VoIP.infoThe independent guide to business communications.
VoIP.info Guide

Asterisk AMI Monitor: legacy lifecycle and MixMonitor migration

Identify the Asterisk 20-and-earlier res_monitor lifecycle, keep rename, pause, stop and file evidence distinct, and migrate without assuming the actions exist on current branches.

Reviewed 2026-10-25Asterisk 20 Monitor, ChangeMonitor, PauseMonitor, UnpauseMonitor and StopMonitor AMI action references, the Asterisk 20 Monitor application, the Asterisk 21 removal notice, and current branch-23-generated MixMonitor, StopMixMonitor and CoreShowChannel references were reviewed October 25, 2026; res_monitor was deprecated in Asterisk 16 and removed in Asterisk 21, so legacy Monitor actions must not be represented as current-branch capabilities; installed release, vendor patches, loaded modules, action inventory, manager permissions, exact channel identity, monitor directory, filenames, formats, file ownership, storage, mix command, audio contents, retention and generated FreePBX dialplan remain deployment-specific; no PBX, module, manager account, action, channel, file, packet, recording, processor, endpoint or live call was inspected or testedAdvancedDocumentation based · not lab tested

Gate the workflow by exact Asterisk version

The documented Monitor, ChangeMonitor, PauseMonitor, UnpauseMonitor and StopMonitor AMI actions belong to res_monitor. Asterisk documents res_monitor as deprecated in Asterisk 16 and removed in Asterisk 21. Treat this workflow as legacy Asterisk 20-and-earlier behavior, not a current-branch control surface.

Record the full runtime version, package source, node and loaded-module and action inventories before sending anything. An action missing on Asterisk 21 or later is an expected version boundary, not evidence of a damaged recording, permission defect or incomplete module reload.

Bind Monitor to one exact channel and output plan

The Monitor action records the named Channel. Preserve ActionID, exact Channel, Uniqueid, Linkedid, bridge identity, File, Format, Mix and synchronized time before the request. Asterisk 20 documents wav as the default format and a default filename derived from the channel when File is omitted.

Those defaults do not prove the path or artifact observed on a particular system. Resolve the live channel immediately before the request, generate a safe server-side filename, and preserve the configured monitor directory, service account, mount and policy owner separately.

Treat rename, pause and resume as lifecycle transitions

ChangeMonitor changes the filename used by a Monitor session and requires both Channel and the new File. PauseMonitor temporarily stops recording on the named channel; UnpauseMonitor re-enables a recording that was previously paused. Preserve each request, response, ActionID and timestamp in order.

An accepted rename does not prove that a file was moved, closed or contains the expected interval. A pause response does not establish silence in an already buffered or downstream copy, and an unpause response does not prove that new media frames were written. Inspect the artifact timeline only after the correct session is stopped.

Close Monitor before interpreting mixed output

StopMonitor ends a previously started Monitor action on the named channel. The Asterisk 20 Monitor application records input and output to files until hangup or stop. Its mix option combines the two leg files after recording ends and normally deletes the raw legs; MONITOR_EXEC can replace that mixer, receive the two leg files and target name, and leave raw files undeleted.

Therefore, request acceptance, stop, leg-file closure, optional external command, mixed target creation, raw-file cleanup and durable storage are separate checkpoints. Do not open or upload the intended final artifact while the lifecycle or mixer is still active.

Migrate semantics rather than action names

Current Asterisk documents MixMonitor and StopMixMonitor under app_mixmonitor. MixMonitor records through a different mechanism, accepts application-style options and may expose a MixMonitor ID; StopMixMonitor can use that ID and is required to guarantee that the file is available for processing during dialplan execution.

Do not mechanically replace Monitor with MixMonitor while preserving assumptions about two raw leg files, ChangeMonitor, PauseMonitor, UnpauseMonitor or MONITOR_EXEC. Rebuild filename, direction, mute, scoped-stop, post-processing, retention and event correlation around the documented MixMonitor interface and the owning dialplan or application.

Validate legacy behavior and migration separately

For an authorized nonproduction legacy node, use one disposable call and prove exact channel identity, start, safe rename if required, pause interval, resume, stop, handle release, expected raw or mixed files, decode, duration and authorized playback. For the replacement, run an independent MixMonitor acceptance test including transfer behavior, scoped stop and one call that policy says must not record.

Keep the old and new evidence sets distinct. Documentation does not establish package availability, compatibility, file ownership, storage capacity, audio quality, legal basis or retention outcome, 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.

Continue your research

Asterisk · First-party Asterisk lifecycle, release-candidate announcement, change-log and artifact indexes were rechecked October 30, 2026. The versions table still labelled 24.x Pre-release, the project had announced 24.0.0-rc4 on October 29, and the inspected release index exposed rc1 through rc4 without establishing a final 24.0.0 release. Lifecycle labels, scheduled dates, branch documentation, candidate artifacts, downstream packages and an installed runtime remain separate evidence. No host, repository, package channel, artifact, hash, signature, source tree, dependency, build, module, configuration, process, API, endpoint, hint, parked call, packet, media stream or call was inspected or tested

