Im having a problem with DTMF interworking on a new SIP PSTN gateway running on Cisco UBE with 3945E (15.3(3)M2). The PSTN carrier side is RTP-NTE, and the SIP leg into our environment is SIP-KPML. To facilitate this requirement, I am using dtmf-relay sip-kpmlon in internal inbound/outbound dial peers, and dtmf-relay rtp-nte on carrier inbound/outbound dial peers.
The Problem CUBE sends both RTP-NTE and SIP-KPML notifications into the internal environment after interworking. Unity Connection sees this as duplicate digits, and causes obvious problems as a result.
From the carrier side, I can see a clean stream of RTP with RFC2833 events for key presses. No SIP DTMF or inband DTMF can be observed. Outbound from CUBE to CUCM, I can see both RFC2833, and SIP-KPML DTMF notifications.
Although the documentation is unclear, it seems to suggest that RTP-NTE should be removed by the CUBE with interworking.
Out of the following guides for interworking, the CUBE IOS document suggests nothing about removing the RTP-NTE packets with interworking. I have implemented the asymmetic payload full command for testing, though this appears to be irrelevant for our scenario of 2 x symmetric DTMF call legs. http://www.cisco.com/c/en/us/td/docs/ios/voice/cube/configuration/guide/vb_book/vb_book/vb_10022.html
The second (obviously for IOS XE CUBE distribute model, which I am not using), suggests that the functionality for RTP-SIP interworking includes removing the RTP-NTE packets. Ive looked for similar statements in SIP RFCs, though cant find anything that confirms this as a standard. http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/guide/sbc/2_xe/sbc_2_xe_book/sbc_dtmf.html#wp1051278
Although it appears that the CUBE should be removing RTP-NTE packets, this seems like it could also be an issue with Unity Connection not locking onto one DTMF type. We notice that UCCX does not have this problem, though it too is receiving both RTP-NTE and SIP-KPML. We're using Unity Connection 18.104.22.16800-32. Ive attempted a bug search on this too, but found nothing.
Any help would be much appreciated. Im happy to provide logs and traces, where possible.
Nishal, I did see the dtmf-relay rtp-nte digit-drop which looked very much like what we were trying to acheive. The only problem with that command on the CUBE <-> CUCM leg, is that it also configures the use of RTP-NTE rather than SIP-KPML, which causes an MTP to be allocated (something were trying to avoid for obvious reasons). What I was hoping for, unsuccessfully, was something like dtmf-relay sip-kpml digit-drop, though this obviously does not exist.
I tried the same command on the CUBE <-> PSTN leg, however, and this proved successful. From the monitor captures performed on the PSTN side of the CUBE, however, I never saw any true inband DTMF, only the RTP-NTE event messages. Unless I missed something, its a curious fix for this issue.
A little bit more investigation, and it appears this command, dtmf-relay rtp-nte digit-drop is quite suited to interworking, and again, for the inbound dial peer.
The resolution is posted below, but to answer your questions:
1. The SIP trunks are configured for No Preference. This is actually an SME cluster, to be honest. As you know, you can force the use of RFC2833 (RTP-NTE) but not the use of OOB, so this is irrelevant for us.
2. The CUBE does have media-flow through and was performing DTMF interworking successfully, the problem was that it was converting RTP-NTE to SIP-KPML but not removing the RTP-NTE
3. Unity Connection is using SIP. I made an error in judgement comparing UCCX and UCXn after a long day looking at this. One is using SIP and the other SCCP. What I could see from network capture on the UCXn, however, was both the SIP-KPML notifications and the RTP-NTE packets were reaching the Unity Connection cluster.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...