[cisco-voip] DTMF Issue with one external number

Sun Oct 21 22:12:09 EDT 2012

Double check that the config took the payload type change to 100.  That's
the default for NSE's and you cannot normally change the payload type value
unless you change the NSE value to another value first.

Don't have a CLI in front of me, but it's similar to:
rtp payload-type nse 99
rtp payload-type nte 100

-nick

On Fri, Oct 19, 2012 at 2:43 PM, Tim <bcchimp at gmail.com> wrote:

> Yes, I have the same feeling on my side. Same problem, just one external
> number doesn’t work.  The far end system is connected on the same carrier
> using SIP Trunks.  Doesn’t make much sense, but from what I’ve been told
> the far end system is some sort of AdTran.****
>
> ** **
>
> *From:* george.hendrix at l-3com.com [mailto:george.hendrix at l-3com.com]
> *Sent:* Friday, October 19, 2012 1:35 PM
> *To:* bcchimp at gmail.com; 'Derek Wyss'
>
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* RE: [cisco-voip] DTMF Issue with one external number****
>
> ** **
>
> Nope, still have this same issue.  Very frustrating that the issue is only
> to one external number and I can actually see the digits being passed out
> the SIP trunk.  And since it works for all other numbers, I really don’t
> see how it could be a carrier issue on our side.****
>
> ** **
>
> -Bill****
>
> ** **
>
> ** **
>
> *From:* bcchimp at gmail.com [mailto:bcchimp at gmail.com]
> *Sent:* Friday, October 19, 2012 11:38 AM
> *To:* Hendrix, George (Bill) @ NSS - STRATIS; 'Derek Wyss'
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* RE: [cisco-voip] DTMF Issue with one external number****
>
> ** **
>
> George,****
>
> ** **
>
> Did you ever find a fix on this? I believe I’m having a similar issue.****
>
> ** **
>
> Thanks****
>
> ** **
>
> *From:* cisco-voip-bounces at puck.nether.net [
> mailto:cisco-voip-bounces at puck.nether.net<cisco-voip-bounces at puck.nether.net>]
> *On Behalf Of *george.hendrix at l-3com.com
> *Sent:* Tuesday, October 16, 2012 9:18 PM
> *To:* Derek Wyss
> *Cc:* 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]
> *Sent:* Tuesday, October 16, 2012 8:40 AM
> *To:* Hendrix, George (Bill) @ NSS - STRATIS
> *Cc:* 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> 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
> https://puck.nether.net/mailman/listinfo/cisco-voip****
>
> ** **
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121021/4284a134/attachment.html>