Asterisk WebSocket media is silent, one-way or disconnected

Classify the failing WebSocket first

Record the Asterisk version, channel unique ID, connection object, application instance, direction, selected codec, timestamp and hangup cause. State whether the WebSocket never opened, opened without MEDIA_START, answered without application media, carried media in one direction, accumulated a queue, or closed unexpectedly. Preserve the far call leg separately.

Confirm this is a WebSocket/... media channel. Browser WSS registration belongs to PJSIP, and a connected ARI event socket belongs to the control plane. Neither proves that chan_websocket created or exchanged application media.

Verify the installed capability and loaded objects

Confirm the running build includes and loads chan_websocket and res_websocket_client, then compare its generated help with the intended options. The base driver starts at Asterisk 22.6.0 on the 22 branch; JSON control format starts at 22.8.0. Treat options seen only in branch documentation or 22.12 release candidates as unavailable on final 22.11.0 until the installed CLI proves otherwise.

For outbound media, inspect the named per-call client object, URI, media subprotocol, authentication, TLS verification and connection result. For incoming media, prove the application used the current ephemeral connection ID and /media/<id> URI rather than a previous call's value.

Follow connection, answer and bridge in order

Correlate socket establishment with MEDIA_START, channel creation and channel answer. If the dial string uses n, the remote application or ARI must answer explicitly; without it, do not diagnose silence as a codec failure. Confirm the WebSocket channel actually joins the intended bridge and that the other leg remains active.

If ARI is involved, verify the Stasis application registration and channel ownership separately. Moving an ARI app between outbound connections can require a two-stage reload, but a media-only Dial path does not require ARI. Avoid reloading unrelated control connections while preserving a failing media channel.

Inspect opcode, format and frame sizing

Prove that audio uses binary frames and commands use text frames. Capture the MEDIA_START format, optimal frame size and packet time, then compare them with application message lengths and timing. A text audio payload is not media, and a binary ANSWER or buffering command is interpreted as media.

For a reframable codec, send exact optimal-size blocks or documented buffered bulk media. For Opus, Speex, G.729 or another passthrough case, the application owns valid codec packets and timing; generic raw PCM sizing will fail. Keep transcoding, decoding and far-leg negotiation separate from WebSocket delivery.

Prove backpressure before increasing buffers

Look for MEDIA_XOFF, MEDIA_XON, queue status, application send rate and any message larger than 65,500 bytes. Stop sending when XOFF arrives and resume only after XON. A full queue can drop later media, while an oversized message closes the WebSocket and hangs up the call. Increasing a network or application buffer without obeying protocol flow control can lengthen delay and preserve the failure.

If silence occurs without backlog, compare application bytes sent and received, generated-silence intervals, bridge media and the other leg. A connected socket with a growing application byte counter is not proof that correctly framed audible media reached Asterisk or the caller.

Apply one correction and retest the whole call

Correct only the demonstrated boundary: use the current connection ID, load the required module, select a supported control format, answer the deferred channel, send the correct frame opcode and size, switch to a compatible codec, or implement XOFF/XON handling. Preserve the old dialplan, client object and application release.

Repeat the same bounded call and record connection, MEDIA_START, answer, binary media both ways, queue state, bridge, far-leg audio and clean hangup. Remove temporary traces and credentials. Then test an unrelated SIP-over-WebSocket or ARI path only if the change could affect it. No host, application, socket, channel, frame, media result or call was tested for this diagnostic.

Confirm that External Media selected WebSocket

When the channel was created through /channels/externalMedia, first verify transport=websocket, encapsulation=none, the version floor and the intended connection type. The External Media diagnostic separates that selection and bridge membership from chan_websocket framing and flow-control failures.