Re: Ask the Expert: Configuring and Troubleshooting Faxing in Ci - Page 2

ciscomoderator · ‎11-02-2012

With Edson Pineiro

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn best practices and tech tips from Cisco expert Edson Pineiro on the common and complex issues with faxing in Cisco IP voice networks. Cisco fax networks run on top of signalling protocols such as fax T.38, T.37, pass-through, NSE based modem passthrough and the underlying fax T.30 protocol with different modulation types. You can ask any questions on how Cisco Fax networks interact with any of the signalling protocols mentioned before.

Edson Pineiro is a senior customer support engineer in the Cisco Technical Assistance Center in Sydney. His current role includes configuring, troubleshooting, and designing gateways, gatekeepers, Cisco Unified Border Element Enterprise Edition, and Cisco Unified Call Manager using his deep knowledge of signaling protocols such as SIP, H.323, MGCP, SKINNY, and others. He has been involved in several bug fixes, escalations, and critical account cases from around the globe. He has over seven years of experience in the IP voice industry.

Remember to use the rating system to let Edson know if you have received an adequate response.

Edson might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Collaboration, Voice and Video sub-community forum shortly after the event. This event lasts through Nov 16, 2012. Visit this forum often to view responses to your questions and the questions of other community members.

bsoth · ‎11-08-2012

Well wouldnt that be the case if I was planning on using all 24 b channels simultaneously? I would expect to enjoy some level of stat muxing.

Edson Pineiro · ‎11-09-2012

Hi Bsoth,

Your are correct, the amount of dsp channels allocated to both the T1 PRI, (if your using ISDN) and the amount of voice-ports assigned by the FXS card will depending on how many channels get allocated. You can use a partial T1 and limit the amount of channels assigned to the controller by specifying the number or range of time-slots configured in the controller T1. However the reason why I mentioned the use of a fully populated T1, is because T1's are commonly used only in the United States of America, and in my 7 years experience I have only seen partial E1 PRI/CAS/R2 used in both Asia Pacific, the rest of Europe, South American service providers and I have worked on a partial T1 connected to a PBX however I have never seen a partial T1 connected to a service providers PSTN.

Regardless, you can always calculate the amount of DSP channels needed for any voice gateway using the Cisco DSP Calculator referenced above.

Please let me know if you have any further questions.

I hope you have a lovely weekend.

Thank you

&

Regards

Edson Pineiro

CISCO - Australia

padraic.lally · ‎11-08-2012

Hi Edson,

Would it be best practise and normal call setup for the following fax call flow;

Fax Call----PSTN---Cisco-H323-Gateway----Callmanager-Cluster---Fax Server

The Fax Protocol is T.38.

I have setup the callmanagers in the cluster as H.323 Gateways.I believe this is needed to setup

up the h225 call between the callmanager's and fax server.

thanks,

Padraic

Edson Pineiro · ‎11-09-2012

Hi Padraic,

Thank you for your question. Regarding your T.38 Fax server, it should work using h.323. However from experience you may find interoperability issues when configuring fast start, h245 tunnelling on the fax sever since UCM does not support h245 tunnelling and only supports outbound fast-start with MTP statically allocated. If you are going to use h323 between UCM and the fax server, my I suggest to disable fast start and h245 tunnelling on the fax server. Please also remember to disable SG3 and ECM accordingly. Also if it is a requirement to use outbound fast start, then remember to configure the pass-through codec on your IOS based Media Termination Point since call manager MTP does not support passthrough codecs. This rule applies to both SIP and h323 when using the MTP check-box. Also, if you run into some h323 signalling issues try checking and un-checking the "Wait for far end h.245 terminal capability set" in the h3232 gateway or trunk.

For your reference please find the following config sample on how to configure the pass-through codec on an IOS SCCP controlled MTP:

!

dspfarm profile 1 transcode

codec pass-through <----------------- Codec pass-through

codec g729r8

codec g729abr8

codec g729ar8

codec g711alaw

codec g711ulaw

maximum sessions 6

associate application SCCP

!

dspfarm profile 2 mtp

codec g711ulaw

codec pass-through <---------------- Codec pass-through

maximum sessions software 10

associate application SCCP

!

Also, with specific regards to the embedded h245 protocol stack within h.323, I have found that the h245 TCP socket sometimes fails to establish or transmit the terminal capability set (TCS) to the signalling peer due to the TCS window size being too large and either fragmented, dropped within the route path or the large port range occupied by h245 being blocked by 3rd party firewalls.

To further comment on h.323, I have had more success using SIP signalling when integrating Right Fax and Xmedius Fax servers. Not to say it won't work, but keep in mind that the old h323 gatekeeper environments are being phased out by the new SIP signalling devices such as SBC and SIP proxies.

Please let me know if you have any further questions or queries regarding your fax issues.

Thank you

&

Regards

Edson Pineiro

CISCO

danplacek · ‎11-08-2012

What would the best practice be for configuring a VG224 + CME/ISR with a PRI for fax?

Fax Machine <-> VG224 FXS <-> C3945/CME <-> PSTN (PRI)

Is H323 or SCCP recommended? (Do both work?)

Could I see a recommended dial-peer configuration?

Thanks.

Edson Pineiro · ‎11-09-2012

Hi Daniel,

