first DTMF digit being missing on UCCX IVR sub-menus only

[woody1848]

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 config:

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                                                       

[woody1848]

This issue has been resolved.

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:

v=0
o=Sonus_UAC 27304 25513 IN IP4 X.X.X.X
s=SIP Media Capabilities
c=IN IP4 X.X.X.X
t=0 0
m=audio 14714 RTP/AVP 0 100
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv
a=maxptime:20

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.