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
