I have wanted to write this post for a while. For a long time I have been concerned about the competitiveness of the SER/OpenSER eco-system in the larger SIP picture.
Let’s look at the big picture: SIP has been established as the preferred signalling protocol for real-time sessions like voice and media. It bears the characteristics of other open technology systems like TCP/IP and the World Wide Web (see Aijt Jaokar’s blogpost on Tim Berners-Lee’s 3GSM presentation for more on open systems). This means that SIP is itself ignorant to what you use it for; it enables innovation instead of restricting it to the “owner’s” ideas of what it should be used for. Open-source projects is an important part of realizing the potential of open technologies.
SIP has been standardized as part of IETF’s work. When 3GPP and the mobile world decided to adopt SIP as the signalling protocol in 3G networks (IP Multimedia Subsystem aka IMS), the scene was set for tensions. The history of mobile technologies is full of “ceiling technologies” (again Tim Berners-Lee expression), technologies that put restrictions on how to use it, thus preventing the technology to be used for other things than what the creators conceived. I won’t go into the fight (still going on) between the SIP open technology proponents and the more ceiling technology proponents, but look at the IETF sip and sipping mailing lists if you are interested…
This has made the backdrop for an interesting dynamic. A successful open technology has the characteristic that it creates an eco-system of innovation. By virtue of being adopted by many people, as well as allowing innovation, innovative people will use the technology for own commercial and non-commercial activities. The fight of the open technology proponents is to keep SIP open and to prevent the SIP eco-system from splitting into independent eco-systems where innovation will not cross. (However, their efforts seem to more effectively create a split.)
I’ll maybe write about the necessity and challenge of keeping SIP as an open technology in another post. Here I will concentrate on the eco-systems I see and why we should bother.
Obviously, IMS creates an eco-system for existing telco-vendors and start-ups. Vendors like Nokia, Siemens, Hewlett-Packard, Ericsson, Nortel, etc etc have their IMS software components and “service delivery platforms”. The challenge for all is the lack of compelling services in IMS (and probably the cost of rolling out). Operators and vendors try to spur innovation by inviting start-ups and 3rd party software developers to develop on IMS (ex. Vodaphone’s partner community and Hewlett-Packard’s Mobile Bazaar). The cost of developing for IMS, in competence, development software, lack of IMS handsets, as well as the lack of IMS roll-outs (i.e. an actual market) makes it not a too attractive business proposition. Thus, most companies developing for IMS also develop for IETF SIP (also called pure or naked SIP).
The second eco-system, IETF SIP innovation is what most VoIP bloggers blog about. In fact, many of the bloggers are also SIP entrepreneurs themselves. Their business models are innovative and they use Internet principles of marketing and distribution, not through operators. Some do both IETF SIP and IMS SIP and develops “split brain”, not necessary due to the technical challenges, but because their business model will be split in two.
A third eco-system without the glossy marketing of end-user SIP services is the IETF SIP innovation where SIP is used as a backbone for core real-time media networks. SIP is used for interconnect, bridging the old PSTN world, creating new ways of “dialling” a SIP user (ex. ENUM), as well as for signalling of all kinds of non-VoIP related stuff. This area is murky and under-exposed, but innovation on these core elements of how to use SIP and how to use SIP in connection with other web technologies can potentially bring revolutionary changes.
A fourth eco-system is mostly associated with Asterisk. Even though Asterisk uses IAX (and have a bit shaky SIP implementation), Digium has done lots of things right and have managed to create a large eco-system around the basic idea of an open-source PBX. Pingtel’s sipXpbx has been less successful in building a community around it.
So what do these eco-systems have as open-source tools? Many innovators start out from “scratch” when building something, using a SIP stack like pjsip or reSIProcate. Asterisk is an obvious candidate to build on top of for small-scale PBX-like applications (or larger scale by distributing across many Asterisk installations). However, the more of the basic stuff already done, the more people can concentrate on innovation. In the IMS SIP and the IETF SIP worlds there are no obvious, de-facto open-source components that give you a complete infrastructure for innovation (components are available though, see further below). That is bad news for both IMS and IETF SIP.
The question is whether this will change or whether the fragmentation in the SIP eco-system will continue (or fragment even more). What do currently SIP innovators have available except for SIP stacks and Asterisk? Obviously, SER and OpenSER can be (and are) used for many innovative projects. Also, most of the IMSish SIP server providers offer developer licenses and programs. And the OpenIMSCore project (based on SER) sponsored by FOKUS has in a very short time gathered a lot of activity. However, there are some important open-source elements missing, like an application server (in this context an IMS application server). This gap is filled by Mobicents, a JSLEE-compliant open-source IMS application server.
On the IETF SIP side, SEMS (SER Media Server) fills the gap with a simple script-based/Python/C++ plugin programming model. However, all these are pieces that need to be pieced together before any innovation can be built on top. It requires deep understanding of SIP and it is not obvious what to choose. I believe the appeal of Asterisk has been that it is “good-enough” for lots of different things. We don’t really have that for large-scale SIP-based services. The attitude is more to polish things into perfection, something you don’t want to show others because you build your business on it.
What is my dream?
- A modularized, highly scalable SIP proxy core with the basic IETF RFC3261 functions with monitoring, failover, and redundancy built in
- Clearly defined interfaces (could be in the form of programming interfaces or integration documentation) for integration with IMS functions, applications servers of various flavors (SIP CGI, SIP Servlet, JSLEE, ParlayX, as well as non-standard programming models like SEMS)
- Ability to use these interfaces to build extensions to the SIP proxy so it can fulfill different functions. This can be IMS CSCF functions, presence capabilities etc. This will create different distributions or flavors of the basic IETF SIP proxy
- Test tools, clients, and that work across IMS and IETF SIP enabling developers to quickly test their applications
Of course, all these should be open-source and people who despise IMS should be allowed to ignore IMS parts, and the projects should be independent, though collaborate on the interfaces, as well as share best practices that everybody needs.
We are in a position to do this: SER/OpenSER have powerful capabilties suitable, and SEMS is very well integrated, there is a dialog between Asterisk and SER/OpenSER developers, OpenIMScore is based on SER, and people and projects are working on these various components.
However, we are struggling with two things:
- Commercial actors have no interest in sharing their best practices (or even acknowlegde their open-source software) as they are courting operators of various flavors with their commercial varients of their open-sourced software. This is across the board and puts a lid on innovation as everybody must integrate and build the basic infrastructure before they can innovate
- There’s a cultural divide between IMS and IETF people, and I don’t see the mutual respect needed for such collaboration. SIP implementors are not really talking together and creating shared goals. And then throw in some good old personal conflicts…
The lack of a robust and de-facto open-source development platform for services that cross the IMS/IETF chasm splits the SIP eco-system, hinders innovation, and ensures that end-users will suffer in the years to come. The commercial interests in getting SIP to work in the mobile world are so big that development will happen. How is an open question, but SER/OpenSER and other IETF SIP proxy implementation may end up as a niche open-source component used by purists unless we start seeing the bigger picture. Comments and suggestions are very welcome!
RSS - Posts