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 <[email protected]> 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- > [email protected] > State of the call : STATE_ACTIVE (7) > Substate of the call : SUBSTATE_NONE (0) > Calling Number : 608xxxssss > Called Number : 608xxxyyyy > Called URI : sip:[email protected]: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 : [email protected]:5070 > State of the call : STATE_ACTIVE (7) > Substate of the call : SUBSTATE_NONE (0) > Calling Number : 608xxxyyyy > Called Number : 608xxxssss > Called URI : sip:[email protected]: > 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:[email protected]:5070;transport=tcp SIP/2.0 > Via: SIP/2.0/TCP 172.25.1.10:5060;branch=z9hG4bKeec9a316b8c73 > From: <sip:[email protected]>;tag=1294924~b2f5c4f8-0137- > 42eb-8fa5-d6a25f53a8b9-18334838 > To: "VAN BENSCHOTEN" <sip:[email protected]>;tag=174FD08-EF4 > Call-ID: [email protected] > 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 < > [email protected]> 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 <[email protected]> >> 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 < >>> [email protected]> 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 <[email protected]> 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 <[email protected]> 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 < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> 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 < >>>>>>>> [email protected]> 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 >>>>>>>>> [email protected] >>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> cisco-voip mailing list >>>> [email protected] >>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>> >>>> >>> >>> >>> -- >>> Ed Leatherman >>> >> >> >> _______________________________________________ >> cisco-voip mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
