Separate received events from sent digits
ARI reports incoming DTMF with ChannelDtmfReceived. The Channels API sends digits with POST /channels/{channelId}/dtmf. These are different directions and different evidence: receiving a digit does not prove that an injected sequence reached another system, while an accepted send request does not prove a later application recognized the digits.
Preserve the running Asterisk version, Stasis application, WebSocket session, channel ID, call-leg identity, intended direction, source endpoint, expected sequence and application operation ID. Do not use a caller-facing display name or SIP account label as a substitute for the channel that raised or received the operation.
Treat ChannelDtmfReceived as an end event
The Asterisk 22 data model says ChannelDtmfReceived is emitted when DTMF ends and does not provide a start notification. It carries the channel, digit and duration_ms. Application timeouts and prompt interruption therefore need to account for end-event timing rather than treating key-down as immediately observable.
Correlate the event timestamp, application and exact channel with the current input state. Duration is an observation for that event, not proof of the caller's physical keypress length, the original transport or acceptance by a downstream IVR. A late event from a channel that has already left the current menu must not advance a newer state.
Keep PJSIP DTMF transport attached to the call leg
Asterisk PJSIP documents rfc4733, inband, info, auto and auto_info endpoint modes. Those choices describe how an endpoint leg sends or receives DTMF before ARI sees a normalized channel event. Record the loaded endpoint policy, negotiated telephone-event payload where applicable, SIP INFO transactions or decoded in-band audio for the actual leg.
A ChannelDtmfReceived event establishes that Asterisk raised one digit on one channel; it does not by itself identify whether the source used RTP telephone events, SIP INFO or in-band tones. Do not change codecs, media encryption or every endpoint's DTMF mode from the ARI event alone. Use the PJSIP DTMF diagnostic when the failure is upstream of ARI.
Choose bridge decoding deliberately
ARI mixing bridges can use direct or native packet sharing when that is the most efficient topology. Asterisk documents that features including DTMF may be unavailable when media bypasses decoding. Creating a mixing bridge with dtmf_events prevents those non-decoding modes so Asterisk can recognize DTMF; proxy_media also keeps media through Asterisk but has a broader media purpose.
Retain the bridge ID, requested attributes, members and topology before and after membership changes. The bridge can switch mixing technology as channels join or leave. A stable bridge object or audible conversation does not prove DTMF decoding was active for the interval that contained the digit.
Make prompt interruption idempotent
Asterisk's ARI example cancels menu playback when a digit arrives. Production code should keep the active Playback ID, input-generation or menu-state ID and the expected channel together. Stop the known playback once, tolerate a PlaybackFinished event that crossed the stop request in flight and ignore events that belong to a prior state.
Define behavior for rapid repeats, invalid digits, multi-digit collection, timeout, hangup, WebSocket reconnect and application restart. De-duplicate only with evidence such as event identity, channel, digit, duration and state window; two equal digits can be valid user input and must not be collapsed merely because their values match.
Bound outbound digit injection
The Channels REST API accepts a digit string plus optional delays before, between and after digits and an optional digit duration; the documented defaults for between-digit spacing and duration are 100 milliseconds. The API distinguishes a missing digit string, missing channel, channel outside Stasis and invalid channel state with 400, 404, 409 and 412 responses.
Record the exact sequence, target channel, timing parameters, response and target lifecycle. Then prove the far application or device received the intended digits in order. REST acceptance is not remote-IVR acceptance, and making digits longer or slower without a measured requirement can hide transport, state or target errors.
Protect digit content and prove the result
DTMF can carry account numbers, access codes and other sensitive input. Restrict ARI credentials and event subscriptions, minimize digit logging, redact support extracts and set an authorized retention period. Do not place reusable secrets in examples or expose ARI directly to an untrusted browser.
Acceptance should preserve the correct channel event or send response, expected application transition, prompt state, downstream result and clean hangup. Keep security, transport, media and application outcomes separate. No event, digit sequence, endpoint or call was tested for this guide.
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.