DTMF Issues

[Quintin.Mayo]

Hi,

We are troubleshooting some  DTMF relay issues. The provider does RFC2833 (inband). The dial-peers on the VG facing CUCM and the provider are set to use rtp-nte and the SIP trunk in CUCM is set to use RFC2833. The Cisco traces and CUBE debugs all show negotiation of rtp-nte and inband but sometimes it works and DTMF digits are recognized by the remote party and sometimes they are not. Since RFC2833 is inband and I don’t see any discrepancies in the logs and traces, why is it not always working? Any assistance would be greatly appreciated.

The call flow is the following – IP phone --> CUCM SIP trunk --> CUBE --> ASA --> SIP provider

We have disabled SIP inspection on the firewall and  modified the SIP headers on the CUBE to present the NAT address of the CUBE to the provider and the private IP of the CUBE to CUCM. The attached are excerpts from the CUCM traces and CUBE debugs that I have extracted and highlighted the pertinent information for you that show the proper DTMF negotiation between all points. In this particular case, the DTMF was finally recognized after placing a number of calls when it wasn’t and the debugs before this call all showed the same results. The only difference with this call was that the caller didn’t have it on speaker phone. When it was on speaker though the DTMF digits were not recognized. The outputs are the same for all calls made but sometimes it works and sometimes it doesn’t.

[R0g22]

So i checked the word doc that has the snippets. Towards the bottom, I see negotiated DTMF as "inband-voice" while the preferred is "rtp-nte". Just to re-iterate, RFC 2833/rtp-nte is NOT in-band mechanism. It is referred in a lot of places as in-band, but it is not purely because the DTMF is carried in NTE packets and not in RTP packets. The PT for rtp-nte will always be different than the PT for the audio codec being used for the RTP packets.
You can think of rtp-nte as a hybrid, wherein the DTMF is using the same media path or is carried along the media/rtp and not in the actual media/rtp.

Now, the part where it does not work I believe the CUBE is set for rtp-nte/rfc2833 which is hybrid/OOB while the DTMF being negotiated is pure in-band. CUBE can interwork b/w them but under some conditions. Read below -

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/200412-DTMF-Relay-and-Interworking-on-CUBE.html#anc36

Add "dtmf-relay rtp-nte sip-kpml" on CUBE voip dial-peers. On CUCM SIP Trunk, have the DTMF set to "No preference".
Also, have you confirmed with your ITSP ? Are they supporting RFC2833 or are they doing RFC4733 ?

[Mohammed al Baqari]

Hi,

Inband-voice rtp is different than rtp-nte. For example, G729 codec has a
payload type of 18. This number is referenced in RTP header and the
receiving endpoint uses the payload type to identity the codec type and
decode. When dtmf method is inband-voice, dtmf digits will be sent using
payload type 18 which is same as actual audio stream (G729). The receiving
endpoint won't recognize this as dtmf and will think that this is part of
audio stream. RTP-NTE uses payload type ranged from 96-127. This is
negotiated during call setup. While g729 is sent in payload type 18, dtmf
digits are sent as payload type 97 (for example) and the receiving endpoint
will be able to differentiate accordingly.

Now you need to troubleshoot why inband-voice is negotiated instead of
RTP-NTE and make dtmf failing. Most of time this is due to dtmf-relay
mismatch. When mismatch happens CUBE will use inband-voice and setup the
call rather than dropping it.