Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

CUBE DTMF Interworking Problem

Hi All,

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-kpml on 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.

Scenario

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.

Hypothesis

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

 

Alternative Hypothesis

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 9.1.1.10000-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.

Regards,

Michael

1 ACCEPTED SOLUTION

Accepted Solutions

Hi,Can you give a try by

Hi,

Can you give a try by dropping RTP-NTE from cube. Below is the command you can use in dial-peer pointing towards CUCM.

voice-gateway(config-dial-peer)#dtmf-relay rtp-nte ?

digit-drop     Digits to be passed out-of-band and in-band digits dropped

If this does not work out then please send below outputs

  • debug voip ccapi inout
  • debug ccsip all
  • debug voip rtp sess name

 Also send the running configuration of your gateway/cube.

 

Regards,

Nishant Savalia

Regards, Nishant Savalia
4 REPLIES

Hi,Can you give a try by

Hi,

Can you give a try by dropping RTP-NTE from cube. Below is the command you can use in dial-peer pointing towards CUCM.

voice-gateway(config-dial-peer)#dtmf-relay rtp-nte ?

digit-drop     Digits to be passed out-of-band and in-band digits dropped

If this does not work out then please send below outputs

  • debug voip ccapi inout
  • debug ccsip all
  • debug voip rtp sess name

 Also send the running configuration of your gateway/cube.

 

Regards,

Nishant Savalia

Regards, Nishant Savalia
New Member

Firstly, many thanks for the

Firstly, many thanks for the responses!

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.

http://www.cisco.com/c/en/us/td/docs/ios/voice/cube/configuration/guide/15_0/vb_15_0_Book/vb-gw-h323sip.html#wp1313530

Again, thanks for your response.

Regards,

Mike

VIP Super Bronze

 Here are my thoughts on this

 

Here are my thoughts on this...

 

1. What is the configuration of the DTMF method on the sip trunk?

2. If you have rtp-nte on one leg and sip-kpml on the other leg, do you have a MTP resource registered locally to the CUBE (not to CUCM) for the DTMF conversion?

3. What is the integration method with unity connection (sip or sccp)?

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Thanks for the response!The

Thanks for the response!

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.

Again, thanks for your answer.

Regards,

Mike

2479
Views
9
Helpful
4
Replies