Kamailio v3.2.2 Released

Kamailio SIP Server v3.2.2 stable is out – a minor release including fixes in code and documentation since v3.2.2 – configuration file and database compatibility is preserved.
Kamailio (former OpenSER) 3.2.2 is based on the latest version of GIT branch 3.2, therefore those running previous 3.2.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v3.2.x.
Resources for Kamailio version 3.2.2
Source tarballs are available at:

• http://www.kamailio.org/pub/kamailio/3.2.2/src/

Detailed changelog:

• http://www.kamailio.org/pub/kamailio/3.2.2/ChangeLog

Download via GIT:

# git clone –depth 1 git://git.sip-router.org/sip-router kamailio
 # cd kamailio
 # git checkout -b 3.2 origin/3.2
 # make FLAVOUR=kamailio cfg

Binaries and packages will be uploaded at:

• http://www.kamailio.org/pub/kamailio/3.2.2/

Modules’ documentation:

• http://www.kamailio.org/docs/modules/3.2.x/

What is new in 3.2.x release series is summarized in the announcement of v3.2.0:

• http://www.kamailio.org/w/kamailio-openser-v3-2-0-release-notes/

Presentations at Fosdem 2012

Fosdem 2012 includes again a dev room for Open Source Telephony, Kamailio SIP Server Project having a dedicated presentation “Secure SIP Communication with Kamailio”, by me (Daniel-Constantin Mierla).

Andreas Granig, also a developer of the project, will present another talk about SIP:Provider solution, which has Kamailio as the core components for SIP routing.

Related to our eco-system, Stefan Sayer will talk about SIP Express Media Server and its SBC functionality.

The schedule for telephony dev room is available at:

• http://fosdem.org/2012/schedule/track/telephony_and_communications_devroom

Kamailio & friends dinner at Fosdem 2012

Fosdem 2012 is approaching and we are going to have our traditional dinner at the event on the evening of Saturday, February 4.

At this moment should be over 15 participants, many Kamailio developers and community members, among them:

• Henning Westerholt
• Andreas Granig
• Daniel-Constantin Mierla
• Stefan Sayer
• Olivier Taylor
• Peter Dunkley
• Raphael Coeffic

If you want to join us, send an email to registration@lists.sip-router.org. Register as early as possible, since we need to make a reservation, also the place cannot accommodate too many people. All friends of Kamailio, SER, SEMS, Asterisk, FreeSWITCH and SIP/VoIP are welcome!

New Module – Cassandra DB Connector

Courtesy of Anca Vamanu, of 1 & 1 Internet AG, Germany, a new module is available in the development version of Kamailio SIP Server (to become the 3.3.0 release). Here is an adapted excerpt done for this web news from the announcement sent to mailing list.

“The module is named db_cassandra and offers a DB interface that can be used by other modules to perform DB operations instead of other DB modules (like db_mysql for example).
Because Cassandra is a NoSQL storage system, it is not possible to run all kind of SQL-like queries on it and this is the reason why the module has some limitations.

It is especially suited for applications that store large data or that require data distribution, redundancy or replication. One usage example is a distributed location system in a platform that has a cluster of SIP servers, with more proxies and registration servers accessing the same location database.

This was actually the main usage we had in mind when implementing the module. It has been tested with usrloc and auth_db modules, but it can also be used with other modules that have similar queries.
You can read more about this module in the README file:

• http://kamailio.org/docs/modules/devel/modules/db_cassandra.html

Inside the module directory you can find an example that modifies the default configuration file to enable a location service with a Cassandra backend. If you have a Cassandra installation, it should be very easy to test it.

We hope you find this module useful and are glad to receive any feedback, comments about it.”

New module – embedded MSRP relay

A new module in development branch of Kamailio SIP Server, named msrp, provides a MSRP routing engine, a.k.a. MSRP relay. The core specification of MSRP (Message Session Relay Protocol) is defined by RFC4975, the extensions for a MSRP Relay being covered in RFC4976. One of typical use case for MSRP is to do Instant Messaging sessions negotiated with SIP via INVITE-200OK-ACK.

The msrp is controlled from configuration file via actions in event_route[msrp:frame-in]. The module is a full, embedded MSRP relay, it does not require any external application nor library. It uses the core transport layer components, thus it benefits of the scalable and asynchronous TCP/TLS support implementation already existing in the project for many years now.

Kamailio, with msrp module loaded, can handle SIP and MSRP traffic received on the same port. But you can configure Kamailio as a stand alone instance to deal only with MSRP traffic, leaving the SIP traffic to another Kamailio instance. Also, another option is to configure Kamailio to listen on different TCP/TLS sockets (e.g., different ports or IP/network interfaces) and direct SIP and MSRP to different ports — then in the config file you can take care of filtering (dropping) inappropriate content on specific ports. With all this flexibility, you can choose a configuration that will not affect at all the routing of SIP messages with Kamailio.

The embedded MSRP relay, built on top of the SIP server, offers many benefits such as:

