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] > <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] > https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
