[cisco-voip] DTMF Issue with one external number
Tim
bcchimp at gmail.com
Tue Dec 11 09:53:10 EST 2012
Cool, sounds like our issues were different all together.
From: george.hendrix at l-3com.com [mailto:george.hendrix at l-3com.com]
Sent: Tuesday, December 11, 2012 8:08 AM
To: bcchimp at gmail.com
Cc: cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] DTMF Issue with one external number
My TAC engineer resolved the issue by creating specific incoming dial-peers
for our range of DIDs along with forcing early offer on the gateway.
Voice service voip
SIP
Early-offer forced
Along with this, he had me to enable fast start on CUCM gateway properties
and I also had to make sure MTP required was checked on the gatway.
According to my TAC engineer, this configuration was the correct setup due
to the fact that I am doing SIP to the provider and h323 to CUCM. He said I
would not have had the issue if I were doing SIP on both sides, or just all
h323.
Regards,
Bill
From: bcchimp at gmail.com [mailto:bcchimp at gmail.com]
Sent: Monday, December 10, 2012 8:15 PM
To: Hendrix, George (Bill) @ NSS - STRATIS
Cc: cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] DTMF Issue with one external number
Bill,
My TAC engineer was able to resolve the issue by registering the transcoders
to the local router, not to CUCM, unchecked MTP Required, and forced the VGW
to use a different codec than the carrier. Apparently the carrier was not
doing any transcoding for the customers as they should be. Registering the
transcoders locally apparently is a better "global" transcoding solution
than having them registered to CUCM.
Hope this helps.
From: george.hendrix at l-3com.com [mailto:george.hendrix at l-3com.com]
Sent: Friday, November 30, 2012 10:48 AM
To: bcchimp at gmail.com
Cc: cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] DTMF Issue with one external number
I have not. I have a TAC case open on this and TAC is saying it is a DTMF
negotiation issue with the provider. I had to open a new ticket with the
provider because they put in the ticket that they didn't see any issues and
just resolved the ticket.
-Bill
From: bcchimp at gmail.com [mailto:bcchimp at gmail.com]
Sent: Thursday, November 29, 2012 1:40 PM
To: Hendrix, George (Bill) @ NSS - STRATIS
Cc: cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] DTMF Issue with one external number
Hi George,
Just wanted to check in and see if you ever got a resolution to this
problem?
Thanks.
From: george.hendrix at l-3com.com [mailto:george.hendrix at l-3com.com]
Sent: Monday, October 22, 2012 8:39 AM
To: Nick Matthews; Tim
Cc: Derek Wyss; cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] DTMF Issue with one external number
I checked to make sure it took the command and it also showed that nte 100
was preferred. However, I was not able to navigate any menu with it set to
this. When I switched it back to the default, the other numbers that worked
with the default setting started working again.
-Bill
From: matthn at gmail.com [mailto:matthn at gmail.com] On Behalf Of Nick Matthews
Sent: Sunday, October 21, 2012 10:12 PM
To: Tim
Cc: Hendrix, George (Bill) @ NSS - STRATIS; Derek Wyss;
cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] DTMF Issue with one external number
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] 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/20121211/750acc3b/attachment.html>
More information about the cisco-voip
mailing list