[cisco-voip] CUBE and LTI for MTPs

[Ed Leatherman]

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/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 <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/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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160707/30700aa3/attachment.html>