Thank you & good question. Both h.323 and SCCP should work for fax when integrating the VG224 with the CME or the PRI gateway. However please be advised of the following SCCP limitation when compared to h.323.

SCCP supports NSE based modem passthrough, NSE based fax t.38. However SCCP does not support protocol based T.38 or protocol pass-through which makes it difficult to integrate SCCP controlled FXS ports with 3rd party t.38 fax endpoints such as SIP carriers and fax servers supporting t.38 or other devices supporting fax protocol based pass-through.
H.323, SIP, supports protocol based T.38, NSE based fax t.38, NSE based modem passthrough, Protocol based fax pass-through. This makes these protocols easy to integrate with most fax devices.
Also MGCP supports most of the above faxing protocols except for protocol based fax pass-through.
As for fax t.37, the call flow topology is slightly different as they only function when connected to a pots (plain old telephony system) call-leg such as an FXO or a PRI voice-port. The TCL script will not invoke when the voip dial-peer terminates from a SIP endpoint.

With regards to the configuration, I like to keep the fax setting global as appose to dial-peer specific for simplicity. NSE based modem passthrough should work for both the SCCP and H.323. After registering the SCCP controlled endpoints please reference the following fax parameters:

Modem Passthrough Config Sample:

VG224:

!

voice service voip

modem passthrough nse codec g711ulaw

!

voice service pots

fax rate disable

!

CME Gateway:

!

voice service voip

modem passthrough nse codec g711ulaw

!

voice service pots

fax rate disable

!

If your integrating a third party fax end point then my suggestion would be to use either h.323, or SIP on the VG224 with fax t.38. You can also configure multiple signalling protocol on the VG224 and keep your analogue handset registered as SCCP and the ports connected to fax machines as SIP or h323 depending if T.38 is part of your design. Additional SIP/h323 voip dial-peers may be required to route calls between the VG224 and the PSTN gateway if t.38 is required.

I hope you have a lovely weekend. Let me know if you need any further configuration samples.

Thank you

&

Regards

Edson Pineiro

CISCO

padraic.lally · ‎11-09-2012

Edson,

Thanks for the response. I'm currently migrating a customer from UCM 6.x to 8.x.

I have pointed the fax number to the current live cluster and to the new cluster.I’m receiving ring-back but no fax tone for when I put to number to 8.x I have analysed the Call manager logs for both calls to the live and new cluster. The live cluster is setting up the H.225 call between the Xmedius Server in Munich and the ingress Gateway. For the new cluster an invite is sent from the Ingress Gateway but the new Call manager does not setup up the call. The Xmedius Fax server configuation has been ammended for the new UCM cluster.

Padraic

Edson Pineiro · ‎11-10-2012

Hi Padraic,

Thank you for your question. To further investigate the issue please confirm the call flow in both the working setup with UCM 6.x and the new topology using with UCM 8.x, can you please verify the following topology diagram:

Call flow topology:

******************************

Functional UCM 6.x

fax --- PSTN --- VGW ---- H.323 ---- UCM 6.x ---- H.323 ---- Xmedius ---- Email

Non-Functional UCM 8.x

fax --- PSTN --- VGW ---- SIP --- UCM 8.x ----- H323 ---- Xmedius --- Email

According to your note, you can see the gateway send the Invite to call manager, however the calling party continue to hear ring back tone and the call does not connect. In the SIP signalling, does the call manager return a 200-ok after sending an 180 ringing or a 183 session progress response?

Commonly I have seen similar symptoms with h323 call flows when either the h245 signalling does not exchange it's codec capabilities on Connect (TCS, OLC), or if the far end h323 endpoint does not return a h225 Connect message to initiate the exchange of the h245 media capabilities. Sometimes enabling outbound fast-start and un-checking "wait for far end terminal capability set" on the h225 trunk in UCM can change the symptom slightly. Though this is only an assumption, to confirm what it actually happening in your scenario I require a debug, a packet capture and a call manager detailed trace. Also please confirm the above call flow topology. If you are using SIP, early media can be enabled by checking MTP on the SIP trunks.

Please let me know if your still running into issues and if you are please upload the packet capture from the Xmedius, a detailed call manager trace and the following debugs on the voice gateway:

!

debug voip ccapi

debug fax relay t30 all

debug ccsip messages

!

Don't forget to record the calling, called party phone number and the time of the test call.

Thank you

&

Regards

Edson Pineiro

CISCO

nexth0pself · ‎11-12-2012

Hi Edson

We have some problem about Fax that connected to VG224. The problem is when I try to send a file using Internal connection, the result was not to bad.From 3 sample, 2 result was OK and sent within full page and the other one was failed to send. But when I try to send a file using PSTN connection, the result was bad.

From 3 sample that I try, 1 sample was sent but the receiver only receive within less than half page and 2 sample was failed to send.

Below of this detailed information about testing environment.

1. CUCM v.8.5.1.10000-26
2. VG224 IOS Version 12.4(24)T6
3. Router VG 3925 IOS Version 15.2(1)T1

FYI, I'm already try to change some configuration :

Before :

voice service voip
fax protocol t38 nse ls-redundancy 0 hs-redundancy 0 fallback cisco modem passthrough nse codec g711alaw

After :

voice service voip
fax protocol none
modem passthrough nse codec g711alaw

