Mailing List Archive

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
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
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.

[cid:image001.png@01D1E10B.5FFCD4F0]

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:

[cid:image003.png@01D1E10B.EA997370]

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@puck.nether.net] On Behalf Of Ed Leatherman
Sent: Monday, July 18, 2016 3:10 PM
To: Cisco VOIP <cisco-voip@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
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
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@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@puck.nether.net] *On Behalf
> Of *Ed Leatherman
> *Sent:* Monday, July 18, 2016 3:10 PM
> *To:* Cisco VOIP <cisco-voip@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
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
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@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@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@puck.nether.net] *On
>> Behalf Of *Ed Leatherman
>> *Sent:* Monday, July 18, 2016 3:10 PM
>> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
Thanks Justin. My concern is with nte's coming in a mix of different
payload types depending on the end point. Since it seems I can only specify
one payload type for them, when I get an offer using a different value,
CUBE doesn't include it in the answer. And then no interworking happens
since we didnt' successfully negotiate a DTMF relay method at all. I'm
hoping with the asymmteric payload feature that cube will negotiate and
pass through the dynamic payload type and also actually look at the packets
and interwork them to kpml. The more I think about it the less likely it
sounds, but I may as well try it.

I think what I really need for it to do is just negotiate EITHER 101 or 98
for dtmf relay out to the 3rd party, but i'm stumped on if/how to make that
work.

On Mon, Jul 18, 2016 at 9:21 PM, Justin Steinberg <jsteinberg@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@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@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@puck.nether.net] *On
>>> Behalf Of *Ed Leatherman
>>> *Sent:* Monday, July 18, 2016 3:10 PM
>>> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>


--
Ed Leatherman
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
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@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@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@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@puck.nether.net] *On
>>> Behalf Of *Ed Leatherman
>>> *Sent:* Monday, July 18, 2016 3:10 PM
>>> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
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@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_264617919921874995299551391601561__table_16E37E2F33CE4E0B836D2E5A809E7252
>
> On Mon, Jul 18, 2016 at 8:21 PM, Justin Steinberg <jsteinberg@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@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@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@puck.nether.net] *On
>>>> Behalf Of *Ed Leatherman
>>>> *Sent:* Monday, July 18, 2016 3:10 PM
>>>> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
It's likely along the same lines as NAT and Finesse for CCX. It works and
people do it fairly often but TAC won't support it because it hasn't been
thouroghly tested for issues and full functionality.

On Jul 19, 2016 2:29 PM, "Justin Steinberg" <jsteinberg@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@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_264617919921874995299551391601561__table_16E37E2F33CE4E0B836D2E5A809E7252
>>
>> On Mon, Jul 18, 2016 at 8:21 PM, Justin Steinberg <jsteinberg@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@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@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@puck.nether.net] *On
>>>>> Behalf Of *Ed Leatherman
>>>>> *Sent:* Monday, July 18, 2016 3:10 PM
>>>>> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
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@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@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_
>> 264617919921874995299551391601561__table_16E37E2F33CE4E0B836D2E5A809E7252
>>
>> On Mon, Jul 18, 2016 at 8:21 PM, Justin Steinberg <jsteinberg@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@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@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@puck.nether.net] *On
>>>>> Behalf Of *Ed Leatherman
>>>>> *Sent:* Monday, July 18, 2016 3:10 PM
>>>>> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
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@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@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@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@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@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@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@puck.nether.net] *On
>>>>>> Behalf Of *Ed Leatherman
>>>>>> *Sent:* Monday, July 18, 2016 3:10 PM
>>>>>> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
I have run in to the very same issue. It seems that it works fine on a
direct inbound and outbound call, but if an incoming call comes in and is
transferred to a uccx application, the first DTMF digit fails after the
transfer. We took debugs and tac confirmed the same, it is not a
supported configuration.

On Sep 29, 2016 3:59 PM, "Brian Meade" <bmeade90@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@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@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@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@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@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@puck.nether.net] *On
>>>>>> Behalf Of *Ed Leatherman
>>>>>> *Sent:* Monday, July 18, 2016 3:10 PM
>>>>>> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
So, what dtmf setup did you go with then, Alan?

On Thu, Sep 29, 2016 at 6:33 PM, Alan Libbee <alan.libbee@umuc.edu> wrote:

> I have run in to the very same issue. It seems that it works fine on a
> direct inbound and outbound call, but if an incoming call comes in and is
> transferred to a uccx application, the first DTMF digit fails after the
> transfer. We took debugs and tac confirmed the same, it is not a
> supported configuration.
>
> On Sep 29, 2016 3:59 PM, "Brian Meade" <bmeade90@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@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@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_264617919921
>>>> 874995299551391601561__table_16E37E2F33CE4E0B836D2E5A809E7252
>>>>
>>>> On Mon, Jul 18, 2016 at 8:21 PM, Justin Steinberg <jsteinberg@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@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@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@puck.nether.net] *On
>>>>>>> Behalf Of *Ed Leatherman
>>>>>>> *Sent:* Monday, July 18, 2016 3:10 PM
>>>>>>> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip@puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
Is this on a 4K or ASR router? Until some of these things are worked out I think it's a safe assumption that MTP for DTMF interworking is going to be a requirement for CTI routes. Unresolved bug CSCtw50974 is an example. 2900/3900 IOS doesn't seem to exhibit some of these problems. ---- On Thu, 29 Sep 2016 22:42:48 -0400 Anthony Holloway<avholloway+cisco-voip@gmail.com> wrote ----So, what dtmf setup did you go with then, Alan?On Thu, Sep 29, 2016 at 6:33 PM, Alan Libbee <alan.libbee@umuc.edu> wrote:I have run in to the very same issue. It seems that it works fine on a direct inbound and outbound call, but if an incoming call comes in and is transferred to a uccx application, the first DTMF digit fails after the  transfer. We took   debugs and tac confirmed the same, it is not a supported configuration. On Sep 29, 2016 3:59 PM, "Brian Meade" <bmeade90@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@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@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_264617919921874995299551391601561__table_16E37E2F33CE4E0B836D2E5A809E7252On Mon, Jul 18, 2016 at 8:21 PM, Justin Steinberg <jsteinberg@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@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@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@puck.nether.net] On Behalf Of Ed Leatherman Sent: Monday, July 18, 2016 3:10 PM To: Cisco VOIP <cisco-voip@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
I ended up doing the Joshua plan, forcing an MTP for all calls to UCCX. I
share in your frustration that this is an issue because it almost works
perfectly.

On Sep 29, 2016 10:52 PM, "Joshua Warcop" <josh@warcop.com> wrote:

> Is this on a 4K or ASR router? Until some of these things are worked out I
> think it's a safe assumption that MTP for DTMF interworking is going to be
> a requirement for CTI routes. Unresolved bug CSCtw50974 is an example.
>
> 2900/3900 IOS doesn't seem to exhibit some of these problems.
>
>
> ---- On Thu, 29 Sep 2016 22:42:48 -0400 Anthony Holloway<avholloway+cisco-
> voip@gmail.com> wrote ----
>
> So, what dtmf setup did you go with then, Alan?
>
> On Thu, Sep 29, 2016 at 6:33 PM, Alan Libbee <alan.libbee@umuc.edu> wrote:
>
> I have run in to the very same issue. It seems that it works fine on a
> direct inbound and outbound call, but if an incoming call comes in and is
> transferred to a uccx application, the first DTMF digit fails after the
> transfer. We took debugs and tac confirmed the same, it is not a
> supported configuration.
>
> On Sep 29, 2016 3:59 PM, "Brian Meade" <bmeade90@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@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@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_
> 264617919921874995299551391601561__table_16E37E2F33CE4E0B836D2E5A809E7252
>
> On Mon, Jul 18, 2016 at 8:21 PM, Justin Steinberg <jsteinberg@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@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@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@puck.nether.net] *On Behalf
> Of *Ed Leatherman
> *Sent:* Monday, July 18, 2016 3:10 PM
> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
Is there a reason you'd like to stick to kpml? Why not try unsolicited
notify and avoid using mtp?
Also what IOS version is this?

On Sep 30, 2016 8:43 AM, "Alan Libbee" <alan.libbee@umuc.edu> wrote:

