Skip to main content
 
Go Search
Home
Categories
Bloggers
OCS 2007 R2 - QoS on the MOC Client (especially with 64-bit clients!)
By: Matthew McGillen | Posted: August 27, 2009 at 2:34 PM

I've been fiddling with QoS and OCS for the past few days and have some insights to share.

First important point is that OCS will support QoS via DSCP marking. But it is not enabled by default on any OCS servers or clients, but can be enabled. Microsoft has some pretty useful info on how to make that work. Straight from TechNet on the MS philosophy of QoS:

Although Office Communicator Server 2007 has been designed to work without any QoS framework, it is possible to configure the media stack to mark the IP traffic conveying the real time audio and video IP traffic according to well established classes of services.

The marking may be enabled or disabled by means of registry keys. If enabled, the marking of the IP packets is done by the QoS Packet Scheduler service. The resulting marked packets can subsequently be recognized by network entities (end systems and routers) to manage the media traffic according to the QoS priorities.

 

And the correct registry entry (a DWORD) is as follows:

HKEY_LOCAL_MACHINE\Software\Microsoft\RTC\Transport\QoSEnabled =1

That's actually the "main" one to change. If you do that, your voice traffic gets marked with a DSCP value of 40 and video gets marked as 28.

QoS with Cisco Switches and Routers

In my experience, most QoS policies (especially Cisco) prefer to treat voice as Expedited Forwarding traffic - the highest level of DSCP QoS - a value of 46 . And for video, it normally should be marked as "assured forwarding -31" - a value of 26. )

Cisco networks that are already set up to prioritize IP telephony traffic will be looking for these markings, not the MS / OCS defaults. It's possible to use other values (like the MS defaults) but I'm pretty sure that EF / AF is the way to go in most cases.

So to make that happen - you can use Group Policy - or just manually set the registry entries like this:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched\DiffservByteMappingConforming\ServiceTypeControlledLoad = 26 (Decimal)

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched\DiffservByteMappingConforming\ServiceTypeGuaranteed = 46 (Decimal)

 

It's probably a good idea to set the following as well:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched\DiffservByteMappingNonConforming\ServiceTypeControlledLoad = 26 (Decimal)

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched\DiffservByteMappingNonConforming\ServiceTypeGuaranteed = 46 (Decimal

 

When you do this, you can run a network capture in wireshark and see that the voice packets are being marked properly:

As well as the video packets:

Case closed. Welllll… not totally: my 64-bit clients, for some reason, were not actually marking the packets properly.

64-bits and QoS with MOC

I've been running Vista for a long time (I appear to be one of tens of people who actually really love Vista & haven't moved to W7 yet) and I've never been able to make the QoS policies work on it. All packets were showing up with 0x00 in the DSCP field. A co-worker and I finally had reached the end of our patience and decided to get to the bottom of the mystery. We both had the same problems, he on W7, me on Vista. Nothing worked… until it dawned on me: we were both running 64-bit OS. That seemed like a likely cause, but I wasn't sure exactly why.

My co-worker, Aaron, suggested that we try making the above registry entries in the "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node". Brilliant! MOC is a 32-bit app, even on a 64-bit machine. So I created all the correct entries:

HKEY_LOCAL_MACHINE\Software\WoW6432Node\Microsoft\RTC\Transport\QoSEnabled =1

HKEY_LOCAL_MACHINE\SOFTWARE\WoW6432Node\Policies\Microsoft\Windows\Psched\DiffservByteMappingConforming\ServiceTypeControlledLoad = 26 (Decimal)

HKEY_LOCAL_MACHINE\SOFTWARE\ WoW6432Node\Policies\Microsoft\Windows\Psched\DiffservByteMappingConforming\ServiceTypeGuaranteed = 46 (Decimal)

And then, just like that, Vista 64-bit was marking packets. I tested audio and video; to my delight QoS was working properly.

 

QoS on OCS Servers

Getting QoS deployed and configured on the OCS servers is a different matter - although it's similar in concept to making it work on OCS clients. I'll save that for a later date.


  Comments   Add Comment   Share It  
  Your Name:
  Your Email: **will not be displayed
  Comment Title:
* Comments:
  If you cannot read the code, please
click here to get a new one. You won't
lose your comments by doing so.
* Security Code:
   
  
  
* Your Name:
* Your Email: **will not be displayed
* Recipient's Email:
* Subject:
  If you cannot read the code, please
click here to get a new one. You won't
lose your comments by doing so.
* Security Code:
  
  
  
