DTMF that doesn't register — RFC2833 vs SIP INFO vs inband, and when each breaks

DTMF (the keypad tones — touch-tones) seems trivial until you hit a voice menu that ignores your key presses, an IVR that half-works, or a recording feature that won't trigger on *9. DTMF over VoIP is carried in one of three different ways, and mismatches between the call legs are the usual culprit.

The three DTMF transport methods

1. RFC2833 (a.k.a. RTP telephone-event)

• DTMF is encoded as named events in the RTP stream (payload type 101 by default).
• Compact, reliable, codec-independent.
• The standard default for SIP and basically every VoIP carrier.
• This is what you should use unless something forces otherwise.

2. SIP INFO

• DTMF is sent as SIP INFO messages — separate from the audio path entirely.
• Used by some older systems and certain carriers.
• Less efficient (each digit is a SIP transaction) but immune to codec or audio-path issues.

3. Inband

• The actual DTMF tones travel in the audio stream as sound.
• Works with G.711 (lossless enough to preserve the tones).
• Doesn't work with compressed codecs (G.729, Opus low- bitrate, GSM) — the compression mangles the tones unrecoverably.
• The default for analog telephone adapters connected to legacy equipment.

Common DTMF failure modes

"Calls work but IVR ignores my key presses"

Most common: one leg of the call uses RFC2833, the other uses SIP INFO. The keys get sent but nobody on the receiving end is listening for them.

Check both ends. In FreePBX®:

• Trunk → Advanced → DTMF Mode = RFC2833 (or whatever the carrier requires).
• Extension → Advanced → DTMF Mode = RFC2833.

If the carrier uses SIP INFO, set BOTH to "auto" — Asterisk negotiates per call.

"Some keys register, others don't"

Almost always inband DTMF over a compressed codec. The codec quietly mangles certain tones (high-frequency dialpad keys) more than others.

Fix: switch to RFC2833 (rfc4733 in some docs).

"Double digits — pressing 1 produces 11"

Both RFC2833 AND inband detection are enabled, so each key gets counted twice. Set DTMF mode to a single explicit method.

"IVR works on incoming calls but not on outgoing"

Different DTMF mode on the outbound trunk vs the inbound context. Pick one method (RFC2833) and set it consistently.

"It worked yesterday, doesn't work today"

Recent codec change. Did you switch a trunk from G.711 to G.729? Or did the carrier renegotiate? Check the call's actual codec via pjsip set logger on and compare to before.

Diagnosis from Asterisk CLI

asterisk -rvvv
pjsip set logger on
core set verbose 4

<make a test call to an IVR or to *9 to record>
<press keys>

You should see lines like:

VERBOSE[12345] chan_pjsip.c: Got DTMF '5' from endpoint 1001
VERBOSE[12345] pbx.c: Executing [s@ivr-menu:3] WaitExten("PJSIP/1001-00000001", "5")

If you press 5 and don't see "Got DTMF '5'", Asterisk isn't receiving DTMF. Check:

• Phone DTMF setting matches Asterisk DTMF mode.
• For RFC2833: the RTP payload type matches (default 101).
• For inband: the codec is G.711.

Phone-side configuration

Each phone's web UI has a DTMF method setting. Recommended:

• Polycom: Settings → Voice → Codecs → DTMF Method = RFC2833.
• Yealink: Account → Codec → DTMF Type = RFC2833.
• Grandstream: Account X → Audio Settings → DTMF mode = RFC2833.
• Cisco SPA/ATA: Voice → SIP → DTMF Method = RFC2833.

Set the same DTMF method on every endpoint and on every trunk for consistency.

When inband is the only option

Occasionally you have a legacy device (an old fax machine, a voice-prompt interactive system from a carrier) that only sends DTMF inband. To accept it:

• Set the relevant extension/trunk to "auto" or "inband" DTMF mode.
• Force the codec to G.711 — no G.729, no Opus low- bitrate.
• Enable Asterisk's inband detector: dtmfmode=inband in the relevant config.

Test with the actual device. Inband DTMF reliability over VoIP is notably worse than RFC2833 — you'll see occasional missed digits even when it's working.

RFC2833 payload type mismatch

RFC2833 uses an RTP dynamic payload type. The default is 101 but some endpoints use a different number. If both ends are configured to use RFC2833 but with different payload types, DTMF silently fails.

Check /etc/asterisk/rtp.conf:

[general]
rtp_telephone_event_pt=101

And the phone's RFC2833 payload type setting. Set both to 101 (or whatever you prefer — just match).

Quick reference

Symptom	Most likely cause
Keys do nothing in IVR	DTMF mode mismatch between trunk and extension
Some keys work, others don't	Inband over compressed codec
Each key registers twice	Inband + RFC2833 both enabled
Works inbound, not outbound	DTMF mode inconsistent between contexts
Worked, now broken	Codec change or carrier renegotiation