VoIP.info Guide

Asterisk AMI MuteAudio: channel, direction and media proof

Mute one channel stream without confusing PBX-relative direction, action acknowledgement, bridge peers, recordings, conferences or endpoint mute.

Reviewed 2026-10-25Current branch-23-generated, Asterisk 22 and Certified Asterisk 22.8 MuteAudio action references, the current MUTEAUDIO function, MixMonitorMute, ConfbridgeMute, CoreShowChannel, Manager API and AMI v2 references were reviewed October 25, 2026; installed release, loaded modules and actions, manager permission, live channel identity, bridge technology, media path, recording, conference policy and endpoint state remain deployment-specific; no PBX, manager session, action, dialplan, channel, bridge, conference, recording, packet, media frame, endpoint, speaker, microphone or live call was inspected or testedAdvancedDocumentation based · not lab tested

Bind the control to one live channel

Record the Asterisk node, installed release, manager identity, unique ActionID, exact Channel, Uniqueid, Linkedid, bridge membership, channel creation time, action time, requested direction and requested state. Resolve the current channel immediately before the action.

MuteAudio operates on the named channel. It does not name a caller, endpoint, whole linked call or every member of a bridge, so a reused display value or stale peer map is not a safe target.

Read in and out from the PBX boundary

The current, Asterisk 22 and Certified 22.8 action pages define in as audio travelling to the PBX, out as audio travelling from the PBX and all as both streams. Translate the desired human outcome through the selected channel leg before sending the action.

On one bridged leg, muting inbound audio can stop that party audio from entering Asterisk; muting outbound audio can stop media sent from Asterisk toward that party. Those labels are not microphone and speaker names, and the opposite bridge leg has its own perspective.

Treat the response as one control boundary

Use State on to turn stream muting on and State off to turn it off, preserving the raw response and matching ActionID. A success response establishes that the action was accepted for processing, not that a listener heard silence or speech.

The generated action page does not document a dedicated MuteAudio state event or a query field for current mute state. Prove the later media effect separately and retain the application policy that owns restoration.

Keep four mute mechanisms separate

The dialplan MUTEAUDIO function controls inbound, outbound or both channel streams from dialplan execution. MixMonitorMute mutes recording directions using read, write or both and numeric state, while ConfbridgeMute targets a conference participant or documented bulk scope.

Endpoint microphone mute, softphone mute, operating-system capture controls and physical headset mute are further layers. Similar words do not make these controls interchangeable; each needs its own target, direction vocabulary, owner and observable result.

Rebuild topology after transfers and optimization

CoreShowChannel can provide the channel name, Uniqueid, Linkedid, bridge ID, application and duration for a timestamped inventory response. Rebuild the intended path after transfer, Local-channel optimization, bridge replacement or masquerade before changing mute state.

Bridge membership establishes only a potential media relationship. It does not prove decoded audio, and changing one channel does not guarantee that another linked or conference channel inherited the same stream restriction.

Validate privacy and recovery on a disposable call

In an approved nonproduction window, use one disposable call and distinct authorized phrases for each direction. Capture the action response, channel and bridge identities, inbound and outbound packet or frame evidence, far-end and local listening results, then restore with the exact inverse action and prove speech recovery.

Test transfer or bridge change only when required by policy. Use a dedicated least-privilege manager identity and a timed restoration guard owned by the application. Documentation does not establish privacy, compatibility, audio quality or fail-safe recovery, and no live system was tested for this guide.

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.