Asterisk ARI bridges: ownership, membership and media topology

Treat a bridge as an application-owned resource

An ARI bridge is a container for channels and communication paths; it is not the call itself. Create it with a deliberate bridge ID, name and type, retain the returned object, and associate it with the business operation that owns cleanup. The current REST API says an ARI-created bridge persists until it is explicitly shut down or Asterisk shuts down.

Bridge creation, channel creation, StasisStart, bridge membership, answer, media exchange and application completion are separate acceptance states. A successful POST /bridges proves that the resource exists, not that any intended channel joined it or that audio can flow.

Choose mixing or holding before adding channels

A mixing bridge passes media among its channels. A holding bridge is a waiting area: participant media is not shared, while an announcer can send media to participants. The two types are mutually exclusive. Preserve the requested type and each channel's intended role instead of inferring behavior from the number of members.

Use ConfBridge when the dialplan conference application and its user, bridge and menu profiles own the session. Use ARI bridges when the Stasis application owns membership and lifecycle. They share Asterisk bridging concepts but are not interchangeable control surfaces.

Let the bridge attributes express media requirements

Asterisk chooses the most performant available mixing technology for the current members. With two compatible channels, media can bypass Asterisk; native packet sharing may pass through Asterisk without decoding; two-party mixing decodes media; multi-party mixing converts participants into signed linear for mixing. Asterisk can change technology as membership changes.

Request proxy_media when media must remain through Asterisk, or dtmf_events when Asterisk must decode media to raise DTMF events. Those attributes prevent direct or native packet sharing. Do not convert a chosen bridge attribute into proof that recording, speech detection, DTMF or an external processor actually worked.

Prove Stasis ownership before membership

POST /bridges/{bridgeId}/addChannel requires the bridge and channel to be controlled by the relevant Stasis application. The documented errors distinguish a missing channel, missing bridge, a bridge outside Stasis, a channel currently recording and a channel outside Stasis. Preserve the HTTP status and exact identifiers rather than retrying a generic add operation.

A successful add request should be correlated with ChannelEnteredBridge; removal should be correlated with ChannelLeftBridge. The event models include the bridge and channel, plus application and timestamp. Read the current bridge snapshot as well: an event can be missed after an application reconnect, and a snapshot alone does not establish when membership changed.

Subscribe to bridge events deliberately

Channels in a Stasis application are automatically subscribed for channel events, and channel-entered or channel-left events are sent because they concern those channels. A bridge itself is not automatically subscribed for all bridge events. Use the applications subscription resource when the application needs bridge-specific events such as creation, destruction or merges.

Keep the application name, WebSocket connection, bridge subscription and channel membership in the same trace. A working HTTP client without the corresponding event connection can create resources while leaving the application unable to observe the lifecycle needed for safe cleanup.

Scope playback, hold and recording to the bridge

ARI can start or stop music on hold, play media and record a bridge. Bridge playback creates its own playback resource. Bridge recording captures mixed audio from participating channels, while the channel recording endpoint records audio from a channel and does not capture audio sent to it. Select scope from the evidence question, not from whichever endpoint is easiest to call.

Retain playback or recording identifiers, format, existence policy, start and finish events, bridge membership and legal authorization. A created media resource is not proof that participants heard the announcement or that the saved recording contains the intended directions.

Design cleanup for every lifecycle exit

Define what happens when either call leg hangs up, a channel leaves Stasis, the event socket reconnects, an originate fails or the application restarts. Remove or hang up the owned channels as appropriate, stop media resources, destroy an unneeded bridge and make cleanup idempotent. Destroying a bridge removes any channels in it and lets them resume their prior behavior, so do not treat deletion as a universal hangup.

Protect ARI with HTTPS/WSS, a restricted identity and source network, and allow-listed channel and media inputs. Use unique application-owned identifiers and reconcile live Asterisk state before repeating a create or add request. No bridge or call was tested for this guide.

Choose bridge or channel playback scope explicitly

A bridge playback can reach bridge participants, while a channel playback targets one member. Use the ARI playbacks guide to preserve target membership, playback identity and event order rather than inferring audience from a valid resource.

Choose bridge or channel recording scope explicitly

A bridge recording captures the mixed audio of participating channels, while a channel recording captures audio from that channel and does not capture audio sent to it. Use the ARI recordings guide to preserve target, membership window, recording lifecycle and stored-file evidence.

Do not turn one channel hold event into bridge-wide state

An intercepted hold request belongs to its initiating channel. The HOLD_INTERCEPT workflow remaps bridge members and peer media before a consumer acts.

Prove the bridge mutation after a ChannelTransfer event

Use the ARI transfer diagnostic to follow channel removal, replacement origination, bridge addition and final participants.

Control per-bridge monitoring cardinality

The Prometheus metrics guide records the version-specific bridge-detail control and keeps a bridge series separate from membership, media and user outcome.

Keep dialplan Bridge separate from ARI ownership

The dialplan Bridge guide joins two existing channels inside dialplan; ARI bridge resources and Stasis events retain a different control contract.

Do not treat a BridgeWait name as an ARI bridge ID

The dialplan holding guide preserves BridgeWait handles and ARI resource identities as different contracts.

Preserve AMI event identity and ARI resource identity

The AMI bridge-control guide keeps manager snapshots and events separate from ARI bridge operations.