Thursday, January 8, 2015

Kamailio v4.2.2 Released

Kamailio SIP Server v4.2.2 stable is out – a minor release including fixes in code and documentation since v4.2.0 – configuration file and database compatibility is preserved.
Kamailio (former OpenSER) v4.2.2 is based on the latest version of GIT branch 4.2, therefore those running previous 4.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 v4.2.x.
Resources for Kamailio version 4.2.2
Source tarballs are available at:
Detailed changelog:
Download via GIT:
 # git clone git://git.kamailio.org/kamailio kamailio
 # cd kamailio
 # git checkout -b 4.2 origin/4.2
Binaries and packages will be uploaded at:
Modules’ documentation:
What is new in 4.2.x release series is summarized in the announcement of v4.2.0:


    Have a great 2015! Looking forward to meeting many of you at Kamailio World 2015!

    Wednesday, December 31, 2014

    Happy New Year!

    A very dynamic 2014 for Kamailio has reached its end! Many thanks to those contributing to it!
    Looking forward to 2015, a lot of new features in Kamailio and new contributors! We wish a healthy and prosperous year 2015 to all Kamailio friends, hoping to meet many of you at Kamailio World Conference and other events around the globe!
    Happy New Year!

    Monday, December 29, 2014

    Kamailio 4.2 Tips: #12 - Execute RPC Commands In Config

    Although part of a new module in Kamailio v4.2 - jsonrpc-s - this bit worth a special mention: one can now execute RPC commands from kamailio.cfg using the function jsonrpc_exec(...).

    The main purpose of these commands was the execution from external applications, but sometimes comes handy to get access to them.

    Next example shows how to execute dispatcher.reload:

    jsonrpc_exec('{"jsonrpc": "2.0", "method": "dispatcher.reload", "id": 1}');

    An useful use case for the above command can be execution in a rtimer route to perform period reload of dispatcher records.

    Another example is to terminate an active dialog using h_entry and h_id.

    jsonrpc_exec('{"jsonrpc":"2.0","method":"dlg.end_dlg","params":[4,8],"id":2}');

    The RPC command has to be given as parameter to jsonrpc_exec() in JSONRPC 2.0 request format.

    There are over one hundred RPC commands exported now by Kamailio and the number is increasing with each major release -- no doubt that many of them can be useful to trigger from kamailio.cfg.

    Enjoy it!

    Friday, December 26, 2014

    Kamailio 4.2 Tips: #11 - Dynamic Pipes and Limits

    Pipelimit module in Kamailio 4.2 gives the possibility to add new pipes at runtime, specifying the algorithm and the limit. When using pl_check(...) with all three parameters, if the pipe is not found, it will be created:

    # perform pipe match for authenticated user, creating the pipe if not found
    $var(limit) = 20;
    if (!pl_check("$au", "traildrop", "$var(limit)")) {
     pl_drop();
     exit;
    }

    The limit can be adjusted later, by keeping the name and algorithm, changing the value for the third parameter. The parameters can be variables, therefore allowing full flexibility to name the pipe and set its limit.

    Practically, with this version, pipes can be created as needed, not depending on record stored in database like with older versions. Here is one useful example: add pipes per each source IP, enabling new mechanisms to protect against unwanted traffic, like D/DoS attacks.

    Enjoy it!

    Wednesday, December 24, 2014

    Merry Christmas!

    Another year getting slowly to the end, an excellent opportunity to thank to all old and new friends of Kamailio project, from contributing code to using it, helping on mailing lists and other places online, or advertising it across the world!
    Merry Christmas and Happy Winter Holidays!

    Thursday, December 18, 2014

    Kamailio World 2015 – Call For Speakers

    Kamailio World is the conference for realtime communication with Kamailio and related projectsKamailio World Conference – now for the third year in Berlin in 2015!  Submission of presentation proposals for Kamailio World 2015 is open. Deadline for submission is February 15, 2015, notification of accepted proposals will be done latest on February 28, 2015.
    Be aware that interesting proposals can be accepted before the deadline, we plan to have two intermediate review sessions before February 15, 2015, announcing any accepted presentations immediately. Therefore it is recommended to send your proposal as soon as possible, do not wait till deadline.
    To submit the proposal, fill in the web form at:
    The main topic of the conference is Real Time Communications, with the majority of the content being about Kamailio and other open source projects in the area. However, like for the past editions, we welcome very interesting presentations beyond those subjects.
    If you are interested to look at the agenda from previous edition, visit:
    Happy Winter Holidays! Looking forward to meeting many of you at Kamailio World 2015!

    Tuesday, December 16, 2014

    Maintenance Work on kamailio.org, Wed, Dec 17, 2014

    A short note to say that kamailio.org server availability may be interrupted shortly after 18:00 (Berlin time), on Wednesday, December 17, 2014, due to scheduled maintenance work.
    Among affected services:
    • main web site
    • wiki site
    • mailing lists: sr-users, sr-dev and business
    • downloads of tarballs
    • the GIT repository mirror on git.sip-router.org
    Hopefully the downtime will be short and barely noticeable for most of the people!

    Monday, December 15, 2014

    Main Kamailio GIT Repository Hosted on Github

    Today we moved the source code management away from an old server to a new infrastructure, based on Github. The main GIT repository that all developers use for development of Kamailio is now on a new address. The web link to it is:
    The old server that was hosted by us became very old and is going to be decommissioned very soon.
    For users (that cloned read-only from git.sip-router.org in the past) – it should be no change – just be sure that the DNS change has been propagated to you, because git.sip-router.org is pointing now to another server which has a real-time clone of Github repository. To know if DNS was updated on your side, browse to:
    an you must be directed to Gitlist web interface:
    If you end up in an URL with gitweb on it, the DNS cache on your side is still pointing to the old server.
    The listed kamailio and sip-router projects are the same (the second is kept for historical reasons and it is a symlink to the first).
    Gitweb is also running on the mirror, so the links from the email notifications of old commits are valid:
    Once the DNS is updated, pulling/fetching in an existing clone done from git.sip-router.org should just work.
    For developers – it requires to change the remote URL of your local clone to point to Github repository. Github provides access methods  via git/ssh or https: as an example of switching the remote URL to Github repository and do the push via https, got you your local clone directory and do:
    git remote set-url origin https://github.com/kamailio/kamailio.git
    Check the change with:
    git remote -v
    You should see:
    origin https://github.com/kamailio/kamailio.git (push)
    origin https://github.com/kamailio/kamailio.git (fetch)
    When you try to push, it should ask you for your Github username and password. For Github repository access, see more details at:
    GITHUB OctocatFrom now on all new commits will be pushed to github!
    Hopefully the migration is going to be smooth for everyone!

    Wednesday, December 10, 2014

    New Kamailio Module: statsd

    A new module has been pushed to GIT repository: statsd. It was contributed by Eloy Coto, a recently added member to Kamailio development team.
    The module provides the ability to send commands to statsd with different kind of information from the Kamailio configuration file. It provides native integration with statsd (https://github.com/etsy/statsd/) and graphite (http://graphite.wikidot.com/).
    statsd-kamailio

    You can read more about the module at:
    Eloy has also published an article about his development version here:

    Tuesday, December 9, 2014

    Kamailio - Shifting Main GIT Repository to Github

    The Kamailio project has decided to move our source code repository, where all the developers contribute source code, to Github on Monday, December 15, 2015. The very old server that runs our current GIT repository for Kamailio is in desperate need of retirement.
    There is already a real time mirror on Github and that is the one to become the main GIT repository – it can be found at:
    The current domain git.sip-router.org will be kept and directed to a read only real time mirror of the GIT repository, therefore those users that installed Kamailio from GIT should not be affected.
    GITHUB OctocatIf you are a developer with GIT write access and you cloned via ssh, you will have to change the remote URL to point to Github repository. You will be given write access to Github as well – if you haven’t sent your Github user id yet, email to

    More updates will be posted once the switch is done.

    Friday, November 28, 2014

    New Kamailio Developer: Eloy Coto Pereiro

    Kamailio project is glad to announce that a new person got developer GIT write access to repository: Eloy Coto Pereiro.
    He has developed a new module named statsd, which offers a connector from kamailio.cfg to manage values in statsd collector application, enabling further monitoring via various tools such as graphite. The module will be merged to main repository in the near future, now is available at:
    His git commit id is: eloycoto
    A warm welcome and looking forward to future work within the project!

    Monday, November 24, 2014

    Deploying Kamailio with Puppet

    Giacomo Vacca from Truphone, one of the very active community members promoting our project, has published a blog post on how to deploy Kamailio using Puppet.
    Puppet describes itself as configuration management system that allows you to define the state of your IT infrastructure, then automatically enforces the correct state. Whether you’re managing just a few servers or thousands of physical and virtual machines, Puppet automates tasks that sysadmins often do manually, freeing up time and mental space so sysadmins can work on the projects that deliver greater business value.
    Such knowledge is extremely useful and can save precious time to everyone handling installations of Kamailio and can be extended to manage the deployment of other components.
    As a project, Kamailio welcomes everyone that shares its experience and expertise, being more than happy to publish news about similar article and even host them if that makes it more convenient for the author. Do not hesitate to contact Kamailio team!

    Tuesday, November 11, 2014

    Kamailio v4.2.1 Released

    Kamailio SIP Server v4.2.1 stable is out – a minor release including fixes in code and documentation since v4.2.0 – configuration file and database compatibility is preserved.
    Kamailio (former OpenSER) v4.2.1 is based on the latest version of GIT branch 4.2, therefore those running previous 4.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 v4.2.x.
    Resources for Kamailio version 4.2.1
    Source tarballs are available at:
    Detailed changelog:
    Download via GIT:
     # git clone git://git.sip-router.org/kamailio kamailio
     # cd kamailio
     # git checkout -b 4.2 origin/4.2
    Binaries and packages will be uploaded at:
    Modules’ documentation:
    What is new in 4.2.x release series is summarized in the announcement of v4.2.0:

    Friday, November 7, 2014

    Kamailio v4.0.7 Released

    Kamailio SIP Server v4.0.7 stable is out – a minor release including fixes in code and documentation since v4.0.0 – configuration file and database compatibility is preserved.
    Kamailio (former OpenSER) v4.0.7 is based on the latest version of GIT branch 4.0, therefore those running previous 4.0.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.0.x.
    Note that branch 4.0 is now the 3rd old stable branch. The latest stable branch is 4.2, at this time having release of v4.2.0 out of it. For the future, the project is focusing on maintaining the last two stable branches, at this moment being 4.2 and 4.1.
    Resources for Kamailio version 4.0.7
    Source tarballs are available at:
    Detailed changelog:
    Download via GIT:
     # git clone git://git.sip-router.org/kamailio kamailio
     # cd kamailio
     # git checkout -b 4.0 origin/4.0
    Binaries and packages will be uploaded at:
    Modules’ documentation:
    What is new in 4.0.x release series is summarized in the announcement of v4.0.0:
    Note that 4.0.x is the 2nd previous stable release series, being followed by 4.1.x and the latest stable one is 4.2.x, you can read more about it at:

    Thursday, November 6, 2014

    Kamailio v4.1.7 Released

    The Kamailio SIP Server v4.1.7  stable version  is released. This is a minor release including fixes in code and documentation since v4.1.6 – configuration file and database compatibility is preserved. We recommend all users of 4.1.x versions to upgrade to this new version – no configuration changes are needed.
    Kamailio (former OpenSER) v4.1.7 is based on the latest version of GIT branch 4.1, therefore those running previous 4.1.x versions are strongly advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.1.x.
    Note that branch 4.1 is the previous stable branch. The latest stable branch is 4.2, at this time having release of v4.2.0 out of it. The project is officially maintaining the last two stable branches, at this moment being 4.2 and 4.1.
    Resources for Kamailio version 4.1.7
    Source tarballs are available at:
    Detailed changelog:
    Download via GIT:
     # git clone git://git.sip-router.org/kamailio kamailio
     # cd kamailio
     # git checkout -b 4.1 origin/4.1
    Binaries and packages will be uploaded at:
    Modules’ documentation:
    What is new in 4.1.x release series is summarized in the announcement of v4.1.0:
    If you want to see what is new in the latest stable version in 4.2.x series, see release notes for v4.2.0:

    Friday, October 31, 2014

    Kamailio 4.2 Tips: #10 - Lightweight retransmission detection

    UDP is still most common transport used for VoIP (hopefully that will change soon -- for proper security and privacy, TLS must be used), but by its nature of unreliable transport layer, applications must retransmit SIP packets over UDP if the next hop is not sending a response in very short time (typically, the first retransmission is done after 500ms, if no response was received). On mobile networks or congested paths, retransmissions happen quite often. The ability to detect quickly and handle them efficiently can improve the performances on SIP server side.

    With the old versions, the retransmission of a request was handled by tm module, creating the transaction, then same requests were matching the transaction and processed appropriately. As early the transaction was created during the config file execution, as quick the retransmission was detected.

    But a transaction is quite big structure (has space to store incoming request, its outgoing branches as well as relevant responses), creates timer tasks and uses shared memory, the last two require synchronised access, thus having impact on performances. Also, in many cases, requests are replied locally (e.g., destination user is not online, the request has to be authenticated), but the decision to reply can take a bit (e.g., a database query has to be performed for authentication).

    Creating the transaction and destroying it quickly, because the request was not forwarded, doesn't sound the most optimal approach. Processing a retransmitted request till it is about to relay it stateful and see at that moment it is a retransmission, it is also affecting performances (e.g., extra database queries are done).

    Kamailio 4.2 introduces a lightweight layer, which can be used between receiving a request and creating the transaction, for detecting and handling retransmissions. TMX module can keep track of requests processed at a moment by all SIP worker processes. Instead of a full transaction structure in memory for each request, it uses a very small structure per worker process in memory, keeping only the attributes needed to match the retransmission -- again, it is not a structure per SIP request, but per SIP worker process, given that at the end of configuration file execution, the worker will create the transaction if the request is relayed.

    To benefit of this feature, you have to use t_precheck_trans() function. Default kamailio.cfg for v4.2 includes it -- the handling of retransmission is done by:

        # handle retransmissions
        if(t_precheck_trans()) {
            t_check_trans();
            exit;
        }
        t_check_trans();

    The logic behind the above config snippet:

    • if the request is handled by another process (t_precheck_trans() returns true), then use t_check_trans() to send the appropriate reply in the eventuality the transaction was created by that process and exit
    • if the request is not handled by the another process (t_precheck_trans() returns false), then use t_check_trans() because the transaction might have been created before

    Within a configuration file that creates other large structures for calls, such as dialog, this feature becomes even more useful.

    Enjoy it!

    Wednesday, October 22, 2014

    Kamailio 4.2 Tips: #9 - Asynchronous Route Execution - DNS

    I got dragged back in the asynchronous loop by several folks here at AstriCon, so again another tip for it.

    Kamailio had a lot of asynchronous processing options for many years (including the transport layer TCP /TLS). Kamailio 4.2 brought in more options or simplified some of the existing alternatives. See also some of the previous posts in this series.

    The subject of this post is asynchronous config route block execution. Technically it is about delegating immediate execution of a group of actions from configuration file to another process than the SIP worker and can be used for various needs, not tied to something specific. For that reason, the example is about doing sort of asynchronous DNS handling (dedicated to Torrey, developer of sipt module, following the discussion after AstriDevCon day, at this moment busy with the hackatron).

    There is a lot of SIP traffic that doesn't require DNS -- for example: traffic terminated on the server, like REGISTER, presence requests, requests within dialog, calls between users registered locally (location service). Likely to have an hostname as next hop address are: requests sent to foreign SIP providers or calls sent to PSTN termination providers. Depending on the type of the service, there can be more or less percentage of SIP requests that need to do DNS lookup. However, DNS query can take a while, so it is an obvious benefit of avoiding such operation in a SIP worker.

    How to do it: first, the number for asynchronous workers has to be set via global parameter: async_workers. Then, the async module provides a new config function: async_task_route("rname").

    The missing piece would be how to decide whether forwarding of the message involves DNS or not. That is simple to do with:
    • $nh(d) - variable returning the next hop domain
    • is_ip(...) - function exported by ipops module which can detect if an address is IP or not
    Next are the relevant config snippets:

    request_route {
    ...
        if(!is_ip("$nh(d)")) {
            if(!async_task_route("DNSRELAY")) {
                send_reply("500", "Server error");
            }
            exit;
        }
    ...
    }
    
    route[DNSRELAY] {
        if (!t_relay()) {
            t_reply("500", "Server error");
        }
        exit;
    }
    
    

    Enjoy it!


    Tuesday, October 21, 2014

    Kamailio 4.2 Tips: #8 - Asynchronous Accounting to Database

    One of frequent database operations done by Kamailio is inserting accounting records. Some of database servers or additional software (sql proxy) offer solutions to speed up such operations, but typically they come with limitations. Such mechanism would INSERT DELAYED offered by MySQL, but it doesn't work for InnoDB tables.

    Kamailio 4.2 introduces the option to do the accounting to database using the asynchronous framework from core, provided that database connector module has support for it. This feature can be enabled by setting the acc module parameter db_insert_mode to 2.

    async_workers=4
    ...
    modparam("acc", "db_insert_mode", 1)

    At this moment, db_mysql module is able to do asynchronous queries, so it has to be used for accounting. Expect other database drivers to implement this feature in the near future. If db_insert_mode is 2 and database connector module doesn't support asynchronous query, then normal insert is performed.

    Enjoy it!

    Monday, October 20, 2014

    Kamailio 4.2 Tips: #7 - Increment CSeq for Proxy Authentication Done by Server

    Using uac module, Kamailio was able to do authentication to the next hop for quite some time. For example, this could be needed when sending traffic to a PSTN termination provider which require to authenticate by username and password.

    But there was a limitation: CSeq was not incremented for the INVITE sent with credentials - which was making authentication not-fully RFC compliant. The authentication worked if the other party was using Kamailio (or SER/OpenSER).

    The dialog module in Kamailio 4.2 has now the capability of detecting that the authentication was done by Kamailio (via uac_auth() from uac module) and increment the CSeq for the INVITE with credentials header. Subsequent messages in the same dialog will get the CSeq value adjusted accordingly.

    This feature has to be enable by setting dialog module parameter 'track_cseq_updates':

    modparam("dialog", "track_cseq_updates", 1)

    Note that the call (starting with initial INVITE) has to be tracked with dialog module (i.e., use dlg_manage() for requests belonging to that call).

    Enjoy it!