The Need For Interoperability

One of the major discussions in UC has to do with the need for interoperability. The legacy voice world is highly proprietary, built around PBXs that speak vendor-specific protocols understood only by that vendor's telephones. A lot of people like to compare the PBX to the mainframe computer, and suggest that, just as in computing, the end station will become untethered, hardware will become commoditized, and everything will reside in software. That may, in fact, turn out to be the end state, bu

Eric Krapf

June 5, 2008

3 Min Read
NetworkComputing logo in a gray background | NetworkComputing

One of the major discussions in UC has to do with the need for interoperability. The legacy voice world is highly proprietary, built around PBXs that speak vendor-specific protocols understood only by that vendor's telephones. A lot of people like to compare the PBX to the mainframe computer, and suggest that, just as in computing, the end station will become untethered, hardware will become commoditized, and everything will reside in software. That may, in fact, turn out to be the end state, but we're nowhere close today. And the interoperability aspect is even more challenging than the basic software issue.This vision actually predates the entry of Microsoft and IBM into the market, but the presence of these two software giants has naturally accelerated all the talk. The issue really took off at VoiceCon Orlando last March, when, during a plenary session, Microsoft and IBM representatives shook hands and agreed to work toward interoperability in some aspects of federation between Microsoft Office Communications Server (OCS) and IBM Lotus Sametime.

The biggest challenge to the fundamental migration from a hardware architecture to a software architecture is inertia, which is a much more powerful force in the voice world than it was and is in the computing world. A post on No Jitter today sums it up:

The historic tendency in the voice world -- unlike, say, PCs -- is to ride the gear until it drops, which is more like a decade than the five years it takes to depreciate it fully. Unless capital budgets for voice suddenly open up (seen any pigs flying lately?) or TDM support just disappears, a lot of true IPT deployments -- meaning new PBXs or the equivalent, and new station sets -- have been and will continue to be greenfield and places where the old stuff just quits.

So while enterprises may not love the proprietary model, they love the fact that the gear is paid for and works.

But let's jump ahead a few years, because eventually the gear will stop working, or at least will get so expensive to support that the cost/benefit will shift; or the PBX vendors will finally end-of-life/end-of-support the stuff, as is finally happening to the original voice mail systems that still are chugging away in many enterprises. When that happens, the move toward software-based systems will be almost irresistible. The question is how much of the interoperability issues will be resolved by then.

Today's IP telephony and Unified Communications software falls far short of the mark when it comes to multivendor interoperability. I recently completed a feature-length article on this topic over at No Jitter, where I went into a fair amount of detail regarding the obstacles to interoperability. Basically, the effort to use the Session Initiation Protocol (SIP) to build vendor-neutral systems that provide full legacy feature sets for PBXs -- well, let's just say that effort is struggling.

Meanwhile, Microsoft's competitors are attacking Microsoft for using a proprietary codec in the endpoints that talk to OCS. Microsoft says it's a better codec that provides a higher quality of experience in a wider range of network environments (especially the public Internet). The competitors say Microsoft is just being Microsoft.

Finally, there's the issue of federated presence. Presence is widely considered to be the heart of the UC system of the future. The presence engine is supposed to know the status of all the system's users at all times, and manage how that information is made available to others. If those "others" are all using the same UC system as the person whose presence we want to know about, everything's fine. If those "others" are on a different system, the presence engines have to federate, and that can be a complicated and difficult task. Interoperability in this environment is nowhere close, and even the aforementioned Microsoft-IBM effort is fairly limited in scope.

So if you're waiting for a Unified Communications environment that looks and acts like the computing environment of today, don't hold your breath. Such an environment may emerge eventually, but it's a long way off.

About the Author

Eric Krapf

Eric Krapf is General Manager and Program Co-Chair forEnterprise Connect, the leading conference/exhibition and online events brand in the enterprise communications industry. He has been Enterprise Connect.s Program Co-Chair for over a decade. He is also publisher ofNo Jitter, the Enterprise Connect community.s daily news and analysis website.
Eric served as editor of No Jitter from its founding in 2007 until taking over as publisher in 2015. From 1996 to 2004, Eric was managing editor of Business Communications Review (BCR) magazine, and from 2004 to 2007, he was the magazine's editor. BCR was a highly respected journal of the business technology and communications industry.
Before coming to BCR, he was managing editor and senior editor of America's Network magazine, covering the public telecommunications industry. Prior to working in high-tech journalism, he was a reporter and editor at newspapers in Connecticut and Texas.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights