DTMF not working in IVR? Causes and fixes that stick

Most IVR (phone menu that plays options and waits for key presses) touch-tone failures come from two things: the wrong DTMF (touch tones) mode and a lossy codec. Set DTMF to RTP events (RFC 2833/4733) now. Do it on your phone or PBX (your office phone system) and on the SIP trunk (the SIP line to your provider). Keep only G.711 (uncompressed phone audio) on IVR legs and place a 10-second “Press 1” test to confirm the IVR sees the digit in the logs or recording.

Start here: two quick fixes that solve most IVR DTMF problems

Lock one DTMF mode and one safe codec before you change anything else. These two changes fix most “press 1 IVR not working” complaints.

• Set DTMF to RTP events (RFC 2833/4733) everywhere: on the phone/softphone, your PBX, and the SIP trunk. Turn off in-band and SIP INFO for now so you don’t double-detect.
• Allow only G.711 on the IVR-facing legs. If your first leg is WebRTC/Opus, keep Opus there, but ensure the hop into the IVR negotiates G.711. Remove or de-prioritize G.729, AMR, GSM, and low-bitrate Opus on the path that reaches the IVR.

Make a fast test: build a simple IVR that says “Press 1 for a test message,” waits 3–5 seconds, then plays “Thanks.” Call it from a mobile and a landline. In your CDRs (call detail records), you should see an RTP DTMF event for “1.” The recording should have one clean beep, and the IVR should take the right branch. If it still fails, keep reading.

If you manage your own PBX or SIP trunk, run a sanity check on the trunk first so you know signaling and media are clean. See the checklist in How to test your SIP trunk. If your quick test works, keep those settings and move on to ring timers and routing.

DTMF not working in IVR: pick one DTMF mode end-to-end

DTMF (the “touch tones” from key presses) can travel three ways:

• In-band: tones ride inside the call audio. Simple, but any audio compression, noise, or echo can distort them.
• RTP events (RFC 2833/4733): tones go as small RTP packets outside the audio stream. This is the safest default for VoIP and WebRTC.
• SIP INFO: tones travel as SIP signaling messages. This can work if every hop allows it and does not proxy out the INFO body.

For inbound IVRs, start with RTP events. It is reliable on mixed networks and does not care what the audio sounds like. SIP INFO can be fine when both ends are under your control and no proxy strips it. In-band is risky on compressed codecs and across mobile networks, so use it only if you control every hop and must interop with a legacy system.

The rule that prevents most DTMF passthrough issues is simple: choose one DTMF mode and keep it constant on every SIP hop. Keep it the same from phone or browser agent to PBX, PBX to trunk, and trunk to the IVR platform. Do not enable in-band and RTP events at the same time. Double-detection makes IVRs see ghost digits or two presses for one key.

One more gotcha: if your IVR forwards to a plain phone, the IVR must collect digits before that phone rings. Once an agent’s voicemail answers, the IVR can’t hear digits anymore. Structure the menu so detection happens first, then routing.

Codecs and transcoding that eat digits

Codecs are how audio is packed for travel. Some crush detail to save bandwidth. That’s bad for tones inside the audio.

Keep G.711 only on legs that hit the IVR. G.711 is “full-rate” and preserves tone shape. De-prioritize or remove G.729, GSM, AMR, and low-bitrate Opus for those hops. If you must use Opus/WebRTC on the first leg from a browser, that’s fine as long as DTMF uses RTP events. Then the audio codec does not matter for digit delivery.

Transcoding is when the codec changes mid-call (for example, Opus to G.729 to G.711). Each change can blur tone edges and timing. Check your CDRs: if one leg shows G.729 and the next G.711, that hop transcodes. Many CDRs show negotiated codecs per leg. If you see multiple changes before the IVR, tighten your codec lists so G.711 wins early.

Retest after you lock the codec list on phones, PBX, and trunk. A successful test sounds like one short, clean beep per key. If you hear double beeps, long warbles, or clicks, you’re still mixing modes or codecs.

Ring timers, queues, and voicemail that steal key-presses

Even with the right DTMF mode and codec, your IVR can miss digits if routing takes the call away too soon.

Set the IVR digit timeout (the wait after the caller presses) to about 3–5 seconds. That keeps the menu from timing out mid-prompt. If your prompt is long, either shorten it or raise the timeout to match. Keep a low, simple background track under the prompt, or none at all. Loud music can drown tones on in-band systems.

Do not start ringing agents until after the IVR collects input. Early ring lets an agent’s voicemail grab the call before the digit lands. In a small clinic setup, let the IVR finish “Press 1 for appointments, 2 for billing,” capture the key press, then route to the right ring group.

