Asterisk receives DTMF but the far IVR ignores or doubles it

Freeze one failed digit sequence

Choose one authorized call and record timestamp, timezone, linked channel identifiers, phone-facing endpoint, trunk-facing endpoint, destination IVR, prompt phase, entered digits and whether the symptom is missing, delayed, doubled or wrong digits. Include whether it begins only after hold, transfer, direct-media change or a later re-INVITE.

Asterisk logging one correct digit proves ingress reception, not egress delivery or far-menu consumption. A far menu repeating a prompt does not prove the digit never left Asterisk. Keep those stages separate.

Prove the ingress representation

Inspect the loaded ingress endpoint's dtmf_mode and correlate the evidence: SDP plus RFC 4733 event packets, a SIP INFO request and response, or the decoded audio path for in-band tones. Match the negotiated dynamic payload mapping to this call. Count starts, end indications and durations rather than treating every retransmitted event packet as another pressed key.

If Asterisk did not receive the intended digit, stop at the ingress owner. Compare the endpoint's actual sent method with Asterisk policy and the accepted SDP. Do not change the trunk or IVR yet.

Prove bridge and channel ownership

Map the phone-facing and trunk-facing channels at the moment of the keypress. A transfer, Local channel, ConfBridge, queue, recording or direct-media transition can change which channel or component owns the media and events. Preserve bridge membership and the final media path before assuming a static two-leg call.

If two representations arrive for one keypress, identify who generated each one. Enabling RFC 4733 and SIP INFO or an in-band duplicate at more than one boundary can cause doubled digits; remove only the demonstrated duplicate source.

Prove the egress representation

Inspect the loaded egress endpoint mode and the actual outbound evidence. For RFC 4733, retain the egress SDP mapping and packets. For SIP INFO, retain the exact method, body and response. For in-band tones, prove Asterisk produced audio that survived the selected codec and path.

An inbound RFC 4733 event need not leave with the same dynamic payload number, and the two legs need not use the same method. Judge the egress against that peer's negotiated and documented behavior, not against the ingress trace.

Move to application timing only after delivery

If the correct egress digit reaches the far side, investigate its IVR timing, valid choices, terminator behavior and input policy. A successful SIP response or received packet does not prove the far application accepted the digit within its collection window. Compare digits during the prompt, after the prompt and at a controlled pace.

Correct only the proven owner: ingress mode, bridge or media topology, duplicate generation, egress mode or far-application policy. Retest one digit, repeated digits, a multi-digit choice, the post-transfer path and a control call. No host, endpoint, trunk, IVR, bridge, event, tone, digit or live call was tested for this diagnostic.

Separate missing transport from a rejected menu match

If the correct DTMF event is already visible, continue with the BackGround digit diagnostic. It checks p and m, destination context, patterns and timeouts before changing the negotiated DTMF method.

Prove a runtime mode write before changing global policy

Use the PJSIP DTMF override diagnostic when the function value is empty, unchanged, set on the wrong leg or does not match the observed signaling method.