Which SIP server to choose: SER, OpenSER, Kamailio, OpenSIPS? What do they have in common and what is the difference?
For many voip network administrators who encounter sip-servers, the words ser, openser, kamailio, opensips cause at least dizziness. Why are there so many of them? Why so similar? Which are actively developing, and which are no longer? What in the end to choose?
Let's turn to history.
')
1995 year. Berlin, Germany. A group of former students of Professor Henning Schulzrinne, one of the authors of the SIP technology, is engaged in research in the field of VoIP in the framework of Fraunhofer Fokus, an independent research organization in the field of telecommunications at the University Fraunhofer. The working group led by Dorgham Sisalem publishes research papers describing the experimental implementation of SIP and recommendations for the first industrial developers of this technology.
1996 Henning Schulzrinne and Mark Handley are developing the final specification of the SIP protocol.
March 1999. The first standard is the sip protocol adopted and published in RFC2543.
year 2001. Andrei Pelinescu wrote the first lines of the SIP Express Router (SER). At that time, he implemented the routing function on the basis of the first found route in the table, which was soon replaced by the scripting language SER. The module support interface has also been added to enable quick addition of new functions. The results were presented on the specially created for this purpose site iptel.org
From 2001 to 2003, new people joined the project, at that moment students. The development of modules for the SER involved Alex Hoffmann, Bogdan-Andrei Iancu, Daniel-Constantin Mierla, Jan Janak. Raphael Coeffic, Uli Abend and Stephan Sayer are developing the SIP Express Media Server. Nils Ohlmeier is developing the SIP protocol SIPSak diagnostic utility. Karel Kozlik is developing a web interface.
September 2002. SER goes free, it is released under the GPL license.
June 14, 2005. Two central developers are separated from the project - Bogdan-Andrei Iancu and Daniel-Constantin Mierla. Together with Elena-Ramona Modroiu, they form a new project, OpenSER.
On July 28, 2008, the project was renamed Kamailio due to a trademark conflict.
August 24, 2008. As a result of a conflict between developers, Bogdan-Andrei Iancu is separated from Kamailio, which forms a new project - Opensips.
November 04, 2008. The Kamailio project merges with the original SER.
So, today, August 2012, we have two actively developing projects: Kamailio (or SIP router) and OpenSIPS.
First, let's compare some statistics:
I want to draw your attention to what does not mean better anymore. And from this table we can conclude that both projects are actively developing.
The next thing to compare is the modules. Some of them are the same, some are different. Modules with the same names often derive from the same modules of the early kamailio, but over so many years many functions may differ in parameters or names. The following data cannot claim objectivity, I just tried to superficially compare what is in one sip-server and what is not in the other.
* In opensips, in addition to the DB API, the CACHEDB API was added, which organizes work with nosql backends.
* kamailio does not support b2b, opensips has a topology hiding function built into the DIALOG module
Many functions are duplicated by different modules, but each server has its own unique features. Each of the servers to one degree or another may suit you more by some parameters.
What's next?
kamailio continues to develop the current sip server.
At the same time, opensips are working on version 2.0, which will be fundamentally different in architecture. According to the developers, the old design can not solve some problems. The new server is planned to be completely asynchronous, which will help eliminate, for example, an architectural flaw with locks when processing tcp connections.
The planned architecture consists of several successive levels.
The lowest level is the core. It is responsible for sip-functionality, which can be executed automatically, without configuration.
The next level is routing. It will be implemented functionality, close to that which is now used for routing in opensips.
And the last level is the application level. With it, you can perform operations at the highest level, using languages such as python.
This is what the interaction of applications with the kernel will look like.
The first alpha release of OpenSIPS 2.0 has already been released and I look forward to a full release, because The architecture proposed by the developers should help solve some pressing problems that neither kamailio nor opensips can solve today.
At the moment, I personally choose opensips, because In my opinion, developers have a more systematic approach to the organization of modules and the introduction of api in cases when it is necessary. And also because of the presence in opensips cachedb api, B2B and embedded STUN-server.
But again, this is just my personal opinion, it is subjective and, perhaps, another server will be more suitable for your tasks. In any case, I hope that this article will shed some light on the differences between the two servers for those who cannot or do not want to deal with it.
Let's turn to history.
')
1995 year. Berlin, Germany. A group of former students of Professor Henning Schulzrinne, one of the authors of the SIP technology, is engaged in research in the field of VoIP in the framework of Fraunhofer Fokus, an independent research organization in the field of telecommunications at the University Fraunhofer. The working group led by Dorgham Sisalem publishes research papers describing the experimental implementation of SIP and recommendations for the first industrial developers of this technology.
1996 Henning Schulzrinne and Mark Handley are developing the final specification of the SIP protocol.
March 1999. The first standard is the sip protocol adopted and published in RFC2543.
year 2001. Andrei Pelinescu wrote the first lines of the SIP Express Router (SER). At that time, he implemented the routing function on the basis of the first found route in the table, which was soon replaced by the scripting language SER. The module support interface has also been added to enable quick addition of new functions. The results were presented on the specially created for this purpose site iptel.org
From 2001 to 2003, new people joined the project, at that moment students. The development of modules for the SER involved Alex Hoffmann, Bogdan-Andrei Iancu, Daniel-Constantin Mierla, Jan Janak. Raphael Coeffic, Uli Abend and Stephan Sayer are developing the SIP Express Media Server. Nils Ohlmeier is developing the SIP protocol SIPSak diagnostic utility. Karel Kozlik is developing a web interface.
September 2002. SER goes free, it is released under the GPL license.
June 14, 2005. Two central developers are separated from the project - Bogdan-Andrei Iancu and Daniel-Constantin Mierla. Together with Elena-Ramona Modroiu, they form a new project, OpenSER.
On July 28, 2008, the project was renamed Kamailio due to a trademark conflict.
August 24, 2008. As a result of a conflict between developers, Bogdan-Andrei Iancu is separated from Kamailio, which forms a new project - Opensips.
November 04, 2008. The Kamailio project merges with the original SER.
So, today, August 2012, we have two actively developing projects: Kamailio (or SIP router) and OpenSIPS.
First, let's compare some statistics:
| Parameter | Kamailio | Opensips |
|---|---|---|
| The number of commits for 2011 | 802 | 593 |
| The number of commits for 2012 (up to and including August) | 1199 | 1015 |
| Latest (devel) version | 3.4 | 1.9 |
| The number of lines of c-code (without empty and comments) | 411940 | 228301 |
| Number of modules | 145 | 117 |
I want to draw your attention to what does not mean better anymore. And from this table we can conclude that both projects are actively developing.
The next thing to compare is the modules. Some of them are the same, some are different. Modules with the same names often derive from the same modules of the early kamailio, but over so many years many functions may differ in parameters or names. The following data cannot claim objectivity, I just tried to superficially compare what is in one sip-server and what is not in the other.
| Kamailio | are common | Opensips |
|---|---|---|
| Accounting and Authentication | ||
| Radius | ||
| ACC_RADIUS Accounting module for RADIUS backend AUTH_RADIUS RADIUS-backend authentication module MISC_RADIUS Generic RADIUS functions, replaces avp_radius, uri_radius and group_radius | - | AAA_RADIUS RADIUS backend for the AAA API AUTH_AAA AAA-backend authentication module |
| Diameter | ||
| CDP C Diameter Peer - core communication engine CDP_AVP C Diameter Peer - application extensions | AUTH_DIAMETER DIAMETER-backend authentication module | - |
| Support for scripts in other languages | ||
|---|---|---|
| Kamailio | are common | Opensips |
| APP_LUA Execute embedded Lua scripts APP_MONO Execute embedded managed code - C #, VisualBasic.NET, Java, Java Script APP_PYTHON Execute embedded Python scripts | PERL embed execution of perl function | CPL-C CPL interpreter module Lua Call LUA scripts from OpenSIPS cfg PYTHON Python scripting support |
| Databases including nosql | ||
|---|---|---|
| Kamailio | are common | Opensips |
| DB_CASSANDRA Cassandra database server connector DB_CLUSTER Generic database connectors clustering DB_SQLITE SQLITE-backend for database API module HTABLE Generich Hash Table Container in shared memory MATRIX Matrix operations MEMCACHED Memcached connector module NDB_REDIS Connector to REDIS NoSQL Database Engine | DB_BERKELEY Berkeley DB driver for DB API DB_FLATSTORE Fast writing text backend for database module DB_MYSQL MYSQL-backend for database API module DB_ORACLE ORACLE-backend for database API module DB_POSTGRES POSTGRES-backend for database API module DB_TEXT Text-backend for database API module DB_UNIXODBC unixODBC driver module Ldap LDAP connector PERLVDB Perl Virtual Database Engine | CACHEDB_CASSANDRA Cassandra Implementation of CacheDB CACHEDB_LOCAL Local Implementation of CacheDB CACHEDB_MEMCACHED Memcached Implementation of CacheDB CACHEDB_REDIS Redis Implementation of CacheDB DB_HTTP HTTP backend for DB API DB_VIRTUAL Middle-layer DB mixer |
| Blacklist support | ||
|---|---|---|
| Kamailio | are common | |
| Blst Blacklisting API for config | USERBLACKLIST User black / white listing | |
| Management interface mechanisms | ||
|---|---|---|
| Kamailio | are common | Opensips |
| MI_RPC RPC support for Management Interface | MI_DATAGRAM DATAGRAM (unix and network) support for Management Interface MI_FIFO FIFO support for Management Interface MI_XMLRPC XMLRPC support for Management Interface | MI_HTTP - HTTP support for Management Interface |
| PRESENCE mechanism | ||
|---|---|---|
| Kamailio | are common | Opensips |
| PRESENCE_CONFERENCE Extension for Presence server for conference events handling PRESENCE_PROFILE Presence server module - user profile extensions - RFC6080 PRESENCE_REGINFO Extension for Presence server for registration info replication (RFC3680) PUA_REGINFO Extension for PUA server for registration info replication (RFC3680) | PRESENCE Presence server module - common API PRESENCE_DIALOGINFO Extension to Presence server for Dialog Info PRESENCE_MWI Extension for Presence server for Message Waiting Indication PRESENCE_XML Presence server module - presence & watcher info and XCAP PUA Common API for presence user agent client PUA_BLA BLA extension for PUA PUA_DIALOGINFO Dialog-Info extension for PUA PUA_MI MI extension for PUA PUA_USRLOC USRLOC extension for PUA PUA_XMPP XMPP extension for PUA (SIMPLE-XMPP presence gateway) | PRESENCE_CALLINFO Extension to Presence server for Call-Info PRESENCE_XCAPDIFF Extension for Presence server for XCAP-DIFF event |
| XCAP support | ||
|---|---|---|
| Kamailio | are common | |
| XCAP_SERVER XCAP server implementation | XCAP_CLIENT XCAP client implementation | |
| TLS functions | ||
|---|---|---|
| Kamailio | Opensips | |
| Tls TLS operations module | TLSOPS TLS operations module | |
| Hiding topology, B2B support | ||
|---|---|---|
| Kamailio | Opensips | |
| TOPOH Topology hiding module | B2B_ENTITIES Back-to-Back User Agent Entities B2B_LOGIC Back-to-Back User Agent Logic MANGLER SIP mangler module | |
| RPC support | ||
|---|---|---|
| Kamailio | ||
| CTL Control connector for RPC interface (fifo, unixsock, tcp, udp) JSONRPC-C JSON-RPC client over netstrings protocol MI_RPC RPC support for Management Interface XHTTP Basic HTTP request handling server XHTTP_RPC RPC commands handling over HTTP XMLRPC XMLRPC connector for RPC interface | ||
| Call routing, LCR, balancing | ||
|---|---|---|
| Kamailio | are common | Opensips |
| LCR Least Cost Routing module PREFIX_ROUTE Execute config file route blocks based on prefix | CARRIERROUTE routing extension suitable for carriers CALL_CONTROL PrePaid application module DIALPLAN Dialplan management DISPATCHER Dispatcher module DROUTING Dynamic Routing / LCR PDT Prefix-to-Domain translator module | CLOSEDDIAL PBX-like dialing features LOAD_BALANCER Load Balancer (for calls) module |
| Various unique features | ||
|---|---|---|
| Kamailio | Opensips | |
| ASYNC Asynchronous SIP request handling functions DEBUGGER Interactive config debugger DMQ Distributed Message Queue System using SIP IPTRTPPROXY NAT traversal module using kernel for media relay MQUEUE Message queue system for config file MTREE Generic memory caching system using tree indexes PDB Number portability module P_USRLOC Partitioned and distributed user location services PIPELIMIT Traffic shaping policies PURPLE Multi-protocol gateway using Purple library RTIMER Execute config route blocks on timer basis TMREC Match based on RFC2445 XMLOPS XML operations in config file using XPATH | DNS_CACHE Key-Value Module for DNS back-end EVENT_DATAGRAM Event datagram module EVENT_RABBITMQ Event RabbitMQ client module Httpd Embedded HTTP server IDENTITY SIP Identity implementation OPTIONS OPTIONS server replier module SIGNALING SIP signaling module STUN Built-in STUN server UAC_AUTH UAC Authentication functionality UAC_REGISTRANT SIP Registrant implementation module | |
| Modules that duplicate the functionality of a competitor or have functions included in the kernel | ||
|---|---|---|
| Kamailio | Opensips | |
| COUNTERS Internal counter API for config Ipops IP and DNS related operations for configuration file KEX Kamailio core extensions module PV Module holding Pseudo-Variables SANITY SIP message formatting sanity checks SDPOPS SDP operations SIPUTILS SIP utilities SQLOPS SQL operations TEXTOPSX Extra text operations Tmx Transaction management extenstions module URI_DB URI operation with database support module Utils A set of useful functions | GFLAGS Global shared flags module SIPMSGOPS SIP operations module URI Generic URI operation module XLOG Advanced logger module | |
| Common modules (first of all in name, may vary greatly in function) |
|---|
| ALIAS_DB Database SIP aliases module AVPOPS AVP operation module BENCHMARK Config file benchmarking CFGUTILS Different config utilities DIALOG Dialog support module Diverion Diversion header insertion module DOMAIN Multi-domain support module DOMAINPOLICY Policies to connect federations Enum ENUM lookup module EXEC External exec module GROUP User-groups module with DB-backend H350 H350 implementation IMC Instant Messaging Conferencing module Jabber JABBER IM and PRESENCE interconnection module Json JSON packing function MAXFWD Max-Forward processor module MEDIAPROXY NAT traversal module MSILO SIP message silo module NATHELPER NAT traversal helper module NAT_TRAVERSAL NAT traversal module Osp Osp peering module PATH Path support for SIP frontending PEERING Radius peering module PERMISSIONS Permissions control module PIKE Flood detector module QOS QOS (RTP) module RATELIMIT SIP traffic shaping module REGEX RegExp via PCRE library REGISTRAR SIP Registrar implementation module Rls Resource List Server implementation RR Record-Route and Route module RTPPROXY NAT traversal using RTPProxy module SEAS Sip Express Application Server (interface module) SIPCAPTURE SipCapture module SIPTRACE SipTrace module SL Stateless replier module SMS SIP-to-SMS IM gateway module SNMPStats SNMP interface for statistics module SPEEDDIAL Per-user speed-dial controller module Sst SIP Session Timer support Statistics Script statistics support TEXTOPS Text operations module Tm Transaction (stateful) module UAC UAC functionalies (FROM mangling and UAC auth) UAC_REDIRECT UAC redirection functionality USRLOC User location implementation module XMPP SIP-to-XMPP Gateway (SIP to Jabber / Google Talk) |
Many functions are duplicated by different modules, but each server has its own unique features. Each of the servers to one degree or another may suit you more by some parameters.
What's next?
kamailio continues to develop the current sip server.
At the same time, opensips are working on version 2.0, which will be fundamentally different in architecture. According to the developers, the old design can not solve some problems. The new server is planned to be completely asynchronous, which will help eliminate, for example, an architectural flaw with locks when processing tcp connections.
The planned architecture consists of several successive levels.
The lowest level is the core. It is responsible for sip-functionality, which can be executed automatically, without configuration.
The next level is routing. It will be implemented functionality, close to that which is now used for routing in opensips.
And the last level is the application level. With it, you can perform operations at the highest level, using languages such as python.
This is what the interaction of applications with the kernel will look like.
The first alpha release of OpenSIPS 2.0 has already been released and I look forward to a full release, because The architecture proposed by the developers should help solve some pressing problems that neither kamailio nor opensips can solve today.
At the moment, I personally choose opensips, because In my opinion, developers have a more systematic approach to the organization of modules and the introduction of api in cases when it is necessary. And also because of the presence in opensips cachedb api, B2B and embedded STUN-server.
But again, this is just my personal opinion, it is subjective and, perhaps, another server will be more suitable for your tasks. In any case, I hope that this article will shed some light on the differences between the two servers for those who cannot or do not want to deal with it.
Source: https://habr.com/ru/post/150280/
All Articles