Bind every recording request to one exact channel
The AMI MixMonitor action starts recording on the named channel; it does not target an abstract call. Preserve the responding node, installed branch, loaded app_mixmonitor module, manager identity, ActionID, exact channel name, Uniqueid, Linkedid, bridge identity and policy owner before issuing a control. A transfer, Local channel, queue or bridge change can create or replace channels while the business call continues.
The action response, channel lifetime and caller outcome are different records. Use a current channel snapshot to resolve the intended leg, and do not start a recorder merely to discover whether the channel exists or whether the account has write authority.
Treat filename, options and post-command as privileged inputs
MixMonitor accepts File, application-style Options and an optional post-recording Command. A relative filename is created under the configured monitor directory; receive-only r(file) and transmit-only t(file) targets can be used without a mixed File. The D option requires a .raw extension or the documentation warns that the result is corrupted.
Generate opaque server-side names and validate paths. Asterisk warns against untrusted values such as caller ID in parameters because of command-injection risk. Prefer a separate bounded processor over a free-form post-command, and keep original, directional, voicemail-copy, processed, uploaded and retained objects as distinct files with separate access and deletion controls.
Correlate acceptance with start, mute and stop events
A successful action response reports that the manager request was accepted; it does not prove durable audio. MixMonitorStart and MixMonitorStop are CALL-class events raised for a channel, while MixMonitorMute reports the Direction and State transition. Preserve event time, channel, Uniqueid and Linkedid and the manager session's event mask and filters.
The published event schemas do not list ActionID, filename, MixMonitor ID, file size, codec or audio result. Correlate them by stable channel identity and bounded time, but do not invent fields or claim that receiving an event proves file content, audibility, consent or retention.
Scope mute and stop controls deliberately
MixMonitorMute operates on the named channel and distinguishes read, write and both; State 1 enables mute and 0 disables it. Those directions are from or to the channel, not universal caller and agent labels. Record the topology before translating them into a business-side description.
StopMixMonitor takes the channel and can take a MixMonitorID; when a valid ID is supplied, the documentation says only that recorder is stopped. If multiple recorders can exist, request the application-style i(chanvar) option at start, preserve the resulting ID on the same channel and use it for the later stop. Do not let an unscoped stop terminate an unintended recorder.
Close the file lifecycle before processing or retention claims
The action and application references require StopMixMonitor to guarantee that the recording file is available for processing during dialplan execution. Treat request, response, stop event, file-handle release, stat, checksum, decode, duration, directional content, downstream processing, upload, retention and deletion as ordered checkpoints.
MixMonitorStop identifies a stopped monitor on a channel but its documented fields do not include the path or a file-integrity result. A visible path, nonzero size or stop event is not proof of the intended participants, complete duration, understandable two-way audio, lawful capture or successful retention.
Validate with a disposable authorized call and negative case
In an approved nonproduction window, place one disposable call whose recording is authorized. Capture the exact channel and identities, action response, start event, optional scoped mute and unmute, scoped stop, stop event, actual filename, released handle, size, duration and authorized playback of distinct phrases in both directions. Exercise the expected transfer path and one call that policy says must not be recorded.
Test full or unavailable storage and processor failure separately. No PBX, module, manager account, credential, session, channel, audiohook, event stream, file, packet, media stream, recording or live call was inspected or tested for this guide; documentation cannot establish availability, compatibility, audio quality, privacy, retention or legal compliance.
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.