Interoperability Support Between Cisco and Microsoft Products in Unified Communications

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

The bottom line is that interoperability provides value for our customers. This article, originally posted on the Communications Server blog, is worth a second glance to discover how Microsoft is providing this interoperability to our customers.

Author: Jamie Stark

Publication date: April 2010 (originally published December 2009)

Product version: Microsoft Office Communications Server 2007 R2

Cisco and Microsoft are competitors in the unified communications space that have very different visions and product approaches – I don’t think that is a surprise to anyone. And it shouldn’t be a surprise that many customers have Cisco networking and telephony gear along with desktop and messaging and collaboration software from Microsoft, and they want our products to interoperate well in their environment.

To Microsoft, that means offering customers software that runs great on Cisco networks. With Office Communications Server’s support for the Cisco ISR platform, support for DSCP packet marking to deliver QoS, VLAN tagging, and many more technologies, we are delivering a lot of capabilities so customers can get the most out of their Cisco network investments.

We also look to interoperate broadly by using open standards with Cisco products in unified communications. As part of both companies’ commitments to our customers and shareholders, we’ve recently published a joint statement of interoperability for our products in unified communications. This joint statement specifically addresses how Office Communications Server and Cisco Unified Communications Manager work together across three different deployment scenarios and explains what each company supports. You can download that statement on the Microsoft site at https://go.microsoft.com/fwlink/?LinkId=178900 or at https://www.cisco.com/web/partners/pr67/pr41/solutions/uci_microsoft_cisco_jointstatement.html.

The statement was drafted specifically with regard to Cisco, but an important point to remember is that Microsoft looks at interoperability across all of the vendors in a particular space. We don’t provide preferential treatment to support Cisco products or scenarios uniquely. So the support statements we’ve crafted with Cisco, while applying directly to Cisco products, are founded on principles that can be applied to any vendor’s products in a given scenario.

The first scenario is Direct SIP, where Communications Server is a peer telephony platform to an IP/PBX and exchanges calls using Session Initiation Protocol (SIP), without the use of an intermediate gateway. A number of IP/PBXs have qualified for Direct SIP support with Communications Server by engaging through our Unified Communications Open Interoperability Program (UCOIP) (https://technet.microsoft.com/ucoip) to provide joint support.

In addition to that effort, Microsoft also tests IP/PBXs that have not engaged in the program, based on customer demand. Therefore, we differentiate between products that have been “qualified” through the UCOIP, and those that have been “tested”, meaning that Microsoft solely has done the testing and supports the configuration. This is why you see some versions of Cisco Unified Communications Manager supported by Microsoft for Direct SIP, but not by Cisco. Our customers have clearly told us it’s important to provide both programs, because many have older IP/PBXs that vendors may not choose to qualify through the UCOIP. These older models Microsoft can test and potentially support (based on the IP/PBXs adherence to standard-based SIP). This allows customers to get more value out of their existing investments.

The second scenario is remote call control, where the PBX station set (doesn’t have to be IP in this case) is controlled by Office Communicator. Here, we don’t have a testing or qualification program—there are many PBXs and gateways that support the ECMA TR/87 standard used by remote call control and those products will work with Communicator because we support the TR/87 interface. Many PBX vendors will have a specific testing matrix for which middleware layer or CTI link is supported with Communications Server. In addition, there are a variety of remote call control gateways available from companies like CoreBridge, Estos, and Genesys that further expand the diversity of PBX models and versions available. Microsoft has announced the deprecation of the remote call control feature for the next release of Communications Server, so new deployments of remote call control will not be supported with the coming release. However, customers who have existing deployments of remote call control can upgrade to the next release and will continue to be supported through the lifecycle of that release for a substantial amount of time.

Finally, several PBX vendors have brought to market plug-ins to Communicator that enable Communicator to interact directly with a PBX environment. These plug-ins are built on top of the Communications Server APIs, which provide an extensible platform for the development of communications integrated directly into business process applications, customizing the functionality of Communicator or Communications Server and much more. Microsoft welcomes all vendors who build on our platform, whether they are Microsoft ISVs, Partners, or traditional competitors in the unified communications space. My colleague, BJ Haberkorn, has devoted an entire blog post to this topic (https://go.microsoft.com/fwlink/?LinkId=188298). Don’t hesitate to check that out.