Asterisk release lifecycle: status, branch docs and module availability

Read support labels and scheduled dates as separate evidence, match documentation to the running branch, and trace a feature from source and build selection to loaded capability.

Read guide →
Guide · Asterisk branch-23-generated and branch-22-generated ListCommands references plus official AMI syntax, v2 specification, manager-command, change/versioning, permission, module-loader and network-security documentation reviewed October 16, 2026; installed branch and maintenance release, build, package and module set, manager user, read and write authorizations, session mask, action registration, request framing, parameters, target objects, response, related events and service outcome remain deployment specific; no PBX, module, package, manager user, manager session, request, response, event, configuration file, channel, packet, media stream or live call was inspected or tested

Asterisk AMI command inventory and permission evidence

Use ListCommands and the administrator CLI to distinguish the actions visible to one manager user from the actions registered by the running Asterisk instance.

Read guide →
Guide · Current Asterisk branch-23-generated ModuleCheck, ModuleLoad and Reload actions, Load, Reload and Unload events, module-loader, module-troubleshooting, architecture and AMI documentation reviewed October 23, 2026; installed branch, compiled modules, dependency graph, modules.conf ownership, load order, module use count, running status, configuration validity, manager permissions, node scope and service impact remain deployment specific; no PBX, module file, dependency, configuration, manager account, session, action, reload, channel, packet, media stream or live call was inspected or tested

Asterisk AMI ModuleCheck and ModuleLoad: state, lifecycle and risk evidence

Check one module and distinguish load, unload, reload and refresh without confusing action acceptance, library presence, running state, configuration validity or working PBX behavior.

Read guide →
Guide · Current Asterisk Latest API CHANNEL_EXISTS, CHANNELS and CHANNEL references, CLI channel-operation and Local-channel optimization documentation, AMI CoreShowChannels surfaces and the upstream func_channel implementation were reviewed October 19, 2026. The generated API pages reported branch 23; installed branch, loaded modules, channel drivers, names, unique IDs, linked IDs, Local optimization, permissions, timing and call outcomes remain deployment specific. No PBX, module, dialplan, channel, bridge, manager session, packet, media stream or live call was inspected or tested

Asterisk channel inventory, identity and lifetime

Treat a channel list as a changing observation, distinguish name from unique identity, and revalidate the exact leg before an authorized operation.

Read guide →
Guide · Current branch-23-generated and branch-22 AMI MixMonitor, MixMonitorMute and StopMixMonitor action references, current MixMonitorStart, MixMonitorMute and MixMonitorStop event references, and current dialplan MixMonitor and StopMixMonitor references reviewed October 17, 2026; AMI request, action response, channel-bound audiohook, start or mute or stop event, filename, open file handle, durable file, decoded audio, retention and caller outcome remain separate evidence boundaries; installed branch, loaded app_mixmonitor module, manager permissions, event filters, channel lifetime, storage, legal basis and generated FreePBX dialplan remain deployment specific; no PBX, module, manager account, credential, session, channel, audiohook, event stream, file, packet, media stream, recording or live call was inspected or tested

Asterisk AMI MixMonitor controls and recording-event evidence

Separate AMI recording requests, channel-scoped audiohooks, start, mute and stop events, file-handle release, stored files, decoded audio and retention outcomes.

Read guide →
Guide · Asterisk 22 LTS application references and current audiohook architecture reviewed September 30, 2026; no PBX, call, channel, recording, file, processor, storage or playback path was tested

Asterisk MixMonitor: channel scope, files and recording evidence

Plan recording policy, bind MixMonitor to the intended channel and verify each file lifecycle boundary.

Read guide →
Guide · FreePBX 17 / Debian 12; module UI varies

FreePBX call recording controls

Understand recording precedence and verify the resulting audio file across transfers.

Read guide →
Guide

Planning business call recording

Decide purpose, access, storage and retention before enabling recording across every call.

Read guide →
Troubleshooting · Asterisk 20 Monitor, ChangeMonitor, PauseMonitor, UnpauseMonitor and StopMonitor AMI action references, the Asterisk 20 Monitor application, the Asterisk 21 removal notice, and current branch-23-generated MixMonitor, StopMixMonitor and CoreShowChannel references were reviewed October 25, 2026; res_monitor was deprecated in Asterisk 16 and removed in Asterisk 21, so legacy Monitor actions must not be represented as current-branch capabilities; installed release, vendor patches, loaded modules, action inventory, manager permissions, exact channel identity, monitor directory, filenames, formats, file ownership, storage, mix command, audio contents, retention and generated FreePBX dialplan remain deployment-specific; no PBX, module, manager account, action, channel, file, packet, recording, processor, endpoint or live call was inspected or tested

Asterisk AMI Monitor action is missing or its recording file is wrong

Find the first divergence across Asterisk version, res_monitor availability, manager authority, channel identity, rename and pause state, stop ordering, mixing, storage and decoded audio.

Read guide →