OpenSIPSLoad BalancingSBCDispatcherHigh AvailabilitySIP Proxy

OpenSIPS Load Balancing & SBC Setup

Deploy carrier-grade SIP load balancing with OpenSIPS. Master the dispatcher module, implement intelligent health checking, configure sticky routing, and build highly available SIP clusters that handle 10,000+ concurrent calls. CelloIP has shipped 25+ production implementations across tier-1 carriers and enterprise VoIP systems.

By Kaushik Parmar • 4,200 words • 18 min read•Updated April 2026

10,000+

Concurrent calls per node

<1ms

Added signalling latency

100ms

Sub-second failover

25+

Carrier deployments by CelloIP

Contents

Why OpenSIPS for Load Balancing?Carrier-Grade Architecture Dispatcher Module Setup Advanced Routing Script Intelligent Health Checking Load Balancing Algorithms Sticky Routing & Session Persistence SBC & Security Features Monitoring & Failover Comparison Table FAQ Get Expert Help

Why OpenSIPS for Load Balancing?

In carrier-grade VoIP environments, no single SIP server can handle all traffic reliably. Hardware fails, calls surge, deployments scale. This is where OpenSIPS load balancing becomes essential. Unlike hardware load balancers (F5, Citrix) costing €50k+, OpenSIPS is free, open-source, and purpose-built for SIP.

OpenSIPS sits in front of your Asterisk, FreeSWITCH, or Kamailio servers and makes intelligent routing decisions based on real-time health, call count, and custom algorithms. It's a full Session Border Controller (SBC) when configured properly—handling codec negotiation, topology hiding, TLS termination, and security policies.

✓ Benefits

• Zero licensing cost
• Sub-100ms failover
• 8+ load balancing algorithms
• Real SBC features (codec control, TLS)
• Carrier-proven at scale

⚠ Challenges

• Requires routing script expertise
• Steeper learning curve
• Memory/CPU overhead vs. passive proxy
• CDR complexity with multiple backends

Carrier-Grade Architecture

A production OpenSIPS load balancer sits at the network edge, receiving calls from external carriers, SIP trunks, and clients. It proxies them to a backend cluster of application servers (Asterisk, FreeSWITCH, etc.). Each backend periodically proves its health via SIP OPTIONS messages, allowing OpenSIPS to reroute traffic if a server dies.

[SIP Clients/Carriers] → [OpenSIPS LB] → [Asterisk Cluster (5–50 nodes)]

OpenSIPS proxies INVITEs, REGISTERs, and BYEs. It tracks health per server, applies security policies (rate limiting, codec filtering), hides internal topology (removes Via, Route headers), and optionally relays RTP. Existing calls survive server restart; new calls route to healthy peers.

Deployment Models

Single-Point Load Balancer

One OpenSIPS instance fronts the cluster. Suitable for ≤5,000 concurrent calls. Upgrade to dual redundant (Active/Backup) for HA.

Multi-Region Failover

OpenSIPS instances in different geographic zones. DNS round-robin or explicit failover rules route traffic. CelloIP's preferred model for carriers.

Dispatcher Module Setup

The dispatcher module is OpenSIPS's load-balancing engine. It maintains a list of destination servers (gateways, Asterisk boxes) with metadata (weight, flags, state) and applies routing algorithms.

dispatcher.list File

dispatcher.listServer groups with weights and algorithms

# id  destination           description
# Set 0: Asterisk Cluster (Round-Robin)
1 sip:10.0.1.10:5060   "AST-01" 0 0 0
2 sip:10.0.1.11:5060   "AST-02" 0 0 0
3 sip:10.0.1.12:5060   "AST-03" 0 0 0

# Set 1: SIP Trunk Gateways (Weight-Based)
1 sip:192.168.1.100:5060   "TRUNK-A" 10 0 0
2 sip:192.168.1.101:5060   "TRUNK-B" 5 0 0

# Set 2: Carrier Gateway (Backup, lower priority)
1 sip:203.0.113.50:5060    "CARRIER" 1 0 0

Flags field (column 5): Use 0 for standard behavior. Advanced flags can disable health checks (4) or mark as backup-only (8).

Loading dispatcher.list at Runtime

shellReload without restart

# SSH to OpenSIPS box
$ opensips-cli -x dispatch reload

# Or via UNIX domain socket
$ echo "reload_dispatcher" | osipsconsole -s /tmp/opensips_uds_socket

Advanced Routing Script

The routing script is where load-balancing logic lives. Here's a production-ready example that:

Proxies REGISTER to backend for SIP registration
Routes INVITE to dispatcher Set 0 (Asterisk cluster)
Implements CallID-based sticky routing
Applies per-user rate limiting

