[cisco-voip] CUBE DTMF

Sat Mar 31 22:42:31 EDT 2018

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 <kent at fredf.org> 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 <
> avholloway+cisco-voip at gmail.com> 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 <kent at fredf.org> wrote:
>
>> Put the NTE first, or if you can only use NTE.
>>
>>
>> On Mar 30, 2018, at 9:10 PM, GR <grccie at gmail.com> 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 <
>> 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
>>>>
>>> _______________________________________________
>> 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/20180401/e0a70d3c/attachment.html>