|
|
This chapter provides design guidelines for multi-site WAN systems that use Cisco CallManager Release 3.0 for centralized call processing. The discussion emphasizes issues specific to the centralized call processing model, with reference to relevant material in other sections of this guide.
This chapter includes the following sections:
In a centralized call processing system (see Figure 7-1), Cisco CallManagers are centrally located at the hub or aggregation site, with no local call processing at the branch location.
In Figure 7-1 the Cisco CallManager cluster is located at the central site. Because all IP phones within this cluster must register with a single Cisco CallManager, this solution can scale to 2500 users per cluster. Multiple clusters can be installed at the aggregation site to further scale the solution, and these clusters can be interconnected using H.323.
The primary advantage of this model is the ability to centralize call processing. This reduces the equipment required at the remote branch, while eliminating the administration of multiple PBXs or key systems, which would have traditionally been used. Figure 7-1 shows that the IP WAN is backed up by an Integrated Services Digital Network (ISDN) connection, which can provide a redundant IP WAN path for call processing. This scheme is particularly attractive for small branch offices of less than 20 people and for telecommuters. Life-line services can be provided by dedicated POTS lines or cellular phones.
Where centralized call processing is used, call admission control (CAC) is provided using the locations construct. Under this scheme, locations are created with a geographical correspondence, such as a branch office. For example, a location could be designated as Branch 1, Mountain View Office. (A postal zip code could also be used.) The location should correlate to a geographical location that is serviced by a wide area link. A maximum bandwidth to be used by inter-location voice calls is then specified for the location. Devices within that location are then designated as belonging to that location. See Figure 7-2.
The centralized Cisco CallManager keeps track of the current amount of bandwidth consumed by inter-location voice calls from a given location. If a new call across the IP WAN tries to exceed the configured setting, a busy signal is issued to the caller as well as a configurable visual display, such as "All Trunks Busy," on devices with this capability. If the caller gets a busy signal, the caller must hang up the phone and dial the access code for that location's PSTN gateway to facilitate an outgoing call.
Unlike previous versions of Cisco CallManager, each location in Cisco CallManager Release 3.0 can use a common access code for its local PSTN gateway. This is discussed in more detail in the "Dial Plan Considerations" section. In addition, Cisco CallManager Release 3.0 is no longer restricted to using gateways based on Skinny Gateway Protocol. You can now use Cisco IOS gateways based on H.323 or MGCP for media stream termination, and use of Media Termination Point (MTP) is no longer required.
Table 7-1 details the common branch gateways and minimum Cisco IOS releases.
| Platform | Minimum Cisco IOS Release |
|---|---|
Cisco 1750 | 12.1.(1)T |
Cisco 2600 | 12.0.(7)T |
Cisco 3600 | 12.0.(7)T |
Cisco MC 3810 v3 | 12.0.(7)XK |
In addition, bandwidth configured for a given location 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 the "WAN Quality of Service."
The following caveats should be considered when using locations-based CAC:
A centralized call processing cluster must be able to handle three primary types of calls:
In this section, generalized design guidelines are provided for each of these cases.
 |
