Define which ARI boundary failed
Record one call or locally originated test channel with the exact time, channel name or unique ID, dialplan context, extension, priority, Stasis() application name and observed result. Keep four failures separate: the client cannot reach the HTTP service, HTTP authentication or authorization fails, the event WebSocket does not register the named application, or the application receives StasisStart but its own logic fails.
A successful REST request proves neither an event subscription nor control of a particular channel. Likewise, a healthy WebSocket registered for one application does not own a differently named Stasis() target. Preserve status codes, close codes and the first specific Asterisk and application errors without logging passwords, bearer material or complete production URLs containing credentials.
Prove the loaded dialplan and Stasis result
Inspect the loaded dialplan for the exact context, extension and priority reached by the channel. Confirm the application name byte for byte, including case, punctuation and any generated prefix. Asterisk documents Stasis(app_name,[args]); the arguments are application data and do not change which application must be registered.
On completion, inspect the channel variable STASISSTATUS. Current Asterisk documentation defines SUCCESS and FAILED; failure reasons can include an unregistered or inactive requested application or inability to send the start message. Capture that value before later dialplan steps overwrite context or end the channel. Do not add a delay, answer the call or loop back into Stasis() merely to hide an ownership failure.
Verify HTTP, ARI and module state independently
ARI uses Asterisk's built-in HTTP server, which is configured separately in http.conf; Asterisk documents that the HTTP server is disabled by default. Confirm the intended bind address, port and TLS listener from the running service, then confirm res_ari and the required ARI resource modules are loaded. Inspect the effective ari.conf user, read-only setting and access controls without printing the secret.
A reachable /ari/ response, an authenticated read request and a WebSocket upgrade are three different checkpoints. Prefer HTTPS and WSS for production, restrict network exposure and origins, and keep any reverse proxy's path, upgrade headers, timeouts and certificate ownership in the evidence. Do not expose ARI directly to browser code; Asterisk's overview recommends keeping it behind the application server.
Prove the exact application registration
For the historical inbound model, the external application connects to /ari/events and supplies the intended app name. Asterisk registers that application on the event WebSocket; when a channel enters the same named Stasis() application, it emits StasisStart. If no WebSocket has been connected for that application, Asterisk documents that the channel is immediately ejected and dialplan execution resumes.
Record the connection owner, authenticated ARI user, application name, subscription scope, upgrade result and first event. Do not infer registration from the process being alive or from a health endpoint. A typo, a connection that registered a different app, a failed upgrade, a proxy idle close and an application crash can produce similar call symptoms but require different repairs.
Keep inbound and outbound WebSocket models versioned
Current res_ari documentation lists outbound-WebSocket configuration from Asterisk 20.15.0, 21.10.0 and 22.5.0 onward. That path uses an outbound_websocket object in ari.conf plus a matching websocket_client.conf object. It is not the same as an external client initiating the historical inbound event WebSocket. Confirm the running branch and loaded configuration reference before using it.
A persistent outbound connection registers its configured applications, while a per-call connection creates an ephemeral application when Stasis() is invoked. The outbound guide documents that one Stasis application can be served by only one WebSocket connection, duplicate registration can invalidate a connection object, and a per-call connection that exhausts reconnection attempts returns with STASISSTATUS=FAILED. Move an application between connections in the documented staged reload sequence rather than trying to claim it from two owners.
Validate lifecycle, loss and rollback
After the supported configuration or application change, connect the event path first, prove the exact registration, and then send one authorized test channel into the intended dialplan branch. Retain StasisStart, the matching channel ID, the first successful bounded control action, application logs and StasisEnd or explicit exit. A start event proves handoff, not that playback, bridge, recording, external media or business logic succeeded.
Test a control application or unaffected route, then deliberately stop only the authorized test client and confirm the documented fallback or failure behavior without risking production calls. Roll back the authoritative dialplan, ari.conf, websocket_client.conf, proxy or application change if the control regresses. No Asterisk host, branch, module, configuration, credential, application process, proxy, WebSocket, dialplan, channel, media path or live call was inspected or tested for this guide.
Diagnose an originated channel that never reaches Stasis
For POST /channels, first retain the returned snapshot and requested channel ID, then prove the exact app-directed request, registered WebSocket and matching StasisStart. For create-then-dial, also prove POST /channels/create succeeded and that the later channel dial was issued. A 2xx response at either HTTP boundary is not evidence that the application received channel ownership.
If no WebSocket is connected, Asterisk can return a channel from Stasis to the dialplan immediately; if an earlier connection broke, the client can miss events. Reconcile server-side channel lifecycle evidence before retrying. Use the ARI channel-origination guide for the request fields, IDs and staged lifecycle.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk ARI configuration ↗
- Asterisk Getting Started with ARI ↗
- Asterisk 23 Stasis application reference ↗
- Asterisk ARI outbound WebSockets ↗
- Asterisk current res_ari configuration reference ↗
- Asterisk ARI overview ↗
- Asterisk 23 ARI Channels REST API ↗
- Asterisk introduction to ARI and channels ↗
- Asterisk ARI channel-state operations ↗
- Asterisk ARI bridge operations ↗
- Asterisk ARI basic mixing bridges ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.