Asterisk DTMF

Asterisk and DTMF (TouchTone)

As a PBX Asterisk is able to translate the different types of DTMF signalling methods (audio, RFC2833, SIP INFO, IAX2).

Variable length DTMF

This is a tricky issue: You cannot expect to have control over the duration of DTMF signals when using SIP INFO in general, or RFC2833 before Asterisk 1.4.0: For example cell phone carriers transmit keys pressed on your GSM phone to fixed length signals regardless of how long you pressed that key. A typical application where you'd want control of the duration of the key press is controlling an electric door opener.


Inband means that DTMF is transmitted in the same network connection as the audio of the phone conversation. Two methods are available, either as audio tones transmitted encoded into RTP packets just like voice, or as named telephony events in specially marked RTP packets according to RFC 2833 (obsolete) or RFC 4733. When sent as audio, only uncompressed codecs such as, G.711 (alaw and ulaw) can carry DTMF reliably. Female voice are known to once in a while trigger the recognition of a DTMF tone. For analog lines inband audio is the only possible means to transmit DTMF.

Changing DTMF duration when sending for ZAP channels

You might try increasing the toneduration - or whatever the option is in /etc/asterisk/zapata.conf - Asterisk's default transmitted DTMF tone length is quite short:


DTMF recognition


Adjust this setting in zapata.conf to your needs (i.e. to NO) if you e.g. have 'talkoff' issues (talkoff means that a human voice incorrectly triggers recognition of a DTMF signal):


mISDN v2

You can config a threshold when loading the mISDN_dsp module:

modprobe mISDN_dsp dtmfthreshold=100

Note: Asterisk 1.4 now also has the relaxdtmf= setting available in sip.conf.

Changing DTMF tone frequency in Asterisk

How to prevent Asterisk from regenerating received DMTF
When Asterisk is handling a call and needs to listen to that call, e.g. to monitor it for DTMF transfer tones, Asterisk will detect and rebuild all DTMF tones on that call.

If you use Asterisk as a bridge to connect appliances that communicate by exchanging DTMF tones (e.g. remote alarms transmitting their alarm-ID, or other remote industrial appliances that were designed before the IP age), Asterisk will consistently intercept, buffer and regenerate all DTMF tones it detects. This may be a problem, as some of those appliances use distinct DTMF-silence cadences, and by regenerating those tones they are output with Asterisk's signal-silence cadences.
In order to avoid this behaviour in Asterisk, what you can do is to modify the frequency of the DTMF tones Asterisk expects, so that the true DTMF tones are not recognized and therefore let alone by the DSP module.
Read more here.

AUDIO (inband)

This method involves transmitting the DTMF as audio in the RTP Stream. Unfortunately, if you have any packet loss on your connection or are using anything other than G711 you will have a lot of problems with DTMF. DTMF should be detected by the edge of your VoIP network. IE, if your customer uses a phone, the phone ( or an ATA connected to the phone ) should detect DTMF and transmit the DTMF as named telephony events (RFC 2833). When calls come into your VoIP network ( tdm, pri, SIP Trunk etc... ) the DTMF detection should be done at the point where the audio enters your network.

RFC2833/RFC4733 (inband)

DTMF are transmitted with RTP packets just like audio on the same network connection, but are encoded separately as a different payload type than the audio stream. This is today the de facto standard. Most SIP Trunk providers use this method.

Earlier implementations of RFC2833 in Asterisk were broken, using any version of asterisk below 1.4 and you will have a lot of problems with DTMF If you are receiving SIP calls from a pre-1.4 Asterisk installation you will want to turn on the rfc2833compensate option in sip.conf.

SIP INFO (out-of-band)

Out-of-band transmission of signaling involves sending the information via a separate network connection. Typically this is accomplished with the methods of the signaling protocol that also controls the setup of audio and video connections. SIP defines the INFO message type for signaling DTMF digits. Although this is a very reliable method of transmitting DTMF, it is not supported by all devices, and PBXs. Most SIP Trunk providers do not support SIP INFO. Using this means Asterisk will have to translate between different methods.

DTMF in IAX channels

On an Asterisk 1.2 system a DTMF signal will be sent just a single AST_FRAME_DTMF frame over IAX2 - there is no information about the duration of the event, just like with SIP INFO. In Asterisk 1.4 also the DTMF duration (if available) will be transmitted.
Troubleshooting: If you experience problems with recognizing DTMF sent over IAX then turn the IAX jitterbuffer off.

DTMF in chan_misdn


a - Have Asterisk detect DTMF tones on called channel
i - Ignore detected DTMF tones, don't signal them to Asterisk, they will be transported inband.
s - Send Non-inband DTMF as inband

FAQ - Questions and Answers

Catch DTMF when 2 users are in conversation

