Unified Communications

08:12 AM
Eric Krapf
Eric Krapf
Commentary
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

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

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.

Comment  | 
Print  | 
More Insights
Cartoon
Hot Topics
White Papers
Register for Network Computing Newsletters
Current Issue
2014 State of Unified Communications
2014 State of Unified Communications
If you thought consumerization killed UC, think again: 70% of our 488 respondents have or plan to put systems in place. Of those, 34% will roll UC out to 76% or more of their user base. And there’s some good news for UCaaS providers.
Video
Slideshows
Twitter Feed