FreePBX call recording missing, silent or incomplete

Classify the exact recording failure

Use one authorized test call and record its timestamp, direction, source, destination, route, answering party, transfers and expected recording policy. Distinguish no recording row, a row with no file, a zero-length or truncated file, one silent direction, a file that exists but will not play in the interface, and a historical file missing after retention or migration. Those symptoms belong to different layers.

Confirm recording consent and access before reproducing the issue. Do not enable broad recording on production traffic solely to obtain evidence, and do not share a call file or CDR that contains identities or conversation content outside the approved diagnostic path.

Follow FreePBX recording precedence through the route

Inspect the configured recording mode at every relevant FreePBX object in call-flow order. Sangoma documents Force, Yes, Don't Care, No and Never as precedence-bearing choices; an extension value alone does not describe an inbound route, queue, ring group, transfer or Call Recording application. Preserve the generated dialplan owner and Apply Config state rather than editing generated recording logic.

Compare the intended decision with the running call's channel variables and dialplan trace under a bounded test. A recording icon or CDR action does not prove that MixMonitor started on the leg carrying the conversation. If a transfer creates another bridge or channel, map each segment before calling the result truncated.

Prove the MixMonitor lifecycle and file target

Asterisk's MixMonitor application records audio through an audiohook and exposes the resulting filename through MIXMONITOR_FILENAME. Capture whether MixMonitor started, its target path and format, whether it was stopped, and any file-open or translation error for the affected channel. The current documentation says StopMixMonitor is required to guarantee file availability during continued dialplan processing; a file still open during the call is not final evidence.

Inspect the actual recording path under Asterisk's configured spool directory, filesystem mount, free space, inodes, ownership and write permissions. Do not repair a path problem with a permissive recursive ownership or mode change. Establish the service account, mount availability and smallest affected directory first.

Separate missing audio from missing metadata or playback

A Sangoma CDR view can expose call details and a recording play or download action, but a CDR row, CEL sequence and recording file remain different artifacts. Find the file directly using the recorded filename before assigning the fault to browser playback. If the file plays outside the interface, inspect authorization, web delivery and the row-to-file mapping; if it does not exist, return to policy and file creation.

For silent or one-sided audio, compare the call leg carrying each direction with the channel on which the audiohook was attached. A working RTP call does not prove that the chosen recording channel received both streams, and changing the trunk codec does not fix a recorder attached to the wrong leg. Preserve an original copy before format conversion or repair attempts.

Keep backup, retention and storage moves distinct

Sangoma's backup documentation states that call-recording files are not included by default and documents adding the Asterisk monitor directory as a custom backup directory. That is a backup-scope choice, not proof that a particular job, restore or external mount contains recordings. Compare the job definition, archive manifest, retention policy and restore target separately.

When files disappeared after a storage move, confirm the configured spool path, mount timing, service ordering, old location and any cleanup job before moving data again. A restored CDR database can reference files that were never backed up, while restored audio can lack a matching report row. Neither mismatch proves that the original call was not recorded.

Retest one call and protect the evidence

After correcting the demonstrated owner, place one approved call with speech from both sides, hold and the transfer pattern involved in the incident. Confirm the policy decision, MixMonitor start and stop, final filename, nonzero size, duration, both directions, authorized interface playback and download. Then repeat one nearby non-recorded case so the repair has not overridden a Never or consent boundary.

Remove temporary verbose logging, retain only the minimum incident evidence and verify that backup and deletion behavior match policy. No PBX, call, consent state, recording rule, MixMonitor process, audiohook, filesystem, backup, retention job, CDR row, browser player or audio result was tested for this guide.

core show application MixMonitor
core show application StopMixMonitor
# Reproduce one authorized call and inspect its exact channel and log window.
# Avoid leaving verbose or protocol logging enabled.

Trace an external MixMonitor controller separately

If AMI starts or stops recording, use the AMI MixMonitor diagnostic to preserve responses, events, recorder ID, path and handle-close evidence.