Friday, May 31, 2013

Personal distributed micro-computing for battery life or something else, will that happen?

Distributed computed is associated with the need to perform tasks that require big resources, mainly related to CPU and memory. Although there are even big projects addressing to the masses (e.g, SETI@Home), most of such projects run on private distributed grids owned by academic institutes or big companies.

Looking around the bunch of gadgets we carry with us these days, probably more in the very near future, I was wondering if delegation of tasks between these devices will improve our experience. As a traveler, the smartphone is the most convenient tool for me to check what happened online. Can be done during queuing for security checks, waiting for and in public transport or during walking. The problem, its battery goes dry fast, very fast.

But there can be plenty of devices around me, owned by me, just sitting in standby. Will a transparent interaction between them can give us a better experience?

The smart phone could be like a control center, delegating tasks to your Google Glases, Apple iWatch, Kindle, Sony MP3 Player or even the laptop. You took a video and want to scale it to upload, the laptop can do faster, it just need to be woken up, get the video and return it back sized down. Checking if there is a new email in inbox can be delegated to mp3 player, that eventually return a 'no' or headers of what is new.

Besides the fancy gadgets these days, kind of required to be small, people like to wear also big things, which can hide battery and computing power - boots, belts, hats, necklaces... Time for them to join the electronic space and for gadget companies to build a personal micro-computing grid framework?

image taken from

Wednesday, May 29, 2013

Five Kamailio command line parameters for troubleshooting

In an era where clicks are ruling the interaction with computers, many people forget that most of applications provide a bunch of command line parameters, some of them quite useful.
It the case of Kamailio, not being the case of a GUI application but a daemon, the control is still done from the terminal, however that's usually via service or init.d scripts. The result is pretty much the same, not many pay attention to what parameters can be given from command line.

There are couple of them related to troubleshooting, which in various cases can save precious moments and make the operating of Kamailio deployments easier. Here are those that you should have always in mind for quick troubleshooting and safety checks.

1) - c - syntax checking of configuration file

No matter how simple changes you think you did to your config file, especially in production environments, do not forget to check for syntax errors. You never know when a key was pressed accidentally without notice. Kamailio can still fail to start for other reasons (e.g., invalid user or password for database), but at least the structure of the configuration file is correct.

Therefore have in mind to run a 'kamailio -c ...' before restarting kamailio.

2) -E - print log messages to standard error

This option can be controlled also via log_stderror global parameter in configuration file. But I don't like changing configs just for temporary needs. Besides that, it many cases (e.g., production environment), editing files can take too long.

I use it mainly with the next one (-d) and I do not want to pollute the log file by an increase of debug verbosity.

Stoping kamailio and starting it with -E -d... for watching live the log messages is helping me a lot. Typically I want to see some INFO, NOTICE or WARNING messages added in config file for a particular purpose, where normal operation mode is having a lower debug threshold like ERROR.

3) -d - increase debug level

This option is the solution to increase the verbosity of log messages without editing the configuration file. Used together with -E, you can watch the messages on the screen. Used alone, the syslog file will be filled with more messages, watching it in real time can be done with 'tail -f ...'.

4) -e - print colourful log messages

When the terminal has the capability to display colourful text, this option enables Kamailio to write the log messages in different colours, depending on log level. It requires -E, otherwise the log message would get non-ASCII content.

5) -A - add a pre-processor define

The queen option of controlling the config file, -A can be used to add pre-processor defines. No need to edit the file to define WITH_DEBUG, you can just start kamailio with '-A WITH_DEBUG'.

Many of my configs are having various #!ifdef's that I can turn on/off from command line just for troubleshooting purposes. Play with it, you are going to like it.

Tuesday, May 28, 2013

Per module debug level in Kamailio

The Debugger module got a new infusion of tools that should make troubleshooting at runtime easier. The latest set of commits from me added the ability to enable per module log level.
What does that mean? Practically, for example, you can configure that log messages from tm module to be printed with DEBUG level threshold and the rest at ERROR threshold. The result is that the tm module will be very verbose, printing all debug messages, while the rest of the code will print only errors or lower log level messages. This feature is seful when troubleshooting a specific module, the log file not being filled by messages that are not important for the case.
Victor Seva contributed further with several enhancements allowing to enable/disable this functionality at run time as well as change module log levels via RPC commands (without restarting Kamailio).
For more details, see the readme file of debugger module:
We hope this functionality is going to help many Kamailio users out there!

Monday, May 27, 2013

New Kamailio module: auth_ephemeral

