What Is DTMF?

What Is DTMF Signaling and What Does DTMF Stand For?

DTMF, short for dual-tone multi-frequency, is the code a telephone keypad uses to send a key: pressing a button sends two tones at the same moment, one from a group of four low frequencies and one from a group of four high frequencies. The receiver identifies the key from the pair, never from either tone alone.

ITU-T Recommendation Q.23, approved in November 1988 and still in force, defines the code in one sentence: "the dialling signal is composed of two frequencies emitted simultaneously when a button is pressed". It plans "10 decimal digits and 6 reserve signals, making 16 signals in all", with each signal taken from "two mutually exclusive frequency groups of four frequencies each", a scheme it calls the "2 (1/4) code".

• Tone - a single sine wave at one frequency, such as 770 Hz. A DTMF signal is the sum of two of them, which is why it is called dual-tone.
• Voice band - Q.23 says the push-button system "applies solely to voice-frequency signals", so the tones travel down the same path as the caller's voice.

Push-button tone dialing reached paying customers in 1963. According to the Hagley Museum and Library, Bell Telephone began offering "the world's first commercial service for an electronic push-button, touch-tone telephone" on 18 November 1963, at first only to customers in Carnegie and Greensburg, Pennsylvania.

DTMF Frequency Table: The Two Tones Behind Each Key

Each keypad row has its own low tone and each column its own high tone, so the DTMF tones of a key are its row frequency plus its column frequency. The grid below follows section 6 and Figure 1 of Q.23.

• Reading the grid - key 5 sits in the second row and second column, so it sends 770 Hz and 1336 Hz together. The star key sends 941 Hz and 1209 Hz, and the pound key 941 Hz and 1477 Hz.
• Sender accuracy - Q.23 requires that "each transmitted frequency must be within ± 1.8% of the nominal frequency". That works out to about 12.5 Hz either side of 697 Hz and about 29.4 Hz either side of 1633 Hz.
• Clean tones - Q.23 also requires harmonics and intermodulation products to be "at least 20 dB below the fundamental frequencies", so the detector sees two clear peaks.
• Sending level - Q.23 sets no standard level, only a cap: on an international connection the levels must not exceed the values in Recommendation Q.16. The CCITT decided at Mar del Plata in 1968 that levels "depend essentially on national transmission plans which are not the same in all countries".

The fourth column, 1633 Hz, carries A, B, C and D. RFC 4733, the IETF standard for sending DTMF over RTP, says "DTMF digits A through D are less frequently encountered, typically in special applications such as military networks." A Texas Instruments application note on Goertzel detection (SPRA066, June 1996) adds that these keys "are usually not present on a regular telephone keypad."

Why Does DTMF Use Two Tones Instead of One?

A single tone is easy for a voice, music or line noise to produce by accident, and a receiver listening for it would register digits nobody pressed. Pairing one tone from each of two groups, at frequencies picked to avoid the patterns in speech, makes such false digits rare.

The reasoning is set out in L. Schenker's paper "Pushbutton Calling with a Two-Group Voice-Frequency Code", published in the Bell System Technical Journal in January 1960. It names the failure talk-off, "false signaling due to speech or noise at the transmitter", and states that "signals with a simple structure are prone to frequent imitation by speech and music".

• One safe band - the paper keeps the system "within the 700 to 1,700 cps range" (cps, cycles per second, is the older name for Hz) because of the attenuation and delay distortion of typical transmission circuits outside it.
• No vowel harmonics - a sustained vowel contains "a number of frequencies bearing harmonic relationships to each other", so valid pairs avoid the simple ratios 1:2, 2:3, 3:4, 3:5, 4:5 and 5:6 that the paper plots.
• Even spacing - adjacent frequencies in each group are "in the fixed ratio of 21:19". Multiplying 697 Hz by 21/19 gives 770.4 Hz, and 770 Hz by 21/19 gives 851.1 Hz, which is how the low group steps up to 941 Hz.
• Louder high tones - the paper proposes sending the upper group 3 dB above the lower group, so that after line loss the difference between the two tones at the receiver "is never more than 5 db, and rarely more than 3 db". The receiver rules below limit the same level difference.

