DTMF not working with UCCX

[W S H FERNANDO]

Hi

We have noticed that DTMF is not working with UCCX,

Call flow ->

PSTN (SIP)-> CUBE - (SIP)-> CUCM - > UCCX

UCCX DTMF is working with IP Phones which are registered with CUCM, But not working with PSTN incoming calls, also we have Unity Connection, for this DTMF is working with PSTN incoming calls,

Please help to troubleshoot this issue,

Rgds

$

[Manish Gogna]

Hi,

A couple of things that can be checked are:

Is the Media Termination point checked on the SIP trunk?

DTMF method is set to "no preference" or "OOB and RFC 2833".  Try changing to "oob and rfc 2833"

Check the incoming and outgoing dial-peers on CUBE to see what dtmf method is configured there.

HTH

Manish

[Jonathan Schulenberg · Accepted solution]

What this boils down to is that the CTI Ports do not support RFC2833, only out of band over the CTI QBE protocol. This means that CUCM must "see" the DTMF packets. If CUBE offers KPML in the call SDP, CUCM will automatically request this and translate from the SIP packet into a CTI event. If CUBE is only offering RFC2833, CUCM would need to invoke an MTP on the call to intercept the RTP packets containing the DTMF event.

If this isn't working the most likely reason is that there is no MTP for CUCM to invoke, or the MTP doesn't support RFC2833 DTMF interop. The best way out of this problem is to adjust the CUCM-facing VOIP dial-peer to include both capabilities: 'dtmf-relay rtp-nte sip-kpml' CUBE, assuming it's doing media flow-through, will do the heavy lifting for CUCM. If you set the DTMF Method on the CUCM-side SIP trunk, CUCM will essentially invoke an MTP for *every* call, in most cases needlessly; that's a great way to introduce problems and break things such as faxing.

Please remember to rate helpful responses and identify helpful or correct answers.

[chrisnoon11]

Thanks for this.  Great info.

I do have a question though... I had this issue, and my dial-peers were offering "dtmf-relay rtp-nte sip-notify sip-kpml", yet the DTMF was not being recognized by UCCX.  Setting it to only "dtmf-relay sip-kpml" resolved the issue.  Why would CUCM be choosing in-band dtmf when kpml was offered?

[Alan Libbee]

Johnathan,

Thank you for this post and solution. I have changed the CUCM facing dial peers in the CUBE to include both SIP-KPML and RTP-NTE and it did completely eliminate the MTPs from being invoked on every UCCX call. The SIP provider only supports RTP-NTE, the cube successfully regenerates the RTP-NTE data as SIP-KPML events in most cases, however, sometimes a digit is missed. We are noticing this especially if a call is transferred. If a dtmf retransmission does not get made, pressing another digit does make everything start working again. Cisco TAC pointed out to me that RTP-NTE to SIP-KPML is not officially supported on the cube, check out the link below.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html

This is what a working SIP-KPML event looks like from my debug (debug ccsip all):

<?xml version="1.0" encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="6" tag="dtmf"/>

Here is the non working event:

<?xml version="1.0" encoding="UTF-8" ?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-response kpml-response.xsd" code="487" digits="" forced_flush="false" suppressed="false" tag="dtmf" text="Subscription Expired" version="1.0"/>

I am running IOS: c3900-universalk9-mz.SPA.154-3.M3.bin

I am mainly posting this to help out the next person that may be reading this article, but if anyone has any ideas or experience with these responses, please reply back. TAC has told me that there is a glitch at this point in the call where the CCAPI layer is not communicating properly with the SIP layer, the BU is looking in to this request for me and if they send a solution, I will test it and post here.

[Jonathan Schulenberg · Accepted solution]

I had discussion about this with the TME and PM that cover CUBE over the weekend. They have confirmed with the development team that RFC2833 to KPML is supported. The internal conversation isn't finished yet. For example, it's not yet clear whether KPML to RFC2833 (i.e. the inverse of what you're doing) is expected to work as well under current code or if that needs to be added to their backlog.

Since you are doing RFC2833 to KPML, you are supported and should push back on TAC. The BU will be updating the documentation once they sort out the remaining details. In the mean time, the TAC engineer should be able to reach out to the product team internally if they need confirmation before continuing to troubleshoot.

[W S H FERNANDO]

Hi

This issue was resolved after using same dtmf method for incomming and outgoing dial-peers, thatk you every one for the support

Regds

$

[Jonathan Schulenberg]

Glad it helped. Please mark one the reply as the correct answer to help the search index (and my ego). haha

[Dennis Heim]

I am actually running into this exact same problem, but with a CSR1000v. Call leg to CUCM is set to sip-kpml only, but is still selecting rtp-nte as the dtmf-relay. Is there something else I need to do beyond just setting the dtmf-relay parameter on the dial-peer pointing to CUCM.

SIP Trunk is set in CUCM to no preference.

dial-peer voice 999 voip
description ** Catch-All Inbound **
session protocol sipv2
incoming called-number .
dtmf-relay rtp-nte
codec g711ulaw
no vad
dial-peer voice 1000 voip
description **Call Center Inbound DID 314.800.1000**
destination-pattern +13148001000
session protocol sipv2
session target ipv4:192.168.10.20
dtmf-relay sip-kpml
codec g711ulaw
no vad
dial-peer voice 1010 voip
description ** Outbound **
destination-pattern +1[2-9]..[2-9]......
session protocol sipv2
session target ipv4:1.1.2.254
dtmf-relay rtp-nte
codec g711ulaw
no vad

SIP UAS CALL INFO
Call 1
SIP Call ID : 32912746-C15A11E6-89F7EFDD-23224CC2@1.1.2.254
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Calling Number : +13175551212
Called Number : +13148992339
Called URI : sip:+13148992339@1.1.2.19:5060
Bit Flags : 0x8C4401C 0x10000100 0x4
CC Call ID : 10156
Local UUID : e622a82ab4e85e1ca3bd54f256e6f90a
Remote UUID : b143f18eba4659c780a1a43913af52ed
Source IP Address (Sig ): 1.1.2.19
Destn SIP Req Addr:Port : [1.1.2.254]:5060
Destn SIP Resp Addr:Port: [1.1.2.254]:53975
Destination Name : 1.1.2.254
Number of Media Streams : 1
Number of Active Streams: 1
RTP Fork Object : 0x0
Media Mode : flow-through
Media Stream 1
State of the stream : STREAM_ACTIVE
Stream Call ID : 10156
Stream Type : voice+dtmf (0)
Stream Media Addr Type : 1
Negotiated Codec : g711ulaw (160 bytes)
Codec Payload Type : 0
Negotiated Dtmf-relay : rtp-nte
Dtmf-relay Payload Type : 101
QoS ID : -1
Local QoS Strength : BestEffort
Negotiated QoS Strength : BestEffort
Negotiated QoS Direction : None
Local QoS Status : None
Media Source IP Addr:Port: [1.1.2.19]:10438
Media Dest IP Addr:Port : [1.1.2.254]:9524
Mid-Call Re-Assocation Count: 0
SRTP-RTP Re-Assocation DSP Query Count: 0

Options-Ping ENABLED:NO ACTIVE:NO
Number of SIP User Agent Server(UAS) calls: 1

[Jonathan Schulenberg]

Those dial-peers do not look quite right. Are those all of the dial-peers configured? Which PIDs are actually used if you do a "show call active voice brief" during a call?

[Dennis Heim]

It is showing dial-peer 999 and 1000. I have it now where "show sip-ua calls" is showing sip-kpml. However, DTMF isn't making making it to UCCx.