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
