03-10-2014 11:35 AM - edited 03-16-2019 10:04 PM
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?
03-10-2014 03:11 PM
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?
03-10-2014 03:16 PM
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.
03-10-2014 08:07 PM
03-11-2014 12:12 AM
03-11-2014 04:02 AM
Hi Tom,
Please enable the MTP point required in CUCM sip Trunk configuration and check.
Regards.
03-11-2014 04:13 AM
Please send us a full sh run of the gateways that are not working
03-10-2014 08:42 PM
03-11-2014 07:08 AM
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.
03-14-2014 07:06 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide