There is a lot of chatter about QoS and how you "don’t need it" to effectively use OCS as a voice platform. The logic behind that seemingly crazy statement is that MS has commissioned a test by Psytechnics (http://www.psytechnics.com/page.php?id=060307§ion=newsandevents) that showed voice calls using Office Communication Server (OCS) 2007 were of a higher quality than those using Cisco CallManager & Cisco IP phones… on a network with no QoS, nonetheless.
At first, the networking guy in me said that this was nuts. Voice is delay sensitive and doesn’t benefit from re-transmitting lost packets; it uses UDP, where there is no real mechanism for re-transmissions & confirmations. So if your network is crappy, or congested, some packets are going to get discarded. If those packets are data packets, no big deal: just retransmit them. However, if they are voice packets, the packets go bye-bye and your conversation will sound crappy. If you aren’t prioritizing voice packets on your routers and switches, you will lose packets, end of story.
To make matters worse, I couldn’t find any real answers as to how MS was justifying it’s seeming indifference to QoS. I figured (and still kinda do) that it was because it was a major marketing blow to Cisco to say that you don’t really need special networking gear to make voice happen. MS was seeming to trumpet the Psytechnics’ study and kinda said "Well, our codec is better, so you don’t need QoS. Trust us!" My favorite bizarre sounding answer was "The Microsoft codecs, working with client software on either end, injects signals and tones into the voice stream, which make the calls sound better than standard VoIP calls made over jittery links". Very infomercial-esque. "Injecting"!
I wasn’t content to hear that a lower bandwidth codec that injected itself with foreign substances was the basis for not really needing QoS. After poking around a bit, I found that MS has a nice whitepaper overview of the technology behind the magic: http://www.microsoft.com/downloads/thankyou.aspx?familyId=5d79b584-79c9-42a8-90c4-4ab3f03d19c4&displayLang=en
As it turns out, MS does have some cool stuff in their voice codec (Real Time Audio, or RT Audio). First – it takes advantage of variable bit rates. This is different than most of the traditional voice codecs out there (G711, G729). G711 always uses 80kb/s of bandwidth for a call, no matter what. G729 always uses 32kb/s, no matter what. When making a call using either of those codecs, if your bandwidth gets pinched, packets get dumped. What RTAudio does is allows the bit rate to vary, depending on traffic. So if your call starts out on a network that isn’t very congested, it will use 45kb/s. If the traffic starts picking up on your network, the bandwidth of your call might adjust to 20kb/s to account for the traffic. When the congestion clears up, the bandwidth may rise again to 40 kb/s. It’s a cool way to make UDP act more like TCP!
The other really nice thing that RT Audio does is use Forward Error Control (FEC) which amounts to sending duplicate copies of each voice packet when it detects high packet loss on the network. Yes, this takes more bandwidth, but it’s good for networks prone to packet loss or jitter. Now, instead of sending one packet that potentially will get lost en route, you send two packets, each with a chance to make it to the destination. So if an unlucky packet is delayed or gets dumped on by a busy switch or router, you’ve doubled the odds that your packet will make it through. Again, this is a nice trick to make UDP like TCP: Just assume that you have to re-transmit by always sending two copies.
Lastly, and probably most importantly, OCS does tag packets with DSCP values so that a QoS-enabled network is able to prioritize the OCS voice packets. This should go a long way towards calming the nerves of the latency-averse network crowd. This can’t be understated: OCS does use traditional QoS methods in addition to the newer codec-related techniques to improve overall voice quality.
My conclusion? I still think that you should deploy QoS on any network with voice traffic. However, I think that Microsoft has made some smart moves and good innovations in the arena of reliable packet delivery over networks with varying degrees of quality.
