Kamailio Advanced Training
Click here for more details!

Learn how to build RTC services with Kamailio!

Wednesday, August 9, 2017

ACC – SQL Define Removed And Diameter Code Relocated

The ACC module (accounting) in Kamailio got a bit of clean up, therefore be aware of following changes:
  • (1) the define conditions on SQL_ACC were removed — this was enabled for more than 10 years and only made the code look complex and hard to follow up its logic.
  • (2) the code related to DIAMETER accounting was relocated to acc_diameter (new) module. It was a consistent size of code that was not enabled for sooo… long. It is now a dedicated module, similar to acc_radius. The diameter accounting code, even a new module now, is in the same stage, compiling but not tested, in pair with auth_diameter module, it may work, but very likely not.
In summary, what’s important for those using the acc module — it offers the same functionality as it was enabled by default in the past 10 years or more: writing accounting records to syslog and sql databases — only the unused code was relocated.
The acc module is now slimmer, only with the code that it needs, therefore easier to maintain and enhance for the future. For any issue, as usual open a report on Github project portal.
Thanks for flying Kamailio!

Tuesday, August 1, 2017

Research On VoIP Fraud Using Kamailio As Sensor

Konstantin Tumalevich has posted an article via GitHub about his research done on VoIP fraud using Kamailio as a sensor, along with other VoIP applications such as Asterisk.
Some interesting facts extracted from the article:
For research, I created honeypot what mimics vulnerable PBX.
For emulation, I used Kamailio nodes that send any calls to termination node and answers to OPTIONS and REGISTER.
For every INVITE I recorded From, To, UA, Call-ID, IP and call time.
Termination node has Kamailio with Flask app for preprocessing calls and Asterisk for topology hiding when calls sent to PSTN.
All calls with a cost of more than 2 cents per minute were rejected with code 486.
I used 4 sensor nodes located in NL, DE, SG and NYC.
For 18 days, 254805 INVITE were collected from 296 different IP’s. On average, 860 INVITEs were received from an IP.
Reports about top source IPs, countries of origin and the operator as well as related graphs can be found in the conclusions of the research. Few hints are also provided about how to protect better.
You can read the entire article at:
Enjoy!
Thanks for flying Kamailio!

Monday, July 24, 2017

ClueCon 2017

As every August for more than a decade, the ClueCon conference takes place again in Chicago, USA, during August 7-10, 2017. Mainly organised by the people behind FreeSwitch project, ClueCon is among those events where you can meet a large group of experienced people with open source realtime communication technologies.
Kamailio will be present with a talk by Fred Posner, one of our very active advocates of the project in North America and not only. His presentation is scheduled for Wednesday, August 9, at 10:45am:
Besides Fred, you will be able to meet other relevant members of Kamailio project or friends from the VoIP world! If you haven’t checked the event so far, do it very soon and consider to register, no much time left and ClueCon is always worth attending! Read moreabout the event at:
Enjoy!
Thank you for flying Kamailio!

Tuesday, July 18, 2017

dSIPRouter – GUI For Kamailio SIP Trunking

dSIPRouter is a web GUI that facilitates deploying Kamailio for SIP trunking services, developed by dOpensource.com and offered as open source on Github under Apache 2.0 license.
It allows to manage the carriers and PBXes from a modern front end web GUI, built in Python. The application was developed for Kamailio 4.4.x series and tested mainly on CentOS.
Enjoy!
Note: should you develop or are aware of any application that is related to Kamailio, do not hesitate to contact us, we will happily publish a news about it on kamailio.org.
Thanks for flying Kamailio!

Monday, July 10, 2017

IvozProvider: Kamailio And Asterisk Based VoIP System

IvozProvider is a provider oriented multilevel IP telephony solution for use on public internet or private networks. It allows multiple access levels within the same infrastructure, from operator administrator to granular brand and company administrators as well as end user.
Here is an excerpt from its presentation:
“IvozProvider was designed always keeping in mind the horizontal scaling of each of its elements, so it can handle hundred of thousands concurrent calls and what is more important, adapt the platform resources to the expected service quality.”
It relies on an handful of open source applications, including Kamailio, RTPEngine, Asterisk, MySQL or JsSIP.
The project is available on Github at:
It has quite an extensive documentation online, offering several options for an easy install:
It is developed by Irontec, the company being another popular SIP-related project, respectively sngrep.

Friday, July 7, 2017

SIREMIS – Ongoing Updates

There is some ongoing work on Siremis (web management interface for kamailio) to make it fully compatible with Kamailio 5.0.x as well as update some of its legacy components:
So I thought to start a discussion here and see if some of those changes are going to impact too much existing installations or what are the best options to use for the future.
Done so far:
  • 1) implemented the JSONRPC client using UDP and unix domain sockets, to work in pair with jsonrpcs module as a replacement for removed MI interface. The old JSONRPC over HTTP is still an option.
  • 2) charts system has been migrated from open flash chart (ofc) to echarts (pure html5/javascript) — therefore no more requiring to enable flash in browser. Configuration is the same and the charts should look pretty similar. If you upgrade, apart of different html view for the charts, the config files should not be changed. If you notice something broken, open an issue on github project linked above.
