UC Interoperation: What's Needed? Session UpdateUC Interoperation: What's Needed? Session Update

Our moderators answer questions we didn't have time for during the session.

Last Wednesday AM, Enterprise Connect attendees filled the room to hear about UC Interoperation. The moderators set the stage with a categorization of the types of UC interoperation and a rating of the maturity and difficulty of each. The panelists from Avaya, Cisco, Microsoft, NEC, NET, and RIM added their commentary on where their customers were having success with interoperation and what their focus would be for expanding their interoperation capabilities in 2011 and 2012. The session was captured on video, and should be available soon for viewing at www.enterpriseconnect.com.

The audience submitted over a dozen great questions. There was not time to answer them all, so we promised to post the un-answered questions along with our answers to these. Please add your comments below, if you wish to expand on or comment on these answers. Again, we thank both the panelists and the audience for participating in this important discussion.

Here are the remaining Qs & As:

Q: Today there are interoperation stories, but during interoperation deployments you tend to lose some of the UC features. What are the vendors doing to close the gaps of interoperation between their products?

A: There will always be approximately three zones of interoperation status, and those three zones will vary according to your enterprise’s needs:

Zone 1: Sufficient or Better: The interoperation available is sufficient to support the requirements of your UC application(s). No UC application requires all possible UC features, so the set that is available may be sufficient or more than sufficient.

Zone 2: Limiting, Requiring Workarounds or More Investment: The interoperation available is not completely sufficient and must be supplemented either by added technology investments or by customizations or one-off connectors. For example, perhaps federation with public IM services does not provide sufficient presence indication or is not sufficiently secure; such a case would limit the user population to those who can federate in secure modes or would require additional investment to add the external users to the in-house system or to provide the secure functionality through a comm-enabled portal. As another example, the use of gateways is a common solution for interoperation between two vendors’ platforms, especially for connection to legacy systems when interoperation is only available on the latest releases. Willingness to work in Zone 2 is subject, of course, to the business value of the new UC solution, whether as to priority or as to financial justification for the added investment.

Zone 3: Not Sufficient, Unavailable: The interoperation is simply not possible. In this case, the solution cannot be implemented and the vendors and VARs will lose the revenue opportunity. Enterprises should make such gaps as visible as possible in the market and to the vendor, e.g. by buying another vendor's platform which does support the interoperation, if necessary.

(Answer by Marty Parker)

Q: Are vendor-proprietary implementations of SIP going to create future interoperability problems?

A: It depends. SIP is a framework standard, not a specific interoperability specification. Just as T-1 and E-1 QSIG provides for Manufacturer Specific Information (MSI) in the transmission headers, and just as eXtensible Markup Language (XML) provides for flexible data definitions, so Session Initiation Protocol (SIP) standards acknowledge vendor-specific implementations.

So, on the one hand, yes, vendor-specific implementations may create both current and future interoperability problems. But, on the other hand, no, it may not create interoperability problems, since most vendors will be required by their customers to support some "core" set of interoperability features, such as support for the "fab five" features on a SIP phone (call, hold, transfer, conference, disconnect).

The SIP Forum (Text that's linked) is fostering SIP interoperability with its SIPIT testing events and its SIPConnect certification process.

Continue to communicate your requirements, as specifically as possible, to your suppliers.

(Answers by Marty Parker and David Yedwab)

Q: Are there any efforts to standardize on a common call admission control approach so that in a multi-vendor environment bandwidth management is not "two ships passing in the night"?

A: Not that we are aware of, but your question is now visible to many gateway providers, SBC providers, network providers, and IP Telephony providers (referring to "call" admission control). In addition, it seems worthwhile to consider new standards for "Media Admission Control", such that a session which begins as, say, Instant Messaging and moves to voice or desktop sharing and then has portions of the session as video, can have the access and bandwidth usage managed dynamically during the call according to enterprise policies.

(Answer by Marty Parker)

Q. What is your recommendation when it comes to integrating components of the UC system? Such as integrating Avaya Modular Messaging into Microsoft OCS/Exchange.

A. As consultants, we always seek clarity on the requirements before making a recommendation. In the case you mention, it will be important to know if you mean to integrate the two systems purely for message storage in Microsoft Exchange, or if your requirements are actually to store messages in Modular Messaging and make them visible in an Outlook Inbox. Fortunately, the integration of Modular Messaging with Exchange has been in existence since 2003 and is well documented by Avaya.

As to integration of Modular Messaging to OCS, it would be necessary to understand the application requirements there, as well. If you are asking how to use Modular Messaging for voice mail call coverage for users who are on Microsoft OCS for their enterprise voice applications, the recommendation is to use a SIP (Microsoft) to T-1 (Avaya Communication Manager connected to Modular Messaging) gateway. You probably will not need or even want message waiting lights (on phones connected to OCS) for those users, since they will see their voice messages in Outlook on their desktop.

(Answer by Marty Parker)