VoIP.info Guide

Asterisk AMI bridge control: actions, membership and event evidence

Bridge two live channels, inventory bridge identity and remove a member without confusing action acknowledgement, bridge membership, signaling and media.

Reviewed 2026-10-17Current Asterisk branch-23-generated AMI Bridge, BridgeList, BridgeInfo, BridgeKick and bridge-event references plus branch 22 Bridge and BridgeKick references reviewed October 15, 2026; installed branch, loaded manager actions, AMI user permissions, live channel and bridge identities, event delivery, signaling, bridge technology and media remain deployment specific; no AMI session, user, permission, host, manager action, bridge, channel, packet, media stream or live call was inspected or testedAdvancedDocumentation based · not lab tested

Separate the AMI Bridge action from dialplan Bridge

The AMI Bridge action takes Channel1 and Channel2, both already existing in the PBX, and can optionally play a courtesy tone to neither, either or both channels. The identically named dialplan application is a different control surface with its own executing-channel and result-variable contract.

Record the manager session, exact action name, ActionID, both live channel identities and tone target. Do not transfer dialplan BRIDGERESULT, ARI bridge IDs or ConfBridge room behavior into an AMI response.

Resolve both channel identities at mutation time

Channel names can change or disappear while a controller waits. Resolve Channel1 and Channel2 immediately before the action, preserve their Uniqueid and Linkedid where available, and reject ambiguous prefixes in automation.

An AMI action addressed to two strings does not prove that those strings still identify the intended call legs. Correlate later events to stable identities and keep Local-channel optimization or replacement in the same chronology.

Treat ActionID as correlation, not membership proof

Current action documentation says ActionID is returned in the action response. Use a unique value to join the request and response, while retaining the manager username, permission boundary and timestamp.

A successful response is one evidence stage. It does not by itself prove a BridgeCreate, the intended channels entering the same bridge, continuing membership, negotiated streams, audible media or a completed call outcome.

Discover bridge identity before operating on it

BridgeList inventories system bridges and can filter by BridgeType. BridgeInfo requests one bridge by BridgeUniqueid; its member records arrive as BridgeInfoChannel events and the bridge summary as BridgeInfoComplete.

Treat this as a timestamped snapshot. Preserve bridge unique ID, type, technology, creator, name and reported channel count, then associate every member by channel name, Uniqueid and Linkedid rather than assuming a display name is globally stable.

Constrain BridgeKick to bridge and channel

BridgeKick requires a channel and accepts an optional BridgeUniqueid. The current reference specifically describes the bridge ID as a way to ensure a channel is not removed from the wrong bridge.

Resolve both values from the same fresh snapshot, send both when bridge ownership matters and correlate the response with BridgeLeave. A leave event proves a membership transition, not why it happened, what dialplan ran next or whether the remaining parties retained usable media.

Reconcile lifecycle events and media separately

BridgeCreate, BridgeEnter and BridgeLeave expose bridge identity and channel details; BridgeInfoChannel carries member identity and state; BridgeInfoComplete carries bridge attributes and channel count. Build one ordered record across request, response, snapshot and lifecycle events.

Then test signaling state, negotiated streams, packet flow, decoding and audible media as separate acceptance layers. No AMI session, user, permission, host, manager action, bridge, channel, packet, media stream or live call was inspected or tested for this guide.

Follow bridge ownership into transfer control

The AMI transfer-control guide applies live channel and bridge identity to BlindTransfer and Atxfer selection.

Verify the bridge after an attended-transfer abort

The CancelAtxfer diagnostic re-resolves transferer and bridge identities before and after cancellation.

Account for Local-driven bridge movement and merging

The AMI Local optimization guide preserves bridge events and takes a new membership snapshot after End.

Re-resolve channels before a bridge mutation

The channel snapshot diagnostic prevents stale name or bridge inventory from selecting the wrong call.

Keep bridge events inside the intended AMI stream

The AMI event-delivery guide distinguishes permitted bridge events from filtered or unprocessed ones.

Do not substitute generic bridge inventory for ConfBridge state

The AMI ConfBridge snapshot guide uses the conference-specific room and participant actions without transferring generic bridge semantics.

Use conference-specific controls for ConfBridge state

The AMI ConfBridge control guide preserves ConfBridge conference and participant semantics instead of substituting generic bridge controls.

Use conference-specific lifecycle identity

The AMI ConfBridge lifecycle guide correlates Conference, BridgeUniqueid and channel Uniqueid without substituting generic bridge semantics.

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.