Kamailio Advanced Training
Click here for more details!

Learn how to build RTC services with Kamailio!

Wednesday, March 27, 2013

WebRTC, SDP and Fata Morgana

There were many discussions lately about the format of session description to be used for real time communications between web browsers. Apparently it was a decision (or at least ongoing work) of IETF to reuse SDP, same format used by other protocols, including SIP.

As usual following a decision, the most verbose begin to be those against, somehow natural, trying to get their last chance to change the things for something they like more.

For what it worth, I am working with SIP continuously for more than a decade in the Kamailio project, but mostly on signaling part for routing between peers. The real interaction with SDP was just to update media IP and port to help with NAT traversal, plus a set of functions to remove codecs or media streams from offerings. Session description document (which is transferred as payload of SIP messages) is none of a SIP signaling server business. Topped with the fact that in webrtc support for ICE is mandatory, therefore no more need for server side NAT traversal processing, it is barely any interaction from SIP server point of view.

Probably SDP is not the ideal format, but it is something deployed world wide, therefore implemented at large scale. It is claimed it got to a very complex structure, that may be true, as initial specs didn't took in consideration NAT at all, IETF striving for years to fix it afterwards, keeping patching formats and protocols.

However, I was not and I am not defending SDP in any way, particularly as it is not something I rely on. What I am against is to decide to go for something not known yet. I haven't seen any proper alternative proposal by those not liking SDP, just few ideas and sketches, more like JSONified or XMLized SDP. I don't think that just adding tags or curly braces around here and there will change dramatically the situation. The complexity level stays the same if that was the concern of using SDP.

Running after fata Morgana proved to be wrong in many past IETF activities. Let's remember how they tried to specify from scratch the presence and instant messaging extensions for SIP. A long and laborious process, trying to cover extreme corner cases, and the results we know very well, not easy at all to put in practice.

From interaction perspective, there are two major use cases for webrtc:
  • communications only within a service (aka, walled garden environment)
  • communications between different services (aka, peering/interconnect networks)
I am concerned only about the second. For the first case, the service provider should not even bother waiting for indications from IETF. The role of IETF is to define interoperable protocols that can connect different implementations from different providers, not to do house keeping for each cottage business.

Here is why I consider to be wrong deciding to start now and wait for specifying a brand new session description format:
  • deployments of webrtc services will be delayed indefinitely, there are parts of the market that want it now. I doubt one can set an accurate timeline for writing specs and do a clear estimate of the time to the market. Even so, it will take at least 2-3 years.
  • many good, practical oriented people will leave at some point - there will be lot of irrelevant discussions about xml vs. json vs. clear text vs. binary vs. whatsoever base format, then each attribute will have few rounds about the name, upper or lower cases, font color, etc. as well as the same for values. If practical people are gone, there are high chances that the result is yet another ideal theoretic specification, but hard to implement
  • many will want the front seat, so there will be many proposals in the first round, then terms to debate and decide on finalists for the world cup tournament to get the *one*, adding more and more delays to the entire process, with harsh fights not missing from the stage
  • no matter how 'perfect' is going to sound the new proposal at first sight, definitely expect many voices against. It will result again in frictions and adverse groups, practically back to current situation
IETF has to do the decisions based on current facts and shall not leave parts required for interoperability unspecified. Anything selected now does not stop working on new ideas, if anyone comes with a better alternative over the time, it will be adopted anyhow by the market.

Web environment offer huge opportunities for innovations, with the major components open source (browsers, servers, development languages and tools) and a non-regulated structure, so nothing has to be started from scratch nor wait for bureaucratic procedures.

Don't waste time looking only at the bad things about SDP, they are known, but there are many good things by reusing a deployed technology, avoided in presentations from dislikers. Get your hands dirty in C/C++ code or other programming language and extend the browsers with your ideal session description format, show the results to the world and how that makes everything easier and better for business and user experience, then the market will simply follow!

Let everyone work in quite and focus on their needs, those that want to deploy now by reusing existing technologies as much as possible, as well as those willing to come up with something different and eventually better for the benefits of everyone.

PS. It is not relevant for interconnect what is the API provided by the browser to upper layer of programming language/JavaScript. For interoperability is important that the format exchanged between different services follow a standard specification. A browser can simplify the presentation of the session description format sent to or received from the network.

