So, what dtmf setup did you go with then, Alan? On Thu, Sep 29, 2016 at 6:33 PM, Alan Libbee <[email protected]> wrote:
> 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_264617919921 >>>> 874995299551391601561__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 > >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
