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 <[email protected]> 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:[email protected]] *On Behalf > Of *Ed Leatherman > *Sent:* Monday, July 18, 2016 3:10 PM > *To:* Cisco VOIP <[email protected]> > *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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
