Installing VICIdial on a VPS

A VPS is a good home for VICIdial. The install is the same as on bare metal — patched Asterisk, the schema, the Perl layer. What's different is the network, and three things there decide whether your calls carry audio: the public IP, the RTP range, and NAT.

A real, static public IP

VICIdial wants a dedicated, static public IP. Your Carrier whitelists it for the SIP trunk, your agents reach the admin and the Webphone at it, and Asterisk advertises it in SIP. A shared or rotating IP breaks all three. Confirm the provider gives you a real routable address, not one behind a provider-side NAT you can't see.

The RTP port range

Signaling and media travel on different ports. SIP (Session Initiation Protocol) sets the call up on port 5060; the actual audio rides RTP on a wide UDP range, commonly 10000 to 20000. The classic VPS mistake is opening 5060 and stopping there. The call rings, the agent answers, and there's silence — because the media ports are closed. Open the full RTP range in the VPS firewall and in any provider-level security group.

sequenceDiagram
  participant C as Carrier
  participant F as VPS firewall
  participant A as Asterisk
  C->>F: SIP INVITE on 5060
  F->>A: allowed
  A-->>C: 200 OK with public IP in SDP
  C->>F: RTP audio on 10000-20000
  F-->>A: blocked if range closed
  Note over A,C: open RTP range or you get one way or no audio

NAT, when the IP isn't on the interface

Some providers give you a public IP that isn't bound directly to the server's interface — the box sees a private 10.x or 172.x address and the public IP lives on a router in front. Asterisk then advertises the private address in its SDP, and your carrier tries to send audio to an address it can't reach. That's a one-way or no-audio call every time.

The fix is to tell Asterisk its real external address. Set the external media address and mark the local subnet as local, so it writes the public IP into signaling while still talking to the right internal interface. This is the single most common NAT traversal problem on a VPS, and it's purely a config fix once you spot it. If your box has a clean public IP straight on the interface, you may not need it at all — check before you add it.

Sizing and the boring extras

For a single dialing box, modest specs go a long way — a few vCPUs and a few gigs of RAM handle a meaningful agent count, since the heavy lifting is per-channel audio, not CPU. Watch disk if you keep Call recording on the box; recordings accumulate fast. And keep the VPS provider's network reputation in mind — a noisy IP block can get your outbound flagged regardless of how clean your install is.

One more thing the cloud adds: oversubscription. A budget VPS shares its host CPU with other tenants, and audio is sensitive to jitter in a way that a web app isn't. If agents report choppy calls under load on an otherwise healthy box, the cause is often a noisy neighbor stealing cycles, not your config. A dedicated or CPU-pinned plan removes that variable, which matters more for a dialer than raw core count does.

For the exact firewall rules, our VICIdial firewall ports guide lists every port to open, and the full install guide covers the build around them.

We provision your dedicated VPS with a real public IP, the RTP range open, and NAT handled — secured VICIdial in under 40 seconds, with root SSH so you can still tune any of it. See VPS-backed plans on our pricing page.