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…
A common question I get from customers, and those following the MSFT UC space, is: what are MSFT’s goals in partnering with PBX vendors on Voice? (E.g. Om Malik, Blair Pleasant, Jim Burton, and Eileen Brown …)
With OCS 2007 and subsequent releases going forward, Microsoft aspires to be able to provide the main voice backbone, as well as the main voice user experience, for its enterprise customers. As hinted by Jeff Raikes’ prediction of 100 million end-users accessing VoIP through Office applications in 3 years, this applies across both a broad group of enterprise customers as well as broadly within those enterprises –i.e. to a majority of endpoints in those enterprises. The “voice backbone” specifically includes voice call control (the “switching” necessary to get a call from Point A to Point B). This eventually would have Microsoft replacing core existing PBX functionality at those enterprises, and transform the device & desktop user experience as well.
How does this relate to Partnering with existing PBX and IP-PBX vendors? In the Microsoft vision, there will always be a key role for PBX vendors & service providers to complement Microsoft’s core voice offering, in at least 4 areas. First, some key telephony requirements revolve around hardware, and Microsoft’s primary business focus is software, not hardware. Therefore, for scenarios such as media gateways, site resiliency, and for hard-phone devices, all of which require (some for technical, some for practical reasons) hardware approaches, Microsoft must rely on Partners delivering those components. Second, several telephony needs involve vertical solutions – such as custom voice solutions for hospitality or retail (think the floor phones for the suits department at your favorite retailer) – and there again, PBX vendors have better domain expertise and business focus than Microsoft to be able to build vertical solutions (but powered by OCS at the core). Third, some critical voice scenarios necessitate working with service providers in the cloud (e.g. SIP trunking, Public Safety Answering Points for 911), and hence Microsoft will partner with carriers/service providers to complete such scenarios. Lastly, but perhaps most importantly, Microsoft needs Partners to deliver services around its Voice story – such as architectural design & deployment of the OCS Voice solution, often in conjunction with Partner solutions - and that is a key focus of its Voice Partnerships.
Hi, I’m Sonu Aggarwal, and this is my first post, where I’d like to take this opportunity to introduce myself and the space I’m going to be covering here.
I am currently the Director of Technical Strategy and Partnerships for Unified Communications at Microsoft. I have been involved with the Real-Time Communications space for a long time… I co-invented the first-ever enterprise IM technology in 1996 with classmates from MIT at my first startup Flash Communications, which was acquired by Microsoft to seed its efforts in Real-Time Collaboration; I have been involved with the RTC space almost continuously since. Most recently, as Group Program Manager for the Office Communications Server group, I was responsible for coordinating the roadmap, feature set, and execution for all Server aspects of Office Communications Server 2007. (Further details about my professional background are here.)
In my current role, I lead a team that drives our Partner technical engagement with Microsoft’s Unified Communications Partners, such as Nortel, Cisco, and a large set of other Partners. My blog here will focus on clarifying some common and rather fundamental questions I get from customers and Partners about our Partner direction in this exciting space. Depending on reader interest, we may also broaden into Office Communications Server product line in general.
Meanwhile, keep the discussion coming! I can’t promise an answer to every query right away, but it’ll help identify topics that I ought to shed light on sooner rather than later…
Technorati tags: Unified Communications , Microsoft UC Partners
