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
