Freeze one holding or add attempt
Record timestamp, installed branch and modules, loaded context and priority, executing channel, exact redacted application arguments, handle, role, options, answer state, holding entry and exit, candidate target, selected bridge, immediate result and caller-visible outcome.
Classify the first symptom: wrong holding group, wrong role, unexpected answer, missing or wrong entertainment, announcer not heard, duration not returning, target absent, target not bridged, loop, general failure, wrong bridge or correct membership with bad media.
Prove the installed contract and loaded arguments
Check local help and module state on the running branch, then prove which priority executed after variable expansion. Preserve blank positional arguments, role case, the first entertainment letter, m() class, S() duration and n.
A correct source file or generated configuration does not prove the loaded call path. Correct application availability, argument order or expansion before changing endpoints, codecs or NAT.
Follow the BridgeWait handle, role and membership
Correlate the exact handle with all overlapping BridgeWait invocations while remembering that it is not an actual bridge ID. Prove participant or announcer role for each channel and the time interval in which they shared the holding workflow.
If an announcer is present, expect participant entertainment to be suspended; then separately prove announcement media. If the wrong channels meet, correct the handle or call path rather than recreating ARI bridges or conference rooms.
Separate configured entertainment from a media fault
Resolve the first letter used by e, then check whether the chosen mode intentionally produces music, ringing, silent audio, channel hold or no entertainment. For music or hold modes, prove the selected or default class, available source and playback start.
Only after the intended generator is proved should the investigation move to negotiated streams, bridge technology, direct media, RTP reachability and endpoint audio. Do not use silence alone to infer a missing bridge.
Correlate answer and every removal trigger
Prove whether BridgeWait answered the executing channel or option n suppressed automatic answer. Measure holding entry to exit and compare it with S() in seconds. Correlate hangup, external removal and duration expiry with the same channel identity and first resumed priority.
A channel that hung up cannot prove duration return. A duration exit proves only that BridgeWait returned to PBX dialplan; it does not prove a later application or business action completed.
Resolve BridgeAdd through the target into its bridge
At invocation time, map the supplied full name, prefix or unique ID to one live target, then prove that target already belongs to the intended bridge. For NONEXISTENT, stay with target lifetime and lookup. For LOOP, test whether the executing channel resolves as the target. For FAILURE, retain bridge membership and channel-state evidence before retrying.
Read BRIDGERESULT immediately and verify the added channel actually enters the same bridge. Membership, signaling and two-way media remain separate. No host, module, dialplan, channel, holding bridge, bridge, packet, media stream or live call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 23 BridgeWait application ↗
- Asterisk 22 BridgeWait application ↗
- Asterisk 23 BridgeAdd application ↗
- Asterisk 22 BridgeAdd application ↗
- Asterisk Bridge application overview ↗
- Asterisk ARI bridge overview ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.