Yeah - it was initially rtp-nte only (both internal and provider facing) but some sites could only do out of band and I wanted to steer clear of using MTPs - so added kpml on top of rtp nte. It works fine now and without the need for mtp.
Sent from my iPhone > On 31 Mar 2018, at 2: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
