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 : [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/ >>> cucm/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/ >>>> en/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
