Depends on the device capabilities involved in the call. What I'm saying is, limiting your DTMF to inband only is a bad idea, and opening it up to OOB as well as inband is a better idea. Since most CTI based applications, which includes call center, do not support Inband DTMF, you will be invoking MTPs for those calls flows, 100% of the time.
On Sat, Mar 31, 2018 at 8:28 PM Kent Roberts <[email protected]> wrote: > 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
