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