opensips.cfgProduction routing logic (excerpt)

# Load dispatcher module
loadmodule "dispatcher.so"

# Modparam: reload from database
modparam("dispatcher", "db_url", "mysql://root:password@localhost/opensips")

# Dispatch Sets IDs
#  0 = Asterisk cluster
#  1 = SIP trunk gateways

route {
  # Skip authentication for initial REGISTER
  if (is_method("REGISTER")) {
    # Forward to backend via dispatcher Set 1 (trunk gateways)
    ds_select_dst(1, "W");  # W = weighted routing
    t_on_failure("register_failover");
    t_relay();
    exit;
  }

  # For INVITE/MESSAGE, use sticky routing
  if (is_method("INVITE")) {
    # Check existing call via CallID hash
    if (ds_is_in_list("$si", "$sp", "0")) {
      # Source is already a backend; skip loop prevention
      ds_select_dst(0, "H");  # H = hash routing
    } else {
      # First-time INVITE: distribute via dispatcher Set 0
      ds_select_dst(0, "RR");  # RR = round-robin

      # Apply rate limit: max 100 calls per user per minute
      if (is_avp_set("$avp(user_calls)")) {
        if ($avp(user_calls) > 100) {
          send_reply(429, "Too Many Requests");
          exit;
        }
      }
    }

    t_on_failure("invite_failover");
    t_on_reply("reply_route");
    t_relay();
    exit;
  }

  # Default: pass through
  t_relay();
}

# Failover logic for INVITE
failure_route[invite_failover] {
  if (t_is_canceled()) exit;
  if (t_check_status("408|500|503")) {
    # Mark server down and try next
    ds_mark_dst("P");  # Probing state
    ds_next_dst();
    t_on_failure("invite_failover");
    t_relay();
  } else {
    t_reply();
  }
}

Intelligent Health Checking

OpenSIPS probes backend servers periodically using SIP OPTIONS messages. If a server stops responding, OpenSIPS marks it down and stops routing to it until it recovers.

Configuration

opensips.cfgHealth check parameters

loadmodule "dispatcher.so"

modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_interval", 10)    # Check every 10 seconds
modparam("dispatcher", "ds_ping_from", "sip:[email protected]")
modparam("dispatcher", "ds_max_icons", 3)         # 3 consecutive failures = down
modparam("dispatcher", "ds_probing_threshold", 2) # Recover after 2 successes

# Optional: Use PRACK for more strict health checking
modparam("dispatcher", "ds_ping_method", "PRACK")

Health Check Behavior

State Flow:

ACTIVE → (OPTIONS fails 3x) → PROBING → (OPTIONS succeeds 2x) → ACTIVE

When a server is in PROBING state, new calls bypass it but existing calls stay (session persistence). Once it recovers, it returns to ACTIVE and accepts new traffic.

Load Balancing Algorithms Explained

OpenSIPS supports multiple algorithms. Choose based on your cluster characteristics and backend statefulness.

Round Robin (id=0)

Cycles through all healthy servers in order

Best for: Homogeneous cluster, even load expected

Weight-Based (id=4)

Routes proportional to numeric weight field

Best for: Mixed hardware tiers, intentional imbalance

Least Loaded (id=8)

Routes to server with fewest active calls

Best for: Highly variable load, dynamic scaling

Hash From-URI (id=10)

Consistent hashing based on SIP From header

Best for: Stateful apps, user session affinity

Algorithm Selection in Code

opensips.cfgDispatcher routing methods

# Round-Robin (algorithm ID 0)
ds_select_dst(0, "RR");

# Weight-Based (algorithm ID 4)
ds_select_dst(1, "W");

# Least Loaded (algorithm ID 8)
ds_select_dst(0, "LL");

# Hash (algorithm ID 10)
ds_select_dst(0, "H");  # Hash on From URI by default

Sticky Routing & Session Persistence

Sticky routing (session affinity) ensures all SIP messages for the same call always route to the same backend server. This is critical for stateful applications like PBX that track call state, user context, or media authentication per call.

Sticky Routing Methods

CallID Pinning (Recommended)

Hash the SIP Call-ID header to always route the same call to the same server. Works for stateful apps.

ds_select_dst(0, "HC"); # Hash on Call-ID

From-URI Hashing

Hash the From URI to ensure the same user always hits the same backend. Good for registration state.

ds_select_dst(0, "HF"); # Hash on From URI

To-URI Hashing

Hash on To URI for recipient affinity. Useful for backend session state keyed by callee.

ds_select_dst(0, "HT"); # Hash on To URI

Overriding Sticky Routing on Failover

opensips.cfgSticky routing with failover fallback

