Asterisk Bridge(): join two existing channels with explicit ownership

Start with two existing channels

Bridge(channel,[options]) runs on a current channel and attempts to bridge it to another channel that already exists. Preserve the executing channel and target channel as separate identities, with names, unique identifiers, linked identifiers and creation times.

This is the central difference from Dial(): Dial normally creates an outbound channel for a requested resource, while Bridge joins the executing channel to an existing target. A device address, endpoint name or dial string is not automatically a live Bridge target.

Resolve the target before entering Bridge

The documented target may be a channel name, a channel-name prefix or a channel unique ID. Prove which live channel one invocation selected. CHANNELS() can list known channel names and optionally filter them with a POSIX.2 regular expression, but a list captured earlier is not a reservation and does not prevent a channel from disappearing or being replaced.

Prefer an exact identifier carried by a controlled workflow. Treat a prefix that can match multiple concurrent channels as ambiguous until the runtime selection is proved. Do not put unrestricted caller input into a channel regular expression or bridge target.

Read BRIDGERESULT on the executing channel

When Bridge completes, the current references document BRIDGERESULT values SUCCESS, FAILURE, LOOP and NONEXISTENT. Capture the value immediately on the channel that executed Bridge and correlate it with bridge-enter, bridge-leave and hangup events.

NONEXISTENT points to target resolution or lifetime, while LOOP prevents treating the executing channel as its own peer. SUCCESS is application outcome evidence; it does not by itself prove how long both parties remained, that expected DTMF features ran, that audio flowed in both directions or that a later business action completed.

Control answering and audible cues deliberately

By default Bridge may answer the executing channel before bridging. Option n inhibits that automatic answer for the executing channel, while BRIDGE_NOANSWER can inhibit answering the target. These controls have different channel owners. Preserve both pre-bridge states and the actual answer events instead of inferring them from configuration.

Option p plays a courtesy tone to the target channel. The presence or absence of that tone is not a general media test: verify negotiated streams, addresses, packets and bidirectional audio separately when media is the symptom.

Assign feature and exit behavior to the correct party

The lowercase and uppercase DTMF options assign hangup, parking, transfer or recording control to different parties. Time-limit options L() and S() also use different units and timing boundaries. Record the exact option string and effective feature configuration before attributing an action to a caller or target.

Uppercase F() moves the bridged party when the bridger hangs up; option x instead hangs up the target after the bridge. These are not aliases for CHANNEL(after_bridge_goto), which is a channel-owned destination after the next bridge if that channel survives. Choose one mechanism whose owner and trigger match the requirement.

Keep Bridge(), ARI bridges and conferencing separate

Dialplan Bridge is a two-existing-channel application. ARI exposes externally controlled bridge resources and Stasis event ownership, while ConfBridge() is a conference application and BridgeWait() uses a holding bridge. Do not transfer identifiers, result variables or lifecycle assumptions among those surfaces.

For an authorized test, prove target resolution, both live channels, answer state, bridge membership, duration, exit owner, immediate BRIDGERESULT, signaling, negotiated media and two-way audio independently. No host, module, dialplan, channel, bridge, packet, media stream or live call was inspected or tested for this guide.

BridgeWait and BridgeAdd have different targets

The holding-bridge guide distinguishes a BridgeWait handle, a BridgeAdd target channel and the two-channel Bridge application.

Do not transfer BRIDGERESULT into AMI

The AMI bridge-control guide distinguishes an action response from the dialplan application result.