The 1960 paper's upper group was 1,094, 1,209, 1,336 and 1,477 cps, which is not today's set. Q.23's high group has no 1,094 cps tone and ends at 1633 Hz instead, one more 21:19 step above 1477 Hz (1477 multiplied by 21/19 works out to 1632.5); neither text says when or why the set changed.

How a DTMF Keypress Travels From the Keypad to the IVR

Follow key 5 on a call into an IVR. Any of the first four steps can lose the digit or invent an extra one.

• The phone generates two tones. The keypad sends 770 Hz and 1336 Hz together, each within the 1.8% tolerance of Q.23, inside the voice band of the call.
• The network carries them. On an analog line or a G.711 VoIP leg the tones ride inside the audio. A gateway may instead detect them, remove them from the audio and send an RFC 4733 telephone event with code 5, or a SIP INFO message that names the digit, as the VoIP section below explains.
• The receiver measures eight frequencies. The IVR's detector measures the energy at the eight DTMF frequencies, for example with the Goertzel algorithm, and looks for one, and only one, strong tone in each group.
• The receiver validates the pair. It accepts the pair as key 5 only when the tones last long enough, sit close enough to 770 Hz and 1336 Hz, and differ in level by no more than the allowed twist, the receiver rules covered below. When the digit arrives as an RFC 4733 event, the gateway has already done steps 3 and 4.
• The application acts on the digit. The IVR menu, PIN collector or voice agent receives "5" and moves to that menu branch, adds it to the PIN, or uses it as the caller's answer.

DTMF Over VoIP: In-Band Tones, RFC 4733 Events and SIP INFO

On a VoIP call a keypress travels in one of three ways: as tones inside the audio (in-band), as an RTP telephone event defined by RFC 4733, or as a SIP INFO message. The two ends of each hop have to agree on the method, or a gateway between them has to convert it as in step 2 above; otherwise the digit never reaches the application.

a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Content-Type: application/dtmf-relay

Signal= 1
Duration= 160

DTMF Timing and Tolerance Rules a Receiver Applies

A receiver accepts a tone pair as a digit only when the tones last long enough, follow a long enough pause, sit close to the nominal frequencies and keep the level gap between them within limits. ITU-T Recommendation Q.24 (November 1988) frames those parameters but leaves their values to national standards rather than setting one international figure.

Q.24 says it "is not intended to supersede existing national standards", and its Table A-1, in Annex A, shows the values adopted by five administrations and operators. It also requires the receiving exchange to check "for the simultaneous presence of one and only one frequency from the high group and one and only one from the low group."

According to the table's footnote, several European administrations use the Danish values.

• Duration - every column accepts a tone of 40 ms or longer and ignores one at or below its own cut-off, which runs from 20 ms (Danish, Brazilian) to 25 ms (Australian); a tone in between is left to the receiver's design. Q.24 gives the reason for ignoring very short tones: "To guard against false signal indications the exchange should not respond to signals whose duration is less than a specified maximum value."
• Pause - RFC 4733 summarizes the table as a 40 ms minimum tone, a 40 ms minimum pause and a maximum of 8 to 10 digits per second, but the table's own pause row runs from 30 ms to 70 ms.
• Digit rate - the last row, minimum time per digit, is what Q.24 calls "signalling velocity", the fastest rate at which digits can be received, which it says "may be related to the above minimum values".
• Frequency window - Q.24 says tolerances somewhat wider than the sender's may be appropriate, for impairments in subscriber cables, and warns that "wider limits may increase susceptibility to noise and digit simulation by speech."
• Twist - Q.24 does not use the word; it lets a receiver take advantage of a limit, if one is specified, "on the maximum difference in power level between the two received frequencies". The AT&T footnote reads: "The high group frequency power level may be up to 4 dB more or 8 dB less than the low group frequency power level."
• Interruptions - Q.24 says that "to minimize erroneous double-registration of a signal", breaks shorter than a set maximum "must not be recognized", which keeps a short transmission break or a noise pulse from splitting one press into two.

Texas Instruments' DTMF application note SPRA096A (May 2000) shows one vendor's choices: its detector guarantees recognition of tones longer than 45 ms and rejection of tones shorter than 23 ms, values it takes from Bellcore requirements. It allows 8 dB of reverse twist (low tone louder) and 4 dB of standard twist, because row frequencies are "typically less attenuated" than column frequencies on a line that behaves like a low-pass filter.

