Web server vs telephony server roles

A VICIdial deployment has two jobs that live in different places. The web role serves the screens — Apache and PHP rendering the admin and agent interfaces. The telephony role moves the calls — Asterisk handling signaling and audio. On a single box they share a machine; in a multi-server build they split, and understanding the split is how you size and scale a cluster.

What the web server does

The web server is Apache plus PHP plus the VICIdial application code. It draws the admin pages where you build a Campaign, loads leads, and reads reports; it draws the agent screen where dispositions get logged. It talks to the database constantly and to Asterisk through the AMI (Asterisk Manager Interface) to issue commands — originate this call, hang up that one. What it does not do is touch the audio. No RTP stream goes through the web role.

What the telephony server does

The telephony server is Asterisk and the dialer processes around it. It holds the SIP trunk to your Carrier, places the outbound calls, and carries the media. The Keepalive loop and the Perl listen processes that drive predictive dialing live here, reading the hopper and originating channels. This is the role that needs the open RTP range and the public IP; the web role doesn't.

flowchart LR
  AG[Agent browser] --> WEB[Web server Apache and PHP]
  WEB <--> DB[(Database)]
  WEB -- AMI commands --> TEL[Telephony server Asterisk]
  TEL <--> DB
  TEL -- SIP and RTP --> CAR[Carrier]
  CAR -- audio --> TEL
  TEL -- media --> AG

How they talk

The two roles coordinate through the database and the AMI (Asterisk Manager Interface). When an agent clicks to dial, the web server writes intent to the database and sends an AMI command to the telephony server, which originates the call over the SIP (Session Initiation Protocol) trunk. The audio then flows from carrier to telephony server to the agent's endpoint, never through Apache. Keep that picture and the whole architecture stops being mysterious.

Why split them at all

Two reasons. Capacity — a busy telephony server carrying hundreds of concurrent channels shouldn't also be rendering report pages for fifty agents; separating the roles lets each scale on its own bottleneck. And resilience — one web server can front several telephony servers, so a single Asterisk box going down doesn't take the whole admin interface with it. That's the heart of a multi-server VICIdial.

For a small or mid-size operation, none of that is necessary. A single box runs both roles fine and is far simpler to operate — one Conf file set, one machine to patch, one place to look when something breaks. Split only when a single server genuinely runs out of room.

A multi-server build also adds its own work. The web server needs database grants for every telephony box, the servers table in the admin has to list each one with its role, and the clocks need to stay in sync or the reports drift. Add a server to the cluster and you're maintaining one more Asterisk to patch, one more firewall to keep tight, one more place a misconfigured SIP (Session Initiation Protocol) peer can break a call. The split buys capacity and resilience, but it isn't free — which is exactly why most operations should stay single-server until the numbers force the move.

Which one you actually need

Most operators start single-server and never outgrow it. If you're weighing the split, our single-server versus cluster guide walks the decision, and the install guide covers the build for both layouts.

Our managed boxes run both roles on a dedicated Single tenant server — the common case — provisioned in under 40 seconds with root SSH, so you can grow into a split later if you ever need it. See plans on our pricing page.