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
