DTMF interworking between Inband G711 & RFC2833 & out of band

[Matthieu LIENART]

Hello everyone,

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.
Matthieu

[R0g22]

1. CTI only support OOB hence the UCCX behavior.
2. I hate to call RFC-2833 as inband because it is not. It could be called a hybrid but not inband.
3. It won't be based on who is calling. This is something that your ITSP needs to handle correctly.

CUBE is capable of doing a interwork but has restrictions for -
1. Transcoder is required at the CUBE. You can use LTI for this.
2. Dial-peer should not have "dtmf-relay" configured to force it to pure inband.

Your understand is correct that you can add another incoming dial-peer to handle pure inband DTMF. Is there a pattern, a particular location, area code etc that you can isolate ? Have you had a talk with your ITSP to see why is in-band being sent when they are actually supposed to use RFC-2833 ?

[Matthieu LIENART]

Hello Nipun,

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? 

[R0g22]

Nope. The link that you added in your initial email highlights the requirements specifically for inband to RFC2833 interworking.

A workaround could be to use E.164 pattern map and match a single incoming dial-peer. I know this is not practical but it's better than having to create a new dial-peer and better than having nothing.

[Matthieu LIENART]

Hello Nipun,

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.

[R0g22]

For CUBE to detect inband vs any other DTMF method dynamically is impossible. Your ITSP is the culprit here. I have worked a lot with ITSP's and this is the first time I have heard that your ITSP does not want to do RFC 2833 (they say they comply only to this) for some calls and do pure in-band for some and want the SBC to correct this dynamically. They are in a habit of punting everything to customer equipment and this is a very good example of this.

[Matthieu LIENART]

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?

[R0g22]

"No preference" won't help here. Further, NTE is basically RFC 2833 and not pure in-band. So having relay command on the dp won't help either.
CUCM won't be able to do that any interop AFAIK. IOS router requires DSP as well for this purpose.

[Matthieu LIENART]

Hello Nipun,

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.

[R0g22]

I don't believe there is a way for CUCM to know about pure in-band DTMF. The interworking is done by CUBE and the transcoder needs to be available locally with the CUBE. CUBE will invoke one for the interworking and not CUCM. Also, the codec needs to be G711u else the compression would cause loss of DTMF tones. And like we have already discussed, the dial-peer facing the leg receiving in-band needs to have dtmf relay disabled.

[Zsolt]

Hi,

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

Cisco says:

DTMF interworking between Inband G711 to RFC2833

CUBE is able to interwork between Inband G711 DTMF (raw audio tones) to RFC2833. However, these requirements need to be met

• The codec used must be G711 end-to-end. This is a restriction because if a LBR codec was to be used then the tones would get distorted due to the compression loss.
• Transcoding resources must be available and registered with the CUBE accordingly. This because the CUBE needs to allocate a transcoding resource (more specifically: a DSP resource) to the media RTP stream to inject or listen for tones within the audio stream.
• The dial-peer for the inband-tones leg must not have any DTMF relay command configured.
• The dial-peer for the RFC2833 leg must have dtmf-relay rtp-nte configured.
• Do not enable digit-drop on any of the dial-peers involved with the call.

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.

Best Regards,

Zsolt