[cisco-voip] CUBE and LTI for MTPs
Anthony Holloway
avholloway+cisco-voip at gmail.com
Wed Dec 7 00:16:29 EST 2016
DTMF and SIP has been a real challenge for me lately. For some reason the
KPML to RFC2833 (RTP-NTE) inter-working has not been working for me. As
in, I'm seeing a higher rate of failures using this inter-working method.
I have recently switched over to NOTIFY to RFC2833 inter-working and so
far, I haven't seen any problems. You just have to enable unsolicited
notify on the SIP trunk security profile. Sorry, but I don't have an
answer for you.
On Tue, Dec 6, 2016 at 10:16 PM, Brian V <bvanbens at gmail.com> wrote:
> Resurrecting this thread again.... :)
>
> Anthony, were you ever able to find a definitive answer if you can
> register a software-only MTP to CUBE using the LTI method ? I'm trying it
> on a ISR 4321 with IOS-XE 16.3.2 and finding the same result you did where
> it won't register.
>
> I also share your observation (perhaps wonderment) that CUBE appears to
> natively inter-network between the CUCM call leg using KPML and the SIP
> provider call leg using rte-nte (RFC2833) without using any MTP or
> transcoders. This is contrary to the supported DTMF inter-networking
> support in the latest CUBE book for IOX-XE (http://www.cisco.com/c/en/us/
> td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html)
>
> When there is a call setup where the leg from CUBE to CUCM is using KPML
> (to an MGCP controlled FXS port) and the leg to the SIP provider is using
> rtp-nte:
> The FXS phone presses a digit,
> I see CUCM send the Notify to CUBE, then CUBE seems to package up the
> digit in rtp-nte RTP packets and sends it out the call-leg toward the SIP
> provider. No MTPs are configured on CUBE, No transcoders on CUBE and the
> media streaming service is shut down on both CUCM nodes just for testing.
> This is not supposed to work according to the documentation, yet it does.
>
> debugs
> debug ccsip messages
> debug VOIP RTP ALL Named Events is ON
> debug VOIP RTP DTMF-RELAY Events is ON
>
>
> !! config snippets
> voice service voip
> ip address trusted list
> no ip address trusted authenticate
> allow-connections sip to sip
> fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
> sip
> registrar server
> listen-port non-secure 5070
> early-offer forced
> no call service stop
>
> voice class uri FromCUCM sip
> host ipv4:172.25.1.10
> host ipv4:172.25.1.11
>
> voice class codec 1
> codec preference 1 g711ulaw
> codec preference 2 g729r8
>
> voice class e164-pattern-map 50
> e164 91[2-9]..[2-9]......
> e164 1[2-9]..[2-9]......
> e164 9[2-9]......
>
> voice class server-group 100
> ipv4 172.25.1.10 port 5060 preference 1
> ipv4 172.25.1.11 port 5060 preference 2
> description CUCM Servers - PUB First
>
> dial-peer voice 201 voip
> session protocol sipv2
> session target sip-server
> incoming called-number 608xxxssss ! < ==inbound dial-peer for SIP service
> dtmf-relay rtp-nte
> codec g711ulaw
> no vad
>
> dial-peer voice 600 voip
> description Google Voice via Simonics.com SIP TRUNK
> translation-profile outgoing VoIPOut-Drp9-LDKeep1-IntKeep011
> session protocol sipv2
> session target dns:gvgw.simonics.com:5070 <== outbound dial peer to SIP
> service
> destination e164-pattern-map 50
> voice-class codec 1
> dtmf-relay rtp-nte
>
>
> dial-peer voice 300 voip
> description outgoing to CUCM <== outbound dial peer to CUCM
> destination-pattern 608xxxssss <= matches inbound dial peer telephone
> number
> session protocol sipv2
> session transport tcp
> session server-group 100
> voice-class codec 1
> dtmf-relay sip-kpml rtp-nte
> ip qos dscp cs3 signaling
> no vad
>
>
>
> *** call is up, 2-way audio*
>
> PSTN-WAN#sh sip-ua calls
> Total SIP call legs:2, User Agent Client:1, User Agent Server:1
> SIP UAC CALL INFO
> Call 1
> SIP Call ID : D370F53F-BB6811E6-80B6B76E-
> F014D1AB at 192.168.0.4
> State of the call : STATE_ACTIVE (7)
> Substate of the call : SUBSTATE_NONE (0)
> Calling Number : 608xxxssss
> Called Number : 608xxxyyyy
> Called URI : sip:608xxxssss at 172.25.1.10:5060
> Bit Flags : 0xC04018 0x90000100 0x80
> CC Call ID : 169
> Source IP Address (Sig ): 192.168.0.4
> Destn SIP Req Addr:Port : [172.25.1.10]:5060 <== CUCM
> Destn SIP Resp Addr:Port: [172.25.1.10]:5060
> Destination Name : 172.25.1.10
> Number of Media Streams : 1
> Number of Active Streams: 1
> RTP Fork Object : 0x0
> Media Mode : flow-through
> Media Stream 1
> State of the stream : STREAM_ACTIVE
> Stream Call ID : 169
> Stream Type : voice-only (0)
> Stream Media Addr Type : 1
> Negotiated Codec : g711ulaw (160 bytes)
> Codec Payload Type : 0
> Negotiated Dtmf-relay : sip-kpml
> Dtmf-relay Payload Type : 0
> QoS ID : -1
> Local QoS Strength : BestEffort
> Negotiated QoS Strength : BestEffort
> Negotiated QoS Direction : None
> Local QoS Status : None
> Media Source IP Addr:Port: [192.168.0.4]:16476
> Media Dest IP Addr:Port : [10.10.111.3]:16462 <== MGCP FXS Port
>
>
> Options-Ping ENABLED:NO ACTIVE:NO
> Number of SIP User Agent Client(UAC) calls: 1
>
> SIP UAS CALL INFO
> Call 1
> SIP Call ID : 6814308 at 162.243.107.101:5070
> State of the call : STATE_ACTIVE (7)
> Substate of the call : SUBSTATE_NONE (0)
> Calling Number : 608xxxyyyy
> Called Number : 608xxxssss
> Called URI : sip:608xxxssss at 69.129.203.165:
> 53467;transport=tcp
> Bit Flags : 0xC0401C 0x10000100 0x4
> CC Call ID : 168
> Source IP Address (Sig ): 192.168.0.4
> Destn SIP Req Addr:Port : [162.243.107.101]:5070 <== SIP Provider
> Destn SIP Resp Addr:Port: [162.243.107.101]:5070
> Destination Name : 162.243.107.101
> Number of Media Streams : 1
> Number of Active Streams: 1
> RTP Fork Object : 0x0
> Media Mode : flow-through
> Media Stream 1
> State of the stream : STREAM_ACTIVE
> Stream Call ID : 168
> Stream Type : voice+dtmf (0)
> Stream Media Addr Type : 1
> Negotiated Codec : g711ulaw (160 bytes)
> Codec Payload Type : 0
> Negotiated Dtmf-relay : rtp-nte
> Dtmf-relay Payload Type : 101
> QoS ID : -1
> Local QoS Strength : BestEffort
> Negotiated QoS Strength : BestEffort
> Negotiated QoS Direction : None
> Local QoS Status : None
> Media Source IP Addr:Port: [192.168.0.4]:16474
> Media Dest IP Addr:Port : [162.243.107.101]:32738
>
>
> Options-Ping ENABLED:NO ACTIVE:NO
> Number of SIP User Agent Server(UAS) calls: 1
>
>
> *** Now press button 5 on the MGCP FXS phone with the debugs on*
>
> PSTN-WAN#sh debug
>
> debug VOIP RTP ALL Named Events is ON
> debug VOIP RTP DTMF-RELAY Events is ON
> CCSIP SPI: SIP Call Message tracing is enabled (filter is OFF)
>
>
>
> PSTN-WAN#
> Dec 7 04:05:45.577: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> Received:
> NOTIFY sip:608xxxssss at 192.168.0.4:5070;transport=tcp SIP/2.0
> Via: SIP/2.0/TCP 172.25.1.10:5060;branch=z9hG4bKeec9a316b8c73
> From: <sip:608xxxssss at 172.25.1.10>;tag=1294924~b2f5c4f8-0137-
> 42eb-8fa5-d6a25f53a8b9-18334838
> To: "VAN BENSCHOTEN" <sip:608xxxyyyy at gvgw.simonics.com>;tag=174FD08-EF4
> Call-ID: D370F53F-BB6811E6-80B6B76E-F014D1AB at 192.168.0.4
> CSeq: 108 NOTIFY
> Max-Forwards: 70
> Date: Wed, 07 Dec 2016 04:05:45 GMT
> User-Agent: Cisco-CUCM11.0
> Event: kpml
> Subscription-State: active;expires=7030
> Contact: <sip:172.25.1.10:5060;transport=tcp>
> Content-Type: application/kpml-response+xml
> Content-Length: 336
>
> <?xml version="1.0" encoding="UTF-8" ?>
> <kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-response
> kpml-response.xsd" code="200" digits="5" forced_flush="false"
> suppressed="false" tag="dtmf" text="Success" version="1.0"/>
>
>
> Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
> sequence 0x7188 timestamp 0x4E9576E9
> Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:0A 00 00 <Snd>>>
> Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
> sequence 0x7189 timestamp 0x4E9576E9
> Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:0A 00 00 <Snd>>>
> Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
> sequence 0x718A timestamp 0x4E9576E9
> Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:0A 00 00 <Snd>>>
> Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
> sequence 0x718B timestamp 0x4E9576E9
> Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:0A 01 90 <Snd>>>
> Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
> sequence 0x718C timestamp 0x4E9576E9
> PSTN-WAN#
> Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:84 03 20 <Snd>>>
> Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
> sequence 0x718D timestamp 0x4E9576E9
> Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:84 03 20 <Snd>>>
> Dec 7 04:05:45.577: s=DSP d=VoIP payload 0x65 ssrc 0x16616F03
> sequence 0x718E timestamp 0x4E9576E9
> Dec 7 04:05:45.577: Pt:101 Evt:5 Pkt:84 03 20 <Snd>>>
>
>
> Sure looks like CUBE is internetworking between SIP-KPML and RTP-NTE
> (RFC2833) when it's not supported
>
> *!!*** now press button 6 from the PSTN phone*
>
> PSTN-WAN#
> PSTN-WAN#
> Dec 7 04:10:00.649: s=VoIP d=DSP payload 0x65 ssrc 0x5B76F3C5
> sequence 0x7F3F timestamp 0xE703188
> Dec 7 04:10:00.649: <<<Rcv> Pt:101 Evt:6 Pkt:00 00 00
> Dec 7 04:10:00.649: s=DSP d=VoIP payload 0x65 ssrc 0x5B76F3C5
> sequence 0x7F3F timestamp 0xE703188
> Dec 7 04:10:00.649: Pt:101 Evt:6 Pkt:00 00 00 <Snd>>>
> Dec 7 04:10:00.669: s=VoIP d=DSP payload 0x65 ssrc 0x5B76F3C5
> sequence 0x7F40 timestamp 0xE703188
> Dec 7 04:10:00.669: <<<Rcv> Pt:101 Evt:6 Pkt:80 07 80
> Dec 7 04:10:00.669: s=DSP d=VoIP payload 0x65 ssrc 0x5B76F3C5
> sequence 0x7F40 timestamp 0xE703188
> PSTN-WAN#
> Dec 7 04:10:00.669: Pt:101 Evt:6 Pkt:80 07 80 <Snd>>>
> Dec 7 04:10:00.669: s=VoIP d=DSP payload 0x65 ssrc 0x5B76F3C5
> sequence 0x7F40 timestamp 0xE703188
> Dec 7 04:10:00.669: <<<Rcv> Pt:101 Evt:6 Pkt:80 07 80
> Dec 7 04:10:00.669: s=DSP d=VoIP payload 0x65 ssrc 0x5B76F3C5
> sequence 0x7F40 timestamp 0xE703188
> Dec 7 04:10:00.669: Pt:101 Evt:6 Pkt:80 07 80 <Snd>>>
> PSTN-WAN#
>
>
> We see inbound rte-nte packets, *no* SIP-Notify towards CUCM , yet on the
> MGCP FXS phone I hear the inbound DTMF.
>
> Whats going on here ?
> Any thoughts ?
>
>
>
>
> On Fri, Jul 8, 2016 at 3:31 PM, Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
>> I use rtp-nte to SIP KPML in CUBE quite a bit actually, despite the
>> documentation saying it's not supported. I also use digit-drop too by the
>> way, because on more than one occasion I have had double DTMF issues.
>>
>> E.g., dtmf-relay sip-kpml rtp-nte digit-drop
>>
>> Also, unless you like using MTPs in your some of call flows (E.g., UCCX),
>> you should have one OOB and one inband DTMF offering on your dial-peers.
>> It surprises me how often I see and hear of people only putting rtp-nte on
>> there.
>>
>> On Thu, Jul 7, 2016 at 7:20 PM, Ed Leatherman <ealeatherman at gmail.com>
>> wrote:
>>
>>> I've been beating my head on this all day, glad I ran across this thread
>>> as it at least seems to rule out one potential issue on my current SIP
>>> puzzle :)
>>>
>>> I've found 2 different documents with tables that suggest KPML <>
>>> rpt-nte shouldn't work... i realize its over a year since this thread
>>> popped in - has anyone ever seen something to the contrary in official
>>> documentation?
>>>
>>> On Tue, Mar 31, 2015 at 11:54 AM, Anthony Holloway <
>>> avholloway+cisco-voip at gmail.com> wrote:
>>>
>>>> After reading a bit more in the CUCM SRND, I see that SIP INFO is not
>>>> supported by CUCM, and furthermore, Cisco's preferred OOB method is KPML.
>>>>
>>>> "Out-of-band (OOB) SIP DTMF signalling methods include Unsolicited
>>>> Notify (UN), Information
>>>> (INFO), and Key Press Mark-up Language (KPML). KPML (RFC 4730) is the
>>>> OOB signalling method
>>>> preferred by Cisco and is supported by Cisco Unified CM, Cisco IOS
>>>> platforms (Release 12.4 and later),
>>>> and most models of Cisco Unified IP Phones. INFO is not supported by
>>>> Unified CM."
>>>> Source: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/c
>>>> ucm/srnd/collab10/collab10/trunks.html#pgfId-1346554
>>>>
>>>> With that said, according to the link you provided on CUBE and DTMF
>>>> inter-working, it would appear as though the only option which remains is
>>>> SIP NOTIFY. This method requires the SIP Trunk Security Profile to have
>>>> the Accept unsolicited notification checkbox checked.
>>>>
>>>> I did test with KPML, and CUBE did inter-work it. My IOS/CUBE version
>>>> is as follows:
>>>>
>>>> *CUBE#sh cube status | in Version*
>>>> *CUBE-Version : 10.0.2*
>>>> *SW-Version : 15.4.3.M2, Platform CISCO2921/K9*
>>>>
>>>> I think I'll go with KPML for now, and thank you for helping me to see
>>>> the light.
>>>>
>>>> On Mon, Mar 30, 2015 at 1:52 PM Brian Meade <bmeade90 at vt.edu> wrote:
>>>>
>>>>> This chart has all the interoperability that can be handled by
>>>>> dtmf-relay natively on CUBE- http://www.cisco.com/c/e
>>>>> n/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/
>>>>> dtmf-relay.html#concept_264617919921874995299551391601561
>>>>>
>>>>> Brian
>>>>>
>>>>> On Mon, Mar 30, 2015 at 2:29 PM, Brian Meade <bmeade90 at vt.edu> wrote:
>>>>>
>>>>>> dtmf-relay I believe should handle that find for you without the MTP.
>>>>>>
>>>>>> On Mon, Mar 30, 2015 at 1:21 PM, Anthony Holloway <
>>>>>> avholloway+cisco-voip at gmail.com> wrote:
>>>>>>
>>>>>>> Oooo, good question Brian. It's my understanding that in order for
>>>>>>> the below specific call flow to work, an MTP is required for DTMF
>>>>>>> inter-working of inband to out-of-band.
>>>>>>>
>>>>>>> PSTN Caller Pushes DTMF ---> ITSP Delivers RFC2833 ---> CUBE
>>>>>>> Delivers OOB ---> CUCM Devlier OOB ---> UCCX CTI Port Receives OOB
>>>>>>>
>>>>>>> Is that not the case?
>>>>>>>
>>>>>>> On Mon, Mar 30, 2015 at 12:01 PM Brian Meade <bmeade90 at vt.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> What are you trying to accomplish with the MTP that can't already
>>>>>>>> be accomplished with media flow-through and dtmf-relay?
>>>>>>>>
>>>>>>>> On Mon, Mar 30, 2015 at 12:38 PM, Anthony Holloway <
>>>>>>>> avholloway+cisco-voip at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> I know the name itself, LTI, includes the word transcoding, but
>>>>>>>>> I'm just double checking that this will or will not work for registering an
>>>>>>>>> MTP on the CUBE. All roads are leading me to the answer, but it just seems
>>>>>>>>> like a huge miss on Cisco's part to not allow us to register MTPs as well
>>>>>>>>> as XCODE via the LTI method.
>>>>>>>>>
>>>>>>>>> This works for me:
>>>>>>>>> dspfarm profile 1 transcode
>>>>>>>>> codec g711ulaw
>>>>>>>>> codec g729ar8
>>>>>>>>> max sessions 1
>>>>>>>>> assoc app cube
>>>>>>>>> no shut
>>>>>>>>> !
>>>>>>>>>
>>>>>>>>> This does not work for me (it hangs on associating to cube app):
>>>>>>>>> dapfarm profile 2 mtp
>>>>>>>>> codec g711ulaw
>>>>>>>>> max sessions software 1
>>>>>>>>> assoc app cube
>>>>>>>>> no shut
>>>>>>>>> !
>>>>>>>>>
>>>>>>>>> I have the required dspfarm and mode border-element commands, and
>>>>>>>>> rebooted after as well.
>>>>>>>>>
>>>>>>>>> Seems like with the standard requirement of rfc2833 on SIP trunks
>>>>>>>>> to the ITPS, and CTI apps in the network (I'm looking at you UCCX), MTPs
>>>>>>>>> play a large role in the success of SIP trunking for customers, and yet I
>>>>>>>>> cannot even register them locally with the LTI.
>>>>>>>>>
>>>>>>>>> I do have a fallback plan, so I'm not stuck. I'm just looking for
>>>>>>>>> the optimal design scenario. In my order of preference I would like to go:
>>>>>>>>>
>>>>>>>>> 1. LTI
>>>>>>>>> 2. SCCP via Telephony Service
>>>>>>>>> 3. SCCP via CUCM
>>>>>>>>>
>>>>>>>>> Would you rank them differently?
>>>>>>>>>
>>>>>>>>> Thanks for your input in advance.
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Ed Leatherman
>>>
>>
>>
>> _______________________________________________
>> 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/20161206/608d8d2f/attachment.html>
More information about the cisco-voip
mailing list