[cisco-voip] CUBE DTMF

[Anthony Holloway]

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/20180315/6573732b/attachment.html>