Asterisk Bridge fails, loops, cannot find the target or has no media

Freeze one attempt as a two-channel timeline

Record timestamp and timezone, installed branch, loaded context and priority, executing channel name and unique ID, exact redacted Bridge target and options, candidate target name and unique ID, both channel states, bridge-enter and bridge-leave events, hangups, immediate BRIDGERESULT and caller-visible outcome.

Classify the first symptom: no target resolved, self-target or loop, general application failure, one channel absent before entry, unexpected answering, bridge entered then ended, wrong party continued, or correct membership with one-way or no audio.

Prove the installed application contract and loaded arguments

Check local application help on the running system and prove the active channel executed the expected dialplan priority. Capture the resolved target and option string after variable expansion. Confirm option case, separators, time units and any destination used by F().

A correct source file, generated GUI configuration or earlier CLI listing does not prove the currently loaded arguments. Correct a loaded-dialplan or expansion error before changing endpoints, transports, codecs or NAT.

Resolve one exact live target at invocation time

Correlate the supplied name, prefix or unique ID with the live channel inventory at the moment Bridge runs. If a prefix could match more than one channel, identify the selected unique ID rather than assuming sort order. If the candidate vanished, determine its hangup time and cause.

For NONEXISTENT, stay with lookup syntax, variable scope, Local-channel optimization, transfer replacement and target lifetime. For LOOP, prove whether the resolved target is the executing channel. Do not retry blindly against a recycled name or broader prefix.

Separate answer state from bridge membership

Capture both channel states immediately before entry and the answer events during the attempt. Verify whether option n applied to the executing channel and whether BRIDGE_NOANSWER was present on the target. A signaling-state surprise is not yet a media diagnosis.

Prove both channels actually entered the same bridge and how long they remained. If entry never occurred, stay with target resolution, state and application result. If entry occurred and ended, correlate the first leave or hangup event with the option owner and cause.

Follow exit ownership and status on the surviving channel

Read BRIDGERESULT immediately on the executing channel if it survives. For uppercase F(), prove that the bridger hung up and that the bridged party reached the configured destination. For x, prove the target was intentionally hung up. For after_bridge_goto, prove the property was set on the channel expected to survive.

Do not add F(), x, a hangup handler and after_bridge_goto together to manufacture continuation. Their owners and triggers differ. Fix the first demonstrated exit mismatch and retest one mechanism.

Diagnose media only after both channels share the bridge

Once membership is proved, inspect negotiated stream formats and addresses, packet flow in each direction, direct-media behavior, RTP reachability, symmetric NAT, encryption and endpoint audio. A courtesy tone tests one bounded playback path and a SUCCESS result reports the application outcome; neither proves two-way conversation media.

Repeat one authorized success and the relevant failure. Confirm exact target resolution, both channel identities, answer state, bridge entry and duration, exit, immediate result and bidirectional media independently. No host, module, dialplan, channel, bridge, packet, media stream or live call was inspected or tested for this diagnostic.

Choose the application whose bridge boundary matches

For holding roles or adding into a target channel’s existing bridge, use the BridgeWait and BridgeAdd diagnostic.

Choose the correct bridge-control surface

For an accepted AMI action with wrong membership, use the AMI bridge diagnostic.