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.
- 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.