VICIdial Call Recording: The Storage Math Nobody Does Until It's Too Late

Last updated: March 2026 | Reading time: ~20 minutes Call recording in VICIdial is one of those features that seems simple until it isn't. You enable campaign recording, calls get recorded, files land on disk. Easy. Then six months later you are staring at a server with 2 TB of WAV files, your compliance team is asking about PCI-DSS, a client wants recordings from 14 months ago that you already deleted, and you realize you never actually planned any of this. This guide covers everything about VICIdial call recording that matters in a production environment: how the recording system works at the Asterisk level, storage format decisions and their real-world implications, capacity planning with actual numbers, compliance requirements by jurisdiction and industry, archival strategies that scale, and the database tables that track it all. Whether you are running 10 agents or 500, if you record calls, you need a recording strategy. Not having one is how operations end up with compliance violations, disk space emergencies at 2 AM, and the inability to produce recordings when a regulator or a lawyer asks for them. ViciStack handles recording infrastructure as part of every deployment --- properly sized storage, automated archival pipelines, and compliance-ready configurations included. Skip the storage headaches. --- ## How VICIdial Call Recording Actually Works Understanding the recording pipeline is essential before you can optimize, troubleshoot, or build compliance processes around it. Here is what happens when a call is recorded in VICIdial. ### The MixMon Application VICIdial uses Asterisk's MixMon() application (or Monitor() on older installations) to capture call audio. When an agent connects to a call and recording is enabled, VICIdial's vicidial_manager process sends an Asterisk Manager Interface (AMI) command that injects MixMon() into the active channel. MixMon captures both sides of the conversation --- the agent's audio and the caller's audio --- and mixes them into a single file. This is called "mixed mode" recording. The alternative, "stereo" recording (agent on one channel, caller on the other), is available but rarely used in production because it doubles storage requirements and most QA workflows expect a single mixed file. The recording command looks like this internally: Action: Originate Channel: Local/5555@default Application: MixMonitor Data: /var/spool/asterisk/monitor/MIXmonitor/20260318-093045_1234567890_6001_campaign1.wav,b The b option tells MixMon to only begin recording when the call is bridged (when both parties are connected), which avoids recording ring time and IVR navigation. ### File Naming and Location VICIdial stores recordings in a predictable directory structure: /var/spool/asterisk/monitor/MIXmonitor/ ├── 20260318-093045_1234567890_6001_campaign1.wav ├── 20260318-093112_5551234567_6002_campaign1.wav └── ... The default filename format is: YYYYMMDD-HHMMSS_PHONENUMBER_AGENTEXTENSION_CAMPAIGNID.wav This naming convention means files are naturally sorted chronologically and you can identify the phone number, agent, and campaign from the filename alone. VICIdial also tracks this information in the database (covered below), but the filename structure is a useful fallback for manual file browsing. The default path /var/spool/asterisk/monitor/MIXmonitor/ is configurable. On a cluster deployment, each telephony server writes recordings locally to its own disk. The web server needs access to these files for playback, which typically means either NFS mounts or a centralized recording server that pulls files from each dialer. ### The recording_log Table Every recording that VICIdial creates gets an entry in the recording_log table in the asterisk database. This is the authoritative index of all recordings: | Column | Purpose | |--------|---------| | recording_id | Auto-increment primary key | | channel | The Asterisk channel that was recorded | | server_ip | Which server made the recording | | extension | Agent extension | | start_time | When recording began | | start_epoch | Unix timestamp of recording start | | end_time | When recording ended | | end_epoch | Unix timestamp of recording end | | length_in_sec | Duration of the recording in seconds | | length_in_min | Duration in minutes (decimal) | | filename | Full filename of the recording file | | location | Full filesystem path or URL to the recording | | lead_id | Links to the vicidial_list lead record | | user | The agent's user ID | | vicidial_id | Links to the vicidial_log or vicidial_closer_log entry | This table is what powers recording search and playback in the VICIdial admin interface. When a manager searches for recordings by date range, phone number, or agent, VICIdial queries recording_log and returns links to the audio files. ### The recording_access Table VICIdial 2.14+ includes a recording_access table that logs who accessed which recordings and when. This is critical for compliance --- particularly HIPAA and PCI-DSS --- where you need an audit trail showing which personnel listened to which recordings. sql -- Check who has accessed recordings for a specific lead SELECT ra.user, ra.access_datetime, rl.filename FROM recording_access ra JOIN recording_log rl ON ra.recording_id = rl.recording_id WHERE rl.lead_id = 12345 ORDER BY ra.access_datetime DESC; --- ## Recording Formats: WAV vs MP3 This is one of the most impactful decisions you will make about your recording system, and it is not as straightforward as "MP3 is smaller, use MP3." ### WAV (Uncompressed) VICIdial records in WAV format by default. Specifically, 8 kHz, 16-bit, mono PCM WAV files. This is the native format of G.711 telephony audio. Storage per minute: approximately 960 KB/minute (about 1 MB/minute for easy math). Advantages: - No CPU overhead during recording --- the audio is already in PCM format from the Asterisk channel - Lossless quality --- you capture every bit of audio fidelity the telephone network provides - Universally compatible --- every audio player, transcription service, and forensic tool handles WAV natively - Required by some compliance frameworks that mandate "original quality" recordings Disadvantages: - Large file sizes --- a 5-minute call is approximately 5 MB - Expensive to store long-term at scale ### MP3 (Compressed) MP3 encoding can be enabled in VICIdial by installing the LAME encoder and configuring the recording format. MP3 at 32 kbps (which is more than adequate for speech-quality telephony audio) reduces file sizes by approximately 8-10x compared to WAV. Storage per minute: approximately 120 KB/minute at 32 kbps, or 240 KB/minute at 64 kbps. Advantages: - Dramatically smaller files --- a 5-minute call is approximately 600 KB at 32 kbps - Reduces storage costs by 80-90% - Faster to transfer, download, and archive Disadvantages: - Requires LAME encoder installation and CPU overhead during recording - Lossy compression --- some audio quality is permanently lost - The CPU cost of real-time MP3 encoding is non-trivial: at 50 concurrent recordings, expect 5-10% additional CPU utilization on the telephony server - Some compliance frameworks reject lossy-compressed recordings ### The Practical Recommendation Record in WAV. Convert to MP3 for archival. This gives you the best of both worlds: original-quality recordings during the active period when QA, disputes, and compliance reviews happen, and compressed recordings for long-term storage. Here is the conversion script we use: bash #!/bin/bash # convert_recordings.sh # Convert WAV recordings older than 30 days to MP3 # Run via cron: 0 2 * * * /usr/local/bin/convert_recordings.sh RECORDING_DIR="/var/spool/asterisk/monitor/MIXmonitor" ARCHIVE_DIR="/var/spool/asterisk/monitor/ARCHIVE" DAYS_BEFORE_CONVERT=30 mkdir -p ${ARCHIVE_DIR} find ${RECORDING_DIR} -name "*.wav" -mtime +${DAYS_BEFORE_CONVERT} | while read wavfile; do mp3file="${ARCHIVE_DIR}/$(basename ${wavfile%.wav}.mp3)" lame --quiet -b 32 --resample 8 "${wavfile}" "${mp3file}" if [ $? -eq 0 ] && [ -f "${mp3file}" ]; then # Update the recording_log table with new location filename=$(basename "${wavfile}") mysql -u cron -p'your_cron_password' asterisk -e \ "UPDATE recording_log SET location='${mp3file}' WHERE filename LIKE '%${filename%.*}%';" rm "${wavfile}" echo "Converted: ${wavfile} -> ${mp3file}" fi done ### Installing LAME for MP3 Support If you want native MP3 recording (skipping WAV entirely): bash # AlmaLinux 9 / Rocky Linux 9 dnf install epel-release dnf install lame lame-devel # ViciBox (openSUSE) zypper install lame libmp3lame0 # Verify LAME is available lame --version Then in VICIdial Admin, navigate to Admin > System Settings > Recording and set the recording format to MP3. Asterisk will use LAME to encode recordings in real-time. --- ## Storage Capacity Planning This is where operations get surprised. Call recordings consume storage faster than most people expect, and running out of disk space on a production VICIdial server is a critical failure --- Asterisk will stop recording and may drop active calls. ### The Math Here are the actual numbers for a 50-agent outbound operation running 8 hours/day: | Metric | Value | |--------|-------| | Agents | 50 | | Shift duration | 8 hours | | Average talk time per hour | 40-48 minutes | | Average call duration (connected calls) | 2-4 minutes | | Calls per agent per hour | 12-20 (with predictive dialing) | | Percentage of calls recorded | 100% (recommended) | WAV storage per day: - 50 agents x 8 hours x 45 min avg talk time = 18,000 minutes of recordings/day - 18,000 minutes x 0.96 MB/min = 17.3 GB/day WAV storage per month (22 working days): - 17.3 GB x 22 = 380 GB/month MP3 storage per month (at 32 kbps): - 18,000 min x 22 days x 0.12 MB/min = 47.5 GB/month Annual storage: - WAV: ~4.5 TB/year - MP3: ~570 GB/year These numbers scale linearly with agent count. A 100-agent operation generates double. A 200-agent operation generates quadruple. If you are running multi-shift or 24/7 operations, multiply accordingly. ### Storage Sizing Recommendations | Agent Count | Daily WAV | Monthly WAV | Recommended Local Disk | Archive Strategy | |-------------|-----------|-------------|----------------------|-----------------| | 10 agents | 3.5 GB | 77 GB | 500 GB SSD | Monthly offsite | | 25 agents | 8.6 GB | 190 GB | 1 TB SSD | Weekly offsite | | 50 agents | 17.3 GB | 380 GB | 2 TB SSD/RAID | Daily offsite | | 100 agents | 34.6 GB | 760 GB | 4 TB RAID | Daily offsite + S3 | | 200+ agents | 69+ GB | 1.5+ TB | Dedicated NAS/SAN | Real-time replication | Critical rule: Never let your recording partition exceed 80% utilization. Set up monitoring alerts at 70% and 80%. When you hit 80%, either archive old recordings or add storage. At 95%, Asterisk recording will start failing silently. ### Disk Space Monitoring Add this to your crontab for daily disk space alerts: bash #!/bin/bash # check_recording_disk.sh THRESHOLD=80 PARTITION="/var/spool/asterisk/monitor" USAGE=$(df -h ${PARTITION} | awk 'NR==2 {print $5}' | tr -d '%') if [ ${USAGE} -gt ${THRESHOLD} ]; then echo "WARNING: Recording partition at ${USAGE}% usage on $(hostname)" | \ mail -s "VICIdial Recording Disk Alert" [email protected] fi Schedule it: 0 */4 * * * /usr/local/bin/check_recording_disk.sh > Never Worry About Recording Storage Again. > ViciStack deployments include automated archival pipelines, disk monitoring, and compliance-ready retention policies. Learn More. --- ## Archival Strategies Keeping all recordings on your primary VICIdial server's local disk is not sustainable. Here are the archival approaches, from simplest to most robust. ### VICIdial's Built-In ARCHIVE Flag VICIdial includes a built-in recording archival mechanism. In Admin > System Settings, the Archive settings control an automated process that moves recordings from the active directory to an archive directory after a configurable number of days. The system works through the AST_audio_archive.pl script that runs via cron. It reads from recording_log, moves files to the archive path, and updates the location column in the database to reflect the new path. This is the simplest archival option and works well for single-server deployments with attached archive storage. ### rsync to Archive Server For multi-server clusters where each telephony server generates recordings locally: bash #!/bin/bash # sync_recordings.sh - Run on each telephony server # Syncs recordings to a central archive server ARCHIVE_SERVER="10.0.2.50" ARCHIVE_PATH="/recordings/$(hostname)" LOCAL_PATH="/var/spool/asterisk/monitor/MIXmonitor/" rsync -avz --remove-source-files \ --include="*.wav" --include="*.mp3" --exclude="*" \ ${LOCAL_PATH} ${ARCHIVE_SERVER}:${ARCHIVE_PATH}/ Schedule this hourly or daily depending on your storage headroom. The --remove-source-files flag frees up local disk after successful transfer. Make sure SSH key authentication is configured between servers. ### S3/MinIO for Long-Term Storage For operations that need years of recording retention (common in financial services, healthcare, and insurance), object storage is the most cost-effective solution. AWS S3: ```bash #!/bin/bash # s3_archive.sh - Archive recordings older than 90 days to S3 RECORDING_DIR="/var/spool/asterisk/monitor/MIXmonitor" S3_BUCKET="s3://company-vicidial-recordings" DAYS_OLD=90 find

Read the full article

About

Built by ViciStack — enterprise VoIP and call center infrastructure.

• VICIdial Hosting & Optimization
• Call Center Performance Guides
• Full Article: VICIdial Call Recording: The Storage Math Nobody Does Until It's Too Late

License

MIT