Ok, I’m back from a period of inward-facing egocentric activities, now I’m ready to go to outward-facing egocentric activities (like this blog). I have updated my profile and although SIP will continue to be an important part of what I post about, I will broaden the scope of the topics I post on.
I thought I’d start out on SIP interoperability. An interesting topic that I have touched before from the angle of eco-systems (Competing-eco-systems-ims-ser-asterisk). As I see it, at the bottom of many of the interoperability fights are the different ways of ensuring interoperability:
- One approach is the classic telco approach, where a standardization body specifies everything in detail and an independent certification body offers test suites and a certification stamp. This approach, however, stifles innovation as adding a new element to the standard is a very heavy process;
- The second approach is the “de-facto” standard. Either as an excepted de-facto standard, or through a company with a significant market power seeing a self-serving purpose in bringing a proprietary technology into a standardization body and make it a standard;
- The third approach is to build flexibility into the standard (also called an “open system”) and then let “Brownian motion” to sort out the interoperability through peer to peer testing;
Under the certification approach, it’s important for the actors to get their features/requirements into the standard when it’s made. Also, from an operations point of view, certification makes it important to reduce the number of boxes needed to be upgraded when a new version of the standard comes out. The rigidness in the approach reduces the possibilities for slowly upgrading independent parts as a box that has not yet been upgraded will throw an error if it finds something it doesn’t understand. However, the brownian motion approach relies on a flexible core standard and an important implementation element is that “if you don’t understand it, ignore it.” The rigidness simplifies interoperability, but restricts your ability to add additional value on top to your customers.
In IETF, these differences have been amusing to watch, especially in the IMS SIP vs IETF SIP discussions where people with telco background wanted SIP headers and drafts for any feature they could dream up, while the “old” SIP folks wanted to keep the core of SIP as lean as possible and rather let the user clients implement new functionality that could be negotiated between the clients without the SIP elements in between really needing to understand the new functionality.
In my eco-system post, I referred to Tim Berners-Lee and the notion of an “open system” and SIP is such an open system. Innovation is the winner, but immediate interoperability suffers as you get into a “everybody needs to test with everybody” mess.
So, what do you do as a vendor when you want to add a new feature to your product because your customers need it and there is no publicly available standard, no de-facto standard, or maybe not even another example out there? That’s the topic of my next post.
RSS - Posts