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_264617919921874995299551391601561__table_16E37E2F33CE4E0B836D2E5A809E7252On
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
_______________________________________________ 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