I also change codec g711alaw become g711ulaw but that's all not solving our problem.

I attached the scheme and also configuration and debugs.

Please let me know if there is misconfiguration or some compatibility issue in this case.

Thank you for your help.

Best Regards

Best Regards,

Nanda Nurhadyan

Edson Pineiro · ‎11-13-2012

Hello Nanda,

Thank you for your question and for uploading debugs, configuration and sharing your topology.

I understand that intermittently outbound PSTN and internal faxes do not function as required. The debugs provided contain many fax and voice calls and I'm not sure which one actually failed other than one or two specific issue found during the NSE and mgcp packet exchange. Since you have multiple fax issues, may I suggest we focus on one specific call flow excluding other complexity using a basic fax test call from the VG224 to a known working fax machine on the PSTN. When I say PSTN fax machine, please choose a fax machine on the PSTN that your going to benchmark and base your configuration on. This means the test fax machine should be 100% functional with other PSTN fax machine before we test your Cisco device. Preferably the fax machine on the PSTN can be adjusted for settings such as ECM and SG3. For further testing please review my action plan.

According to the debugs collected I analysed one specific call flow on the VG224 that I'm suspecting a failure. According to the NSE exchange, the 192 then 193 events were exchanged however there was a follow-up 192 event. The follow-up 192 event may have caused the fax up-speed failure. However with the specific debugging collected I was unsure of what exact command were enabled on both the VG224 and the MGCP gateway, or wether or not the modem passthrough command were matching codecs. Please see the following snippet:

BPN-VG224-OFN-1#

*Mar 4 00:56:23.461: s=VoIP d=DSP payload 0x64 ssrc 0x65591CA sequence 0x154F timestamp 0x187FA17C

*Mar 4 00:56:23.461: << Pt:100 Evt:192 Pkt:00 00 00

*Mar 4 00:56:23.469: //258/7183BACF824A/CCAPI/cc_api_call_feature:

Feature Type=13, Interface=0x6424A538, Call Id=258

*Mar 4 00:56:23.473: s=VoIP d=DSP payload 0x64 ssrc 0x65591CA sequence 0x1551 timestamp 0x187FA17C

*Mar 4 00:56:23.473: << Pt:100 Evt:192 Pkt:00 00 00

*Mar 4 00:56:23.477: s=DSP d=VoIP payload 0x64 ssrc 0x1C8C sequence 0x9BF timestamp 0xD664B3D0

*Mar 4 00:56:23.477: Pt:100 Evt:192 Pkt:00 00 00 >>

BPN-VG224-OFN-1#

*Mar 4 00:56:23.489: s=DSP d=VoIP payload 0x64 ssrc 0x1C8C sequence 0x9C0 timestamp 0xD664B3D0

*Mar 4 00:56:23.489: Pt:100 Evt:192 Pkt:00 00 00 >>

*Mar 4 00:56:23.493: s=VoIP d=DSP payload 0x64 ssrc 0x65591CA sequence 0x1553 timestamp 0x187FA17C

*Mar 4 00:56:23.493: << Pt:100 Evt:192 Pkt:00 00 00

*Mar 4 00:56:23.509: s=DSP d=VoIP payload 0x64 ssrc 0x1C8C sequence 0x9C1 timestamp 0xD664B3D0

*Mar 4 00:56:23.509: Pt:100 Evt:192 Pkt:00 00 00 >>

*Mar 4 00:56:23.509: //258/7183BACF824A/CCAPI/cc_api_modify_media_ind:

IFType=0x9, Source Call Id=0x102, Destination Call Id=0x103,

Codec=1, Codec Bytes=160

*Mar 4 00:56:23.653: s=VoIP d=DSP payload 0x64 ssrc 0x65591CA sequence 0x1563 timestamp 0x187FA76C

*Mar 4 00:56:23.653: << Pt:100 Evt:193 Pkt:00 00 00

*Mar 4 00:56:23.661: s=VoIP d=DSP payload 0x64 ssrc 0x65591CA sequence 0x1565 timestamp 0x187FA76C

*Mar 4 00:56:23.661: << Pt:100 Evt:193 Pkt:00 00 00

*Mar 4 00:56:23.669: s=DSP d=VoIP payload 0x64 ssrc 0x1C8C sequence 0x9D1 timestamp 0xD664B9C0

*Mar 4 00:56:23.669: Pt:100 Evt:193 Pkt:00 00 00 >>

BPN-VG224-OFN-1#

*Mar 4 00:56:23.677: s=DSP d=VoIP payload 0x64 ssrc 0x1C8C sequence 0x9D3 timestamp 0xD664B9C0

*Mar 4 00:56:23.677: Pt:100 Evt:193 Pkt:00 00 00 >>

*Mar 4 00:56:23.681: s=VoIP d=DSP payload 0x64 ssrc 0x65591CA sequence 0x1568 timestamp 0x187FA76C

*Mar 4 00:56:23.685: << Pt:100 Evt:193 Pkt:00 00 00

*Mar 4 00:56:23.697: s=DSP d=VoIP payload 0x64 ssrc 0x1C8C sequence 0x9D6 timestamp 0xD664B9C0

*Mar 4 00:56:23.697: Pt:100 Evt:193 Pkt:00 00 00 >>

BPN-VG224-OFN-1#

