# What Is DTMF? Keypresses, IVR and Why They Sometimes Fail

> What DTMF is, how IVR systems use keypresses, why keypresses sometimes fail to register, and what to check when callers say the menu is not responding.

Source: https://edesy.in/blog/what-is-dtmf-ivr-keypress-guide-2026

**Short answer:** DTMF — Dual-Tone Multi-Frequency — is the tone your phone sends when you press a
key. Each key emits two simultaneous frequencies, and the receiving system identifies the key from
that pair. IVR menus are built on it. When a menu "does not respond", DTMF is usually why, and it
is almost never the menu logic that is broken.

## How It Works

Press 1 and your phone emits two tones at once: one from a low group, one from a high group. The
combination is unique to that key. Pressing 5 sends a different pair. To hear each pair, or save a
digit sequence as a file for testing a menu, use the [DTMF tone generator](https://edesy.in/tools/dtmf-tone-generator).

Two tones rather than one is deliberate. A single tone could be produced accidentally by a voice
or background noise; two specific frequencies arriving together almost never happen by chance.
That is why DTMF has survived since the 1960s essentially unchanged.

## How It Travels Today

On a modern voice network the tones may not travel as audio at all. There are three common
approaches:

| Method | How digits travel | Notes |
|---|---|---|
| **RFC 2833** | As separate signalling events | The usual default, most reliable |
| **Inband tones** | As actual audio in the call | Vulnerable to compression |
| **SIP INFO** | As SIP protocol messages | Less common |

Edesy's platform defaults to **RFC 2833**, with keypresses delivered to your application as
events. If you are building against the API, digits arrive as events you can act on rather than
audio you have to detect.

## Why Keypresses Fail

This is the practical part. When a caller says "I pressed 2 and nothing happened":

**Method mismatch.** One side sends RFC 2833, the other expects inband. The call audio is fine —
speech works perfectly — and digits vanish. This is the most common cause and the most confusing,
because the call otherwise seems healthy.

**Audio compression eating the tones.** With inband DTMF, aggressive compression can distort the
tones enough that the receiver does not recognise them. Speech survives compression; precise dual
frequencies do not always.

**Pressing too early.** Some systems do not listen for digits until the prompt finishes. Callers
who know the menu press immediately and appear to be ignored. Allowing keypresses during the
prompt fixes this and makes regulars much happier.

**Pressing too briefly.** A very short tap may not produce a long enough tone to register.

**The handset itself.** Some devices and some softphone configurations handle DTMF poorly. If one
caller has trouble and nobody else does, suspect the device before the system.

## What to Check

In order, when keypresses are not registering:

1. **Does it fail for every caller, or one?** One caller points at their device or network. All
   callers points at configuration.
2. **Does it fail for every key, or some?** Some keys working is unusual and suggests audio
   quality; no keys working suggests method mismatch.
3. **What method is each side using?** Confirm both ends, do not assume they match.
4. **Is the system listening during the prompt?** Try pressing after the prompt completes — if
   that works, allow barge-in.
5. **Is it only on one route?** If calls from one carrier fail and others work, the difference is
   in that path.

## DTMF and Speech

Menus can also accept spoken input rather than keypresses. Worth being clear about when each is
right:

**DTMF is better for** account numbers, PINs, amounts, anything where accuracy matters and a
misrecognition is expensive. It is exact — a 4 is a 4 — and it works in a noisy environment where
speech recognition struggles.

**Speech is better for** open-ended intent, where forcing a caller to map "my order is late" onto
one of four options is the actual problem. That is a
[conversational agent](https://edesy.in/ai-voice-agent), not a menu.

Many good systems use both: speech for intent, DTMF for the digits.

## Designing for DTMF

- **Allow keypresses during the prompt.** Regulars know the menu; do not make them listen.
- **Confirm entered digits.** For anything longer than one key, read it back.
- **Give a way to correct.** A caller entering a ten-digit number will mistype it.
- **Do not require more digits than necessary.** Every extra digit is another chance to fail.

## Related Reading

- [How to write an IVR script](https://edesy.in/blog/how-to-write-ivr-scripts-2026)
- [IVR menu design](https://edesy.in/blog/ivr-menu-design-how-many-options-2026)
- [Why callers hate your IVR](https://edesy.in/blog/why-callers-hate-your-ivr-2026)
- [IVR flow builder](https://edesy.in/tools/ivr-flow-builder)

## Related reading

- [When AI calls should ask for keypad input](https://edesy.in/blog/keypad-dtmf-input-ai-voice-calls-2026)