[cisco-voip] Right FAX - UDP h.323 with MGCP Analog Fax Devices
Gyrion, Larry
Larry.Gyrion at deancare.com
Thu Mar 28 12:40:33 EDT 2013
Problem Description:
* Fax originating from FXS 1/0/3 hair pinning via controller t1 0/0/0:23 to FXS 1/0/2 is failing.
* Ingress Fax to 608 288 6491 from TAC office in Sydney (Australia) successful.
Call Flow
Fax---Fxs 1/0/03 MGCP-----Call Manager---SIP----Gateway-----Pri (0/0/0:23.23)---Pri (0/0/0:23.1)----Gateway----H323----Call Manager----MGCP 1/0/2 FXS---Fax
Troubleshooting:
* PCM captures taken on FXS ports.
* Completed debugs on the gateway taken.
* There is also CVP services involved in the macro topology - added information.
Applied changes below to dial-peer voice 1000900 voip (SIP) & dial-peer voice 10098901 voip (H323) and tested, still failed.
fax rate 14400
fax-relay ecm disable
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
The call connects and the Re-INVITE for the T.38 negotiation occurs. During the Tone negotiation - from the debugs, the DIS & DCS are seen to be detected & transmitted on the PRI interface - see below extract
digital identification signal (DIS)
digital command signal (DCS)
http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monitoring_--_Fax_Relay#Figure:_T.30_Transactions
T.30 messages extracted from the debugs attached.
064799: Mar 27 23:09:01.559: 1/0/3 3121427988 fr-entered=10(ms)
064800: Mar 27 23:09:01.559: 0/0/0:23 (31798) 3121427990 fr-entered=10(ms)
timestamp=3121429338 fr-msg-det DIS
timestamp=3121429828 fr-msg-tx DIS
timestamp=3121429850 fr-msg-det DIS
timestamp=3121430328 fr-msg-tx DIS
timestamp=3121432308 fr-msg-det DCS
timestamp=3121432770 fr-msg-tx DCS
timestamp=3121432788 fr-msg-det DCS
timestamp=3121433298 fr-msg-tx DCS
As identified, it is possible we are experiencing the below defect, as we note that TCF is seen to be dropped - no training check.
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtu18634
Now we are applying this upgrade and will re-test.
Thank you,
Larry Gyrion | Telecommunications Analyst
Dean Clinic - Corporate Offices
Information Technology
1802 W. Beltline Hwy
Madison, WI 53713
Phone 608.294.6201 | TL 540 | Fax 608.250.1483
larry.gyrion at deancare.com<mailto:larry.gyrion at deancare.com> | www.deancare.com <http://www.deancare.com/>
Partners who care
From: Eric Pedersen [mailto:PedersenE at bennettjones.com]
Sent: Friday, March 22, 2013 3:31 PM
To: Gyrion, Larry; Collins, Matthew; Cisco-voip (cisco-voip at puck.nether.net)
Subject: RE: Right FAX - UDP h.323 with MGCP Analog Fax Devices
Check out CSCtu18634, which your IOS version has. We had many failures with the fax relay switchover due to this.
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Gyrion, Larry
Sent: 22 March 2013 10:32 AM
To: Collins, Matthew; Cisco-voip (cisco-voip at puck.nether.net)
Subject: Re: [cisco-voip] Right FAX - UDP h.323 with MGCP Analog Fax Devices
We ran a fresh test last night and obtained the following results:
The test performed was:
FAX-port 1/0/3---MGCP GW----CUCM-----SIP----GW---PRI---
That call would return to the PRI
PRI---GW----SIP------CUCM---MGCP---GW -FXS 1/0/2-FAX
Basically we have to deal with 2 calls: 2 SIP 2 MGCP IP legs, 4 telephony(ports) legs, for a total of 8 legs.
When starting the outbound call
>From show call active voice brief: 1956 is the segment FXS 1/0/3-CUCM MGCP (2 legs: 1 pots, 1 MGCP)
1956 : 26926 18:20:58.318 CDT Thu Mar 21 2013.1 +0 pid:999103 Answer active
dur 00:00:14 tx:442/74256 rx:460/73600
Tele 1/0/3 (26926) [1/0/3] tx:9190/9190/0ms g711ulaw noise:-72 acom:67 i/0:-71/-82 dBm
1956 : 26927 18:21:03.508 CDT Thu Mar 21 2013.1 +0 pid:0 Originate connecting
dur 00:00:09 tx:443/70880 rx:442/70720
IP 10.23.191.213:19942 SRTP: off rtt:0ms pl:7100/0ms lost:0/1/0 delay:65/65/75ms g711ulaw TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
35 is the segment CUCM SIP-PRI (2 legs: 1 SIP, 1 pots)
35 : 26928 18:21:03.518 CDT Thu Mar 21 2013.1 +-1 pid:1000900 Answer 6082886492 connecting
dur 00:00:00 tx:442/70720 rx:443/70880
IP 10.4.41.2:29138 SRTP: off rtt:0ms pl:7230/0ms lost:0/0/0 delay:55/55/65ms g711ulaw TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
35 : 26929 18:21:03.616 CDT Thu Mar 21 2013.1 +-1 pid:1012000 Originate 2886491 connecting
dur 00:00:00 tx:443/74424 rx:443/70880
Tele 0/0/0:23 (26929) [0/0/0.23] tx:8850/8850/0ms g711ulaw noise:-84 acom:3 i/0:-79/-71 dBm
pid:1000900: this is the incoming dial-peer, meaning that the GW is "answering" that outbound call with a SIP dial-peer:
!
dial-peer voice 1000900 voip
translation-profile incoming 1000900
session protocol sipv2
session target sip-server
incoming called-number .
voice-class codec 1
dtmf-relay rtp-nte
no vad
!
***********************************************************************************************************
Analyzing that first part of the test (outbound call to PSTN) in the call flow:
MGCP fax transport method has been configured for passthrough NSE, and T.38 protocol based.
mgcp modem passthrough voip mode nse
no ccm-manager fax protocol cisco
no mgcp fax t38 inhibit
mgcp package-capability fxr-package
mgcp default-package fxr-package
no mgcp fax t38 ecm
mgcp fax t38 nsf 000000
Whereas SIP will use the voice service method of T.38 protocol based:
!
voice service voip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
!
In theory there should be a selection/preference for T.38 and we see it when the RTP connects for that outbound calls, the RTP link to VoIP endpoints:
1956 : 26927 18:21:03.507 CDT Thu Mar 21 2013.1 +0 pid:0 Originate connecting
dur 00:00:22 tx:741/118560 rx:788/118462
IP 10.23.191.213:19942 SRTP: off rtt:0ms pl:14570/0ms lost:0/1/0 delay:55/55/75ms t38 TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
35 : 26928 18:21:03.517 CDT Thu Mar 21 2013.1 +9400 pid:1000900 Answer 6082886492 connected
dur 00:00:12 tx:741/118560 rx:812/121037
IP 10.4.41.2:29138 SRTP: off rtt:0ms pl:11660/0ms lost:0/0/0 delay:55/55/65ms t38 TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
***********************************************************************************************************
The second part of the call deals with the segment PSTN-PRI-GW-SIP---CUCM-MGCP-FXS-1/0/2
1E3D segment incoming call PRI---MGCP IP side (2 legs;1 pots, 1 MGCP)
1E3D : 26930 18:21:03.774 CDT Thu Mar 21 2013.1 +8910 pid:1004000 Answer 6082886492 active
dur 00:00:00 tx:2/336 rx:2/320
Tele 0/0/0:23 (26930) [0/0/0.1] tx:30/30/0ms g711ulaw noise:-4 acom:3 i/0:-73/-61 dBm
1E3D : 26931 18:21:03.774 CDT Thu Mar 21 2013.2 +8910 pid:1003900 Originate 5656491 active
dur 00:00:00 tx:2/320 rx:3/480
10.4.41.2:24624 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
1E3E is the segment CUCM MGCP-FXS port (2 lets: 1 mgcp, 1 pots or port 1/0/2)
1E3E : 26933 18:21:03.784 CDT Thu Mar 21 2013.1 +0 pid:0 Originate connecting
dur 00:00:08 tx:3/480 rx:2/320
IP 10.23.191.213:28180 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:65/65/65ms g711ulaw TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
1E3E : 26932 18:21:03.788 CDT Thu Mar 21 2013.2 +8890 pid:0 Originate active
dur 00:00:00 tx:2/336 rx:274/43840
Tele 1/0/2 (26932) [1/0/2] tx:5470/5470/0ms g711ulaw noise:-82 acom:3 i/0:-70/-69 dBm
The outbound dial-peer to the CUCM is pid:1003900:
!
dial-peer voice 1003900 voip
description Incoming Calls to CUCM - dhsccmsub4
translation-profile outgoing 1001900
destination-pattern 8.......$
session protocol sipv2
session target ipv4:10.1.233.22
voice-class codec 1
dtmf-relay rtp-nte
no vad
!
Again T.38 should have been chosen however MGCP fails to select T.38 and uses NSE:
1E3D : 26931 18:21:03.777 CDT Thu Mar 21 2013.2 +8910 pid:1003900 Originate 5656491 active
dur 00:00:13 tx:267/42566 rx:318/43370
IP 10.4.41.2:24624 SRTP: off rtt:0ms pl:4560/0ms lost:0/0/0 delay:55/55/65ms t38 TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
1E3E : 26933 18:21:03.787 CDT Thu Mar 21 2013.1 +0 pid:0 Originate connecting
dur 00:00:22 tx:271/42892 rx:293/42485
IP 10.23.191.213:28180 SRTP: off rtt:0ms pl:770/0ms lost:0/0/0 delay:55/55/55ms t38 TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
MODEMPASS nse buf:0/0 loss 0% 0/0 last 0s dur:0/0s
***********************************************************************************************************
For any Fax call both ends at the IP stream have to agree in the switchover/Fax transport method.
The terminating device is in charge of initiating the switchover process based on the tones that the GW is "hearing"
If we consider:
OGW= Originating GW
TGW=Terminating GW
Then:
For the outbound call:
FAX-port 1/0/3---MGCP OGW----CUCM-----SIP----TGW---PRI---
For the inbound call:
PRI---OGW----SIP------CUCM---MGCP---TGW -FXS 1/0/2-FAX
Therefore, based on the outputs above:
1) The fax fails because the MGCP leg to the TGW is "activating" both transport methods simultaneously: T.38 and MODEMPASS
Thank you,
Larry Gyrion | Telecommunications Analyst
Dean Clinic - Corporate Offices
Information Technology
1802 W. Beltline Hwy
Madison, WI 53713
Phone 608.294.6201 | TL 540 | Fax 608.250.1483
larry.gyrion at deancare.com<mailto:larry.gyrion at deancare.com> | www.deancare.com <http://www.deancare.com/>
Partners who care
From: Collins, Matthew [mailto:matthew.collins at linklaters.com]
Sent: Friday, March 22, 2013 4:34 AM
To: Gyrion, Larry; Cisco-voip (cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>)
Subject: RE: Right FAX - UDP h.323 with MGCP Analog Fax Devices
Have you double checked the region settings to make sure the calls are not being restricted to G729. That caught me out initially.
From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Gyrion, Larry
Sent: 21 March 2013 19:15
To: Cisco-voip (cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>)
Subject: [cisco-voip] Right FAX - UDP h.323 with MGCP Analog Fax Devices
Greetings -
We have been working on implementing Right-FAX 10.5 with CUCM 8.5 and have been running into road blocks to a fully functioning product.
In CUCM we have the Right-FAX server utilizing h.323, this all works great for External parties to fax in and for Right Fax to send out.
Where we are running into issue is this:
If the Analog Fax machine is connected to an FSX port (SCCP); we only have issues when the device tries to fax to the internal Right-Fax number. Mainly this reason is because Cisco's SCCP does not support t.38
So we converted the Analog Fax machine's FXS port to MGCP; which we can successfully transmit to the Internal Right-Fax number, however we have these other issues:
1. We cannot fax site to site... cannot fax from one MGCP Analog Fax device to another MGCP Analog Fax device.
2. We cannot fax to the External Right-Fax number
3. We have some failures from incoming faxes from EXTERNAL sources to MGCP Analog Fax devices (this same External source works fine inbound to an SCCP Analog Fax device)
4. We can fax both directions MGCP Analog Fax device to/from SCCP Analog Fax device for internal and external dial.
Cisco has worked with us and has confirm the config is correct on the router for both MGCP and h.323.
The Router IOS > C2951 Software (C2951-UNIVERSALK9-M), Version 15.1(3)T2, RELEASE SOFTWARE (fc1)
We use TCP for our SCCP protocol due to an older issue within our UCCE environment
For the h.323 we are using UDP
Has anyone ran across an issue like this before? Or do you have a suggestion?
Thank you,
Larry Gyrion | Telecommunications Analyst
Dean Clinic - Corporate Offices
Information Technology
1802 W. Beltline Hwy
Madison, WI 53713
Phone 608.294.6201 | TL 540 | Fax 608.250.1483
larry.gyrion at deancare.com<mailto:larry.gyrion at deancare.com> | www.deancare.com <http://www.deancare.com/>
Partners who care
The information contained in this e-mail message and any attachments may be proprietary and is intended only for the confidential use of the designated recipient named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error please notify us immediately at the e-mail address listed above. Thank you.
________________________________
Any business communication, sent by or on behalf of Linklaters LLP or one of its affiliated firms or other entities (together "Linklaters"), is confidential and may be privileged or otherwise protected. If you receive it in error please inform us and then delete it from your system. You should not copy it or disclose its contents to anyone. Messages sent to and from Linklaters may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free. Anyone who communicates with us by email is taken to accept these risks.
Linklaters LLP is a limited liability partnership registered in England and Wales with registered number OC326345. It is a law firm authorised and regulated by the Solicitors Regulation Authority (www.sra.org.uk<http://www.sra.org.uk>). The term partner in relation to Linklaters LLP is used to refer to a member of Linklaters LLP or an employee or consultant of Linklaters LLP or any of its affiliated firms or entities with equivalent standing and qualifications. Please refer to www.linklaters.com/regulation<http://www.linklaters.com/regulation> for important information on our regulatory position.
A list of Linklaters LLP members together with a list of those non-members who are designated as partners and their professional qualifications, may be inspected at our registered office, One Silk Street, London EC2Y 8HQ and such persons are either solicitors, registered foreign lawyers or European lawyers.
The information contained in this e-mail message and any attachments may be proprietary and is intended only for the confidential use of the designated recipient named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error please notify us immediately at the e-mail address listed above. Thank you.
The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.
The information contained in this e-mail message and any attachments may be proprietary and is intended only for the confidential use of the designated recipient named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error please notify us immediately at the e-mail address listed above. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130328/0419adc4/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: conplete call debug.txt
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130328/0419adc4/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 625087151.rar
Type: application/octet-stream
Size: 1218641 bytes
Desc: 625087151.rar
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130328/0419adc4/attachment.obj>
More information about the cisco-voip
mailing list