Q: I want to know if it is possible in Asterisk to catch a DTMF event sent by one of the phone to trigger an action, for example to play a sound/video clip to one of the phones.
A: Google for features.conf, but you'll need to keep asterisk in the callpath, i.e. canreinvite=no, otherwise the RFC2833 DTMF codes will only be sent between the end points. If you need to reinvite, then you might have to try using SIP-INFO for DTMF instead of RFC2833.

Detect duration of a DTMF key press?

Q: Here's the scenario, I am planning to use SIP phone to connect asterisk local extension number where it will connect me to my agiserver. My agiserver(written in java) as of now can detect and prints dtmf tones but not the dtmf done by prolonged key pressed.
A: As of Asterisk 1.4, if you use RFC2833-generated DTMF, then it is possible. It would also be possible in any version with inband audio DTMF (which requires ulaw or alaw). All other cases, it is only possible to know that the event occurred, not how long the event lasted.

Broadcasting DTMF to conference users

Q: How can I arrange the ability for MeetMe participants to press DTMF keys on their phone and for the tones to then pass out to the other party(ies)?
A: The pseudo zap channels - that's what all VOIP channels have to use to get into a MeetMe - can't do DTMF with any measure of reliability at all. So what I did was program into app_conference the ability to do DTMF broadcasting of both audio and RFC DTMF.
The broadcast DTMF portion will do a separate send to each of the participants that has the flag set for RFC and for inband flagged participants it will go to a section that will play an audio file of a DTMF tone(to allow for SIP RFC participants to send DTMF to inband Zap participants for example).
It does still have a random double-free memory that I can't find anyone to fix which will crash Asterisk if you use audio DTMF broadcasting a lot, but it has worked for me for periods of time as long as 2 weeks without crashing. (Quote as of Sep 2006)
To do DTMF broadcasting, make sure you read the README which has instructions on the flags for Conference in the dialplan.

Modify DTMF timing

Q: How and where can I adjust the DTMF timing?
A: main/channel.c, include/asterisk/channel.h: 2007-04-24 21:34 +0000 [r61781-61787] Russell Bryant (Asterisk 1.4.3)
Improve DTMF handling in ast_read() even more in response to a discussion on the asterisk-dev mailing list. I changed the enforced minimum length of a digit from 100ms to 80ms. Furthermore, I made it now enforce a gap of 45ms in between digits. These values are not configurable in a configuration file right now, but they can be easily changed near the top of main/channel.c.

DTMF in conferences

Q: Can I use a MeetMe conference to relay DTMF to other callers?
A: Asterisk 1.4 has introduced a new option 'F' in MeetMe that serves this purpose.

Manually extract and post DTMF digits

Q: I'm trying to make asterisk detect some DTMF digits during a call and post them (can't use WaitExten or Features.conf).
A: I would suggest that you implement that in logger.c and configure a line to send logs to an HTTP POST (via logger.conf), with the pbx_substitute_variables_helper function, using the ${CURL()} function directly. You may need to "preload =>" in modules.conf, but that will work well. Or use a simple log watcher:

tail -n0 -f /var/log/asterisk/debug | \
grep 'DTMF digit: [0-9#*]' | \

Reading DTMF logs

I have wrote nice little php script that gets the dtmf info dumps it into a csv and then zip's it up.

This is written for asterisk 1.4 but it should work on other versions with out to many changes.
I could possible improve it but it works for now.
First of enable dtmf logging in logger.conf, I set mine to dtmf => dtmf.
login into asterisk and reload logger.

Make a couple of test calls to make sure its logging ok.

Here is the php code.

//Location of the log file
$myfile =("/var/log/asterisk/dtmf");
// Set the date your looking (ie todays date)
$today = date('Y-m-d');
$lines = file($myfile);
error_reporting(E_ALL ^ E_NOTICE);
// if you want to see whats been grabbed from the file uncomment next line.

