Asterisk after-bridge dialplan: channel ownership, exit and continuation

Start with the channel that must continue

Post-bridge behavior is channel-specific. Name the caller, every created callee, both halves of any Local channel, the bridge identifier and the channel that should execute the next priority. A shared linkedid or participation in one customer call does not make their dialplan positions interchangeable.

Write the expected exit condition before choosing a mechanism: the peer hangs up while this channel survives, this channel is explicitly removed from a bridge, the current Dial() application returns, or one party must be transferred when the other hangs up. Those are different events with different owners.

Use after_bridge_goto for one surviving channel and its next bridge

Asterisk documents CHANNEL(after_bridge_goto) as a writable, parseable Goto destination for the current channel after it exits the next bridge it joins, provided that channel does not hang up. It is not a whole-call callback and does not promise execution on the peer.

Set it on the intended channel before that channel enters the target bridge. Use a fully qualified context, extension and priority, and confirm the target exists in the loaded dialplan. This inert example logs one surviving channel; it does not place a call or create a bridge.

[rx-entry]
exten => 7201,1,NoOp(Set one-channel post-bridge destination)
 same => n,Set(CHANNEL(after_bridge_goto)=rx-after-bridge,s,1)
 same => n,NoOp(The application that creates the next bridge belongs here)
 same => n,Hangup()

[rx-after-bridge]
exten => s,1,NoOp(Surviving channel ${CHANNEL(uniqueid)} left its bridge)
 same => n,Hangup()

Do not confuse normal Dial continuation with a bridge exit target

Dial() creates outbound channels and normally reports call results on the originating channel. Its lowercase g option continues at the next priority when the destination channel hangs up. DIALSTATUS, DIALEDPEERNAME and timing variables describe that application result; they do not prove that an arbitrary peer ran a post-bridge destination.

Keep no-answer, busy, congestion, cancellation and answered-then-disconnected cases separate. A Dial() application can continue without the call ever having formed a bridge, while after_bridge_goto requires the owning channel to leave the next bridge without itself hanging up.

Keep transfer options and channel owners explicit

Dial() uppercase F() transfers the called party when the caller hangs up, while uppercase G() sends the calling party to the named priority and the called party to the following priority when the call is answered. The Bridge() application has its own F() behavior for the bridged party when the bridger hangs up, and reports BRIDGERESULT to the current application owner.

These controls are not aliases for after_bridge_goto. They select different moments and may move a different channel. Dial() also documents that variables needed by its F() destination must be inherited to the called channel. Prove the owner and creation time before changing inheritance or adding another jump.

Treat bridge leave, channel hangup and dialplan entry as separate evidence

AMI BridgeEnter and BridgeLeave identify both the bridge and channel, including unique and linked identifiers. Correlate those events to the exact owner configured for continuation. A BridgeLeave event proves that a channel left a bridge; it does not prove that the channel remained alive or entered the intended extension.

Next inspect channel state, the loaded Goto target and the first executed priority. If a Hangup event for the same channel precedes any dialplan entry, the survival condition for after_bridge_goto was not met. A peer hangup and owner hangup must not be collapsed into one bridge-ended label.

Test the exit matrix without manufacturing success

In a controlled window, test the exact mechanisms in scope: no answer, busy, destination hangup, originator hangup, bridge removal, transfer and Local-channel optimization. Confirm which channel enters and leaves which bridge, which channel survives, the resolved continuation target, application result, final hangup and CDR or CEL output.

Accept only the intended owner entering the intended loaded destination once. Roll back if an unaffected route, transfer or recording path changes. No PBX, dialplan, channel, bridge, event, endpoint, call or continuation was inspected or tested for this guide.

Dial continuation is not a whole-call callback

The Dial guide distinguishes lowercase g, party-transfer options and one channel’s after_bridge_goto ownership.

Choose one bridge-exit owner and trigger

The Bridge guide distinguishes F(), x, BRIDGERESULT and channel-owned after_bridge_goto.

Distinguish ConfBridge menu exit from later continuation

The ConfBridge menu diagnostic reads CONFBRIDGE_RESULT after the application returns and keeps DTMF exit, marked-user removal, kick, hangup and timeout separate.