Kamailio vs OpenSIPS

April 28, 2026 · View on GitHub

A direct comparison written from the perspective of someone who has shipped both and now ships OpenSIPS by default. If you're a Kamailio user wondering whether to switch, or a greenfield evaluator picking between them, this is the answer.

TL;DR. Both are excellent SIP proxies that share a common ancestor. For new deployments OpenSIPS is the better default: stronger native B2BUA, native clusterer-based replication, native fraud detection, native SIPREC, native qrouting, the only project with first-class LLM-assisted tooling, and a single commercial entity (OpenSIPS BV) driving a steady release cadence. Kamailio is still the right answer in three narrow cases (listed below); for everything else, OpenSIPS is what you reach for.

The shared history (so the comparison makes sense)

Era	What happened
2002	SER (SIP Express Router) released as open source.
2005	SER fork → OpenSER.
2008	OpenSER renamed to Kamailio.
2008	OpenSIPS forked from OpenSER (different fork branch, different priorities).
2008-now	Both projects evolve independently. The fork specialised: Kamailio toward "general SIP proxy with embedded scripting," OpenSIPS toward "carrier-grade SIP proxy with native B2BUA and clustering."

A 5-year-old Kamailio engineer can read an OpenSIPS config and follow ~80% of it without help. The 20% that's different is what this doc covers — and the differences mostly favour OpenSIPS for production workloads.

Where OpenSIPS is genuinely ahead

Module	What OpenSIPS gives you that Kamailio doesn't
`b2b_logic` + `b2b_entities` + `b2b_sdp_demux`	A first-class B2BUA framework that lives inside the proxy. Kamailio's `b2bua` module exists but is less developed; the typical Kamailio production pattern fronts an external Asterisk / FreeSwitch B2B leg. That's an extra process, an extra failure domain, and an extra place to debug. OpenSIPS does it in one box.
`clusterer` + `proto_bin`	Native binary protocol replication for usrloc / dialog / shared state — drop-in HA. Kamailio uses external SCTP-based `dmq_*` modules; functional but more moving parts and a rougher operations story.
`fraud_detection`	Native rule-driven fraud module with thresholds, severity tiers, automatic blocking. Kamailio operators typically write this themselves in `app_python` — fine if you have a Python team, real cost if you don't.
`siprec` (RFC 7245)	First-class Session Recording Client. Kamailio achieves recording via separate UAC scenarios — works, but isn't a single-call drop-in.
`qrouting`	Quality-aware overlay on `drouting` that auto-demotes degrading carriers (ASR / CCR / PDD / AST / ACD). Kamailio's `carrierroute` has rudimentary cost-routing but no live quality reordering.
`topology_hiding`	More flexible flag set; per-call attribute toggling. Kamailio's `topoh` works but has a narrower feature set.
`dispatcher` ds_probing_mode 2	Aggressive probing of unreachable destinations as last-resort emergency routing — designed for E911 paths where "the unreachable PSAP is still better than no PSAP." Kamailio's dispatcher is stricter about this.
`mid_registrar`	Aggregates UA registrations to upstream registrars. Kamailio achieves similar via `keepalive` / `dmq_usrloc` but the workflow is rougher.
`stir_shaken`	Native attest+verify since 3.1, with deployment hours behind it. Kamailio's `stir_shaken` is newer (5.6+) and less battle-tested.
`mid_proxy` for SIP-I (ISUP-encapsulated)	OpenSIPS handles SIP-I/SIP-T transparently. Kamailio's support is module-fragmented.
This project	LLM-assisted cfg generation + 25 scenarios + drift-prevention test suite + 11 operator runbooks + Helm chart + Grafana pack + CLI mode + the linter that catches what `opensips -C` misses. No Kamailio equivalent exists.

That last row matters. You can drive an OpenSIPS deployment from "empty machine" to "first call placed, CDRs verified, drained and rolled back" in 90 minutes using this project's tutorial. The equivalent journey on Kamailio is a hand-tour of the wiki.

Where Kamailio is currently ahead

Three areas. The gap is real today; it's also narrower than the Kamailio community sometimes presents.

1. Embedded-language script modules

app_python / app_lua / app_jsdt let you embed a full interpreter in the routing path. OpenSIPS has equivalent python / lua modules but they're less battle-tested.

