Thursday, January 20, 2011

HOW TO: Use Call Admission Control to actually control a call in Lync Server 2010

So you may have done some reading on what Call Admission Control (CAC) in Lync Server 2010 does and how it can add value in a distributed environment. There are several guides out there on the terminology and overview of CAC but I've found a slight gap in the practical application of it.

Throughout reading the Microsoft documentation on Lync Server 2010 including the CHM file, I've stitched together what I believe is a reference design for CAC and the steps necessary to get it to actually work.

First, you need to make sure you've configured CAC network regions, sites, subnets, policies, links and routes. If you haven't done your reading yet, buckle down and understand the concepts using this link: http://technet.microsoft.com/en-us/library/gg398842.aspx.

At a high level, it looks like this:
  1. Create a CAC Policy Profile (a.k.a. Bandwidth Policy).
  2. Create a Region and make sure you enable the "Enable audio alternate path" option.
  3. Create your Sites, link them to a Region, and assign your Bandwidth Policy (a.k.a. Policy Profile).
  4. Create your Subnets and assign them to a Site.
  5. Optional: If you have multiple Regions, you need to do two things. First, you need to create a Region link stitching together both Regions (i.e. Canada_to_USA_Region_Link). Second, you must create a Region Route even if you have only one Region Link....more on this later.
Enable audio alternate path in your Region


Once you have the network configuration portion complete, you need to make sure you've configured a voice policy for your users which permit rerouting of phone calls and finally enable CAC in your global network configuration.

Enable call admission control in your Global network configuration

Enable PSTN reroute on your voice policy for your users

So with all this configured, let's talk about what happens when you call someone over a link which is bandwidth constrained, has a CAC policy, and doesn't have enough bandwidth. Here's the story:

Jason is in Edmonton where he has a Branch Survivable Gateway.

Anton is in Calgary where he sits next to the Front-End server, Mediation Server, and a Direct SIP connection to Cisco Call Manager.

Both Edmonton and Calgary are connected by a WAN link which is limited to 10Mb.

Jason has a voice policy with the "Enable PSTN reroute" option set to 'enabled' and the "Enable bandwidth policy override" option set to 'disabled'.

Jason calls Anton using his Lync 2010 client.

Both users are in the "Canada" Region which has the option for "Enable audio alternate path" enabled.

The Canada Region contains both the Calgary and Edmonton Site.

The Edmonton site has a bandwidth policy which, based on current bandwidth consumption, is fully consumed. This would normally prevent the call from proceeding.

Instead of the CAC policy stopping the call or sending it to Anton's voicemail, the call is rerouted out Jason's local PSTN gateway as configured in his Lync Server topology.

Nice eh?

Well what happens if "Enable PSTN reroute" isn't turned on in Jason's voice policy? Well the call would end up being answered by Exchange UM or simply denied with a message being displayed to the user.

What if Jason's voice policy has "Enable bandwidth policy override" turned on? Well the call would proceed over the WAN without obeying the CAC policy. You may want to enable this option for special voice policies tied to certain staff members.

What if Anton's voice policy doesn't have the "Enable bandwidth policy override" turned on and Jason calls him and his IS turned on? Well the call will be denied as CAC works both ways. The only way for the call to proceed is if Jason's policy permits PSTN reroute.

Now I'm still learning the underlying framework here and a lot of the "how it works" along with answers to questions in my head remain unanswered. I'll update this post with more detail as it becomes available.

Cheers!

p.s. This ain't your momma's CAC....

1 comment:

  1. Nice post, i am scratching my head on probably the same topics...

    ReplyDelete