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.
- Asterisk 23 AMI Bridge action ↗
- Asterisk 22 AMI Bridge action ↗
- Asterisk 23 AMI BridgeList action ↗
- Asterisk 23 AMI BridgeInfo action ↗
- Asterisk 23 AMI BridgeKick action ↗
- Asterisk 22 AMI BridgeKick action ↗
- Asterisk 23 AMI BridgeCreate event ↗
- Asterisk 23 AMI BridgeEnter event ↗
- Asterisk 23 AMI BridgeLeave event ↗
- Asterisk 23 AMI BridgeInfoChannel event ↗
- Asterisk 23 AMI BridgeInfoComplete event ↗
- Asterisk 23 AMI Redirect action ↗
- Asterisk 22 AMI Redirect action ↗
- Asterisk 23 AMI BlindTransfer action ↗
- Asterisk 22 AMI BlindTransfer action ↗
- Asterisk 23 AMI Atxfer action ↗
- Asterisk 22 AMI Atxfer action ↗
- Asterisk 23 AMI BlindTransfer event ↗
- Asterisk 23 AMI AttendedTransfer event ↗
- Asterisk 23 AMI CancelAtxfer action ↗
- Asterisk 22 AMI CancelAtxfer action ↗
- Asterisk 23 attended-transfer feature configuration ↗
- Asterisk 22 attended-transfer feature configuration ↗
- Asterisk feature-code call transfers ↗
- Asterisk 23 AMI LocalOptimizeAway action ↗
- Asterisk 22 AMI LocalOptimizeAway action ↗
- Asterisk 23 AMI LocalOptimizationBegin event ↗
- Asterisk 23 AMI LocalOptimizationEnd event ↗
- Asterisk 23 AMI LocalBridge event ↗
- Asterisk AMI v2 specification: Local channel optimization ↗
- Asterisk Local channel optimization ↗
- Asterisk Local channel modifiers ↗
- Asterisk 23 AMI CoreShowChannelMap action ↗
- Asterisk 22 AMI CoreShowChannelMap action ↗
- Asterisk 23 AMI CoreShowChannelMapComplete event ↗
- Asterisk 22 AMI CoreShowChannelMapComplete event ↗
- Asterisk 23 AMI CoreShowChannels action ↗
- Asterisk 23 AMI CoreShowChannel event ↗
- Asterisk 23 AMI CoreShowChannelsComplete event ↗
- Asterisk 23 AMI Status action ↗
- Asterisk 23 AMI Status event ↗
- Asterisk 23 AMI StatusComplete event ↗
- Asterisk 23 AMI Newchannel event ↗
- Asterisk 23 AMI Rename event ↗
- Asterisk 23 AMI Events action ↗
- Asterisk 22 AMI Events action ↗
- Asterisk 23 AMI Filter action ↗
- Asterisk 22 AMI Filter action ↗
- Asterisk 23 AMI WaitEvent action ↗
- Asterisk 22 AMI WaitEvent action ↗
- Asterisk AMI event filtering ↗
- Asterisk Manager TCP/IP API ↗
- Asterisk 23 AMI Login action ↗
- Asterisk 23 AMI Ping action ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.