Inventory before issuing a control
Confirm the responding Asterisk node, installed branch, loaded app_confbridge module, manager account and available actions before making a change. Use a completed ConfbridgeListRooms snapshot to identify the active conference and a completed ConfbridgeList snapshot to resolve current participants.
A configured FreePBX conference destination, bridge profile or menu is not an active room. Do not issue a control merely to discover whether the room, action or manager permission exists.
Lock and unlock only the admission boundary
ConfbridgeLock and ConfbridgeUnlock require an exact Conference value and return the supplied ActionID. The official CLI description says a locked conference allows only admin users to join. Record the action response and a later room snapshot as separate observations.
Lock is not an eviction action. Existing participants, waiting users, marked-user behavior, PIN checks, dialplan reachability and audio remain separate. Unlocking restores the documented admission state but does not prove that a later caller was admitted.
Resolve mute and kick targets literally
ConfbridgeMute and ConfbridgeUnmute take Conference and Channel. The current action documentation says an incomplete channel name selects the first matching prefix; it also defines all and participants, with participants limited to non-admin channels. Require an exact full channel name for a single-user change unless broader scope is intentionally approved.
ConfbridgeKick separately documents all and participants. A successful response reports acceptance of that request; use participant snapshots and authorized lifecycle events to determine the resulting membership or mute state.
Keep response, event and caller outcome separate
Retain the request, unique ActionID, response, server time and any ConfbridgeMute, ConfbridgeUnmute, ConfbridgeLeave or room-state evidence authorized for the manager session. A control event can show a state transition at Asterisk while a later snapshot shows the state at a different moment.
Neither response nor event proves continuous mute, audible silence, successful re-entry denial, endpoint display, announcement playback or the final caller experience. Preserve joins, leaves and concurrent moderator actions when explaining a disagreement.
Treat recording as a multi-boundary operation
ConfbridgeStartRecord accepts an optional RecordFile. If omitted, Asterisk uses the bridge profile setting or generates a file in the monitor directory; starting when recording is already in progress returns an error. ConfbridgeStopRecord addresses the conference. Retain the exact response and the corresponding ConfbridgeRecord or ConfbridgeStopRecord event when visible.
An accepted action or recording event is not proof of the expected path, durable close, retention, permissions, decodable media, participant mix, silence handling or legal authorization. A file check and controlled playback are separate, explicitly authorized validations.
Bound authority, audit and rollback
Separate observation-only and control manager identities where practical. Grant only the action and event classes required, restrict source addresses, redact secrets, retain operator identity and reason, serialize conflicting controls and define who may use bulk values such as all or participants.
No PBX, module, manager account, credential, session, conference, participant, channel, lock, mute, kick, recorder, file, packet, audio or live call was inspected or tested. Validate controls in an authorized maintenance window with a disposable conference before operational use.
Preserve lifecycle evidence around conference controls
The AMI ConfBridge lifecycle guide keeps membership and detector events separate from control acceptance and caller outcomes.
Separate menu-driven controls from AMI requests
The ConfBridge profiles guide identifies per-user menu roles and actions without treating them as the same request path as AMI moderation controls.
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.