Bell Labs introduced Touch-Tone in the 1960s to replace pulse (rotary) dialing. Each key plays two simultaneous sine waves, one from a low group and one from a high group, so a detector can tell keys apart even on a noisy analog line. The scheme is Dual-Tone Multi-Frequency: two tones, many frequencies. It remains the way callers talk to IVRs, enter PINs, and confirm transfers when speech recognition is unavailable or untrusted.
On analog loops the tones are simply audio. On packet networks that audio is fragile. Compressed codecs, packet loss, and echo cancellers can destroy or duplicate digits. The IETF defined a payload that sends the digit as a named event alongside the speech path (RFC 2833, later RFC 4733).
What DTMF is
A DTMF digit is not a protocol message in the analog world. It is two frequencies mixed for a minimum duration (historically at least about 40 ms on-key, with a gap between digits). Receivers look for a valid pair, not for speech-like energy. That is why you can sometimes talk through a menu without triggering it, and why a TV soundtrack can still false-trigger a poorly designed detector.
The 16-key layout includes 0-9, *, #, and A-D. Consumer phones omit A-D. Those four keys still appear in some radio and network-control applications. * and # are first-class digits for menus: 'press pound to confirm' is a DTMF #.
The frequency grid
| 1209 Hz | 1336 Hz | 1477 Hz | 1633 Hz | |
|---|---|---|---|---|
| 697 Hz | 1 | 2 | 3 | A |
| 770 Hz | 4 | 5 | 6 | B |
| 852 Hz | 7 | 8 | 9 | C |
| 941 Hz | * | 0 | # | D |
The high-group fourth column (1633 Hz) is the A-D column. * is 941+1209 Hz. # is 941+1477 Hz. 0 is 941+1336 Hz.
Transport: in-band versus RFC 4733
Three methods appear in production VoIP:
| Method | How it works | Strengths | Weaknesses |
|---|---|---|---|
| In-band audio | Tones are mixed into the G.711 (or other) audio stream | Works through analog gateways that know nothing of RFC 4733 | G.729 and other CELP codecs distort tones; loss hides digits; echo cancellers can clip them |
| RFC 4733 telephone-event | RTP payload type with named events (end bit, volume, duration) | Survives compression; standard for SIP and WebRTC insertDTMF | Both ends and every transcoding hop must pass the payload type; mismatch causes 'IVR deafness' |
| SIP INFO | DTMF in a SIP INFO body mid-dialog | Simple on some application servers | Travels outside the media path; proxies may block INFO; browsers do not send it natively |
Negotiation uses SDP: a=rtpmap:101 telephone-event/8000 and a=fmtp:101 0-16 (or 0-15). If the answerer omits telephone-event, the offerer may fall back to in-band. A SIP trunk that strips the payload type is a common cause of 'press 1 does nothing' tickets.
DTMF and IVR menus
An IVR collects digits to route a call: language, department, account number. Design constraints come from DTMF reliability, not from the prompt script. Allow an inter-digit timeout, accept # as a terminator for variable-length input, and re-prompt once if the detector hears nothing. Do not require ten-digit entry on a lossy mobile path without a confirmation step.
Speech recognition often runs in parallel. Dual-mode IVRs should define which input wins if the caller speaks and presses a key. DTMF is still the accessibility and noisy-room fallback.
WebRTC, SIP, and special events
Browsers expose RTCRtpSender.insertDTMF, which generates RFC 4733 events on the audio sender. There is no reliable 'play tones into the mic' equivalent that will survive Opus. SIP phones usually send telephone-event automatically when a key is pressed during an answered call (INFO is a configurable fallback).
RFC 4733 also defines events beyond the keypad (fax tones, country-specific signals). Most business voice systems only care about 0-9, *, #. Duration and end-bit handling matter: a long press should not register as twenty digits. Stacks that fire both in-band and telephone-event can double-enter a digit. Disable one path when you enable the other.