How DTMF Detection Works: A Goertzel Detector Run

The Goertzel algorithm measures one frequency at a time: each sample updates a recursion that keeps two running values (s = x + c * s1 - s2, with c = 2 cos(2 pi f / fs), as in the code below), and at the end of the window those two values give the power at that frequency, so eight such filters cover every DTMF key. Texas Instruments' SPRA096A states that "The Goertzel algorithm is the basis of the DTMF detector" in its implementation, and that it "is much faster than a true FFT, as only a few of the set of spectral line values are needed".

SPRA096A also checks second harmonics: it assumes the generator sends only the fundamental frequencies, while speech "will always have significant even-order harmonics".

const FS = 8000;

// Goertzel: amplitude of frequency f
// in x[start, start + len).
// Works for any f (not only integer DFT bins).
function goertzelAmp(x, start, len, f) {
  const c = 2 * Math.cos((2 * Math.PI * f) / FS);
  let s1 = 0;
  let s2 = 0;
  for (let i = 0; i < len; i++) {
    const s = x[start + i] + c * s1 - s2;
    s2 = s1;
    s1 = s;
  }
  const p = s1 * s1 + s2 * s2 - c * s1 * s2;
  return (2 * Math.sqrt(Math.max(p, 0))) / len;
}

To show the receiver rules at work, a short Node.js script built around that function was written for this guide and run on 5 November 2026 with Node.js v25.5.0. It generates each DTMF signal as two sine waves, each at a quarter of digital full scale, at 8,000 samples a second, and applies these rules:

• Window - 106 samples (13.25 ms), moved 1 ms at a time. In each window the script picks the strongest low tone and the strongest high tone and requires both to clear a fixed level floor.
• Duration - at least 40 ms, the accept value in all five Q.24 columns.
• Twist - between -8 dB and +4 dB (high tone minus low tone), the AT&T column.
• Frequency - within 2.5% of nominal, a cut chosen by the script to sit between the columns' accept values (1.5% to 1.8%, plus 2 or 4 Hz in two columns, about 2.1% at most) and their reject values (3.0% and up).
• Breaks - gaps of 10 ms or less inside one tone are bridged, the interruption value in the NTT, AT&T and Brazilian columns.

DTMF tones and a Goertzel detector
Run date 2026-11-05 (IST), Node.js v25.5.0
8,000 samples a second, each tone 0.25 of full scale
Window 106 samples (13.25 ms), hop 1 ms
Accept: tone >= 40 ms, twist -8 to +4 dB,
  frequency within 2.5%, breaks <= 10 ms bridged

1. All 16 keys, 80 ms tones, 80 ms pauses
   sent    123A456B789C*0#D
   decoded 123A456B789C*0#D (16/16)
   twist +0.0 to +0.0 dB, max offset 0.00%

2. Same keys after G.711 mu-law encode and decode
   decoded 123A456B789C*0#D (16/16)
   signal to quantization noise 37.9 dB
   twist +0.0 to +0.0 dB after the codec

3. Key 5 at shorter durations (rule: >= 40 ms)
   sent  70 ms  measured  69 ms  accepted
   sent  42 ms  measured  41 ms  accepted
   sent  30 ms  measured  30 ms  rejected (too short)
   sent  20 ms  measured  20 ms  rejected (too short)
   sent  10 ms  measured  14 ms  rejected (too short)

4. Key 5 with one tone weaker (rule: -8 to +4 dB)
   high -6 dB  twist  -6.0 dB  accepted
   high -10 dB twist -10.0 dB  rejected (twist)
   low -3 dB   twist  +3.0 dB  accepted
   low -6 dB   twist  +5.9 dB  rejected (twist)

5. 1,000 Hz low-pass (a stand-in for a channel that
   loses the upper tones, not a real codec)
   loss 697 -0.2  770 -0.4  852 -1.0  941 -2.0
   loss 1209 -8.2 1336 -11.9 1477 -16.0 1633 -20.5
   1 ok  -7.9  2 no -11.7  3 no -16.1  A no -20.4
   4 ok  -7.8  5 no -11.3  6 no -15.3  B no -19.7
   7 ok  -7.1  8 no -10.8  9 no -15.2  C no -19.7
   * ok  -6.2  0 no -10.1  # no -14.1  D no -18.3
   decoded 147* (4/16)
   12 keys rejected: twist

