I am trying to set up an IVR using a custom recording. When I ring it internally it all works fine however when I ring in from external (via our ISDN) the digits are not accepted while the custom recording is playing but they are accepted if there is a gap in the speech.
I have the IVR password protected and when the default system recordings are played I can enter the password at any point as quickly as I like during playback which is fine, it then goes to play my custom recording and if I make a selection while there is recorded speech it does not work but if I make my selecting when there is a gap or at the end it accepts.
The recording was exported from audacity at 8000hz 16-bit wav and imports OK under System Recordings. I have also ran sox and converted it to alaw and sln but still the same
I have read a lot about DTMF options however if this was the case then surely this would affect the entire call? - As mentioned I can enter digits perfectly when a standard system recording is being played, it’s only my custom recording that’s not accepting it (only if there is a gap in the speech)
I have also enabled DTMF logging and when testing no digit is received, this only happens when my custom recording is being played. I though it may have been due to the recording being a bit loud but on turning down the volume in audacity made no difference.
I’m not having a problem with phantom digits being recognised, When pressing a digit while my custom recording is being played is not being accepted by the system unless there is a silent spot in the custom message. It’s as if the custom message being played is drowning out the DTMF tone coming back in but the volumes are the same on the default system and my custom recordings.
As mentioned earlier, I can enter numerical passwords and be accepted 100% of the time when a default system recording is being played.
The DTMF (dual tone, multi frequency) detection process uses “Fast Fourier Transforms” to isolate the [4x4] matrix DTMF tones from the audio stream, not volume or anything else, if your recording contains traces of such a “hit” on one of those single 8 mono-tones, then it can confuse that process. That’s just theory, so use a different recording to test
I assume DTMF works different internally (pure SIP enviroment) as the process works perfect, it’s only when coming in via our ISDN that has the problem.
I have just ran the custom audio file through the link you provided in the first post and it picks up almost every digit and some letters!
I then ran through the short agent-login file and the net-target-destination file which is default to asterisk and it detects none
I need to see if I can find some way of removing the tones from the recording without disturbing the audio
Well, sip dtmf is usually detected and sent out of band, in call dtmf over TDM/analog is of course constrained to in-band. With reference to
you could simplistcally run your recording through a single pass three element filter that bandrejects “1209 Hz” “1336 Hz” and “1477 Hz” this should effectively suppress any spuriously detected DTMF signaling, the width and height of the filter would have to be experimented with, using sox you can “trial and error” with
play yourfile rate 16000 sinc -t 8 -a 180 1214-1204 sinc -t 8 -a 180 1341-1331 sinc -t 8 -a 180 1482-1472
where -t is the total band width and -a the attenuation, the range should symetrically span the single sine frequency of interest. Reverse the range for a bandpass to hear them one by one, you should “man sox” first so you fully understand.
If you are comfortable with deploying python code then probably:-
will likely be a lot more effective and less “disturbing” as it uses the slower but more precise DFT (discrete fourier transform) extractions, (sorry, possibly too much math theory here but if it worked for AT&T . . .)
A caveate is that I can’t say whether that will fix your problem and ANY filter will “disturb” the audio.
but if it worked for AT&T . . .)