*Mar 4 00:56:27.857: //258/7183BACF824A/CCAPI/cc_api_call_feature:

Feature Type=1, Interface=0x6424A538, Call Id=258

BPN-VG224-OFN-1#

*Mar 4 00:56:30.697: //258/7183BACF824A/CCAPI/cc_api_call_feature:

Feature Type=1, Interface=0x6424A538, Call Id=258

BPN-VG224-OFN-1#

*Mar 4 00:56:41.717: //258/7183BACF824A/CCAPI/cc_api_call_feature:

Feature Type=1, Interface=0x6424A538, Call Id=258

BPN-VG224-OFN-1#

*Mar 4 00:56:47.273: s=VoIP d=DSP payload 0x64 ssrc 0x65591CA sequence 0x1C9F timestamp 0x1882898C

*Mar 4 00:56:47.273: << Pt:100 Evt:192 Pkt:00 00 00

*Mar 4 00:56:47.281: s=VoIP d=DSP payload 0x64 ssrc 0x65591CA sequence 0x1CA1 timestamp 0x1882898C

*Mar 4 00:56:47.281: << Pt:100 Evt:192 Pkt:00 00 00

*Mar 4 00:56:47.305: s=VoIP d=DSP payload 0x64 ssrc 0x65591CA sequence 0x1CA3 timestamp 0x1882898C

*Mar 4 00:56:47.305: << Pt:100 Evt:192 Pkt:00 00 00

BPN-VG224-OFN-1#

*Mar 4 00:56:52.677: //258/7183BACF824A/CCAPI/cc_api_call_feature:

Feature Type=9, Interface=0x6424A538, Call Id=258

*Mar 4 00:56:52.681: //258/7183BACF824A/CCAPI/cc_api_voice_mode_event:

Call Id=258

*Mar 4 00:56:52.681: //258/7183BACF824A/CCAPI/cc_api_voice_mode_event:

Call Entry(Context=0x0)

*Mar 4 00:56:53.957: //258/7183BACF824A/CCAPI/cc_api_call_feature:

Feature Type=1, Interface=0x6424A538, Call Id=258

*Mar 4 00:56:53.969: s=DSP d=VoIP payload 0x64 ssrc 0x1C8C sequence 0x1547 timestamp 0xD6686CA0

*Mar 4 00:56:53.969: Pt:100 Evt:192 Pkt:00 00 00 >>

*Mar 4 00:56:53.977: s=DSP d=VoIP payload 0x64 ssrc 0x1C8C sequence 0x1548 timestamp 0xD6686CA0

*Mar 4 00:56:53.977: Pt:100 Evt:192 Pkt:00 00 00 >>

*Mar 4 00:56:53.997: s=DSP d=VoIP payload 0x64 ssrc 0x1C8C sequence 0x154A timestamp 0xD6686CA0

*Mar 4 00:56:53.997: Pt:100 Evt:192 Pkt:00 00 00 >>

*Mar 4 00:56:54.001: //258/7183BACF824A/CCAPI/cc_api_modify_media_ind:

IFType=0x9, Source Call Id=0x102, Destination Call Id=0x103,

Codec=1, Codec Bytes=160

*Mar 4 00:56:54.013: s=VoIP d=DSP payload 0x64 ssrc 0x65591CA sequence 0x1EC9 timestamp 0x18835C2C

*Mar 4 00:56:54.013: << Pt:100 Evt:192 Pkt:00 00 00

*Mar 4 00:56:54.021: s=VoIP d=DSP payload 0x64 ssrc 0x65591CA sequence 0x1ECA timestamp 0x18835C2C

*Mar 4 00:56:54.021: << Pt:100 Evt:192 Pkt:00 00 00

*Mar 4 00:56:54.041: s=VoIP d=DSP payload 0x64 ssrc 0x65591CA sequence 0x1ECB timestamp 0x18835C2C

BPN-VG224-OFN-1#

*Mar 4 00:56:54.041: << Pt:100 Evt:192 Pkt:00 00 00

BPN-VG224-OFN-1#

*Mar 4 00:57:16.637: //258/7183BACF824A/CCAPI/cc_api_call_feature:

Feature Type=1, Interface=0x6424A538, Call Id=258

Due to the limited debugging that was enabled I can not confirm were exactly the RTP NSE packet terminate or originate from, other than the VG224 received it from somewhere and sent it. From the logs collected on the VG224 I cannot verify why the fax re-trained. Also according to the NSE exchange I can see the event 193 caused by the Ansam tone with phase reversal for Super G3 calls. Can you please disable both ECM and SG3 on this fax machine. As both these settings are a cause of many fax failures.

According to the debugs on the gateway. The MGCP create connection CRCX from call manager is responded with a 200-ok including an NSE offering and advertising it own local IP address to terminate the media. The call manager responds to the 200-ok with a modify connection MDCX with the IP address 10.193.139.204. The IP address 10.193.139.204 is the IP were the gateway will send and expect the RTP traffic to source from. However I would have expected this IP address to belong to the VG224. The VG224 IP address is 10.193.133.201. If the IP address 10.193.139.204 belongs to an MTP call manager resource then the fax will obviously fail. This is because the only MTP resource that supports faxing is IOS based using the pass through codec. However even IOS based MTP has it's limits were it's only supported using fax protocol t.38.