failure_route[invite_failover] {
  if (t_is_canceled()) exit;

  if (t_check_status("503")) {
    # Server down but we have sticky routing.
    # Mark it probing and find next server via same algorithm
    ds_mark_dst("P");

    # Try next server (breaks stickiness but preserves failover)
    if (ds_next_dst()) {
      t_on_failure("invite_failover");  # In case next also fails
      t_relay();
    } else {
      # No more servers; return 503
      send_reply(503, "Service Unavailable");
    }
  }
}

Session Border Controller (SBC) Features

Beyond load balancing, OpenSIPS can function as a full SBC when configured with security, topology hiding, codec control, and TLS termination. This protects your internal network and enforces policies at the edge.

Codec Normalization

Restrict codecs between networks

Topology Hiding

Remove internal headers and topology

TLS Termination

Decrypt TLS on ingress, re-encrypt on egress

SIP Header Manipulation

Add/remove/modify routing and user headers

Media Relay

Optional RTP bridging for encrypted calls

Rate Limiting

Throttle by user, source IP, or call count

Codec Normalization Example

opensips.cfgRestrict codecs between networks

loadmodule "sipmsgops.so"

# Remove 'in' codecs from external ingress; add 'out' codecs for backend
route[codec_fix] {
  # Strip codecs from external calls before proxying to internal
  if (get_in_sdp_codecs() =~ /opus/) {
    remove_codecs();  # Remove opus from external caller
    add_codec("PCMU");  # Transcode to PCMU for backend
  }
}

Topology Hiding

opensips.cfgHide internal headers and routes

loadmodule "sipmsgops.so"

modparam("sipmsgops", "remove_hf_name", "P-Asserted-Identity")
modparam("sipmsgops", "remove_hf_name", "P-Preferred-Identity")

# Rewrite Via headers to hide internal IP
remove_hf("Via");
append_hf("Via: SIP/2.0/UDP lb.celloip.com\r\n");

Monitoring & Failover Strategy

A robust OpenSIPS load balancer needs real-time monitoring to track server health, call volume, and performance. Integrate with Prometheus, Grafana, or syslog for visibility.

Key Metrics to Monitor

Server state: ACTIVE, PROBING, DISABLED (check every 60 seconds)
Response time: Average SIP OPTIONS RTT per backend (should be <100ms)
Call volume: Calls/sec per dispatcher set; imbalance ratios
Failover events: Count of servers marked down and recovered per hour
Dispatcher latency: Time to route INVITE through dispatcher (should be <10ms)

OpenSIPS-CLI Monitoring

shellCheck dispatcher status

$ opensips-cli -x dispatcher list

GW-Index = 0 (Asterisk)
  id=1  sip:10.0.1.10:5060  state=ACTIVE  weight=0  calls=245
  id=2  sip:10.0.1.11:5060  state=ACTIVE  weight=0  calls=312
  id=3  sip:10.0.1.12:5060  state=PROBING weight=0  calls=0

GW-Index = 1 (Trunks)
  id=1  sip:192.168.1.100:5060  state=ACTIVE  weight=10  calls=156

OpenSIPS vs. Alternatives

How does OpenSIPS compare to other SIP load balancers? Here's the real breakdown:

Aspect	OpenSIPS	Hardware SBC	Kamailio
Protocol Support	SIP, SIP/WSS, TLS, SRTP	Limited or separate module	Similar to OpenSIPS
Load Balancing Algorithms	8+ (Round Robin, Weight, Hash, Least-Load)	Typically 2–4	Similar to OpenSIPS
Health Checking	OPTIONS, PRACK, custom	Basic ICMP or TCP	Similar to OpenSIPS
Sticky Routing	CallID, From URI, To URI	Often fixed/static	Similar to OpenSIPS
Failover Speed	Sub-second	1–5 seconds typical	Similar to OpenSIPS
SBC Features	Codec control, topology hiding, TLS termination	Partial or feature-gated	Similar to OpenSIPS
Cost	Free, open-source	€10k–€100k+ licensing	Similar to OpenSIPS

Frequently Asked Questions

Q: What is the difference between OpenSIPS load balancer and a traditional SBC?

A: OpenSIPS is a lightweight, open-source proxy that can function as an SBC when configured with proper security (TLS, codec control, header manipulation). Traditional SBCs are often hardware appliances with dedicated management GUIs. OpenSIPS offers better customization and zero licensing cost.

Q: How quickly does OpenSIPS failover when a backend server goes down?

A: Sub-second — typically 10–100 ms. When a health check fails, OpenSIPS marks the server as down and immediately routes new requests to healthy peers. Existing calls are not rerouted unless you implement CallID-based sticky routing override.

Q: Can OpenSIPS load balance WebRTC and traditional SIP simultaneously?

