Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
As illustrated in Figure 2-3, the model for a multisite WAN deployment with distributed
call processing consists of multiple independent sites, each with its own CUCM cluster,
connected to an IP WAN that carries voice traffic between the distributed sites.
CUCM, applications, and DSP resources may be located at each site. The IP WAN carries
signaling traffic only for intersite calls; signaling traffic for calls within a site remains local
to the site. This way, the amount of signaling traffic between sites is reduced compared to
a Centralized Call Processing model.
With the use of gatekeepers, a Distributed Call Processing model can scale to hundreds
of sites. It also provides transparent use of the PSTN in the event that the IP WAN is
unavailable.
40 Chapter 2: Deployment Models
Figure 2-3 Multisite WAN with Distributed Call Processing
The Multisite with Distributed Call Processing model has the following design characteristics:
■ Maximum of 30,000 SCCP or SIP IP phones or SCCP video endpoints per cluster.
■ Maximum of 1100 MGCP gateways or H.323 devices (gateways, MCUs, trunks, and
clients) per CUCM cluster.
IP
SIP/SCCP
IP
SIP/SCCP
Unified CM
Cluster
Unified CM
Cluster
V V
IP
Unified CM
Cluster
SIP/SCCP
PSTN
V
IP WAN
GK
Gatekeeper
Multisite Deployment with Distributed Call Processing 41
■ PSTN for all external calls.
■ DSP resources for conferencing, transcoding, and MTP.
■ Voice mail, unified messaging, and Cisco Unified Presence components.
■ Capability to integrate with legacy PBX and voice-mail systems.
■ H.323 clients, MCUs, and H.323/H.320 gateways that require a gatekeeper to place
calls must register with a Cisco IOS Gatekeeper (Cisco IOS Release 12.3(8)T or later).
CUCM then uses an H.323 trunk to integrate with the gatekeeper and provide callrouting
and bandwidth management services for the H.323 devices registered to it.
Multiple Cisco IOS Gatekeepers may be used to provide redundancy. Cisco IOS
Gatekeepers may also be used to provide call-routing and bandwidth management
between the distributed CUCM clusters. In most situations, Cisco recommends that
each CUCM cluster have its own set of endpoint gatekeepers and that a separate set of
gatekeepers be used to manage the intercluster calls. It is possible in some
circumstances to use the same set of gatekeepers for both functions, depending on the
size of the network, the complexity of the dial plan, and so forth.
■ MCU resources are required in each cluster for multipoint videoconferencing.
Depending on conferencing requirements, these resources may be either SCCP or
H.323 or both, and they may all be located at the regional sites or may be distributed
to the remote sites of each cluster if local conferencing resources are required.
■ H.323/H.320 video gateways are needed to communicate with H.320 videoconferencing
devices on the public ISDN network. All these gateways may be located at the
regional sites, or they may be distributed to the remote sites of each cluster if local
ISDN access is required.
■ High-bandwidth audio (for example, G.711, G.722, or Cisco Wideband Audio)
between devices in the same site, but low-bandwidth audio (for example, G.729
or G.728) between devices in different sites.
■ High-bandwidth video (for example, 384 kb/s or greater) between devices in the same
site, but low-bandwidth video (for example, 128 kb/s) between devices at different
sites. The Cisco Unified Video Advantage wideband codec, operating at 7 Mb/s, is
recommended only for calls between devices at the same site. Note that the Cisco
VT Camera wideband video codec is not supported over intercluster trunks.
42 Chapter 2: Deployment Models
Benefits
The Multisite WAN with Distributed Call Processing model provides the following
benefits:
■ PSTN call cost savings when using the IP WAN for calls between sites.
■ Use of the IP WAN to bypass toll charges by routing calls through remote-site
gateways, closer to the PSTN number dialed (TEHO).
■ Maximum utilization of available bandwidth by allowing voice traffic to share the
IP WAN with other types of traffic.
■ No loss of functionality during IP WAN failure because there is a call-processing
agent at each site.
■ Scalability to hundreds of sites.
■ Gatekeeper networks can scale to hundreds of sites, and the design is limited only by
the WAN topology.
Best Practices
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.
Among the key elements of this Multisite WAN model are the SIP or gatekeeper proxy
servers. They each provide dial plan resolution, with the gatekeeper also providing CAC.
A gatekeeper is an H.323 device that provides CAC and E.164 dial plan resolution.
The following best practices apply to the use of a gatekeeper:
■ Use a Cisco IOS Gatekeeper to provide CAC into and out of each site.
■ To provide high availability of the gatekeeper, use Hot Standby Router Protocol
(HSRP) gatekeeper pairs, gatekeeper clustering, and 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.
Clustering over the IP WAN 43
■ Use only one type of audio codec on the WAN, because the H.323 specification does
not allow for Layer 2, IP, User Data Protocol (UDP), or Real-Time Transport Protocol
(RTP) header overhead in the bandwidth request. Using one type of codec on the WAN
simplifies capacity planning by eliminating the need to overprovision the IP WAN to
allow for the worst-case scenario.
Clustering over the IP WAN
Cisco supports CUCM clusters over a WAN. Characteristics include the following:
■ Applications and CUCM of the same cluster distributed over the IP WAN.
■ IP WAN carries intracluster server communication and signaling.
■ Limited number of sites:
—Two to four sites for local failover (two CUCM servers per site)
—Up to eight sites for remote failover across the IP WAN (one CUCM
server per site)
The cluster design, as illustrated in Figure 2-4, is useful for customers who require more
functionality than the limited feature set offered by SRST. This network design also allows
remote offices to support more IP phones than SRST in the event that the connection to the
primary CUCM is lost.
Figure 2-4 Clustering over the IP WAN
IP
IP
SIP/SCCP
Publisher/TFTP Subscribers
IP WAN
V V
<40 ms Round-Trip Delay
QoS Enabled BW
IP
IP
SIP/SCCP
44 Chapter 2: Deployment Models
The design guidelines for clustering over the IP WAN are as follows:
■ Two CUCM servers in a cluster must have a maximum round-trip time (RTT) delay of
40 ms between them. Because of the strict 40-ms database replication requirement, this
design can be used only between high-speed locations. The sites cannot be located on
separate coasts of the United States, for example, because the speed of light is not
capable of communicating between New York and California (propagation delay). In
comparison to this strict RTT database requirement, high-quality voice guidelines
dictate that one-way end-to-end delay should not exceed 150 ms.
■ For every 10,000 busy hour call attempts (BHCA) within the cluster, an additional
900 kb/s of WAN bandwidth for intracluster runtime communication must be supported.
The BHCA represents the number of call attempts made during the busiest hour of
the day.
■ Up to eight small sites are supported using the Remote Failover deployment model.
Remote failover allows one server per location with a maximum of eight call-processing
servers supported in a cluster. In the event of CUCM failure, IP phones register to
another server over the WAN. SRST is not required in this deployment model. The
remote failover design may require significant additional bandwidth, depending on the
number of telephones at each location.
NOTE In earlier versions of CUCM, subscriber servers in the cluster used the publisher’s
database for read/write access, and they used their local database for read access only when
the publisher’s database could not be reached.
With CUCM 6.x, subscriber servers in the cluster read their local database. Database
modifications can occur in the local database (for special applications such as user-facing
features). IBM Informix Dynamic Server (IDS) database replication is used to synchronize
the databases on the various servers in the cluster. Therefore, when recovering from failure
conditions such as the loss of WAN connectivity for an extended period of time, the CUCM
databases must be synchronized with any changes that might have been made during the
outage. This process happens automatically when database connectivity is restored and can
take longer over low-bandwidth links.
In rare scenarios, manual reset or repair of the database replication between servers in the
cluster might be required. This reset/repair is performed by using commands such as utils
dbreplication repair all and utils dbreplication reset all at the command-line interface
(CLI). Repair or reset of database replication using the CLI on remote subscribers over the
WAN causes all CUCM databases in the cluster to be resynchronized, in which case
additional bandwidth above 1.544 Mb/s might be required. Lower bandwidths can take
longer for database replication repair or reset to complete.
CUCM Call-Processing Redundancy 45
Although there are stringent requirements, clustering over the IP WAN design offers these
advantages:
■ Single point of administration for users for all sites within the cluster
■ Feature transparency
■ Shared line appearances
■ Extension mobility within the cluster
■ Unified dial plan
The clustering over IP WAN design is useful for customers who want to combine the
resiliency advantages of this model with the benefits provided by a local call-processing
agent at each site. Intrasite signaling is kept local, and WAN failures will not result in loss
of functionality. This network design also allows remote offices to support more Cisco IP
Phones than SRST in the event of WAN failure.
These features make clustering across the IP WAN ideal as a disaster recovery plan for
business-continuance sites or as a single solution for up to eight small or medium sites.
No comments:
Post a Comment