ViciDial Recording Setup and Storage Planning

How ViciDial Recording Works at the Asterisk Layer

ViciDial triggers call recording through the Asterisk Monitor() or MixMonitor() application, depending on your build version. Modern ViciDial deployments (0.5+ SVN) use MixMonitor(), which records both audio channels into a single mixed file. Older builds used Monitor() and created two separate files (inbound and outbound audio) that required a post-call mix step.

MixMonitor() writes audio directly to disk in the configured format during the call, in real time. This means recording is an I/O operation running continuously for the duration of every recorded call. On a 150-agent floor with 80% recording rate and average talk time of 4 minutes, you have roughly 120 simultaneous file write streams during peak hours.

Step 1: Enable Recording in ViciDial Admin

Navigate to Admin → Campaigns → Campaign Detail → Recording Settings:

• Call Recording: Set to ALLCALLS to record all connected calls, or SALESONLY to record only calls where the agent marks a disposition indicating a sale. ALLCALLS is the standard for QA-heavy operations.
• Recording File Format: Use wav for maximum compatibility with downstream QA tools. gsm files are smaller but require transcoding for most analysis platforms. ogg is compact and high-quality but less universally supported.
• Recording Filename Prefix: Set a meaningful prefix that includes campaign identifier — this simplifies retrieval and storage organization.

Step 2: Configure the Recording Directory

Recording files land in the directory configured in asterisk.conf under astastvarsdir and the Monitor directory path, typically /var/spool/asterisk/monitor/. Ensure this path:

1. Is on a dedicated disk or partition separate from the OS and Asterisk log partition
2. Has sufficient write speed — spinning disk works for up to ~100 concurrent recordings; for 200+, use SSD or a fast NAS with NFS mount

Do not write recordings to the same volume as the OS, Asterisk logs, or the ViciDial application. A filled recording volume will crash the Asterisk process.

Step 4: Automated Archival to Object Storage

Storing 90+ days of recordings on the Asterisk host's local disk is impractical. The standard architecture:

1. Local disk (SSD/NVMe): 7–14 days of hot recordings. Agents and supervisors access recent recordings directly.
2. NFS or iSCSI NAS: 30–90 days of warm recordings. Accessible but not on the fastest tier.
3. Object storage (S3-compatible): 90+ days of cold recordings. Accessed via API, not direct file path.

Automate the movement between tiers with a cron job that checks recording age and moves or copies files accordingly. A simple bash script using find and aws s3 cp (or the equivalent for your object storage provider) runs on a nightly schedule.

Remove local copies after successful upload confirmation — do not leave both local and remote copies indefinitely. Verify the remote copy checksums before deleting local.

Step 5: Recording Retrieval in ViciDial

ViciDial's Reports → Call Log section links CDR entries to recording files by filename. The CDR stores the recording filename; ViciDial Admin generates a playback link. For this to work, the web server must have access to the recording directory.

If recordings are on a remote NAS or object storage, configure either:

• A symbolic link in the web-accessible directory pointing to the NAS mount path
• A thin proxy endpoint that fetches recordings from object storage by CDR lookup

The second option is more secure — recordings are not directly web-accessible, and all retrieval goes through an authenticated application layer.

Step 6: I/O Impact and Mitigation

Recording on a busy ViciDial floor competes with Asterisk's real-time call processing for disk I/O. Signs of I/O contention:

• Asterisk log shows MixMonitor write error or dropped recording frames
• System iostat shows disk utilization consistently above 80% during peak hours
• Recordings have gaps or clicks (periodic I/O starvation)

Mitigations:

• Dedicated disk for recordings (physically separate from OS/Asterisk partition)
• Write recordings to a RAM-based tmpfs mount and sync to disk asynchronously (advanced — requires a robust sync daemon to avoid data loss on crash)
• Use Linux I/O scheduler mq-deadline for Asterisk servers with mixed random and sequential workloads

For reference: a 200-agent floor at full recording generates approximately 40 MB/s of sustained disk writes at peak. Spinning disk achieves 80–120 MB/s sequential; consumer SSD achieves 400–500 MB/s. SSD is appropriate for floors above 150 agents running ALLCALLS recording.