VoIPNorm’s Myth Busters

Recently on UC strategies Dave Michaels wrote an opinion piece on Microsoft’s UC strategy. I am always interested to read or hear what independent industry analysts have to say on the topic because it is my belief that they are typically an unbiased opinion based upon well researched material. Even though Dave brought forward some valid points he certainly has fallen victim to some common myths and generalities around Microsoft’s UC strategy.

As you can guess Dave received some feedback in the comments on his piece that make just as interesting reading as the article itself. Some in his favor others not so much. While I don’t call into questions Dave’s motives or research method I felt compelled to talk about some of the common myths and generalities that Dave has called out and some others that I have heard over the last few years.

I can’t take all the credit for collecting the myth’s that I will be covering in the next few posts. Darryl Rowe (a fellow voice warrior from Microsoft) was kind enough to collaborate with me on these posts which I hope people enjoy.

So without any further ado:



In no particular order:

Myth#1” Microsoft only supports its own proprietary voice codec.”

As a matter of fact Communicator 2007 R2 supports a total of 7 voice codecs besides RTAudio.



While it is true that the mediation server only supports RTAudio (OCS Side) and G.711 for connectivity to the PSTN, Communicator supports this full list of codec’s.
While on the subject of the mediation server, Dave’s article calls out the mediation server with “to transcode every external call is a questionable trade-off”. This is incorrect. The two main reasons the mediation server is required in OCS R2 is transcoding and encryption. In saying that, not every call to the PSTN is transcoded in OCS R2. Microsoft recognized the fact that LAN calls really do not require the use of RTAudio where there is less jitter and latency. Also when calling the PSTN RTAudio will always fall back to narrowband due to the fact that the PSTN does not support wideband . So whenever a Communicator endpoint is within 20ms of a mediation server it uses G.711 and there is no transcoding required only encryption.

RTAudio is proprietary but it has been licensed by a number of vendors (including Tandberg which we all know by now is part of Cisco). That of course doesn’t make it open just easily obtainable under license. I don’t believe you can truly call it open until it is ratified by the IETF as an RFC and it is free to use, but this is just my opinion. Even though G.729 may be a recommended standard according to the ITU, guess what, you still have to pay a license so I have trouble with discerning something as a standard when you still need to pay for it. It may as well be propriety.

So, after dissecting this myth a little. I think we can safely say it is BUSTED.

Myth#2 “Microsoft doesn’t support quality of Service (QoS)”

If you have followed my blog at any length you already know this is false. While I have argued the validity of certain areas of QoS and their necessity, it is universally agreed that it is an important architecture element of any VoIP enterprise network, hence the reason OCS supports DSCP both at a server and desktop level. Does this get easier and better with Windows 7 and CS14? Absolutely, but the current product still supports QoS.

With that in mind, there is no QoS on the internet which more and more enterprises are leaning on for remote workers and intercompany traffic. So while having QoS on the enterprise network is fine, using RTAudio gives the enterprise some ability to achieve call quality over the internet and other uncontrolled networks. More company’s are moving towards these types of codec’s, Microsoft isn't alone. Google’s purchase of GIS and acquiring the rights to iSAC (a propriety adaptive codec), which was submitted to the IETF in conjunction with Cisco, shows that this isn't just a Microsoft trend but an industry trend. Variable bandwidth codecs are the way of the future, solidifying Microsoft’s initiatives behind RTAudio.

So after dissecting this myth a little. I think we can safely say it is BUSTED.

Myth#3 “Microsoft does not support SIP endpoints”

Probably the most common reason that generic SIP phones cannot register with OCS is because they do not support SIP/TLS over TCP which is an integral part of the OCS design. Now with that said, there is an open standard SIP phone manufacture (SNOM) that has in fact gone and created a firmware load that supports direct registration with OCS using SIP/TLS.

How is this possible? Microsoft, as with nearly every manufacture, supports the standard SIP RFC’s(RFC 3261 etc, etc).

Is it possible for other phone manufactures to do the same? Absolutely.

But don’t they need to implement RTAudio? No they don’t as SNOM has proven with using the other supported OCS codecs (G.711 and G.722).

Even though SNOM is not a Microsoft certified endpoint, SNOM has been fully supporting its OCS(snom Open Communication Solution Edition)edition for a few years now and has a SNOM supported production firmware build.

So after dissecting this myth a little. I think we can safely say it is BUSTED.

Well, thats all for MythBusters this week. I am on vacation next week but look forward to busting more myths on my return.

Comments welcomed.

VoIPNorm