For this edition we had an increased number of speaking proposals, we tried to accommodate as many as possible from the very interesting ones, therefore we are introducing a group of Lightning Talks, most of them being on Monday, May 14, in the afternoon.
The range of topics is also richer, covering from the common use cases for IP telephony, VoLTE/5G or WebRTC, to scalability on demand with Docker, Blockchains in telecom, use of Redis backend for data sharing among many Kamailio instances, leveraging Lua for call routing and testing or VoIP security.
Related projects in the RTC world are again very well represented: Asterisk, FreeSwitch, Kazoo, SIP:Provider, Homer SIP Capture, Janus Gateway, CGRateS, FusionPBX and reSIProcate.
We continue to have the two interactive sessions that never missed a Kamailio World edition so far:
VUC Visions coordinated by Randy Resnick – expect again an engaging debate about the future of RTC, the impact of sharing personal data and privacy matters with the Internet giants services or surprise topics brought on table by panelists and audience
Dangerous Demos coordinated by James Body – prepare your demo and be part of a very entertaining contest that can make you famous as well as reward your work with a prize
A novelty for this edition is an open discussion with Kamailio developers – Ask Me Anything – aiming to get the participants face to face with several main Kamailio developers to chat and clarify any doubts about using or developing the project.
Kamailio SIP Server v5.1.3stable is out – a minor release including fixes in code and documentation since v5.1.2. The configuration file and database schema compatibility is preserved, which means you don’t have to change anything to update.
Kamailio® v5.1.3 is based on the latest source code of GIT branch 5.1 and it represents the latest stable version. We recommend those running previous 5.1.x or older versions to upgrade. There is no change that has to be done to configuration file or database structure comparing with the previous releases of the v5.1 branch.
Kamailio source tree include a set of few dozen of shell-based unit tests developed several years ago, residing inside test/unit/ of the source code tree. They were more or less not actively maintained during the past few years.
Based on the interest from the community and discussions during past IRC development meetings as well as panels at Kamailio World Conference, a new effort was started recently to built a unit testing framework leveraging Docker.
The first version has been published on GitHub, being available at:
The unit tests have been run when releasing a new stable version during the past months. They leverage tools such as sipp or sipsak for generating SIP traffic and testing routing scenarios, but some of them go beyond SIP and detect source code issues such as missing symbols or broken dependencies.
The architecture of the unit testing framework is still a moving target, we aim to provide something easy for community members to contribute to as well as require for newly added modules to be accompanied by a set of basic tests.
One of the main benefits it would be to have the reports of the issues that can be reproduced submitted along with a unit test. It would make it easier to troubleshoot and then after fixing it, would be tested always before releases in order to avoid regressions.
Right now, a good help from community would represent converting the old unit tests to the new framework, afterwards we can decommission test/unit. The conversion should be rather easy, as we still rely on shell and the sip tools like sipp/sipsak … If you want to help here by you need clarifications or get stuck somewhere, just write to mailing list and I would be more than happy to assist. Such contributions should be submitted as pull requests in order to be easy to review:
Julien Chavanton from Flowroute added recently a new module: acc_json
The module builds JSON documents from the accounting records and can send them to mqueue to be consumed by other processes or write to syslog. For example, when using it configured with mqueue, the consumers (e.g., started with rtimer module) can send the accounting JSON document to an external system via HTTP (see http_client or http_async_client modules), rabbitmq, nsq or even as a payload to a new SIP message (see uac module).
More details about acc_json module can be read at: