Topic Last Modified: 2010-07-18
Following are some planning guidelines for Mediation Server deployment. After reviewing these guidelines, it is recommended that you use the Communications Server Planning Tool to create and view possible alternative topologies, which can serve as models for what the final tailored topology you decide to deploy could look like. For details about how to access and use the Planning Tool, see Using the Planning Tool to Design the Topology (Optional).
- Mediation Server is by default collocated on the Enterprise
Pool Front End Server at central sites. The number of PSTN calls
that can be handled and the number of machines required in the pool
will depend on the number of gateway peers that the Mediation
Server pool controls, the busy hour traffic through those gateways,
and the percentage of calls that are bypass calls. When planning,
make sure that after taking into account the processing
requirements for non-bypass PSTN calls and for the AVMCU (if it is
running on the same pool), there is enough processing to handle
signaling interactions (allow at least 30% of CPU for this) for the
number of busy hour calls that need to be supported. If there is
not, then a separate standalone pool of Mediation Servers will need
to be deployed, and PSTN gateways, IP-PBXs, and SBCs will need to
be split into subsets that are controlled by the collocated
Mediation Servers (pool 1) and the standalone Mediation Servers
(pool 2).
- If there are PSTN Gateways, IP-PBXs, SBCs that do not support
the correct capabilities to interact with a pool of Mediation
Servers, then such entities will need to be associated with a
standalone pool consisting of a single Mediation Server.
Additionally, if redundancy is needed in such cases, virtual
gateways will need to be created corresponding to the same physical
gateway as described earlier; each redundant MS would be
responsible for a trunk to a different virtual gateway.
- The Mediation Servers at the central site can be used to
control IP-PBXs or PSTN gateways at remote sites. Note that SIP
trunks require a Mediation Server at the site where they terminate.
Having a Mediation Server at the central site control an IP-PBX or
PSTN gateway at a remote site does not require the use of bypass.
However, if bypass can be used, it will result in improved media
quality via the elimination of the non-bypass call requirement that
the media path follow the signaling path, meaning reduced media
path latency. It will also decrease the processing load on the
pool.
- If remote site branch office resiliency is required, a
Survivable Branch Appliance or combination of a Front End and a
Mediation Server and a gateway must be deployed at the remote site.
(The assumption with branch office resiliency is that there is no
resilient presence or conferencing at the site.) For guidance on
branch site planning for voice, see Branch Site Voice
Resiliency.
- For interactions with an IP-PBX, if the IP-PBX does not
correctly support early media interactions and RFC 3960
interactions, there can be clipping of the first "Hello" for
incoming calls from the IP-PBX to Communications Server 2010
endponts. This problem could be made more severe if a Mediation
Server at a central site is controlling an IP-PBX with media
termination point at a remote site since the time for signaling
completion is increased. If this is an issue, then deploying a
Mediation Server at the remote site is the only choice to reduce
clipping of the first "Hello".
- If your central site has a TDM PBX, or if your IP-PBX does not
eliminate the need for an IP-PSTN gateway, then you must deploy a
gateway on the call route connecting Mediation Server and the
PBX.