[cisco-voip] DTMF interworking on CUBE - asymmetric payloads

Tue Jul 19 15:44:23 EDT 2016

I do it to, but did you know that RTP-NTE to SIP-KPML is not supported on
CUBE as of yet?

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561__table_16E37E2F33CE4E0B836D2E5A809E7252

On Mon, Jul 18, 2016 at 8:21 PM, Justin Steinberg <jsteinberg at gmail.com>
wrote:

> yes, CUBE can do RFC2833/NTP to a Telco and SIP-KPML to CUCM.   I do this
> for calls that terminate on CCX IVR since CCX does not support RFC2833.
> With only rtp-nte on the dialpeer from CUBE to CUCM, CUCM will invoke a
> MTP.   Adding sip-kpml to the dial-peer will allow RTP directly from CUBE
> to CCX without any MTP in the middle.
>
> On Mon, Jul 18, 2016 at 5:08 PM, Ed Leatherman <ealeatherman at gmail.com>
> wrote:
>
>> Thanks Daniel, that helps a lot in understanding the feature. I'm curious
>> if CUBE will also translate digits to KPML in this case if the leg to CUCM
>> has that negotiated. Wish I had a lab built out for this :)
>>
>>
>>
>> On Mon, Jul 18, 2016 at 4:22 PM, Daniel Pagan <dpagan at fidelus.com> wrote:
>>
>>> Ed:
>>>
>>>
>>>
>>> I specifically worked with the dynamic payload option for a few cases
>>> that came my way. Based on my findings, when a dynamic payload type (such
>>> as 100/101/etc.) is received by CUBE, it will check if the next-hop
>>> dial-peer has the asymmetric payload feature enabled and, if it is, will
>>> pass the received payload type through to the next call-leg. Take a look at
>>> my screen shot below. This was taken from some old notes where AT&T was the
>>> customer’s carrier.
>>>
>>>
>>>
>>>
>>>
>>> The call flow above shows two call-legs, and *the arrows represent an
>>> offer/answer exchange*.
>>>
>>>
>>>
>>> With asymmetric payload enabled on both call legs, the 100 offer from
>>> ATT is passed to CUCM despite 101 being the default PT for NTE. In the SDP
>>> answer from CUCM, we’re getting PT 101 -- since asymmetry is enabled on the
>>> DP to ATT in this call flow, we pass the 101 through to ATT despite having
>>> received PT 100.
>>>
>>>
>>>
>>> This results in asymmetry on our negotiated PT for each call-leg.
>>>
>>>
>>>
>>> *Let’s change it up a bit… A second example.*
>>>
>>> If asymmetry was disabled on the dial-peer to CUCM but enabled to ATT,
>>> we would receive 100 PT from ATT, send 101 to CUCM, receive 101 from CUCM,
>>> and send 101 to ATT. The resulting PTs would be symmetrical between CUBE
>>> and CUCM, but asymmetrical between CUBE and ATT.
>>>
>>>
>>>
>>> See screenshot below for a third example:
>>>
>>>
>>>
>>>
>>>
>>> This example shows asymmetric payload disabled on both call-legs using
>>> the same call flow. CUBE receives PT of 100 from ATT -- the outbound
>>> dialpeer has asymmetry disabled, so it transmits the PT specified for that
>>> dial-peer (default 101 or any hardcoded dynamic PT) to CUCM. We then
>>> receive 101 from CUCM and, since our inbound dial-peer has asymmetry
>>> disabled, CUBE sends 100 to match the original PT it received. Asymmetry is
>>> disabled so CUBE is not passing the received dynamic PT through to the
>>> next-hop dial-peer - we have symmetry on both call legs for our NTE PT.
>>>
>>>
>>>
>>> Note that CUBE has no issues receiving one dynamic PT for NTE and
>>> sending another (ex: receiving PT 100 and transmitting 101 for RTP-NTE) on
>>> the same call leg.
>>>
>>>
>>>
>>> Hope this helps
>>>
>>>
>>>
>>> - Dan
>>>
>>> --------end attach---------
>>>
>>>
>>>
>>> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On
>>> Behalf Of *Ed Leatherman
>>> *Sent:* Monday, July 18, 2016 3:10 PM
>>> *To:* Cisco VOIP <cisco-voip at puck.nether.net>
>>> *Subject:* [cisco-voip] DTMF interworking on CUBE - asymmetric payloads
>>>
>>>
>>>
>>> I'm trying to get my head wrapped around some DTMF interworking
>>>  features...
>>>
>>>
>>>
>>> I have this setup:
>>>
>>>
>>>
>>> UCM ------ CUBE ------- 3rd party system
>>>
>>>
>>>
>>> For both call legs through CUBE I'm advertising kpml and rtp-nte for
>>> dtmf-relay
>>>
>>>
>>>
>>> The 3rd party sometimes sends me rtp payload type 101 for nte's, and no
>>> kpml, and things work (as a bonus I observed CUBE correctly interworking
>>> the nte's from the pbx into KPML, so uccx didn't break).
>>>
>>> Sometimes they send type 98 and no kpml, and things don't work.
>>>
>>>
>>>
>>> I'm trying to understand what is happening and what feature should fix
>>> it (without breaking other things)
>>>
>>>
>>>
>>> Assumption:
>>>
>>> "dtmf-relay rtp-nte kpml" is telling CUBE to offer/accept rtp type 101
>>> only for nte. I observe that CUBE negotiates KPML only for the associated
>>> call leg back to UCM and doesn't bother with rtp-nte, so its just like any
>>> other codec that CUBE doesn't care about.
>>>
>>>
>>>
>>> So.. if third party system ONLY sent me dtmf-relay with payload type 98,
>>> could I just set the rtp payload type for this to 98 on the inbound dial
>>> peer? would CUBE then correctly switch these up to 101 headed back to UCM?
>>>
>>>
>>>
>>> How can I (or can I at all) make this work in my particular case were I
>>> could receive both?
>>>
>>> I see "asymmetric payload dtmf" thrown about as a possible solution, but
>>> I'm having trouble understanding what it actually does. It sounds like it
>>> passes these payload types through CUBE, so UCM could be getting rtp
>>> payload type 98 - it knows what to do with it? It seems like then CUBE
>>> wouldn't be able to translate things to KPML this way...
>>>
>>>
>>>
>>> I'm reading
>>> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-dymc-payld-dtmf.html
>>> but I guess I'm just not drinking enough coffee today (or too much) and I'm
>>> not getting what exactly this command does.
>>>
>>>
>>>
>>> Anyone know how that asymmeteric command works?
>>>
>>>
>>>
>>> --
>>>
>>> Ed Leatherman
>>>
>>
>>
>>
>> --
>> Ed Leatherman
>>
>> _______________________________________________
>> 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/20160719/256a48d3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 8218 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160719/256a48d3/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2755 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160719/256a48d3/attachment-0001.png>