6. Key 5 with both tones shifted (rule: <= 2.5%)
   +1.8%  measured +1.8/+1.8%  accepted
   -1.8%  measured -1.8/-1.8%  accepted
   +3.0%  measured +3.0/+3.0%  rejected (off frequency)
   -3.5%  measured -3.5/-3.5%  rejected (off frequency)

7. Key 5, 100 ms, with an 8 ms dropout in the middle
   no break rule:   "55" (46 + 46 ms)
   10 ms rule:      "5" (100 ms)

Not simulated: noise, speech, echo, packet loss,
RFC 4733 events, SIP INFO, G.729 or other low-rate codecs

• Clean and G.711 - all 16 keys decoded, before and after a G.711 mu-law encode and decode, with 37.9 dB of signal to quantization noise and no change in twist. The result says nothing about G.729 or other low-rate codecs.
• Short tones - 70 ms and 42 ms passed; 30 ms, 20 ms and 10 ms failed. A 30 ms tone sits in the zone Q.24 leaves to each receiver, so this script rejects it where another receiver may accept it. The 10 ms tone measured 14 ms because it is shorter than the 13.25 ms window.
• Twist - a high tone 6 dB weak passed and 10 dB weak failed; a low tone 3 dB weak (+3.0 dB twist) passed and 6 dB weak (+5.9 dB) failed.
• Lost upper tones - a 1,000 Hz low-pass filter cut 1209 Hz by 8.2 dB and 1633 Hz by 20.5 dB. Only the 1209 Hz column (1, 4, 7 and star) decoded, key 1 at -7.9 dB just inside the limit, and the other 12 keys failed on twist although both of their tones were present.
• Off frequency - shifts of plus and minus 1.8%, the Q.23 sender limit, passed; +3.0% and -3.5% failed.
• Dropout - an 8 ms gap in one 100 ms press read as "55" without the break rule and as "5" with it: the double registration Q.24 warns about.

The run does not model a real call end to end. It adds no line noise, speech or music (so it does not test talk-off), no echo, dial tone, packet loss or jitter, and no RFC 4733 events, SIP INFO or SDP. The low-pass filter only stands in for a channel that loses the upper tones; it is not a codec and does not model G.729, G.723.1 or any other, and levels are fractions of digital full scale, not dBm.

Why Do DTMF Digits Get Lost, Cut Short or Doubled?

Q.24 names the three ways a disturbance spoils a keypress: it may cause the signals "to be missed, split (double signal registration) or cause signal simulation". A digit of the PIN in the opening example was missed or split, and each cause below is tagged with the failure it produces.

• A low-rate codec on the path (missed) - in-band tones cross a leg coded with a low-rate speech codec, which RFC 4733 says cannot be relied on to keep them recognizable. Moving that leg to G.711, or to telephone events, avoids it.
• No telephone-event agreement in SDP (missed) - if the two ends never agree on the telephone-event payload, the sender has to fall back to tones in the audio, or to SIP INFO if both ends are configured for the same body. RFC 4733 describes Internet IVRs that "rely on sending systems to generate events in place of tones and do not perform their own audio waveform analysis", and such an IVR never sees those tones.
• Tones and events sent together (doubled) - the first milliseconds of a digit arrive as ordinary audio before the events begin, and some implementations keep sending audio for the whole event. RFC 4733 warns that without careful time and level alignment between the two, spurious digits can appear at the receiver, and recommends that gateways play out only the events once they arrive.
• A break inside one tone (doubled) - RFC 4733 says "unintended breaks in playout of a DTMF digit can confuse the receiving endpoint by creating the appearance of extra digits".
• A tone that is too short (missed) - a tone below the receiver's accept value in the Q.24 table may be dropped. Gateways and test callers that regenerate tones set their own lengths, so check them against the receiver.
• Weak high tones (missed) - a path that attenuates high frequencies widens the level gap until it breaks the twist limit, as the low-pass case in the detector run showed for 12 of 16 keys.
• Echo (split or missed) - Q.24 warns that on long lines an echo "may persist for a number of milliseconds" and can cause errors, "for example due to a reduction of the detected pause duration". The AT&T column asks receivers to tolerate echoes delayed up to 20 ms and at least 10 dB down.
• Speech and noise (false digit) - talk-off, where the receiver hears a digit in the caller's voice or in line noise. AT&T's Table A-1 target for signal simulation by speech is 1 false digit in 3,000 calls for 0 to 9, 1 in 2,000 with star and pound added, and 1 in 1,500 with A to D, so the target loosens as the receiver listens for more keys.

