Asterisk ARI events are missing, duplicated or delivered to the wrong client

Freeze one expected event and its resource

Choose one event type, ARI application, Asterisk instance, resource ID and bounded time window. Record whether the symptom is no raw WebSocket message, more than one raw message, a message on another client, a parsed message with no handler action or one handler action repeated downstream. Preserve the REST request and response only when they are part of the same scenario.

Retain the event type, application, timestamp, optional asterisk_id, channel or bridge IDs and client connection identity. Similar JSON bodies across two logs are not automatically duplicate server emissions, and one accepted REST request is not evidence that any event was delivered.

Prove application registration and one active owner

Confirm the HTTP service, ARI authentication, WebSocket upgrade and exact app name independently. Asterisk says a channel entering Stasis() needs a WebSocket connected for that application; otherwise it is returned to the dialplan. For an application that was previously connected, a break can instead create a period in which events are missed.

Search server and client logs for ApplicationRegistered, ApplicationUnregistered and ApplicationReplaced. The data model documents that a newer WebSocket wins when two connections subscribe to the same application, while the older one receives ApplicationReplaced. Stop unintended owners before treating the winning client as silent or the losing client as a second valid observer.

Compare expected resource scope with the current Application state

Determine whether the event should arise from a channel automatically subscribed during Stasis ownership or from an explicit source such as channel:, bridge:, endpoint: or deviceState:. Retrieve the Application state and compare its exact resource URIs. A readable resource is not necessarily an event source for this application.

If subscription failed, preserve the documented response: 400 for a missing parameter, 404 for an absent application and 422 for a source that does not exist. For unsubscribe, keep 409 for a source that was not subscribed distinct from a successful removal. Do not add subscribeAll merely to bypass a malformed or stale resource ID.

Inspect subscribeAll and event filters independently

Record whether the event connection used subscribeAll=true. The Events API says that broad scope effectively disables application-specific subscriptions; it changes the evidence model rather than supplementing one source. If false, the exact application and resource relationships remain decisive.

Retrieve the application's event filter and compare the case-sensitive expected type with both allowed and disallowed lists. The filter API begins at Asterisk 13.26.0 and 16.3.0, so confirm the running branch before assuming a request or stored state behaves like current documentation. Preserve the filter body before making a bounded correction.

Follow the message through transport and client state

Correlate the Asterisk state change with the raw WebSocket frame, connection-open interval, proxy or load-balancer path, close code, client parse result, handler registration and application state transition. A raw event that the client ignored belongs to application logic; an absent raw frame with correct scope and filter belongs earlier in the delivery path.

On reconnect, inspect whether the client registered handlers twice, replayed durable work, retained stale in-memory resource state or opened another socket for the same app. Make downstream operations idempotent with application-owned correlation. Do not discard messages solely because their event type and resource match; repeated state changes can be legitimate.

Correct one owner and retest lifecycle boundaries

Correct only the demonstrated owner: application name, WebSocket upgrade or timeout, competing connection, resource URI, broad subscription, event filter, parser, handler lifecycle, reconnection logic or downstream idempotency. Retest registration, one expected event, one deliberately unrelated event, unsubscribe where applicable, reconnect and a neighboring unaffected ARI resource.

Restore temporary broad scope and verbose logging, redact credentials and call data, and record the running version and rollback. A received event proves delivery to one application connection; it does not prove business processing, media, a completed call or external side effects. No Asterisk host, ARI user, application, WebSocket, subscription, filter, event, resource, client handler or call was inspected or tested for this guide.

Narrow missing ARI talking events at the detector boundary

When the absent event is ChannelTalkingStarted or ChannelTalkingFinished, use the TALK_DETECT diagnostic to prove channel media and thresholds before subscription or reconnect handling.