Microsoft OCS Rides Its Own Wave

By Dave Michels May 14, 2010 8 Comments

Voice systems are known for their proprietary heritage. Mysterious hardware connected via dedicated cabling to proprietary endpoints. But despite this, interfaces were always well understood. For example, most traditional PBX systems will connect to any carrier and most third party systems such as voice mail or call recording systems.

Over the past decade, with game changing UC requirements and VoIP, voice solutions have been gradually opening up to a world of convergence. New emerging standards such as codecs, SIP for trunks and endpoints, POE (IEEE 802.3af), and XML. This is a journey as technologies and requirements continuously change - XMPP for IM can be added to the list, but inter-operable SIP video is still young. Most major UC players are embracing these trends, but Microsoft OCS stands-out with the most innovative approach to the old model.

Starting with the VoIP codec, while every major UC vendor embraced the G.711, G.729, and G.722 codecs for voice - Microsoft found them unacceptable. Instead, Microsoft invented RT-Audio for internal OCS communications. This codec is a cross between G.722 and eG.711. The three variables in codec design are audio quality, bandwidth requirements, and processor requirements. RT-Audio delivers high quality audio with low bandwidth consumption, but requires significant processing capability to do so. This works well on a Windows desktop (soft phone), but OCS hard phones require relatively more power and are subsequently more expensive.

Microsoft designed a new line of phones that are effectively running Windows (licensed versions of Windows CE, Office Communicator, and RT Audio). The phones are manufactured by Polycom and now Aastra under licensing agreements. Microsoft not only created the firmware for them, but actually specified most of the hardware within the devices (practically eliminating the benefits associated with years of experience both Polycom and Aastra have in phone design). Curiously, Snom (not a Microsoft Partner) devised a solution for OCS environments presumably without paying any license fees. Georgia Military College successfully implemented Snom phones on 80% of their desktops at a significant savings over the endorsed hardware. Microsoft's solution to the high cost of the phone is a USB "phone" or accessory that uses the PC's processing power but looks/acts like a phone. This innovation requires a PC running Communicator which reduces its suitability in many environments (i.e. courtesy phone).

