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

Thu Sep 29 17:53:08 EDT 2016

Ok, so then what's your OOB play now?  Notify (Cisco proprietery) or Info
(Standards based)?  I am not excited about RTP-NTE end to end, and its
requirement for an MTP on certain call flows (E.g., UCCX call flows).

On Thu, Sep 29, 2016 at 2:59 PM, Brian Meade <bmeade90 at vt.edu> wrote:

> Bringing up this old thread as I've been doing RTP-NTE to SIP-KPML on a
> lot of setups but finally ran into an issue with intermittently digits not
> being converted from KPML to RTP-NTE.  The debugs showed the DTMF-relay
> conversion being done and the digits being sent through RTP-NTE but packet
> capture shows some digits not making it onto the wire.
>
> TAC shut it down and said this is one of the caveats and why this isn't
> fully supported.
>
> So just FYI for everyone on why it's apparently officially not supported
> without a transcoder.
>
> On Tue, Jul 19, 2016 at 4:28 PM, Justin Steinberg <jsteinberg at gmail.com>
> wrote:
>
>> interesting - i wonder why that is not supported when it works.  doc
>> error or some legit technical issue ?
>>
>> On Tue, Jul 19, 2016 at 3:44 PM, Anthony Holloway <
>> avholloway+cisco-voip at gmail.com> wrote:
>>
>>> 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_26461791992
>>> 1874995299551391601561__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/voi
>>>>>> ce/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
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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/20160929/3da629a3/attachment.html>
-------------- 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/20160929/3da629a3/attachment.png>
-------------- 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/20160929/3da629a3/attachment-0001.png>