[cisco-voip] DTMF SIP to Verizon, wrong payload type...

Nick csvoip at googlemail.com
Fri May 18 06:39:53 EDT 2012


I have faxing and dmtf working perfectly over Verizon using the following

!
voice service voip
 address-hiding
 dtmf-interworking rtp-nte
 mode border-element
 allow-connections sip to sip
 redundancy
 fax protocol pass-through g711ulaw
 sip
  bind control source-interface GigabitEthernet0/0
  bind media source-interface GigabitEthernet0/0
  early-offer forced
  midcall-signaling passthru

On 17 May 2012 21:58, 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
>>>
>>>
>>
>
> _______________________________________________
> 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/20120518/e0b2c54b/attachment.html>


More information about the cisco-voip mailing list