There's a lot of documentation about in-band audio DTMF interworking with SIP including these, which I have already read:
- DTMF relay and interworking on CUBE: https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/200412-DTMF-Relay-and-Interworking-on-CUBE.html#anc12
- CUBE fundamental and basic setup - DTMF relay: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html
But I yet haven't find a configuration which allows to support everything.
Here's the situation:
1- The UCCX only accepts Out-Of-Band DTMF
2- The CUCM is connected to an ITSP which requires RFC 2833 DTMF (so inband DTMF with DTMF information in the payload)
3- Some rare people are dialing in to the Call Center number and sending inband audio G.711 DTMF (so inband DTMF with no DTMF information in the payload)
---------Calls described in point #3 fail.
Taking packet capture on the CUBE I can confirm using Wireshark that calls coming in using with RFC 2833 compliant DTMFs are handled properly by the CUBE/CUCM/UCCX configuration.
Incoming calls with inband audio G.711 DTMF are not understood by the CUBE/CUCM/UCCX configuration.
Now here is the incompatibility:
A) The carrier, as mentioned in (2) requires RFC 2833. So on the CUBE, on both the incoming dialpeer from the ITSP and the outgoing dialpeer to the CUCM the "dtmf-relay rtp-nte" must be configured for those DTMF to be handled.
B) Reading Cisco documentation about "DTMF interworking between Inband G711 to RFC2833, it says:
"The dial-peer for the inband-tones leg must not have any DTMF relay command configured"
The requirement "Transcoding resources must be available and registered with the CUBE accordingly" are covered.
But based on information A and B the two requirements are incompatible.
I tried to change the ITSP side dialpeer to remove dtmf-relay but then all the RFC2833 compliant calls' DTMF are never understood.
I was thinking of adding a second incoming dial-peer from the ITSP to the CUBE without the dtmf-relay but how would that work? How would the system know which dial-peer to go through?
Still, I can't believe this is the only environment on earth having an ITSP requiring RFC2833 DTMF and some callers still on old systems sending inband audio G.711 DTMF.
Thank you in advance for ideas.
Thank you very much for replying.
1- That I understand
2- I agree but that's how most people calls it so...
3- It does in the way that the carrier explicitly says that they do not deal with inband audio G711 DTMF, that their requirement is RFC2833 and the callers and my customer UC infrastructure must comply or do the conversion themselves. So if someone outside of their network doing inband audio G711 DTMF passes by their network to reach my customer Call Center, they won't make the interworking themselves.
Regarding the CUBE's interworking requirements, I understand them and comply with the #1 you mention but can't comply with the #2 because of the carrier requirement...
The problem is that there's no pattern and people dialing in are individuals or very small businesses so it could be anyone and come from anywhere. We we wouldn't know in advance, we would have to wait for them to complain to add a specific dialpeer for them so that it works the second time they call.... totally unpractical.
And regarding talking to the carrier, yes we did, and as I mentioned above they say they only support RFC2833 and won't do the interworking if someone from outside of their network (on another carrier and non SIP service) calls in with inband audio G711 DTMF.
Basically reading you, you are confirming my analysis and that in the current situation there's no solution, are you?
Or does anyone else has a magic trick?
Thank you again for taking the time to reply.
I can create individual dialpeer matching incoming individual E.164 number. The problem is that we have to wait for such callers sending in-band audio G.711 DTMF to call the Call Center, complain that DTMF is not working for us to know that we have to create a specific dial-peer for that caller for the next time she/he calls in.
But as everyone is moving to SIP, if one of this caller switch to an RFC2833 compliant SIP service then - because of the specific dial-peer created for that caller without dtmf-relay - DTMF will fail again. That won't give a great image of my customer Call Center to their customer...
It seems to me that their's no really good solution other than replacing the Cisco CUBE by a non Cisco SBC which can support both interworking of in-band audio G.711 DTMF to RFC2833 dtmf and relay RFC2833 DTMF on the same incoming SIP strunk.
There must be something out there as again this is not the only UCCX Call Center in the world having to deal with this problem.
Out of curiosity, on the CUCM side configuration of the CUBE-CUCM SIP trunk, would changing the "DTMF Signaling Method" from "RFC2833 and OOB" to "No preference" be of any help ?
I'm sure I've played with that though, but I tried so many combination that I lost track...
Maybe I should ask the question differently.
If the CUBE ITSP-facing ingress dial-peer can't do both in-band audio G.711 DTMF and RFC2833, and is set for "dtmf-relay rtp-nte", the in-band audio DTMF will still be carried within the audio RTP.
Can't then the CUCM detect (I mean it obviously can from the SIP INVITE header+SDP information, the question does it) that the call was not RFC2833 or OOB and then allocate MTP resources to do the conversion?
Just one last question to be sure, you are saying that the CUCM won't help, but if we configure the SIP trunk between the CUBE and the CUCM to force MTP resources and in the MRGL applied to the SIP trunk only include transcoding resources configured on the CUCM, wouldn't that force the the RTP to go through transcoding resources running on the CUCM which would catch those in-band audio DTMF code and transcode them ? Or even in this configuration the CUCM transcoding resources would not do this type of interworking ?
Thank you in advance.
I had a similar problem and could help here.
My setup is much smaller and doesn't involve CUCM nor UCCX. It's just a CME with auto-attendant application.
In my case, the ITSP changed the DTMF encoding from RFC 2833 to inband G711 audio for all calls. Don't ask why, they just did and from that point, the AA application didn't accept any DTMF, hence it didn't forward any call to the proper queue.
So after a lot of research including this topic, I found that a transcoder might be able to translate between the two encoding types. Inband G711 --> RFC2833
CUBE is able to interwork between Inband G711 DTMF (raw audio tones) to RFC2833. However, these requirements need to be met
So I configured a transcoder registered to the CUBE and removed the dtmf-relay from the incoming dial-peer and it works!
I know in your case you must keep the dtmf-relay under your incoming dial-peer. However, just for testing, I put the dtmf-relay back to my incoming DP and still works. So I'm not 100% sure what's the order of operation... The transcoder might be able to intelligently make a decision based on the DTMF type...
Sorry, I'm not a Voice professional just wanted to share what worked in my case.
Hope it helps.