Separate the four ConfBridge identities
ConfBridge has a conference identifier, one bridge profile for the conference, a user profile for each participant and a conference menu for each participant. Preserve all four plus the responding node, installed branch, loaded app_confbridge module and exact dialplan invocation.
The conference name is assigned in the dialplan and need not be numeric. A bridge profile governs the conference, while user and menu profiles can differ by channel. A FreePBX conference destination, a generated context and a runtime room are related but are not interchangeable evidence.
Resolve explicit, dynamic and default profiles in order
The documented ConfBridge(conference,[bridge_profile,[user_profile,[menu]]]) arguments select named sections from confbridge.conf. When an argument is blank, the application looks for a dynamic profile on the channel and then falls back to default_bridge, default_user or default_menu. Record the exact argument value rather than assuming a blank means no profile.
CONFBRIDGE(type,option) can create or modify dynamic bridge, user or menu profiles on that channel, and clear removes already applied options. Template selection and option writes are ordered dialplan operations. Mixing bridge profiles inside one conference is documented as not recommended with undefined results; do not infer which profile won from one caller screen.
Treat a menu sequence as collected DTMF plus an action
A menu maps one DTMF sequence to actions such as mute toggle, volume changes, participant count, leaving the conference, a dialplan excursion or administrator controls. playback returns after the prompt, while playback_and_continue continues collecting the sequence and terminates prompt playback when a digit arrives. Admin-only actions also depend on the participant user profile.
Keep endpoint emission, PJSIP DTMF mode, channel receipt, sequence matching and action execution separate. A tone heard locally is not proof that Asterisk received the expected event, and a received digit is not proof that it matched the intended menu or that an administrator action was authorized.
Bound prompt and announcement evidence
Bridge profiles name sounds for joins, leaves, pins, locks, mute state, invalid menus, marked-user waiting and other conditions. User profiles can suppress enter and leave prompts with quiet, announce counts, play a per-user announcement, wait for a marked user or end when the last marked user leaves. The documented core prompt list currently describes the English package.
A configured filename is not proof that the installed language and sound package contains a usable file. A prompt that plays proves neither subsequent DTMF collection nor a conference action; an absent prompt can instead reflect profile selection, quiet, package, format, file access, channel language or media delivery.
Read CONFBRIDGE_RESULT only after the application returns
The application sets CONFBRIDGE_RESULT when it completes, with documented values FAILED, HANGUP, KICKED, ENDMARKED, DTMF and TIMEOUT. Preserve the value on the same channel before later dialplan steps overwrite or lose it, and correlate it with lifecycle events and channel evidence.
The result describes why that invocation returned. It is not proof of who sent a DTMF digit, which menu action ran, why a participant was kicked, whether audio was usable or whether every intended participant reached the same outcome.
Validate one disposable path without broad claims
In an approved window, use one disposable conference and explicit test profiles. Record the resolved bridge, user and menu names, effective dynamic writes, endpoint DTMF mode, one known digit sequence, prompt selection, resulting action, application return and later room and participant snapshots. Change one owner at a time and keep rollback.
No PBX, module, dialplan, generated configuration, profile, menu, prompt, sound package, endpoint, channel, DTMF frame, packet, media stream, conference or live call was inspected or tested. Documentation cannot establish availability, interoperability, prompt audibility, menu reliability, performance, security or caller experience for an unobserved deployment.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.