'Talk-off' issue & how to disable DTMF detection

Asterisk Asterisk Support
#1

I have been experiencing issues regarding ‘talk-off’ & dtmf signal detection.

Is there a way in the dialplan to temporarily turn off all dtmf signal detection (& likewise dtmf signal re-generation) for a channel?

For instance, I have recorded music that plays back via IVR. The music has a ‘telephone-themed’ composition, which includes some processed DTMF tones (actually recorded into the sound files). So when Asterisk plays through the music and hits those tones, it tries to re-generate them as new DTMF tones that scramble the music.

I have tried setting my dtmfmode to both rfc2833, and in-band, with the same result. In both cases, I had enabled only ulaw & alaw.

Thank you in advance for any suggestions.

#2

If the DTMF was part of the audio itself in the recording, then Asterisk would merely forward the audio through - it won’t do DTMF detection on that and use out of band signaling.

#3

I think this is being done downstream of Asterisk. If you are using rfc2833, and the peer is using it, it may be happening quite a long way downstream.

#4

Thank you for your responses.

I have done some further testing and you are both right that it does not appear to be an Asterisk issue. When dialing into my SIP URI via softphone, I am not observing any ‘talk-off’ behaviour.

However I am experiencing this problem with 2 different trunk providers. With one provider, I am able to set DTMF mode to ‘RFC2833’ on their side. On the second provider (Anveo-direct), I do not see an option anywhere to set ‘RFC2833’. I have enabled that also in my pjsip configuration (as ‘dtmf_mode=rfc4733’), and also tested with a chan_sip configuration using ‘dtmfmode=rfc2833’.

Is this kind of problem to be expected? Would it be a good decision to remove any sound from the music that might potentially be detected as DTMF tones? Or is there some potential way around the issue?

Thank you for your help.

#5

I can’t really comment on the behavior of trunk providers or their equipment. I don’t know what their media handling would be doing to the audio and what impact it could have. Theoretically they may always place a DSP on the line for inband DTMF detection for example. No real way around that if DTMF is in the audio stream.

#6

Thank you for your response.

I wonder if it is even technically possible for a trunk provider, using rfc2833, to ignore all in-band DTMF, but to still listen for DTMF tones encoded in RTP packets. So DTMF tones that playback from my audio file would be ignored, but DTMF input from the caller would be accepted.

I am new to VOIP & Asterisk so my question might seem a little naive. If it seems possible, I will try to push forward with other providers. If not. . . I will have to replace all the DTMF tones in my music recordings with something else. Thank you again!

#7

RFC2833 is out of band, it’s not sent as audio. There’s no reason that the audio can’t be passed through left alone, that is what Asterisk itself does when configured as such.

#8

If, for example, the call goes onto the PSTN and to a mobile number, all the DTMF will end up in band on the PSTN, but might be taken back out of band for the mobile network (mobile network codecs aren’t compatible with DTMF (or good quality music), but whilst DTMF is definitely sent out of band downlink, I’m not sure that the networks try to preserve it on the uplink).

#9

Hello, thank you both again for your responses. I have had conversations with different technicians with 3 different providers, and all of them seem to think that it won’t be possible to avoid DTMF detection at some stage, at least when connecting by mobile.

I know that ulaw/alaw codecs are far from ideal for music playback. But actually I get a pretty good frequency response between 800hz and 3khz (at 8 bit, unfortunately)—which is quite workable for me, there is a lot of space to play there. Plus there is some historical presidence.

I have decided the most reliable and simplest method is to just remove the DTMF tones from my music. Thanks again for your detailed and helpful responses.

#10

Mobile phones use vocoder codecs, not Mu–Law or A-Law, which are simply companded linear.

#11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.