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

[Ed Leatherman]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160718/ee532fd8/attachment.html>