Kamailio: the SIP server you configure, not the one you click

What Kamailio actually is, and who ends up running it

Kamailio is an open source implementation of a SIP signaling server. SIP is the IETF protocol specified in RFC3261, and Kamailio handles the signaling: registration, routing, authentication and the proxying of requests between endpoints. It does not carry the media itself. That distinction matters more than any feature list, because it tells you where Kamailio sits in a deployment and what it is not responsible for.

The README is explicit about the target audience: the server is designed for scalability and targets large deployments, such as IP telephony operators or carriers with a large subscriber base or a big volume of calls. It also states the same build can serve enterprises or personal needs for VoIP, instant messaging and presence. So the project does not exclude small users, but the design decisions were made for the large ones.

The history is worth knowing because it explains the community shape. Development started in 2001 at Fraunhofer Fokus in Berlin under the name SIP Express Router, or SER. A fork called OpenSER appeared in 2005 and was renamed Kamailio in July 2008 over trademark issues. From autumn 2008 the two projects moved toward a merge, and Kamailio became the main name. Fraunhofer Fokus is no longer involved in the project's evolution; Kamailio is developed and managed by its worldwide community, though Fokus still uses it in research projects and hosts related events.

If you are choosing a SIP server for a small office PBX with a web admin panel, this is the wrong shape of tool. If you are terminating or routing signaling for thousands of subscribers and you want to write the routing logic yourself, it is the right one.

How Kamailio works: a C core plus modules you opt into

Kamailio is written in C, and the repository is organised so that the core lives in src/ while optional functionality is split into modules. The top-level tree contains src/, plus doc/, etc/, misc/, pkg/, test/ and utils/, along with build entry points such as Makefile and CMakeLists.txt. The root Makefile is a thin forwarder: it defines KSR_DIR as src/ and passes nearly every target down with a recursive make call into that directory. In other words, the root file exists for convenience, and the real build logic is under src/.

That layout is the mechanism behind the project's flexibility. You start from a core that understands SIP and add modules for the behaviour you need. The README points to the stable-branch module documentation as the reference, and notes that each module has its own README file in the source tree. That is where parameters and functions are documented, module by module.

The practical consequence is that a Kamailio deployment is defined as much by what you leave out as by what you include. A server acting as a SIP proxy for a straightforward routing case loads far fewer modules than one doing IMS work or acting as a session border controller. Because the configuration file drives which modules load and how requests are handled, the config is effectively the application. This is the central trade-off of the project: you get precise control over signaling behaviour, and in exchange you take on the job of writing and maintaining that control.

Installing Kamailio and getting a first config running

The README does not walk through installation itself. It points to step-by-step tutorials for installing from source at the project's wikidocs installation index, and it says to read the INSTALL file in the source code for more information. It also lists repositories for Linux packages, one page for deb packages and one for rpm packages. Those are the two supported paths: distro packages, or a source build.

If you build from a clone, the root Makefile forwards to src/. A typical sequence looks like this:

make cfg
make all
sudo make install

The first command prepares the build configuration, the second compiles the core and the default module set, and the third installs the result. The root Makefile's install target simply calls make -C src/ install. Note that the README warns about one legacy condition: if an old modules directory is present at the top level, the Makefile prints a warning telling you to clean it, because modules now live under src/ and the build strips that prefix when forwarding the modules parameter.

After installation, the server reads its configuration, conventionally kamailio.cfg. The README does not reproduce a minimal config, so the honest starting point is the documentation index and the per-module README files rather than a copied snippet. What you should expect to see when the server starts is a running SIP listener that accepts requests on the transport you configured. Verifying that means sending a SIP request at it and reading the log, not clicking through a UI, because there is no UI in the README.

For containers, the related searches include kamailio docker, but the README does not document an official image or a Dockerfile path. Treat container usage as something to confirm against the wiki before you build a deployment process around it.

Where Kamailio is the wrong tool

The clearest limitation is operational, not technical. Kamailio's power comes from a configuration file that behaves like a program. If your team cannot read a SIP trace and reason about request routing, that config becomes a liability: a subtle change can alter how calls are routed for a subset of subscribers, and nothing in the README suggests a safety net beyond the documentation and the mailing lists.