> I ended up doing the Joshua plan, forcing an MTP for all calls to UCCX. I
> share in your frustration that this is an issue because it almost works
> perfectly.
>
> On Sep 29, 2016 10:52 PM, "Joshua Warcop" <josh@warcop.com> wrote:
>
>> Is this on a 4K or ASR router? Until some of these things are worked out
>> I think it's a safe assumption that MTP for DTMF interworking is going to
>> be a requirement for CTI routes. Unresolved bug CSCtw50974 is an
>> example.
>>
>> 2900/3900 IOS doesn't seem to exhibit some of these problems.
>>
>>
>> ---- On Thu, 29 Sep 2016 22:42:48 -0400 Anthony Holloway<
>> avholloway+cisco-voip@gmail.com> wrote ----
>>
>> So, what dtmf setup did you go with then, Alan?
>>
>> On Thu, Sep 29, 2016 at 6:33 PM, Alan Libbee <alan.libbee@umuc.edu>
>> wrote:
>>
>> I have run in to the very same issue. It seems that it works fine on a
>> direct inbound and outbound call, but if an incoming call comes in and is
>> transferred to a uccx application, the first DTMF digit fails after the
>> transfer. We took debugs and tac confirmed the same, it is not a
>> supported configuration.
>>
>> On Sep 29, 2016 3:59 PM, "Brian Meade" <bmeade90@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@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@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@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@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@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@puck.nether.net] *On
>> Behalf Of *Ed Leatherman
>> *Sent:* Monday, July 18, 2016 3:10 PM
>> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
I'm not sure yet. I was using Unsolicited Notify originally but had issues
with that not working after transfers. TAC said Unsolicited Notify isn't
supported on SIP Trunks unless you have the DTMF Preference hard set to
"OOB and RFC2833" which still forces an MTP since I'm not advertising
RTP-NTE.

On Thu, Sep 29, 2016 at 5:53 PM, Anthony Holloway <
avholloway+cisco-voip@gmail.com> wrote:

> 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@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@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@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_264617919921
>>>> 874995299551391601561__table_16E37E2F33CE4E0B836D2E5A809E7252
>>>>
>>>> On Mon, Jul 18, 2016 at 8:21 PM, Justin Steinberg <jsteinberg@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@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@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@puck.nether.net] *On
>>>>>>> Behalf Of *Ed Leatherman
>>>>>>> *Sent:* Monday, July 18, 2016 3:10 PM
>>>>>>> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip@puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
Re: DTMF interworking on CUBE - asymmetric payloads [ In reply to ]
From that defect:

"Use CUCM MTPs instead of ASR/ISR4K MTPs for media termination points in
CUCM"

Wow. That's got to be a first. Recommending CUCM MTP over IOS MTP.

On Thu, Sep 29, 2016 at 9:52 PM, Joshua Warcop <josh@warcop.com> wrote:

> Is this on a 4K or ASR router? Until some of these things are worked out I
> think it's a safe assumption that MTP for DTMF interworking is going to be
> a requirement for CTI routes. Unresolved bug CSCtw50974 is an example.
>
> 2900/3900 IOS doesn't seem to exhibit some of these problems.
>
>
> ---- On Thu, 29 Sep 2016 22:42:48 -0400 Anthony Holloway<avholloway+cisco-
> voip@gmail.com> wrote ----
>
> So, what dtmf setup did you go with then, Alan?
>
> On Thu, Sep 29, 2016 at 6:33 PM, Alan Libbee <alan.libbee@umuc.edu> wrote:
>
> I have run in to the very same issue. It seems that it works fine on a
> direct inbound and outbound call, but if an incoming call comes in and is
> transferred to a uccx application, the first DTMF digit fails after the
> transfer. We took debugs and tac confirmed the same, it is not a
> supported configuration.
>
> On Sep 29, 2016 3:59 PM, "Brian Meade" <bmeade90@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@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@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_
> 264617919921874995299551391601561__table_16E37E2F33CE4E0B836D2E5A809E7252
>
> On Mon, Jul 18, 2016 at 8:21 PM, Justin Steinberg <jsteinberg@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@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@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@puck.nether.net] *On Behalf
> Of *Ed Leatherman
> *Sent:* Monday, July 18, 2016 3:10 PM
> *To:* Cisco VOIP <cisco-voip@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>