Freeze one failed digit path
Record timestamp and timezone, installed Asterisk release, exact caller and callee channels, unique and linked IDs, endpoint names, endpoint dtmf_mode, runtime values before and after the write, handler location, digit sequence, direction, expected consumer and observed result. Preserve a sanitized control call.
Classify the first mismatch: function unavailable, non-PJSIP owner, write on the wrong leg, handler did not run, unsupported value, endpoint and override confused, peer did not advertise the method, no protocol event, digit received but not forwarded, or downstream IVR handling failed.
Prove function support and the selected channel
Confirm the installed branch exposes PJSIP_DTMF_MODE(); current documentation lists it since 13.18.0, 14.7.0 and 15.1.0. Run the read on the exact PJSIP leg. An empty result on a Local, DAHDI or already-destroyed channel is not evidence that the endpoint lacks DTMF policy.
Use CHANNEL(endpoint) and the channel driver to prove ownership. Compare caller and callee legs explicitly rather than moving the same write through several contexts until a test happens to work.
Compare endpoint policy with the runtime value
Read the loaded endpoint dtmf_mode and the current leg value before the override. Apply one documented mode and read the leg again immediately. If the function value changes, preserve that as channel-state evidence only; do not yet claim that the next digit used that method.
For outbound calls, prove the lowercase callee pre-dial handler executed on every intended destination and returned. A caller-side write and a callee-side write are not interchangeable.
Find the first missing protocol event
For rfc4733, compare SDP telephone-event advertisement, negotiated payload type, digit event, duration and end packets. For info, preserve the INFO request and response. For inband, confirm the audio and codec path can carry the tones. For auto or auto_info, record the advertised support that controlled the fallback.
Do not equate audible tones with RFC 4733 packets, a SIP INFO request with an RTP event or an endpoint mode with negotiated peer support. Direct media and transcoding can move or alter the observation boundary.
Follow the digit across bridge and application boundaries
Compare AMI DTMF begin and end events on the sending and receiving channels, including direction and duration. Then inspect the exact IVR, feature, bridge or application consumer. A Received event on the ingress leg does not prove a Sent event on the egress leg, and a Sent event does not prove the remote IVR accepted the digit.
If digits double, look for two demonstrated sources rather than shortening all durations. If digits disappear, stop at the first leg or consumer without evidence.
Correct one boundary and retest the same call
Correct only the demonstrated owner: function availability, channel selection, pre-dial timing, endpoint mode, runtime value, SDP support, SIP INFO handling, audio path, bridge forwarding or downstream IVR. Repeat the same call and digit sequence, then verify an unrelated control that must remain unchanged.
Restore temporary overrides and logging after the test. Do not retain account PINs or sensitive menu digits in shared evidence. No PBX, endpoint, channel, SIP message, RTP event, audio stream, digit or call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk PJSIP_DTMF_MODE dialplan function ↗
- Asterisk res_pjsip endpoint configuration reference ↗
- Asterisk PJSIP_ENDPOINT dialplan function ↗
- Asterisk CHANNEL dialplan function ↗
- Asterisk Dial application and pre-dial handler guidance ↗
- Asterisk AMI DTMFBegin event ↗
- Asterisk AMI DTMFEnd event ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.