// Start looping through the data
foreach ($lines as $dtmf){
// Because Logger logs more than one line per key press, I check for pattern that matches only one line so it wont get confused.
if (substr($dtmf,1,10) == $today && substr($dtmf,58,8) == "received"){
// echo substr($dtmf,58,8)."\n";
$firstApos = strpos($dtmf, "'");
//echo $firstApos."\n";
$x = substr($dtmf,($firstApos +1) ,1);
// echo $x."\n";
$thedate = substr($dtmf,1,19);
if($x == '1') {
// echo "Date: ".$thedate." Option: ".$x."\n";
$key[].= $thedate.",".$x.",";
$var .= "Date: ".$thedate." Option: ".$x."\n";
if ($x == '2') {
// echo "Date: ".$thedate." Option: ".$x."\n";
$key[] .= $thedate.",".$x.",";
$var.="Date: ".$thedate." Option: ".$x."\n";
//If your looking for how many times a number is pressed keep this in.

//dump it all into csv using the date as the name
$fp = fopen($today.'.csv', 'w');
foreach ($key as $line) {
fputcsv($fp, split(',',$line));
// debugging junk but nice to keep an eye on things
//How many times was 1 pressed
echo $i1."\n";
//How many times was 2 pressed
echo $i2."\n";
// See whats been pressed and what time
echo $var;
// Call the linux zip script
exec("zip ".$today.".zip ".$today.".csv");

//Thats all folks




  • enable debug mode in the Asterisk CLI to be informed of DTMF events
  • record the audio (with e.g. ztmonitor) and make sure Asterisk gets valid DTMFs in the audion stream.

Q: After I upgraded from 1.2 to 1.4.13 the CLI does not show DTMF anymore, even at high debug level. Do I need to activate that?
A: You need to enable DTMF debugging in logger.conf, then type "logger reload" at the Asterisk CLI for those changes to take effect.

Receiving one DTMF digit on Zap (PRI Sangoma E1) in Asterisk 1.4

CLI> core set debug channel Zap/1-1

[Jul 30 13:19:05] << [ TYPE: DTMF Begin (12) SUBCLASS: 5 (53) ] [Zap/1-1]
[Jul 30 13:19:05] << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [Zap/1-1]
[Jul 30 13:19:05] << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [Zap/1-1]
[Jul 30 13:19:05] << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [Zap/1-1]
[Jul 30 13:19:05] << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [Zap/1-1]
[Jul 30 13:19:05] << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [Zap/1-1]
[Jul 30 13:19:05] << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [Zap/1-1]
[Jul 30 13:19:06] << [ TYPE: DTMF End (1) SUBCLASS: 5 (53) ] [Zap/1-1]

rtpkeepalive mutes/blocks DTMF

  • A bug/feature in Asterisk 1.4 and possibly other versions blocks/mutes DTMF when rtpkeepalive is enabled
  • Solution: set rtpkeepalive=0
  • Description: When rtpkeepalive is enabled Asterisk sends comfort noise to the other party. During sending of comfort noise DTMF processing is disabled. See function ast_rtp_sendcng in rtp.c

Unreliable detection of audio DTMF

  • Possible solution: Make sure you have a zaptel timer / timing device, i.e. either 'ztdummy' or some zaptel hardware on your system.
  • Another possible solution: If your asterisk isn't reliably recognizing dtmf and you're using a provider that only supports audio dtmf, consider dumping them for another provider that can give you out of band dtmf such as RFC2833. Depending on your situation, this may be an easier fix than some other solutions. Inband dtmf detection seems to be very problematic.

Duplicate DTMF

  • Change the setting relaxdtmf= and see if that helps
  • If you appear to be receiving doubled DTMF signals then you are likely to get both audio and RFC2833 or SIP INFO signalling on your Asterisk box; you will want to make the sening party use only one of these two methods.
  • Another possible cause would be that your telephony card has hardware-based DMTF detection turned on, coupled with the fact that Asterisk also detects the DTMF signal(s).

Testing DTMF with Asterisk

The D option to the Dial command transmits DTMF tones, with a 'w' causing a pause:


Bugs & patches

  • Inband audio DTMF and de-bouncing bug in Asterisk 1.2 and 1.4 (Aug 2007), see patch 10535
  • Asterisk 1.2: DTMF modes are not getting translated in P2P bridging mode
    • If 2 call-legs have different DTMF modes and peer-to-peer bridging (and probably native) is used then DTMFs are not getting translated and as such are not recognized by the peer.
    • While bridged in P2P mode, there is no DTMF detector used on the incoming audio.
  • New in Asterisk 1.4.0: The Asterisk RTP stack has been changed in regards to RFC2833 reception and transmission.
    • Packets will now be sent with proper duration instead of all at once. If you are receiving calls from a pre-1.4 Asterisk installation you will want to turn on the rfc2833compensate option. Without this option your DTMF reception may act poorly.
  • 5970: RFC-2833 DTMF support is broken in Asterisk 1.2.1
  • 6027: [patch] picking up multiple DTMF using RFC2833
  • 6011: when jitterbuffer=yes DTMF is unreliable on IAX2 links
  • 6667: [patch] Asterisk 1.2.4 and rfc2833 compliance
  • 6082: [patch] new AMI event (manager): DTMF sent/received
  • 12658: Resolve issues that could cause DTMF to be processed out of order.
  • 13209: After Asterisk 1.4.18 up to and including 1.4.22: DTMF RFC2833 via SIP is not working (duplicated digits)
  • 14460: Fixed for Asterisk 1.4.24: Asterisk plays a continuous tone forever if it never receives a RFC 2833 end packet (see r178141 and r178373 of the 1.4 ChangeLog, related to rev 175124)

Trouble with other vendor devices

  • Sipura 3000 aka SPA3K: As per my (numerous) statements on this subject Asterisk WILL NOT properly work with the spa-3000 DTMF in rfc2833. Use INBAND when dealing with Asterisk on both the FXO/FXS ports of the spa3k if you are dealing with Asterisk.
  • Sangoma cards and DTMF debugging

See also

Created by: JustRumours, Last modification: Sun 28 of Aug, 2016 (01:58 UTC) by khb
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+