[cisco-voip] DTMF Issue with one external number

Buchanan, James jbuchanan at presidio.com
Thu Oct 18 00:12:08 EDT 2012


Is there anything unique about the one number that will not work? Also, did you say you had tested that number from a cell phone?


James Buchanan | Sr. Network Engineer
Presidio | www.presidio.com<http://www.presidio.com>
12 Cadillac Drive Suite 130, Brentwood, TN 37027
D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 | jbuchanan at presidio.com<mailto:jbuchanan at presidio.com>



[Be Secure In The Knowledge]<http://www.presidio.com>


Follow us:

[Follow Presidio on Twitter]<http://www.twitter.com/presidio>

From: george.hendrix at l-3com.com [mailto:george.hendrix at l-3com.com]
Sent: Thursday, October 18, 2012 4:11 AM
To: Buchanan, James; Derek Wyss
Cc: cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] DTMF Issue with one external number

If I set my preferred nte payload to 100, an inbound call looks just like below and DTMF doesn’t work.

Preferred Codec        : g711ulaw, bytes :160
                Preferred  DTMF relay  : rtp-nte
                Preferred NTE payload  : 100
                Early Media            : No
                Delayed Media          : No
                Bridge Done            : No
                New Media              : No
                DSP DNLD Reqd          : No

                 Stream type            : voice-only
                  Media line             : 1
                  State                  : STREAM_ADDING (2)
                  Stream address type    : 1
                  Callid                 : -1
                  Negotiated Codec       : g711ulaw, bytes :160
                  Nego. Codec payload    : 0 (tx), 0 (rx)
                  Negotiated DTMF relay  : inband-voice
                  Negotiated NTE payload : 0 (tx), 0 (rx)

If I leave it as default, it uses 101 on an inbound call, shown below.  Set to default, inbound dtmf and most outbound dtmf work just fine.

Preferred Codec        : g711ulaw, bytes :160
                Preferred  DTMF relay  : rtp-nte
                Preferred NTE payload  : 101
                Early Media            : No
                Delayed Media          : No
                Bridge Done            : No
                New Media              : No
                DSP DNLD Reqd          : No

                  Stream type            : voice+dtmf
                  Media line             : 1
                  State                  : STREAM_ADDING (2)
                  Stream address type    : 1
                  Callid                 : -1
                  Negotiated Codec       : g711ulaw, bytes :160
                  Nego. Codec payload    : 0 (tx), 0 (rx)
                  Negotiated DTMF relay  : rtp-nte
                  Negotiated NTE payload : 101 (tx), 101 (rx)

-Bill



From: Buchanan, James [mailto:jbuchanan at presidio.com]<mailto:[mailto:jbuchanan at presidio.com]>
Sent: Wednesday, October 17, 2012 2:17 AM
To: Hendrix, George (Bill) @ NSS - STRATIS; Derek Wyss
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: [cisco-voip] DTMF Issue with one external number

When an inbound call comes in requiring DTMF (to voicemail or something like that), what does that look like?


James Buchanan | Sr. Network Engineer
Presidio | www.presidio.com<http://www.presidio.com>
12 Cadillac Drive Suite 130, Brentwood, TN 37027
D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 | jbuchanan at presidio.com<mailto:jbuchanan at presidio.com>


[Image removed by sender. Be Secure In The Knowledge]<http://www.presidio.com>

Follow us:

[Image removed by sender. Follow Presidio on Twitter]<http://www.twitter.com/presidio>
From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net]<mailto:[mailto:cisco-voip-bounces at puck.nether.net]> On Behalf Of george.hendrix at l-3com.com<mailto:george.hendrix at l-3com.com>
Sent: Wednesday, October 17, 2012 3:18 AM
To: Derek Wyss
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] DTMF Issue with one external number

The RTP NTE negotiated is indeed 101.  However, when I enter the commands to set it to 100, I get the following on the debug.

Preferred Codec        : g711ulaw, bytes :160
        Preferred  DTMF relay  : rtp-nte
        Preferred NTE payload  : 100
        Early Media            : No
        Delayed Media          : Yes
        Bridge Done            : No
        New Media              : No
        DSP DNLD Reqd          : No

Stream type            : voice-only
          Media line             : 1
          State                  : STREAM_ADDING (2)
          Stream address type    : 1
          Callid                 : -1
          Negotiated Codec       : g711ulaw, bytes :160
          Nego. Codec payload    : 0 (tx), 0 (rx)
          Negotiated DTMF relay  : inband-voice
          Negotiated NTE payload : 0 (tx), 0 (rx)
          Negotiated CN payload  : 0


Bill Hendrix  |  Network/VOIP Engineer
L3 STRATIS  POWERED BY EXCELLENCE

From: Derek Wyss [mailto:wyss34 at gmail.com]<mailto:[mailto:wyss34 at gmail.com]>
Sent: Tuesday, October 16, 2012 8:40 AM
To: Hendrix, George (Bill) @ NSS - STRATIS
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] DTMF Issue with one external number

What does your SDP show using debug ccsip all?

I've ran into this before where the provider had a different RTP map to their IP customers vs their ISDN customers.  What I had to do was create separate dialpeers for those numbers with a different RTP map.  See example below:
v=0
o=CiscoSystemsSIP-GW-UserAgent 9601 2828 IN IP4 X.X.X.X
s=SIP Call
c=IN IP4 X.X.X.X
t=0 0
m=audio 16384 RTP/AVP 18 0 101
c=IN IP4 10.8.2.4
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:0 PCMU/8000
a=rtpmap:101 X-NSE/8000
a=fmtp:101 192-194

v=0
o=Sonus_UAC 16372 5325 IN IP4 X.X.X.X
s=SIP Media Capabilities
c=IN IP4 X.X.X.X
t=0 0
m=audio 23002 RTP/AVP 18 0 100
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv
a=maxptime:20

As mentioned above the yellow highlighted portion of the SDP’s is where we can see a mismatch in our payload type.  You can see the telco is sending 100 and we are sending 101.  To resolve this issue you have to remap the rtp payload type for signaling and telephony events.  Here is the commands I had to run to send 100 as our NTE to match what the provider was expecting…

Lincoln-VG01(config-dial-peer)#rtp payload-type nse 98
Lincoln-VG01(config-dial-peer)#rtp payload-type nte 100
Lincoln-VG01(config-dial-peer)#rtp payload-type nse 101

Because the signaling is defaulted at nte 101 and nse 100 you have to remove 100 from nse by assigning it a random unused value before you can assign 100 to nte.  See this image for the default reserved values: https://communities.cisco.com/servlet/JiveServlet/downloadImage/2-5295-2243/450-185/defaultpayloadtype.png

Hope this helps,

Derek

On Tue, Oct 16, 2012 at 7:25 AM, <george.hendrix at l-3com.com<mailto:george.hendrix at l-3com.com>> wrote:
Hey guys,

  We have an odd issue going on with DTMF.  Below is the path to the PSTN.

CUCM <-> h.323 Gateway <-> SIP Provider.

The problem is that when we dial into this one external number and press 1 to select option 1, it doesn’t seem to accept the digit.  If we dial into that same number from anywhere else, it works fine.  Having said that, I can dial into other numbers from the system and have no issue at all with dtmf.  Any ideas of what this issue is?

Thanks,
Bill



_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments. Please be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121018/39f89116/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 379 bytes
Desc: image001.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121018/39f89116/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 338 bytes
Desc: image002.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121018/39f89116/attachment-0001.jpg>


More information about the cisco-voip mailing list