Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

DTMF not working on new install CUCM9

Hi,

We installed a new CUCM9.1 cluster with 3 locations, each location having its own voice gateway. connection between CUCM and voice gateway is SIP each time.

 

For 1 location, DTMF is working. The other 2 it isn't. The configuration is exactly the same, and I cannot figure out why it isn't working.

This is the dial-peer to the CUCM for a non working site:

dial-peer voice 2000 voip
 description Incoming calls to UC-CUCM-BREDA
 preference 1
 session protocol sipv2
 session target ipv4:172.25.63.122
 destination e164-pattern-map 1
 voice-class codec 100  
 voice-class sip options-keepalive
 dtmf-relay rtp-nte
!

In the SIP trunk configuration on CUCM, RFC 2833 is chosen as DTMF Signaling method.

 

However, this is exactly the same on the other sites.

 

Anybody have any idea what the issue might be?

Everyone's tags (1)
9 REPLIES
VIP Super Bronze

What is your call flow? What

What is your call flow? What end points are involved in this? Does this affect only external calls? How are the gateways in the affected location connected to PSTN?

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Call Flow: IP Phone >> SCCP >

Call Flow: IP Phone >> SCCP >> CUCM >> SIP >> Gateway >> ISDN PRI >> PSTN

This is the same in all three locations. It is only for external calls. Depending on what CSS I give a certain IP Phone, and thus which gateway it takes to call out, DTMF is working or not, with everything else staying the same.

Can you post your voice

Can you post your voice service voip configuration? Regards.
New Member

!

! voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw modem passthrough nse codec g711alaw sip !

Hi Tom, Please enable the MTP

Hi Tom,

 

Please enable the MTP point required in CUCM sip Trunk configuration and check.

 

Regards.

VIP Super Bronze

Please send us a full sh run

Please send us a full sh run of the gateways that are not working
 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Hi Tomribbens,

Hi Tomribbens, Could you please enable the MTP in the SIP trunk and check if the MTP is working. If both party are on SCCP cisco phones then its support both in band and out of band. However if you facing issue with the PSTN world, then please check the MTP in SIP trunk and DTMF method as RFC 2833 OR OOB & RFC 2833. this is because one side support inband and other side support only out of band so we need MTP to terminate the RTP session there and from MTP a new RTP session would be established to the destination. Please let me know if this work.

Try running "debug voip rtp

Try running "debug voip rtp session named-event" and see if the gateway is receiving the digits from the phone in the first place.  You could also do a packet capture.  If that is working, it may be an issue with putting the digits on the PRI.  You may need a PCM capture to confirm that.

 

Another thing to try would be to force KPML on the incoming dial-peer and in CUCM and see if that has better results using out of band instead.

New Member

Sorry for the late reply, it

Sorry for the late reply, it's been a busy week, but the resolution has been found:

The difference between the two sites, was that one was using destination-pattern in the dial-peer, the other one was using destination e164-pattern-map. This matters for incoming dial-peer matching, as destination-pattern is also used for matching, but e164-pattern-map is not. So calls would match dial-peer 0, which had no dtmf-relay configured.

Resolution was as simple as creating a dial-peer for incoming matching, and configuring dtmf-relay on it.

376
Views
5
Helpful
9
Replies