DTMF Tones: Meaning, RFC 4733, and Fixes

DTMF (Dual-Tone Multi-Frequency) is the signaling system behind every telephone keypad: each keypress plays two sine waves at once — one from a low-frequency group, one from a high-frequency group — and the receiving equipment decodes that frequency pair back into the digit you pressed. Developed by Bell Telephone Laboratories in the early 1960s to replace rotary pulse dialing, DTMF tones are what an IVR hears when you “press 1 for sales.” On modern SIP trunks the tones usually do not travel as audio at all — they are re-encoded as RTP events or SIP messages, and that re-encoding is where digits get lost.

The frequency matrix comes first, then the three ways DTMF crosses a VoIP network, then the checklist we actually use when a customer says “callers press 1 and nothing happens.”

How each keypress becomes two frequencies

The keypad is a grid. Rows map to the low-frequency group (697, 770, 852, 941 Hz) and columns map to the high-frequency group (1209, 1336, 1477, 1633 Hz). Pressing a key plays its row tone and column tone simultaneously — 4 rows × 4 columns = 16 possible symbols:

	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 frequencies were chosen deliberately: no frequency is a harmonic of another, and no sum or difference of any two equals another frequency in the matrix. That is what stops a voice or hold music from accidentally registering as a digit — the failure the industry calls “talk-off.”

The A–D column exists on military and special-purpose keypads. Consumer phones never got those keys, but A–D remain valid DTMF events, and you will see them in signaling specs and SDP to this day.

One piece of history worth knowing because the trademark still circulates: the Bell System launched DTMF commercially as “Touch-Tone” on November 18, 1963 in Carnegie and Greensburg, Pennsylvania. The earliest sets had ten buttons; * and # were added later, and rotary dials persisted alongside Touch-Tone for decades.

Inband, RFC 4733, or SIP INFO: the three VoIP transports

On a VoIP call, a keypress at one end has to arrive intact at the other. There are exactly three ways to carry it, and mismatches between them are the single biggest source of dead IVR digits.

	Inband audio	RFC 4733 telephone-event	SIP INFO
Where it travels	Inside the RTP voice stream, as actual audio	Dedicated event packets in the same RTP stream	SIP signaling path, out of band
Negotiation	None needed	SDP offer/answer (telephone-event)	None formal — never standardized for DTMF
Codec sensitivity	Survives G.711 only; compression mangles tones	Immune — events are not audio	Immune
Timing vs audio	Exact	Exact (same media stream)	Can skew — signaling and media take different paths
Failure mode	Distorted tones, lost packets = lost digits	Silent failure on payload-type mismatch	Digits vanish if any hop doesn’t relay INFO

Inband means the tones are just sound inside the voice stream. Nothing to configure — and nothing to protect you. It works acceptably only on uncompressed codecs (G.711 ulaw/alaw), and every lost packet is a lost slice of tone.

RFC 4733 telephone-event is the industry default, and the one your PBX config almost certainly calls “RFC 2833.” Same mechanism: RFC 4733 (December 2006) explicitly obsoletes RFC 2833, but Asterisk’s dtmfmode=rfc2833 and a generation of field engineers kept the old name. Digits are sent as named events — codes 0–9 for the digits, 10 for *, 11 for #, 12–15 for A–D — in dedicated RTP packets carrying an event code, an end bit, a volume, and a duration. The final end-of-event packet should be sent three times so a single lost packet does not leave a digit stuck. Both sides must agree to it in SDP (a=rtpmap:101 telephone-event/8000 plus a=fmtp:101 0-15); if only one side offers it, digits get sent one way and ignored.

SIP INFO carries each digit as a SIP request on the signaling path, typically with Content-Type: application/dtmf-relay and a de facto body convention of Signal= and Duration= lines. It is human-readable in a SIP trace and immune to codec problems, but DTMF-in-INFO was never formally standardized — RFC 6086, which added the Info Package framework, says as much about the legacy usage — so interop is inconsistent, every signaling hop must relay it, and its timing can drift relative to the audio. It survives mostly as a fallback when telephone-event negotiation fails; Cisco gateways behave exactly this way.

SIPNEX trunks use RFC 2833/telephone-event as the standard DTMF method — the same recommendation in our SIP trunk configuration guide, and consistent with the DTMF entry in our VoIP glossary.

Why digits die on compressed codecs

G.729 compresses speech to 8 kbps by modeling the human vocal tract: 10 ms frames, 80 bits each, prediction tuned for voice. A pure pair of sine waves is not voice. The codec re-synthesizes the tones with enough distortion that a far-end detector may or may not recognize them — fine for a demo, unacceptable for a production IVR. The same class of failure hits fax and modem tones, and packet loss on a congested WAN compounds it. Our G.711 vs G.729 comparison covers the trade-off in full.

The rule of thumb: inband DTMF survives G.711 and dies under compression. If a compressed codec is anywhere in the call path, RFC 4733 telephone-event is mandatory, not optional.

