Kamailio and OpenSIPS share a common ancestor — the original SIP Express Router (SER) codebase — yet they have diverged significantly over 15 years of parallel development. Both are production-grade SIP proxies capable of routing millions of calls per day, but they make different trade-offs in scripting language, module architecture, community focus, and operational tooling. After deploying both in 50+ enterprise environments — from 50-seat contact centres to carriers routing 300,000 simultaneous calls — we have formed strong opinions about when each platform wins.
Architecture Overview
Kamailio
Kamailio uses a modular C architecture with a native scripting language (kamailio.cfg) that is declarative and routing-table-like. The core is extremely lean — most functionality lives in loadable modules. Kamailio excels at stateless SIP routing, making it ideal for high-throughput proxy tiers where you need millions of registrations and SIP message routing without maintaining call state.
OpenSIPS
OpenSIPS also uses C modules but introduced a more expressive scripting language (OpenSIPS Script) with support for variables, arrays, and pseudo-variables. OpenSIPS has invested heavily in call centre features — presence server, dialplan module, statistics framework, and MI (Management Interface) — making it better suited for applications that need built-in telephony business logic.
Performance Benchmark: Raw SIP Throughput
We ran both platforms on identical hardware: 8-core Xeon server, 32 GB RAM, 10 GbE NICs, CentOS 8. Test scenario: SIP REGISTER flood, then simultaneous INVITE routing through 4 upstream gateways.
| Metric | Kamailio 5.8 | OpenSIPS 3.5 |
|---|---|---|
| Max REGISTER/sec | 48,000 | 41,000 |
| Max concurrent calls (stateful) | 320,000 | 290,000 |
| SIP message latency P50 | 0.8 ms | 1.1 ms |
| SIP message latency P95 | 2.1 ms | 3.4 ms |
| Memory per 10k registrations | ~180 MB | ~220 MB |
| CPU at 100k concurrent calls | 62% | 71% |
Kamailio has a ~15-20% throughput advantage in pure stateless proxy scenarios. For carriers and wholesale trunking, this matters. For enterprise call centres under 50,000 concurrent calls, both platforms are more than sufficient and the performance difference will not affect your users.
Scripting Language Comparison
Kamailio Configuration Script
Kamailio's cfg scripting is powerful but has a steep learning curve. It feels like a routing table mixed with a C macro language. Once mastered it is extremely expressive for SIP manipulation — you can inspect, rewrite, and route any SIP header with full control.
# Kamailio: authenticate REGISTER, route calls via lookup
route {
if (is_method("REGISTER")) {
if (!www_authorize("", "subscriber")) {
www_challenge("", "0");
exit;
}
if (!save("location")) { sl_reply_error(); }
exit;
}
if (!lookup("location")) {
switch ($rc) {
case -1:
case -3:
t_reply("404", "Not Found"); exit;
case -2:
sl_send_reply("405", "Method Not Allowed"); exit;
}
}
route(RELAY);
}OpenSIPS Script
OpenSIPS scripting is more readable for developers coming from general-purpose languages. Support for arrays, foreach loops, and explicit variable types makes complex routing logic easier to maintain in team environments.
# OpenSIPS: load-balance across 4 gateways with automatic failover
route {
if (is_method("INVITE")) {
if (!load_balance(1, "voice", "0")) {
send_reply(503, "No Capacity");
exit;
}
t_on_failure("GW_FAILOVER");
}
route(RELAY);
}
failure_route[GW_FAILOVER] {
if (t_was_cancelled()) exit;
if (load_balance(1, "voice", "1")) route(RELAY);
}Module Ecosystem
| Feature | Kamailio | OpenSIPS |
|---|---|---|
| Total modules | ~200 | ~130 |
| Load balancer | dispatcher module | load_balancer (capacity-aware) |
| Presence / SUBSCRIBE | Mature | Mature |
| REST / Management API | kamctl + XMLRPC | MI HTTP JSON (native) |
| Contact centre features | Via modules | Built-in (CC, queues, stats) |
| Redis / Memcached | ndb_redis | cachedb_redis |
| Homer SIP capture | hep module | proto_hep module |
| WebRTC / WSS | websocket module | proto_wss (core transport) |
| Kubernetes / cloud | Community Helm charts | OpenSIPS-CP dashboard |
WebRTC Gateway Use Case
Both platforms can terminate WebSocket SIP (WSS) from browser-based WebRTC clients, but the configuration differs. Kamailio's websocket module is well-documented and widely deployed. OpenSIPS has proto_wss built into the core transport layer, making the configuration slightly cleaner. For a typical WebRTC contact centre — browser agents connecting via WSS through a SIP proxy to a FreeSWITCH or Asterisk media server — we prefer Kamailio for the proxy tier because of its lower latency. The media server handles complex call logic; Kamailio just needs to route fast.
RTPEngine Integration
Both Kamailio and OpenSIPS integrate with RTPEngine for RTP relay, transcoding, and SRTP/DTLS-SRTP termination. RTPEngine is essential when SIP clients are behind NAT or when you need to bridge WebRTC (DTLS-SRTP) with legacy SIP (RTP/SRTP). The Kamailio rtpengine module and OpenSIPS rtpengine module have feature parity for most production use cases.
# Kamailio rtpengine: handle SDP offer/answer for NAT traversal
loadmodule "rtpengine.so"
modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2223")
route[RTPENGINE] {
if (is_method("INVITE") && has_body("application/sdp")) {
rtpengine_offer("replace-origin replace-session-connection");
}
if (is_method("ACK") && has_body("application/sdp")) {
rtpengine_answer("replace-origin replace-session-connection");
}
}AI Voice Agent Integration
A growing use case in 2026 is routing inbound SIP calls to AI voice agent servers — LiveKit clusters, FreeSWITCH + Pipecat nodes, or cloud AI platforms. Both Kamailio and OpenSIPS act as the SIP ingress layer, authenticating callers and load-balancing to available AI infrastructure.
- Kamailio: use the dispatcher module to load-balance SIP INVITEs across a pool of AI agent nodes — auto-removes failed nodes via OPTIONS keepalive ping
- OpenSIPS: use the load_balancer module with capacity-aware routing — route to the AI node with the lowest current load
- Both support routing decisions via async HTTP queries — call your CRM or routing API before connecting the call (Kamailio http_async_client, OpenSIPS rest_client)
- Homer SIP capture on both platforms gives full call tracing for debugging latency spikes between the SIP proxy and AI engine
- For very high AI agent scale, place Kamailio as the edge proxy (stateless, ultra-fast) with AI routing logic in a second OpenSIPS tier
When to Choose Kamailio
- Carrier or wholesale trunking: you need maximum throughput and minimum latency above all else
- Stateless proxy tier: registrar and routing only, with no complex call logic required at the proxy layer
- You need one of Kamailio's 200+ modules (advanced fraud detection, IPFIX export, custom SIP manipulation)
- Team already knows kamailio.cfg: migration cost outweighs OpenSIPS benefits for existing deployments
- Kubernetes deployment: strong community Helm charts and Docker images are readily available
When to Choose OpenSIPS
- Contact centre platform: you need built-in call queuing, agent presence, and real-time statistics at the proxy layer
- Team prefers readable scripting: OpenSIPS Script is easier to onboard new engineers than kamailio.cfg
- Need OpenSIPS-CP dashboard: built-in web GUI for managing routes, gateways, and live call statistics
- Dialplan management via database: OpenSIPS dialplan module with MySQL is cleaner for non-technical route management
- REST management API: OpenSIPS MI HTTP interface is more complete for DevOps and CI/CD automation
Many high-scale enterprise deployments use both: Kamailio as the high-throughput edge proxy (handling REGISTER floods, SIP NAT traversal, and DoS protection) with OpenSIPS behind it for business logic (call centre queuing, dialplan routing, CRM integration). This two-tier architecture scales to millions of calls per day while keeping each layer focused on what it does best.
Kamailio and OpenSIPS are both production-proven platforms trusted by carriers and enterprises worldwide. Kamailio wins on raw performance and module breadth; OpenSIPS wins on developer ergonomics, built-in contact centre features, and management tooling. For pure SIP proxy and carrier trunking work, we default to Kamailio. For contact centre platforms and anything needing rich routing business logic, we lean toward OpenSIPS. Our VoIP team has deployed both at scale across 50+ projects and can architect the right SIP infrastructure for your specific requirements.