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:

• https://www.cluecon.com/schedule.html

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:

• https://www.cluecon.com

Enjoy!

Thank you for flying Kamailio!

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.

Several screen shots are presented in its documentation.

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!

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:

• https://github.com/irontec/ivozprovider

It has quite an extensive documentation online, offering several options for an easy install:

• https://irontec.github.io/ivozprovider/en/index.html

It is developed by Irontec, the company being another popular SIP-related project, respectively sngrep.

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:

• https://github.com/asipto/siremis

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!

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!