cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
363
Views
2
Helpful
10
Replies

Inband DTMF tones not working on CUC

mdrangell22
Level 1
Level 1

Hello 

I have an EOL CUCM and CUC v10.5 and Gatewy 3925 with IOS 15.4(3)M1 where they are using

Provider -- E1 -- GW --  H323 -- CUCM -- SCCP -- CUC and the DTMF to AA are working fine

but now they will have to migrate to sip using the following call flow

Provider -- SIP - GW -- SIP -- CUCM -- SCCP -- CUC and the dtmf are not working for AA ..... if they call is to a SCCP or SIP phone the dtmf work fine so my opinion is that there is an issue with the CUC. 

I have read other cisco forum pots with the same issue and I have applied that workaround but didn't work.

My dial-peer are configured with dtmf-relay rtp-nte I have tried with MTP enabled check box with MTP software and hardware and algo with transcode in MRGL but not work.... Also I changed to SIP between CUCM - CUC and its not working.

Do you guys know what else can i do? There is maybe a bug? this version are so old....

Something that called my attention is that in the INVITE SDP they send to GW i don't see payload 101. it doesnt have that field... I was going to ask to provider but also call my attention that in sccp or sip phones the dtmf work even the the INVITE SDP is also doesn't appear

 

 

 

10 Replies 10

Brad Magnani
Cisco Employee
Cisco Employee

You'll want to gather CallManager traces to observe the signaling/media, CUC traces and packet capture from CUC as well to confirm you are receiving digits as you would expect.  For CUC traces, enable "Call Flow", "Call Control" and "Conversation Traces" Macro traces. 

For packet capture on CUC: utils network capture file DTMFCap count 100000 size al

Reproduce problematic calls, gather CallManager traces from CUCM.  Connection Conversation Manager traces and Packet Capture Logs from CUC.  This should start you on the right track.

First, you need to understand from your ITSP what DTMF is supported with the SIP service they provide. Normally, the ITSP provides those details when they provide their sip server details. . Based on that information, you need to configure the gateway or devices for the DTMF to work.

Enabling the MTP check is not a solution for such issues.

I'm a bit confused regarding this: "if the call is to an SCCP or SIP phone, the DTMF works fine, so my opinion..." How do you test DTMF by calling to a SCCP and SIP phones?

If you have set the DTMF relay configured on the dial-peers, another thing to ensure is that the calls are hitting the right dial-peer for the DTMF to work.

 



Response Signature


Hello

If I call from to my cellphone to a SCCP or SIP phone and I push any button in my cellphone I received a "sound" in my SCCP or SIP phone so that is to I tested it

My ITSP told me they are using inband dtmf, now I activated debug voip rtp session named-event and I push one in my cellphone I don't see any packet in the debug but I can hear the tone in my IP Phone ... Now if I push any button in my ip phone I can see packet debug but I don't hear any tone in my cellphone.... I don't get it.

With debug ccsip all I can see that  Gateway -- CUCM leg is negotiated rtp-nte payload 101 but Gateway - ITSP leg is negotiated inband payload 0... the payload can be 0? Also in the Invite SIP packet DSP information I don't see any payload ... It's this normal or maybe its an ITSP issue?

Gateway - Phone leg 

Stream type : voice+dtmf
Media line : 1
State : STREAM_ADDING (2)
Stream address type : 1
Callid : 571
Negotiated Codec : g711alaw, bytes :160
Nego. Codec payload : 8 (tx), 8 (rx)
Negotiated DTMF relay : rtp-nte
Negotiated NTE payload : 101 (tx), 101 (rx)
Negotiated CN payload : 0
Media Srce Addr/Port : [X.X.X.X]:16492
Media Dest Addr/Port : [x.x.x.x]:24592

Gateway -- ITSTP Leg

