Most communication technologies follow a fairly predictable trend: first, forward-thinking researchers develop prototype of the technology. Then, pilot deployments demonstrate the viability of the technology. After the utility of the technology is proven, the protocols for multiple interoperable implementations are standardized. If the technology is successful, the early pilot deployments begin to gateway to each other (and a broader community) using the standardized protocols. Eventually, the proprietary islands disintegrate, leaving behind a fully standardized solution.
And that’s when the exciting stuff starts to happen.
One of the clearest examples of this is email – the earliest days of email began with dial-in bulletin board systems and isolated corporate email systems. The IETF standardized the Simple Mail Transfer Protocol (SMTP) in 1982; and, gradually, the proprietary systems gatewayed to the standardized protocols. Eventually, the islands faded away – today, just about all email in the world is exchanged using SMTP. Long gone are the days when you had to worry about having an account on the same email service to be able to communicate with your buddies; when someone says they have “email,” you assume that you can communicate with them using whatever email system(s) you happen to use.
We’ve seen similar migrations in the World Wide Web (distributed hypertext systems trace back to Douglas Engelbart’s work from 1968), with standardization coming about a decade later than email. And we’re in the same curve (albeit much earlier) for Presence and Instant Messaging (think ICQ, AOL, and Yahoo followed by XMPP and SIMPLE), and realtime Voice and Video over IP.
What’s exciting is how quickly we’re getting to the stages of gatewaying the proprietary islands to standardized protocols: last week, Skype announced its plans to gateway its own (very large) voice-over-IP island to the rest of the world.
However, unlike the other technologies I mention above, I have noticed a worrying trend in deployments of SIP to add proprietary extensions to the protocol – most often, in ways that interfere with proper interoperation with actual standard clients. The examples are manifold.
A major operating system vendor has incorporated what they claim to be “SIP” into a number of products, but uses a format for presence that is completely proprietary, and cannot interoperate with standard clients. These products also employ a proprietary federation mechanism that is fundamentally incompatible with the SIP inter-domain routing model.
Another major vendor who sells “SIP” PBXes abuses the SIP events mechanism quite egregiously by sending message waiting indications to every registered phone, regardless of whether those indications are supported by the device (and, conversely, sells phones that never subscribe to receive message waiting indicators). The same vendor uses the same kind of unsolicited (and unauthenticated) notification to cause the phones to reboot – meaning one person with a 10-line perl script can knock an entire enterprise’s voice network over whenever they want to. And I have personally had to modify clients to deal with the fact that this vendor’s products send certain unwanted (and largely useless) types of media packets, even when the SIP negotiation has indicated they should not be sent.
The story repeats itself many times in the SIP world – current deployments have multiple, non-interoperable ways of sending DTMF (TouchTones®) with SIP; bridged-line appearance; directed call pickup; and several other features.
Why, you may ask, is this any worse than the proprietary islands? Well, back when these vendors had their own proprietary systems, no one expected things to work together. You bought an entire system from a single vendor, and never expected things to work with other vendors’ equipment. But now, when vendors decide to implement non-standard protocols and call them “SIP,” they raise expectations that their equipment will work with systems from other vendors who also claim to implement “SIP.” And when things go off the rails, everyone starts getting the impression that “SIP doesn’t work.”
As someone who has spent well over a decade making sure that SIP does work, I find this very frustrating. Basically, you have vendors implementing proprietary protocols inspired, to varying degrees, by the SIP standard. And these implementations get labeled “SIP,” when they’re not. And we know they don’t work (or, even worse, sometimes work and sometimes don’t) with actual SIP devices.
My point is: standards are pretty much an all-or-nothing proposition. If you’re going to claim to follow a standard, you’ll do everyone a favor by following that standard. If you’re going to do something non-standard that is somehow based on SIP, then what you have is a proprietary protocol inspired by a standard. And that’s okay, as long as you don’t hold it out to be anything other than a proprietary protocol.