1. Network Configuration
Planning the network configuration first is key when
beginning to plan for Call Admission Control, Media Bypass, or Enhanced
911 services in Lync Server 2010. Each of these components relies on
network regions, sites, and links to be configured correctly before they
can be enabled. The definition of each region, sites, and subnets might
seem overwhelming at first, but it offers quite a bit of flexibility
and control over call routing.
There are a few basic components that must first be understood when planning for these services:
Regions—
Network regions are the backbone of a network. Each network region must
be associated with a Lync Server central site defined within the
topology. This is a site where Lync Front End Servers are deployed and
users are homed. Network regions are typically a hub where many other
network sites are connected. Examples of regions are North America and
Europe, or even on a smaller scale such as West Coast and East Coast.
Sites— Each network region consists of at least one site and possibly many more. Sites
are offices or locations that are associated with the major network
region. In other words, all the offices or locations that have users
homed in the central site for the region should be created as sites.
This site definition should not be confused with the central site to
which the network region was associated. In fact, a network site object
should also be created for the central site if users or voice gateways
are physically located there. This might seem redundant, but is required
for appropriate routing.
Subnets—
Each site defined should contain at least one subnet definition. Each
subnet used at a site should be entered and associated with the correct
site. Lync endpoints are associated with a site and region by matching
to a subnet defined here.
The Call Admission Control and Media Bypass features rely on matching
the subnet of the IP/PSTN gateway to callers, so be sure to include the
subnets used for voice hardware.
Bandwidth Policy Profiles—
Bandwidth policy profiles define a network link speed and the available
bandwidth for audio or video calls. Both the individual session limit
(two-way) can be specified as well as the total amount of bandwidth used
for audio and video traffic. Bandwidth policy profiles are associated
with a site or region link. Sites do not require a bandwidth policy
profile to be assigned. In fact, if sites within a region are not
bandwidth constrained, no profile should be assigned. Assign bandwidth
policy profiles only to sites that should have their audio and video WAN
usage limited.
Region Links—
When multiple regions exist, and by definition a region is multiple
Front End pools with different central sites, region links should be
defined that identify the amount of bandwidth available between regions.
When defining a region link two regions are required as well as a
bandwidth policy profile to apply between the two regions.
Region Route—
A region route specifies how two regions should be connected. In many
cases, a region route mimics a region link and can just be between two
different regions. In other cases where two regions are not directly
linked, but share a link to a common region, a region route defines how
these regions must traverse the common region to communicate. In that
case, two different region links must be crossed, which might each have a
different bandwidth policy profile.
Site Link—
The final component of the network configuration is a site link. In
most cases, sites are connected to a network region directly, which acts
as a hub for the users. There might be instances where in addition to a
connection to the network region central site, sites have a direct
connection to each other that bypasses the central site. Site links are
used to create these objects that can then have a bandwidth policy
profile associated.
Figure 1 depicts a sample configuration. The definition of each component will vary based on the organization.
2. Call Admission Control
Planning to deploy call admission control features in
Lync Server 2010 is going to depend greatly on the network
configuration discussed in the previous section. The basis for this is
because this feature relies heavily on locating an endpoint based on
subnet and then applying policies appropriately. Call Admission Control
in Lync Server 2010 applies to both audio and video traffic, but
organizations can specify different limits for each type of traffic.
Both a session limit (two-way traffic) and a total limit for all
sessions can be specified.
The
key to successful Call Admission Control deployment is to correctly
define and associate the bandwidth policy profiles to sites and links by
completing the following steps:
1. | Identify the connection speed of each WAN link to sites that are bandwidth constrained.
|
2. | Define
the maximum audio and video session and total bandwidth limits to be
used by Lync endpoints associated with site and policy. These limits
vary based on the desired traffic type and the different audio codecs
used.
|
3. | Evaluate
the site and make some estimates on the type of audio codecs used to
create an appropriate limit. For example, if users make several
Lync-to-Lync calls, RTAudio is predominantly used. If most calls are
conferences, Siren might be more prevalent.
|
Bandwidth Estimates
Table 1
defines the various bandwidth estimates for each protocol. Usually the
typical bandwidth usage values can be used for planning purposes.
Forward error correction (FEC) is enabled when Lync clients detect poor
network connectivity and attempts to provide a more resilient voice
connection to combat network jitter or latency.
Table 1. Bandwidth Codec Estimates
Codec | Planning Value | Maximum Bandwidth without FEC | Maximum Bandwidth with FEC |
---|
RTAudio (Narrowband) | 26 kbps | 40 kbps | 52 kbps |
RTAudio (Wideband) | 35 kbps | 57 kbps | 86 kbps |
Siren | 22 kbps | 52 kbps | 68 kbps |
G.711 | 60 kbps | 92 kbps | 156 kbps |
RTVideo (CIF) | 203 kbps | 250 kbps | N/A |
RTVideo (VGA) | 492 kbps | 600 kbps | N/A |
When a
bandwidth policy limit is exceeded by a user, Call Admission Control
kicks in with an attempt to reroute the call. First, the call attempts
to be directed over the Internet. Instead of using the WAN link, the
call traverses the Internet and Edge infrastructure. If that is not
possible or fails, the call can reroute across the PSTN. Whether this is
allowed depends on whether the voice policy assigned to the user allows
this feature. If neither Internet nor PSTN rerouting is possible, the
call will attempt to be sent directly to voicemail. Lastly, if voicemail
is unavailable, the call will simply fail.
Note
Whether PSTN rerouting or bandwidth policy override is allowed for a call depends on the voice policy of the user receiving
the call. Enable these features carefully because they can have a
significant effect on how calls are routed. If limiting the WAN
bandwidth with a policy is in effect, be sure the local IP/PSTN gateway
can support the number of calls expected to be rerouted when enabling
PSTN rerouting.
It is also important to note that Call Admission
Control only applies to Lync Server endpoints traversing a WAN link.
Other applications transmitting data on the same WAN link are not
affected by Lync Call Admission Control policies. Organizations can
define a bandwidth limit for Lync traffic and still see that WAN link
become saturated due to other applications. In this scenario, it makes
sense to enforce QoS policies on the WAN link to ensure Lync endpoints
can always place calls.
The bandwidth override policy is enforced by the
receiving endpoint and not the sender. When a call is placed, the
receiving endpoint leverages its subnet information and checks whether
the call will exceed the bandwidth policy limit. If not, the call will
be allowed.
The only clients that actually respect Call Admission
Control policies are Lync 2010 endpoints. Earlier clients, such as
Office Communicator 2007 R2, are not able to perform a bandwidth check
when a Lync client calls. However, media calls from Office Communicator
2007 R2 to a Lync endpoint enforce Call Admission Control policies.