Troubleshooting · Symptoms
DTMF Not Working: When Menus Can't Hear Your Keypresses
'Press 1 for sales' — you press 1, and nothing happens. DTMF, the keypad signaling that drives IVRs, voicemail menus and conference PINs, has three mutually incompatible ways to travel over VoIP, and the failure mode is always the same: the two ends picked different ones, or the tones were destroyed by a codec on the way.
Unlike audio faults, DTMF failures are deterministic: find the mismatch and every press works, every time. A capture shows DTMF events (or their absence) explicitly.
The three transports
| Method | How it travels | Strengths / failure modes |
|---|---|---|
| RFC 2833 / 4733 (telephone-event) | As special RTP packets alongside audio, negotiated as a payload type in SDP (e.g., telephone-event/8000) | The standard. Fails when: not negotiated in SDP, payload type mismatch, or an SBC strips it |
| SIP INFO | As SIP messages mid-call carrying the digit | Simple; support varies — some providers/IVRs ignore INFO entirely |
| Inband | As actual audio tones inside the voice stream | Works only on G.711 (uncompressed); G.729 and other speech codecs distort the tones into unrecognizability |
Reading the failure
In a capture, filter for RTP events: Wireshark decodes telephone-event packets and even names the digit. No event packets when you press keys → the phone isn't generating 2833 (setting off, or it negotiated inband onto a compressed codec). Events leave your phone but the IVR still ignores them → something mid-path strips or renumbers the payload type (compare SDP at both ends: the telephone-event payload type, often 101, must be consistent through any transcoding/SBC), or the far IVR expects a different method. Digits doubled or extended (menus jump two levels) → both inband audio AND 2833 are being delivered, and the receiver hears both — force one method end-to-end. Conference bridges and banking IVRs are the usual witnesses because their detection is strict.
Fix sequence
- Identify where DTMF fails: all IVRs or one? Voicemail on your own system or external? One strict external IVR plus working internal voicemail is a negotiation mismatch signature.
- Standardize on RFC 2833/4733 end-to-end: enable it on phones, PBX and trunk; confirm SDP in a test call offers telephone-event and note the payload type.
- If any leg forces G.729, either move DTMF fully to 2833 on that leg or expect inband to die there — there is no third outcome.
- Disable parallel methods: pick ONE method per path to prevent double-digit delivery; most SBCs/PBXs have a DTMF mode setting per trunk — set it deliberately rather than 'auto' everywhere.
- Test against a known-strict IVR (a bank or the provider's own voicemail) pressing every digit including * and #, and confirm single, correct registration of each.
Frequently asked questions
- Why does voicemail on our own system work but external IVRs fail?
- Internal paths are homogeneous — your PBX and your phones agreed long ago. External calls cross your trunk and another organization's SBC/IVR, adding two more negotiation points and often a codec change. The fault lives at a boundary, which is why internal tests pass.
- Keypresses work at the start of a call but not after hold/transfer.
- The media path changed: a transfer or hold/resume renegotiated SDP (or moved the call through a different gateway) and the DTMF terms changed with it. Capture across the transfer and compare the telephone-event negotiation before and after.
- Is SIP INFO ever the right choice?
- When a specific provider or legacy IVR requires it — it exists because some ecosystems standardized on it. The rule is not 'always 2833' but 'one method, consistent end-to-end, matched to the strictest receiver you call'.