Design Guidelines for Multisite WAN with Distributed Call-Processing
Deployment
A multisite WAN deployment with distributed call processing has many of the same
requirements as a single site or a multisite WAN deployment with centralized call processing.
Follow the best practices from these other models in addition to the ones listed
here for the distributed call processing model.
Gatekeeper or SIP proxy servers are among the key elements in the multisite WAN model
with distributed call processing. They each provide dial plan resolution, with the gatekeeper
also providing call admission control. A gatekeeper is an H.323 device that provides
call admission control and E.164 dial plan resolution.
Best Practices for Multisite WAN with Distributed Call-Processing
Deployment The following best practices apply to the use of a gatekeeper:
■ Use a Cisco IOS Gatekeeper to provide call admission control into and out of each
site.
■ To provide high availability of the gatekeeper, use HSRP gatekeeper pairs, gatekeeper
clustering, and/or alternate gatekeeper support. In addition, use multiple gatekeepers
to provide redundancy within the network.
■ Size the platforms appropriately to ensure that performance and capacity requirements
can be met.
■ Use only one type of codec on the WAN because the H.323 specification does not
allow for Layer 2, IP, UDP, or RTP header overhead in the bandwidth request.
■ Using one type of codec on the WAN simplifies capacity planning by eliminating
the need to over-provision the IP WAN to allow for a worst-case scenario.
■ Gatekeeper networks can scale to hundreds of sites, and the design is limited only
by the WAN topology.
SIP devices provide resolution of E.164 numbers as well as SIP uniform resource identifiers
(URIs) to enable endpoints to place calls to each other. UCM supports the use of
E.164 numbers only.
The following best practices apply to the use of SIP proxies:
■ Provide adequate redundancy for the SIP proxies.
■ Ensure that SIP proxies have the capacity for the call rate and number of calls
required in the network.
Call-Processing Agents for the Distributed Call Processing Model Your choice
of call-processing agent will vary, based on many factors. The main factors, for the purpose
of design, are the size of the site and the functionality required.
For a distributed call-processing deployment, each site has its own call-processing agent.
The design of each site varies with the call-processing agent, the functionality required,
and the fault tolerance required. For example, in a site with 500 phones, a UCM cluster
containing two servers can provide one-to-one redundancy, with the backup server being
used as a publisher and Trivial File Transfer Protocol (TFTP) server.
The requirement for IP-based applications also greatly affects the choice of callprocessing
agent because only UCM provides the required support for many Cisco IP
applications.
Table 1-4 lists recommended call-processing agents for distributed call processing.