[cisco-voip] CUBE and LTI for MTPs

[Anthony Holloway]

According to the table in that document, what I just did is not supported.
Great!

On Mon, Mar 30, 2015 at 1:52 PM Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:

> 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/f040ab0c/attachment.html>