Freeze one occurrence and name the expected survivor
Record one authorized occurrence with timestamp and timezone, Asterisk branch, caller and callee channel names, unique and linked identifiers, bridge identifier, creating application, dial string or Bridge() arguments, expected surviving channel and expected context, extension and priority. Classify the first symptom: no bridge entry, no bridge exit, owner hung up, wrong channel continued, target was not found, target ran twice or a later action failed.
Preserve the loaded dialplan and event interval before adding g, F(), G() or another Goto. A missing log line is not yet proof that the bridge callback failed.
Prove the continuation was set on the correct channel before entry
Locate the exact Set(CHANNEL(after_bridge_goto)=...) or application option and capture the current channel at that priority. Resolve the final destination string and verify the context, extension and priority exist in the loaded dialplan. Then prove that same channel later enters the intended next bridge.
A value set on the caller does not configure a callee or Local-channel half. Likewise, setting it after bridge entry cannot be treated as proof it controlled that entry. If the symptom uses Dial() or Bridge() options instead, record the application owner and the party each option is documented to move.
Correlate BridgeEnter and BridgeLeave for the same identifiers
Match BridgeEnter and BridgeLeave by BridgeUniqueid and channel Uniqueid, not display name alone. Account for swaps, transfers, Local-channel optimization and new bridges. after_bridge_goto applies to the next bridge the owning channel joins; a later bridge or peer-only event is not the same lifecycle.
If the intended channel never entered the bridge, stay on call construction. If it entered but did not leave during the captured interval, stay on bridge ownership and exit. Do not edit the destination until the qualifying bridge exit is demonstrated.
Separate a surviving exit from channel hangup
After BridgeLeave, check whether the same channel remained alive long enough to execute dialplan. CHANNEL(after_bridge_goto) is conditional on the owner not hanging up. Correlate the owner and peer Hangup events rather than assuming the last party heard is the channel that survived.
If the owner hung up, choose a mechanism whose documented owner and trigger match the requirement instead of forcing the unreachable target. For example, Dial() lowercase g, Dial() or Bridge() F(), and Dial() uppercase G() have different party and timing semantics.
Trace target resolution and first priority before downstream work
For a surviving owner, inspect the resolved Goto destination, loaded context, extension and priority, include order and the first application executed. Keep target entry separate from a later Gosub, playback, database write, transfer or hangup. A post-bridge section can run successfully even when a remote effect fails.
If execution arrives twice, look for two bridge lifecycles, two configured mechanisms or two surviving channels before adding a guard. If it arrives on the wrong leg, correct channel ownership rather than sharing global state or copying the destination to every leg.
Correct the first divergence and retest the exit matrix
Correct only the demonstrated boundary: wrong channel, late assignment, wrong next bridge, invalid target, owner hangup, inappropriate Dial or Bridge option, missing variable inheritance, duplicated mechanism or downstream failure. Preserve the original dialplan and loaded state before reload.
Retest no-answer, busy, destination hangup, originator hangup, bridge removal and transfer only where relevant. Confirm one intended owner, one bridge lifecycle, one continuation entry, expected call result, final hangup and records. This workflow is documentation-derived and was not reproduced on an installed or laboratory Asterisk system.
Prove the Dial option and surviving channel
The Dial diagnostic distinguishes lowercase g, party-transfer options and channel-owned after-bridge destinations.
First prove that Bridge entered and which party survived
The Bridge diagnostic separates lookup, result and first exit from later continuation logic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 22 CHANNEL function reference ↗
- Asterisk 22 Dial application reference ↗
- Asterisk 22 Bridge application reference ↗
- Asterisk 22 Goto application reference ↗
- Asterisk 22 BridgeEnter AMI event ↗
- Asterisk 22 BridgeLeave AMI event ↗
- Asterisk 22 Hangup AMI event ↗
- Asterisk 23 Dial application ↗
- Asterisk pre-dial handlers ↗
- Asterisk hangup-cause overview ↗
- Asterisk HANGUPCAUSE_KEYS function ↗
- Asterisk CHANNEL function ↗
- Asterisk 23 Bridge application ↗
- Asterisk Bridge application overview ↗
- Asterisk 23 CHANNELS function ↗
- Asterisk ARI bridge overview ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.