Asterisk 22 ConfBridge profiles, lifecycle and acceptance

Keep bridge, user and menu profiles independent

ConfBridge joins channels in a server-side conference, but its configuration has three scopes. A bridge profile controls shared mixing and room behavior, a user profile controls one participant, and a menu maps that participant's DTMF sequences to actions. The default bridge and user sections apply only when the dialplan omits those arguments.

The bridge profile supplied by the channel that creates the room governs the conference-lifetime announcer and shared settings. Later callers must not be allowed to silently redefine that room. Record the room identifier, creating channel, loaded bridge profile, user profile and menu for each acceptance run.

Design moderator and room lifecycle explicitly

Marked and admin roles are separate. wait_marked can hold a participant until a marked user arrives, end_marked removes eligible participants when the last marked user leaves, and Asterisk 22 also documents end_marked_any for leaving when any marked user departs. These options produce different meeting lifecycles and must not be treated as synonyms.

answer_channel defaults to yes in the Asterisk 22 module reference, but an answered channel is not proof that the caller entered the intended room or heard usable media. Decide who may create, join, lock, mute, remove and record; a dialable room number or PIN is not sufficient authorization if untrusted callers can reach its context.

Bound DTMF, DSP and media processing

A ConfBridge menu consumes DTMF sequences for local actions such as mute or participant count, while dtmf_passthrough controls whether received DTMF is sent to other participants and defaults off. Test ambiguous prefixes, timeouts, permitted admin actions and any downstream application that legitimately needs DTMF.

Silence dropping, talking and silence thresholds, denoise and jitter buffering are separate user-profile controls. Silence dropping can reduce mixed background noise and processing, but loose talk detection can clip speech onset; the jitter buffer can absorb arrival variation while adding delay and processing cost. Keep these settings attached to observed participant legs instead of applying a room-wide audio cure without evidence.

Inspect loaded state before changing the room

Use confbridge show profile bridges, confbridge show profile users and the menu commands to inspect loaded definitions. confbridge list reports active rooms; the room-specific form exposes each participant channel and its selected profiles. Lock, mute and kick commands change live state and require an authorized operator record rather than being used as harmless probes.

When one participant has bad audio, compare that channel's negotiated codec, RTP direction and endpoint before changing the bridge profile. A room with one answered channel, one active participant or a visible CLI row is not proof of bidirectional speech, moderator policy, recording or capacity.

Test recording, exit status and recovery separately

ConfBridge recording has bridge-profile, CLI and AMI control paths. The configured record_file, automatically generated monitor-directory file, start or stop action, recorder channel, closed file and authorized playback remain separate evidence. If append mode is selected, stopping and restarting recording changes the file lifecycle and must be included in retention and disclosure testing.

Join an ordinary participant, a moderator and an external participant in a controlled room. Verify wait and leave behavior, menu authorization, bidirectional speech, DTMF, a permitted recording, final file ownership and a nearby room that must not be recorded. Capture CONFBRIDGE_RESULT on exit, then repeat after restart or reload as the approved change procedure requires. No participant count, codec list or carrier channel entitlement alone sizes the mixing, transcoding and recording workload.

Do not collapse ConfBridge into an ARI mixing bridge

ConfBridge remains a dialplan conference application with bridge, user and menu profiles. An ARI bridge is instead controlled through Stasis membership and REST lifecycle operations; choose the owner before designing admission, media and cleanup.

Trace the FreePBX-managed bridge without bypassing ownership

For a FreePBX-created conference, use the focused diagnostic to reconcile the saved module record and generated destination with loaded ConfBridge profiles, menus, participant state and media. Make durable corrections through the owning FreePBX object rather than leaving a runtime CLI change as configuration.

Choose one ConfBridge jitter-buffer owner

The Asterisk jitter-buffer guide distinguishes the ConfBridge user-profile default adaptive option from a fine-tuned JITTERBUFFER() policy applied before bridge entry.

Do not use two-party Bridge semantics for conferences

The dialplan Bridge guide covers one executing channel and one existing target, not conference profiles or participant roles.

Do not map holding roles to conference profiles

The BridgeWait and BridgeAdd guide keeps participant and announcer roles separate from ConfBridge room policy.

Do not infer conference policy from generic bridge events

The AMI bridge-control guide limits bridge events to lifecycle and membership evidence.

Inventory runtime rooms separately from profiles

The AMI ConfBridge snapshot guide keeps configured profiles, active rooms, participant rows and media outcomes distinct.

Keep moderation, recording and conference outcomes distinct

The AMI ConfBridge control guide separates lock, mute, kick, recording, room state and caller experience.

Separate conference lifecycle, membership and speech detection

The AMI ConfBridge lifecycle guide explains start, join, leave, end and optional talking events as distinct boundaries.

Do not let an empty profile argument hide a fallback

The profiles, menus and exit-results guide traces named, dynamic and default bridge, user and menu profiles before interpreting prompts or DTMF actions.