VoIP Infrastructure Guide
SIP Load Balancing
8 min read · Updated April 2026
SIP load balancing distributes call traffic across multiple servers for scalability and high availability. DNS SRV, software proxies like Kamailio, and SBCs all provide different load balancing capabilities with different tradeoffs.
1. Why SIP load balancing matters
A single SIP server becomes a bottleneck as call volume grows. Load balancing solves this by distributing SIP signaling and media across multiple servers:
- Scalability: Add servers to handle more concurrent calls without changing client configuration
- High availability: If one server fails, traffic automatically routes to healthy servers
- Geographic distribution: Route calls to the nearest server to minimize latency
- Maintenance without downtime: Take servers out of rotation for upgrades without dropping calls
2. DNS SRV load balancing
DNS SRV records let you define multiple servers for a service with priority and weight. SIP clients that support SRV lookups automatically distribute traffic across servers.
; DNS SRV records for SIP load balancing
; Format: _service._proto.name TTL class SRV priority weight port target
; Equal weight round-robin across 3 servers
_sip._udp.sip.example.com. 300 IN SRV 10 33 5060 sip1.example.com.
_sip._udp.sip.example.com. 300 IN SRV 10 33 5060 sip2.example.com.
_sip._udp.sip.example.com. 300 IN SRV 10 34 5060 sip3.example.com.
; Primary/backup failover
_sip._udp.sip.example.com. 300 IN SRV 10 100 5060 primary.example.com.
_sip._udp.sip.example.com. 300 IN SRV 20 100 5060 backup.example.com.
; TLS SRV records
_sips._tcp.sip.example.com. 300 IN SRV 10 50 5061 sip1.example.com.
_sips._tcp.sip.example.com. 300 IN SRV 10 50 5061 sip2.example.com.
Priority determines preference (lower = higher priority). Weight distributes traffic among equal-priority servers proportionally. A server with weight 100 gets twice the traffic of a server with weight 50 at the same priority.
SRV limitations: Not all SIP clients support SRV lookups. SRV does not detect server failures in real-time — it relies on SIP-level timeouts. Use SRV as a first layer with application-level health checking for production deployments.
3. Kamailio dispatcher module
Kamailio dispatcher provides dynamic load balancing with real-time health checking via OPTIONS pings:
; kamailio.cfg - dispatcher configuration
loadmodule "dispatcher.so"
modparam("dispatcher", "db_url", DBURL)
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_interval", 30)
modparam("dispatcher", "ds_probing_threshold", 3)
modparam("dispatcher", "ds_inactive_threshold", 3)
modparam("dispatcher", "ds_probing_mode", 1)
; dispatcher.list (or database table)
; setid flags priority attrs destination
1 0 10 weight=50 sip:192.168.1.10:5060
1 0 10 weight=50 sip:192.168.1.11:5060
1 0 20 weight=100 sip:192.168.1.12:5060 ; backup
; In request route
if (is_method("INVITE")) {
if (!ds_select_dst("1", "4")) { ; 4=weighted round-robin
send_reply("503", "Service Unavailable");
exit;
}
xlog("L_INFO", "[$ci] Routing to $du
");
t_relay();
}
Dispatcher algorithms: 0=round-robin, 4=weighted round-robin, 6=least connections, 8=first available. The ds_probing_mode=1 setting enables active OPTIONS health probing on all destinations, not just those receiving traffic.
4. SBC-based load balancing
Enterprise SBCs (AudioCodes, Ribbon, Oracle) provide application-aware SIP load balancing with features beyond what DNS or proxy-level load balancing offers:
- Call-aware load balancing: Track concurrent call counts per server, distribute based on actual load not just round-robin
- SIP dialog pinning: Ensure all messages for the same dialog go to the same backend server (session affinity)
- Media anchoring: Handle RTP media as well as SIP signaling
- Active/active failover: Stateful failover preserving active calls during server failure
- Codec transcoding: Normalize codecs before distributing to backend servers
5. Health checks and failover
; Kamailio - check dispatcher health status
opensipsctl fifo ds_list
; Shows each destination with status: AP (active probe) or DP (down probe)
; Force reload after adding/removing destinations
opensipsctl fifo ds_reload
; Manually mark destination as up/down
opensipsctl fifo ds_mark_dst 1 sip:192.168.1.10:5060 a ; mark active
opensipsctl fifo ds_mark_dst 1 sip:192.168.1.10:5060 i ; mark inactive
; Check OPTIONS response from a destination
sipsak -s sip:192.168.1.10:5060
Failure route handling
; Kamailio - retry on failure
failure_route[MANAGE_FAILURE] {
if (t_is_canceled()) exit;
# Try next dispatcher destination on failure
if (t_check_status("5[0-9][0-9]|4[0-9][0-9]")) {
if (ds_next_dst()) {
t_relay();
exit;
}
}
send_reply("503", "All destinations failed");
}
6. Common SIP load balancing patterns
Pattern A
Stateless proxy with DNS SRV
Simplest approach. Multiple PBX servers, DNS SRV distributes registrations and calls. No central proxy. Works well for horizontal scaling when session affinity is not needed. Requires SRV-aware clients.
Pattern B
Kamailio/OpenSIPS proxy front-end
Single Kamailio/OpenSIPS proxy receives all traffic and distributes to backend Asterisk/FreeSWITCH servers using dispatcher. Proxy handles registration, routing, and health checking. Backend servers handle media. Production-grade, supports complex routing logic.
Pattern C
SBC with backend media servers
Enterprise SBC at the network boundary handles all external traffic, distributes to backend servers. Full media anchoring, transcoding, and security. Highest cost but production-hardened with commercial support. Used by carriers and large enterprises.
Frequently asked questions
How do I load balance SIP traffic?
Load balance SIP traffic using DNS SRV records with multiple servers at equal priority and weighted distribution, a Kamailio/OpenSIPS proxy with the dispatcher module for dynamic load balancing with OPTIONS health checks, or an SBC with built-in load balancing for enterprise deployments. DNS SRV is simplest but requires SRV-aware clients; Kamailio dispatcher offers real-time health monitoring and more routing control.
What is DNS SRV for SIP load balancing?
DNS SRV records define multiple servers for a SIP domain with priority and weight values. Lower priority = higher preference. Weight distributes traffic proportionally among equal-priority servers. SIP clients that support SRV lookups automatically try servers in priority order and use weights for traffic distribution. It provides basic load balancing and failover without requiring a SIP proxy.
How does Kamailio dispatcher load balance SIP?
Kamailio dispatcher module maintains a list of destination servers and distributes SIP traffic using configurable algorithms: round-robin (0), weighted round-robin (4), or least connections (6). It sends periodic OPTIONS pings to each destination to check health. Failed destinations are automatically removed from rotation. On failure, the failure_route can call ds_next_dst() to retry on a healthy destination.
Testing your load balanced SIP infrastructure?
Paste SIP traces from your load balanced deployment into SIPSymposium. The analyzer identifies which backend server handled each call, checks for uneven distribution, and flags health check failures.