Asterisk MixMonitor: channel scope, files and recording evidence

Define the recording policy first

Choose which calls and segments may be recorded, the lawful basis and notice, who can retrieve or export audio, the retention period, deletion process and incident owner. Requirements depend on jurisdiction, sector and use case; resolve them for the actual deployment before enabling capture. A MixMonitor option or audible beep is a technical mechanism, not a compliance program.

Treat the original audio, receive-only and transmit-only files, copies sent to voicemail, transcripts, backups and exported files as separate data objects. Each needs an owner, access boundary and deletion path.

Attach the audiohook to the intended channel

MixMonitor records audio on the current channel through an audiohook; it does not represent an abstract whole call. A transfer, queue, local channel or other topology change can introduce or replace channels, so capture the channel unique ID and linked ID where the recording starts. Asterisk's audiohook documentation specifically warns that a hook stays bound to its invoking channel and describes attended-transfer masquerades as a boundary requiring deliberate inheritance behavior.

MixMonitor does not answer the channel automatically. If the dialplan requires answered or early media, provide Answer() or Progress() deliberately. Starting a recorder is not evidence that the call answered, bridged or produced usable audio.

Control filenames, format and command input

Use a controlled directory and a server-generated identifier. A relative filename goes to Asterisk's configured monitoring directory; an absolute filename selects that path. Read MIXMONITOR_FILENAME for the actual target because the documented legacy .wav49 case is rewritten to .WAV. Do not concatenate untrusted caller ID, name, SIP header or other call-supplied text into any MixMonitor parameter. Asterisk explicitly warns that untrusted parameters can create command-injection risk.

Treat the optional post-recording command as privileged execution. Prefer a separate queued processor with a fixed executable and validated opaque identifier. If the D stereo-interleaving option is selected, the Asterisk 22 reference requires a .raw extension; another extension produces a corrupted file.

Choose the capture boundary explicitly

The b option writes audio only while the channel is bridged. The s(seconds) option delays writing and can leave no file when the call ends before that interval. The r(file) and t(file) options split receive and transmit feeds; the direction is relative to the recorded channel, not a user-interface label such as agent or customer. By default Asterisk inserts silence to keep those files synchronized, while n disables that behavior.

Append, overwrite, delete-on-completion, start or stop beeps, voicemail copies and volume adjustments all change the artifact or user experience. Select only the required behavior and record it in the acceptance plan instead of inheriting a copied option string.

Stop the correct recorder before processing

The i(chanvar) option stores the MixMonitor ID in a channel variable. Preserve that ID when a channel can host more than one recorder. StopMixMonitor([MixMonitorID]) stops the selected recording and frees its file handle; without a valid ID, the operation is not scoped to a named recorder.

Asterisk requires StopMixMonitor to guarantee that the audio file is available for later dialplan processing. File existence while the handle is still open is not completion evidence. Keep stopping, checksum or size capture, processing, upload, retention and deletion as ordered steps with failure handling.

Verify the artifact and a nearby non-recorded case

Place one authorized test call, speak distinct phrases in both directions, use hold and the intended blind or attended transfer path, then hang up. Correlate the intended policy, channel and MixMonitor ID with the actual filename. After an explicit stop, verify ownership, nonzero size, expected duration, both directions, playback through an authorized interface and any downstream copy. A successful call and a created file are still separate results.

Also test one call that policy says must not be recorded. In a nonproduction environment, exercise full or unavailable storage, processor failure and retention cleanup. If audio is empty or truncated, inspect channel ownership, bridge-only or delay options, transfer boundaries, translation errors and storage before changing SIP credentials or media negotiation.

Keep audiohook ordering visible beside recording paths

The TALK_DETECT guide explains why channel ownership and audiohook placement must be proven before interpreting detection beside recording or media-processing hooks.

Separate periodic recording tones from recording proof

The periodic-hook guide keeps policy, hook execution, audio injection, listener audibility and capture in a recording as separate outcomes.

Add manager actions without collapsing the MixMonitor lifecycle

The AMI control guide extends channel, file and StopMixMonitor evidence to external start, mute and stop requests and their CALL-class events.