• reuse mature code tested over the past 10 years, msrp module itself being really small piece of code in regards to MSRP protocol
• MSRP is done over TCP/TLS, thus implicitly the forwarding is done asynchronously, offering great performances
• IPv4 and IPv6 support
• MSRP is for transmission of a SIP session content, going to be used by the SIP users in your UC platform — there is no need to manage a different user profile
• the configuration and MSRP routing is done via the same flexible language and format as for SIP traffic, you being in control of what is passing through your server
• access to all existing extensions that are related to SIP request routing, for example: IP address checking, flood detection, many database connectors, accounting, a.s.o.

You can read more about the msrp module in the documentation file:

• http://kamailio.org/docs/modules/devel/modules/msrp.html

At this moment, Kamailio offers a set of extensions that allows building a complete Unified Communication platform, within a single SIP server instance for small deployments as well as a grid of servers, each one doing particular functions:

• voice, video, screen sharing, etc. sessions with content communication via RTP
• end to end presence – this is purely SIP routing
• SIMPLE-based presence (aka, presence server or presence agent model) via presence* and pua* modules — user presence, dialog states notification (aka, blinking lamps), resource lists service (including OMA/RCS extensions), user location states notification and replication, audio/video conference mixer notifications, a.s.o.
• embedded XCAP server – management of user contact lists, presence policies, user agent configuration files, a.s.o. There is also an XCAP client extension
• embedded HTTP server – for admin and user interaction with the service via pure HTTP or XMLRPC requests
• embedded MSRP relay – for relaying and fine controlling of the message-based content of SIP sessions
• IRC-style instant messaging conference via imc module
• storage of instant messages for offline users and relay to them when they become again online via msilo module

All above components are built on the same solid foundation, practically is Kamailio core plus a selected set of modules, no extra dependencies, just configuration options.

Per socket number of worker processes

The development branch of Kamailio SIP Server has a new feature that allow setting number of worker processes to handle received traffic per listen socket.

So far there were global parameters that were applied to all sockets (e.g., ‘children’ value set the number of workers for all udp sockets). So far each UDP and SCTP socket had its own pool of workers (e.g., children=4 and 2 udp sockets resulted in 8 processes), while for TCP and TLS was a single pool of workers (e.g., having children (or tcp_children) set 8, resulted in 8 processes no matter how many TCP/TLS sockets).

The new features is based on using a new config parameter, named “socket_workers“, before a “listen” parameter. The value of “socket_workers” will overwrite the value of appropriate “*children” parameter. For UDP and SCTP will result in creating a number of “socket_workers” processes. For TCP and TLS will add an extra set of “socket_workers” processes, that will handle traffic only on those specific sockets.

The value of “socket_workers” is reset with the next listen socket added. If “socket_workers” is not set, the value of “*children” parameter is used in backward compatible fashion.
Some typical scenarios where this feature may become handy:

• set a lower number for loopback or internal/replication sockets, as the traffic there is low (e.g, maybe for keepalive monitoring on loopback, or it is only REGISTER requests replication done over the replication sockets)
• set a dedicated group of tcp/tls workers for handling HTTP/XMLRPC/XCAP traffic – handling such traffic may be time consuming, in this way you avoid delays on routing SIP over TCP/TLS
• fine tune the number of over all forked processes by a SIP server instance, thus controlling better the resources used from the physical server (e.g., overall private memory used by sip server is a matter of how many forked processes are there)

You can see details about the new parameter and examples on the wiki page:

• http://www.kamailio.org/wiki/cookbooks/devel/core?&#socket_workers

Fancy time recurrence matching in config

A new module for Kamailio SIP Server named for now tmrec allow matching of time recurrences based on definitions specified by Internet Calendaring and Scheduling Core Object Specification (Calendar COS – RFC 2445).

It becomes trivial to match current time against rules such as working hours, weekend, up to complex conditions such as the interval from 18:00 to 20:00 of the 98th day of every other year if it is a Thursday.

Here is an example of how to match the working hours 8:30am to 6:30pm on business days:

 if(tmrec_match("20120101T083000|10H|weekly|||MO,TU,WE,TH,FR")
  xdbg("it is within working hours\n");

The rule can be specified via a config variable (e.g., load from user profile stored in database via sqlops). A typical use case is time based routing policies.

You can read more about the new extension in the documentation:

• http://kamailio.org/docs/modules/devel/modules/tmrec.html

New Year, New Extension – Embedded execution of managed code (C#)

The first committed module for Kamailio SIP Server in 2012 is app_mono, which offers embedded execution of manage code (e.g., C#/.NET) via Mono project (http://www.mono-project.com/).
The readme of the new module is available at:

• http://kamailio.org/docs/modules/devel/modules/app_mono.html

Current API which exported by SIP server for usage in C# application is documented at:

• http://www.kamailio.org/wiki/embeddedapi/devel/mono

Besides C#, app_mono should be able to run managed code compiled from applications written in other languages such as VisualBasic.NET, Java, Java Script, Python, … more are listed at:

• http://www.mono-project.com/Languages

A primary use is integration with several widely used Microsoft technologies and APIs, for example C# having up-to-date libraries to connect to Active Directory LDAP service or MS SQL Server.

Happy 2012!

Same type of activity for me in the past 10 years and still enjoying it! Looking forward to the 11th!

Watch Kamailio SIP Server project news, lot of cools stuff is coming out!

Have a great 2012 friends!