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:

1. 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 Communications Server.
   
   

   Note:
   Using a Director pool is optional. An Enterprise Edition pool may be used instead.

2. The Director pool informs the client about the user’s primary Registrar pool and backup Registrar pool.
   
   
3. 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.
  
  

Dependencies

Communications Server depends on the following infrastructural and software components to assure voice resiliency:

Component	Functional
DNS	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 different sites
  
  
• Basic call handling, including call hold, retrieval, and transfer
  
  
• 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
  
  

See Also

Other Resources

Branch-Site Voice Resiliency

---

Recommended topology for central site voice resiliency