DTMF Uses: IVR Menus, PIN Entry and AI Voice Agents

RFC 4733 describes the most common application: DTMF sent in one direction, "typically from the calling end", to a consuming device that "is most commonly an IVR". It adds that "DTMF may alternate with voice from either end", the pattern of a phone flow that mixes speech and keypresses.

• IVR menus - each key picks a branch, so a lost digit can replay the menu and a wrong one can send the call to the wrong queue.
• PIN, account and card entry - a string of digits, sometimes closed with a terminator key such as pound, where every digit must arrive exactly once or the check fails.
• Voicemail and conference bridges - access codes, mailbox numbers and keypad commands such as skip or replay.
• AI voice agents - an agent that talks to callers may still ask for a PIN on the keypad in the middle of a spoken call, and an outbound agent that calls another company's IVR has to send keypresses itself.

The difference between a keypad menu and a virtual agent that understands speech is covered in IVA vs IVR. For the agent side of a mixed flow, see how to test a voice agent.

How to Check DTMF Keypad Paths on Test Calls

A test call exercises the whole chain at once: the keypad tones, the carrier, any gateway and codec, and the IVR's detector. Point each check at one link of that chain:

• Transport - confirm which method each route uses. In a SIP trace, an a=rtpmap line for telephone-event in the SDP answer shows RFC 4733 was agreed (its fmtp line should list the event codes your menus need), INFO requests during the call show SIP INFO, and neither usually means the digits travel in-band.
• Digit count - compare the digits the IVR logged with the digits sent, so a missing or doubled digit fails the test instead of passing as a wrong PIN.
• Codec - repeat the same keypad path on every codec your trunks negotiate, G.711 and any low-rate codec.
• Tone timing - when your test caller generates its own tones, send each tone for longer than 45 ms, pause 70 ms or longer and send no faster than one digit per 125 ms, or the test fails for reasons of its own. Every column of Q.24's table accepts a 40 ms tone, but the Bellcore values quoted in SPRA096A guarantee recognition only of tones longer than 45 ms; the pause and digit-rate figures are the strictest in Q.24's table.

The keypad test cases themselves are listed in the DTMF testing section of the IVR guide, and scripting the test calls is covered in IVR automation testing.

DTMF Keypad Tests You Can Run on TestMu AI Agent Testing

Agent Testing is TestMu AI's platform for testing chat, voice, phone, video and image agents. For phone flows, a Phone Caller agent places a real call to your IVR or phone agent (inbound) or tests an agent that places calls (outbound), and the docs list DTMF support for both directions.

• Keypad navigation - a scenario can turn on DTMF / IVR Navigation, and your IVR specification can describe its DTMF conventions and menu commands, so the simulated caller works through keypad menus.
• Detected digits - the platform detects DTMF tones for menu navigation during the live call, and each call's transcript shows the keypad inputs it captured (0 to 9, star and pound).
• Path scenarios - scenarios can cover DTMF entry, speech input fallback, and timeout and retry behavior.
• Failure triage - when a connected call fails, play the recording beside the transcript to find the menu step where it went wrong. The docs list a digit that did not register among the usual causes.

The IVR testing software page gives the product overview, and the same platform runs contact center testing for IVRs, voice agents and chatbots. Testers who want to prove they can run agent tests on the platform can take the Agent Testing certification, an online multiple-choice test.

Start with the keypad path that carries the most risk, such as PIN or account entry, and check it again whenever a trunk, gateway or codec on your side changes. The phone agent testing docs explain what inbound and outbound phone tests share and link the setup guide for each direction.