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
session protocol sipv2
session target ipv4:172.25.63.122
destination e164-pattern-map 1
voice-class codec 100
voice-class sip options-keepalive
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?
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?
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.
Please send us a full sh run of the gateways that are not working
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.
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.