Like everywhere else in the world of technology, the high-visibility suites of videoconferencing, voice over IP, instant messaging and “presence” services are built upon arcane sets of standards.
As elsewhere, these are often competing sets of standards. While, fortunately, the end user remains blissfully unaware of the underlying architecture, it doesn’t mean such matters are unimportant. And victories on the standards front can have significant implications down the road: witness the collapse of token ring and how that ultimately triggered the re-architecting of virtually every corporate network.
Nothing can turbocharge existing momentum more than having a major vendor cast its lot with one side. Barely noticed amid the myriad issues surrounding the launch of Microsoft Corp.’s Windows XP operating system was the tectonic shift from H.323 to Session Initiation Protocol (SIP) as the signalling protocol for its new converged messaging application called, appropriately and simply enough, Messenger. (Check out the SIP Center Web site at www.sipcenter.com for detailed information about the protocol.)
Just as the use of H.323 did not make or break Microsoft’s legacy NetMeeting product, neither does the use of SIP have a gargantuan impact on the Messenger product. Yet, the overall quality of Messenger and, thus, its acceptance rate ultimately will have an impact – positive or negative – on the acceptance of SIP. Thus, we need to look closely at the product as a whole.
To understand Messenger, though, one needs to understand NetMeeting. Launched as a new-generation messaging platform, NetMeeting met with limited success. Being forced to use H.323 as its signalling protocol certainly did not help. As SIP promoters will tell you, H.323 has complexity levels that are too high and flexibility levels that are too low. Any application, then, that is forced to use it gets to carry that same baggage.
But what was really wrong with NetMeeting was not the fault of H.323 but, rather, the fault of Microsoft. Specifically, its voice-over-IP endpoint latency was so inordinately high as to make it virtually useless.
How did I find this out? Microsoft said so. (I’ve since proven it to myself.) In its inimitable way, Microsoft warmed up analysts covering XP by self-bashing its previous-generation products. In so many words, Microsoft said NetMeeting was bad because its latency was excessive but that Messenger under XP fixed all that and exhibited remarkably low latency.
We looked at Messenger on XP and Windows 2000 (Microsoft brought out a version for that platform at the same time XP was launched), looked at NetMeeting’s H.323 performance and ran identical benchmarks on H.323 and SIP IP phones from Siemens.
True to Microsoft’s word, the NetMeeting latency was through the roof and the Messenger latency – not only on XP but on Win 2000 as well – was quite impressive. Those particular measurements were as good as or better than the IP phones. However, the overall experience as measured in terms of voice quality did not match the IP phones.
Network executives might want to consider Messenger as an auxiliary method to deliver low-cost voice over IP, but they’d do well to take pause and realize that, contrary to what Microsoft seems to be implying, delivering quality voice over IP hinges on much more than a single latency benchmark number.
Tolly is president of The Tolly Group, a strategic consulting and independent testing company in Manasquan, N.J. He can be reached at [email protected] or www.tolly.com.
