OpenSIPS vs Kamailio: Which SIP Proxy Should You Deploy?

Choosing between OpenSIPS and Kamailio is one of the first decisions you make when building SIP infrastructure from scratch — and it shapes everything downstream. Both are open-source SIP proxies descended from the same SER (SIP Express Router) codebase. Both handle millions of calls per day in production. But they have diverged meaningfully in architecture, scripting model, and operational tooling. This post gives you the technical differentiators to make the call without guessing.

Origins and Architecture

OpenSIPS and Kamailio forked from SER around 2008. Since then they've accumulated different design philosophies:

• Kamailio stays closer to the SER roots: a monolithic process with a rich C module API and a mature pseudo-scripting language (kamailio.cfg). It prioritizes raw routing performance and has a well-understood memory model.
• OpenSIPS introduced a multi-process worker architecture early on and has invested heavily in its scripting language (OpenSIPS Script), a management interface (MI), and higher-level abstractions like B2BUA and dialog management.

Both compile to native binaries. Neither runs in a VM or interpreter at call time. In raw SIP routing benchmarks on identical hardware, the performance difference is under 5% — irrelevant at any realistic scale below 10,000 calls per second.

Scripting Model

This is where the two platforms diverge most visibly.

Kamailio Configuration (kamailio.cfg)

Kamailio uses a C-like block structure with global parameters, module loading, and routing blocks. Routing logic lives in named route blocks called sequentially.

request_route {
    if (is_method("REGISTER")) {
        route(REGISTRAR);
        exit;
    }
    if (!mf_process_maxfwd_header(10)) {
        sl_send_reply("483", "Too Many Hops");
        exit;
    }
    route(DISPATCH);
}

route[DISPATCH] {
    if (!ds_select_dst(1, 4)) {
        send_reply("503", "No Destination");
        exit;
    }
    t_relay();
}

Kamailio's scripting feels low-level but is extremely predictable. Every variable, AVP, and pseudo-variable has documented lifetime semantics.

OpenSIPS Script

OpenSIPS Script is closer to a proper language: it supports switch, while, and local variable scoping. The xlog and pv modules give string interpolation that Kamailio handles through pseudo-variables.

route {
    if (is_method("REGISTER")) {
        do_registration();
        exit;
    }

    $var(tries) = 0;
    while ($var(tries) < 3) {
        if (ds_select_dst(1, 4)) {
            t_relay();
            exit;
        }
        $var(tries) = $var(tries) + 1;
    }
    send_reply(503, "No route available");
}

For complex routing logic with loops and conditionals, OpenSIPS Script is more readable. For teams already fluent in C or shell scripting, Kamailio's model is immediately familiar.

Module Ecosystem Comparison

Kamailio's app_python3 module is a significant differentiator if your team writes Python. It lets you call arbitrary Python code inside routing blocks, which is useful for integrating with internal APIs, databases, or ML-based fraud detection without writing C modules.

OpenSIPS's callcenter module provides ACD (automatic call distribution) queuing logic in pure OpenSIPS Script — Kamailio has no equivalent and you'd build it in Lua or an external application server.

Management and Operations

Kamailio exposes control via kamctl (CLI) and kamcmd (socket-based FIFO). The XMLRPC and JSONRPC modules enable HTTP-based management. Kamailio's state is not centralized — each process reads shared memory, which means cluster-wide state changes require sending commands to each node.

OpenSIPS ships with a built-in HTTP management interface (mi_http) and the standalone opensips-cli tool that talks to the MI layer. The clusterer module provides native cluster state replication: push a dispatcher list update to one node and it propagates automatically. For large clusters, this difference is operationally significant.

Both support hot-reloading of routing configuration via kamcmd cfg.reload and opensips-cli mi reload_routes respectively — no restart required for routing changes.

Performance at Scale

Synthetic benchmarks (SIPp, 10,000 INVITE/sec, no media, 4-core VM):

These numbers compress at high concurrency because OpenSIPS's worker isolation reduces lock contention. Above 30,000 concurrent calls, OpenSIPS's multi-process model can outperform Kamailio's shared-memory approach on NUMA hardware.

When to Choose Kamailio

• Your team writes Python or Lua and wants scripting inside routing logic.
• You need a well-documented, battle-tested SIP registrar and proxy with minimal operational complexity.
• You're running a stateless SIP proxy at very high throughput (carrier peering, SBC front-end).
• You want deep Asterisk or FreeSWITCH integration via tm and uac modules.

When to Choose OpenSIPS

• You need built-in ACD call queuing without an external application server.
• You're building a multi-node cluster and want native state replication via clusterer.
• Your routing logic has complex branching that benefits from proper loop and scoping constructs.
• You want a first-class HTTP management API without bolting on additional modules.

The Honest Answer

For pure SIP proxy and load balancing, either works. The decision usually comes down to your team's scripting comfort and which module covers your specific use case out of the box. Run both in a lab against your actual traffic pattern for 48 hours before committing. The benchmark that matters is your workload, not SIPp.

If you're building a carrier-grade platform and need to pick one: Kamailio for stateless high-throughput routing, OpenSIPS for complex stateful call flows with cluster replication.