The biggest interoperability challenge of all is probably not an immediate concern for most enterprises, but it's critical to the future architecture of Unified Communications. Today, companies worry about different vendors' PBXs talking to phones and to each other, as well as to applications such as contact centers. But the major bone of contention going forward into UC is presence and the need to "federate" presence engines.

Why is presence so important? As explained by Akiba Saeedi, Program Director, Unified Communications and Collaboration Software for IBM's Software Group, "Presence is the heart and soul of the [UC] system."

But while the presence engine may sit at the heart of the new architecture, it will be receiving information about users from multiple systems—calendar applications, workflow apps, the cellular network, and of course the device formerly known as the PBX. And several of those sources may be willing and able to offer presence information on a given user at the same time. And while the presence function may be the heart of the system, the enterprise may actually have multiple boxes maintaining presence state information, and these boxes need to be in synch. Oh, and the enterprise will want to share that presence information with other enterprises or service providers.

Actually, that last point is the (relatively) easy part of presence federation. Inter-domain presence uses SIP/SIMPLE to reconcile a single user's multiple identities in separate domains, say an IM service like Yahoo and your corporate messaging system. What's more difficult is when everything is happening within the same domain where you have multiple different servers maintaining presence state, and each one thinks it holds the definitive information about the current availability state of, say, don@sturdy.com. Explains Microsoft's Eric Swift:

It's difficult to have 2 and synchronize, because you end up with 2 versions of the truth. They get out of synch, updates collide and that's a hard problem that's been looked at across many different technical areas, and you run into the same problems; one of them is, which version of the truth are you going to believe? And what happens when they get out of synch? And with something like realtime presence, boy, getting out of synch can be critical.

And then you have the developer standpoint. Say I'm a corporate developer and I want to build a new application, and I want to get presence, who do I get presence from? Is there a single repository I can go to, or do I have to go to 3 different places because I need to get the PC presence from this system, and I need to get the phone presence from that system, and I need to get the login state of that application from another system? And that becomes a burden for the corporate developer. So you have that issue: If I'm a corporate information architect, if I'm going to create a presence architecture, do I want to have 2 versions of the truth? Do I want to have 1 and tell everybody to hang off that? That's a hard conceptual thing to work through.

An IETF effort is under way to try and work out this problem, with the technical challenges laid out in detail in an Internet Draft authored by Jonathan Rosenberg of Cisco and Avshalom Houri of IBM. Among the issues they address is the problem of whether to have a central hub of presence or allow multiple instances to be distributed in different places.

And then there's an additional level of detail to the whole issue of presence federation/interoperability, one that roughly parallels the SIP/PBX-feature challenge. It'd be a whole lot easier for multiple vendors' systems to exchange presence information if there were only a few basic presence states, like you probably have now with your public network IM service: On the basic configuration of my Yahoo IM, I can be Available, Busy, Stepped Out, Be Right Back, Not at My Desk, or On the Phone. And there's probably even one too many there: Stepped Out is pretty similar to Be Right Back.

However, just as PBX feature/functionality gets hairy when the features get more complicated and task-specific, the same is true (though for different technical reasons) when you get to Presence. And, as with PBX features, the equipment vendors are going to want to use fine-grained functionality (i.e., detailed presence states) as one product differentiator. Eric Swift says the market wants such granularity:

"I was in Wall Street a couple weeks back, they have a turret phone system there, [with] several different presence states beyond what a normal phone has. It has not only on hold or off hook, or what have you; it has the on-intercom, or on a private call or in a public call. Got all those weird states. You probably don't want to push all those states into your central presence engine."

Likewise, manufacturing or retail customers might want presence states that say, On The Factory Floor or At Cash Register 15, for example, Swift adds. "Does that make interop harder? Of course, because then you don't have a pre-defined [rule]: There are 7 different presence states that are acceptable across the world. You have to say: There are N number of presence states, and here's how you figure out what they are, and here's how you deal with them once you figure out what they are, and you then relate to them in a standard way as opposed to having them pre-defined in a cookie-cutter fashion. And that makes it a little more difficult to interoperate, even with a standard. But I think it's a necessary thing if you want to have practical and relevant flexibility as a platform."

