<div dir="ltr">Ok, time to take a step back and appreciate the situation I just found myself in.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><div>CUBE#sh voip rtp conn | in 10\.</div><div>2 20591 20590 16434 30492 10.U.B.E 10.U.C.M</div></div><div><br></div><div><div>CUBE#sh call active voice | in Dtmf</div><div>tx_DtmfRelay=rtp-nte</div><div>tx_DtmfRelay=rtp-nte</div></div><div><br></div><div><br></div><div>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.</div><div><div><div><br></div><div>CUBE#sh voip rtp conn | in 10\.</div><div>2 20579 20578 16430 26404 10.U.B.E 10.C.C.X</div></div><div><br></div><div>CUBE#sh call active voice | in Dtmf</div><div>tx_DtmfRelay=rtp-nte</div><div><span style="line-height:1.5;font-size:13.1999998092651px">tx_DtmfRelay=sip-kpml</span><br></div><div><br></div><div>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.</div><div><br></div></div></div><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 1:29 PM Brian Meade <<a href="mailto:bmeade90@vt.edu">bmeade90@vt.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">dtmf-relay I believe should handle that find for you without the MTP.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 1:21 PM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<br><br><div>PSTN Caller Pushes DTMF ---> ITSP Delivers RFC2833 ---> CUBE Delivers OOB ---> CUCM Devlier OOB ---> UCCX CTI Port Receives OOB</div><div><br></div><div><span style="line-height:1.5;font-size:13.1999998092651px">Is that not the case?</span><br></div></div><div><div><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 12:01 PM Brian Meade <<a href="mailto:bmeade90@vt.edu" target="_blank">bmeade90@vt.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What are you trying to accomplish with the MTP that can't already be accomplished with media flow-through and dtmf-relay?</div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 30, 2015 at 12:38 PM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">All,<div><br></div><div>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.</div><div><br></div><div>This works for me:</div><div>dspfarm profile 1 transcode</div><div> codec g711ulaw</div><div> codec g729ar8</div><div> max sessions 1</div><div> assoc app cube</div><div> no shut</div><div>!</div><div><br></div><div>This does not work for me (it hangs on associating to cube app):</div><div>dapfarm profile 2 mtp</div><div> codec g711ulaw</div><div> max sessions software 1</div><div> assoc app cube</div><div> no shut</div><div>!</div><div><br></div><div>I have the required dspfarm and mode border-element commands, and rebooted after as well.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>1. LTI</div><div>2. SCCP via Telephony Service</div><div>3. SCCP via CUCM</div><div><br></div><div>Would you rank them differently?</div><div><br></div><div>Thanks for your input in advance.</div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div>