- 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.
- 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.
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
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!
# cd kamailio
# git checkout -b 4.3 origin/4.3Binaries and packages will be uploaded at:
# cd kamailio
# git checkout -b 4.4 origin/4.4Relevant notes, binaries and packages will be uploaded at:
# cd kamailio
# git checkout -b 5.0 origin/5.0Relevant notes, binaries and packages will be uploaded at:
There were few changes to mark the last release compatible with Kamailio v4.x series. Future development will focus on compatibility with Kamailio v5.x.
Step by step installation tutorial, screenshots and demo are available on the web at:
Siremis is used during Kamailio Advanced Training classes for management of SIP server, a good opportunity to learn about Siremis itself, see more details at:
# cd kamailio
# git checkout -b 5.0 origin/5.0Relevant notes, binaries and packages will be uploaded at:5th edition of Kamailio World Conference, the project’s annual event, scheduled for May 8-10, 2017, in Berlin, Germany!Thanks for flying Kamailio!