Freeze one operation and its identifiers
Choose one authorized call attempt and preserve the running Asterisk version, Stasis application, event-socket connection, bridge ID and type, channel IDs, add-channel request, response status and timestamps. Include the business operation or idempotency key that owns cleanup. Do not create replacement bridges while an earlier application instance may still own live resources.
Read the current bridge and channel snapshots. Confirm that the identifiers refer to the intended call legs rather than an optimized Local-channel half, an External Media channel, an earlier retry or a bridge created by another application.
Interpret the add-channel response precisely
A missing channel can produce 400, a missing bridge 404, a bridge outside the Stasis application or a currently recording channel 409, and a channel outside Stasis 422. Correct the named ownership or state failure; do not treat all of these responses as a race or retry them blindly.
If the channel never reached the expected StasisStart, use the Stasis registration diagnostic. If it left Stasis before the add request, reconcile its dialplan or hangup path rather than creating a new bridge around an obsolete identifier.
Correlate membership events with the live bridge
For a successful request, find ChannelEnteredBridge with the exact application, bridge and channel. Track ChannelLeftBridge, hangup, StasisEnd, bridge merge and BridgeDestroyed events in timestamp order. Then compare the bridge's current channel list.
An entry event followed immediately by a leave is not stable membership. A current member without a retained entry event can indicate an event-socket gap or application restart. Recover from the server-side snapshot, but preserve that evidence gap instead of manufacturing a complete timeline.
Verify that the bridge type matches the expected audio
A holding bridge intentionally prevents participant-to-participant media. Confirm whether the channel was added as a participant or announcer. In a mixing bridge, inspect proxy_media and dtmf_events and remember that Asterisk can move between direct, native, decoded two-party and multi-party mixing as membership changes.
If the symptom appears only when a third member joins or leaves, capture the before-and-after channel list, negotiated formats and media addresses. Membership changes can alter the topology without changing the bridge ID. Use the External Media diagnostic when a media-service channel is involved.
Separate bridge media operations from call audio
Bridge music on hold, playback and recording each create or control a media operation; they are not the same as ordinary participant media. Preserve the playback or recording ID and its events. If a bridge recording is required, do not substitute a channel recording: the channel endpoint records audio from that channel and does not capture audio sent to it.
Confirm legal authorization, file format, storage state and the intended membership window. A recording start event, created file or byte count does not prove both directions, intelligibility, participant notice or complete business coverage.
Correct one owner and retest cleanup
Change only the evidenced failure owner: application registration, event subscription, bridge type, channel role, request timing, channel recording conflict, identifier correlation, media attribute, codec path or application cleanup. Preserve restricted ARI access and do not expose the HTTP interface or broad media ranges as a shortcut.
Run one fresh attempt and retain bridge creation, channel Stasis entry, add response, membership event, stable snapshot, expected media result, leave or hangup event and bridge destruction. Reconcile any survivors after an application restart. No host, bridge, channel, recording, media path or call was inspected or tested for this diagnostic.
Separate bridge membership from playback state
If members remain in the bridge but an announcement is queued, stuck or silent, use the ARI playback diagnostic to follow media lookup, playback events, control state and audible output without recreating the bridge.
Separate bridge membership from recording state
If a recording is missing, empty or contains the wrong participants, use the ARI recording diagnostic to follow target scope, membership, live controls, stop or cancel and stored-file evidence.
Continue from media flow to talk-detection evidence
After proving media reaches the intended channel, the TALK_DETECT diagnostic checks detector attachment, audiohook order, thresholds and ARI delivery.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk ARI Bridges REST API ↗
- Asterisk bridges in a Stasis application ↗
- Asterisk ARI mixing bridges ↗
- Asterisk ARI holding bridges ↗
- Asterisk ARI bridge operations ↗
- Asterisk ARI data models ↗
- Asterisk ARI recording API ↗
- Asterisk ARI simple media playback ↗
- Asterisk ARI playback operations ↗
- Asterisk ARI Playbacks REST API ↗
- Asterisk ARI Channels REST API ↗
- Asterisk ARI Sounds REST API ↗
- Asterisk ARI DTMF handling ↗
- Asterisk configuration for ARI ↗
- Asterisk 22 TALK_DETECT function ↗
- Asterisk 22 DENOISE function ↗
- Asterisk 22 AMI ChannelTalkingStart event ↗
- Asterisk 22 AMI ChannelTalkingStop event ↗
- Asterisk 22 ARI data models ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.