And although this article isn't going into detail on interoperability between communications and business applications, it's worth noting here that such multi-layer integration will further complicate presence federation. "When people want to deploy presence, they're not just looking at, are you offline and I'm online," noted Anwar Siddiqui, manager of Avaya Labs' chief technology office. "Companies want to pull that [presence information] together and expose it upwards to the business applications."

At VoiceCon Orlando 2008, Avaya announced its approach for doing this: Its Intelligent Presence software which, according to the vendor, "aggregates telephony, desktop and application presence information from Avaya and third party sources, such as those from Microsoft, IBM and others, and bridges industry standard protocols including SIP/SIMPLE and XMPP."

Which brings us to the really tough issue: The major vendors all want to own presence. Christian Szpilfogel, who's in the office of the CTO at Mitel, echoes Eric Swift's comments about the application environment. Szpilfogel explained that the advantage of owning the "call" (in whatever medium) is that the vendor who owns the call will likely own all of the interworking behavior, and effectively owns the addressing space of the customer, which in turn is going to be what's used to tie collaboration more deeply into the rest of the network.

All of which brings us to the Interoperability discussion that took place at VoiceCon Orlando, and the commitment that Microsoft and IBM made to work toward interoperability of OCS and Sametime, respectively. Since the March on-stage handshake between Eric Swift and IBM's Pat Galvin, the two companies have been talking, and Akiba Saeedi said recently that, "I absolutely remain hopeful that we're going to make significant progress here."

Saeedi didn't want to go into the details of what's been discussed for a planned interop demo at VoiceCon San Francisco in November. Eric Swift of Microsoft said, "What we're following up on is discussing how we can demonstrate between Sametime and Office Communications Server, inter-domain federation. We have a lot of clients who want to do that, who either work with other companies or work with other business units on different domains, that they want to be able to use our product next to Sametime." So, in other words, the interoperability work between Microsoft and IBM will only address the (relatively) easier issue around presence federation, that of inter-domain federation.

What's at issue for Microsoft-IBM integration at this level? According to Eric Swift, "What it comes down to basically is when they send an instant message, they send the message along with the initial request, whereas we send the SIP message which says, Hey, we want to have a conversation; once we get that acknowledgement, then we send the instant message along with it. Those two options are both supported within the standard, and so we've just got to decide, do we each do both, do we move to one, or does one of us do both and one of us stick with our status quo?

"This is not rocket science," Swift concluded. "This spec is pretty well understood. It's just a matter of deciding on the approach and then testing it and agreeing to support it, that's all."

It may not be rocket science, but any interoperability work like this is going to involve a lot of diplomacy, which is often much harder than rocket science.

As for intra-domain federation, while it may be a technical problem that's still unsolved, it's clearly an important one for users who want their internal systems to be able to talk to each other. To the extent that either Microsoft or IBM believes they'll gain market share at the other's expense as enterprises move more deeply into UC, it could be in their interest to have an interoperability standard. Assuming that enterprise migrations will take years, not weeks or months, it's almost certain that enterprises will own multiple vendors' systems during the course of their migration, and less interoperability means less opportunity to capture the benefits the enterprise is seeking by going to UC in the first place.

CONCLUSION

So interoperability challenges come with different levels of urgency, technical difficulty, and likelihood of vendor intransigence. When it comes to basic communications systems, it's worthwhile to keep in mind something Mark Straton of Siemens noted, namely that large voice systems typically have a 10-15-year life cycle: "Customers don't replace their fundamental communications systems until they wear out," he said.

This isn't just because those systems are expensive (though of course they are). It's because they work, and making things work in real time is another degree of difficulty from the integration and interoperability challenges that have occurred in other parts of the network. It's a challenge that the industry is beginning to explore and attempt to define; but we can't expect solutions any time soon.

Eric Krapf is editor and lead blogger for No Jitter, and is also program co-chairman of VoiceCon.

[You can discuss/comment on this article in the Comments section here.]

Here are some handy URLs and No Jitter blog posts on this topic:

Standards work