Duplicate DTMF problem

Asterisk Asterisk Support
1

I’m having a random recurring issue with DTMF while dialing into external conference bridges (entering the passcode)…only on speakerphone… The issue is that the digits get repeated sometimes where 1234 might appear as 11234 thus being invalid and making the user try again. It’s only while on speaker, the workaround is to use the handset, but it’s not really a solution. Naturally, everytime I test it it works fine without the duplicates, but it’s been happening enough to piss off some execs. We run on Asterisk 1.8.14.1 and the handsets are Aastra 6737i.
The handset settings are:
Force RFC2833 Out-of-Band DTMF: TRUE
DTMF method: RTP (choice of RTP, SIP INFO, BOTH)

The SIP peer definition specifies RFC2833, so the output of ‘sip show peer’ shows it negotiating to RFC2833, which is good. That’s also what our SIP trunk provider supports.

Being that it only happens on speakerphone, I see it maybe being an acoustic echo issue where the RFC packet informs the server a digit was pressed, but the sound of the digit being pressed echoes in the room and enters the RTP stream a fraction of a second later, but late enough to appear as another keypress. It’s like I need to FORCE only RFC and mute anything that appears in the RTP stream, but I’m not entirely sure, and that should be what that setting is already doing! Does this make sense to anyone who’s had this issue before or who understands this at a deeper level than I do? Is this a handset problem or Asterisk problem? Any better workarounds I could use like the VOLUME function? Thank you!

2

In terms of codecs, the phones allow g722, then ulaw. Asterisk changes the codec to ulaw in the dialplan if the call is going outside over our provider. We used to have it so the codec would be g722 and let asterisk transcode external calls to g711, but still see the same issue either way.

3

I’m going to try NOT forcing the out-of-band rfc2833 from the phone and let it negotiate to ‘inband’. Asterisk should then translate the inband dtmf to rfc2833 when the call is bridged to my provider.

My thought process is that only a single digit will be possible as long as the dtmf duration/detection settings are sufficient. Echo might still prove to be a problem, but when using rfc, echo makes it more likely that a duplicate tone gets introduced into the stream (the rtp event + the tone detected by the mic).

The only other methods out there that I found are using Polycom/other phones that have DTMF masking with pacifier tones or ability to not play the tone out loud when on speaker. Our phones don’t have that option. I also saw some info about modifying source to boost dtmf tone frequencies to become tone-blind. This is all assuming I’m right about the issue stemming from acoustic echo; maybe this is at the network level or elsewhere :cry: