My previous post was mostly about why to control bandwidth management, and some of the things you should think about when it comes to doing something about it. But as soon as I read it online, I realized I should follow up with a post on CAC, and how you might do it (the really easy way).
The thing is; CAC is so simple, I don’t get why customers don’t do it more. I realize there is not much use of it on a big campus design, with plenty of bandwidth. But as I tried to highlight in my previous post, there are plenty of locations where bandwidth actually is an issue.
I’ll get straight to the point this time. I have an imaginary customer with 500 employees. They decided to replace their entire legacy pstn and go for Lync Enterprise Voice as their solution. The Customer’s HQ has 400 of the employees. The rest is working at three remote locations with various bandwidths.
The customer doesn’t have a bandwidth issue yet, but are worried some issues might arise if nothing is done to prevent it. This is how I could approach the customer:
- How much BW do they have to each location?
- How much available BW do they have, or can they set aside (using QOS)
- Based on answers from the two questions above; How much BW do you want to restrict for Audio and Video traffic?
The last question is the most important one, as it will result in direct guidelines on values to use in your policies.
The last question was answered with the following values:
- To Location “Remote1” they want to restrict traffic to 2MB
- To Location “Remote2” they want to restrict traffic to 4MB
- To Location “Remote3” they want to restrict traffic to 512k, and not allow video.
How do we go about and configure rules for this request? It’s easier than you might think. But before we begin, let me explain a couple of things:
- You cannot (to my knowledge) disable Video in your voice policies. But as you might see from my configuration, we can configure it almost “useless”.
- No matter what we configure in the policies. These settings only apply when the media stream leaves your subnet, and enters another subnet. (Setting a limit for audio or video size pr session will not restrict sessions within a subnet).
- These policies apply to both peer-to-peer sessions, and for conferences/meeting.
In addition to knowing how much BW the customer wants, we also need to know which subnets (the way clients are configured) each site has. Then we can get around doing some configuration.
Here is a simple set up:
- Remote1: 10.10.1.0/24 and 10.10.2.0/24
- Remote2: 10.20.1.0/24 and 10.20.2.0/24
- Remote3: 10.30.1.0/24
Let me briefly discuss the policy settings first, then take you through the implementation process.
There are 4 values you may set in a policy:
- Audio Limit
- Audio Session Limit
- Video Limit
- Video Session Limit
These values might make an impact on the user experience if you do not think things through. The Audio Limit is the total BW (in kbps) you will allow for all calls to that subnet. This value will add to the Video limit when calculating the total BW requirement. Why is this important to realize? Well, with the limitation of 2MB for the link. You better not type 2048 in the Audio limit and then 2048 in the Video limit, as that would actually make use of 4096 in total. See what I mean?
There are many ways to configure these values to suit your needs, but I’ll keep it simple with the following configuration (for now):
- Remote1: Audio Limit 512 and Video Limit 1510
- Remote2: Audio Limit 1024 and Video Limit 3020
- Remote3: Audio Limit 412 and Video Limit 100
And that’s all you think you have to do. But sadly, it’s not. There is a gotcha here somewhere, and I’m coming to it.
As it is, you need to (or really, really should) also configure the “session” values as well. Why? Well, take a look at Remote1. It has a Video limit of 1510. A single HD stream of video is 1510. And if a single call can negotiate this rate, it will use it and hold on to it for dear life.
Consequence? We could quite possibly soon learn there is only one person at the time in that location which would be able to stream video to another site. The second attempt will be blocked and will be alerted with a “not enough BW” message in the client.
But wait? Doesn’t Lync renegotiate the BW in use when network issues arise? Well, it still does, but the first stream does not see any issues, and will not negotiate down. CAC kind of breaks some these features. Which in one way, actually might be a good thing. Once a session is up and running, it will not change (unless there are real network issues somewhere). But the thing is: When the second session is attempted, CAC only looks at available BW. It does not query existing session to share the allowed BW.
This is why we need to also configure session limits. So here is my proposed setup:
- Remote1: Audio Limit 512, Audio Session Limit 45 and Video Limit 1510, Video Session Limit 250
- Remote2: Audio Limit 1024, Audio Session Limit 161 and Video Limit 3020, Video Session Limit 300
- Remote3: Audio Limit 412, Audio Session Limit 45 and Video Limit 100, Video Session Limit 100
This will allow Remote site to set up 11 (or so) calls with fair quality, even to the pstn if media bypass is not configured for the mediation server. And it will allow for 6 video streams (I am sure you can do the math on the rest of the locations).
Why then, have I allowed for 100kbps of video, when the customer wanted it disabled (but not disabled within the site). Simply because disabling it is not an option. It is better only to allow the one 100kbps stream, than not use any restriction at all.
If you are wondering where I got my figures, I based them loosely on the values given here:
http://technet.microsoft.com/en-us/library/gg413004.aspx
Finally, A quick list of what to do to enable CAC in Lync:
- Enable Call Admission Control on the central site in the topology builder, and assign which front end pool should be responsible for the service.
- Publish the topology, and deploy the service on the target pool (Running Lync Server Deployment Tool)
- Start the services related to CAC
- Go to the Lync Control panel (Or use PowerShell if that’s your thing :)
- Locate the “Network configuration” at the bottom left of the CSCP
- Enable “CAC” on the Global object
- Create your bandwidth profiles under the “Policy Profile” section
- Create (if it is not already there) a region for your topology (In a large environments, there will be several pools in several regions. But not here. I only have the one pool in one region)
- Create your sites, and add the policies as desired.
- Create subnets and associate them with the sites.
- Region Link and Region Routes are only used in larger deployments.
- Restart services (not necessary, but I always do it).
- Test your new rules.
That’s it, there is nothing more to it really, as for a basic setup that is. There are many more “nerd-knobs” to explore if you like. But you can get very far with a similar setup as described in this post. Other things to consider should include; exceptions to CAC (Implemented in Voice policies) and possible reroutes through PSTN if the wan is congested.
What you will have to do, which I did not previous to writing this. Is to analyze the company’s actual needs in terms of how many calls they want, and at which quality to offer services.
I cannot leave you without mentioning the excellent Resource Kit for Lync, in which you can see (live) the current utilization between the sites. Or the Monitoring server, which will tell you how many calls were dropped due to Network outage.
Comments