DTMF Interworking when Transcoding

[eric.butcher]

I currently have an enterprise sip solution from a provider that offers only g711 and only RFC2833 for DTMF.

Calls from this provider come in via 3945E CUBE with locally registered transcoder profile with RFC2833 and then are sent on to CUCM with the DTMF switched to sip-notify.

All calls on this solution ring in to UCCX in g711 mode.

Some of our agents are at remote sites with bandwidth constraints requiring the use of g729, and after a caller makes it through our IVR system and is routed to one of these remote agents, the CUBE invokes a transcoder session for the duration of the call.

In some cases, at the end of a call, our agent will need to transfer the caller back into our IVR system to make credit card payments.  When this happens, since the transcoder stays in place once invoked, we lose our DTMF Interworking between RFC2833 and sip-notify.

Does anybody know how to remedy this?

The CUBE is using RTP-RTP Flowthrough and here is a breakdown of the call:

PSTN => Telco =SIP(g711)=> CUBE =SIP(g711)=> CUCM =JTAPI=>UCCX - No transcoding yet, DTMF works.

Upon transfer to agent, the call becomes:

PSTN => Telco =SIP(g711)=> CUBE(xcoder) =SIP(g729)=> CUCM =SCCP=> Agent Phone - Transcoding active

When the agent transfers the call back into the IVR:

PSTN => Telco =SIP(g711)=> CUBE(xcoder) =SIP(g711)=> CUCM =JTAPI=> UCCX - Transcoder still in the call path, no DTMF

Will placing an MTP in here somewhere resolve this issue?  If so, does it have to be on every call or will it invoke the MTP when needed?

[eric.butcher]

Also:

06352978.010 |09:58:08.960 |AppInfo  |DET-MediaManager-(15263)::isMTPNeededForMismatchOrConfig, MTPNeededDueToDTMFCapMismatch(2833/OOB) mtpinsertionReason=1 dtmfMTPSide=2

10.5.2 still has that one... but only when an MTP is actually needed.  The above is from a call between the aforementioned "remote office" placing outbound calls through a remote SIP gateway.  In this case, an outbound call is being made from an SCCP device to the CUBE and it is not coming up with acceptable DTMF.  Since we don't do outbound on this sip except in this special (and temporary) circumstance, I'm not concerned about it.

[eric.butcher]

I did just find this:

https://tools.cisco.com/bugsearch/bug/CSCuu90195

I'm running 15.4(3)M3

The release notes show this as fixed in 15.4(3)M4 and the bug info itself shows fixed in 15.4(3)M3.1 (not even sure what that is...)

I suspect this might be what I was running into, but it doesn't explain why my interworking appears to be functioning for a Source/Destination DTMF type that isn't listed in the "supported" table.

[Ayodeji Okanlawon]

Eric,( +10 for this outstanding effort)

First of all hats off to you for the brilliant effort you are putting into this to get to the bottom of it. People like you inspire me and make me proud of my trade.

This bug isnt affecting you. The bug states that CUBE sends rtp-nte in the 200 OK for the re-INVITE. In this bug CUBE sends call-info and specify DTMF method as "NOTIFY". So everything looks okay from a signalling perspective.

My earlier comments was actually wrong because I didnt consider the fact the you were using NOTIFY and in which case we dont see the DTMF attributes for it in SDP we actually see it in the call-info header. Though I am glad it led us to the solution. :)

[eric.butcher]

Thx.

There is a ReInvite based transfer carried out, which results in CUBE receiving Delayed Offer mid-call Invite with Call-Info header containing NOTIFY.
When CUBE sends 200 OK with Offer, it responds with Call-Info header containing NOTIFY along with SDP containing RTP-NTE for DTMF.
Upon receiving ACK with Answer-SDP without RTP-NTE, CUBE should assume SIP-NOTIFY as negotiated DTMF mechanism

My read of this is that the CUBE sends the 200 OK with sdp (with RTP-NTE) + call-info header (for Sip-notify), then gets back an ACK from the remote end (in this case, CUCM for the UCCX endpoint) with SDP that doesn't contain the RTP-NTE, it ignores the fact that the Call-Info header was there fore Notify and falls back to no-DTMF when it should assume SIP-NOTIFY.

Looking back over the SIP messages, I see that my CUBE is only sending the Call-info header, and not the rtp-nte sdp part... but I also see CUCM sending back this:

Allow-Events: presence, kpml

And

Allow-Events: presence

At various times.  Its like CUCM doesn't want to accept sip-notify.

I'm going to end up having to open a TAC case.  CUCM shouldn't be supporting KPML for this transaction per the documentation, but it is clearly working without an MTP.

The issue is technically fixed but I'm far from comfortable with the "why".

[Ayodeji Okanlawon]

Eric,

Yes please do. But you could check in cucm trace to see why MTP was not invoked as I suggested earlier..Please keep us updated.