Topic Last Modified: 2011-03-24

New for the Mediation Server in Lync Server 2010 is the ability for a single Mediation Server to control multiple gateways. In previous releases, there was a 1:1 ratio of Mediation Servers to gateways. A given gateway can be assigned to multiple call routes and associated with one Mediation Server or a pool of Mediation Servers. Multiple gateways can be associated with either a single Mediation Server or a pool of Mediation Servers. In this release, the number of gateways that a given Mediation Server can handle depends on the processing capacity of the server during peak busy hours. If you deploy a Mediation Server on hardware that exceeds the minimum hardware requirements for Lync Server 2010, as described in “Supported Hardware” in the Supportability documentation, then the estimate of how many active calls a stand-alone Mediation Server can handle is approximately 1000 calls. When deployed on hardware meeting these specifications, the Mediation Server is expected to perform transcoding, but still route calls for multiple gateways even if the gateways do not support media bypass.

When defining a call route, you specify the gateways associated with that route, but you do not specify which Mediation Servers are associated with that route. Instead, you use Topology Builder to associate gateways, and therefore routes, with Mediation Servers. In other words, routing determines which gateway to use for a call and the Mediation Server associated with that gateway handles the call.

Also new for Lync Server 2010 is the ability for a Mediation Server to be deployed as a pool; this pool can be collocated with a Front End pool, or it can be deployed as a stand-alone pool. When a Mediation Server is collocated with a Front End pool, the pool size can be at most 10 (the limit of the Registrar pool size). Taken together, these new capabilities increase the reliability and deployment flexibility for Mediation Servers, but they require associated capabilities in the following peer entities:

• PSTN gateway. A Lync Server 2010 qualified gateway must implement DNS load balancing, which allows a qualified PSTN gateway to act as a load balancer for one pool of Mediation Servers and thereby to load balance calls across the pool.
  
  
• Session Border Controller. For a SIP trunk, the peer entity is a Session Border Controller (SBC) at an Internet telephony service provider. In the direction from the Mediation Server pool to the SBC, the SBC can receive connections from any Mediation Server in the pool. In the direction from the SBC to the pool, traffic can be sent to any Mediation Server in the pool. One method of achieving this is through DNS load balancing, if supported by the service provider and SBC. An alternative is to give the service provider the IP addresses of all Mediation Servers in the pool, and the service provider will provision these in their SBC as a separate SIP trunk for each Mediation Server. The service provider will then handle the load balancing for its own servers. Not all service providers or SBCs may support these capabilities. Furthermore, the service provider may charge extra for this capability. Typically, each SIP trunk to the SBC incurs a monthly fee.
  
  Alternatively, the service provider can configure a single SIP trunk to your site and you can deploy a hardware load balancer between the SBC and the Mediation Server pool (or Mediation Servers collocated on the Front End pool). With this configuration, if you add a new Mediation Server, the service provider configuration need not change. SBC redundancy could be achieved if the IP of the SBC is a virtual IP (VIP) that can terminate at different physical SBCs. In that case, if an SBC becomes unavailable, there is a recovery mechanism.
  
  
• IP-PBX. In the direction from the Mediation Server pool to the IP-PBX SIP termination, the IP-PBX can receive connections from any Mediation Server in the pool. In the direction from the IP-PBX to the pool, traffic can be sent to any Mediation Server in the pool. Because most IP-PBXs do not support DNS load balancing, we recommend that individual direct SIP connections be defined from the IP-PBX to each Mediation Server in the pool. The IP-PBX will then handle its own load balancing by distributing traffic over the trunk group. The assumption is that the trunk group has a consistent set of routing rules at the IP-PBX. Whether a particular IP-PBX supports this trunk group concept and how it intersects with the IP-PBX’s own redundancy/clustering architecture needs to be determined before you can decide if a Mediation Server cluster can interact correctly with an IP-PBX.
  
  

A Mediation Server pool must have a uniform view of the peer gateway with which it interacts. This means that all members of the pool access the same definition of the peer gateway from the configuration store and are equally likely to interact with it for outgoing calls. Thus, there is no way to segment the pool so that some Mediation Servers communicate with only certain gateway peers for outgoing calls. If such segmentation is necessary, a separate pool of Mediation Servers must be used. This would be the case, for example, if the associated capabilities in PSTN gateways, SIP trunks, or IP-PBXs to interact with a pool as detailed earlier in this topic are not present.

A Lync Server 2010 deployment assumes that a particular PSTN gateway, IP-PBX, or SIP trunk peer depends on only a single Mediation Server pool; calls are routed to that pool by the Lync Server 2010 Front End pool so that they can get to that gateway peer.

For SIP trunks, IP-PBXs, and PSTN gateways where a separate pool of Mediation Servers must be used, the following scheme can be used to achieve redundancy:

• To solve multiple Mediation Servers interacting with the same gateway peer entity, you need to configure multiple virtual gateways. Each gateway would be associated with a different FQDN, which DNS would resolve to the same IP address.
  
  
• Individual stand-alone Mediation Servers (for example, a pool of one Mediation Server) would be used, and a trunk would be defined from a Mediation Server to a virtual gateway; each redundant Mediation Server would be responsible for a trunk connection to a different virtual gateway.
  
  
• For this scheme to work for gateway peers that support TLS, the FQDN for each virtual gateway needs to be in the subject name or subject alternative name part of the certificate provided by the gateway peer.
  
  
• The policy that is applied for interaction with the gateway peer will be the policy that is associated with the first gateway object in the configuration store that matches. This should not be an issue, because the same policy should be associated with all virtual gateways. (The virtual gateways all correspond to the same physical hardware.)
  
  
• Lync Server 2010 routes will use different virtual gateways. Each virtual gateway will depend on a different Mediation Server.
  
  

The number of gateways that a particular pool of Mediation Servers can control depends on the number of calls that use media bypass. If a large number of calls use media bypass, a Mediation Server in the pool can handle many more calls, because only signaling layer processing is necessary.