The other quiet killer is the payload type. telephone-event uses a dynamic RTP payload type from the 96–127 range. 101 is the overwhelming convention — Cisco and Asterisk/FreePBX both default to it — but it is convention, not standard, and some carriers use 96 or 97. The number is declared per-call in SDP, and a mismatch or asymmetry between trunk legs is a classic cause of one-way or completely dead DTMF. SBCs routinely re-map payload types (96 to 101, for example) to interwork two legs that disagree.

Timing matters too. ITU-T Q.24, the legacy-switch survey cited in the RFC itself, puts the minimums at 40 ms of tone, 40 ms of inter-digit pause, and no less than 93 ms per digit cycle. Callers who key ahead faster than the far-end detector’s thresholds get digits silently dropped — the “fast dialing into an old IVR” problem.

The IVR digit-failure checklist

When digits fail on a SIP trunk, work this list in order. Every item is a failure we see in the wild:

1. Method mismatch. Your PBX sends inband while the far end expects telephone-event, or vice versa. Read the SDP in the INVITE and 200 OK — is telephone-event offered and answered on both legs?
2. Payload type mismatch. One leg says 101, the other says 96. Audio is perfect, DTMF is dead. Fix at the SBC or align both configs.
3. Compressed codec + inband. G.729 negotiated while DTMF rides inband. Force RFC 4733 or pin the call to G.711.
4. Double-sending. The endpoint sends inband audio and telephone-event simultaneously — the IVR hears every digit twice. Disable one.
5. SIP INFO not relayed. A proxy or SBC in the signaling path swallows INFO requests. Audio works; digits vanish.
6. Lost end-of-event packets. Packet loss eats the end packet and the IVR sees a stuck or repeated digit. RFC 4733’s triple end-packet transmission mitigates this but cannot eliminate it on a lossy path.
7. Digits too short or too fast. Below Q.24’s 40 ms minimums, detectors miss keypresses. Slow the dialing or lengthen the configured digit duration.
8. Transcoding leg drops events. When an SBC transcodes media, it must regenerate telephone-event on the new leg. Some configurations forget.

Verification is the same in every case: take a packet capture, filter for RTP event packets (Wireshark decodes telephone-event natively) or SIP INFO bodies, press one digit, and confirm it appears exactly once on each leg. One capture beats an hour of config guessing. If you are new to reading the signaling side, start with how the SIP protocol works.

Frequently asked questions

What does DTMF stand for and what does it mean?

DTMF stands for Dual-Tone Multi-Frequency. It means every keypress transmits two simultaneous sine waves — one from a low-frequency row group (697, 770, 852, 941 Hz) and one from a high-frequency column group (1209, 1336, 1477, 1633 Hz). The receiver decodes the unique pair back into the key. It replaced rotary pulse dialing and is still how IVRs, voicemail systems, and conference bridges read your keypad input.

Is RFC 2833 the same as RFC 4733?

Functionally, yes. RFC 4733 (December 2006) obsoletes RFC 2833 and describes the same mechanism: DTMF digits carried as named telephone-event packets inside the RTP stream instead of as audio. The differences are housekeeping — RFC 4733 set up an IANA event registry, kept only the basic event codes, and dropped RFC 2833’s flash-hook event (code 16). PBX settings named “RFC 2833” configure exactly this mechanism, so the old name persists in nearly every vendor UI.

Why do DTMF tones fail on G.729?

G.729 compresses audio using a predictive model built for human speech. Pure dual sine tones are not speech, so the codec re-synthesizes them with distortion, and the detector at the far end frequently fails to recognize them. If G.729 or any compressed codec is in the call path, DTMF must be carried out of the audio — as RFC 4733 telephone-event packets or SIP INFO — or the call must be pinned to G.711.

What is RTP payload type 101?

It is the dynamic RTP payload type conventionally assigned to telephone-event, declared in SDP as a=rtpmap:101 telephone-event/8000. Any value in the 96–127 dynamic range is legal — 101 is only the dominant convention (Cisco, Asterisk, and FreePBX all default to it), and some carriers use 96 or 97. When two legs of a call disagree on the payload type and nothing re-maps it, audio works fine but DTMF silently dies.

Why does my IVR receive doubled digits?

The sending side is emitting DTMF twice — as inband audio in the voice stream and as telephone-event packets at the same time. The IVR detects both and registers each keypress as two digits. Disable one method on the endpoint or trunk. A packet capture confirms it quickly: one keypress should produce either audio tone energy or RTP event packets, never both.

---

SIPNEX trunks negotiate RFC 2833/telephone-event DTMF with G.711u as the primary codec, so IVR digits arrive intact by default — see the exact settings in our SIP trunk configuration guide. If digits are dying somewhere between your PBX and your current carrier, test a SIPNEX trunk against the same call flow, or start with our published rates.