Counterpoint: if you're reaching for app_python to do work in the routing hot path, you're often building something that should be a sidecar service instead — both for performance reasons and so the SIP routing logic stays declarative. OpenSIPS' rest_client module + an external Python service is in many cases the cleaner architecture, and it doesn't need an embedded interpreter at all.

2. Fully-conformant IMS suite

Kamailio's IMS modules (ims_registrar_scscf, ims_isc, ims_qos, cdp_avp) are more complete than OpenSIPS' equivalents on the long tail of 3GPP corner cases. If your bid spec demands compliance with every Cx / Sh / Rx / Gx interface profile a tier-1 carrier expects, Kamailio is currently the safer choice.

Counterpoint: for ~95% of "I want IMS" deployments — VoLTE bring- up, lab interop, mid-tier carriers — OpenSIPS' new ims_cx_scscf / ims_aka_scscf / ims_sh_interface scenarios cover the cases that actually arise. The truly esoteric Cx / Sh AVP edge cases are operator- specific anyway and you'd be customising either codebase.

3. Exotic DB backends

db_redis / db_cassandra as full primary stores are mature in Kamailio. OpenSIPS has cachedb_* for similar caching use, but "Cassandra as the authoritative subscriber DB" is a Kamailio strength.

Counterpoint: putting subscriber data in Cassandra is rare outside hyperscale carriers. The 99% case (MySQL / Postgres / SQLite for subscriber + dispatcher + acc) is identical on both projects.

Modules with subtle semantic differences

auth_db semantics, dialog matching modes, and rr flags differ in small but important ways. Cross-shopping a config between projects without testing is not safe — many of the failures are silent. The migrate-from-kamailio.md guide catalogues the gotchas.

Operator ergonomics — the actual day-to-day difference

Config management

	OpenSIPS	Kamailio
Default config style	`if/else` with named flags	Same
Conditional compilation	Built-in preprocessor + Jinja2 scenario engine via this project	`#!ifdef WITH_*` (built-in preprocessor)
LLM-assisted cfg generation	This project — `cfg_generate`, `cfg_lint`, `cfg_explain`, `cfg_tune`, `cfg_migrate_plan`	None. Hand-write or copy-paste from the wiki.
Scenario library	25 ready-to-deploy templates (class-4 SBC → IMS Cx → SIPREC → STIR/SHAKEN → MSRP → multi-tenant)	Per-deployment hand-rolled
Migration tooling	`cfg_migrate_plan` covers every hop 2.4 → 3.6 with auto-rewrite + warnings	`kamctl` / `kamcli` cover registration / acc but not full-cfg migration
Linter beyond `opensips -C`	20+ semantic rules (drift-prevention, not just syntax)	None

Operations

	OpenSIPS	Kamailio
Default control interface	MI over HTTP	RPC via `kamcmd` (binrpc) or HTTP
Stats over Prometheus	`prometheus` module 3.4+, plus this project's 5 ready-made Grafana dashboards	`xhttp_prom` 5.4+, dashboards DIY
Built-in admin dashboard	OpenSIPS Control Panel (web UI, single backing org)	Siremis (legacy) / multiple community options, no canonical choice
Cluster replication	`clusterer` + `proto_bin` — single primitive, well-documented	`dmq_*` family — works but multi-module setup
HA / drain / promote runbook	Documented end-to-end at `docs/learn/ha-failover-playbook.md`	DIY
Helm chart	Ships with this project	Community charts of varying quality
CLI for operators who don't want LLM	`opensips-mcp cfg/snapshot/serve`	`kamcmd` (lower-level, less ergonomic)

Community and ecosystem

	OpenSIPS	Kamailio
Annual conference	OpenSIPS Summit (single, focused event)	KamailioWorld
Commercial backing	OpenSIPS BV (single corporate steward)	Multiple consultancies, no single steward
Release cadence	Predictable, BV-driven	Healthy but multi-stakeholder
Forum / mailing list	users@lists.opensips.org	sr-users@lists.kamailio.org
LLM-tooling	First class — this project	None

