Topic Last Modified: 2010-03-19
New for the Mediation Server in Communications Server 2010 is the ability for a single Mediation Server to control multiple (N) gateways. In previous releases, there was a 1:1 ratio of Mediation Server to Gateways. Also new for Communications Server 2010 is the ability for a Mediation Server to be deployed as a pool; this pool can be collocated with the Registrar on an Enterprise Front End pool, or can be a standalone pool. When collocated with the Registrar, the pool size can be at most 10 (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 Communications Server 2010 certified
gateway must implement DNS load balancing, which allows a certified
IP-PSTN gateway to load balance across a pool of Mediation Servers
and thereby to connect to the first available Mediation Server in
the pool.
- SIP Trunk Session Border Controller (SBC). For a SIP
trunk, the peer entity is an SBC at a Service Provider. In the
direction from the Mediation Server pool to the SBC, the SBC can
receive connections from any MS in the pool; the MS is selected by
DNS Load Balancing by Outbound Routing. In the direction from the
SBC to the pool, want traffic to be sent to any MS in the pool. DNS
load balancing will probably not work for the Service Provider for
several reasons--DNS to resolve MS pool members not possible from
outside the corporation, provisioning complexity for the Service
Provider, SBCs don’t support getting a list of IP addresses after
DNS resolution. The model that is recommended instead is that the
customer will provide the Service Provider with the IP addresses of
the different MSs in the pool, and the Service Provider will
provision these in their SBC as different SIP Trunks. The Service
Provider will then handle doing the load balancing at its end. Not
all Service Providers or SBCs may support the capabilities detailed
above. Furthermore, the Service Provider may charge extra for this
capability. (Note--SBC redundancy could be achieved if the IP of
the SBC is a Virtual IP (VIP) that can terminate at different
physical SBCs, so that if an SBC goes down, there is a recovery
mechanism.)
- IP-PBX. For an IP-PBX peer, the peer entity is a SIP
control entity associated with the IP-PBX. In the direction from
the Mediation Server pool to this IP-PBX SIP termination, the
IP-PBX can receive connections from any MS in the pool; the MS is
selected by DNS Load Balancing by Outbound Routing. In the
direction from the IP-PBX to the pool, want traffic to be sent to
any MS in the pool. DNS load balancing will probably not
work, since most IP-PBXs do not support this. The model that is
recommended instead is that individual direct SIP trunks are
defined from the IP-PBX to each Mediation Server in the pool. The
IP-PBX will then handle doing the load balancing at its end, 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-PBXs own
redundancy/clustering architecture needs to be determined before a
decision can be made as to whether a Mediation Server cluster can
interact correctly with an IP-PBX.
A Mediation Server pool must have a uniform view of the peer gateway entity that it interacts with. This means that ALL members of the pool access the same definition of the peer gateway entity from configuration, and are equally likely to interact with it for outgoing calls. Thus, there is no capability to segment the pool such that some Mediation Servers only talk to 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 IP-PSTN gateways, SIP Trunks, or IP-PBXexs to interact with a pool as detailed above are not present.
A Communications Server 2010 deployment assumes that a particular IP-PSTN gateway, IP-PBX, or SIP Trunk peer depends on only a single Mediation Server pool; calls are routed to that pool by the Communications Server 2010 Front End/Registrar so that they can get to that gateway peer.
For SIP Trunks, IP-PBXes, and IP-PSTN gateways where a separate pool of Mediation Servers must be used (due to the fact that these entities do not support the correct capabilities to interact with a pool), the following scheme can be used to achieve redundancy:
- To solve multiple Mediation Servers interacting with the same
gateway peer entity, the admin needs to configure multiple virtual
gateways. Each gateway would be associated with a different FQDN,
which would resolve in DNS to the same IP address
- Individual standalone 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 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 Alternate Name part of the certificate provided by the
gateway peer.
- Note that the policy applied for interaction with the gateway
peer will be the policy associated with the first gateway object in
the configuration store that matches. This should not be an issue,
since the policy associated with all virtual gateways should be
identical (they all correspond to the same physical hardware).
- Communications 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 is dependent on the number of calls that are bypass. Bypass calls imply that the media does not flow through any Mediation Server in the pool. This in turn implies that a Mediation Server in the pool can handle many more calls, since only signaling plane processing is necessary. Contrast this to a case where the media flow can never bypass the Mediation Server.