VoIP high availability means designing a telephony platform so that no single failure, whether a server, a network link, a SIP carrier or an application dependency, stops callers from reaching you. For a contact center, a healthcare provider or a payment line, an outage is immediately visible to customers. Voxivra designs and operates Asterisk-based architectures with redundancy built in at every layer, and we are explicit about what each design protects and what it does not.
Start with the failure modes
Before choosing a cluster topology, we list what can fail and what the business impact would be:
- Asterisk node failure: hardware, VM, crash or a bad deployment.
- Application dependency: the FastAGI or ARI service, the database, the CRM API, the speech AI provider.
- Network: data center connectivity, firewall, NAT device, DNS.
- SIP carrier: trunk outage or routing problems at the provider.
- Human error: a configuration change that breaks the dialplan on every node at once.
Each one calls for a different safeguard. Clustering Asterisk does nothing for a carrier outage, and two carriers do nothing for a dialplan error deployed everywhere.
Topology 1: active/passive
Two Asterisk servers share a virtual IP address. The active node handles all calls; the passive node takes over the address if the active one fails. This is typically implemented with keepalived (VRRP) or Pacemaker and Corosync, with configuration synchronized between nodes and a shared or replicated database.
Strengths: simple to understand, few moving parts, works with most existing dialplans. Limits: half of the capacity sits idle, failover takes a few seconds, calls in progress on the failed node are lost, and split-brain must be prevented with proper fencing or quorum.
We recommend active/passive for moderate volumes where one server handles the peak load comfortably and the team wants an architecture it can operate without specialized SIP proxy skills.
Topology 2: active/active behind a SIP proxy
A SIP proxy, usually Kamailio or OpenSIPS, receives all signaling and distributes calls across several Asterisk nodes. The proxy itself is deployed as a redundant pair.
Carriers / SBC
|
Kamailio (pair, shared VIP)
dispatcher + OPTIONS probes
/ | \
Asterisk 1 Asterisk 2 Asterisk 3
\ | /
Shared DB / config / ARI or FastAGI servicesKamailio’s dispatcher module sends periodic SIP OPTIONS to every node. A node that stops answering is marked inactive and receives no new calls until it recovers. Distribution can be round-robin, weighted or hash-based (for example by Call-ID), and nodes can be drained gracefully for maintenance.
For media, Asterisk nodes often handle RTP directly. When NAT traversal, topology hiding or a single public media address are needed, a relay such as RTPengine is added alongside Kamailio.
Strengths: horizontal scaling, no idle capacity, rolling upgrades node by node, a single node failure affects only its share of calls. Requirements: application logic must not depend on which node handles a call. That means stateless FastAGI or ARI services, shared configuration (Asterisk Realtime or configuration management), and shared or replicated data (for example, a PostgreSQL or MariaDB Galera cluster).
Health checks beyond “the server responds”
A node can answer SIP OPTIONS while its ARI application is disconnected or its database is unreachable. Good health checks reflect the ability to actually serve calls:
- SIP-level probes from the proxy (OPTIONS) for basic reachability;
- application-level checks: the ARI WebSocket is connected, FastAGI responds within its timeout, the database is reachable;
- synthetic test calls placed regularly through the real path, checking that prompts play and DTMF is recognized;
- metrics and alerts on active channels, failed calls, SIP response codes, RTP quality and registration status.
A node that fails application checks should be removed from the dispatcher automatically, not only flagged on a dashboard.
Carrier and network redundancy
- At least two SIP carriers or two independent paths to the same carrier, with outbound routing that fails over on errors or timeouts.
- Inbound redundancy: DNS SRV records or multiple signaling addresses registered with the carrier, so inbound calls reach a surviving site.
- Geographic redundancy where the business case justifies it: a second site or cloud region, with numbers that can be rerouted quickly.
- Graceful degradation: if the AI voicebot provider fails, calls fall back to a simpler IVR or straight to a queue rather than failing.
Deployments and testing
Most real outages come from changes. We use versioned configuration, staged rollouts (one node first, then the rest), automated tests on the dialplan and applications, and load tests with SIP traffic generators before go-live. Failover is tested on a schedule, not only on paper: we pull a node, a carrier and a dependency, and verify the result.
When Voxivra recommends which design
| Situation | Typical recommendation |
|---|---|
| Single site, moderate volume, small team | Active/passive pair, two carriers, monitoring |
| Growing volume, AI voicebots, frequent releases | Kamailio pair + active/active Asterisk nodes, stateless apps |
| Critical service, regulatory or contractual uptime needs | Multi-site active/active, geo-redundant carriers, regular failover drills |
We do not promise a specific uptime figure without knowing your infrastructure and providers; availability is the product of every layer. What we provide is an architecture whose failure behavior is understood, documented and tested.
High availability goes hand in hand with VoIP security, since an attack or fraud incident is also an outage. If you are moving from a single legacy server, our telephony migration service covers the transition without downtime, and our support and consulting team can operate the platform with you. For a review of your current architecture, get in touch.