Stream type : voice-only
Media line : 1
State : STREAM_ADDING (2)
Stream address type : 1
Callid : 570
Peer Callid : 571
RTP/SRTP Negotiated : 8
Negotiated Codec : g711alaw, bytes :160
Nego. Codec payload : 8 (tx), 8 (rx)
Negotiated DTMF relay : inband-voice
Negotiated NTE payload : 0 (tx), 0 (rx)
Negotiated CN payload : 0
Media Srce Addr/Port : [X.X.X.X]:16490
Media Dest Addr/Port : [X.X.X.X]:37848

The answer to why it isn't working is in your output there. Please post your dial peer configuration. That said, I find that really unusual. I don't think I have ever worked with an ITSP that didn't use RTP-NTE (aka RFC2833). Can you get them to change their configuration to use RTP-NTE? I doubt inband will ever work with things like CUC or CCX that require out of band DTMF.


Gateway - Phone leg 

Negotiated DTMF relay : rtp-nte
Negotiated NTE payload : 101 (tx), 101 (rx)


Gateway -- ITSTP Leg

Negotiated DTMF relay : inband-voice
Negotiated NTE payload : 0 (tx), 0 (rx)

Hello

I don't get it very well, rfc2833 is rtp-nte and this one is not a inband dtmf method? in the gateway itsp leg as they are using inband dtmf method it is normal that say inband-voice and nte payload 0?

This is dial-peer GATEWAY - ITSTP

dial-peer voice 7000007 voip
description Llamadas SIP Entrantes ITSTP-CUBE Troncal SIP
preference 1
session protocol sipv2
incoming called-number 021299999..
voice-class sip early-offer forced
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711alaw
no vad

This is dial-peer GATEWAY - CUCM

dial-peer voice 7000008 voip
description Llamadas SIP Salientes CUBE-CUCM Troncal SIP
translation-profile outgoing In_Troncal_SIP_Cantv
preference 1
destination-pattern 021299999..
session protocol sipv2
session target ipv4:1.1.1.1:5060
voice-class sip early-offer forced
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
codec g711alaw
no vad

CUBE can do conversion between DTMF relay methods, but it can't do that if the configured DTMF relay method on the dial peer doesn't match what the ITSP is sending. I still think you should push the ITSP to do RTP-NTE since that doesn't appear to be what they are configured to use.

I missed click accepted as solution..... 

So in that field negotiated DTMF should appear something different that inband-voice?

 

Instead of using incoming called-number as the match on your inbound dial peer from the SP it would be advised to use information in the VIA header to make that match the inbound dial peer. Something along with this should work.

 

voice class uri PSTN sip
 host ipv4:<IP of the SP SIP server(s)/peer(s)> ! add more line as needed
!
dial-peer voice 7000007 voip
 no preference 1 !not applicable to inbound dial-peer, this is used for outbound dial-peers
 no incoming called-number 021299999..
 incoming uri via PSTN

 

This is btw the recommended option to use for dial peer matching for any calls, including coming from CM.



Response Signature


Hello

Thanks for your recommendation. I resolved the main issue but now I have another one. 

I resolved the issue using a Transcode associated to CUBE and not to SCCP... Doing this the DTMF works fine from cellphone to ip phone and from ip phone to cellphone and the most important the DTMF start working to AA CUC. I don't know if this is needed because the IOS is too old or maybe because the ITSP is using inband dtmf but I had never configured a resource as CUBE.

dspfarm profile 6 transcode
codec g711alaw
maximum sessions 10
associate application CUBE

But now when I push the button to any transfer is completed succesfully but after 5 or 10 sec the call is drop an not audio is heard... I had to activated the mtp check box in Trunk CUCM - Gateway and then the he audio is good and the call isn't drop. The resource beeing used after mtp check box checked is a sccp transcode and with show sccp connection I can see that the leg Gateway - ITSTP is g711alw and leg from Gateway - IP Phone is g711ulaw?????

After AA-CUC transfer the call to ip phone this one have to be g11ulaw?? this is not defined by region? when I do a call from my cellphone to ip phone this use g711alaw both sides.

Suggest that you use a codec list on your dial peers instead of specifying a single codec.



Response Signature