In-Band DTMF

Dear Experts ,

I have one general question (for DTMF detection) that makes me crazy . if inbound call (GSM >>to>>IVR). Normally , DTMF tone (from the external GSM phone) should be received by the IVR , and it will make FFT to extract 2 basic frequencies , then the keypad pressed is known.
What about in-Band DTMF, where there is no tone sent to IVR . How does the IVR recognize it ?.


Asterisk doesn’t FFT.

Tone decoding is ONLY done for inband. For other schemes, the tones are already decoded to digits.

GSM codecs are incompatible with DTMF, so DTMF tones never come from the phone in GSM networks; they come from the basestation, or a mobile switching centre. Of course, if you present DTMF to the microphone of a GSM phone, it won’t work.

Dear David ,

First, you gave me hope , and now I am not crazy :smile:
The question now : how to decode the inband tone ?

As per below screenshot, the phone call is recorded by the IVR, and the GSM phone on the other end has a song on the background. When the user presses any key , the a silence is heard till the user releases the button.

Thanks for support
[attachment=0]Phone call.jpg[/attachment]

Please explain what you mean by IVR in this context. You can implement interactive voice response in many ways with Asterisk and generally you let Asterisk decode the tone, and then either use Read or something like Waitexten, to recover the digits.

I am doing my own code to decode the DTMF, not using Asterisk.
When I started, the DTMF tone was received by my application , then by applying the FFT , I could extract the DTMF key. But after 3 months, the DTMF was not received by my application , and for most it became inband. So, I need to decode.

also , May you please feedback this case i face , is it In Band or Out of Band.
What is the difference.


I don’t understand “feedback this case i face”!

In band means that tone is transmitted as audio samples (or analogue audio). Out of band means that the the digits are transmitted separately, and generally not as tones. In SIP contexts, the use of telephone events frames, to send start and stop indications for digits is considered out of band, even though they are interleaved with audio frames.

As noted before, GSM mobile networks always transmit keypresses out of band between the handset and base station. The tone you hear is not what is transmitted. However, that is probably irrelevant here, as the mobile network will have generated in band tones, once the switch to a G.711 codec has been made.

Normal best practice with VoIP is to convert to out of band and the boundary of the VoIP system and only convert back to in band on leaving the VoIP system. E.g. a SIP phone would never generate a tone when a button is pressed, and any tone would only be generated at the destination phone. This is because missing frames can damage tones and many VoIP systems use, vocoder based, codecs, that cannot cope with pure tone pairs.

But for GSM Phone to Phone normal call , when the user presses any key , the recipient with the second GSM phone does NOT hear any DTMF tone. how come ?. As per what I understood , the DTMF should be heard once switch to a G.711 codec is made automatically.
NB. I am not speaking about SIP , or VoIP.

You are definitely doing something unusual, and of which it is unlikely that anyone on this forum has any experience. It is still not clear to me what your exact configuration is.

Dear David,

I just need to understand DTMF transfer through GSM network. eg for [color=#BF4080]GSM Phone to Phone normal call , when the user presses any key , the recipient with the second GSM phone does NOT hear any DTMF tone[/color]. how come ?. As per what I understood , the DTMF must heard , or it is transferred to the GSM phone as out of Band ?

Update :
[color=#4000BF]When I make a GSM phone call to Land line phone >> I can hear the DTMF tone.[/color]

Thanks so much for your continuous support. Really appreciated.

The GSM network will not be able to accurately send the tone to the destination phone inband, so the options are to try to force it through the codec anyway,which will not reproduce it accurately, or to covert it back to out of band. Just blanking it without sending it out of band seems pointless.

If the tone is to be decoded at the receiving end, out of band is the only option.

However, I’ve never had a case where it made sense to send DTMF to a GSM device, so I have never investigated this.

Dear David,
Thanks so much for your support. You really give me hope.

to make the issue clearer for me, May you please answer these questions. Here I am asking about [color=#8000BF]GSM >> Asterisk[/color].

1- [color=#8040FF]If a GSM is calling Asterisk & DTMF is sent. Will be it sent to Asterisk as Tones (in band) , or out of band[/color] ?. I guess Out-of-Band.

2-[color=#4000FF] If sent as In-Band , does Asterisk perform FFT to extract the correct tone pressed ?[/color]. As per your last feedback , Asterisk does not perform FFT , so I guess that Asterisk only work with out of band.

3-[color=#4040FF] if Out of Band , who does Asterisk extracts the correct tone ?[/color]. >> I do not know the correct answer. I guess that the bytes sent from GSM to Asterisk is searched (by Asterisk) for special bytes sequence that will describe the tone pressed.

Thanks for support.

  1. GSM doesn’t support the GSM air interface without third party hardware. The answer to this question will depend on that hardware.

  2. Asterisk uses DSP to detect the tones, but does not do an FFT. It appears to use spot frequency filters for the various tones. For more details see main/dsp.c.

  3. I can only answer for SIP. Details for your GSM connection will depend on the third party hardware and its drivers. For SIP, the digits are sent as binary numbers. In one mode, they are sent in INFO method requests. In the more commonly used mode they are sent with a special codec number in the RTP stream as either a start or a stop indication and the digit number. Both start and stop are repeated multiple times.

The air interface specification for DTMF over GSM appears to be available at … 50000p.pdf