[cisco-voip] DTMF SIP to Verizon, wrong payload type...
Nick Matthews
matthnick at gmail.com
Fri May 18 12:22:41 EDT 2012
A little more background information for the curious:
NSE - this is a cisco proprietary RTP packet type that we've used for
a long time to signal certain events from device to device. Cisco Fax
Relay uses this (defunct), as well as modem passthrough. Basically
two cisco TDM termination devices that need to switch to faxing or
modem.
So in theory it should only have an effect if your ISP supported Cisco
specific modem passthrough (not likely) or you had TDM ports on your
CUBE that were interoperating with other Cisco gateways.
I filed a bug on this a while back: CSCtc00564. It should warn you
when you do this, though I can't remember if it blocks the
configuration or not. You shouldn't be able to assign both DTMF and
modem passthrough to the same RTP payload type.
-nick
On Thu, May 17, 2012 at 4:58 PM, Jonathan Charles <jonvoip at gmail.com> wrote:
>
> That fixed it!
>
> Yay....
>
> Now, will faxing still work...
>
> On Thu, May 17, 2012 at 2:15 PM, Nick Matthews <matthnick at gmail.com> wrote:
>>
>> They're actually right.
>>
>> Remove this:
>> modem passthrough nse payload-type 101 codec g711ulaw
>>
>> Or change it to something similar like:
>> modem passthrough nse payload-type 100 codec g711ulaw
>>
>> -nick
>>
>>
>> On Thu, May 17, 2012 at 2:58 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com> wrote:
>>>
>>> Do you use EO in CUCM on the Trunk's SIP profile? And what is the DTMF setting in CUCM on the trunk? And lastly, your MTP Required check box setting on the trunk?
>>>
>>> -Anthony
>>>
>>>
>>> On Thu, May 17, 2012 at 1:49 PM, Jonathan Charles <jonvoip at gmail.com> wrote:
>>>>
>>>> Even that example shows:
>>>>
>>>> a=rtpmap:101 telephone-event/8000
>>>>
>>>> Whereas I am seeing
>>>>
>>>> a=rtpmap:101 X-NSE/8000
>>>>
>>>>
>>>> A: Why?
>>>> B: How do I change it?
>>>>
>>>> On Thu, May 17, 2012 at 1:42 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com> wrote:
>>>>>
>>>>> Here is the VoE I was talking about:
>>>>>
>>>>> https://communities.cisco.com/docs/DOC-7823
>>>>>
>>>>> Look towards the top for "VoE - CUBE SIP Trunking"
>>>>>
>>>>> Then download the PDF, and goto page 90. The page is also discuss in the Webex recording @ 1h 48m 55s. For those who cannot see this, it says:
>>>>>
>>>>>> “c” parameter identifies the IP
>>>>>> address (20.1.1.1) that the peer
>>>>>> device should send the media to
>>>>>
>>>>>
>>>>>>
>>>>>> “m” parameter identifies:
>>>>>> the type of call (audio)
>>>>>> port number for media (16950)
>>>>>> payload type for the 1st
>>>>>> preferred codec (18 for G729)
>>>>>> dtmf (101 for RFC2833)
>>>>>
>>>>>
>>>>>>
>>>>>> “a’” parameter identifies all the
>>>>>> codecs and other descriptors for this
>>>>>> call leg
>>>>>
>>>>>
>>>>> This VoE event is very informative. Hope that helps.
>>>>>
>>>>> -Anthony
>>>>>
>>>>> On Thu, May 17, 2012 at 1:20 PM, Jonathan Charles <jonvoip at gmail.com> wrote:
>>>>>>
>>>>>> It is not.
>>>>>>
>>>>>> Per Verizon tech:
>>>>>>
>>>>>> Octet1058 SIP Message Body: SDP
>>>>>> --------------------------------------------------------------------------------
>>>>>> ........ Header Field v=0
>>>>>> ........ o=CiscoSystemsSIP-GW-UserAgent 794 632 IN IP4 1,1,1,1
>>>>>> ........ s=SIP Call
>>>>>> ........ c=IN IP4 1.1.1.1
>>>>>> ........ t=0 0
>>>>>> ........ m=audio 17176 RTP/AVP 0 101
>>>>>> ........ c=IN IP4 1.1.1.1
>>>>>> ........ a=rtpmap:0 PCMU/8000
>>>>>> ........ a=rtpmap:101 X-NSE/8000 <-- should be telephone-event/8000
>>>>>> ........ a=fmtp:101 192-194
>>>>>> ........ a=ptime:20
>>>>>>
>>>>>>
>>>>>> They say the problem is on our end, and since we are sending the wrong DTMF, they are closing their ticket.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, May 17, 2012 at 1:17 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com> wrote:
>>>>>>>
>>>>>>> I'm glad you posted that.
>>>>>>>
>>>>>>> The m= is the actual setting for that call. The a= are the available settings. And you can see in the m=, you have codec 0 (g711) and DTMF 101 (telephony).
>>>>>>>
>>>>>>> This looks correct.
>>>>>>>
>>>>>>> -Anthony
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 17, 2012 at 1:13 PM, Jonathan Charles <jonvoip at gmail.com> wrote:
>>>>>>>>
>>>>>>>> Added it, no change.
>>>>>>>>
>>>>>>>>
>>>>>>>> v=0
>>>>>>>> o=CiscoSystemsSIP-GW-UserAgent 2264 8655 IN IP4 157.130.97.178
>>>>>>>> s=SIP Call
>>>>>>>> c=IN IP4 1.1.1.1
>>>>>>>> t=0 0
>>>>>>>> m=audio 18130 RTP/AVP 0 101
>>>>>>>> c=IN IP4 157.130.97.178
>>>>>>>> a=rtpmap:0 PCMU/8000
>>>>>>>> a=rtpmap:101 X-NSE/8000 <------------- this needs to be telephone-event/8000
>>>>>>>> a=fmtp:101 192-194
>>>>>>>> a=ptime:20
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, May 17, 2012 at 12:49 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I see you are setting EO = Forced on the CUBE, which the telco requires, but are you using EO on the SIP trunk form CUCM to the CUBE? What is your DTMF Signaling Method set to on that Trunk?
>>>>>>>>>
>>>>>>>>> The only command I run which I can see is missing from your config is:
>>>>>>>>>
>>>>>>>>> voice service voip
>>>>>>>>> dtmf-interworking rtp-nte
>>>>>>>>>
>>>>>>>>> But I'm not positive that's your problem.
>>>>>>>>>
>>>>>>>>> -Anthony
>>>>>>>>>
>>>>>>>>> On Thu, May 17, 2012 at 12:01 PM, Jonathan Charles <jonvoip at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> We have a SIP trunk to Verizon, Long Distance, Local and international work fine, however, for toll free calls, DTMF does not function.
>>>>>>>>>>
>>>>>>>>>> We are set to send RTP-NTE, but Verizon is saying that we are sending this:
>>>>>>>>>>
>>>>>>>>>> a=rtpmap:101 X-NSE/8000
>>>>>>>>>>
>>>>>>>>>> And it should be:
>>>>>>>>>>
>>>>>>>>>> telephone-event/8000
>>>>>>>>>>
>>>>>>>>>> And that is why it is failing.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What configuration change can we do to force it to send the right DTMF method?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This is on a Cisco 3825 CUBE running 12.2.20.T4 (per Verizon's request), there is a software MTP and Transcoder on the router (both in use)... Verizon says it is not their problem and closed their ticket.
>>>>>>>>>>
>>>>>>>>>> Relevant SIP Config:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> !
>>>>>>>>>> voice call send-alert
>>>>>>>>>> voice rtp send-recv
>>>>>>>>>> !
>>>>>>>>>> voice service voip
>>>>>>>>>> allow-connections h323 to h323
>>>>>>>>>> allow-connections h323 to sip
>>>>>>>>>> allow-connections sip to h323
>>>>>>>>>> allow-connections sip to sip
>>>>>>>>>> no supplementary-service sip refer
>>>>>>>>>> redirect ip2ip
>>>>>>>>>> h323
>>>>>>>>>> h225 display-ie ccm-compatible
>>>>>>>>>> modem passthrough nse payload-type 101 codec g711ulaw
>>>>>>>>>> sip
>>>>>>>>>> bind media source-interface MFR1
>>>>>>>>>> early-offer forced
>>>>>>>>>> midcall-signaling passthru
>>>>>>>>>> !
>>>>>>>>>> !
>>>>>>>>>>
>>>>>>>>>> dial-peer voice 800 voip
>>>>>>>>>> description OUTBOUND Voice SIP calls to VzB
>>>>>>>>>> destination-pattern 1800[2-9]......
>>>>>>>>>> voice-class sip dtmf-relay force rtp-nte
>>>>>>>>>> session protocol sipv2
>>>>>>>>>> session target sip-server
>>>>>>>>>> incoming called-number .
>>>>>>>>>> dtmf-relay rtp-nte
>>>>>>>>>> codec g711ulaw
>>>>>>>>>> no vad
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> !
>>>>>>>>>> sip-ua
>>>>>>>>>> retry invite 2
>>>>>>>>>> retry bye 2
>>>>>>>>>> retry cancel 2
>>>>>>>>>> registrar dns:verizonsipgateway expires 3600
>>>>>>>>>> sip-server dns:verizonsipgateway:5071
>>>>>>>>>> g729-annexb override
>>>>>>>>>> !
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jonathan
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>
>>
>
More information about the cisco-voip
mailing list