<p dir="ltr">It's likely along the same lines as NAT and Finesse for CCX. It works and people do it fairly often but TAC won't support it because it hasn't been thouroghly tested for issues and full functionality.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Jul 19, 2016 2:29 PM, "Justin Steinberg" <<a href="mailto:jsteinberg@gmail.com">jsteinberg@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">interesting - i wonder why that is not supported when it works. doc error or some legit technical issue ?</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 19, 2016 at 3:44 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">I do it to, but did you know that RTP-NTE to SIP-KPML is not supported on CUBE as of yet?<div><br></div><div><a href="http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561__table_16E37E2F33CE4E0B836D2E5A809E7252" target="_blank">http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561__table_16E37E2F33CE4E0B836D2E5A809E7252</a><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 8:21 PM, Justin Steinberg <span dir="ltr"><<a href="mailto:jsteinberg@gmail.com" target="_blank">jsteinberg@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">yes, CUBE can do RFC2833/NTP to a Telco and SIP-KPML to CUCM. I do this for calls that terminate on CCX IVR since CCX does not support RFC2833. With only rtp-nte on the dialpeer from CUBE to CUCM, CUCM will invoke a MTP. Adding sip-kpml to the dial-peer will allow RTP directly from CUBE to CCX without any MTP in the middle.</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Jul 18, 2016 at 5:08 PM, Ed Leatherman <span dir="ltr"><<a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Thanks Daniel, that helps a lot in understanding the feature. I'm curious if CUBE will also translate digits to KPML in this case if the leg to CUCM has that negotiated. Wish I had a lab built out for this :)<div><br></div><div><br></div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 4:22 PM, Daniel Pagan <span dir="ltr"><<a href="mailto:dpagan@fidelus.com" target="_blank">dpagan@fidelus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Ed:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I specifically worked with the dynamic payload option for a few cases that came my way. Based on my findings, when a dynamic payload type (such as 100/101/etc.) is received by CUBE, it will check if the next-hop dial-peer has the asymmetric
payload feature enabled and, if it is, will pass the received payload type through to the next call-leg. Take a look at my screen shot below. This was taken from some old notes where AT&T was the customer’s carrier.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><img width="280" height="123" style="width:2.9166in;min-height:1.2812in" src="cid:image001.png@01D1E10B.5FFCD4F0"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The call flow above shows two call-legs, and <b>the arrows represent an offer/answer exchange</b>.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">With asymmetric payload enabled on both call legs, the 100 offer from ATT is passed to CUCM despite 101 being the default PT for NTE. In the SDP answer from CUCM, we’re getting PT 101 -- since asymmetry is enabled on the DP to ATT in this
call flow, we pass the 101 through to ATT despite having received PT 100. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This results in asymmetry on our negotiated PT for each call-leg.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="text-indent:.5in"><b>Let’s change it up a bit… A second example.<u></u><u></u></b></p>
<p class="MsoNormal" style="margin-left:.5in">If asymmetry was disabled on the dial-peer to CUCM but enabled to ATT, we would receive 100 PT from ATT, send 101 to CUCM, receive 101 from CUCM, and send 101 to ATT. The resulting PTs would be symmetrical between
CUBE and CUCM, but asymmetrical between CUBE and ATT.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">See screenshot below for a third example:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><img width="341" height="116" style="width:3.552in;min-height:1.2083in" src="cid:image003.png@01D1E10B.EA997370"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This example shows asymmetric payload disabled on both call-legs using the same call flow. CUBE receives PT of 100 from ATT -- the outbound dialpeer has asymmetry disabled, so it transmits the PT specified for that dial-peer (default 101
or any hardcoded dynamic PT) to CUCM. We then receive 101 from CUCM and, since our inbound dial-peer has asymmetry disabled, CUBE sends 100 to match the original PT it received. Asymmetry is disabled so CUBE is not passing the received dynamic PT through to
the next-hop dial-peer - we have symmetry on both call legs for our NTE PT.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Note that CUBE has no issues receiving one dynamic PT for NTE and sending another (ex: receiving PT 100 and transmitting 101 for RTP-NTE) on the same call leg.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Hope this helps<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">- Dan<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:white">--------end attach---------<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> cisco-voip [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>]
<b>On Behalf Of </b>Ed Leatherman<br>
<b>Sent:</b> Monday, July 18, 2016 3:10 PM<br>
<b>To:</b> Cisco VOIP <<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a>><br>
<b>Subject:</b> [cisco-voip] DTMF interworking on CUBE - asymmetric payloads<u></u><u></u></span></p><div><div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">I'm trying to get my head wrapped around some DTMF interworking features...<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I have this setup:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">UCM ------ CUBE ------- 3rd party system<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">For both call legs through CUBE I'm advertising kpml and rtp-nte for dtmf-relay<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The 3rd party sometimes sends me rtp payload type 101 for nte's, and no kpml, and things work (as a bonus I observed CUBE correctly interworking the nte's from the pbx into KPML, so uccx didn't break).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Sometimes they send type 98 and no kpml, and things don't work.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm trying to understand what is happening and what feature should fix it (without breaking other things)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Assumption:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">"dtmf-relay rtp-nte kpml" is telling CUBE to offer/accept rtp type 101 only for nte. I observe that CUBE negotiates KPML only for the associated call leg back to UCM and doesn't bother with rtp-nte, so its just like any other codec that
CUBE doesn't care about.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">So.. if third party system ONLY sent me dtmf-relay with payload type 98, could I just set the rtp payload type for this to 98 on the inbound dial peer? would CUBE then correctly switch these up to 101 headed back to UCM?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">How can I (or can I at all) make this work in my particular case were I could receive both?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I see "asymmetric payload dtmf" thrown about as a possible solution, but I'm having trouble understanding what it actually does. It sounds like it passes these payload types through CUBE, so UCM could be getting rtp payload type 98 - it
knows what to do with it? It seems like then CUBE wouldn't be able to translate things to KPML this way...<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm reading <a href="http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-dymc-payld-dtmf.html" target="_blank">http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-dymc-payld-dtmf.html</a>
but I guess I'm just not drinking enough coffee today (or too much) and I'm not getting what exactly this command does.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Anyone know how that asymmeteric command works?<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<p class="MsoNormal">Ed Leatherman<u></u><u></u></p>
</div>
</div>
</div>
</div></div></div>
</div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div data-smartmail="gmail_signature">Ed Leatherman<br></div>
</font></span></div>
<br></div></div>_______________________________________________<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" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<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" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div></div>