Interoperability Scenarios with Voice Partners
In my previous post, I talked about our long term goals for partnering with PBX vendors etc. on Voice – Hardware solutions, Vertical solutions, service providers for key scenarios, and Services.
A key near-term need is interoperability with existing PBX infrastructure, and that is where much of our Voice Partner execution has recently focused. Under the umbrella “Open Interoperability Program”, this spans 3 key interop scenarios Partners are currently delivering – Media Gateways, Remote Call Control, and Dual Forking. In this post, I’ll give an overview of each.
Media Gateways are hardware devices that bridge IP networks on one side, with PSTN networks (e.g. T-1 or E-1 TDM signaling, which is a very different electrical interface from standard IP networks and is typically used by carriers) on the other. Since virtually every single voice deployment needs to “interop” with “normal” users hosted by carriers (e.g. employee on Office Communicator voice calling a customer’s cell-phone), every VoIP deployment – including OCS voice deployment – requires Media Gateways somewhere in its infrastructure. Typically, every voice site – such as every branch office – will require a Media Gateway, such that the enterprise can accept local inbound numbers (e.g. salespeople in the New York branch office being able to take customer calls to a 212 area code). We are working with a set of Media Gateway vendors to certify them as interoperable with OCS. Long-term, we will see a trend towards centralizing this infrastructure using techniques such as SIP trunking, but that’s a topic for another post.
The Media Gateway program is officially termed “Direct SIP Interconnect”, as it requires Media Gateways to directly support (via a firmware update) the particular implementation of SIP that OCS (via Mediation Server) requires. The same Direct SIP Interconnect program also supports PBXs effectively acting as Gateways, either for calls between OC users and external users (via the PBX) or for calls between OC users and existing PBX users. Conceptually, they are the same architecture from a gatewaying standpoint, and are hence under the same umbrella.
Remote Call Control, Dual-Forking, and “Pure Microsoft Unified Communications” represent different points in the transition from 100% existing telephony to 100% Microsoft UC for a specific end-user in the enterprise. A user is on “Pure Microsoft UC” if all of their telephony needs are served by Office Communicator, and thereby represents a fully “converted” user. This is often the end-goal, and is indeed the path some enterprises are adopting towards reaping the full benefits of VoIP in the shortest possible timeframe.
Dual-forking benefits those enterprises that require a more conservative approach - usually to test out the benefits of VoIP without dismantling their existing PBX, for the same users. With dual-forking, a user has both their existing telephone device (e.g. Nortel, Cisco, etc.) and Office Communicator softphone, working in a coordinated manner. Incoming calls to that user are “forked”, and the user sees both their telephone device (via the pre-existing PBX) and their OC softphone (via OCS) ring. When the user answers either one, the other leg is automatically canceled, and the user continues the call where it was initially answered. Similarly, in the outbound direction, the call is routed through the existing PBX even if it was initiated by OC.
The classic case for dual forking is enterprises that appreciate the voice User Experience of Office Communicator, but - for now - want to continue to leverage their existing PBX or IP-PBX infrastructure as well as handsets. If an enterprise has already committed to deploying OCS for IM/Presence or for Web Conferencing, dual forking adds relatively little incremental operational cost (since it mostly leverages the same administrative infrastructure for OCS), but provides significant additional value via the OC voice experience. Hence, we expect dual forking to be quite popular with a large segment of enterprises, in the near-to-medium term.
Remote Call Control is best suited for enterprises that are even more conservative and are not yet ready to start converting their user base to OCS VoIP. With Remote Call Control (which Microsoft first offered in LCS 2005), a user uses their Office Communicator client primarily for Presence/IM , but instead of using it as a full softphone – uses OC to control their existing PBX phone. The typical scenario is the user checking presence for someone in OC, and then clicking on that user to call – but then having their desk-phone (not OCS-powered, but existing TDM or IP-PBX) ring such that they can take the call from there. Remote Call Control can also be deployed in conjunction with Dual-Forking, but it can (depending on the PBX) also be deployed stand-alone.
We are working with a number of PBX vendors to support the above scenarios, and I expect we will have a majority of initial implementations/certifications done in 1H 08. More on specific vendors – including Nortel and Cisco – in subsequent posts…