A: Yes. OpenSIPS can proxy WebRTC clients over WSS to one dispatcher set and traditional SIP endpoints to another. The websocket module allows bidirectional proxying between WebRTC and UDP/TLS SIP.

Q: What is CallID pinning and why is it important?

A: CallID pinning (sticky routing by Call-ID) ensures all messages in the same call session route to the same backend server. This is critical for stateful applications like VoIP PBX or IVR systems that track call state.

Q: How do I prevent toll fraud in an OpenSIPS load balancer setup?

A: Implement rate limiting per user/IP, validate CLI (Calling Line Identity), reject unregistered users, enforce TLS, log all CDRs, and monitor for anomalous patterns (e.g., hundreds of calls to expensive destinations in minutes).

Q: Can I use OpenSIPS in front of multiple Asterisk clusters across different data centers?

A: Yes. Deploy multiple OpenSIPS instances (one per region) with geographic DNS failover, or use a single OpenSIPS instance with dispatcher groups per region. CelloIP has shipped multi-region OpenSIPS clusters for tier-1 carriers.

Q: Does OpenSIPS support GSLB (geographic server load balancing)?

A: OpenSIPS itself doesn't handle DNS, but you can integrate it with external GSLB solutions or use round-robin DNS with health checks. For true geo-failover, deploy multiple OpenSIPS instances in different regions with SLA-based failover.

Q: What hardware do I need to run OpenSIPS at carrier scale?

A: Modern multi-core servers (8+ cores, 16+ GB RAM) easily handle 5,000–10,000 concurrent calls per box. At 50,000+ calls, use 2–4 load-balanced OpenSIPS instances. CelloIP has deployed on standard AWS/Azure instances and on-premises hardware.

Expert OpenSIPS Consulting & Development

Deploying OpenSIPS at scale requires deep expertise in SIP routing, cluster architecture, and operational support. CelloIP specializes in carrier-grade VoIP infrastructure. We've built 25+ production OpenSIPS clusters for tier-1 carriers, MVNOs, and enterprise customers.

Fixed-Price Implementation

$15k–$50k

Architecture design
Dispatcher config
Health checking setup
Failover testing

Dedicated OpenSIPS Developer

$4k–$8k/mo

Full routing script ownership
24/7 escalation support
Performance tuning
Continuous deployment

Team Augmentation

$6k–$12k/mo

2–3 senior engineers
Architecture consultation
Custom module development
Production SLA

Related Services

Hire VoIP Developers Hire Voice AI Developers OpenSIPS Development Asterisk Development FreeSWITCH Development Kamailio SBC Development Voice Bot Dev Guide Contact Our Engineers

Back to Blog Talk to a VoIP Engineer

What is OpenSIPS load balancing?

How does the OpenSIPS dispatcher module work?

What is sticky routing in OpenSIPS?

OpenSIPS Load Balancing & SBC Setup

Why OpenSIPS for Load Balancing?

✓ Benefits

⚠ Challenges

Carrier-Grade Architecture

Deployment Models

Single-Point Load Balancer

Multi-Region Failover

Dispatcher Module Setup

dispatcher.list File

Loading dispatcher.list at Runtime

Advanced Routing Script

Intelligent Health Checking

Configuration

Health Check Behavior

Load Balancing Algorithms Explained

Round Robin (id=0)

Weight-Based (id=4)

Least Loaded (id=8)

Hash From-URI (id=10)

Algorithm Selection in Code

Sticky Routing & Session Persistence

Sticky Routing Methods

CallID Pinning (Recommended)

From-URI Hashing

To-URI Hashing

Overriding Sticky Routing on Failover

Session Border Controller (SBC) Features

Codec Normalization

Topology Hiding

TLS Termination

SIP Header Manipulation

Media Relay

Rate Limiting

Codec Normalization Example

Topology Hiding

Monitoring & Failover Strategy

Key Metrics to Monitor

OpenSIPS-CLI Monitoring

OpenSIPS vs. Alternatives

Frequently Asked Questions

Q: What is the difference between OpenSIPS load balancer and a traditional SBC?

Q: How quickly does OpenSIPS failover when a backend server goes down?

Q: Can OpenSIPS load balance WebRTC and traditional SIP simultaneously?

Q: What is CallID pinning and why is it important?

Q: How do I prevent toll fraud in an OpenSIPS load balancer setup?

Q: Can I use OpenSIPS in front of multiple Asterisk clusters across different data centers?

Q: Does OpenSIPS support GSLB (geographic server load balancing)?

Q: What hardware do I need to run OpenSIPS at carrier scale?

Expert OpenSIPS Consulting & Development

Fixed-Price Implementation

Dedicated OpenSIPS Developer

Team Augmentation

Related Services