cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2131
Views
18
Helpful
12
Replies
Highlighted

DTMF not traversing our environment

I am starting to think that what I am trying to do will not work but would love someone to contradict me :-)

I have 794x SCCP phones connecting using CUCM 8.5.1 to Cisco 2921 routers running IOS 15.0-1.  The calls are then routed using SIP to a Net UX2000 gateway and from there via SIP to our external provider. I have MS Lync phones connecting directly to the UX gateway.

Call from the Cisco phones to the PSTN work fine as do calls from the Lync phones. BUT, DTMF doesn't work from the Cisco phone to the PSTN.

Tracing the SIP setup between gatways shows that the DTMF preferred relay has been negotiated as rtp-rte but I see no debug messages when the keys on the phone are pressed and nothing gets to the far end.  I am starting to wonder whether SCCP->SIP is a no go for DTMF.

Glen.

Everyone's tags (3)
1 ACCEPTED SOLUTION

Accepted Solutions

Re: DTMF not traversing our environment

Not quite. SCCP phones will always send the StationInit KeypadButtonMessageID event when a button is pressed. If SIP KPML has been negotiated between CUCM and the gateway, CUCM will generate a NOTIFY with a KPML payload and send it; the phone doesn't do this.

If CUCM negotiated rtp-nte, it will instruct the phone to also send RFC2833 RTP packets in the media stream (different payload type). CUCM cannot generate these on behalf of the phone unless it invokes an MTP to proxy the RTP streams.

Also, the 7940/7960 DO support RFC2833 in their most recent firmware. The SRND documents this on the Endpoints page, Table 18-12. There is a checkbox on the phone that you can disable RFC2833 support and this should be unchecked.

So, "should this work [with a 7960]"? Yes.

Is 'dtmf-relay rtp-nte sip-kpml' (order denotes preference) a good command? Yes. It's my default config to cover applications such as CCX or phones such as the 7936 which truely don't support RFC2833.

Why doesn't it work? Good question. The first thing that comes to mind is whether the payload types differ between your UX gateway and CUCM/the phone. If memory serves (I would have to packet capture this), I believe Cisco sets it to a type of 100. Second, is if an MTP is getting invoked (e.g. you're forcing Early Offer) on the call? If it is and you're using IPVMSA instead of IOS this won't work.

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

12 REPLIES 12
Beginner

DTMF not traversing our environment

Do you have the dtmf rtp-nte specified on your outbound sip dial-peer?

DTMF not traversing our environment

Yes, I have

dial-peer voice 99901 voip

description PSTN Calls via TUR-LYNCMGW3

preference 1

destination-pattern +T

modem passthrough nse codec g711alaw redundancy

session protocol sipv2

session target ipv4:10.123.130.10

session transport tcp

voice-class codec 10

dtmf-relay rtp-nte sip-notify

fax rate 9600

fax nsf 000000

fax protocol pass-through g711alaw

ip qos dscp cs3 signaling

no vad

!

Have tried both with and without the sip-notify, didn't make any difference either way.

Rising star

DTMF not traversing our environment

DTMF from Lync to PSTN is working fine?

what is the connection between CUCM 8.5 and 2921 gateway? I presume it is also SIP. if so, is it SIP to SIP CUBE?

could you please configure only rtp-nte dtmf (not sip notify) in the dial-peers?

what is DTMF method between Lync GW and PSTN? Try to configure only RTP-NTE (RFC2833) in all SIP connection in the call flow and check.

//Suresh Please rate all the useful posts.
Beginner

Re: DTMF not traversing our environment

Yep, Lync to PSTN works fine.

