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.
> On Mar 31, 2018, at 1:16 AM, GR <[email protected]> wrote: > > 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. > > Sent from my iPhone > > On 31 Mar 2018, at 2:38 pm, Kent Roberts <[email protected] > <mailto:[email protected]>> wrote: > >> Put the NTE first, or if you can only use NTE. >> >>> On Mar 30, 2018, at 9:10 PM, GR <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Thx Anthony. Just an update, did that and interworking works fine between >>> kpml and rtp nte. >>> >>> 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. >>> >>> Sent from my iPhone >>> >>> On 17 Mar 2018, at 5:08 am, Anthony Holloway >>> <[email protected] <mailto:[email protected]>> >>> wrote: >>> >>>> 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. >>>> >>>> On Fri, Mar 16, 2018 at 12:33 AM GR <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> 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. >>>> >>>> >>>> Sent from my iPhone >>>> >>>> On 16 Mar 2018, at 2:10 am, Anthony Holloway >>>> <[email protected] <mailto:[email protected]>> >>>> wrote: >>>> >>>>> 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. >>>>> >>>>> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561 >>>>> >>>>> <https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561> >>>>> >>>>> 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. >>>>> >>>>> Citations from that link: >>>>> >>>>> "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." >>>>> >>>>> "If you configure more than one out-of-band DTMF method, preference goes >>>>> from highest to lowest in the order of configuration." >>>>> >>>>> "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." >>>>> >>>>> "CUBE selects DTMF relay mechanisms using the following priority: >>>>> sip-notify or sip-kpml (highest priority) >>>>> rtp-nte >>>>> None—Send DTMF in-band" >>>>> 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. >>>>> >>>>> On Thu, Mar 15, 2018 at 8:44 AM GR <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> Hi Guys, >>>>> >>>>> 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) >>>>> >>>>> Randomly one of the MGCP/h323 gateway is having issues, where it only >>>>> supports OOB and then further complications trying to resolve the problem. >>>>> >>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> Thanks >>>>> GR >>>>> >>>>> >>>>> >>>>> >>>>> Sent from my iPhone >>>>> _______________________________________________ >>>>> cisco-voip mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>>> <https://puck.nether.net/mailman/listinfo/cisco-voip> >>> _______________________________________________ >>> cisco-voip mailing list >>> [email protected] <mailto:[email protected]> >>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> <https://puck.nether.net/mailman/listinfo/cisco-voip> >>
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