Peter Dunkley from Crocodile RCS has pushed a new module in Kamailio GIT master branch: auth_ephemeral. Quoting from the module documentation:
This module contains all authentication related functions that can work with ephemeral credentials.
Ephemeral credentials are generated by a web-service and enforced on Kamailio. This usage of ephemeral credentials ensures that access to Kamailio is controlled even if the credentials cannot be kept secret, as can be the case in WebRTC where the credentials may be specified in Javascript.
To use this mechanism, the only interaction needed between the web-service and Kamailio is to share a secret key.
Typically, credentials will be requested from the web-service using an HTTP GET and provided in a JSON response. To prevent unauthorised use the HTTP requests can be ACLd by various means.
This mechanism is based on the Google proposal for a “TURN Server REST API”.
An obvious usage is together with websocket module to provide authentication for WebRTC-related communications. Read more about in the module documentation:

Sunday, May 26, 2013

Kamailio SCTP transport now as a module

The Kamailio implementation of the SCTP transport layerhas been moved from core to a dedicated module. Befor this change, enabling SCTP required a recompile of the core if you didn’t do it from the beginning, making it a bit complex at least when installing from packages.
Following the same architecture as with TLS, the SCTP code has been moved to its own module, making it possible to enable SCTP support by just compiling and installing the SCTP module. If Kamailio was installed from packages, an extra package has to be installed as well (kamailio-sctp-modules).
The parameters related to control of SCTP sockets have been moved to the module as well. You can read the module documentation at:
On Linux, to get sctp modules compile, you have to install libsctp-dev package.
The SCTP module will be part of the next major release of Kamailio, later this year.

Saturday, May 18, 2013

New Kamailio Developer: Victor Seva

The Kamailio project announced that a new person joined the development team, getting developer GIT write access to repository – his name is Victor Seva.
Victor helped pushing back Kamailio in official Debian packages and lately has submitted many patches to various modules, among upcoming ones is some work on newly added per module debug level .
His git commit id is: vseva
Warm welcome and looking forward to his future work within the project!

Friday, May 17, 2013

What is the IP Multimedia Subsystem (IMS) in Kamailio 4.0?

Since release 4.0.0 Kamailio has incorporated support for basic IP Multimedia Subsystem – IMS – functionality – but what does this mean? This article aims to describe IMS as well as the history and current state of the IMS functionality in Kamailio 4.0. 
The IP Multimedia Subsystem (IMS) was first introduced by3GPP in 2005 and has since become the de facto standard for supporting voice and other multimedia services over LTE and other IP networks in an efficient, secure, reliable and billable manner.
It bridges the gap between reliable circuit switched voice services and efficient IP technologies – and enables opportunities for the creation of advanced multimedia services and 3rd party applications. While IMS has been discussed widely outside service provider networks, it is still growing and is the focus of a migration away from old technologies in the carrier space.

Sunday, May 12, 2013

Next events to meet Kamailio

After a very successful dedicated conference, Kamailio World, the project continues to be present across the world for various events. During the next two months, one can meet with Kamailio developers or participate to dedicated events at:
If you organize or participate to an event involving Kamailio, write us to publish the details here and help connecting with other community members in the area.
You can email to .

Wednesday, May 8, 2013

Siremis v4.0.0 Released

Siremis, the web management interface, has released the version 4.0.0, offering out of the box compatibility with Kamailio v4.0.x release series.
Read more details and links to installation guides at:

Monday, May 6, 2013

Careers & Jobs with Kamailio

There are many opportunities for those looking to pursue a career in real time communications with SIP and Kamailio as well as projects related to this area.
Here are several announced within Kamailio project environment:
If you have an open position in your enterprise that is related to Kamailio in some way, send an email to mailing list  and you will be listed in this post.

Thursday, May 2, 2013

DNSSEC Support in Kamailio

Thanks to Marius Zbihlei, DNSSEC support in Kamailio can be activated by loading the module with the same name, there is no need to recompile the sources anymore.
An online tutorial has been made available on the wiki for those that want to get started with DNSSEC — it can be found at:
The wiki can be edited by anyone creating an account on it, we hope people with add content as they discover themselves useful tips for this use case.
Apparently Kamailio is the first SIP server with this extension, fortunately Jitsi, the SIP softphone, supports it already as well, the two offering the tools necessary for experimenting with DNSSEC in a complete VoIP service.
Special thanks to Dan York, from Internet Society and VOIPSA, for including Kamailio with its DNSSEC extension in the presentation given at SIPNOC’13 conference last week – slides are available at:
This Friday, Dan will speak about DNSSEC at the weekly VoIP Users Conference, join the conversation to learn how DNSSEC can help improving security in VoIP.
Don’t hesitate to send any feedback about dnssec implementation to our mailing lists, it will help us to improve it and get it ready for production with the next major release, v4.1.0, expected later this year.