Not really predictions, but more what is driven by current situation in SIP world, here I present my thoughts about this market from the perspective of
Kamailio Project co-founder and leader these days.
2011 is my 10th year in the SIP world. Officially I started on 1st of January 2002, few months after I graduated Computer Science University I joined the development team of
SIP Express Router (SER) at Fraunhofer FOKUS Institute in Berlin, Germany. Since then I was involved in top management and development of this line of open source SIP servers: SER-Kamailio (formerly named OpenSER). All my living revenue was and still is generated from SIP world. Lot of things I would have liked to be reality by now, haven't happened yet, but it is about the time for some of them.
Therefore is more about feeling the directions where things are moving right now and trying to comment a bit and show where Kamailio can help at very best.
SIP over TLS will take off to the masses2010 exploded in terms of VoIP attacks and fraud. Weak protection provided by most widely used transport protocol in SIP, namely UDP, along side with digest authentication and raw text based IP communication are making the life too easy for attackers.
TLS makes the phone-to-server SIP signaling channel fully encrypted. Major SIP phone vendors such as
Snom showed a clear focus on security as well and many other SIP phones support TLS. As SIP is now more and more the first telephony line for many of us, we like to keep everything about it private. I don't think the ISP needs to know who I am calling and how long (yes, yes, I know they (say they) don't monitor it, right, yeah), it has to be only between the me and my ITSP because I have confidentiality as part of the contract with them for telephony services.
As for attackers, ITSPs can use free of cost self-signed certificates which will put quite some tough barrier to any kind of attack. For peering, ITSP-to-ITSP, I will expect many will start to allow traffic from other ITSP even they don't have preset peering agreement, but only based on a trusted certificate signed by recognized certificate authorities.
Regarding
Kamailio, since version 3.1.0, it has support for
asynchronous TLS communication (before this enhancement, Kamailio 3.0. with its new core architecture, was able to scale up to 80 000 active connections on an usual server hardware for residential user type of SIP traffic, now the numbers should go much higher). That rules out any alternative of SIP server out there by orders of magnitude.
IPv6, the time has arrivedMy
good friend Olle is on the barricades for several good months by now, trying to wake up in time the SIP world to be ready and start the switch to IPv6. At the SIPit in May 2010, I and Olle set up a Kamailio test bed to help implementers advance with their IPv6 support.
Kamailio had IPv6 support before TCP, so IPv6 is approaching as well 10 years. In the early 2000, IPv6 was a hot topic at least in the research area, so we added it and we improved over the years. Core and main modules are fully compliant with IPv6 on all transports layers, very well tested. With the main developer of IPv6 support in SER-Kamailio member of our development core team, you are in the safe boat for the future.
You like it or not, time for IPv6 is now -- and we are ready.
Re-empowering the SIP proxy modelBack in 2002, when I got involved in SIP, the communication model was 'the SIP endpoint has the power'. But somehow that was changed by Telecom and Mobile Operators adopting SIP and trying to replace legacy telephony services not by adapting communication model, but by enforcing legacy architecture to SIP.
The old telephony model was based on very dummy endpoints (the less by now 5 bucks microphone+speaker+dialpad wired to the switch or pbx, i.e., can and wire) and smart core network, but where are we today?
Look at the market trends, everyone is buying (hey Telcos, heads and (both) ears up!!!) SMARTPHONES. Do you think I will keep using your service with my $$$ device and cannot benefit of it for video,
3D holograms or what so ever fancy things may show up tomorrow because you stick to old Back-to-Back User Agent (B2BUA) model and those are not supported YET (if ever) by the two UA you placed in the middle, face-to-face to me and my callee?
You better reconsider that, let me and my caller negotiate the communication type, I am paying to you already IP connectivity fee, if you want my money for telephony, I should be able to decide my communication type. And I WANT to talk with my caller, not with a half of your dummy B2BUA.
I am not a B2BUA believer at all, I admit it has a good role for certain cases (e.g., gatewaying), but for the core of communication, that has to be completely removed. Look out there: Facetime, Facebook, GoogleTalk, Yahoo, Skype - the customer (client) is the smart side and that is reflected in service growth.
ITSP will have to adapt and let communication capabilities in hands of customers, or die. They will offer the communication infrastructure (like location services, routing failover, call hunting, hosted routing preferences, a.s.o.) and server side add-on services (that will act like another end point).
Not much to underline about Kamailio in this story, it is by definition transparent to UA capabilities. Do you have two SIP phones able to do 3D holographic calls, just wire them to Kamailio, dial and ENJOY!
SIP and WebIf we talk about telecommunications, today or in the future, it is SIP. But that is not all to satisfy current communications needs and the most important complementary service is the Web. Still to decide which one leads the real time communication, the fact is we want both and we need both.
Blending the both systems in one service is for sure a win bet. API defines the interaction for and between various very popular services these days, and these APIs are carried mainly via HTTP and Web2.0 technologies. Smart ITSPs will start offering such interfaces as well.
The latest version of Kamailio has an embedded HTTP server and a very scalable XMLRPC interface. Therefore you can jack directly into Kamailio via HTTP(S). Do you want to initiate a click-to-dial, check you missed calls or call history, verify your credit level? It is straightforward for you as ITSP to implement that with Kamailio and offer new attractions to your customers, with a single sign-on password for telephony and plus-value web-sip services.
Watch
this video of a presentation by Robin Rodriguez of
Ifbyphone at
Cluecon 2010 just to get how simple is to add new SIP-Web services to your ITSP offering with latest Kamailio.
That's all folks! I still keep few ideas I would like to be able to use in my pockets for later on, more likely suitable for 2012. What is your take regarding the evolution of SIP world in 2011?
Posts
