Why there isn't a successful SIP certification program
Posted by Robert Sparks on Tue, Dec 01, 2009 @ 12:47 PM
Over the last several years, I've had many conversations about building a certification program for SIP, including trying to define a few. All of those conversations have ended either in frustration or the conclusion that such a certification program is not the right thing to build.
The proponents of such a program came in each time with a lot of energy and excitement. The conversations got tough when we looked closely at what the program would actually certify. What do you test? What do you require a passing system to do? Each time, it turned out that the proponents really had a single, focused use of SIP in mind (usually simple telephony replacement). The motivation statements tended to look like "I want to buy a phone from
and have it work with my service". The participants quickly became mired in arguments about what the tests to ensure that should cover. They discovered that they really wanted to test for a lot of end-user visible behavior that the SIP specification itself leaves undefined.
As we tried to work further through the details, we'd frequently see arguments to profile the protocol. In very early conversations, there was pressure to not require (or even penalize) the implementation of SIP over TCP or the use of the 100rel/PRACK extension, usually driven with a "nobody really does that" argument. It's worth noting that both of those are required in many deployments today. The folks focusing on simple telephony didn't want to be burdened with testing the parts of the protocol needed for presence and vice-versa. The business telephony oriented people had an entirely different idea of what a program should look like than the single-line replacement oriented folks.
In short, what people really wanted was a certification program for their particular application, not for the protocol itself. Unfortunately, at the time, I don't think anyone involved realized that was the root of why such programs weren't coming together.
With that realization, I've become even more convinced that a generic SIP certification program isn't feasible - it wouldn't produce a useful tool for making our ecosystem(s) better. The energy would be better focused on how the protocol is used rather than trying to certify implementation of the protocol itself.
There are a few new programs under discussion now, in the SIP Forum and other organizations, which are trying the approach of defining certification programs for an application. Those conversations seem to be going further than the earlier attempts, and I think some of them have a chance of succeeding.