[cisco-voip] CUBE DTMF

[Anthony Holloway]

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/20180316/8efc2d99/attachment.html>