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

Joel Perez tman701 at gmail.com
Thu May 17 16:05:30 EDT 2012


I have a few CUBE's using Verizon SIP trunks and the one config that has
pretty much always worked for me is the following:

voice service voip
 dtmf-interworking rtp-nte
 allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip
 no supplementary-service h450.2
 no supplementary-service h450.3
 no supplementary-service sip moved-temporarily
 no supplementary-service sip refer
 fax protocol pass-through g711ulaw
 h323
 modem passthrough nse codec g711ulaw
 sip
  bind control source-interface GigabitEthernet0/0
  bind media source-interface GigabitEthernet0/0
  early-offer forced
  midcall-signaling passthru
!
!
dial-peer voice 313 voip
 description description ** OUTBOUND VOICE SIP CALLS TO VZB FROM FLBOCA**
 translation-profile outgoing DIGITSTRIP-FLBOC
 destination-pattern 113T
 voice-class codec 1
 voice-class sip early-offer forced
 session protocol sipv2
 session target sip-server
 dtmf-relay rtp-nte digit-drop
 no vad
!
!
sip-ua
 retry invite 2
 retry bye 2
 retry cancel 2
 retry options 5
 sip-server ipv4:X.X.X.X:XXXX
 g729-annexb override

It's not the prettiest but it works. Haven't had any issues with DTMF that
I know of using it this way.

Joel P



On Thu, May 17, 2012 at 3: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/20120517/a0e9ed85/attachment.html>


More information about the cisco-voip mailing list