Use 20–25 second ring legs to agents (or to buyers, if you sell calls). Shorter legs can yank the call out of the IVR into the next target too fast, especially if you chain several targets. If the call sometimes goes to voicemail, listen to a recording: if you hear “Hi, you’ve reached…,” your IVR is no longer in control and won’t hear any more digits. Move voicemail behind the IVR options or extend ring timers. You can also send overflow to a queue or a voicemail box that belongs to the IVR, not an agent’s mobile.

If you use time-of-day routing, be sure after-hours calls hit an IVR or a queue first. Sending them straight to a cell can trigger carrier voicemail. That swallows any attempt by the caller to press a key.

When it’s the caller’s phone or a far-end IVR

Not every DTMF problem is on your side. Some handsets and mobile networks clip tones under weak signal or Wi-Fi calling.

Have two outside testers call from different networks (for example, a mobile on one carrier and a landline). If only one fails, suspect the caller’s device or their carrier. Ask the caller to retry with Wi-Fi calling off or call from another line. If the caller’s phone or app offers a DTMF tone length setting, switch it to “long” and retry. If not, ask them to turn off speakerphone or use a different phone.

Depending on the app or network, DTMF is sent as in-band audio or as signaling (for example, RFC 2833 events or SIP INFO). The iPhone’s native dialer doesn’t let you choose the mode. VoIP apps handle this internally.

Outbound cases are different. If your agents can’t press keys on banks’ IVRs but your inbound menu works, the issue is on the far end or on the outbound path. Your inbound DTMF settings are not the cause. Check your outbound trunk’s DTMF mode and codec list separately.

Finally, keep prompts short and clean. Over-compressed or very loud music under a prompt can mask tones for in-band systems. If you record your own prompts, follow the tips in IVR prompts that callers understand.

Check the call path and logs to find the drop point

Before you change more settings, trace where the digit disappears. Draw the path: Caller → Business number → IVR menu → Router → Target → Voicemail. The IVR listens in the menu step. Routing takes over after a valid digit or a timeout.

Use live logs and CDRs to confirm whether RTP DTMF events arrive at the IVR. Many platforms show “DTMF 1 via RTP” at a timestamp. If events appear at your PBX but not at the IVR, the mismatch is between the trunk and the IVR platform. If events stop after the handset but before the PBX, fix the phone or LAN. Correlate four times for each test call: when the prompt ends, when the caller presses, when ring to an agent starts, and when any voicemail picks up. That timeline points to the exact hop that ate the digit.

If you are new to CDRs, this walkthrough helps: Read call logs and CDRs to debug fast. If your setup includes forwarding to external numbers, also run through the test call forwarding checklist to be sure ring legs and voicemail can’t pre-answer.

Run a clean end-to-end test and lock the settings

Build a one-option IVR: “Press 1 for a test message.” Set the digit timeout to 3–5 seconds. Turn recording on for this test. Make 5–10 calls from different networks and devices: two mobiles on different carriers, one landline, one softphone behind a firewall, one browser call if you use WebRTC. For each call, confirm in the logs that the IVR sees an RTP DTMF event, and that the call takes the right branch every time.

Write down the trio that works for you:

• DTMF mode: RTP events (RFC 2833/4733) end-to-end
• Codec list: G.711 only on IVR legs
• Ring timers: IVR collection first, then 20–25 second agent legs, with any voicemail behind the IVR

Do not mix modes later for “just one target.” That’s how intermittent bugs creep back months later.

On platforms like CallFlow, you control IVR prompts, the routing order (priority, weighted, round-robin, or simultaneous), schedules, queues, and you can inspect real-time logs. Your DTMF mode and codec choices live on your SIP endpoints and PBX, and on any trunk you bring.

If problems persist after these steps, open a ticket with your SIP trunk or platform support. Send two failed call examples with timestamps, calling numbers, the called number, and what digit was pressed. Include CDR screenshots that show codecs per hop and any DTMF events you saw. That gives the engineer a place to start.

Extra notes by region

DTMF modes are global, but mobile coverage and codecs differ by market. In the United States, G.711 PCMU is common to the edge. In India, the Philippines, Thailand, Bangladesh, and Pakistan, some mobile paths use heavy compression between towers and gateways. This is another reason to prefer RTP events for IVR capture. If you interop with legacy TDM gear in any country, test both PCMU and PCMA and keep the one that yields clean event logs.

What to do next

• Make the two quick changes: RTP events for DTMF and G.711 only on your IVR legs.
• Run the short “Press 1” IVR test and confirm in logs that digits land.
• Fix ring timers so the IVR collects before any agent leg rings, and agent voicemail can’t pre-answer.
• Keep a written record of the working DTMF mode, codec list, and ring timers.

If you need a clean place to host the IVR, route calls by schedule or buyer, and see live logs while you test, you can try CallFlow. Get a number and build an IVR in minutes when you sign up, or contact us.