Design Guidelines for Multisite WAN with Centralized Call-Processing Deployment
Follow these guidelines when implementing the multisite WAN model with centralized call processing:
■ Minimize delay between Cisco UCM and remote locations to reduce voice cut-through delays (also known as clipping). The ITU-T G.114 recommendation specifies a 150 ms maximum one way.
■ Use HSRP for network resiliency.
■ Use the locations mechanism in Cisco UCM to provide call admission control into and out of remote branches.
■ The number of IP phones and line appearances supported in SRST mode at each remote site depends on the branch router platform, the amount of memory installed, and the Cisco IOS release. SRST on a Cisco IOS gateway supports up to 720 phones, whereas Unified CME running in SRST mode supports 240 phones. Generally speaking, however, the choice of whether to adopt a centralized call processing or distributed call processing approach for a given site depends on a number of factors, such as
■ IP WAN bandwidth or delay limitations
■ Criticality of the voice network
■ Feature set needs
■ Scalability
■ Ease of management
■ Cost
Note If a distributed call-processing model is deemed more suitable for a customer’s business needs, the choices include installing a UCM cluster at each site or running Unified CME at the remote sites.
■ At the remote sites, use the following features to ensure call processing survivability in the event of a WAN failure:
■ For SCCP phones, use SRST on a Cisco IOS gateway or Unified CME running in SRST mode.
■ For SIP phones, use SIP SRST.
■ For MGCP phones, use MGCP Gateway Fallback.
SRST or Unified CME in SRST mode, SIP SRST, and MGCP Gateway Fallback can reside with each other on the same Cisco IOS gateway.
Multisite WAN with Distributed Call-Processing Deployment
The model for a multisite WAN deployment with distributed call processing, as illustrated in Figure 1-27, consists of multiple independent sites, each with its own call-processing agent cluster connected to an IP WAN that carries voice traffic between the distributed sites.
An IP WAN interconnects all the distributed call processing sites. Typically, the PSTN serves as a backup connection between the sites in case the IP WAN connection fails or does not have anymore available bandwidth. A site connected only through the PSTN is a standalone site and is not covered by the distributed call processing model.
WAN connectivity options include the following:
■ Leased lines
■ Frame Relay
■ ATM
■ ATM and Frame Relay SIW
■ MPLS VPN
■ IPsec V3PN
Multisite distributed call processing allows each site to be completely self-contained. In the event of an IP WAN failure or insufficient bandwidth, a site does not lose call-processing service or functionality. Cisco UCM simply sends all calls between the sites across the PSTN.
Figure 1-27 Multisite WAN with Distributed Call Processing
Design Characteristics of Multisite WAN with Distributed Call-Processing Deployment
The multisite model with distributed call processing 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 UCM cluster.
■ 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). UCM then uses an H.323 trunk to integrate with the gatekeeper and provide call routing and bandwidth management services for the H.323 devices registered to it. Multiple Cisco IOS Gatekeepers might be used to provide redundancy. Cisco IOS Gatekeepers might also be used to provide call routing and bandwidth management between the distributed UCM clusters. In most situations, Cisco recommends that each UCM cluster have its own set of endpoint gatekeepers and that a separate set of gatekeepers be used to manage 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 and complexity of the dial plan.
■ MCU resources are required in each cluster for multipoint video conferencing. Depending on conferencing requirements, these resources might be either SCCP or H.323, or both, and might all be located at the regional sites or 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. These gateways might all be located at the regional sites or 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 kbps or greater) between devices in the same site, but low-bandwidth video (for example, 128 kbps) between devices at different sites. The Cisco Unified Video Advantage Wideband Codec, operating at 7 Mbps, 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.
■ Minimum of 768 kbps or greater WAN link speeds. Video is not recommended on WAN connections that operate at speeds lower than 768 kbps.
■ Call admission control is provided by UCM locations for calls between sites controlled by the same UCM cluster and by the Cisco IOS Gatekeeper for calls between UCM clusters (that is, intercluster trunks). AAR is also supported for both intraclus-ter and intercluster video calls.
Benefits of Multisite WAN with Distributed Call-Processing Deployment
The main benefits of the multisite WAN with distributed call-processing deployment model are as follows:
■ Cost savings when you use 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 (that is, tail-end hop-off [TEHO])
■ Maximum utilization of available bandwidth by allowing voice traffic to share an IP WAN with other types of traffic
■ No loss of functionality during an IP WAN failure
■ Scalability to hundreds of sites
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.
The requirement for IP-based applications also greatly affects the choice of call-processing 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. Table 1-4 Recommended Call Processing Agents
|
Call Processing Agent |
Recommended Size |
Comments |
|
Cisco Unified Communications Manager Express (Unified CME) |
Up to 240 phones |
For small remote sites. Capacity depends on Cisco IOS platform. |
|
Cisco UCM |
50 to 30,000 phones |
Small to large sites, depending on the size of the UCM cluster. Supports centralized or distributed call processing. |
|
Legacy PBX with VoIP gateway |
Depends on PBX |
Number of IP WAN calls and functionality depend on the PBX-to-VoIP gateway protocol and the gateway platform. |
Clustering over the IP WAN Deployment
Cisco supports Cisco UCM clusters over a WAN, as illustrated in Figure 1-28. Clustering over the WAN involves having the applications and UCM of the same cluster distributed across the IP WAN.
Figure 1-28 Clustering over the IP WAN
Clustering over the WAN can support two types of deployments:
■ Local Failover Deployment Model: Local failover requires that you place UCM subscriber and backup servers at the same site, with no WAN between them. This deployment model is ideal for two to four sites with UCM.
■ Remote Failover Deployment Model: Remote failover allows you to deploy the backup servers over the WAN. Using this deployment model, you might have up to eight sites with UCM subscribers being backed up by UCM subscribers at another site.
Note The remote failover deployment model might need higher bandwidth because a large amount of intracluster traffic flows between the subscriber servers.
You can also use a combination of the two deployment models to satisfy specific site requirements. For example, two main sites might each have primary and backup subscribers, with another two sites containing only a primary server each and utilizing either shared backups or dedicated backups at the two main sites.
Benefits of the Clustering over the IP WAN Deployment
Although stringent requirements exist, the clustering over the IP WAN deployment design offers these advantages:
■ Single point of administration for users for all sites within a cluster
■ Feature transparency
■ Shared line appearances
■ Extension mobility within the cluster
■ Unified dial plan
These features make this solution ideal as a disaster recovery plan for business continuance sites or as a single solution for as many as eight small or medium sites.
The cluster design is also 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 Cisco IP Phones than SRST in the event that the connection to the primary Cisco UCM server is lost.
WAN Considerations
For clustering over the WAN to be successful, you must carefully plan, design, and implement various characteristics of the WAN itself. The Intra-Cluster Communication Signaling (ICCS) between UCM servers consists of many traffic types. The ICCS traffic types are classified as either priority or best effort. Priority ICCS traffic is marked with IP Precedence 3 (DSCP 24 or PHB CS3). Best-effort ICCS traffic is marked with IP Precedence 0 (DSCP 0 or PHB BE).
The following design guidelines apply to the indicated WAN characteristics:
■ Delay: The maximum one-way delay between any UCM servers for all priority ICCS traffic should not exceed 20 ms, or 40 ms round-trip time (RTT). Delay for other ICCS traffic should be kept reasonable to provide timely database access. Propagation delay between two sites introduces 6 microseconds per kilometer without any other network delays being considered. This equates to a theoretical maximum distance of approximately 3000 km for 20 ms delay or approximately 1860 miles. These distances are provided only as relative guidelines and in reality will be shorter because of additional delay incurred within the network.
■ Jitter: Jitter is the varying delay that packets incur through the network because of processing, queue, buffer, congestion, or path variation delay. Jitter for the IP Precedence 3 ICCS traffic must be minimized using QoS features.
■ Packet loss and errors: The network should be engineered to provide sufficient prioritized bandwidth for all ICCS traffic, especially the priority ICCS traffic. Standard QoS mechanisms must be implemented to avoid congestion and packet loss. If packets are lost due to line errors or other "real world" conditions, an ICCS packet will be retransmitted because it uses the TCP protocol for reliable transmission. The retransmission might result in a call being delayed during setup, disconnect (teardown), or other supplementary services during the call. Some packet-loss conditions could result in a lost call, but this scenario should be no more likely than errors occurring on a T1 or E1, which affect calls via a trunk to the PSTN/ISDN.
■ Bandwidth: Provision the correct amount of bandwidth between each server for the expected call volume, type of devices, and number of devices. This bandwidth is in addition to any other bandwidth for other applications sharing the network, including voice and video traffic between the sites. The bandwidth provisioned must have QoS enabled to provide the prioritization and scheduling for the different classes of traffic. The general rule for bandwidth is to overprovision and undersubscribe.
■ QoS: The network infrastructure relies on QoS engineering to provide consistent and predictable end-to-end levels of service for traffic. Neither QoS nor bandwidth alone is a solution. Rather, QoS-enabled bandwidth must be engineered into the network infrastructure.
Summary
The main topics covered in this topic are the following:
■ The Cisco Unified Communications System Architecture fully integrates communications by enabling data, voice, and video to be transmitted over a single network infrastructure using standards-based IP.
■ VoIP is the family of technologies that allows IP networks to be used for voice applications, such as telephony, voice instant messaging, and teleconferencing.
■ VoIP uses H.323, MGCP, SIP, and SCCP call signaling and call control protocols.
■ Signaling protocol models include peer-to-peer and client/server categories of protocols.
■ Configuring voice in a data network requires network services with low delay, minimal jitter, and minimal packet loss.
■ The actual voice conversations are transported across the transmission media using RTP and other RTP-related protocols.
■ Gateways connect IP Communications networks to traditional telephony networks.
■ Several types of voice gateways meet all kinds of customer needs, from small enterprises to large service provider networks.
■ Supported Cisco IP telephony deployment models are single site, multisite with centralized call processing, multisite with distributed call processing, and clustering over the IP WAN.
■ In the single-site deployment model, the Cisco UCM applications and the DSP resources are at the same physical location. The PSTN handles all external calls.
■ The multisite centralized model has a single call-processing agent. Applications and DSP resources are centralized or distributed, and the IP WAN carries voice traffic and call control signaling between sites.
■ The multisite distributed model has multiple independent sites, each with a call-processing agent, and the IP WAN carries voice traffic between sites but not call control signaling.
■ Clustering over an IP WAN provides central administration, a unified dial plan, feature extension to all offices, and support for more remote phones during failover, but places strict delay and bandwidth requirements on the WAN.
