Freeze one input attempt and channel timeline
Choose one authorized attempt and preserve timestamp and timezone, Asterisk version, Stasis application, WebSocket session, source endpoint, target channel ID, bridge ID and attributes, prompt or Playback ID, expected digits, observed events, application state and hangup or StasisEnd. Do not retry through a new call leg before reconciling the original one.
Classify the symptom: no DTMF reaches Asterisk, Asterisk raises no ARI event, an event reaches the wrong application or channel, a valid event arrives after the input window, the same source creates multiple events, the application processes one event twice, or outbound injection is accepted without a downstream result.
Prove Stasis ownership and event delivery
Confirm the exact channel entered the intended Stasis application and that its WebSocket connection was established for the affected interval. Match ChannelDtmfReceived by application and channel rather than by digit value alone. A channel snapshot retrieved later does not prove the controller received an earlier event.
The event is sent when the digit ends and carries digit and duration_ms; there is no corresponding ARI digit-start event in the documented model. Compare the application's timeout boundary with the event timestamp before calling the digit late or lost. Preserve any reconnect or application-replacement event that creates a gap.
Inspect the source transport before changing ARI
If no event exists, inspect the actual source leg. Record the loaded PJSIP dtmf_mode, SDP telephone-event negotiation where used, SIP INFO requests and responses, or authorized in-band audio evidence. A keypad beep heard locally is not proof that the endpoint transmitted a form Asterisk could decode.
Correct only the mismatched endpoint or carrier leg. rfc4733, inband, info, auto and auto_info are not interchangeable labels, and a mode that works on one leg does not establish the other. Keep codec and encryption changes outside the repair unless the evidence shows they own the in-band path.
Check bridge decoding and membership
If the affected channel is in an ARI mixing bridge, retain the bridge's requested attributes and the membership window. Direct or native packet sharing can keep media from being decoded inside Asterisk; the documented dtmf_events attribute prevents those mixing modes so DTMF events can be recognized.
A bridge may change mixing technology as participants join or leave. Compare a missing event with that topology transition, not merely the current bridge object. Do not add proxy_media or rebuild every bridge until the narrower DTMF-decoding requirement and its CPU or media consequences are understood.
Separate duplicate source events from duplicate processing
Retain every event's channel, digit, duration, timestamp, application and current input-generation ID. Compare those records with RTP telephone events, SIP INFO or in-band detection to determine whether Asterisk produced multiple channel events or the application handled one event more than once.
Use idempotent state transitions and retire listeners when a prompt, menu generation or channel ends. Do not de-duplicate solely by digit and a broad time window: 11, ## and other repeated input can be valid. A finish event from an old Playback must not reopen or advance a completed input state.
Diagnose outbound injection separately
For POST /channels/{channelId}/dtmf, retain the digit string, before, between, duration and after values plus the HTTP result. Resolve 400, 404, 409 or 412 against the documented missing-input, channel, Stasis and channel-state boundaries before altering timing.
If Asterisk accepted the operation, inspect the target leg and the receiving application. Prove the digits arrived in order and produced the intended bounded result. A 204-style successful request or absence of an ARI error does not establish that a remote IVR decoded or accepted the sequence.
Correct one owner, retest and remove sensitive traces
Change only the demonstrated owner: source DTMF transport, Stasis application or WebSocket, bridge decoding, channel correlation, timeout, listener lifecycle, application state or outbound timing. Repeat one authorized sequence and one known-good control, then confirm prompt interruption, state transition, downstream result and clean hangup.
Remove temporary SIP, RTP and application traces, redact digit values where required and retain only the evidence authorized by policy. No PBX, endpoint, event, digit, bridge, prompt 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 ARI handling DTMF events ↗
- Asterisk 22 ARI REST data models ↗
- Asterisk 22 ARI Channels REST API ↗
- Asterisk ARI bridge overview ↗
- Asterisk ARI mixing bridges ↗
- Asterisk 22 PJSIP endpoint configuration ↗
- Asterisk configuration for ARI ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.