Topic Last Modified: 2011-02-25

Planning for call admission control (CAC) requires detailed information about your enterprise network topology. To help plan your call admission control policies, follow these steps.

Identify the hubs/backbones (called network regions) within your enterprise network.
Identify the offices or locations (called network sites) within each network region.
Determine the network route between every pair of network regions.

Determine the bandwidth limits for each WAN link.

Note:
Bandwidth limits refer to how much of the bandwidth on a WAN link is allocated to Lync Enterprise Voice and audio/video traffic. Therefore, when a WAN link is described as “bandwidth-constrained”, the WAN link has a bandwidth limit that is lower than the expected peak traffic over the link.

Identify the IP subnets that are assigned to each network site.

To explain these concepts, we’ll use the example network topology shown in the following figure.

Note:
All network sites are associated with a network region. For example, Portland, Reno and Albuquerque are included in the North America region. In this figure, only WAN links that have CAC policies applied are shown, with bandwidth limits. Network sites Chicago, New York, and Detroit are shown inside the North America region oval because they are not bandwidth-constrained and therefore do not require CAC policies.

Note:

All network sites are associated with a network region. For example, Portland, Reno and Albuquerque are included in the North America region. In this figure, only WAN links that have CAC policies applied are shown, with bandwidth limits. Network sites Chicago, New York, and Detroit are shown inside the North America region oval because they are not bandwidth-constrained and therefore do not require CAC policies.

The components of this example topology are explained in the following subsections. For details about how this topology was planned, including the bandwidth limits, see Example: Gathering the Required Information for Call Admission Control.

Identify Network Regions

A network region represents a network backbone or a network hub.

A network backbone or hub is a part of computer network infrastructure that interconnects different parts of the network, providing a path for the exchange of information between different LANs or subnets. A backbone can tie together diverse networks from a small location to a wide geographic area. The backbone's capacity is typically greater than that of the networks that connect to it.

Our example topology has three network regions: North America, EMEA, and APAC. A network region contains a collection of network sites (see definition of network sites in this topic). Work with your network operations team to identify your network regions.

Associating a Central Site with each Network Region

CAC requires that for each network region, a Lync Server central site. A software component in the Lync Server makes CAC decisions. The preceding example network topology shows three network regions, each with a central site that manages CAC decisions. This central site is chosen by the geographic vicinity. Because media traffic is heaviest within network regions, assigning ownership by geographic vicinity makes the network region self-contained; communications within a network region will continue even if other central sites become unavailable. From the preceding example, the appropriate association is as shown in the following table.

Note:
Central sites do not necessarily correspond to network sites. However, in the examples in this documentation, the names of some central sites—Chicago, London, and Beijing--are the same as some of the network sites. Even if a central site and network site share the same name, the central site is an element of the Lync Server topology. The network site is a part of the overall network in which the Lync Server topology resides.

Note:

Central sites do not necessarily correspond to network sites. However, in the examples in this documentation, the names of some central sites—Chicago, London, and Beijing--are the same as some of the network sites. Even if a central site and network site share the same name, the central site is an element of the Lync Server topology. The network site is a part of the overall network in which the Lync Server topology resides.

Network regions, central sites, and network sites

Network Region	Central Site	Network Sites
North America	Chicago	Chicago New York Detroit Portland Reno Albuquerque
EMEA	London	London Cologne
APAC	Beijing	Beijing Manila

Identify Network Sites

A network site represents a location where your organization has offices, a set of buildings, or a campus. Start by inventorying all of your organization’s offices. In our example topology, the North America network region consists of the following network sites: New York, Chicago, Detroit, Portland, Reno, and Albuquerque.

You must associate every network site with a network region. Depending on whether or not the network site has a constrained WAN link, a bandwidth policy is associated with the network site. For details about CAC policies and the bandwidth that you allocate by using them, see “Define Bandwidth Policies” later in this topic. To configure CAC, you associate network sites with network regions, and then you create bandwidth-allocating policies to apply to the bandwidth-constrained connections between a given site or region and the WAN connections between the sites and regions.

Identify Network Links

Network links represent connections to the physical WAN that links different regions and sites. In our example topology, there are two regional network links, five network links between regions and sites, and one network link between two sites.

The two regional links are between North America and EMEA, represented as NA-EMEA-LINK, and between APAC and EMEA, represented as EMEA-APAC-LINK.

The site links are indicated by the lines connecting Portland, Reno, and Albuquerque to the North America region, Manila to the APAC region, and Cologne to the EMEA region. The line between Reno and Albuquerque shows a direct network link between these two sites.

Define Bandwidth Policies

Work with your network operations team to determine how much WAN bandwidth is available for real-time audio and video traffic across the WAN links in your organization. Bandwidth policies are typically applied to WAN links if the bandwidth usage is constrained, that is, if it expected to be more than the bandwidth that can be allocated for audio and video modalities.

CAC bandwidth policies define how much bandwidth is reserved for real-time audio and video modalities.

CAC bandwidth policies can define any or all of the following:

Maximum total bandwidth allocated for audio
Maximum total bandwidth allocated for video
Maximum bandwidth allocated for a single audio call (session)
Maximum bandwidth allocated for a single video call (session)

Note:
All CAC bandwidth values represent the maximum unidirectional bandwidth limits.

Note:
The Lync Server 2010 Voice Policy features provide the ability to override bandwidth policy checks for incoming calls to the user (not for outgoing calls that are placed by the user). After the session is established the bandwidth consumption will be accurately accounted for. This setting should be used sparingly and should be avoided for appropriate call admission control decisions. For details, see Create a Voice Policy and Configure PSTN Usage Records or Modify a Voice Policy and Configure PSTN Usage Records in the Deployment documentation.

Note:

