[cisco-voip] CUBE and LTI for MTPs

[Anthony Holloway]

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