VoIP.info Diagnostic

FreePBX conference caller waits, cannot join or has no audio

Trace one conference attempt through entry routing, PIN and role, marked-user lifecycle, loaded ConfBridge state, participant media and bridge mixing before changing room-wide settings.

Reviewed 2026-10-17Current Sangoma Conferences-module and configuration-example pages plus Asterisk 22 ConfBridge application, current configuration and CLI references reviewed October 10, 2026; installed FreePBX labels, module version, generated profiles and loaded Asterisk state require confirmation; no PBX, module, route, PIN, profile, menu, conference, participant, recording, channel, RTP stream, prompt, music or call was inspected or testedIntermediateDocumentation based · not lab tested

Freeze one caller, route and conference attempt

Record timestamp and timezone, caller and source route, dialed number or IVR choice, conference number, intended participant or administrator role, prompt sequence, entered digits, waiting or admission result, mute state and the exact missing audio direction. Preserve the FreePBX module and Asterisk versions, saved conference fields, generated destination and authorized log lines for that attempt.

Classify the symptom before changing the room: wrong destination, PIN rejected, ordinary participant waiting for a leader, admitted but muted, one participant has no audio, nobody hears anybody, DTMF menu fails, or the room ends unexpectedly. Those patterns have different owners.

Prove the call reaches the intended ConfBridge

The FreePBX Conferences module creates a dialable extension and a reusable destination for inbound routes, IVRs, time conditions and other modules. Follow the selected route into the generated conference destination and then the running ConfBridge application. A phone's local three-way conference, a similarly numbered room and a prompt from another application are not the same bridge.

Confirm the conference identifier and loaded user, bridge and menu profile. Reaching a PIN prompt proves only that the caller reached an access stage; it does not prove the intended role, marked-user lifecycle, bridge membership or usable media.

Separate PIN acceptance, role and marked-user lifecycle

Preserve participant and administrator PIN handling without placing secret values in tickets or broad logs. Then identify whether the admitted caller is an administrator, a marked user, both or neither. Asterisk documents marked, wait_marked, end_marked and end_marked_any as separate profile controls.

If an ordinary participant hears waiting treatment, verify whether the room intentionally waits for a marked user and whether the expected leader joined with the profile that actually carries the marked role. If callers are removed when a leader leaves, inspect the loaded end-marked behavior instead of treating the removal as a network drop.

Use live bridge state to distinguish waiting from active

Use the documented ConfBridge CLI inspection commands during an authorized reproduction to list the intended conference and participants and to review the loaded profiles and menus. Preserve membership, role, waiting, mute and talking state before using any administrative mute, kick or lock action.

A channel present in the conference list can still be waiting for a marked user or muted. An empty list after the caller hears a prompt points back toward route, PIN, profile or application exit evidence rather than a mixed-audio problem. Avoid creating a second room merely to make the caller appear.

Trace each participant media leg before the mix

For one silent participant, correlate that channel's SDP, RTP source and destination, packet arrival, codec, mute state and endpoint audio independently from the bridge. Then compare a known-good internal participant and an external trunk leg. One broken endpoint or NAT path should not trigger room-wide profile tuning.

If every participant is present but nobody hears mixed audio, inspect loaded bridge state, channel directions, translation availability and resource evidence. Talk detection, drop-silence thresholds, jitter buffering and mixing interval can change behavior and delay; do not tune them without a captured symptom and an accepted rollback.

Keep menus, prompts, waiting music and recording separate

Asterisk assigns DTMF actions through a menu profile, while join prompts, user counts, recorded names and waiting music have separate scopes. Prove digit transport, the loaded menu and the resulting action. A received digit does not establish that the intended menu was attached or that an unauthorized caller should have administrator actions.

If waiting music is silent, preserve the wait-marked state and selected music class before using the focused music-on-hold diagnostic. A configured conference recording, an active bridge and a final readable file are also separate outcomes.

Correct one owner and replay the lifecycle

Correct only the demonstrated boundary: route or destination, saved PIN or role mapping, generated and loaded profile, marked-user assignment, mute or menu state, one participant media path, missing prompt or selected music class. Retest participant first, leader second, another participant third, each required audio direction and each departure order.

Verify that the intended room empties, public entry paths remain restricted, temporary logging is removed and unrelated conferences still work. This workflow is derived from first-party documentation and has not been reproduced on a customer or laboratory PBX.

Use inventory only for the runtime membership boundary

The ConfBridge list diagnostic checks active room and participant snapshots without treating them as admission or media proof.

Separate moderation state from admission and audio

The ConfBridge control diagnostic checks lock, mute, membership and recording controls without making them proof of caller experience.

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.