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.
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:
- Does it fail for every caller, or one? One caller points at their device or network. All callers points at configuration.
- Does it fail for every key, or some? Some keys working is unusual and suggests audio quality; no keys working suggests method mismatch.
- What method is each side using? Confirm both ends, do not assume they match.
- Is the system listening during the prompt? Try pressing after the prompt completes — if that works, allow barge-in.
- 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, 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.