<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">One thing to watch out for, or keep in the back of your mind. Do you know if your carrier will route customer to customer calls on net? I had an issue with a carrier. One of their customers only did G711 and we offered G729 to start, and it would kill the call, since the vendor didn’t normalize the calls between their customers.<div class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 31, 2018, at 1:16 AM, GR <<a href="mailto:grccie@gmail.com" class="">grccie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">Yeah - it was initially rtp-nte only (both internal and provider facing) but some sites could only do out of band and I wanted to steer clear of using MTPs - so added kpml on top of rtp nte. It works fine now and without the need for mtp. <div class=""><br class=""><div class="">Sent from my iPhone</div><div class=""><br class="">On 31 Mar 2018, at 2:38 pm, Kent Roberts <<a href="mailto:kent@fredf.org" class="">kent@fredf.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">Put the NTE first, or if you can only use NTE.<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 30, 2018, at 9:10 PM, GR <<a href="mailto:grccie@gmail.com" class="">grccie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">Thx Anthony. Just an update, did that and interworking works fine between kpml and rtp nte. <div class=""><br class=""></div><div class="">Was enquiring abt digit drop to follow a proactive approach rather than reactive. So far its ok without that - but I still have few pending sites so not implemented globally yet. <br class=""><br class=""><div class="">Sent from my iPhone</div><div class=""><br class="">On 17 Mar 2018, at 5:08 am, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" class="">avholloway+cisco-voip@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">I have had to add digit-drop to the dial-peers when calls were heading to CUC, but not 100% of the time. As with a lot of things, don't configure something just to configure it. Know that it's needed first, then configure it. Else you end up with this giant configuration that you cannot explain half of what its doing.</div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Mar 16, 2018 at 12:33 AM GR <<a href="mailto:grccie@gmail.com" class="">grccie@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="">Thanks Anthony. So no need to configure digit drop ? Even if I am doing RFC2833 on one leg and advertise both Inband and OOB on second leg. <div class=""><br class=""><br class=""><div id="m_-1079940384260945231AppleMailSignature" class="">Sent from my iPhone</div></div></div><div dir="auto" class=""><div class=""><div class=""><br class="">On 16 Mar 2018, at 2:10 am, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank" class="">avholloway+cisco-voip@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">I was going to mention that CUBE doesn't support rtp-nte to sip-kpml interworking. Weird, I know. But that's how it was. However, when I went to grab the link for my source, the table has been updated, and I see that this is now supported.<div class=""><br class=""></div><div class=""><a href="https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561" target="_blank" class="">https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561</a></div><div class=""><br class=""></div><div class="">Therefore, I see no gotchas with enabling....well...maybe one gotcha. If you enable both RTP-NTE and SIP-KPML on a dial-peer, note that CUBE will advertise both, and the offer answer model dictates that CUBE will then not be able to choose or control the DTMF relay selected. However, when CUBE receives an offer with multiple relays in it, it will choose which to use based on order....maybe.</div><div class=""><br class=""></div><div class="">Citations from that link:</div><div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="">"If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are negotiated successfully, NOTIFY-based out-of-band DTMF relay takes precedence."</div><div class=""><br class=""></div><div class="">"If you configure more than one out-of-band DTMF method, preference goes from highest to lowest in the order of configuration."</div><div class=""><br class=""></div><div class="">"CUBE negotiates both rtp-nte and sip-kpml if both are supported and advertised in the incoming INVITE. However, CUBE relies on the rtp-nte DTMF method to receive digits and a SUBSCRIBE if sip-kpml is not initiated. CUBE still accepts SUBSCRIBEs for KPML. This prevents double-digit reporting problems at CUBE."</div><div class=""><br class=""></div><div class=""><div class="">"CUBE selects DTMF relay mechanisms using the following priority:</div></div></blockquote><div class=""><div class=""><ul class=""><ul class=""><li class="">sip-notify or sip-kpml (highest priority)</li><li class="">rtp-nte</li><li class="">None—Send DTMF in-band"</li></ul></ul></div></div><div class="">I recommend to read that entire document, or at least the chapter I linked, because it has some good info on it. Of course, you'll want to test everything, because it's not out of reason to have to file a documentation defect.<br class=""></div><div class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Mar 15, 2018 at 8:44 AM GR <<a href="mailto:grccie@gmail.com" target="_blank" class="">grccie@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Guys,<br class="">
<br class="">
I am having an issue with SIP provider only supporting rfc2833. The CUBEs are configured only for rtp-nte on all dial-peers facing both the provider and the CUCM internal network (multiple clusters)<br class="">
<br class="">
Randomly one of the MGCP/h323 gateway is having issues, where it only supports OOB and then further complications trying to resolve the problem.<br class="">
<br class="">
I am planning to add sip kpml as well on top of rtp-nte to advertise both inband and outofband DTMF methods towards our internal CUCM network and let CUBE do inter-working in case where one leg is rfc2833 (carrier side) and other is kpml(internal network lets say MGCP gateway). Trying to stay away from MTPs.<br class="">
<br class="">
Any gotchas if I just go ahead and add kpml on top of existing rtp-nte method (on CUBE dial-peers facing our internal network) as I don’t want to break the setup where only inband is supported, hard to check in a global deployment.<br class="">
<br class="">
Any need to use digit-drop in case both inband and out of band digits are sent? If required it will be only on dial-peers facing CUCM side? Or this is not required as the provider only supports rfc2833.<br class="">
<br class="">
Thanks<br class="">
GR<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
Sent from my iPhone<br class="">
_______________________________________________<br class="">
cisco-voip mailing list<br class="">
<a href="mailto:cisco-voip@puck.nether.net" target="_blank" class="">cisco-voip@puck.nether.net</a><br class="">
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank" class="">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br class="">
</blockquote></div></div></div></div>
</div></blockquote></div></div></blockquote></div>
</div></blockquote></div></div>_______________________________________________<br class="">cisco-voip mailing list<br class=""><a href="mailto:cisco-voip@puck.nether.net" class="">cisco-voip@puck.nether.net</a><br class=""><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" class="">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div></div></div></blockquote></div><br class=""></div></body></html>