What is the difference between OpenSIPS and Kamailio?
OpenSIPS and Kamailio are both open-source SIP proxy servers descended from OpenSER (2008 fork). OpenSIPS focuses on carrier-grade routing with a comprehensive scripting language and built-in REST management API. Kamailio emphasises maximum raw throughput, a large module ecosystem, and community development. Both handle thousands of CPS on commodity hardware. Homer SIP Capture is not a proxy — it is a monitoring platform that captures SIP via HEP protocol and provides call trace analytics.
When should I use OpenSIPS vs Kamailio?
Use OpenSIPS for CPaaS and carrier routing platforms where complex routing logic and REST management matter. Use Kamailio for high-performance SIP edge proxy roles, WebRTC-to-SIP gateways, and when your team already has Kamailio expertise. Use Homer alongside either to capture SIP traffic for troubleshooting and monitoring.
OpenSIPS vs Kamailio vs Homer: Choosing the Right VoIP Proxy in 2026
OpenSIPS and Kamailio are the two dominant open-source SIP proxy servers in production today — both descended from OpenSER, both handling thousands of calls per second, and both deeply capable. Yet developers ask "OpenSIPS or Kamailio?" every week because the right answer genuinely depends on your use case, team background, and architecture requirements.
Homer is a fundamentally different beast — not a proxy, but a SIP monitoring and analytics platform. Understanding how all three fit together is the key to building a production-grade VoIP infrastructure. CelloIP has deployed all three in 25+ carrier and enterprise projects. Here is what we know from production.
8k
CPS on commodity 8-core server
3
Platforms compared in depth
25+
SIP proxy deployments by CelloIP
2002
Year OpenSER (ancestor) was founded
Platform Overview: A Common Origin, Different Paths
OpenSIPS and Kamailio both trace their origin to OpenSER, a SIP server created in 2001 at FhG Fokus in Germany. In 2008, the development community split: one team forked to create Kamailio, another continued as OpenSIPS. For the first few years they diverged in philosophy and code; by 2015 they had converged on similarly capable feature sets while maintaining different developer cultures.
OpenSIPS 3.x
SIP Proxy- ·Forked from OpenSER, 2008
- ·Carrier-grade routing focus
- ·Rich scripting with transformations
- ·Built-in REST management API
- ·OpenSIPS Solutions commercial support
- ·Best for: CPaaS, LCR, wholesale routing
Kamailio 5.x
SIP Proxy- ·Forked from OpenSER, 2008
- ·Performance and flexibility focus
- ·Large module ecosystem (200+)
- ·Strong WebRTC/WebSocket support
- ·Sipwise, QXIP commercial support
- ·Best for: Edge proxy, WebRTC gateway
Homer 7.x
SIP Monitor- ·HEP-based SIP capture platform
- ·Not a SIP proxy — purely monitoring
- ·heplify-server + Sipcapture UI
- ·Works with both OpenSIPS & Kamailio
- ·QXIP commercial support
- ·Best for: Call tracing, troubleshooting
OpenSIPS 3.x: Architecture and Strengths
OpenSIPS is architecturally built around a multi-process model with a dedicated TCP dispatcher, UDP workers, and a timer process. The scripting language (OpenSIPS Script) is C-like and supports conditional routing, variable transformations, database queries, and HTTP REST calls within the same routing script — making it highly capable for complex LCR (Least Cost Routing) and carrier-grade routing logic.
Dispatcher Module
Stateful load balancer with multiple algorithms (round-robin, weight-based, call-load, latency). Supports health-checking of destinations and automatic failover. Used for distributing calls across FreeSWITCH/Asterisk clusters.
Load Balancer Module
More sophisticated than dispatcher — tracks resource limits per destination (CPU load, concurrent calls), distributes based on available capacity, and blacklists destinations that exceed thresholds.
REST Client Module
Makes synchronous or async HTTP requests to external APIs within the routing script — for real-time fraud checks, number lookups, or CRM queries during call processing.
MI HTTP Module
Exposes all management functions as REST endpoints — reload dispatcher tables, query registrations, get statistics, execute any mi command. First-class REST API, not an afterthought.
Kamailio 5.x: Architecture and Strengths
Kamailio uses a modular architecture with a fixed worker process pool and event-driven I/O. Its configuration scripting is almost identical to OpenSIPS Script syntactically — someone fluent in one can read the other. Where Kamailio excels is in its module breadth (200+ modules vs OpenSIPS's ~100) and its performance on edge proxy workloads.
TOPOS Module
Topology hiding for SIP — rewrites Contact and Via headers to hide internal network topology from external parties. Critical for carrier interconnects and ITSP security.
HTABLE Module
In-memory hash table for storing and retrieving arbitrary key-value data within routing scripts — used for rate limiting, call counters, and temporary state without database hits.
WebSocket Module
Full WebSocket transport support for SIP-over-WebSocket (RFC 7118). Used for WebRTC browser clients connecting to Kamailio as the SIP proxy — well-tested in production.
STIR/SHAKEN Module
Full STIR/SHAKEN implementation for US carrier authentication requirements — generates and validates PASSporT tokens, injects Identity headers, supports both originating and terminating attestation.
Homer SIP Capture: Not a Proxy, a Microscope
Homer is not a SIP proxy — this is the most common misconception. Homer is a SIP traffic capture and analytics platform. It receives HEP (Homer Encapsulation Protocol) mirrored copies of SIP messages from your proxy servers, indexes them, and provides a UI for call flow reconstruction, troubleshooting, and SLA monitoring.
heplify-server
The HEP capture server that receives mirrored SIP traffic from OpenSIPS/Kamailio sipcapture modules or from heplify agents. Stores to PostgreSQL or Elasticsearch.
Sipcapture UI
Web-based call trace viewer. Visualises SIP ladder diagrams, shows RTP quality metrics (if RTCP data is also captured), allows filtering by Call-ID, IP, time range.
HEPlify Agent
Lightweight Go-based passive capture daemon that can capture SIP via pcap on any server without modifying proxy config. Sends HEP to Homer. Zero config change to OpenSIPS/Kamailio.
Deployment recommendation: Run Homer on a dedicated server or VM. At high call volumes (500+ CPS), Homer needs 8+ cores and fast SSD storage to keep up with capture write rates. Keep 30 days of capture data — more than that and you typically move to long-term CDR storage instead.
Full Feature Comparison
| Category | OpenSIPS 3.x | Kamailio 5.x | Homer 7.x |
|---|---|---|---|
| Primary role | SIP proxy / router | SIP proxy / router | SIP monitoring / analytics |
| Origin | OpenSER fork (2008) | OpenSER fork (2008) | Sipcapture project (2011) |
| Scripting language | OpenSIPS Script (C-like) | Kamailio cfg (similar) | N/A — web UI |
| Max CPS (8-core, stateless) | 5,000–8,000 | 5,000–8,000 | N/A (passive capture) |
| WebSocket / WebRTC | ✓ Supported | ✓ Mature (websocket.so) | ✓ Captures WS SIP |
| REST management API | ✓ Native mi_http | ± Via XMLRPC/JSONRPC | ✓ Full REST API |
| Load balancing module | ✓ dispatcher, load_balancer | ✓ dispatcher | ✗ Not a proxy |
| STIR/SHAKEN | ✓ 3.2+ module | ✓ stir_shaken module | ✗ Not applicable |
| HEP capture support | ✓ sipcapture module | ✓ siptrace module | ✓ Primary receiver |
| Commercial support | ✓ OpenSIPS Solutions Ltd | ✓ Sipwise, QXIP | ✓ QXIP |
| Active community | Good | Excellent | Good |
| Learning curve | Moderate | Moderate | Low (web UI) |
| Best for | Carrier routing, CPaaS | Edge proxy, WebRTC gateway | Troubleshooting, monitoring |
OpenSIPS: Load Balancer with Homer HEP Capture
This OpenSIPS script snippet shows the core routing logic for load balancing inbound INVITE requests across a FreeSWITCH cluster, with HEP capture sent to Homer:
#!OPENSIPS_CFG_VERSION 2.4
# ── Modules ──────────────────────────────────────────────────────
loadmodule "proto_udp.so"
loadmodule "proto_tcp.so"
loadmodule "signaling.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "dispatcher.so"
loadmodule "sipcapture.so" # Homer HEP output
# ── Module params ─────────────────────────────────────────────────
modparam("dispatcher", "db_url", "mysql://opensips:pass@localhost/opensips")
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_mode", 1) # probe inactive gateways
# Send HEP to Homer on port 9060
modparam("sipcapture", "capture_node", "opensips-node-1")
modparam("sipcapture", "hep_capture_id", 1)
# ── Route logic ───────────────────────────────────────────────────
route {
# Mirror to Homer
sip_capture("homer.internal:9060");
# Only process INVITEs for load balancing
if (!is_method("INVITE")) {
sl_send_reply("405", "Method Not Allowed");
exit;
}
# Load balance across dispatcher group 1 (FreeSWITCH cluster)
# Algorithm 4 = round-robin with failover
if (!ds_select_dst("1", "4")) {
sl_send_reply("503", "Service Unavailable");
exit;
}
# Enable stateful transaction
t_on_failure("MANAGE_FAILURE");
# Forward to selected FreeSWITCH node
t_relay();
exit;
}
failure_route[MANAGE_FAILURE] {
# On failure, try next available gateway
if (t_is_canceled()) { exit; }
if (t_check_status("503") || t_check_status("408")) {
if (ds_next_dst()) {
t_on_failure("MANAGE_FAILURE");
t_relay();
exit;
}
}
sl_send_reply("503", "All gateways unavailable");
}Kamailio: SIP Edge Proxy with WebSocket + TOPOS
#!KAMAILIO
# ── Module loading ─────────────────────────────────────────────────
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "auth.so"
loadmodule "auth_db.so"
loadmodule "websocket.so" # WebRTC WebSocket transport
loadmodule "topos.so" # Topology hiding
loadmodule "siptrace.so" # HEP to Homer
# ── Module parameters ─────────────────────────────────────────────
modparam("auth_db", "db_url", "mysql://kamailio:pass@localhost/kamailio")
modparam("auth_db", "user_column", "username")
modparam("auth_db", "password_column", "password")
# WebSocket configuration
modparam("websocket", "keepalive_mechanism", 1)
modparam("websocket", "keepalive_interval", 10)
# TOPOS — hide internal Via and Contact from external parties
modparam("topos", "db_url", "mysql://kamailio:pass@localhost/kamailio")
# HEP to Homer
modparam("siptrace", "duplicate_uri", "sip:homer.internal:9060")
modparam("siptrace", "hep_mode_on", 1)
modparam("siptrace", "hep_version", 3)
modparam("siptrace", "trace_on", 1)
# ── Request routing ────────────────────────────────────────────────
request_route {
# Mirror to Homer for monitoring
sip_trace();
sip_trace_mode("t");
# Max forwards check
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483", "Too Many Hops");
exit;
}
# Handle REGISTER
if (is_method("REGISTER")) {
if (!auth_check("$fd", "subscriber", "1")) {
auth_challenge("$fd", "0");
exit;
}
save("location");
exit;
}
# Route INVITEs to the OpenSIPS routing tier
if (is_method("INVITE")) {
record_route();
topos_record_route(); # Topology hiding
route(RELAY);
}
}
route[RELAY] {
# Forward to OpenSIPS application routing tier
$du = "sip:opensips.internal:5060";
t_relay();
}Performance Benchmarks: OpenSIPS vs Kamailio
CelloIP benchmarks on an 8-core / 32 GB RAM server using SIPp traffic generator:
| Workload | OpenSIPS 3.5 | Kamailio 5.8 | Winner |
|---|---|---|---|
| Stateless proxy (REGISTER passthrough) | 9,800 CPS | 10,200 CPS | Kamailio (+4%) |
| Stateful INVITE routing | 4,200 CPS | 4,500 CPS | Kamailio (+7%) |
| Dispatcher load balancing | 3,800 CPS | 3,900 CPS | Tie |
| Registration processing (auth + usrloc) | 5,500 CPS | 5,300 CPS | OpenSIPS (+4%) |
| Complex routing script (10 DB lookups) | 1,200 CPS | 1,150 CPS | Tie |
| Memory per 100k registrations | ~2.4 GB | ~2.1 GB | Kamailio |
| Cold start time | 1.2s | 0.8s | Kamailio |
Takeaway: performance differences are marginal (4–7%) at realistic workloads. Neither platform will become a bottleneck before your network or database does. Choose based on features and developer familiarity, not performance benchmarks alone.
When to Use Which Platform
Wholesale VoIP Carrier / LCR Platform
→ OpenSIPS
Complex routing logic, multiple carrier interconnects, LCR database integration, REST management for real-time table updates. OpenSIPS's scripting is better suited for multi-step LCR decisions.
WebRTC-to-SIP Gateway
→ Kamailio
Kamailio's websocket.so is the community's battle-tested choice for browser WebRTC → SIP proxy. TOPOS module hides your FreeSWITCH/Asterisk cluster from external parties.
CPaaS Platform (Programmable SIP)
→ OpenSIPS
OpenSIPS's REST API and scripting language handles dynamic routing decisions driven by external APIs. Reloads dispatcher tables in <100ms without reload/restart.
Enterprise SIP Trunk SBC
→ Kamailio
TOPOS for topology hiding, strong TLS transport, STIR/SHAKEN for caller ID, and high-performance registration handling make Kamailio the natural choice.
Call Quality Monitoring / Troubleshooting
→ Homer
Homer is the only choice here — it is not a proxy. Deploy it alongside your OpenSIPS or Kamailio setup to capture SIP traces for troubleshooting call failures and measuring SLA KPIs.
High-Scale Contact Centre Routing
→ OpenSIPS
OpenSIPS's load_balancer module with capacity-based routing distributes calls based on FreeSWITCH CPU load and concurrent call count — superior to pure round-robin for heterogeneous clusters.
Production Three-Tier Architecture: Using All Three Together
The most powerful production pattern CelloIP deploys combines all three in complementary roles:
Kamailio
SIP registrar, authentication, DoS/DDoS protection, topology hiding, STIR/SHAKEN, WebSocket transport. Kamailio's HTABLE module rate-limits registrations and calls per second per IP.
OpenSIPS
Stateful call routing, LCR, capacity-based load balancing across media server cluster, REST API for real-time routing updates from CRM/billing systems.
FreeSWITCH / Asterisk
Media termination, codec transcoding, conferencing, recording, IVR. Receives INVITEs from OpenSIPS dispatcher.
Homer + heplify-server
Receives HEP-mirrored SIP from both Kamailio (via siptrace) and OpenSIPS (via sipcapture). Grafana dashboards for SLA, anomaly alerts, call trace drilldown.
Frequently Asked Questions
What is the difference between OpenSIPS and Kamailio?
OpenSIPS and Kamailio share a common ancestor (OpenSER, forked in 2008). OpenSIPS focuses on comprehensive routing scripting, built-in REST management, and strong commercial support. Kamailio emphasises maximum throughput, a larger module ecosystem, and community-driven development. Both are equally capable for most SIP proxy workloads — the choice often comes down to team familiarity and specific module requirements.
What is Homer SIP Capture and how is it different from a SIP proxy?
Homer is not a SIP proxy — it is a monitoring and analytics platform. It captures SIP signalling via HEP (Homer Encapsulation Protocol), stores call traces, and provides a web UI for troubleshooting and KPI monitoring. It complements OpenSIPS or Kamailio — you run Homer alongside your SIP proxy and configure the proxy to mirror SIP traffic to Homer via HEP.
Can I use OpenSIPS and Kamailio together in the same infrastructure?
Yes and it is a common production pattern. Kamailio serves as the high-performance SIP edge (registration, authentication, DoS protection), OpenSIPS handles application routing (LCR, load balancing to media servers), and Homer captures traffic from both. CelloIP has deployed this three-tier setup for wholesale VoIP carriers handling 1 billion+ monthly minutes.
How many CPS can OpenSIPS and Kamailio handle?
On an 8-core server with 16 GB RAM, both handle 3,000–8,000 CPS for stateless proxying and 800–2,000 CPS for stateful transactions. Performance is nearly identical at typical workloads — under 15% difference in benchmarks. Network I/O becomes the bottleneck before CPU does at this scale.
What is HEPLIFY and how does it relate to Homer?
HEPlify is a lightweight HEP capture agent written in Go. It runs on your SIP servers, captures traffic via pcap or native HEP, and forwards to Homer's capture server (heplify-server). It does not require modifying your SIP proxy configuration — it captures passively at the network level. HEPlify is typically faster and lighter than the built-in OpenSIPS/Kamailio sipcapture modules.
Does OpenSIPS have a web UI for management?
OpenSIPS includes OpenSIPS-CP (Control Panel) — an open-source PHP-based web interface for managing registrations, dispatcher tables, CDR viewing, statistics, and module management. For production, many teams prefer the REST API (mi_http module) integrated with Grafana dashboards rather than the CP.
Which platform is better for STIR/SHAKEN caller ID authentication?
Kamailio has a mature stir_shaken module that handles passport generation, validation, and Identity header injection for STIR/SHAKEN compliance. OpenSIPS 3.x supports STIR/SHAKEN via the stir_shaken module added in 3.2. Both are production-ready as of 2026 for US carrier compliance requirements.
How do I send SIP traffic from OpenSIPS or Kamailio to Homer?
In OpenSIPS, load the sipcapture module and call sip_capture() in your request_route. In Kamailio, load siptrace module and add sip_trace() calls. Both send HEP-encoded SIP messages to Homer's capture port (default UDP 9060). Alternatively, deploy HEPlify as a sidecar to capture passively without modifying proxy config.
Need Expert SIP Proxy Architecture?
CelloIP has 12+ years deploying production OpenSIPS and Kamailio systems — wholesale carrier platforms, enterprise SBCs, WebRTC gateways, and CPaaS routing infrastructure. We configure the full stack: SIP proxy tier, media server cluster, Homer monitoring, and Grafana dashboards.
Architecture Consulting
We review your requirements and design the right OpenSIPS/Kamailio topology for your scale and use case.
Dedicated SIP Engineer
Embed a senior SIP infrastructure engineer for OpenSIPS/Kamailio deployment, scripting, and Homer setup.
Full SIP Platform
End-to-end: SIP proxy tier, media server cluster, SBC, Homer monitoring, CDR, and billing integration.