Second, the README describes Kamailio as a SIP signaling server. Media handling is not part of that description. Teams that expect one process to do signaling and media should look at what the project actually claims before assuming coverage, and should check the module documentation for what each component does.

Third, the support model is community-based. The README lists mailing lists for stable-version discussions (sr-users), development and master-branch state (sr-dev), and commercial purposes (business), plus a Matrix channel. There is no vendor SLA attached to the project itself. Organisations that need a contract with a named party have to source that separately; the README only points at the lists.

Finally, documentation is distributed. The main index, the stable-branch module docs, the wiki, and one README per module in the source tree. There is no single page that describes every module parameter. For a small team, that is a real cost of ownership, and it is the main reason a simpler SIP server can be the better choice even when Kamailio would scale further.

Kamailio vs Asterisk and OpenSIPS: different jobs, different code

The most common comparison people search for is Kamailio against Asterisk. The distinction that matters is architectural. Kamailio is a SIP signaling server: it registers users, routes requests and proxies signaling, and the README does not present it as a media or application server. Asterisk sits in a different category, as a PBX and media application platform. Choosing between them is less about performance and more about whether you are building a routing layer or an application endpoint. Many real deployments use both, with Kamailio in front.

OpenSIPS is the closer comparison, and the shared history explains why. Kamailio and OpenSIPS both descend from the same lineage described in the README: SIP Express Router, then the OpenSER fork, then the rename to Kamailio in 2008 and the subsequent merge effort. The two projects diverged after that, and today they are separate codebases with separate module sets and separate communities. The practical difference for an evaluator is not a single feature; it is which module ecosystem and which configuration dialect your team already knows, and which project's documentation answers your questions. Because both are configured through a script-like file and both are C servers, the migration cost between them is mostly in module names and config syntax, not in the deployment shape.

A third alternative is simply a hosted SIP provider or a managed SBC. If your requirement is a working phone system rather than control over signaling, buying the service removes the entire configuration-ownership problem that Kamailio deliberately creates.

Licence, releases and the cost of staying current

The main licence is GPLv2, and the README is careful about the details. Each source file states its own licence and copyright at the top. Most of the code is GPLv2, and some parts are BSD. That mixed picture is why the repository's licence field is not a single clean identifier; the authoritative statement is per file, not per repository.

For new contributions there are specific rules. Contributions to the core and to several main modules (auth, corex, sl, tls, tm) must be under the BSD licence. New contributions under the GPL must grant the GPL-OpenSSL linking exception. Contributions to components already released under BSD must also be under BSD. If you plan to modify and redistribute Kamailio, or to link it with other code, those rules determine what you can do. This is a factual constraint, not legal advice; the file headers and the project's licensing rules are the source to read.

On releases, the recent tags show two maintained lines running in parallel: 6.0.8 on 2026-09-16, 6.1.4 on 2026-08-20, and 6.0.7 on 2026-06-19. The last push to the repository was on 2026-09-23. Two active branches means an upgrade decision: stay on 6.0.x for patch-level fixes, or move to 6.1.x and absorb whatever changed between the lines. Because routing logic lives in your config and modules, an upgrade is not a drop-in binary swap. You should expect to read the module documentation for the modules you load and check whether parameters or functions you rely on changed. The cost of staying current is therefore proportional to how much of the module surface you use. A minimal proxy config is cheap to upgrade; a deployment loading dozens of modules is not.

Editorial conclusion

Adopt Kamailio if your team already reads SIP traces and is willing to own a kamailio.cfg that behaves like code. Do not adopt it if you expect a web console to configure dial plans; the README lists no such interface, and the project's own documentation index points to wikidocs and per-module README files instead. Before committing, verify three things: which modules your routing logic needs, how you will build or install Kamailio on your target distribution, and whether your licence obligations fit GPLv2 for the core you plan to deploy.

Frequently asked questions

Official sources

1. Issues
2. kamailio/kamailio on GitHub
3. Project website
4. README
5. Releases