The Lync Server 2010 Voice Policy features provide the ability to override bandwidth policy checks for incoming calls to the user (not for outgoing calls that are placed by the user). After the session is established the bandwidth consumption will be accurately accounted for. This setting should be used sparingly and should be avoided for appropriate call admission control decisions. For details, see Create a Voice Policy and Configure PSTN Usage Records or Modify a Voice Policy and Configure PSTN Usage Records in the Deployment documentation.

To optimize bandwidth utilization on a per-session basis, consider the type of audio and video codecs that will be used. In particular, avoid underallocating bandwidth for a codec that you expect to be used frequently. Conversely, if you want to prevent media from using a codec that requires more bandwidth, you should set the maximum bandwidth per session low enough to discourage such use. For audio, not every codec is available for every scenario. For example:

Peer-to-peer audio calls between Lync 2010 endpoints will use either RTAudio (8kHz) or RTAudio (16kHz) when you factor in the bandwidth and prioritization of codecs.
Conference calls between Lync 2010 endpoints and the A/V Conferencing service will use either G.722 or Siren.
Calls to the PSTN either to or from Lync 2010 endpoints will use either G.711 or RTAudio (8kHz).

Use the following table to help optimize the maximum per-session bandwidth settings.

Bandwidth utilization by codecs

Codec	Bandwidth requirement with no forward error correction (FEC)	Bandwidth requirement with forward error correction (FEC)
RTAudio (8kHz)	49.8 kbps	61.6 kbps
RTAudio (16kHz)	67 kbps	96 kbps
Siren	57.6 kbps	73.6 kbps
G.711	102 kbps	166 kbps
G.722	105.6 kbps	169.6 kbps
RTVideo (CIF 15 fps)	260 kbps	Not applicable
RTVideo (VGA 30 fps)	610 kbps	Not applicable

Note:
Bandwidth requirements take into account overhead for the following: Ethernet II, IP, UDP, RTP, and SRTP. They also include 10 kbps for RTCP overhead.

The G.722.1 and Siren codecs are similar, but they offer different bit rates.

G.722, the default codec for Lync Server 2010 conferencing, is completely different from the G.722.1 and Siren codecs.

The Siren codec is used in Lync Server 2010 in the following situations:

If the bandwidth policy is set too low to allow G.722 to be used
If a Communications Server 2007 or Communications Server 2007 R2 client connects to a Lync Server 2010 conferencing service (because those clients do not support the G.722 codec)

Bandwidth utilization by scenario

Scenario	Bandwidth requirement optimized for quantity (kbps)	Bandwidth requirement for Balanced mode (kbps)	Bandwidth requirement optimized for quality (kbps)
Peer-to-peer audio calls	45 kbps	62 kbps	91 kbps
Conference calls	53 kbps	101 kbps	165 kbps
PSTN calls (between Lync 2010 and PSTN gateway, with media bypass)	97 kbps	97 kbps	161 kbps
PSTN calls (between Lync 2010 and Mediation Server, without media bypass)	45 kbps	97 kbps	161 kbps
PSTN calls (between Mediation Server and PSTN gateway, without media bypass)	97 kbps	97 kbps	161 kbps

Identify IP Subnets

For each network site, you will need to work with your network administrator to determine what IP subnets are assigned to each network site. If your network administrator has already organized the IP subnets into network regions and network sites, then your work is significantly simplified.

In our example, the New York site in the North America region is assigned the following IP subnets: 172.29.80.0/23, 157.57.216.0/25, 172.29.91.0/23, 172.29.81.0/24. Suppose Bob, who typically works in Detroit, travels to the New York office for training. When he turns on his computer and connects to the network, his computer will get an IP address in one of the four ranges that are allocated for New York, for example 172.29.80.103.

Warning:
The IP subnets specified during network configuration on the server must match the format provided by client computers in order to be properly used for media bypass. A Lync 2010 client takes its local IP address and masks the IP address with the associated subnet mask. When determining the bypass ID associated with each client, the Registrar will compare the list of IP subnets associated with each network site against the subnet provided by the client for an exact match. For this reason, it is important that subnets entered during network configuration on the server are actual subnets instead of virtual subnets. (If you deploy call admission control, but not media bypass, call admission control will function properly even if you configure virtual subnets.) For example, if a client signs in on a computer with an IP address of 172.29.81.57 with an IP subnet mask of 255.255.255.0, Lync 2010 will request the bypass ID associated with subnet 172.29.81.0. If the subnet is defined as 172.29.0.0/16, although the client belongs to the virtual subnet, the Registrar will not consider this a match because the Registrar is specifically looking for subnet 172.29.81.0. Therefore, it is important that the administrator enters subnets exactly as provided by clients (which are provisioned with subnets during network configuration either statically or by DHCP.)

Warning:

The IP subnets specified during network configuration on the server must match the format provided by client computers in order to be properly used for media bypass. A Lync 2010 client takes its local IP address and masks the IP address with the associated subnet mask. When determining the bypass ID associated with each client, the Registrar will compare the list of IP subnets associated with each network site against the subnet provided by the client for an exact match. For this reason, it is important that subnets entered during network configuration on the server are actual subnets instead of virtual subnets. (If you deploy call admission control, but not media bypass, call admission control will function properly even if you configure virtual subnets.)

For example, if a client signs in on a computer with an IP address of 172.29.81.57 with an IP subnet mask of 255.255.255.0, Lync 2010 will request the bypass ID associated with subnet 172.29.81.0. If the subnet is defined as 172.29.0.0/16, although the client belongs to the virtual subnet, the Registrar will not consider this a match because the Registrar is specifically looking for subnet 172.29.81.0. Therefore, it is important that the administrator enters subnets exactly as provided by clients (which are provisioned with subnets during network configuration either statically or by DHCP.)