Vicidial Multi-Server Setup: 2026 Guide

1. Why a Single-Server Vicidial Setup Hits a Wall

Vicidial is famously easy to install on a single VICIbox VM and ramp to 80–120 simultaneous calls. The wall shows up around three pressure points: MySQL contention, RTP bandwidth, and Asterisk CPU saturation on long calls or heavy IVR scripts.

MySQL on a single box has to service every dialer cycle, every agent action, every call recording metadata insert, plus the heavy reporting queries your supervisors run. Once vicidial_log and call_log cross 100 million rows, even an indexed query can lock the dialer pipeline for seconds at a time. That is when you see the dreaded “NEW DIAL TIMEOUT” bursts in your asterisk.log.

Network is the second wall. A single 1 Gbps NIC carrying RTP for 250 active calls plus the agent web traffic plus MySQL replication is theoretically possible — but you will start losing voice packets the moment a backup job kicks off. Read our OpenSIPS scaling guide for context on how SBCs absorb that traffic.

2. Vicidial Multi-Server Setup Architecture: The Big Picture

The reference cluster we deploy looks like this:

• 1 × Web/Admin server — Apache/LiteSpeed + the agent and admin GUI. No Asterisk, no dialer process. Stateless behind a load balancer if you scale horizontally.
• 2–N × Dialer servers — each runs Asterisk + the Perl dialer (AST_VDauto_dial.pl, AST_VDadapt.pl, etc.). Sized roughly 200 concurrent calls per modern 8-core server.
• 1 × MySQL primary — handles all writes (dialer cycles, call logs, agent events).
• 1–2 × MySQL replicas — read-only, dedicated to reporting and the admin GUI dashboards.
• 1 × Archive/Recordings server — NFS or S3-compatible storage for call recordings, separated from the live cluster.
• 1–2 × SBCs (OpenSIPS / Kamailio) — perimeter SIP, registration, anti-toll-fraud, trunk failover.

Component breakdown

Roles must not overlap. Putting Asterisk and MySQL on the same box for “convenience” is the single most common reason we are called in to fix a struggling production dialer. Once the workloads are separated, you can size, monitor, and harden each tier independently.

Network requirements

Two physical NICs per dialer minimum — one for SIP/RTP traffic to the SBC, one for MySQL/HTTP back-end traffic. Place all internal traffic on a private VLAN with a 10 Gbps backbone, so MySQL replication and recordings transfer never compete with voice. Latency between dialers and the MySQL primary should stay under 1 ms; anything above 5 ms degrades hopper performance noticeably.

3. Setting Up the Asterisk/Dialer Servers

Each dialer node runs the same VICIbox image but is configured differently in vicidial_servers. Critical settings:

• active_asterisk_server = Y for the dialer nodes; N for the web server.
• sounds_update = Y on every node so prompts stay in sync — pair it with the SVN sounds repo or a shared NFS mount.
• Set generate_vicidial_conf = Y on each node so its extensions.conf regenerates automatically.
• Bind Asterisk to the SIP/RTP NIC only. Do not let Asterisk listen on the management interface.

If you are starting from scratch, our free Vicidial install guide covers the base VICIbox setup that each dialer node should begin with.

4. MySQL Replication for Vicidial Multi-Server Setup

Vicidial does not support a true multi-writer cluster. The dialer requires a single source of truth for the hopper. Use classic asynchronous replication: one primary, one or two read replicas, and a regular Percona XtraBackup snapshot to a separate host.

• Enable binlog_format = ROW and gtid_mode = ON on the primary.
• Tune innodb_buffer_pool_size to 60–70% of RAM. For a 64 GB primary, that is ~40 GB.
• On replicas, set read_only = ON and super_read_only = ON — accidental writes from the GUI are the most common cause of replication breakage we see.
• Point the admin GUI db_listing reporting queries at a replica using a separate asterisk_report user.

Hard-won lesson: never run OPTIMIZE TABLE on the primary during business hours. On a 200 GB vicidial_log it locks the table long enough to drop calls. Schedule it on a replica during the maintenance window, then promote.

5. Trunk Routing, SBCs, and Load Balancing

Hand off SIP signalling to a pair of OpenSIPS or Kamailio SBCs. The SBCs do four jobs: register the dialer nodes upstream, distribute outbound calls across them via least-load logic, terminate TLS/SRTP, and absorb attack traffic before it reaches Asterisk. We cover the scaling math in our OpenSIPS 3.6 scaling write-up.

