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!

Siremis v3.2.0 Released

Siremis v3.2.0 is out – the web management interface for Kamailio SIP Server (former Openser) and SIP Express Router (SER). This is a major release, compatible with Kamailio v3.2.x.
This release brings a large set of new features. Among them:

• SQL-based CDR rating engine for billing purposes
• stored procedure to compute the costs of calls
• Management of billing rates
• longest prefix rate selections
• rating rules can be grouped to allow many sets of values
• time unit is configurable per rating rule
• Management of remote registration records (uacreg table)
• Managment of mtree module (mtree and mtrees tables)
• Management of dialog variables table
• Update of LCR and SIP Trace views for compatibility with Kamailio 3.2.x
• Tools to generate new database table views in a wizard fashion
• create new views to database table with a command line tool in 5 steps
• Charts drawing statistics of accounting records
• graphics to show the evolution of accounting records during the past hours
• graphics to show the types of INVITEs (call setup) during the past hours
• Tables presenting summary of accounting records
• count the number of INVITEs and BYEs in the past hours
• present the top activity of accounting records – e.g., top 5 caller and callee
• more can be added from configuration file
• More SIP server activity charts (e.g., SIP requests traffic load)
• e.g., default chart presents how many requests are received in intervals of 10 minutes
• Buttons to switch to command pannel to reload Dispatcher or PDT records in SIP server cache
• once new records are added, in two clicks they get in the cache of SIP server
• Views for managing global black lists table
• Many improvements to user interface
• selection of local domain is done via select box or picker form (e.g., in aliases, user preferences, pdt, …)
• selection of local username is done via picker form (e.g., user black lists, user preferences, aliases, …)
• group names can be set in config file and selected from a list box
• many static values are given as option to select from a list box (e.g., dispatcher flags, lcr options)
• More targets in Makefile to make administration easier

Step by step installation tutorial, screenshots and demo are available on the web at:

• Installation Tutorial
• Screenshots
• Web Demo for Siremis 2.0 - v3.2.0 is built on same core framework, just new features were added (thus more options in the menu)

Siremis is used during Kamailio Advanced Training classes for management of SIP server, a good oportunity to learn about Siremis itself, check for next locations at:

• Kamailio Advanced Training Presentation Page

Migrating project from BerliOS to GitHub

BerliOS, the open source software forge, announced ending of its life by Dec 31, 2011. Although some time later, there was another announcement that the service will continue, to be operated by a non-profit foundation, I thought anyhow of copying two projects I had there to GitHub.

The two small projects I wrote long time ago, while being a researcher at Franhofer Fokus, were not really maintained, but anyhow it would be a pity to lose the code, parts of it may be useful in the future. If anyone wanders, here is short the description of these projects:

• pocketsipmsg - this project was used a lot durin 2002-2005 to make demos of SIP instant messaging using iPaq running Windows CE. It is basically a SIP user agent capable of sending and receiving text messages, developed in Visual C for Windows CE
• tmrec - this project offers a C library and command line tool for matching time recurrences defined by iCal RFC2445. The code is actually used, being embedded in cpl-c module of Kamailio SIP Server

Initially they were stored in CVS repository of BerliOS, but I switched them to SVN some time ago. Therefore, I was looking how to migrate SVN repository from BerliOS to a GIT repository on GitHub.

Googling gave lot of useful tutorials about migrating SVN to GIT, I am writing here just to show the specific case of migration from BerliOS to GitHub - it could save time for some people interested in same kind of operation.

Personally I used a Mac OS X, so first I installed git-svn from ports:

# port -v -d install git-core +svn

On a Debian/Ubuntu, the command should be:

# apt-get install git-svn

You have to create a file to map BerliOS username (used for SVN commits) to name and email address (to be used by Git). I named it authors.txt, the content:

dcm = Daniel-Constantin Mierla <me@xyz.com>

(no author) = Daniel-Constantin Mierla <me@xyz.com>

root = Daniel-Constantin Mierla <me@xyz.com>

For some reasons, which I didn't want to spend time to investigate why, there were two other authors appearing to have committed in SVN: root and (no author) -- so simply I mapped them to myself as well.

Next step I used git svn to clone the berlios project - here is the command used for pocketsipmsg project:

# git svn clone http://svn.berlios.de/svnroot/repos/pocketsipmsg --no-metadata -A authors.txt -t tags -b branches -T trunk pocketsipmsg

You will have to replace pocketsipmsg with your project ID on BerliOS.

I wanted to get the tags and branches from SVN. In the cloned directory, pocketsipmsg, you can list the branches with:

# git branch -r

You will notice that the SVN tags are now branches, to get them back to tags, you have to execute for each tag (named next as $tagname):

# git tag $tagname tags/$tagname

# git branch -r -d tags/$tagname

On GitHub you have to create the repository for storing the project - see http://help.github.com/create-a-repo/ to learn how to do it, if you haven't done it yet. In my case, I named it also pocketsipmsg.

Then add GitHub as remote repository and push to it:

# git remote add origin git@github.com:miconda/pocketsipmsg.git

# git push origin master --tags

That's all, your project is now stored on GitHub!

In summary, if git-svn is installed, your project does not have tags, you created authors file and added the repository $PROJECTNAME on GitHub under user $USERID, the commands you have to run for migration of $PROJECTNAME from BerliOS to GitHub are:

# git svn clone http://svn.berlios.de/svnroot/repos/$PROJECTNAME --no-metadata -A authors.txt -t tags -b branches -T trunk $PROJECTNAME

# cd $PROJECTNAME

# git remote add origin git@github.com:$USERID/$PROJECTNAME.git

# git push origin master

Enjoy!

Kamailio v3.2.1 Released

Kamailio SIP Server v3.2.1 stable is out – a minor release including fixes in code and documentation since v3.2.0 – configuration file and database compatibility is preserved.

Kamailio (former OpenSER) 3.2.1 is based on the latest version of GIT branch 3.2, therefore those running previous 3.2.0 versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with v3.2.0.

Resources for Kamailio version 3.2.1

Source tarballs are available at:

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

Detailed changelog:

• http://www.kamailio.org/pub/kamailio/3.2.1/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.1/

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/