cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5042
Views
0
Helpful
8
Replies

DTMF issues on SIP trunk to Verizon

Were you able to resolve this problem?  I am having an identical issue also with Verizon.

8 Replies 8

Steven Holl
Cisco Employee
Cisco Employee

I branched this to a new thread, since your symptoms may not match what the previous post was seeing.

Like I mentioned in that thread, collect the following for a test call where DTMF is entered during the call:

debug voip ccapi inout

debug ccsip all

debug voip rtp sess name

You  can look at the 'ccsip all' debug and see where it says 'negotiated  dtmf relay' on each leg to ensure that rtp-nte was negotiated, and what  payload type was negotiated.

Also, ensure that you have  'dtmf-interworking rtp-nte' configured under 'voice service voip since  there are timing issues with thier SBC regarding the RTP-NTE packets.

Our topology and symptoms are as follows:

Outside phone -> PSTN -> Vzn SBC -> Vzn SIP trunk -> CUBE -> CUCM / VM system

DTMF tones generated by an IP phone are heard and recognized by an outside (off-net) phone/system as you would expect.  However, DTMF tones generated by an outside (off-net) phone are not recognized by our voice mail system. When listening to the DTMF tone on an IP phone, it sounds very distorted and faint.  A sniffer trace performed on the CUBE shows RFC 2833 NTEs being received from Verizon, and they appear to be properly relayed by the CUBE to the destination.  Payload type negotiated for both legs is 101.

We are running CUCM 6.1.5.  We have a CUBE router between CUCM and the Verizon SIP trunk.  The CUBE router is running 12.4(24)T3 with the IPIPGW feature set.  Our voice mail system is an AVST CallXpress system running v7.9 software.  To CUCM the AVST voice mail ports appear as DNs assigned to several SCCP 7940 phones (DNs are part of a hunt group, hunt pilot = vm pilot).  The AVST masquerades and registers as the 7940 phones.

I tried applying the "dtmf-interworking rtp-nte" both globally and at the dial-peer level with no success.  Attached is the debug output you suggested.

What device is 172.16.0.6?  I see us send RTP-NTE to this IP in the debugs.

Since you have CUBE---sip---CM----sccp---VM you need an MTP to pull the rtp-nte DTMF out of the media stream and put it in the signaling path.  Make sure the SIP trunk and the SCCP ports for VM both have MRGLs with an MTP.  IF the calls are g.711, you can use the CM MTP for this.  If the calls are g.729, you will need to configure an IOS SW MTP.  Make sure to reset both devices from CM after making this change.

If you still see issues after this, get CM traces along with 'debug voip rtp sess name' from the gateway and (if you can) a packet capture off the MTP.

172.16.0.6 is gateway with transcoding resources.  Our voice mail system supports only G.711 and since our calls come in on the SIP trunk G.729, they require transcoding.

I configured an IOS software MTP, one for each possible codec although I believe I should just need the one g729 codec configured for our SIP trunk.  I added these MTPs to UCM and put them all in their own MRG.  I added that group to the top of the MRGL used by the SIP trunk.  I haven't been able to make any changes to our VM phones yet since it is in production.  I have, however, been using another IP phone on my desk to test DTMF and I set the MRGL in my phone to be the same as that used by the SIP trunk.  I reset the SIP trunk and my phone.  I placed a test call to my phone but the DTMF digits still sound the same (distorted and faint).

It appears as though UCM is not invoking an MTP as the trace on the CUBE shows the RTP session going direct from the CUBE to my IP phone.  Attached is the debug output from the CUBE, a packet capture from the CUBE (MTP packet capture was empty), and a CM trace.  IPs are as follows:

10.202.0.26 - CUBE

10.201.4.49 - Vzn SBC

10.201.4.164 - Vzn SBC

10.100.16.150 - Subscriber

10.203.232.216 - IP Phone

I also tried selecting the "MTP Required" checkbox in the trunk configuration.  The MTP was inserted into the path this time and it generated SCCP NotifyDtmfToneMessage packets destined for UCM.  UCM did not, however, send these to my phone.

I configured an IOS software MTP, one for each possible codec 

You don't want to do this.  When CM needs an MTP, it picks the first available MTP/Xcoder it will find in the MRGL.  It is not smart enough to know that if it needs a g729 MTP to pick a g729 MTP resource over a g711 resource.  Hence, you should only have one codec-type MTP in the MRGL, for the codec that you intend to use across the trunk.

Don't test DTMF to an IP phone if you are using RTP-NTE, because most IP phones won't play received DTMF towards the earpiece.  RTP-NTE debugs or packet captures are the best way to troubleshoot RTP-NTE.

The MTP was inserted into the path this time and it generated SCCP 
NotifyDtmfToneMessage packets destined for UCM.  UCM did not, however, 
send these to my phone.

How are you verifying this?  Are you verifying with a CM traces or a packet capture off the back of the phone?  Those are the ways to test.

You don't want to do this.  When CM needs an MTP, it picks the first available MTP/Xcoder it will find in the MRGL.  It is not smart enough to know that if it needs a g729 MTP to pick a g729 MTP resource over a g711 resource.  Hence, you should only have one codec-type MTP in the MRGL, for the codec that you intend to use across the trunk.


Thanks...I was not aware of this.  I think we may be homing in on the problem.  This appears to be a compatibility issue with our voice mail solution.  Each "port" on the voice mail system appears to UCM as a 7940 phone.  When the voice mail system registers one of these "ports" with UCM, it registers with the codecs it supports and it is also indicating that it supports RFC 2833 NTEs (see attached packet capture).  I am guessing this is why UCM did not automatically invoke an MTP for DTMF digit translation and perhaps why it is not forwarding the digits as SCCP messages when I force an MTP to be invoked with the "MTP required" checkbox.

Even though our CallXpress system registers with UCM with support for NTEs, in practice it doesn't seem to support them.  The NTEs do get relayed properly to our voice mail system but it doesn't react to them.

How are you verifying this?  Are you verifying with a CM traces or a packet capture off the back of the phone?  Those are the ways to test.

Packet captures on the CUBE, MTP, and voice mail system.

We have a fix.  We selected the "Disable RFC 2833" and "Require DTMF reception" checkboxes for each AVST CallXpress port configured in UCM as a SCCP 7940 phone.

Hi Andrew,

 

You solution fix my issue with CallXpress. Good post!

Thanks!!

Michael

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: