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" <[email protected]> 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 <[email protected]> > 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 < >> [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_26461791992 >>> 1874995299551391601561__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/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 >>>>> [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 >> >> > > _______________________________________________ > 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
