first DTMF digit being missing on UCCX IVR sub-menus only
So we are having an issue where when a Sprint customer calls in to our UCCX AA they have 2 options (ENG or SP) those options work fine, no problems. But once the customer is in a sub menu the first DTMF digit does not register and only registers on the 2nd press of the DTMF digit. It only happens when using a Sprint cell phone and only happens with our sub menus but not the main AA.
I understand that this is possible a Sprint issue and that they will have to look on their end. I have called them and have spent 2+ hours on the phone trying to get to lvl 2 tech support or some type of engineer without success. I have also put in a ticket with them and they have not contacted me since. So I am trying to see if there is anything that I can do on my end to remedy this issue.
I have attached a Debug and have pasted our dial-peer below
Cisco IOS XE Software, Version 16.02.01, router 4431
dial-peer voice 200 voip description ** UCM02 SIP PEER ** session protocol sipv2 session target ipv4:10.2.21.11 destination e164-pattern-map 200 incoming called-number 9 voice-class codec 1 voice-class sip asymmetric payload full voice-class sip early-offer forced voice-class sip bind control source-interface Port-channel1 voice-class sip bind media source-interface Port-channel1 dtmf-relay rtp-nte sip-kpml fax-relay ecm disable fax rate 14400 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none ip qos dscp cs3 signaling no vad
The solution was to enter the command 'voice-class sip dtmf-relay force rtp-nte' under dial-peer voice 200 voip which is our dial-peer for CUCM. That is a hidden command and will not show up as an option in the IOS. But it will work if entered as is under a dial-peer. This Command ensures that the CUBE will always uses RFC2833 for DTMF even if it was not offered by the provider in the initial invite. The SIP provider has to support RFC2833, and lucky for us most providers will support RFC2833 as its pretty common.
My best guess from going through multiple debugs is that Sprint sends their DTMF only with payload type 100 (NSE) and not 101 (NTE). Here is an example:
So when a caller connects with our IVR it is not negotiating the correct payload, which should be 101, which defines DTMF, instead of 100, and the first DTMF digit fails. I'm just not sure why after pressing the digit the second time UCCX recognizes the DTMF.
With the new command 'voice-class sip dtmf-relay force rtp-nte' it forces the negotiation to be RTP-NTE which then defines DTMF.
Configuring Cloud Connected PSTN (CCP) – Easy as 1-2-3!
STEP 1: PREPARE
Before you can configure your CCP in Control Hub, you must procure PSTN services from an authorized Webex Calling CCP Partn...
To participate in this event, please use the button to ask your questions
This topic is a chance to discuss more about how to read Cisco Unified Communications trace files. In this session, Cisco D...