|
|
This chapter provides design guidelines for multi-site WAN systems that use Cisco CallManager for distributed call processing. The discussion emphasizes issues specific to the distributed call processing model, with reference to relevant material in other sections of this guide.
This chapter includes the following sections:
In a distributed call processing system (see Figure 6-1), each site contains its own Cisco CallManagers, voice messaging, and Digital Signaling Processor (DSP) resources.
The distributed call processing model can initially support up to 10 sites networked across the IP WAN. Voice calls between sites use the IP WAN as the primary path and the PSTN as the secondary path in the event the IP WAN is down or has insufficient resources to handle additional calls. Whether calls use the IP WAN or use the PSTN is transparent to both the calling party and the called party.
The primary advantage of this deployment model is that, by using local call processing, it provides the same level of features and capabilities whether the IP WAN is available or not. Each site can have from one to five Cisco CallManagers in a cluster based on the number of users. This is the predominant deployment model for sites with greater than 20 users, and each site can support up to 10,000 users. In addition, there is no loss of service if the IP WAN is down.
Quality of service (QoS) tools ensure voice quality in two ways: by giving voice priority over data and by preventing voice from oversubscribing a given WAN link. The second task is accomplished by call admission control (CAC) mechanisms. The need for CAC in IP telephony networks is amplified greatly by the fact that all IP phones have an open IP path to the WAN, whereas toll bypass networks, in contrast, could limit the number of physical trunks eligible to initiate calls across the WAN. Figure 6-2 illustrates why CAC is needed.
For distributed call processing systems, you can implement CAC with an H.323 gatekeeper. In this design, Cisco CallManager registers with the Cisco IOS gatekeeper, also known as Multimedia Conference Manager (MCM), as a Voice over IP (VoIP) gateway and queries it each time it wants to make an IP WAN call. The Cisco IOS gatekeeper associates each Cisco CallManager with a zone that has specific bandwidth limitations. Thus the Cisco IOS gatekeeper can limit the maximum amount of bandwidth consumed by IP WAN voice calls in or out of a zone.
In brief, when Cisco CallManager wants to place an IP WAN call, it first requests permission from the gatekeeper. If the gatekeeper grants the call, it is placed across the IP WAN. If the gatekeeper denies the request, Cisco CallManager places the call across the secondary path, the PSTN.
This is effectively a call accounting method of providing admission control, in which the gatekeeper simply keeps track of the bandwidth the IP WAN calls consume. The maximum bandwidth setting for a zone should take into account the limitation that the WAN link not be filled with more than 75% voice. Figure 6-3 illustrates the process used by this CAC mechanism.
 |
