At RADVISION we’ve been dealing with the VoIP protocol stacks market for over a decade now, licensing the technology that enables voice and video over IP to whoever needs it.
Every once in a while we were approached by an operating system vendor who wants to embed a VoIP protocol stack into his operating system – usually around H.323 or SIP. The end result in that case is never really satisfying.
Why? I guess you can attribute it to several factors:
VoIP is too broad in its definition
Take SIP as an example. There’s just too much stuff you can do with it – it’s not only voice. Or video. Or even messaging. You can build a user agent with it. Or a gateway. Or a proxy. Or any other kind of a server that sits somewhere in the backbone of the Internet. Or the enterprise. Or a SOHO environment.
While such SIP stacks exist in the market (including RADVISION’s), they require a bit more work to operate than most other SDKs that come with an operating system.
Interoperability is hell
VoIP protocols are complex by nature. People can argue here, but I think I’ll have the upper hand. The simple truth is that once a VoIP protocol becomes popular, it gets more complex because more vendors will try to do more things with it, and the basic standard will get bloated up. It happened with H.323 and it happened with SIP. I am sure XMPP is no different – or will become no different if it ever increases to the ecosystem that SIP has today.
This complexity brings with it interoperability issues. And a lot of them. And dealing with them sometimes requires a bit of an extra effort – being able to modify messages and send some proprietary stuff to meet the needs of this or that system.
VoIP is usually only part of the picture
VoIP is the signaling side of the story. It comes hand in hand with the media side of the story, and the media isn’t provided with the operating system in most cases either – at least not in a way that works for bi-directional voice and video calling.
It means that the operating system vendor, who actually wants to provide a complete solution, is missing another piece of the puzzle and a piece that isn’t easy to complete, as it relies on low-level optimizations on the hardware architecture used – something that will vary a lot between vendors.
How do you succeed then?
So how can an operating system vendor succeed? By limiting his target audience. You don’t target server developers. Or people developing user agents. You focus on specific services. You limit interoperability. You reduce features.
Any other way isn’t going to cut it for an operating system. The problem with this approach though, is that you might end up with something that fits no one at all or that is too tailored for a specific system – both are the opposite of what an operating system stands for.
Android just came out with a SIP stack in their Gingerbread release. Windows Phone is rumored to have a VoIP solution of their own in a future release of the operating system. Will these solutions work? Probably yes. Question is – who is the target audience going to be.