!

Nov 1 2012 16:35:00.548 WIB: MGCP Packet received from 10.193.144.1:2427--->

CRCX 681267 S0/SU0/DS1-1/31@JKT-VG1-CR-3925 MGCP 0.1

C: D000000009bae861000000F500004b08

X: 1f

L: p:20, a:PCMU, s:off, t:b8

M: recvonly

R: D/[0-9ABCD*#]

Q: process,loop

<---

!

Nov 1 2012 16:35:00.552 WIB: MGCP Packet sent to 10.193.144.1:2427--->

200 681267 OK

I: 15640

v=0

c=IN IP4 10.193.144.126 <----------------- IP address is the local loopback on the mgcp gateway.

m=audio 31886 RTP/AVP 0 100

a=rtpmap:100 X-NSE/8000

a=fmtp:100 192-194 <----------------------- the mgcp gateway is offering 192-194 payload types for modem passthrough

<---

Nov 1 2012 16:35:00.692 WIB: MGCP Packet received from 10.193.144.1:2427--->

MDCX 681269 S0/SU0/DS1-1/31@JKT-VG1-CR-3925 MGCP 0.1

C: D000000009bae861000000F500004b08

I: 15640

X: 1f

L: p:20, a:G.729b, s:off, t:b8

M: sendrecv

R: D/[0-9ABCD*#]

S:

Q: process,loop

v=0

o=- 87616 0 IN EPN S0/SU0/DS1-1/31@JKT-VG1-CR-3925

s=Cisco SDP 0

t=0 0

m=audio 16538 RTP/AVP 18

c=IN IP4 10.193.139.204 <-------------------- Call Manager responds with this IP address. This IP address is were the RTP packet will terminate.

<---

Action Plan:

***************************

Currently your call flow topology diagram looks like so:

Fax machine ---- VG224 ---- SCCP ---- UCM ---- MGCP ---- VGW ----- ISDN ----- PSTN ---- ISDN ----- VGW ----- MGCP ---- UCM ----- SCCP ---- VG224 ---- FAX machine

May I suggest we make the call flow simple, for testing different command scenarios in order to verify an acceptable working base configuration. After verifying an acceptable working base configuration for a simple scenario then we can move on to testing the rest. For debugging and test purposes, please simplify the call flow, for example:

Fax machine ---- VG224 ---- SCCP ----- UCM ----- MGCP ----- VGW ----- ISDN ---- PSTN ---- Known Working Fax

To narrow the issue and isolate the problem further, lets test with one faxing protocol. From experience Disabling Cisco fax relay and enabling modem passthrough seems to be a stable test scenario. Please adjust the configuration as follows:

VG224:

!

voice service pots

fax rate disable

!

voice service voip

modem passthrough nse codec g711ulaw

fax protocol none

!

VGW:

!

mgcp modem passthrough voip mode nse

mgcp modem passthrough voip codec g711ulaw

!

Please make sure the same configuration is enabled on both the MGCP gateway and the SCCP controlled VG224. I.e disable cisco fax relay, disabled fax t38, and enable modem passthrough on both the VG224 and MGCP gateway on the call manager configuration page.

With regards to your media resource group lists, please ensure that there is no MTP or transcoding assigned to your fax calls.

As for the fax machine, please apply the following setting on the physical fax machine:

!

ECM = Disable

Super G3 (SG3) = Disable

Fax speed = 14400

!

After applying the above change, please enable the following debugs and collect only one fax test call at a time, with no other calls on both the VG224 and the gateway:

VG224

!

debug voip rtp session named-event

debug voip ccapi

debug voip vtsp all

debug vpm signal

debug voip app stcapp port x/x

debug voip rtp packet

!

MGCP Gateway

!

debug mgcp packet

debug isdn q931

debug voip ccapi

debug voip vtsp all

debug voip rtp session named-event

debug voip rtp packet

!

In addition to the above debugs I require a packet capture from the mgcp gateway and a PCM capture on the VG224. To collect the packet capture on the ISR G2, please use IP export. For your reference I noted the procedure to both collect a PCM and packet capture on the IOS, please see the following guide:

IOS Packet capture using IP Export:

*****************************************************

- Hint: Does not work well with the first generation ISR (2800, 3800). Works very well in ISR G2 (2900, 3900).

- "Option:" access list to filter out any un-wanted captures:

!

access-list 100 permit ip any any

access-list 100 permit udp any any

access-list 100 permit tcp any any

!

ip traffic-export profile faxT30 mode capture

bidirectional

incoming access-list 100

outgoing access-list 100

no length

!

interface GigabitEthernet0/0

ip traffic-export apply faxT30 size 100000000

!

enable:

traffic-export interface type number clear

traffic-export interface type number start

traffic-export interface type number stop

traffic-export interface type number copy

!

The traffic-export can be collected directly from the buffer into the flash/tftp/ftp etc

Router IP Traffic Export Packet Capture Enhancements

http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_rawip.html

PCM capture on IOS gateway prior to IOS 15.2(2)T1

*****************************************************

!

voice hpi capture buffer 50000000

voice hpi capture destination flash:pcm.dat

!

vg224#test voice port x/x/x pcm-dump caplog 7 duration 255

!

Run the test voice port command from enable mode.

!

PCM capture on IOS gateway.

*****************************************************

IOS 15.2(2)T1 or above.

!

voice pcm capture buffer 200000

voice pcm capture destination tftp://x.x.x.x/

!

dial-peer voice x voip/pots

pcm-dump caplog 7 duration xxx

!

I understand this is a a lot of capturing and work to do, however I usually do this in 15 minutes over webex. I't's just a lot of details to note when working over a forum. If you like, please feel welcome to open a TAC case if needed. Otherwise I am happy to explain it on my forum.

If you have any further questions please do not hesitate to contact me.

Thank you

&

Regards,

Edson Pineiro

CISCO

sanotto · ‎11-13-2012

T.38. MGCP, SIP and DTMF Relay (mismatch) Issues

Hi Edson,

I have the following scenario t.38 Fax scenario:

FAX Machine <-> MGCP GW <-> CUCM SIP TRK <-> CUBE <-> ITSP

CUCM version 8.6, CUBE15.2, MGCP GW and CUBE using protocol based switchover.

On the CUBE dial peers, I'm using only rtp-nte as the dtmf relay method, on the MGCP GW (I think) I'm using rtp-nte (nte-gw) as well.

On an outbound fax call I could see from the CUCM debugs, that a MTP is being invoked due to a DTMF relay method mismatch, and the CUCM finally responds to the CUBE with a "SIP/2.0 488 Not Acceptable Media" message, after the CUBE sends a re-invite o establish the t.38 session. I also noticed that just before the CUCM sends the SIP rejection message back to the CUBE the following message appears: "T38-SIP: Rejecting T38 only incoming offer-INVITE_NOT_ACCEPTABLE_HERE. The MTP does not support Pass Thru for FAX". This issue was fixed using the codec pass-though in an IOS MTP. After that configuration the fax transmission went through with no issues.

I could also fix it adding the sip-kpml dtmf relay method on the CUBE incoming dial peer (no MTP use whatsoever), however in my environment I must use rtp-nte only (on the incoming CUCM facing dial peers), which forces me to use the first solution temporarily.

Now, here are my questions (I guess I'm missing something really obvious here):

1.- Why in this scenario the MTP is being invoked only when sip-kpml is not available on the CUBE dial peer? where is the actual dtmf relay mismatch happening?

2.- What is the correct MGCP configuration (dtmf relay wise) such that I dont have to use an MTP in this scenario?

3.- Can you please elaborate on the MGCP gw DTMF relay methods and how they are related to t.38 protocol based switchover scenarios?

Here's a snippet of the mgcp gw and cube configuration:

**********************************

ccm-manager fallback-mgcp

ccm-manager redundant-host x.x.x.x y.y.y.y

ccm-manager mgcp

no ccm-manager fax protocol cisco

ccm-manager music-on-hold

!

mgcp

mgcp call-agent z.z.z.z 2427 service-type mgcp version 0.1

mgcp dtmf-relay voip codec all mode nte-gw

mgcp rtp unreachable timeout 1000 action notify

mgcp modem passthrough voip mode nse

mgcp package-capability rtp-package

mgcp package-capability sst-package

mgcp package-capability pre-package

mgcp default-package fxr-package

no mgcp package-capability res-package

no mgcp timer receive-rtcp

mgcp sdp simple

mgcp bind control source-interface GigabitEthernet0/0

mgcp bind media source-interface GigabitEthernet0/0

dial-peer voice 150 voip

description incoming voice / t.38 fax call facing CISCO UCM IPPBX

session protocol sipv2

incoming called-number ^912225551212$<- fake test fax number

voice-class codec 1

voice-class sip asserted-id pai

no voice-class sip privacy-policy send-always

voice-class sip privacy-policy passthru

voice-class sip profiles 2

dtmf-relay rtp-nte

fax rate 14400 bytes 48

fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

no vad

voice class sip-profiles 2

response ANY sip-header Allow-Header modify "UPDATE," ""

voice class codec 1

codec preference 1 g729r8 bytes 30

codec preference 2 g711ulaw

**********************************

I'm also attaching a couple of logs for your reference:

1.- call-failed-dtmf-mismatch.txt, Call-ID: ca9a0e00-a21c875-28494-ce0960a

2.- call-ok-no-mtp-invoked.txt, Call-ID: 2568500-a21cddb-2863d-ce0960a

Thanks so much, and please let me know if you need more info.

Otto

Edson Pineiro · ‎11-14-2012

Hello Otto,

Thank you for your question and for collecting logs. After analysing the ccm detail trace, I traced through a phone call from calling number 6369491576, called number 913143925415 between a SIP trunk and an MGCP gateway with a fax machine. When using RFC2833 on the CUBE and Gateway controlled NTE on the mgcp gateway I can see that RTP-NTE negotiates successfully on the SIP trunk, however the MGCP gateway negotiates out of band DTMF. As per the 200-ok response to the modify connection MDCX request received from the mgcp gateway the telephony-event 101 is present in the gateway mgcp SDP header. This means that the MGCP gateway has offered rtp-nte, however is waiting on further response from the call manager. The call manager also responds with a MDCX however the SDP header does not include telephony-event 101, instead it includes out of band DTMF signalling support using the MDCX header. Please see the following snippets:

!

16:23:52.074 |MGCPHandler send msg SUCCESSFULLY to: 10.150.224.50

MDCX 16170 AALN/S1/SU0/0@stc1ube1.lmiaerospace.com MGCP 0.1

C: A000000003110bf4000000F5

I: 2

X: 9

L: p:20, a:G.729, s:off, t:b8, fxr/fx:t38

M: recvonly

R: L/hu

Q: process,loop

|3,100,157,1273.1^*^*

!

16:23:52.076 |MGCPHandler received msg from: 10.150.224.50

200 16170 OK <---------------------------------------------- 200-ok with SDP response from the gateway, in response to the MDCX request sent from UCM.

v=0

c=IN IP4 10.150.224.50

m=audio 32568 RTP/AVP 18 101

a=rtpmap:18 G.729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000 <---------------- Telephony-event using payload type 101 support for rtp-nte.

a=fmtp:101 0-15

a=X-sqn:0

a=X-cap: 1 audio RTP/AVP 100

a=X-cpar: a=rtpmap:100 X-NSE/8000

a=X-cpar: a=fmtp:100 192-194,200-202

a=X-cap: 2 image udptl t38

|3,100,159,1.654719^10.150.224.50^*

!

16:23:52.079 |MGCPHandler send msg SUCCESSFULLY to: 10.150.224.50

MDCX 16171 AALN/S1/SU0/0@stc1ube1.lmiaerospace.com MGCP 0.1

C: A000000003110bf4000000F5

I: 2

X: a

L: p:20, a:G.729, s:off, t:b8, fxr/fx:t38

M: sendrecv

R: L/hu, L/hf, D/[0-9ABCD*#], FXR/t38 <-------------- OOB DTMF request by UCM "D/[0-9ABCD*#]"

S:

Q: process,loop

v=0

o=- 2 0 IN EPN AALN/S1/SU0/0@stc1ube1.lmiaerospace.com

s=Cisco SDP 0

t=0 0

m=audio 32496 RTP/AVP 18

c=IN IP4 10.150.224.50

a=X-sqn:0

a=X-cap:1 image udptl t38

!

!!!!######################### The above SDP header from UCM does not include telephony-event support (RFC2833).

!

When integrating RFC2833 between 2 separate MGCP gateway's the rule of thumb is that you can use gateway controlled NTE to negotiate the payload type between 2 separate MGCP gateways. However when integrating RFC2833 between an MGCP gateway and a non-MGCP gateway, the call manager (Call-Agent, "CA") should negotiate the payload type between both endpoints. Since the MGCP gateway is currently using out of band (OOB) DTMF it requires an MTP resource to terminate the media and signal the Call Agent via SCCP of the DTMF digit when the other call-leg (SIP trunk) negotiates RFC2833. Basically MTP is required in this scenario to convert RFC2833 to OOB DTMF. Since Call Manager MTP does not support the passthrough codec, faxing will fail and the UCM will return a 488 media not acceptable to disconnect the call. This is functioning as per design, only IOS based MTP supports passthrough codec which is required to up-speed fax calls using fax protocol t.38.

As per the following document in order to integrate RFC2833 between an MGCP gateway and a non-MGCP endpoint you should use the following commands on the MGCP gateway:

!

mgcp dtmf-relay voip codec all mode nte-ca

mgcp package-capability fm-package

!

DTMF Signaling from Cisco MGCP Gateways to the IVR Services with SIP Trunks

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00808b6ca6.shtml#Tp2

Please apply the above command change and collect the following from both the mgcp gateway and the CUBE:

mgcp gateway:

!

show mgcp

show call active voice | in Dtmf

show call history voice | in Dtmf

!

CUBE

!

show call active voice | in Dtmf

show call history voice | in Dtmf

!

When collecting the above show output, please ensure that you have an active fax call between the CUBE and the MGCP gateway. Please also attach an updated CCM detailed trace.

For your future reference I'm also including the following command reference regarding mgcp dtmf relay.

mgcp dtmf-relay

http://www.cisco.com/en/US/docs/ios/12_3/vvf_r/vrg_m1_ps1839_TSD_Products_Command_Reference_Chapter.html#wp1022347

If you have any further questions please do not hesitate to contact me.

Thank you

&

Regards

Edson Pineiro

CISCO

sanotto · ‎11-14-2012

Thanks for your detailed explanation Edson,

It works now with the suggested commands and no MTP use. I was missing the fact that one will only use nte-gw when talking to other MGCP gws, and not when doing it to SIP gateways. In normal voice calls from the analog mgcp ports the dtmf could be passed with no issues though (using nte-gw).

Here's the show MGCP summarized output:

*************************************

MGCP Admin State ACTIVE, Oper State ACTIVE - Cause Code NONE

MGCP call-agent: x.x.x.x 2427 Initial protocol service is MGCP 0.1

MGCP dtmf-relay voip codec all mode nte-ca

MGCP voip modem passthrough mode: NSE, codec: g711ulaw, redundancy: DISABLED,

MGCP voip modem relay: Disabled

MGCP voip mdste modem relay: Disabled

MGCP voip mdste modem mer relay: Disabled

MGCP T.38 Named Signalling Event (NSE) response timer: 200

MGCP simple-sdp ENABLED

MGCP undotted-notation DISABLED

MGCP codec type g711ulaw, MGCP packetization period 20

MGCP default package: fxr-package

MGCP supported packages: gm-package dtmf-package trunk-package line-package

hs-package rtp-package atm-package ms-package dt-package

mo-package mt-package sst-package fxr-package pre-package

md-package fm-package

MGCP T.38 Max Fax Rate is DEFAULT

MGCP T.38 Fax is ENABLED

MGCP T.38 Fax ECM is DISABLED

MGCP T.38 Fax NSF Override is DISABLED

MGCP T.38 Fax Low Speed Redundancy: 0

MGCP T.38 Fax High Speed Redundancy: 0

MGCP Fax relay SG3-to-G3: ENABLED

MGCP control bound to interface GigabitEthernet0/0

MGCP media bound to interface GigabitEthernet0/0

MGCP Dynamic payload type for NTE is 101

**********************

It would be nice to see this type of information on the actual Fax, Modem, and Text Support over IP Configuration Guide, as this is very common scenario nowadays when using sip trunks and t.38.

Really appreciate your help.

Thanks,

Otto

Edson Pineiro · ‎11-14-2012

Hello Otto,

Thank you for your feedback, I really appreciate knowing the results of my suggestions. I'm glad it is working now, and as for our Cisco Documentation I will forward your comments onto the BU. In the past I have opened documentation issues with our documentation teams to make adjustments. It would be good to document common case scenarios and typical troubleshooting examples in the guide.

For your reference I'm adding the following fax relay troubleshooting guide. The basic concepts and functionality is documented, however it fails to display an up-to date common case scenario such as a typical mgcp gateway to SIP CUBE topology.

Cisco IOS Voice Troubleshooting and Monitoring -- Fax Relay

http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monitoring_--_Fax_Relay#Troubleshooting_T.38_Fax_Relay

I'm also going to reference the following Fax Configuration and Troubleshooting Project, which displays certain scenarios which should be complete in future to show certain call flows and debugs:

Fax Configuration and Troubleshooting Project

https://supportforums.cisco.com/community/netpro/collaboration-voice-video/ip-telephony/blog/2010/10/26/fax-configuration-and-troubleshooting-project

Hello All,

Typical Fax Config

************************************

If you want Guys, I will be happy to document certain call scenarios and fax configuration using this Forum, for example: SCCP controlled ATA186 -- UCM -- MGCP Gateway --- ISDN -- Fax or VG224 --- MGCP --- UCM --- SIP --- CUBE --- SIP --- Carrier?

Please let me know if there is a call scenario that you would like to clarify. Everyone that adds a call flow scenario I will provide a typical fax configuration sample for the devices provided in the call flow. Also if your willing to test it, I will debug it and analyse it on the forum :-)

************************************

If you have any further questions please let me know.

Thanks again,

&

Regards

Edson Pineiro

CISCO

fhk-cseifert · ‎11-15-2012

Hi Edson,

at first, thank you for your great discussion about the fax-theme with many new infos and helps.

My question to you is, if you please take a look at our fax-scenario? ...we want to use a sip-provider in near future beside the good-known E1/PRI lines.

Here are our call flow:

PSTN<=E1=>C2921<=mgcp=>UCM8.6<=sccp=>VG224

and

PSTN<=sip=>CUBE<=sip=>UCM8.6<=sccp=>VG224

The C2921 one hardware for cube and mgcp-gw.

VG224-config:

voice service voip

fax protocol t38 nse version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw

modem passthrough nse codec g711alaw

At UCM for VG224 ModemPassthrough and T38FaxRelay enabled. CiscoFaxRelay disabled.

C2921-config:

voice service voip

fax protocol t38 nse version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw

modem passthrough nse codec g711alaw

MGCP:

mgcp

mgcp call-agent x.y.z.a 2427 service-type mgcp version 0.1

mgcp dtmf-relay voip codec all mode out-of-band

mgcp rtp unreachable timeout 1000 action notify

mgcp modem passthrough voip mode nse

mgcp package-capability rtp-package

mgcp package-capability sst-package

mgcp package-capability pre-package

no mgcp package-capability res-package

no mgcp package-capability fxr-package

no mgcp timer receive-rtcp

mgcp sdp simple

mgcp bind control source-interface GigabitEthernet0/0

mgcp bind media source-interface GigabitEthernet0/0

SIP dial-peer:

dial-peer voice 101 voip

destination-pattern 0T

signaling forward unconditional

no modem passthrough

session protocol sipv2

session target ipv4:x.y.z.a:5060

session transport udp

voice-class codec 1

voice-class sip privacy-policy passthru

voice-class sip dtmf-relay force rtp-nte

voice-class sip early-offer forced

voice-class sip profiles 1

dtmf-relay rtp-nte

fax-relay ecm disable

fax rate 14400

no vad

At UCM for MGCP-gw ModemPassthrough and T38FaxRelay enabled. CiscoFaxRelay disabled.

Is that config one of the best choice to match most of fax, modem or analogue phone requirements and in case of a fallback from sip-trunk to E1 or E1 to sip-trunk.

First basic tests working well... but we have not already finished with most of possible test cases. IOS releases are for VG224 15.1.4M1 and C2921 15.2.3T2

Thank you very much in advance for any hints.

Greetings, Chris

Ask the Expert: Configuring and Troubleshooting Faxing in Cisco IP Voice Networks