Note Where location-based call admission control is used, alternate routing through the PSTN is not possible. Instead, the calling party hears a busy tone and, on devices with a display, sees an out-of-bandwidth message. |
Inter-location calls are generally made between IP phones and other devices such as fax machines and analog phones connected to gateway devices based on Media Gateway Control Protocol (MGCP) or the Skinny Gateway Protocol. As within a cluster, all devices register with a single Cisco CallManager so that the availability of all devices is known. When a call is attempted, the outcome is one of the following:
No configuration of a dial plan is required for intra-cluster calls in the majority of cases.
Inter-cluster calls are made using H.323 and can use alternative routing, including routing calls to the PSTN. Between clusters connected over a WAN, a gatekeeper is required for call admission control. The issues with inter-cluster calls are covered in greater detail in "Multi-Site WAN with Distributed Call Processing." See also Figure 3-11.
Each site can dial a single number to access the local PSTN. The same code can be used for PSTN access and, based upon the partition and calling search space, a local gateway is selected.
In the network depicted in Figure 7-3, the desired operation is to permit all users to call each other within the cluster and also to permit a subset of the users to make PSTN calls. The text following Figure 7-3 explains how to achieve this.
In the case of Figure 7-3, the partitions detailed in Table 7-2 would be configured to allow users to have access to either all intra-cluster locations or all intra-cluster locations and a local gateway.
| Partition Name | Designated Devices Assigned to Partition |
|---|---|
Cluster-X Users | All IP phones within the cluster |
Cluster-X Hub PSTN Access | PSTN gateway(s) at hub location |
Cluster-X Branch 1 PSTN Access | PSTN gateway at Branch 1 |
Cluster-X Branch 2 PSTN Access | PSTN gateway at Branch 2 |
Cluster-X Branch 3 PSTN Access | PSTN gateway at Branch 3 |
The calling party search spaces in Table 7-3 would then need to be defined. These calling search spaces would allow users to be assigned the ability to dial either numbers within the cluster only or all numbers within the cluster as well as PSTN calls through the local gateway.
| Calling Search Space | Partitions | Assigned To |
|---|---|---|
Cluster-X Internal Only | Cluster-X Users | Devices that can make only internal calls |
Cluster-X Hub Unrestricted | Cluster-X Users Cluster-X Hub PSTN Access | Internal calls and PSTN calls through hub location gateways |
Cluster-X Branch 1 Unrestricted | Cluster-X Users Cluster-X Branch 1 PSTN Access | Internal calls and PSTN calls through Branch 1 gateway |
Cluster-X Branch 2 Unrestricted | Cluster-X Users Cluster-X Branch 2 PSTN Access | Internal calls and PSTN calls through Branch 2 gateway |
Cluster-X Branch 3 Unrestricted | Cluster-X Users Cluster-X Branch 3 PSTN Access | Internal calls and PSTN calls through Branch 3 gateway |
This example presents one of the simplest configurations for multi-site WAN local call processing. The dial plan would consist essentially of a single pattern for PSTN calls, typically a 9. Gateway selection would depend entirely upon the partition and calling search space of the calling device, as detailed above.
Additional considerations, which would require a more ambitious dial plan, are listed in the "Calling Search Space" section.
The following design parameters apply for Cisco CallManager clusters in a centralized call processing environment using Cisco CallManager Release 3.0:
With WAN Cisco CallManager clusters, all active devices are required to register with a single Cisco CallManager. This allows the Cisco CallManager to maintain call state for all calls and thereby ensure that the specified bandwidth to a location is not exceeded.
Figure 7-4 shows devices registered to a single Cisco CallManager.
Where more than 2500 remote devices are required, multiple WAN clusters can be configured and interconnected using H.323. For a more detailed discussion, see "Cisco CallManager Clusters."
In this model, a single Cisco CallManager redundancy group should be configured, and it should be the default Cisco CallManager redundancy group. All devices would then be assigned to this group to ensure that they all are registered to the same Cisco CallManager.
Centralized call processing is typically done in environments where the provisioning of dedicated call processing at each site is not cost effective or is administratively unacceptable. The benefits of such a configuration are its central administration and low cost when spread across many sites. Digital signal processing (DSP) resources are required for transcoding and conferencing of calls. These resources are dedicated to each individual Cisco CallManager and must be located at the aggregation site.
Figure 7-5 shows the allocation of DSP resources.
The number of allocated resources is based upon the requirements for transcoding to voice mail and 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 cases where the placement of resources per Cisco CallManager is deemed cost prohibitive, the resources could be statically moved within the WAN cluster in the event of failure of the primary Cisco CallManager.
Figure 7-6 shows a centralized transcoding resource providing conversion from G.729a or G.723.1 to G.711 when a call that was initially placed at G.729a or G.723.1 rolls to voice mail, which is only a G.711 application.
Conferencing poses another example of an application that uses G.711 only. Consequently, if the party wanting to make a conference call can traverse the WAN using only a low-bit-rate codec, then the call must be transcoded to G.711 before the conference is initiated. See Figure 7-7.
In the scenario shown in Figure 7-7, the call from the branch traverses the WAN using G.729a, but must be transcoded to G.711 before being added to the conference resource.
Voice mail, like call processing, is usually not cost effective at the branch locations. Centrally locating voice mail simplifies voice mail administration as well as the provisioning of IP phones.
Whether interconnecting to a legacy system or an IP-based voice mail system, it is important to plan adequate capacity for concurrent voice mail sessions and to provision associated transcoding resources if a low bit rate codec is required over the wide area network. See Figure 7-8.
In Figure 7-8, there are five uOne application servers at the hub location, and they can provide voice mail for up to 2500 remote users. The MTP resources are required to transcode from G.729 to G.711 in the event that a low bit rate codec is used between locations.
Posted: Thu Jul 27 10:30:58 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.