PPS. The webrtc is not referring here strictly to a particular specification named the same, but more to the broader concept of real time communications over web technologies.


Tuesday, March 26, 2013

Not in my mobile world...

Spending over a decade in time in real time communication services, at some point in early stage of my career even working for a mobile operator, I realized about some things I never had or barely did:
  • never had a contract with a mobile operator - no monthly subscription fee, only prepaid. In late nineties I got first cell phony while still being at studies. To get a contract, one had to provide a lot of documents to guarantee for paying the bills. Going for prepaid was easier, but of course more expensive per minute. Once I got closer to the industry and understood the risks of over-charging, specially for people that travel a lot, spending many weeks a year on roaming, contracts were no longer attractive. I started with email before cell phone, I am still an email centric communication guy. Also, my business is mainly about IP telephony, when traveling I prefer to pay for one hour of WiFi access where I can call VoIP but also check the emails. Today I have three active seems always around me (one just for 3G data plan), none under contract. And no bill shock can happen, although I spend substantial time on roaming.
  • never sent a MMS - probably the most useless feature I ever seen on mobile services. Introduced before the era of popular big screen smartphones, sending a picture that couldn't be actually seen meant simply just paying for stupidity. I was never more than few hours far from an internet connection, there are better ways to share a moment with images
  • never bought subsidized smartphones - even in most cases they are bound to monthly contracts, there are more expensive options for what is called here 'branded phones with sim lock'. Practically, you cannot use other mobile networks and the phone is pre-installed with that specific mobile operator apps. The difference of few tens of Euros comparing with standard price was never appealing when the device costs anyhow several hundreds. Traveling frequently results in a quite big stock of international SIM cards, ability to use any of them is a real value for a phone
  • never used call forwarding - this is it, if the call was for me, it's me or nobody answering
Among services I barely use:
  • voicebox - I try to disable the service whenever possible, although many times the operators makes it impossible or reactivate the service periodically for what so ever unknown services. As it may not be convenient calling back to voicebox service (could happen again because of traveling), better not have messages that people consider as delivered. Calls are for real time interaction, if not available, use email or SMS for short description of the matter
  • directory or info desk services - locating a restaurant nearby or other place is much easier using the Internet. If I'm going to be premium charged for a call, again I rather pay for internet access on public WiFi hotspots.
That leaves pretty much voice and sms, both used quite rare lately, more and more rarer! Why? Because mobile operators add new features too late on the market, when already another IP-based service is very popular for offering same features. It is hard to change habits then.

Hopefully at some point we will see true innovation from mobile operators, till then Internet rocks!

Sunday, March 24, 2013

4.0 and beyond

Kamailio is flying, and the time with it, already two weeks since the release of v4.0!

Last months I was very busy getting Kamailio-SER integration finished (i.e., removing duplicated modules) and correlated with the usual business and traveling agenda, effectively this blog, with few exceptions, was just mirroring news from Kamailio project.

v4.0 is rocking, with excellent feedback from community, especially from WebRTC enthusiasts playing around with WebSocket support in Kamailio. IMS extensions are attracting many eyes as well, being one of the very few open source implementations out there.

Development for v4.1 is at full speed already, a new module is available in master branch (app_java - embedded java code execution), one on its way (cnxcc - credit control/prepaid system) and another one in developer personal branch (ims_ro - RO prepaid accounting interface for IMS). Besides those, many old modules have been worked on, such as snmpstats, usrloc, tm, p_usrloc, sca, carrierroute, ... Team is growing as well, two new people got on board recently: Hugh Waite and Carlos Ruiz Diaz.

My next big milestone is Kamailio World Conference, just about 3 more weeks and the event starts in Berlin, Germany. All signs predict a successful show, agenda is completed (just few bits to be adjusted), participation exceeded the initial planned capacity, with attendees from small and medium companies to large telcos and mobile operators, from pretty much all over the world (North and South America, Asia, Africa and Europe). But the real work with organization starts now on the fields, next three weeks will keep me a lot out of the office.


For the next months, besides coding for Kamailio v4.1 (expect some surprising goodies to be announced) and business activities, I plan to spend more time on catching up what is happening around. Among my top priorities:
  • review what is new in the SIP phones world - it's been quite a while since I analyzed what, if any, appealing features were brought by vendors with latest firmwares and devices
  • dedicate more time on federated SIP - following the panel as Fosdem, it is time to increase the federating of real time communication (RTC) services, email proved it can be done
  • blog more about RTC technologies, with or without relation to Kamailio project
