As an open source sip client library, pjsip needs to connect to a server (well, P2P SIP is of course a possibility, especially using NAT Traversal, but that’s a topic for another day).
OpenSER is one such server. A quick unscientific trawl through pjsip mailing list archives reveals more than 80 mentions of OpenSER. We’ve used it ourselves for testing purposes.
For the last week or so I’ve been hearing that OpenSER has been “renamed Kamailio”, according to the news at Kamailio website. That seems to be true, because I can see most of the site, logo, footer is still saying openser.org. And the website openser.org will redirect you to kamailio.org.
So, goodbye OpenSER, welcome Kamailio.
All finished? Not quite.
Welcome also to OpenSIPS (Open SIP Server), which is a “a continuation of the OpenSER project”.
Confused? Don’t be. This sometimes happen in an open source project. The same OpenSER code is taken by both Kamailio and OpenSIPS and from now on will take a life of its own. This is called a ‘fork’. In fact both projects will start with release 1.4.0 (with OpenSIPS releasing today, and Kamailio planning for later this week).
For completeness, I will mention that OpenSER itself is based on SIP Express Router (SER) project.
Is this bad? Depends. If for example you have 100 contributors to OpenSER, and assume it is an even split between OpenSIPS and Kamailio, then you will have ‘only’ 50 contributors each. By simple math it would seem each project is for the worse, because less contributors means less feature implementation, less testing, less everything in general.
But look further then in software projects it is often not the raw numbers that matters. If the 100 contributors rarely agree on anything, then the project is stalled anyway. By forking, then maybe each new segment will be more energised, and will release better software.
What about users? It does leave them in a bewildered state for a while. At the initial release, both projects are almost literally the same. Over time each project should take its own trajectory and we can then evaluate each on their merits.
Where does this leave pjsip as a SIP client framework? Well, as long as all the SIP servers adhere to published RFCs, and have commitment to follow the standards (which they all do), we’re fine. We should be able to connect to SER, OpenSER Kamailio, OpenSIPS, and others that may or may not come after these products/projects.
At the end of day, each open source project, including pjsip itself, lives and die by its adoption.
What do you think? Will you use Kamailio or OpenSIP or none of them? Let us know in the comments.
(Credit: 
pjsip blog 