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
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
