This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Interoperability in IP Telephony and Unified Communications
As enterprise real-time communications moves from a hardware to a software architecture model, the issue of interoperability has come to the fore. Enterprise telecom departments traditionally have had to support multiple vendors’ PBXs within their networks, and have been frustrated by these systems’ limited ability to support common features and functionality across different vendor platforms. One of the key benefits of moving to a software model is supposed to be that this new model could more easily and effectively support a multi-vendor environment.
Mark Straton, senior VP at Siemens Communications, explains that customers have a “huge amount of leverage” when [interoperable software] systems are deployed on common off-the-shelf (COTS) hardware,” and he adds that there are “huge economies in getting [vendors] to specialize on components.”
The most important driver of the issue now is the entry of Microsoft and IBM into the communications space, and the role that these two companies’ systems are expected to play in this new software-based communications architecture. At VoiceCon Orlando in March, representatives of the two vendors shook hands and agreed to work on aspects of the interoperability challenge (more about that later in this article). However, the attitude held by several of Microsoft’s (and IBM’s) competitors on that VoiceCon stage can be summed up in a No Jitter comment posted by a commenter with the handle, “Bithead:”
They [Microsoft] have come to the market touting a unique software-based architecture, and in doing so they should be able to claim an openness that far surpasses that of traditional vendors. What I see is the opposite…. Ultimately we should be looking at architecture and how they drive the ultimate value for customers.
So what’s really involved in getting to a real-time architecture in which multi-vendor interoperability is possible and can support meaningful enterprise features and functions? And then what needs to happen to actually bring about such interoperability?
A big picture view would place communications systems within the larger context of the entire enterprise IT infrastructure. It envisions a world where there’s interoperability not only among different pieces of communications gear, but between communications gear and other business process applications. I’ve tried to give a general sense of these different levels of interoperability in a recent No Jitter blog post
However, this Feature article will be limited to three major interoperability challenges within the communications level of the architecture, and won’t touch on the “levels of interoperability” challenge in the blog post cited above. We’ll look at the multi-layered challenge in future coverage, but there’s way more just at the communications level than you can deal with in a single article.
The three areas of focus for this article are:
1.) The effort to use SIP to standardize legacy PBX functions in new IP-based PBXs.
2.) The issue of codecs, and their implications for interoperability.
3.) Presence federation.
These are not identical kinds of challenges: Number 1 is a pretty straightforward problem of writing standards that will cover implementation scenarios such that a vendor’s assurance of standards compliance will, in the real world, mean that the vendor’s product actually does “plug and play” with another vendor who claims their product also meets the standard. Actually, this is a straightforward statement of the problem, but the problem itself is anything but straightforward, as you’ll see.
Number 2 has to do with how interoperability is playing out in the real world, in one specific area where clear standards exist and are, in fact, widely implemented in an interoperable fashion--and where there is, nevertheless, debate over whether one vendor (Microsoft) is violating some tenets of interoperability.
Number 3 represents an area where there an ongoing effort to attain interoperability, but where there are also serious underlying technical/conceptual hurdles to overcome before a framework for multi-vendor interoperability can even be realized.
[You can discuss/comment on this article in the Comments section