Freeze one channel and its media contract
Choose one authorized call and retain the running Asterisk version, requested channel ID, Stasis application, external_host, transport, encapsulation, connection type, format, direction, transport data and variables. Preserve the HTTP response and timestamp. Do not retry repeatedly while an earlier channel or external service may still be active.
Confirm the tuple is valid for the installed driver: RTP over UDP, AudioSocket over TCP or WebSocket with no encapsulation. A created channel with the wrong external destination or decoder can look healthy in ARI while carrying no useful audio.
Prove Stasis ownership and bridge membership
Find the matching StasisStart, then confirm the External Media channel and intended call channel are members of the expected bridge at the same time. A channel that exists but was never added to the bridge cannot observe or inject that bridge's media. A bridge object that exists does not prove the intended members stayed in it.
Retain ChannelEnteredBridge, removal, StasisEnd and hangup timing. If the application event connection was absent or broke, use the Stasis registration diagnostic before changing the media path.
Trace Asterisk-to-application media
For RTP, capture at Asterisk and the external host. Confirm that Asterisk sends standard RTP to the address and port resolved from external_host, that routing and firewall policy allow it, and that the application receives the expected source tuple and payload. An HTTP response or bridge event is not packet evidence.
For AudioSocket, prove the TCP connection and correctly parse the three-byte header, type and declared payload length. For WebSocket, confirm MEDIA_START and binary media frames using the WebSocket media diagnostic. Keep control-text failures separate from absent media frames.
Trace application-to-Asterisk media
For RTP injection, read UNICASTRTP_LOCAL_ADDRESS and UNICASTRTP_LOCAL_PORT from the actual External Media channel. Confirm the application sends valid, correctly timed RTP to that tuple and that Asterisk receives it. Do not return packets to the configured external destination by assumption.
For AudioSocket, verify the selected PCM type, frame length and endianness. For WebSocket, verify driver direction, optimal frame size, timing or buffering and XOFF/XON state. In every path, packets arriving at Asterisk remain separate from audio being accepted into the bridge and heard on the far leg.
Verify format and translation without guessing
The External Media format is explicit and is not negotiated. Compare it with the external application's encoder or decoder and the bridge channels' formats. Check that the required Asterisk translation modules are loaded and that the application is not treating RTP headers as audio, applying the wrong sample rate, swapping byte order or decoding a WebSocket or AudioSocket frame as another protocol.
Use a bounded known-file or tone test only when approved. Correlate the expected samples, captured packets, Asterisk translation state and decoded far-leg result. Packet counters alone do not prove intelligible audio or correct channel direction.
Correct one owner and retest the lifecycle
Change only the evidenced owner: driver tuple, destination resolution, bridge membership, return tuple, firewall rule, protocol parser, format, translation module, pacing, WebSocket flow control or application lifetime. Preserve ARI TLS and access restrictions; do not open broad UDP ranges or expose the media application as a shortcut.
Repeat one fresh call and retain channel creation, Stasis ownership, bridge entry, outbound and inbound media, decoded result, bridge removal and cleanup. Remove temporary captures and verbose logs when complete. No host, socket, packet, media stream or call was inspected or tested for this diagnostic.
Prove the bridge before debugging the media service
If the External Media channel will not stay in the intended bridge, use the ARI bridge diagnostic to reconcile Stasis ownership, add-channel errors and membership events before changing transport, format or packet handling.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk ARI Channels REST API ↗
- Asterisk External Media and ARI ↗
- Asterisk AudioSocket protocol ↗
- Asterisk WebSocket channel driver ↗
- Asterisk configuration for ARI ↗
- Asterisk ARI bridge operations ↗
- Asterisk ARI Bridges REST API ↗
- Asterisk bridges in a Stasis application ↗
- Asterisk ARI mixing bridges ↗
- Asterisk ARI holding bridges ↗
- Asterisk ARI data models ↗
- Asterisk ARI recording API ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.