Topic Last Modified: 2010-07-16
Increasingly, enterprises have multiple sites spread across the globe. Maintaining emergency services, access to help desk, and the ability to conduct critical business tasks when a central site is out of service is essential for any enterprise voice resiliency solution. When a central site becomes unavailable:
- Voice failover must be provided.
- Users who normally register with the central site Registrar
pool must be able to discover a new Registrar pool.
- Calls to and from users located at other sites must be rerouted
to the PSTN.
- Voice survivability must be provided for users when the
presence pool is unavailable.
This topic describes the recommended solution for securing central site voice resiliency.
Architecture and Topology
Planning for voice resiliency at a Central Site requires a basic understanding of the role played by the Microsoft Communications Server 2010 Registrar. The Registrar plays the central role in enabling voice failover scenarios.
The Communications Server 2010 Registrar is a server that enables client registration and authentication, and provides routing services. The Registrar is a new server role. It resides along with other components on a Standard Edition Server, Enterprise Front End Server, Director, or Survivable Branch Appliance. A Registrar pool consists of Registrar Services running on the Microsoft Communications Server pool and residing at the same site. The pool must be load balanced. DNS load balancing is recommended, but hardware load balancing is acceptable. A client connects to the Registrar pool FQDN and is then directed by the load balancing mechanism to one of the registrars in the pool.
Each user enabled for Enterprise Voice is assigned to a particular Registrar pool, which becomes that user’s primary Registrar pool. Typically, at a given site, hundreds or thousands of users share a single primary Registrar pool.
To assure voice resiliency in the event of central site failure, the primary Registrar pool must have a single designated backup Registrar pool located at another site. Assuming a resilient WAN link between the two sites, users whose primary Registrar pool is no longer available are automatically directed to the backup Registrar pool.
The following steps describe the client discovery and registration process:
- A client discovers Microsoft Communications Server through DNS
SRV. In Communications Server 2010, DNS SRV can be configured to
return more than one FQDN to the DNS SRV query. For example, if
enterprise Contoso has three central sites (North America, Europe,
and Asia-Pacific) and a Director pool at each central site, DNS SRV
can point to the Director pool FQDNs in each of the three
locations. As long as the Director pool in one of the locations is
available, the client is able to connect to the first hop
Note: Using a Director pool is optional. An Enterprise Edition pool may be used instead.
- The Director pool informs the client about the user’s primary
Registrar pool and backup Registrar pool.
- The client attempts to connect to the user’s primary Registrar
pool first. If the primary Registrar pool is available, it accepts
the registration. If the primary Registrar pool is unavailable, the
client attempts to connect to the backup Registrar pool. If the
backup Registrar pool is available, and has determined that the
user’s primary Registrar pool is unavailable (by detecting a lack
of heart beats for a specified failover interval) the backup
Registrar pool accepts the user’s registration.
The following figure shows the recommended topology for assuring central site resiliency. The two sites are connected by a resilient WAN link. If the central site becomes unavailable, users who are assigned to that pool are directed to the backup site for registration.
Requirements and Recommendations
The following requirements and recommendations for implementing central site voice resiliency are appropriate for most organizations:
- The sites in which the primary and backup Registrar pools
reside should be connected by a resilient WAN link.
- Each central site must contain a Registrar pool consisting of
one or more Registrars.
- Each Registrar pool must be load-balanced by using DNS load
balancing or hardware load balancing.
- Each user must be assigned to a primary Registrar pool.
- The primary Registrar pool must have a single backup Registrar
pool located in the backup central site.
- The primary Registrar pool must be configured to fail over to
the backup Registrar pool. The failover interval is configurable by
an administrator. Default is 300 seconds.
Communications Server depends on the following infrastructural and software components to assure voice resiliency:
Resolving SRV records and A records for server-server and server-client connectivity
Exchange and Exchange Web Services (EWS)
Contact storage; calendar data
Exchange Unified Messaging and Exchange Web Services
Call logs, voice mail list, voice mail
DHCP Options 120
If DNS SRV is not available, the client will attempt to use DHCP Option 120 to discover the Registrar. For this to work, either a DHCP server must be configured or Communications Server 2010 DHCP must be enabled. For more information, see Hardware and Software Requirements in the Branch-Site Voice Resiliency section.
Survivable Voice Features
Assuming that the above requirements and recommendations have been implemented, the following voice features will be provided by the backup Registrar pool:
- Outbound PSTN calls
- Inbound PSTN calls, if the carrier provides the ability to
failover to a backup site
- Enterprise calls between users at both the same site and two
- Basic call handling, including call hold, retrieval, and
- Authentication and authorization
- Two-party instant messaging and audio/video between users at
the same site
- Call Detail Records (CDR)
- Call forwarding, simultaneous ringing of endpoints,
boss-administrator and team call services
- Existing phones and clients continue to work
The following voice features do not work when a primary central site is out of service:
- Voice mail deposit and retrieval
- Conference Auto-Attendant
- Conferencing of all types
- Presence and DND-based routing
- Updating call forwarding settings
- Response Group Service and Call Park
- Provisioning new phones and clients