Planned to be done:
  • 3) Relocate siremis/modules/ser to siremis/modules/sipadmin — this purely for more suggestive name for the admin module related to the SIP services offered by Kamailio, and be in pair with the module sipuser. This is mainly search and replace over php and xml files, however, it is going to impact if you developed your own internal extensions for Siremis and placed them in the ‘ser’ module. It will require that you do the same search+replace
  • 4) Review existing database tables views and add fields for missing columns.
  • 5) Add views for other database tables. First in my mind being the table for rtpengine module. If you use some modules with tables not yet managed by Siremis, reply and list them to set a list of priorities.
Should have other things to report about Siremis and are not yet listed on project’s issue tracker, let’s discuss here.
Testing and feedback for 1) and 2) are very appreciated!
Thanks for flying Kamailio!

Wednesday, July 5, 2017

Skype For Android Update Brings No User Presence

Apparently the latest update of Skype for Android from few weeks ago removed the user's presence status, so no more online, do not disturb, etc. for your contacts. Either a bug or a feature, not clear yet, but it is reported or discussed across the web (redit, microsoft, etc.).

Being one of the first RTC apps that worked cross plaform (Linux, Windows, Mac OS), I got couple of old relatives used to it and they relied a lot on presence status to start chatting. This change had an impact, as they didn't contact each other for a while, until they starting questioning what happens.

I am still using it from time to time as a channel for first discussions on a potential business prospect, if nothing else is convenient, but there I don't rely on presence status at all, anyhow, the desktop version still presents user's status.



Anyhow, the reason for blogging about is to debate the usefulness vs. complexity of presence services. The telephony and VoIP is probably one of the biggest consumers for presence, mainly related to so called BLF (busy lamp fields), very common in the PBX world. Maybe an easy to implement in old PBX models, where each phone had a unique extension (number) associated with, the implementation complexity escalated in the VoIP/IP telephony world with the possibility of a user to have many devices for the same account.

Moreover, the rise of multi-tenant cloud-based PBX systems, the presence service became an issue of scalability as well. Behind presence service is a greedy data consumer, for each state change, there is a bunch of notifications going on behind:

  • either one from device to the server, then from server to many watchers (the contacts) - presence server model
  • or many from device to each of the watchers - end-to-end presence model
I think the main reason for shrinking presence services is the monetisation, or better said, the lack of it. If there would be enough financial benefits, the RTC providers will invest in it. Besides users not willing to pay for it (or not being used to pay for it), the free RTC networks out there cannot do much with data collected on this scope -- it is no much commercial value to know how many times you went from online to idle to do-not-disturb and back within a day. Texting on the other hand is where you share your needs or thoughts, the provider learns quickly you asked a friend for suggestions on a new gadget, so your next web browsing session has the adds waiting right there.

There is another reason that presence might be disabled on mobile apps -- background traffic to update the status, which affects both battery life and data usage. This issue could be eventually overcome by doing presence requests only when the contact is displayed, so I don't see it as the main reason for not offering presence.

The free messaging services space is so crowded that the cost of operations is crucial. Many services started with no real time presence (e.g., WhatsApp). Others are following now, more or less we see a movement like in the low cost airlines model - get rid of what is not making money directly, offer only the minimal!

Friday, June 23, 2017

Kamailio v4.3.7 Released

Kamailio SIP Server v4.3.7 stable is out – a minor release including fixes in code and documentation since v4.3.6. The configuration file and database schema compatibility is preserved.
Kamailio (former OpenSER) v4.3.7 is based on the latest version of GIT branch 4.3, therefore those running previous 4.3.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.3.x.
Important Note: v4.3.7 is the last official release from branch 4.3. Consider to upgrade to v4.4.x or 5.0.x as soon as possible to benefit of proper source code maintenance.
Resources for Kamailio version 4.3.7
Source tarballs are available at:
Detailed changelog:
Download via GIT:
 # git clone git://git.kamailio.org/kamailio kamailio
 # cd kamailio
 # git checkout -b 4.3 origin/4.3
Binaries and packages will be uploaded at:
Modules’ documentation:
What is new in 4.3.x release series is summarized in the announcement of v4.3.0:
Note: the branch 4.3 is becoming an unmaintained stable branch. The maintained stable branches at this moment are 4.4 and 5.0, with v5.0.2 being released out of the latest stable branch. Therefore an alternative is to upgrade to latest 4.4.x or 5.0.x – be aware that you may need to change the configuration files and database structures from 4.3.x to 4.4.x or 5.0.x. See more details about it at:
Thanks for flying Kamailio and enjoy the summer holidays!