By: Richard | Posted: July 15, 2010 at 7:11 AM
Hi, just another FYI: I had bad experience, if Nonconforming part of the configuration was also done under vista32. The result: it did not mark packets (the value was 0 or the OS default 40, I cannot remember).
re: value of 26
By: Matt | Posted: April 29, 2010 at 4:37 PM
Oh!! I see what you are saying! Yeah, you are right, it's "AF 31" as the classification - but it's DSCP value 26. Totally right. Thanks for that, I've corrected the post.
Value of 26
By: Nick | Posted: April 23, 2010 at 2:59 AM
I think the 31 in the string in the wireshark is part of the display text not a reference to the value. So I get this when I set the value to 26. I think the value just needs to be 26 rather than 31. Thanks for the response, also a very useful blog for me undersstanding QoS with OCS.
re: Value of 26 = 0x1a
By: Matt | Posted: April 22, 2010 at 1:36 PM
Thanks for the message regarding the hex. You are definitely right - 1a is 26. I'm not sure why wireshark was displaying it like that. It's strange that it would show 0x1a: Assured forwarding 31. It must be a bug in that version of wireshark. I'll see if I can recapture and post a better graphic. Thanks again! --Matt
Value of 26 = 0x1a
By: Nick | Posted: April 22, 2010 at 12:29 AM
I have been doing some testing on this and noticed that 1a in decimal is 26 not 31, so to get assured forwarding I have set the controlledload to 26 not 31. Is this an error on the blog or have I got it wrong
QoS on servers
By: Shane Hitching | Posted: November 30, 2009 at 4:29 AM
Hi Matt, thanks for the great post. Is there any chance you’ll be blogging on QoS for servers any time soon? Our network is configured for non-MS VoIP so we need to change the default DSCP values. It works OK on the clients, but our OCS servers just aren’t using the value set in ServiceTypeControlledLoad and ServiceTypeGuaranteed. TIA, Shane.
QoS on R2 servers
By: Shane Hitching | Posted: November 30, 2009 at 4:28 AM
Hi Matt, thanks for the great post. Is there any chance you’ll be blogging on QoS for servers any time soon? Our network is configured for non-MS VoIP so we need to change the default DSCP values. It works OK on the clients, but our OCS servers just aren’t using the value set in ServiceTypeControlledLoad and ServiceTypeGuaranteed. TIA, Shane.
Set QoSEnabled in Group Policy?
By: Tyler | Posted: November 18, 2009 at 4:27 PM
Can you set the QoSEnabled=1 in Group Policy, without using Group Policy Preferences?
Setting QoSEnabled=1 in Group Policy?
By: Tyler | Posted: November 18, 2009 at 4:25 PM
Is there a way to set the QoSEnabled=1 without using Group Policy Preferences?
Nice- any thoughts on Call Admission Control?
By: Tom | Posted: October 8, 2009 at 5:57 AM
Excellent post. Do you know of any work arounds for Call Admission Control? In other words protecting links from getting over subscribed?
Vista still no good
By: Richard | Posted: October 5, 2009 at 7:08 AM
I checked several 32 bit Vista systems, and none of them applies the change from decimal 40 to decimal 46. 32 bit XP and 32bit/64bit Windows7 is fine
ReRe:Nice
By: Richard | Posted: September 28, 2009 at 9:19 AM
Ok, it seems to be some Vista issue, on a 32bit XP system it works flawlessly after a reboot.
ReRe:Nice
By: Richard | Posted: September 28, 2009 at 8:39 AM
Matt, I am afraid, the situation is still the same: still marks packets with 0x28 and not 0x2e (GPO editing done, restart done) What is the difference (if any) between editing the GPO\Qos scheduler policy and editing the registry by hand (registry solution you mentioned above)?
re: Nice
By: Matt | Posted: September 25, 2009 at 4:29 PM
Hi Richard - 0x28 is the MS default. In order to get it to read 0x2e, you will need to open up gpedit.msc on your local machine and change the settings for QoS. Go to gpedit.msc -->Computer Configuration-->Admin Templates --> Network --> QoS Packet Scheduler --> DSCP value for Conforming packets. Then change guaranteed service type to "enabled" and change the number from 40 to 46. You might want to do the same thing for non-conforming packets as well. Then reboot. - Matt
Nice
By: Richard | Posted: September 25, 2009 at 10:34 AM
Hi, a really nice topic indeed. I am also trying to make that QoS classification work, but with a very small luck. On a Vista 32 bit system, it is not doing what I would expect. making all the steps that you listed, I get the following result: DSCP 0x28: Class selector 5; ECN=0x00 (using wireshark 1.0.5) no DSCP 0x2e Expedited forwarding. Packet scheduler needs to be turned on somehow, or binding it to the network interface is the only step required?
re: Not recommended...
By: matt | Posted: September 1, 2009 at 9:29 PM
Hi Dan, Thanks for the comment. I do, however, want to make it clear that this method works, is supported, and has shown no adverse effects for any of the people I've talked to or helped configure. My guess is that there's something else going on to cause your issue, not just the registry entry.... I'll also say that using network-based vs. OS based QoS is a great idea; although since OCS clients use any port greater than 1024 for RTP, you'll want to narrow that range via group policy prior to configuring a switch-based policy that "prioritizes" all UDP traffic above 1024. Thanks again for the comment. - Regards, Matt
Not recommended...
By: Dan Maslin | Posted: September 1, 2009 at 2:28 AM
I've been doing testing with QoS at the OS level and in summary, would not recommend doing it. See my post for further detail: http://blog.danovich.com.au/?p=75
 

 About Matt McGillen

Practice Manager - Unified CommunicationsMatt McGillen is the practice manager for Unified Communications at PointBridge. He has over 10 years of IT consulting experience, focusing mainly on the government, legal, financial and health care s... [more]

 Tag Cloud

 External Links

 ‭(Hidden)‬ Admin Links