- A TechNote on Unified Communications
- Michael Finneran, President
- dBrn Associates
One of the hard realities of unified communications (UC) is that most organizations are building it largely on top of an installed base of legacy equipment. What's more, that installed base is often cobbled together from a variety of vendors as the result of separate purchasing decisions made by business units or because of mergers and acquisitions.
All of this screams for the requirement to have federation, or interoperability, among UC systems so all UC capabilities work regardless of which users are on what systems. Unfortunately, UC interoperability is in its nascent stage today, with virtually no cross-platform compatibility. Will this get resolved - and how?
The Situation Today
Because very few of us are lucky enough to have infinite budgets at our disposal to rip-and-replace our way to UC, we will very likely have to build our UC solution on a polyglot assemblage of multivendor solutions. However, the real power of UC comes about when presence, collaboration and the rich UC suites provided allows all users at any location to freely interconnect. As time goes on, we will also want to do the same with key suppliers and business partners, regardless of what UC platforms they are using.
But the state of UC interoperability currently doesn't allow all this mixing and matching. Microsoft and Cisco each have the ability to federate their own implementations, but not to each other or to anyone else, for example.
Industry Forum Efforts
The UC Interoperability Forum (UCIF) is attempting to address the federation issue. However, the UCIF is heavily weighted toward Microsoft and its partners, such as Polycom, HP, AudioCodes and Plantronics. The other major UC vendors, including Cisco, Avaya, IBM, Siemens and NEC, are all noticeably absent, and the only name from the IP PBX world that shows up on UCIF's member roster is ShoreTel.
Make no mistake about it, herding this bunch of cats will be no easy matter. Many like to draw an analogy to the uncontested success of the Wi-Fi Alliance, but that is a very different business. First, the Wi-Fi standards address Layers 1 and 2 of the OSI Reference Model; UC interoperability affects the entire stack, up through Layer 7. So you not only have to worry about getting your message from Point A to Point B, C and D; you have to ensure that the video or audio codecs are compatible, the collaboration and screen-sharing tools are in sync and so on.
Even more importantly, the members of the Wi-Fi Alliance had to work together for the whole thing to fly. No one would have invested in wireless LAN infrastructure equipment that only worked with client devices made by one supplier or a select group of suppliers, so Alliance members had to sit down and hammer out their differences.
The UC providers, on the other hand, see themselves entirely as competitors, where one party's gain is seen as another's loss.
How to Federate?
Also there's a question of "how" to federate the various systems. Should each implementation interface directly to every other, or should there be some "grand federation in the cloud" where one service effectively translates among all of the various implementations. My colleague Russell Bennett discusses the options and advantages and disadvantages of federation in some detail in this UC Insights blog.
The message is that in planning for UC, it's important to look beyond immediate needs to the long-term issues. A single UC deployment has value, but business transformation based on UC is a function of Metcalf's Law, which says the value of a communications network is proportional to the square of the number of connected users. So in planning for UC, federation should be front and center in your thinking.
This TechNote is brought to you in part due to the generous support of:
All of this screams for the requirement to have federation, or interoperability, among UC systems so all UC capabilities work regardless of which users are on what systems. Unfortunately, UC interoperability is in its nascent stage today, with virtually no cross-platform compatibility. Will this get resolved - and how?
The Situation Today
Because very few of us are lucky enough to have infinite budgets at our disposal to rip-and-replace our way to UC, we will very likely have to build our UC solution on a polyglot assemblage of multivendor solutions. However, the real power of UC comes about when presence, collaboration and the rich UC suites provided allows all users at any location to freely interconnect. As time goes on, we will also want to do the same with key suppliers and business partners, regardless of what UC platforms they are using.
But the state of UC interoperability currently doesn't allow all this mixing and matching. Microsoft and Cisco each have the ability to federate their own implementations, but not to each other or to anyone else, for example.
Industry Forum Efforts
The UC Interoperability Forum (UCIF) is attempting to address the federation issue. However, the UCIF is heavily weighted toward Microsoft and its partners, such as Polycom, HP, AudioCodes and Plantronics. The other major UC vendors, including Cisco, Avaya, IBM, Siemens and NEC, are all noticeably absent, and the only name from the IP PBX world that shows up on UCIF's member roster is ShoreTel.
Make no mistake about it, herding this bunch of cats will be no easy matter. Many like to draw an analogy to the uncontested success of the Wi-Fi Alliance, but that is a very different business. First, the Wi-Fi standards address Layers 1 and 2 of the OSI Reference Model; UC interoperability affects the entire stack, up through Layer 7. So you not only have to worry about getting your message from Point A to Point B, C and D; you have to ensure that the video or audio codecs are compatible, the collaboration and screen-sharing tools are in sync and so on.
Even more importantly, the members of the Wi-Fi Alliance had to work together for the whole thing to fly. No one would have invested in wireless LAN infrastructure equipment that only worked with client devices made by one supplier or a select group of suppliers, so Alliance members had to sit down and hammer out their differences.
The UC providers, on the other hand, see themselves entirely as competitors, where one party's gain is seen as another's loss.
How to Federate?
Also there's a question of "how" to federate the various systems. Should each implementation interface directly to every other, or should there be some "grand federation in the cloud" where one service effectively translates among all of the various implementations. My colleague Russell Bennett discusses the options and advantages and disadvantages of federation in some detail in this UC Insights blog.
The message is that in planning for UC, it's important to look beyond immediate needs to the long-term issues. A single UC deployment has value, but business transformation based on UC is a function of Metcalf's Law, which says the value of a communications network is proportional to the square of the number of connected users. So in planning for UC, federation should be front and center in your thinking.
This TechNote is brought to you in part due to the generous support of:
 |
 |
 |
UC interoperability is indeed a major issue, and, while SIP will provide some of the tools and infrastructure, that's only a starting point.
Of course, this situation is not fundamentally different from interoperability of VoIP implementations, which is still being resolved.
Perhaps one of the interim steps will be to implement third-party implementations for management and translation, as has been the case with VoIP?
Also, the newer generation of Session Border Controllers might offer some paths for interoperability with capabilities like video transcoding.