Microsoft suggests that RT-Audio is both necessary and open, but neither are true. Generally speaking, the world is quite pleased with G.711 and G.722 compression quality. At best RT-Audio is comparable not better (it is negligibly more efficient on the LAN, but that isn't usually a bottleneck). However, the requirement for expensive endpoints and to transcode every external call is a questionable trade-off for the enterprise. Microsoft does license RT Audio to partners and developers, but that doesn't make it open. To be fair, most of Microsoft's competitors are leading with proprietary phones for advanced features, but they also support SIP endpoints. This opens up a world of low-cost and specialized devices where needed. As a result, OCS does not have a low cost lobby phone, or any wireless (Wi-Fi or Dect) phones, or third party soft clients (desktop or mobile). There was no supported speaker saucer until last year.

OCS is heavily influenced by SIP standards, but SIP stops at the Mediation server. Since carriers and external systems generally don't expect (or support) RT Audio, all calls need to go through a translation process performed by an OCS Mediation server(s) - and then often a gateway after that. Only a few gateway makers are approved for OCS, but that's okay because it can be completely skipped if the customer is willing to limit carrier choices to a select few. Microsoft is the only major UC vendor that does not support SIP endpoints. This is odd in itself, but even more so after hearing an OCS presentation position SIP (trunks) as such a central part of its strategy and ROI. It seems as though Microsoft went out of its way to not support SIP endpoints.

Related to the phone is the emerging standard of an XML microbrowser. Nearly all SIP and H.323 VoIP phones include an XML browser that can be used for custom UC or web applications. The Microsoft OCS phones buck this trend as well.

But voice is only a portion of OCS and an even smaller portion of the complete Microsoft UC vision. OCS is a piece of a complex puzzle that involves multiple Microsoft components and products; including Active Directory, Exchange, Live Meeting, SharePoint, and SQL Server. This is an important part of the solution and partially explains why OCS is missing so many "PBX" features. Active Directory and Exchange are not optional components. By committing to OCS for voice, the user is committing to network security and messaging standards. Is there any other UC solution that mandates the messaging solution? Microsoft positions this as infrastructure organizations already have, but that isn't the same as infrastructure organizations will always want. Voice solutions tend to last a minimum of five years, longer than IT server life cycles. Even worse, with "Wave 14" (AKA version 3), Microsoft is now recommending dedicated Exchange servers for voice and email - (un-unified messaging). OCS users have not enjoyed the benefits of multi-user collaboration with SharePoint (although this feature was recently announced).

The Microsoft UC vision is very broad and impressive, but equally locked. It is known as a walled garden approach. And many organizations will find it a delightful garden. The converse is a "best of breed" approach that allows users to optimize various components of a UC solution. For example, IBM's SameTime solution does not require Notes and can work with MS Exchange and numerous solutions for voice. Organizations considering or requiring approaches involving thin or virtual desktops, server virtualization, integration with social networking, strong integration with mobility, alternatives to MS Office, cloud services, or real time multi user collaboration may find OCS confining. Additionally, as some applications are moving to the cloud, users are realizing savings with different types of workstations (including Windows Home Edition), this option is also closed with OCS.

OCS can be implemented without its native voice features, using a different vendor for a voice solution in conjunction with OCS. One method of doing so is with Remote Call Control (RCC). Here the PBX station set (doesn’t have to be IP) is controlled by Office Communicator. Unfortunately, Microsoft announced the deprecation of the RCC feature for the next release of OCS. Instead, IP equipment makers seeking interoperability need to qualify through Microsoft's Unified Communications Open Interoperability Program (UCOIP) to directly connect to OCS. Participation in this "open" program is solely at Microsoft’s discretion and requires the vendor to become a Microsoft Partner and agree to Microsoft's NDA.

One area where proprietary often wins is with custom integration. But this is usually limited to the walled garden. Microsoft profiles some wins on its site. A good example is POSTcti created a custom recording application for OCS via the Office Communicator client. "With this capability, users can use their PC-based soft phones to perform call recording through an Internet connection from anywhere they are located...Live-PA was built on the Windows Server 2003 operating system, the Microsoft .NET Framework, and Windows Media Encoder 9 Series." Examples of non Microsoft based integrations are harder to find.

Enterprise infrastructure technologies are in a state of flux - particularly in the area of unified communications. Endpoint devices, mobility, videoconferencing, collaboration, presence, calendaring, location, virtualization, thin clients, SaaS, and more are transforming the UC space. For one vendor to deliver it all is a herculean task, thus openness and partnerships are critical. Microsoft OCS has influenced the space impressively and will continue to do so. Microsoft could indeed become a top player in UC if it can translate mind-share into market-share. And many organizations, will consider OCS the default solution. Microsoft is selling an entire stack, not just a voice component which will suit many organizations well. I expect Microsoft to continue to make innovative incremental improvements to OCS, but if it can effectively innovate its entire solution - presence, video, collaboration, Office, etc. at a competitive clip is yet to be seen.

8 Responses to "Microsoft OCS Rides Its Own Wave" - Add Yours

Jay Brandstadter 5/15/2010 9:09:18 AM

2 years ago, Microsoft launched its "VoIP As You Are" campaign. Implying that there was no need to rip and replace your PBX, just add (OCS) software to what you already have. The slogan should be "VoIP as Microsoft Dictates". Good old proprietary lock-in. Interoperability and openness? Yea, right!

Don Van Doren 5/17/2010 5:28:46 AM

Clearly Microsoft (along with most of the other ecosystem-focused suppliers) understands the coming sea change in communications, and the potential for transformative opportunities that UC offers when integrated into business processes. My inherent bias is toward openness, and the “rising tide raises all boat” side of the argument. I feel that environment will best serve the broad spectrum of opportunities available.
The question is whether Microsoft, with its version of “open”, can corral this wide range of opportunities that will emerge. Perhaps an interesting parallel is Microsoft vs. Apple in the past wars for PC dominance. Apple then argued for “proprietary is better”, which turned out to be beside the point. Is Microsoft looking more like Apple in the current UC wars? Granted, Apple then was more closed than Microsoft is now. But, Microsoft’s success then was first on integrating into other suppliers’ hardware, and second on the emerging ecosystem of application developers working with Microsoft OS. In UC, Microsoft wants integration on its terms, but it still has legions of developers and integrators. Having such an ecosystem will be key to communications-enabling business application opportunities.
The question is will it be enough or will the market demand full openness, too? The current pace of UC-B adoption is slow, and many enterprises are making their evaluation based on UC-U criteria. Openness and integration are often most important in UC-B, so perhaps these will be relegated to “nice-to-have” features that get lost in the shuffle. At least in the near term. We’ll see.

Marty Parker 5/17/2010 8:26:23 AM

Thanks, Dave, for taking a position, so we can debate it. It is clear to me that the leaders in new markets always have to launch technologies and protocols that look proprietary at the time. Just look at Cisco with the Skinny protocol for VoIP when processing power limits dictated an alternative approach -- worked for them. Just look at WebEx who determined that proprietary networking protocols were needed to deliver the web conferencing experience they needed to deliver -- worked for them. Just look at Avaya's initiative with Aura Session Manager and Cisco's initiative with Intercompany Media Engine; while both are in the Internet Protocol and SIP categories, neither is based on a published standard -- yet to see if those will work for their sponsors.
So, it seems unreasonable to measure Microsoft's initiatives based on legacy PBX interoperability. IMHO, one needs to look at what the goal is and then assess the actions. Look at my post on NoJitter.com last year: https://www.nojitter.com/blog/archives/2009/02/microsoft_ocs_2_1.html?queryText=marty+parker+OCS.
You'll see a whole list of things Microsoft did differently, with the potential of better results.
This debate is about CODECs and phones. On the CODEC side, the protocols are adaptive to bandwidth, a feature not available with the existing "standard" protocols that depend on fixed bandwith (the old T-1 model) or reserved bandwidth on QOS managed LANs or corporate WANs. Perhaps Microsoft thinks that more and more traffic will flow over the Internet and chose/built a CODEC for that.
As to phones, well that's really a legacy discussion. I continue to marvel at the fancy touch display phones that are intended to sit next to a PC with dual 18-inch screens. And the ecosystem is supplying plenty of SIP gateways for SIP phones as shown by SNOM or NET.
My bottom line has always been that it would be a waste of money to create another version of a PBX. But a new, dare I say, Unifie

Marty Parker 5/17/2010 8:31:03 AM

Following post was too long. Ending is
But, dare I say, a Unified Communications system that bets on business process improvements, on federated and distributed enterprises operating their supply chain over the Internet, and on increasingly cheap processing power, now that's interesting.
Comments?

Dave Michels 5/17/2010 12:00:54 PM

Great discussion points. I forgot about the VoIP as you Are campaign. That story has changed a bit. So has the ResponsePoint story - Microsoft's other proprietary voice solution introduced for SMB a few years ago and recently abandoned. Businesses have rights to change their story and abandon under performing product lines - that's exactly why such proprietary Kool-Aide is so dangerous. ResponsePoint used proprietary phones with a special button that can't easily be retrofitted. Customers and Partners don't have any use for this equipment - nor can an ecosystem survive at all without Microsoft to lead it.

Darryl Rowe 5/20/2010 9:24:17 AM

A few comments. G.711 and G.729 are 20th century codecs not designed to run on IP networks. Hence the development of QOS. However, what do you do when you are on a network without QOS? One of the foundations of UC is "work anywhere." While RTA is more efficient than G7.xx codecs, it is also higher quality and has built in mechanisms to overcome packet loss, jitter etc, as found on the Internet. None of the G.7xx codecs have that, not even G.722.
The development of RTA has led to Cisco frantically licensing ILBC and iSAC (not standards either) to catch up. Google just bought GIPS (inventor of these codecs,) so obviously Microsoft got something right.
Only a few gateway vendors? I count 17 different vendors and over 40 certified gateways on the MS website. How many gateway vendors do Avaya and Cisco really support?
A SNOM phone is a SIP phone. It runs G.711. It registers to OCS directly. Other SIP phones that don't embrace security such as TLS and SRTP can register to OCS via a gateway such as NET VX.
BTW, while Cisco and Avaya can support SIP endpoints, how many people actually go and install SNOM or Grandstream to their CUCM or Aura? Licensing plus HW make that more expensive than buying the proprietary phones that Cisco and Avaya sell.

Aamer Kaleem 5/20/2010 10:03:09 AM

It appears to me that author (and few others) are still approaching UC as something built on top of a dial-tone solution. They need to stop thinking in traditional (or may I dare to say in legacy) way and starting connecting the dots.
They need to ask themselves from which application usually they start their day from and then what they do next and next. Essentially, how they communicate, share, collaborate, work etc. with others (whether their colleagues, partners, customers, affiliates etc).
Moment you do that then people like Dave (Strategists/Advisors) starting thinking of solutions that will allow inherent efficiencies in terms of productivity and costs.
Enterprises today are not looking for 700 features PBX with IP in front of it, but they are looking for a Communications & Collaboration platform that allows them to move between Synchronous and Asynchronous workspaces anywhere, everywhere & always.
Anyone who has experience Microsoft solution knows the feeling :)

Mark Nickerson 5/20/2010 1:47:25 PM

Jay.. not sure your point. Polycom and Tandberg both interoperate with Microsoft OCS via the published APIs. RIM, Modality, Cisco...what's not open? RTA is used because there is no standard for an adaptive codec, and the client will support the legacy g.xxx codecs.