Note In this scheme, IP phones are not mobile between sites. Should an IP phone register across the WAN, admission control would not operate as designed. |
In this model, it is important that the dial plan be tightly coupled with the gatekeeper CAC mechanism because it is the dial plan that ultimately decides when to place a call across the IP WAN and what to do if the gatekeeper rejects it. This concern is addressed in the "Dial Plan Considerations" section.
Communication between sites that have a Cisco CallManagers or Cisco CallManager cluster requires the use of H.323v2. This means that a remote Cisco CallManager or Cisco CallManager cluster must be configured as an inter-cluster H.323 device. Within the Cisco CallManager configuration for an H.323 device, you can configure the device to be controlled by a gatekeeper and can specify which gatekeeper to be queried. This means that, before the Cisco CallManager sets up a call with a remote Cisco CallManager, it must first send an admission request (ARQ) with the requested bandwidth to the gatekeeper.
This remote Cisco CallManager is then placed in a route group, which can be associated with various route patterns for IP WAN calls. This route group would be configured as the first-choice route group in a route pattern or route list, and the route group associated with the PSTN would be configured as the second choice if the gatekeeper rejected the call. In this way, the call can be transparently routed across the PSTN if the IP WAN is unavailable.
|
Note With Cisco CallManager Release 3.0, 128 kbps is always requested in the ARQ, regardless of the IP WAN codec to be used. This requires the use of a single WAN codec for all IP WAN calls, as well as using a correction factor to determine the maximum amount of bandwidth entered in the Cisco IOS gatekeeper. In effect, every 128 kbps entered in the gatekeeper equates to one call at 80 kbps or 24 kbps, depending on the WAN codec selection. This is further explained later in this section. |
Figure 6-4 depicts the details of the interaction between Cisco CallManager and the gatekeeper.
In earlier releases of Cisco CallManager, all H.323 IP WAN calls were required to use the Media Termination Point (MTP) application to support supplementary services. This required the IP flow of each IP WAN call to pass through Cisco CallManager as well as use G.711, which consumes 80 kbps of IP bandwidth per call. This limitation is lifted in Cisco CallManager Release 3.0 in that IP WAN calls between Cisco CallManagers and Cisco CallManager clusters use H.323v2 with the empty capabilities set, which does not require MTP.
In addition, bandwidth configured for a given zone must be equal to or less than the configured queue for voice on the wide area links. The preferred method of queuing is low latency queuing, which is covered in more detail in "WAN Quality of Service."
The following considerations apply when using gatekeeper-based call admission control:
|
Note In this scheme, IP phones are not mobile between sites. Should an IP phone register across the WAN, admission control would not operate as designed. |
In the example depicted in Figure 6-6, users dial five digits for internal calls and seven digits for inter-site calls across the IP WAN. If the IP WAN is down or has insufficient resources, the PSTN is used transparently for inter-site calls. For long distance calls that will be directed to the PSTN, users dial the access code 9 followed by 1 + area code and the 7-digit number. Users dialing local PSTN calls dial 9 plus the 7-digit number. This model also provides gateway redundancy in the event of a gateway or trunk failure to the PSTN. The PSTN gateways are Cisco IOS gateways using H.323.
|
Note This section deals only with inter-site IP WAN calls that are intended to traverse the IP WAN as the first choice and use the PSTN as the second choice. See the "Calls out the PSTN" section for POTS-only calls. |
The goal of this dial plan is to be able to dial the San Jose location using only seven digits, where calls take the IP WAN as the first choice and the PSTN as the second choice. Thus, users in Philadelphia should be able to dial San Jose users at (408) 526-XXXX by simply dialing 526XXXX.
This configuration begins at the route pattern. A route pattern is entered as 52.6XXXX with an assigned route list as SJ. The location of the dot (.) signifies that all digits to the left comprise the access code for this route pattern. Also, no digit manipulation is selected or required because each route group needs to invoke its own unique manipulation.
Figure 6-6 depicts the route pattern configuration for 52.6XXXX.
As shown in Figure 6-6, the route list contains two route groups, SJ-IPWAN and PHL-PSTN, listed in order of priority. The SJ-IPWAN route group is listed first and points to the San Jose Cisco CallManager. The digit manipulation specified in route pattern SJ-IPWAN discards the access code (52). This ensures that, when the call is sent across the IP WAN, five digits are delivered to the remote Cisco CallManager because that is what it requires for its internal dial length. The H.323 device associated with the remote Cisco CallManager must be configured to be gatekeeper controlled to ensure that the gatekeeper is consulted before attempting the call across the IP WAN.
If the call is rejected by the gatekeeper, the route list uses the next route group, PHL-PSTN. This route group is configured to prepend 1408 to the dialed number to ensure that the call transparently reaches the other end.
In a distributed call processing environment, you configure dialing restrictions by using partitions and calling search spaces. This is very similar to configuring dialing restrictions in a campus or individual site, as explained in the "Configuring Dial Plan Groups and Calling Restrictions" section.
The bandwidth that is consumed by calls between devices (IP phones and gateways) can be controlled by setting up regions that dictate codec usage. Devices are placed in a region that has a particular codec specified for all intra-region calls and can have other codecs specified for inter-region calls. Regions are assigned to devices using a device pool. The supported codecs defined in regions are G.711, G.729, and G.723. (G.723 is supported only on the Cisco IP Phone 12 SP+ and the Cisco IP Phone 30 VIP.)
Figure 6-7 illustrates the use of regions for distributed call processing environments, where often only two regions need be assigned.
|
Note Just one WAN region is associated with all H.323 devices across the IP WAN because of the single codec restriction. In future releases of Cisco CallManager, multiple WAN regions may be supported. |
The following design considerations apply for Cisco CallManager clusters in a distributed call processing environment using Cisco CallManager Release 3.0:
The major design consideration regarding Cisco CallManager clusters in this type of system is how the H.323 peering is achieved between clusters. Based on the way Cisco CallManager Release 3.0 registers with the gatekeeper, Cisco recommends that no redundant peering occur between clusters. This recommendation may change with future releases of Cisco CallManager.
This section briefly considers DSP resources in distributed call processing environments. In a multi-site WAN with distributed call processing, each site is required to have DSP resources for conferencing and for transcoding across the IP WAN. Conferencing and transcoding services are enabled by the Media Termination Point (MTP) application.
The main purpose of transcoding DSP resources is to perform conversion between different codec types in a Real-Time Transport Protocol (RTP) stream in the event of a codec mismatch. For example, a compressed G.729 media RTP stream across the IP WAN might need to terminate on a device that supports only G.711. The transcoding DSP resource would terminate the G.729 media stream and convert it to G.711. This allows the media stream to remain compressed across the WAN. Figure 6-8 depicts the function of DSP resources across the IP WAN, as listed in the following steps:
Step 2 Cisco CallManager B sees that the destination is region A, LBR codec.
Step 3 Cisco CallManager A sees an LBR incoming call for a G.711-only device.
Step 4 The media stream is directed to the terminating side DSP farm.
The number of allocated resources is based upon the requirements for transcoding to voice mail as well as transcoding to G.711 for other applications such as conferencing. These numbers are calculated based upon the ratio of users to voice mail ports and the volume of conference calls placed.
In a multi-site IP WAN with distributed call processing, each site must have its own voice messaging components. This is the case whether using Cisco uOne or interfacing to a legacy voice messaging system. See Figure 6-9.
|
Note In the scheme shown in Figure 6-9, there is no support for voice mail networking between sites when using Cisco uOne 4.1E for voice messaging. |
Posted: Thu Jul 27 10:34:05 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.