Therefore keep an eye on this site. If you plan to attend Kamailio World Conference, ping me to arrange for a chat!

Thursday, March 21, 2013

New Kamailio developer: Carlos Ruiz Diaz

Kamailio project is glad to announce that its development team is expanding again – a new person got developer GIT write access to repository: Carlos Ruiz Díaz.

He is going to add and maintain the credit control module, which was announced earlier this year on project’s mailing list – the module is part of a framework that has three parts:
His git commit id is: caruizdiaz

A warm welcome and looking forward to future work within the project!

Wednesday, March 20, 2013

New module in Kamailio: app_java

Konstantin Mosesov has added a new module to Kamailio development branch that allow embedded execution of Java compiled code. Java applications get access to attributes of current processed SIP messages and can execute internal Kamailio functions via Java Native Interface (JNI).

You can learn more about the new module from its readme documentation:
Effectively, one can write the SIP routing logic in Java and let Kamailio execute the code at runtime faster than as external application. This extension enables rapid integration of Kamailio in existing environments developed on Java technology.

The new module adds to a group of existing embedded interpreters in Kamailio, respectively: app_lua (for Lua language), app_mono (for managed languages C#/.Net, F#, …), app_perl (for Perl language) and app_python (for Python language).

Friday, March 15, 2013

Kamailio at FOSDEM’13 – Slides

More than one month later since FOSDEM’13, everyone being busy making Kamailio v4.0.0 happen, the slides related to Kamailio project are available on project’s website.

In the Telphony Dev Room, Peter Dunkley gave the presentation on SIP and MSRP over WebSocket in Kamailio (click for pdf), with Daniel-Constantin Mierla briefing on what was new in Kamailio during the past year (click for pdf).

On the main track, Daniel-Constantin Mierla was part of the panel about Free, open, secure and convenient communications, discussing about open federations with SIP and Kamailio (click for pdf).

There was another big gathering of Kamailio community, more than 20 people related to the project being around. Everyone is now waiting for the next year edition!

Meanwhile, we look forward to meeting again at Kamailio World Conferece, in Berlin, by mid April 2013.

Tuesday, March 12, 2013

Packages for Kamailio v4.0.0

RPM packages for Kamailio v4.0.0 are available now for several Linux distributions: Centos 5.5 and 6, RedHat 5 and 6, Fedora 16, 17 and 18, OpenSuse 12.1, 12.2 and 12.3.

You can find download links at:
The Debian packages for several distributions, including Ubuntu, should become available soon on project’s APT repository. Meanwhile, packages for Debian Squeeze are available at:

Monday, March 11, 2013

Kamailio v4.0.0 Released

March 11, 2013: Kamailio v4.0.0 is out -  a special major release, shifting up the first digit in versioning number!
 
Besides bringing a lot of improvements and new features, the main reasons for this upgrade of version string are:
  • end of Kamailio – SER integration: for the 3.x release series, there was the same source code for Kamailio and SER, but with some duplicated modules and different database structures. Now the project is back to one set of modules, all the duplicated modules being integrated.
  • new transport layer: starting with this release, Kamailio supports WebSocket transport layer (both plain and secure), in addition to UDP, TCP, TLS and SCTP. WebSocket allow modern Web browsers to call between them using SIP for signaling.
  • Kamailio becomes the default application name (aka, default flavour) and what the public project is packaging. SER can be built manually, its flavour being kept for historical and maintenance reasons.
This release is a result of about 6 months of development and 2 months of testing. Continue to read full release notes at:
We look forward to meeting many from project community and potential users of Kamailio at our dedicated event – Kamailio World Conference – during April 16-17, this year in Berlin, Germany!

Enjoy SIP routing in a secure, flexible and easier way with Kamailio v4.0.0!
Thank you for flying Kamailio!

Wednesday, March 6, 2013

New Kamailio Developer: Hugh Waite

Kamailio project announced that a new person got developer GIT write access to repository: Hugh Waite – he is quite old contributor by now, with many patches and activity on mailing lists.

He is part of the Crocodile RCS team, which developed very important features for Kamailio so far, like websocket and outbound extensions, Lua API and presence/rls improvements.