[cisco-voip] CUBE DTMF

[GR]

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 <avholloway+cisco-voip at gmail.com> 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 <grccie at gmail.com> 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 <avholloway+cisco-voip at gmail.com> 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 <grccie at gmail.com> 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
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180331/8a86c184/attachment.html>