VoIP.info Troubleshooting

Asterisk channel leaves a bridge but dialplan does not continue

Trace the intended channel from the configured continuation through bridge entry, exit, survival, target resolution and first executed priority.

Reviewed 2026-10-15Asterisk CHANNEL, Dial, Bridge, Goto and AMI bridge-event documentation reviewed October 12, 2026; exact continuation depends on the installed Asterisk branch, loaded dialplan, channel owner, bridge technology, application options and hangup path, and no PBX, dialplan, channel, bridge, event, endpoint, call or continuation was inspected or testedAdvancedDocumentation based · not lab tested

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.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.