For the agent web traffic, put the GUI behind a stateful load balancer (HAProxy or LiteSpeed Web ADC) with sticky sessions on PHPSESSID. Sticky sessions matter — Vicidial caches a lot of agent state in the PHP session, and bouncing an agent across web nodes mid-call will desync their state.

6. Vicidial Multi-Server Setup Security: Hardening Each Node

An exposed Vicidial cluster is a high-value target — toll fraud against an unpatched cluster has cost our clients five-figure SIP bills overnight. Minimum baseline:

• Never expose port 5060 to the public internet. Trunks should reach Asterisk only via the SBC; agents reach the GUI only over HTTPS via your load balancer.
• Disable guest SIP context in sip.conf: allowguest=no.
• Force secret length ≥ 24 characters for every vicidial_phones peer.
• Enable fail2ban with custom Asterisk and Apache filters; alert on > 50 failed agent logins per minute.
• Run the dialer-hardening checklist from our Vicidial hardening guide on every dialer node.
• For remote agents, terminate them on a ZeroTier or WireGuard overlay — see Securing Remote IP Phones with ZeroTier.

7. Monitoring and Capacity Planning

The four signals that actually matter for a multi-server Vicidial cluster:

• Asterisk active channels per dialer (Prometheus exporter or a simple asterisk -rx "core show channels count" scrape every 10 s).
• MySQL replication lag in seconds — alert at > 30 s.
• Hopper level per campaign — if the hopper drains faster than it refills, dialer drop rate climbs.
• RTP packet loss / jitter at the SBC.

Plot agents-online vs. CPU per dialer over a working week. Add a new dialer when any node sustains 70%+ CPU during peak. Linear scaling holds well into the low thousands of agents if MySQL is healthy and the SBCs are sized right.

8. Common Pitfalls We See in 2026 Deployments

• Leaving active_keepalive=Y on the wrong server. Two keepalives racing causes random campaign pauses.
• Time drift between dialer nodes. If clocks differ by > 1 second, agent transfers fail mysteriously. Use chronyd against a single internal stratum-2 source.
• Reusing the same server_id in my.cnf across replicas — replication will silently overwrite GTID positions.
• Putting recordings on the dialer disk. Recordings I/O eats Asterisk CPU; ship them to NFS or S3 within 60 seconds of call end.

Each of these we have personally fixed in production. They are not theoretical.

Frequently Asked Questions

How many concurrent calls can a single Vicidial dialer node handle?

On a modern 8-core / 32 GB VM with NVMe storage and a clean voicemail/IVR config, plan for ~200 simultaneous calls per dialer node. Heavy IVR scripts, call recording on local disk, or single-NIC networking will pull that down to 100–120.

Can I run Vicidial in a true active-active multi-master MySQL cluster?

No — the dialer architecture assumes a single authoritative writer for the hopper. Galera and InnoDB Cluster cause subtle race conditions in the dialer cycle. Use one primary plus replicas, and rely on a fast failover script for HA.

Do I need an SBC if my carrier delivers SIP directly?

For a serious deployment, yes. The SBC gives you trunk failover, anti-toll-fraud rate-limiting, TLS/SRTP termination, and a clean security boundary. Direct carrier SIP into Asterisk is acceptable only for very small lab installs.

How much MySQL storage should I plan for per million calls?

Roughly 1.5–2 GB per million completed calls in vicidial_log and related tables, before recordings. Plan archive jobs to move call_log rows older than 90 days off the hot tables.

What is the easiest way to add a new dialer node to a running cluster?

Provision a fresh VICIbox VM, register it in vicidial_servers with the same MySQL credentials, run install.pl in cluster mode, allow inbound SIP from the SBC, and let the next generate_vicidial_conf run write its dialplan. Watch the first 30 minutes of asterisk.log for any dialplan errors before adding it to a campaign.

Why Vicidial Multi-Server Setup Pays Back Inside 12 Months

Vicidial multi-server setup pays back operationally before financially. Single-box deployments hit a hard ceiling around 350 concurrent agents; vicidial multi-server setup removes that ceiling and adds patch cadence, predictable MySQL performance, and disaster-recovery posture. The vicidial multi-server setup architecture documented in this guide is the same one we deploy for clients running 500–5,000 agents — same component layout, same MySQL replication pattern, same OpenSIPS SBC perimeter. The variation is sizing, not architecture.

Further reading: VICIdial.org official open-source project.