FreePBX IVR keypress is ignored or reaches the wrong destination

Classify the symptom on one exact IVR call

Choose one authorized affected call and preserve its timestamp and timezone, caller and called identities, inbound route, Time Condition or other upstream destinations, exact IVR name, prompt state, source endpoint or carrier, entered sequence and observed result. Prove the call reached this IVR before changing its options. A caller hearing a familiar recording does not establish which duplicate recording, parent menu or generated IVR context owns the call.

Separate five symptoms: Asterisk never receives a digit; it receives a different or duplicate digit; it receives a correct digit but waits; it classifies the sequence as invalid or timeout; or it chooses the expected branch but the downstream destination behaves unexpectedly. Retain the current FreePBX, Asterisk and IVR module versions, applied configuration state and a screenshot or export of the managed menu before repair.

Prove digit reception before changing the menu

Use a short, bounded Asterisk log channel that includes the DTMF level and the PJSIP logger for one test. Confirm whether the exact channel records each digit once and in order. For RFC 4733, preserve the offer and answer telephone-event mapping; for SIP INFO, preserve the request and response; for in-band behavior, preserve the negotiated codec and media path without treating an audible local key tone as remote evidence. Stop high-volume or sensitive debugging after capture.

Compare the effective PJSIP DTMF mode on the ingress endpoint or trunk with the actual signaling. Asterisk documents rfc4733, inband, info, auto, auto_info and none as distinct modes. Direct media and later re-INVITEs can change whether Asterisk is able to observe media-based digits. Correct a proven call-leg mismatch rather than enabling several methods or changing codecs indiscriminately.

Follow received digits through IVR matching and timing

When Asterisk receives the correct digit, inspect the loaded FreePBX-generated IVR context without editing generated files. Asterisk's Background() listens during prompt playback and matches extensions in the current context; WaitExten() continues waiting afterward. Preserve the current response timeout, digit timeout, valid single- and multi-digit entries and the moment the caller entered each digit. A valid prefix can wait for another digit, while a timeout is different from an invalid completed sequence.

Compare the entered value with the exact managed IVR entries. Do not infer the branch from the spoken announcement: a prompt can be stale after menu changes. Submit and Apply Config ownership is separate from file content and loaded dialplan state. If the generated branch is missing, correct the managed entry or applied configuration; do not add a hand-written extension to the generated context.

Separate menu entries from direct dialing and retry policy

Sangoma documents direct dialing as a separate IVR policy that can be disabled, enabled broadly or restricted through a directory. A multi-digit extension can therefore be invalid even when its digits arrived correctly. Record whether the caller attempted a configured menu entry, a permitted extension or a number outside the selected directory; do not enable broad direct dialing merely to make one test succeed.

Keep invalid and timeout paths separate. Preserve invalid retries, timeout retries, retry recordings, append-announcement settings, parent-IVR return behavior and the final invalid and timeout destinations. A repeated prompt can be the configured retry path rather than lost DTMF. Parent return can also produce surprising results when the actual preceding IVR differs from the assumed parent. Test no input, a deliberate invalid sequence and exhausted retries independently.

Verify the selected destination and bounded repair

After the IVR selects an expected entry, follow the generated destination into the actual extension, ring group, queue, voicemail, announcement or nested IVR. A digit can be recognized and mapped correctly while the downstream target is unavailable, redirected or governed by its own timeout. Preserve the branch transition and destination result rather than reopening the DTMF investigation.

Correct only the demonstrated owner: ingress DTMF mode or negotiation, direct-media path, IVR digit timing, managed entry, direct-dial policy, retry behavior, applied configuration or downstream destination. Retest digits during and after the prompt, single- and multi-digit entries, permitted direct dialing if used, invalid input, silence, retry exhaustion and each production branch through an authorized test route. No PBX, module, endpoint, trunk, generated dialplan, prompt, destination, RTP event, SIP INFO request, in-band tone, digit or live call was tested for this guide.

Separate a local FreePBX menu from a far-side IVR

If the FreePBX IVR never receives a digit, stay on its ingress leg. If Asterisk receives the digit and a remote IVR is the failing consumer, use the PJSIP DTMF mismatch diagnostic to prove the egress method and bridge owner before changing the managed trunk setting.

Continue from the IVR branch into a Misc Destination

When the selected branch is a Misc Destination, follow the Misc Destination diagnostic through its stable record ID, generated handoff, exact digits and final route or feature owner.

Use the Asterisk application boundary beneath a generated IVR

After proving which FreePBX IVR generated and loaded the route, the Asterisk BackGround diagnostic separates channel DTMF, application options, destination context, match order and timeout at runtime.