[cisco-voip] CUBE and LTI for MTPs

Fri Jul 8 16:31:08 EDT 2016

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 <ealeatherman at gmail.com>
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 <
> 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/20160708/1e50f598/attachment.html>