[cisco-voip] CUBE DTMF

[Anthony Holloway]

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/4c0c0623/attachment.html>