[cisco-voip] CUBE and LTI for MTPs

[Anthony Holloway]

Ok, time to take a step back and appreciate the situation I just found
myself in.

You were absolutely correct.  I lab'd this up just now and my mouth is a
gape.  I've been doing and teaching the MTP method for UCCX for like 4
years now, and not once have I ever had anyone correct me.  Not in the
countless conversations I've had, TAC cases, etc.  It's like I've been in
the Truman show and everyone knew but me, but didn't want to tell me.

This is what it looked like when I had RTP-NTE on both ITSP and CUCM facing
DP's.  Note the 10.U.C.M address is because the MTP is software on CUCM.

CUBE#sh voip rtp conn | in 10\.
2     20591      20590      16434    30492  10.U.B.E
         10.U.C.M

CUBE#sh call active voice | in Dtmf
tx_DtmfRelay=rtp-nte
tx_DtmfRelay=rtp-nte


I changed my CUCM facing DP's to sip-kpml and then it changes to this.
Note the change to 10.C.C.X because no MTP is needed.  And I pushed buttons
to validate, and it worked.

CUBE#sh voip rtp conn | in 10\.
2     20579      20578      16430    26404  10.U.B.E
         10.C.C.X

CUBE#sh call active voice | in Dtmf
tx_DtmfRelay=rtp-nte
tx_DtmfRelay=sip-kpml

Damn.  I'm happy I posted the question, even though it wasn't the answer I
was expecting.  Thanks Brian, I owe you a beer.


On Mon, Mar 30, 2015 at 1: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/20150330/0a9050fd/attachment.html>