Asterisk AMI Bridge succeeds but membership is wrong

Freeze one manager transaction

Record installed branch, timestamp, manager username and redacted connection, exact action, unique ActionID, supplied channel names, stable channel IDs, tone target, response, candidate bridge ID, surrounding bridge events and caller-visible outcome.

Classify the first symptom: rejected action, accepted action with no expected enter, wrong member, wrong bridge, member leaves immediately, kick affects another bridge, correct membership with no media, or later call failure.

Prove action availability and manager authorization

Check local action help, loaded module state and the AMI user read and write permissions on the running branch. Correlate the request and response by ActionID; distinguish a transport disconnect, parser error, authorization denial and action-level response.

A controller implementation or upstream documentation does not prove that the installed host exposes the action to this manager account. Correct that boundary before changing dialplan, endpoints or RTP settings.

Re-resolve Channel1 and Channel2

At action time, map each supplied channel value to one intended live leg and preserve its Uniqueid and Linkedid. Correlate rename, masquerade, Local-channel optimization, hangup and replacement events before assuming a stale name still owns the call.

If the wrong leg entered, fix selection and lifetime control. Retrying the same ambiguous or expired names can create a second misleading acknowledgement without repairing ownership.

Correlate the bridge snapshot and lifecycle

Use BridgeList to bound candidate bridges, then request BridgeInfo for the intended BridgeUniqueid. Collect all BridgeInfoChannel records and the BridgeInfoComplete summary, preserving type, technology, creator, name and channel count.

Align that snapshot with BridgeCreate, BridgeEnter and BridgeLeave. A snapshot before or after a transition is not contradictory; the timestamps and stable identities determine which state each record describes.

Prevent a kick from targeting the wrong bridge

When removing a member, resolve the channel and its current bridge together and include the optional BridgeUniqueid when bridge ownership matters. If the action is acknowledged but the expected leave is absent, check stale bridge identity, channel replacement, authorization and event visibility.

If a different membership changes, preserve both bridge IDs and all enter and leave events. Do not infer that a channel has only one relevant bridge context from a reused display name.

Separate membership, signaling, media and teardown

Once the intended members are proved in the intended bridge, inspect channel state, negotiated stream addresses and directions, bridge technology, packet flow on each leg, decoding and endpoint playback. Keep later leave or hangup cause, dialplan continuation and final business result independent.

An AMI success response, enter event or complete snapshot cannot by itself prove two-way audio or final call success. No AMI session, user, permission, host, manager action, bridge, channel, packet, media stream or live call was inspected or tested for this diagnostic.

Validate the membership snapshot boundary

The channel snapshot diagnostic compares list completion, stable identity and bridge lifecycle events.

Verify that bridge lifecycle events were deliverable

The AMI event diagnostic separates action success from event subscription and storage.