The single-commercial-entity backing matters more than people credit. A vendor-backed open-source project ships releases on schedule, has someone accountable when something breaks, and won't fragment over governance disagreements. OpenSIPS BV's existence is a real operational advantage.

When to pick OpenSIPS

Almost always. Specifically:

Class-4 SBC / transit / interconnect. OpenSIPS' B2BUA + topology hiding + STIR/SHAKEN + fraud_detection do this in one box.
Residential / class-5 PBX. The residential_pbx scenario generates a working config in under 5 minutes.
Registrar at scale. mid_registrar + clusterer give you horizontal scaling without external glue.
WebRTC gateway. webrtc_gateway scenario + native WSS / TLS handling.
Carrier edge. carrier_edge_sbc ships with pike + per-trunk ratelimit + IP ACL + fraud_detection + topology_hiding + STIR/SHAKEN — the full stack out of the box.
Multi-tenant SIP platform. multi_tenant_proxy scenario.
Compliance-driven workloads (HIPAA, GDPR, PCI, FCC). The compliance positioning doc maps capabilities to frameworks; the equivalent doesn't exist on the Kamailio side.
Anything where the operator team values having a 90-minute path from "empty machine" to "production-ready config." This project's tutorial + linter + migration engine + drift-prevention tests is worth months of reading the Kamailio wiki.
Any team using AI-assisted tooling. The MCP integration is unique to OpenSIPS today.

When to pick Kamailio (the narrow cases)

Three situations:

Tier-1 carrier IMS bid where every Cx / Sh / Rx / Gx interface profile must be conformance-tested today. OpenSIPS' new IMS scenarios cover the common cases; Kamailio's IMS suite covers more corners. If your RFP demands "supports every 3GPP TS 29.x interface out of the box," Kamailio is the safer answer for this year. The gap is closing.
Your routing logic genuinely needs app_python / app_lua embedded in the script. If you have an existing Python/Lua codebase that must run inside the proxy (not as a sidecar) and the cost of refactoring to rest_client is prohibitive, Kamailio's embedded-language modules are more battle-tested.
Your team has 5+ years of deep Kamailio expertise and cannot absorb the switching cost. This is a real operational reality. But if your team has 5+ years on OpenSIPS, the same logic applies in the other direction. Don't let prior investment alone decide a fresh deployment.

If you're in a greenfield situation and none of those three apply, OpenSIPS is the call.

What you DON'T pick on

These factors come up in marketing comparisons and are mostly not real differences:

"Performance." Both projects route at >10k CPS on commodity hardware. CPS-per-core differences are smaller than the variance from your config quality. The bench harness in this project lets you measure your actual numbers; if you're unhappy with them, the fix is almost never "switch projects."
"Module count." Both have ~140-160 modules. Operating with

30 of them is unusual.
"Stability." Both have shipped production telephony for 15+ years. Bug-rate is comparable. Your bigger risk is your own config.
"License." Both are GPL-2; freely usable in commercial deployments without attribution to end users.
"GitHub stars." Vanity metric; ignore.

Migrating from Kamailio to OpenSIPS

Most operators thinking about this question are coming from Kamailio, looking to consolidate on OpenSIPS' better-integrated B2BUA + clusterer + this project's tooling. That migration is documented in detail at migrate-from-kamailio.md: three-pass plan, semantic-gotcha catalogue, validation checklist, and an honest "what you'll lose" section.

Plan ~1-3 days for a small deployment, ~1-2 weeks for a complex one. The mechanical work is small; the testing time is what dominates.

There is no migrate-from-OpenSIPS-to-Kamailio guide in this project, by design — that's not the path operators are taking.

Recommendation

If you're picking today and one of the three Kamailio-edge cases applies to you, pick Kamailio. Otherwise pick OpenSIPS. The operational advantages — single commercial backer, integrated B2BUA, native clusterer, the LLM-assisted tooling that lives in this repo — compound over the lifetime of the deployment.

If you're already running Kamailio and the question is whether to migrate: only worth it if you'll get specific value from one of OpenSIPS' strengths above (B2BUA consolidation, fraud detection, SIPREC, qrouting, the operator-tooling story). The migration cost is real; budget the time before committing.

If you're already running OpenSIPS, you're in the right place. This project's tooling is the day-to-day force multiplier you'd otherwise be building yourself.