In this post I will stay at the 100 level because I don’t think I could cover Call Admission Control (CAC) in just one post in any great depth. When you first look at the configuration for CAC it may start to get a little confusing. But the most important thing you can do with CAC is to plan, plan, plan. I could say it again but I think you get the message. Outlining your complete network is going to be critical to establish the correct admission control requirements. You will also need to either use a combination of the Control Panel with PowerShell or just use PowerShell to make a successful CAC configuration.
More about regions, sites and subnets with CAC
While my opening post helped open the conversation about Regions, Sites and subnets it was a high level view that wasn’t focused on CAC. Now we are here lets dive a little deeper in relation to CAC. For information from Technet on this topic see here.
Network Regions – Network hub or backbone. Every network site must be associated with a network region. This concept seems a little odd when looking at the above diagram. Here is why. The sites drawn inside the circle are highly connected and CAC is not required. Those outside the green region circles require a bandwidth policy applied to their links although. This diagram is taken directly from the CAC planning guide and it really doesn’t explain that part. Just know that every site must be associated with a region and that remote sites like Portland in the example also require a bandwidth policy to enable CAC.
Central site – This is where you Lync pool resources are located and must be associated with a network region. Every network region is owned by a central site.
Network site – Can be a remote location, campus or a set of buildings. Basically it’s a set of IP subnets that have that are highly connected. In the example diagram Reno and New York are examples of a network sites. The difference between these two sites is New York is a highly connected site that does not require CAC policy applied to it. So if someone in Chicago is calling someone in New York there would be no restrictions. Reno on the other hand is bandwidth limited and does require the use of CAC. So if someone in Reno makes or received a call from any other sites in the North American region CAC would be applied.
Network Links - In the example there are a number of different link scenarios. They are Region to region (NA – EMEA), site to region (Portland –NA), site to site(inter-site) (Reno-Albuquerque). How you plan out your CAC requirements will largely come from your networking team who will have a vested interested in bandwidth usage. Not all sites require a bandwidth Policy applied directly to them. New York is a good example.
This is the most important stage in the process of deploying CAC. There is excellent guidance available in the Planning for Enterprise Voice Lync Server 2010 guide. So rather than belabor the point I will point to the guide on the best methods for planning.
How to configure CAC
This is a rough break down with the basic steps. As your network gets more complex as will your network mapping. First step is to enable CAC.
Figure 1 Enable CAC
Next, define a Central Site and associate it to a region. Central site is a site with Lync Server 2010 deployment or pool. In this case my central site is called home (my home lab).
Figure 2 Configure a region and central site
Figure 3 Define sites within region
Figure 4: Define a Bandwidth Policy
Figure 5 Define Links
Figure 6 Define Routes
Some network configuration tasks cannot be performed by using Lync Server Control Panel. For example, to create inter-site links, refer to the Lync Server 2010 Management Shell documentation for the New-CsNetworkIntersitePolicy.
The last screen shot is to highlight the ability to enable certain folks the ability to not be control by bandwidth restriction. This can be controlled through the voice policy so you can apply it to multiple users . See Jens blog for a more in-depth explanation of this feature http://blogs.technet.com/b/jenstr/archive/2010/10/07/bandwidth-management.aspx.
Benefits of CAC
Being able to define and control a roaming users use of WAN bandwidth is critical in some organizations. Unlike some systems that define CAC based on a single location for a device, Microsoft designed CAC with the roaming user in mind which is important as softphone technology becomes more prevalent.
- No matter where a user is located CAC can be applied according to the sites policy without requiring any direct user or network configuration
- Not only can you limit the number of audio and video calls you can also limit the amount of bandwidth those video or voice calls make per call
- For calls that exceed the predefined max, they can be redirected to an alternate PSTN gateway or the internet if edge servers are in place.
- Codec selection by the client can be maximized. The client will pick the codec that uses the least amount of bandwidth based on the max bandwidth allowed per call defined by the administrator. So potentially you could force all calls across a WAN link to default to G.722 if you set your max bandwidth per call below the threshold of RTAudio.
Points to keep in mind about CAC
1. The Mediation Server cannot enforce CAC when Media Bypass is in use which in any case the use of CAC should not be required.
2. CAC cannot be enforced on clients prior to Lync. So if you have Communicator 2007 R2 and lower registering to Lync Server during a migration period CAC will not work for those clients until they are migrated Lync.
3. Does not affect data. So this includes web conferencing and desktop sharing.
4. Better together with Quality of Service (QoS). You cannot achieve complete call quality relying solely on CAC. CAC is for bandwidth consumption control. It doesn’t not affect what happens on the wire. So if you configure CAC for a WAN link to a remote site other data can still affect your call quality over that link unless you deploy QoS. QoS is a big subject with a number of different ways to configure and maintain depending on your Enterprise QoS architecture. In saying that CAC is independent of QoS for the purposes of network configuration. Lync CAC does not require any specific network configuration nor is there any dependency on QoS.
5. Beware that if you are to deploy CAC anywhere in your network, all subnets need to be entered into Lync Server 2010. This is critical as the Bandwidth Policy Server coordinates bandwidth limitations based on your current location and not where you are homed which it cannot do unless you map your entire network. This sounds like a lot of work but it’s really not to bad as long you have a good list of where your subnets map to your network. Entering the subnets into Lync as a site will most likely be the easy bit. Gathering all the required network subnet information from your network will be the hard part. Hopefully you have a diligent network team that has documented all this information. If you have then its nothing more than transferring information to a csv file that can be uploaded via PowerShell script into Lync.
From the help file. How to assign subnets from a CSV file:
- Create a CSV file that includes all of the subnets you want to add. For example, create a file named subnet.csv with the following content:
IPAddress, mask, description, NetworkSiteID
18.104.22.168, 24, "NA:Subnet in Portland", Portland
22.214.171.124, 24, "NA:Subnet in Reno", Reno
126.96.36.199, 25, "EMEA:Subnet in Warsaw", Warsaw
188.8.131.52, 31, "EMEA:Subnet in Paris", Paris
- Start the Lync Server Management Shell: Click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Management Shell.
Although this is not a complete guide to implementing CAC my hope was to cover the basics without having the need to read the planning guides before diving in.
Other posts in this series:
Regions, Sites and Subnets