The CUCM to 2921 is SIP.  I am not entirely sure what SIP CUBE is :-(

Phone to 2921 to PSTN via PRA (alternate path on the same router) - DTMF works fine.

I have tried without sip_notify and it doesn't make any difference.

Lync GW to PSTN is rfc2833.

I suppose a basic question is "Should this work ?"  I have rfc2833/rtp-nte everywhere as far as I can see and running debug on the router showed successful negotiation between the 2921 and the UX2000 for rtp-nte/rfc2833.

VIP Mentor

DTMF not traversing our environment

I bet your Lync phones are sip based hence they can do rtp-nte. Most SCCP phones except the latest ones cant do rfc2833 (rtp-nte) they only support OOB DTMF. KPML is the preferred DTMF method for cisco. So I suggest you use KPML

On the inbound dial-peer from CUCM configure ( the config you sent doesnt show you have one..ensure you do)

dtmf-relay sip-kpml rtp-nte

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts
Beginner

Re: DTMF not traversing our environment

Yes, all the Lync phones are SIP based, mostly Polycoms.  The Cisco phones are old 7940s mainly. This was the info I was after, thanks.  Now I have something I can work with

Beginner

Re: DTMF not traversing our environment

I'm still little confused. The 7940s are std SCCP loads and they talk SCCP to CUCM, CUCM talks SIP to the gateways. So is the sip-kpml intended for CUCM or the phone

Re: DTMF not traversing our environment

Not quite. SCCP phones will always send the StationInit KeypadButtonMessageID event when a button is pressed. If SIP KPML has been negotiated between CUCM and the gateway, CUCM will generate a NOTIFY with a KPML payload and send it; the phone doesn't do this.

If CUCM negotiated rtp-nte, it will instruct the phone to also send RFC2833 RTP packets in the media stream (different payload type). CUCM cannot generate these on behalf of the phone unless it invokes an MTP to proxy the RTP streams.

Also, the 7940/7960 DO support RFC2833 in their most recent firmware. The SRND documents this on the Endpoints page, Table 18-12. There is a checkbox on the phone that you can disable RFC2833 support and this should be unchecked.

So, "should this work [with a 7960]"? Yes.

Is 'dtmf-relay rtp-nte sip-kpml' (order denotes preference) a good command? Yes. It's my default config to cover applications such as CCX or phones such as the 7936 which truely don't support RFC2833.

Why doesn't it work? Good question. The first thing that comes to mind is whether the payload types differ between your UX gateway and CUCM/the phone. If memory serves (I would have to packet capture this), I believe Cisco sets it to a type of 100. Second, is if an MTP is getting invoked (e.g. you're forcing Early Offer) on the call? If it is and you're using IPVMSA instead of IOS this won't work.

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

VIP Mentor

DTMF not traversing our environment

Jonathan thanks for the post. What firmware version on the 7940/7960 support rtp-nte.

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

DTMF not traversing our environment

I have never been able to figure that out. Neither the release notes nor the bug toolkit show an enhancmenet that I can find. I even posted a question to the forums about this a while back but it never got an answer.

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

VIP Mentor

DTMF not traversing our environment

On of the reasons why I always believed they didnt support rfc2833 was that in the old CUCM8.X SRND it mentioned that it didnt. I have gone back to check that SRND and its no longer there. I had an issue in the past where very call over my sip trunk invoked an MTP for dtmf mismatch between the 7940/7960 endpoints and the negotiated rfc2833 between CUCM and my sip trunk. I added sip-kpml and that removed the need for an MTP. What is not even clear is why did this work. The doc you referenced showed that these phones do not support KPML. This is expected because they are running SCCP firmware.

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

DTMF not traversing our environment

I added sip-kpml and that removed the need for an MTP. What is not even clear is why did this work. The doc you referenced showed that these phones do not support KPML. This is expected because they are running SCCP firmware.

In that context it's talking about SIP KPML between phones and CUCM; this only applies for SIP phones. For SCCP phones KPML is done purely between CUCM and the SIP Trunk destination. They can negotiate it during SDP exchange and it'll work with any SCCP phone or CTI device ever built. CUCM converts the SCCP KeypadButtonMessageID event into a SIP NOTIFY just as it can convert from SCCP into an H.245 alphanumeric with H.323 gateways: it acts as protocol translator. Since this is happening OOB it doesn't need an MTP; it's already in the traffic path.

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

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards