Interesting. Hundreds of millions of never saw that issue. I wonder if that was a carrier specific setting. Cause they did some really screwy things that I haven’t seen with other carriers
Kent > On Mar 31, 2018, at 18:56, Anthony Holloway <[email protected]> > wrote: > > Don't do that. That's a sure fire way to invoking MTPs for flows that don't > need it, when your CUBE will happily inter-work Inband to OOB. > >> On Fri, Mar 30, 2018 at 10:38 PM Kent Roberts <[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]> 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]> 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]> 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]> 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 >>>>>> >>>>>> 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]> 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] >>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> _______________________________________________ >>> cisco-voip mailing list >>> [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-voip >>
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
