VoIP.info Guide

Asterisk ARI External Media: channel, driver and bridge boundaries

Choose the RTP, AudioSocket or WebSocket driver tuple, fix the media format, join the intended bridge and prove both media directions independently.

Reviewed 2026-10-09Current first-party Asterisk ARI Channels, External Media, AudioSocket, WebSocket, ARI configuration and bridge documentation reviewed October 9, 2026; no HTTP server, ARI user, Stasis application, channel, bridge, host, socket, DNS answer, firewall, RTP packet, AudioSocket frame, WebSocket frame, codec, transcription service, media stream or call was inspected or testedAdvancedDocumentation based · not lab tested

Treat External Media as an ARI channel

POST /channels/externalMedia creates a channel for a media source or sink and places it in the named Stasis application. It does not automatically attach that channel to the caller or conference whose media the external service needs. Create or identify the intended bridge, add the External Media channel and retain the channel and bridge identifiers separately.

The returned channel object, StasisStart, bridge membership, outbound packets, inbound packets and usable far-leg audio are separate acceptance states. Deleting the External Media channel hangs it up; application cleanup must also account for the bridge and other channels it owns.

Select a valid transport and encapsulation pair

The current ARI reference maps udp plus rtp to chan_rtp, tcp plus audiosocket to chan_audiosocket, and websocket plus none to chan_websocket. Do not choose each field independently or assume every transport supports server mode. The API documents server connection type only for WebSocket; its public direction field currently allows both.

Record the running Asterisk version, loaded driver, exact transport, encapsulation, connection type, external host and transport-specific data. An HTTP 2xx response proves parameter acceptance and channel creation, not socket establishment or media delivery.

Fix the format before media starts

External Media requires a format. The original RTP design explicitly has no codec negotiation: Asterisk transcodes bridge media into the requested format. Preserve the requested format, the bridge's native formats, translation path and the external application's decoder or encoder rather than guessing from payload size.

RTP adds its standard header and makes packet timing, payload interpretation and return addressing application responsibilities. AudioSocket uses a framed TCP protocol whose type byte distinguishes UUID, DTMF, PCM variants, termination and errors. WebSocket uses binary media frames plus case-sensitive text control messages and has its own re-framing and pacing rules.

Prove both RTP directions from their real tuples

For RTP over UDP, external_host is the destination to which Asterisk sends media. A hostname is allowed, but the original implementation notes that its synchronous DNS lookup can delay the request. Record the resolved address and timestamp instead of treating the hostname as a permanent route.

For media injected back into the bridge, the UnicastRTP channel exposes UNICASTRTP_LOCAL_ADDRESS and UNICASTRTP_LOCAL_PORT. Fetch those channel variables through ARI and send to that tuple. Do not assume that the configured external destination is also Asterisk's receiving port, or that an outbound packet proves the return path.

Keep WebSocket release features versioned

WebSocket External Media is available only in the documented release lines beginning at 20.16.0, 21.11.0, 22.6.0 and 23.0.0. The transport_data field that appends driver options begins later at 20.18.0, 22.8.0 and 23.2.0. Confirm the running release and installed help before using server mode, direction options, JSON control messages or no-auto-answer behavior.

Use the WebSocket media guide for MEDIA_START, frame sizing, buffering, passthrough codecs and XOFF/XON flow control. Those driver events are not substitutes for ARI StasisStart, bridge membership or far-leg audio evidence.

Protect the control and media boundaries separately

Protect ARI HTTP with TLS and events with WSS, restrict the ARI user and network path, allow-list the external destination and format, and bound channel lifetime. External RTP over UDP does not gain confidentiality or peer authentication merely because ARI uses HTTPS. AudioSocket over TCP likewise needs an explicitly protected deployment boundary; WebSocket TLS proves only that adjacent connection.

Treat cloud speech recognition, transcription, recording or generated-audio services as separate data processors. Establish authorization, notice, retention, access, deletion and incident ownership before sending call media. No External Media workflow was tested for this guide.

Treat External Media as one explicit bridge member

The ARI bridges guide explains why creating an External Media channel does not connect it to an existing call. Correlate its own Stasis lifecycle and membership with the call channels before interpreting packets or audio.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.