Is there a reason you'd like to stick to kpml? Why not try unsolicited notify and avoid using mtp? Also what IOS version is this?
On Sep 30, 2016 8:43 AM, "Alan Libbee" <[email protected]> wrote: > I ended up doing the Joshua plan, forcing an MTP for all calls to UCCX. I > share in your frustration that this is an issue because it almost works > perfectly. > > On Sep 29, 2016 10:52 PM, "Joshua Warcop" <[email protected]> wrote: > >> Is this on a 4K or ASR router? Until some of these things are worked out >> I think it's a safe assumption that MTP for DTMF interworking is going to >> be a requirement for CTI routes. Unresolved bug CSCtw50974 is an >> example. >> >> 2900/3900 IOS doesn't seem to exhibit some of these problems. >> >> >> ---- On Thu, 29 Sep 2016 22:42:48 -0400 Anthony Holloway< >> [email protected]> wrote ---- >> >> 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_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 >> >> >> _______________________________________________ >> 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
