[cisco-voip] DTMF interworking on CUBE - asymmetric payloads

Fri Sep 30 12:32:01 EDT 2016

>From that defect:

"Use CUCM MTPs instead of ASR/ISR4K MTPs for media termination points in
CUCM"

Wow.  That's got to be a first.  Recommending CUCM MTP over IOS MTP.

On Thu, Sep 29, 2016 at 9:52 PM, Joshua Warcop <josh at warcop.com> 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<avholloway+cisco-
> voip at gmail.com> wrote ----
>
> So, what dtmf setup did you go with then, Alan?
>
> On Thu, Sep 29, 2016 at 6:33 PM, Alan Libbee <alan.libbee at umuc.edu> 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" <bmeade90 at vt.edu> 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 <jsteinberg at gmail.com>
> 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 <
> avholloway+cisco-voip at gmail.com> 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 <jsteinberg at gmail.com>
> 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 <ealeatherman at gmail.com>
> 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 <dpagan at fidelus.com> 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:cisco-voip-bounces at puck.nether.net] *On Behalf
> Of *Ed Leatherman
> *Sent:* Monday, July 18, 2016 3:10 PM
> *To:* Cisco VOIP <cisco-voip at puck.nether.net>
> *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
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160930/c21a0ae1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.png
Type: image/png
Size: 8218 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160930/c21a0ae1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.png
Type: image/png
Size: 2755 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160930/c21a0ae1/attachment-0001.png>