Check VICIdial recording access and retention

01 / 04

1. Find a test recording

1. Open Reports → Agent Reports → User Stats for the synthetic agent. Enter the known test date range; confirm the selected user and report timezone. Leave Call status blank unless intentionally filtering one exact code.
2. In Outbound Calls for this Time Period, locate the known DATE/TIME, CAMPAIGN, LIST, LEAD and STATUS. Use the inbound section instead for an inbound event. More than one candidate means narrow the known time/scope, not choose by filename.
3. In the same user/time scope find the available recording entry/link. If this build/report omits it, ask the report owner to locate the exact synthetic recording with recording_lookup or the bounded metadata read below.
4. Before opening audio, compare recording start/end, lead and agent with the known test. Keep full URLs and filenames in the private incident record; a link is a reference, not proof of its audio contents.

SHOW COLUMNS FROM recording_log;SELECT recording_id,lead_id,user,start_time,end_time,length_in_sec,filenameFROM recording_logWHERE lead_id=12345 AND user='YOUR_SYNTHETIC_USER'  AND start_time >= '2026-11-07 00:00:00' AND start_time < '2026-11-08 00:00:00'ORDER BY start_time,recording_id LIMIT 20;

Observed recording directory

Open to enlarge

You should seeOne authorized test event is associated with a specific recording reference, or the exact missing/ambiguous boundary is handed to the report/storage owner.

Set the exact User Stats filters →

Verify the protected SQL client →

02 / 04

2. Check the access boundary

1. With the storage/application owner, record the expected authorized role and denied role for this exact test file and export path.
2. In a fresh authorized-account browser session, open the matched test recording and verify the expected synthetic content. This is the positive access case.
3. Have the owner repeat with a separate account lacking recording rights and, if policy requires, an unauthenticated client using the exact same protected path. A redirect/200 login page is not audio access: check whether actual protected bytes are returned. Do not share a secret recording URL in a ticket.
4. Record PASS/FAIL for each role, the tested entry point and time. If denied users receive the audio, stop sharing it and escalate; changing only a directory mode is not a verified web authorization fix.

You should seeIf an unauthorized account can access the test file, stop sharing links and escalate to the owner for remediation.

03 / 04

3. Document retention and recovery ownership

1. Record where recordings are stored, the retention period and the owner of deletion and backups.
2. Confirm encryption and offsite-copy controls with the storage administrator.
3. Track any unverified recovery test as an open action; a database backup by itself does not establish that media was saved.

You should seeDo not change retention or storage until the owner approves the policy and verifies its effect.

04 / 04

Recorded lab terminal checks

Recorded lab checks were run against the synthetic demo on November 4, 2026. These read-only observations supplement the configuration steps above; they do not establish that a call, route, recording or report workflow succeeded.

Recorded lab observation: LAB01 was ONDEMAND; does not establish capture, audio quality, retention or access controls.

mysql --defaults-extra-file=/etc/vicidial-readonly.cnf --batch vicidb -e "SELECT campaign_id, campaign_recording FROM vicidial_campaigns WHERE campaign_id='LAB01';"

View a still screenshot

Recorded lab terminal: lab recording mode

Open to enlarge

You should seeThe recorded lab command and output show exactly what the demo returned. Use the original workflow’s separate end-to-end acceptance checks before declaring success.