This chapter provides a detailed explanation of the tasks and processes involved in designing a call-processing infrastructure and IP Telephony (IPT) applications that meet the requirements of XYZ, Inc. Topics covered in this chapter include the following:
This chapter uses information collected in the design questionnaires listed in Appendixes D, “IPT Design Phase: IP Phone Selection Questionnaire,” through F, “Ordering T1/E1 PRI from the Carrier Questionnaire”. It also uses the information collected about XYZ in Chapter 3, “Large-Scale Enterprise Requirements for IP Telephony.” To review the high-level architecture of the proposed IPT solution for XYZ, which is a multisite WAN with distributed call processing, see Figure 5-1 in Chapter 5, “Design Phase: Network Infrastructure Design.”
This section covers these high-level design aspects of the proposed IPT system for XYZ:
Fax and analog terminals
Voice gateways
Media resources
IPT applications
The VG248 and FXS ports on Cisco IOS routers will handle the fax needs. Three VG248s will be deployed in San Jose to provide a total of 3 × 48 = 144 analog ports to connect fax machines and provide modem access to the users. VG248 communicates with CallManager via the Skinny Client Control Protocol (SCCP).
Voice gateways connect the IPT network to the public switched telephone network (PSTN) and the PBX system. This section discusses the voice gateway modules and signaling protocols used to interface the IPT network with the PSTN and PBX system.
Each site in the XYZ network has direct access to the PSTN. At each site, the primary path to call the PSTN is the local voice gateway. Calls between sites take the IP WAN as a first preference and are rerouted to the PSTN if the IP WAN is down or not enough bandwidth is available to route the call. Detailed call-routing requirements are discussed in the “Dial Plan Architecture” section later in this chapter.
As mentioned in Chapter 4, “Planning Phase,” in the “PBX Infrastructure and Migration” section, the San Jose site has six T1 connections. At the beginning of IPT deployment in the San Jose site, only four of the T1s that are currently terminating on the PBX will be moved to voice gateways in the IPT system. The remaining two T1s will stay connected to the PBX. This is required to route the calls between the IP Phones and the phones that are on the PBX (not yet migrated to the IPT network). Table 6-1 shows the different hardware used for PSTN access and the type of PRI signaling used for the trunking.
Table 6-1. Hardware List for PSTN Trunks and Signaling Type
Location | Hardware | Port and SignalingType | No. ofTrunks |
---|---|---|---|
San Jose | Communications Media Module (WS-SVCCMM-6T1) | T1 PRI National ISDN (NI2) | 4 |
Seattle | Cisco 3745 with the High-Density Voice Network Module (NM-HDV) and the Network Voice Module (NM-HDA) | T1 PRI NI2,Analog FXS[1] | 1 |
Dallas | Cisco 2651XM with the analog NM-HDA | Analog FXSAnalog FXO[2] | 4 |
Sydney | Catalyst 6000 Family Voice E1 WS-X6608-E1 | E1 PRI NET5 | 4 |
Melbourne | Cisco 3745 with the NM-HDV | E1 PRI NET5Analog FXS | 1 |
Brisbane | Cisco 2651XM with the analog NM-HDA | Analog FXSAnalog FXO | 4 |
[1] FXS = Foreign Exchange Station [2] FXO = Foreign Exchange Office |
The PBX system will continue to operate in the San Jose office. Table 6-2 shows the location where a PBX will remain connected to the IPT network.
Media resources are the entities that provide resources for media mixing (conferencing), codec conversion (transcoding), Media Termination Point (MTP), and Music on Hold (MoH). These resources, except the transcoding, are available as both software and hardware. Transcoding requires the use of digital signal processors (DSPs), so it is available only as hardware. Every CallManager in the cluster provides conferencing, MTP, and MoH resources by default. The CallManager services that are responsible for providing these resources are Cisco IP Voice Media Streaming Application and Cisco MoH Audio Translator (used only by MoH).
Enabling these software-based resources on the CallManager consumes some part of the system resources. Hence, you need to take into account these services when you calculate device weights, discussed later in this section.
Cisco IOS gateways and Catalyst gateways provide the conferencing, transcoding, and media termination resources in hardware. If you have enough hardware equipment to provide these resources, disable these two services on the CallManager to reduce its load.
In a multisite IPT deployment, you can deploy all the media resources at a central location or use the distributed approach.
If you choose centralized deployment, for every conferencing or transcoding request, the streams from the remote sites have to traverse to the central site, which is a waste of bandwidth on the WAN link. If the requirement is to use a centralized deployment, make sure that you choose a lower-bandwidth codec to optimize the bandwidth usage on the WAN links by multiple streams.
Distributed media resource deployment conserves the bandwidth, but you might have to spend more money on the hardware. You should compare the cost of the additional hardware required to the cost of additional bandwidth on the WAN links before you make a decision on placing the media resources in the network.
The following two types of conferencing services are available in CallManager:
Ad Hoc conferencing—. The conference call initiator (conference controller) adds the participants to the conference call. IP Phone users press the Confrn softkey on the IP Phone to join the other participants in the existing conversation.
Meet-Me conferencing—. All participants are provided with a preconfigured bridge or directory number that they dial to join the conference call. Before users can invoke Meet-Me, the CallManager system administrator must configure the Meet-Me directory numbers in the CallManager as a part of the dial plan configuration and publish these numbers to all the users in the organization.
The transcoding resources convert voice streams from one compression type to another. In a multisite IPT deployment, such as XYZ’s, the remote sites typically use the G.729 codec over the WAN to conserve the bandwidth, because G.729 consumes less bandwidth than G.711. Voice applications such as IVR and voice mail can stream either G.711 or G.729. In case of XYZ, these two applications are deployed at the central site to use the G.711 codec only. It is highly recommended not to enable the transcoding features on these applications even if they are available, because it consumes a lot of system resources and generates poor voice quality. Deploying the hardware-based transcoder is the best approach when a user in a remote site needs to access one of these two applications and when a transcoder will be required in the voice path to convert the audio G.729 to G.711 or vice versa.
When an IP Phone (G.729 voice stream) at a remote site connects to IVR or the Cisco Unity server, CallManager invokes the transcoder to transcode the G.729 voice stream to G.711. Chapter 7, “Voice-Mail System Design,” covers the Cisco Unity design and deployment.
Two endpoints using different codecs cannot establish a two-way communication if no transcoding devices are available. You can press the i button twice on the Cisco IP Phone (7960/7940 models) during the call to see the codec used for the call. The following list summarizes the deployment of transcoding and conferencing resources for XYZ:
In San Jose, Cisco CMM provides conferencing and transcoding resources using the Ad Hoc Conferencing and Transcoding (ACT) port adapter (WS-SVC-CMM-ACT), which has four DSPs. Each ACT port adapter provides 128 channels (32 channels per DSP) for conferencing and transcoding. A single CMM can have a maximum of four ACT port adapters, providing a maximum of 512 channels. One ACT port adapter in the San Jose CMM provides the resources for transcoding and conferencing by using the partitioning technique. We will partition the ACT port adapter to use three DSPs to provide a conferencing resource pool of 96 channels and to use one DSP to provide a transcoding resource pool of 32 channels.
In Seattle and Melbourne, the Cisco 3745 router that is equipped with the NM-HDV provides support for conferencing only, by partitioning the DSP resources. The ACT port adapter in the CMM at San Jose handles all the transcoding requests for Seattle.
In Sydney, the additional E1 ports on the Catalyst 6000 Family Voice E1 (WS-6608-E1) card provide transcoding and conferencing resources. Two E1 ports provide conference resources, and two E1 ports provide transcoding.
No local conferencing and transcoding resources are deployed in Dallas or Brisbane. Users in Dallas and Brisbane use the conferencing and transcoding resources at the San Jose and Sydney central sites, respectively.
Table 6-3 shows the hardware deployed in each location for providing conferencing and transcoding resources.
Table 6-3. Hardware Conferencing and Transcoding Device List
Location | Hardware |
---|---|
San Jose | Two ACT port adapters (WS-SVC-CMM-ACT), one ACT per CMM. |
Seattle | NM-HDV (DSP partitioning) with 4 Packet Voice DSP Modules (PVDMs) forconferencing only |
Dallas | None |
Sydney | Catalyst 6000 family voice E1 (WS-X6608-E1) using 4 ports (2 port conferencing and 2 port transcoding) |
Melbourne | NM-HDV (DSP partitioning) with 5 PVDMs for conferencing only |
Brisbane | None |
Music on Hold, as the name implies, streams the predefined music from an MoH server to the caller when the caller is placed on hold. The MoH feature allows two types of hold:
End-user hold—. An IP Phone user presses the Hold key while on the call.
Network hold—. An IP Phone user attempts to transfer a call, joins a conference call, or parks the call at a call park number.
MoH supports both unicast and multicast transport mechanisms to transport the audio streams to the endpoints. Unicast MoH consists of streams sent directly from the MoH server to the endpoint requesting an MoH audio stream. With multicast, the MoH server continuously plays the audio stream. Endpoints that request a multicast MoH stream have to join the multicast IP address of the stream. This is similar to a multicast client joining a multicast group.
As discussed in the preceding section, CallManager offers MoH as a software feature. While designing the MoH feature, you need to consider the following:
Can CallManager servers provide the MoH feature in the network? Alternatively, is a dedicated MoH server needed?
How many simultaneous MoH requests are required for the planned IPT network?
Is the MoH feature required for all the sites?
Should unicast MoH or multicast MoH be used?
Before you choose an MoH model for XYZ, you need to consider some of the MoH design scenarios, described next.
Enabling the MoH feature on the CallManager consumes system resources. If you plan to enable the MoH feature on the CallManager servers in the cluster, ensure that you account for the device weights for the MoH feature when you calculate the device weights. As long as the device weights do not exceed the maximum capacity of the server, you can enable the feature on the CallManager servers. However, in larger IPT deployments, consider separating the MoH feature onto a dedicated server. For instance, you can combine DHCP, TFTP, and MoH functionality into a single server. An MoH server that is co-resident with CallManager supports 20 streams, whereas a dedicated standalone MoH server supports up to 250 streams depending on the server platform. You can install the dedicated MoH server on any approved Media Convergence Server (MCS) platforms.
The industry recommendation to calculate the number of users who will be using the Hold feature in any telephony system is approximately 1 to 2 percent of the total user base. This could be network or end-user hold. Based on the numbers that you derive by using this formula, you can choose either a co-resident or a dedicated MoH server solution.
Another approach to the MoH design is to enable MoH on the CallManager servers and monitor the MoH server performance counters (refer to “Memory Upgrades” in Chapter 9, “Operations and Optimization,” for a discussion on Performance Monitor counters and monitoring procedures) to check the MoHOutOfResources performance counter for the Cisco MoH device performance object. If you see this counter going up, you can plan to add the dedicated MoH server to the network.
With multisite IPT deployment models, enabling the MoH feature for the remote branches consumes bandwidth on the WAN links. If you enable MoH, ensure that you provision the Low Latency Queueing (LLQ) for WAN links to include the additional bandwidth required for the MoH streams.
Finally, you have to consider whether you want to enable unicast, multicast, or both for MoH streams. Multicast MoH is attractive especially when streaming the audio files from the central site MoH server. Consider the scenario in which two IP Phones at the remote site place their respective callers on hold. With multicast MoH, only one stream traverses from the MoH server to the remote-site router, whereas with unicast MoH, two separate streams would go from the MoH server to each IP Phone, which consumes twice the bandwidth. In XYZ, the approach taken to deploy MoH across the network is as follows:
One CallManager in the cluster runs the MoH server, and all the central site users receive the audio streams from this MoH server via unicast.
In addition to the capability of CallManager to provide centralized MoH, the remote-site routers at Seattle and Melbourne can function as multicast MoH resources. This allows a distributed MoH design. This feature is available on the routers starting with Cisco IOS releases 12.2(15)ZJ2 and 12.3(4)T.
XYZ has no plans to deploy the MoH feature for the Dallas and Brisbane sites. A Beep/Tone on Hold is played when a user in either of these two locations is placed on hold. The Beep/Tone on Hold replaces MoH when MoH is turned off. Instead of hearing music, the user on hold will hear a beep/tone every 10 seconds (could be more or less depending on the configuration of a service parameter in CallManager)
Cisco offers a wide variety of IPT applications that integrate with CallManager. Deploying these applications in the network adds functionality and, in some cases, helps to increase the overall productivity of the organization. Based on the requirements received by XYZ, it requires the following applications:
AutoAttendant (AA)
Interactive Voice Response (IVR)
Call Center
XYZ requires an application that can provide full-time AutoAttendant functionality to take every call on the first ring, present to the caller a menu of options, and provide the following three choices:
Dial by extension
Dial by name
Transfer to the operator
XYZ has a dedicated number for the AutoAttendant. Every external caller who calls this number reaches the AutoAttendant application’s main menu and is provided with the preceding three choices.
XYZ also has a separate number to reach an IVR system. When external callers call this number, the IVR system provides the caller with the following two options:
Transfer to the AutoAttendant
Transfer to the sales and support group
In San Jose, the AutoAttendant application is based on the Cisco Customer Response Server (CRS) engine. In implementation (when users reach the AutoAttendant application in San Jose), the search scope includes all the employees of XYZ in the San Jose, Seattle, and Dallas sites. Note that you can also implement the AutoAttendant application by using Cisco Unity. The Directory Partitioning feature in Cisco Unity allows us to limit the search scope to any branch based on the user’s selection. Refer to the “Multiple Directory Handlers” section of Chapter 7 for details on implementing the AutoAttendant feature in Cisco Unity.
XYZ needs a call center capability in the IPT network. The XYZ call center group consists of 20 personnel from the sales group and support groups, all of whom are employees of XYZ, USA. These groups are responsible for answering customer calls regarding the new sales and support of existing products.
At any given time, 20 personnel will be servicing the customers. The call center operates from 8 a.m. to 5 p.m., Monday through Friday. The proposed architecture includes a CRS/IP Contact Center (IPCC) Express solution, which is best suited for companies such as XYZ that have a small- to medium-scale call center network.
According to the proposed voice-messaging architecture for XYZ, the present Octel voice-mail system at San Jose integrates with CallManager via the Simplified Message Desk Interface (SMDI). Cisco Unity replaces the voice-mail system at Sydney. The remote locations in Australia will use the Sydney Unity voice-mail system.
Whereas Chapter 7 provides the details of the voice-messaging system design, this chapter covers the configuration and design requirements to configure the CallManager system to support the proposed voice-mail architecture.
Cisco CallManager, which is the key part of Cisco IPT solution, requires configuration and customization to meet specific requirements. When you are designing the IPT solution for large-scale enterprises, it is critical to understand the call-routing, sizing, and future growth requirements and to translate those requirements into CallManager configurations. This section provides the detailed design and configurations based on XYZ’s requirements.
The CallManager cluster (cluster 1) in San Jose, shown in Figure 6-1, consists of three CallManager servers: one CallManager publisher, SJCCMA-PUB, and two subscribers, SJCCMB-SUB1 and SJCCMC-SUB2. An additional server, SJCDHCPTFTP, acts as a DHCP and TFTP server. In large deployments, the best practice is to separate the TFTP/DHCP server functionality from the publisher server.
The servers perform the following roles in the U.S. cluster:
SJCCMB-SUB1—. Serves as the primary subscriber to which all the IP Phones, voice gateways, and other IPT endpoints register under normal operations.
SJCCMC-SUB2—. Serves as the secondary subscriber, which acts as a backup to the primary subscriber.
SJCCMA-PUB—. Keeps the read-write master database of the cluster’s configuration information. Also acts as a tertiary CallManager to keep the IPT service up and running should both subscribers fail.
SJCDHCPTFTP—. Serves the configuration and binary loads for the IPT endpoints in its role as a TFTP server and serves as a DHCP server to lease out the IP addresses for the IP Phones in San Jose.
Table 6-4 shows the CallManager server names, IP addresses, and server roles in the U.S. cluster. You perform CallManager server configuration via the Cisco CallManager Configuration page in Cisco CallManager Administration (choose System > Cisco CallManager).
Table 6-4. U.S. CallManager Servers
CallManagerServer Name | CallManagerServer IP Address | Server Role | Auto-RegistrationInformation |
---|---|---|---|
SJCCMA-PUB | 10.1.1.5/27 | Publisher | Auto-Registration Disabled on This CallManager: Checked Partition: <None> |
SJCCMB-SUB1 | 10.1.1.6/27 | Subscriber—primary call processing for all devices | Auto-Registration Disabled on This CallManager: Unchecked Partition: p-autoregphone |
SJCDHCPTFTP | 10.1.1.7/27 | DHCP, TFTP server | Not applicable |
SJCCMC-SUB2 | 10.1.1.36/27 | Subscriber—secondary call processing for all devices; MoH server | Auto-Registration Disabled on This CallManager: Checked Partition: <None> |
Refer to Table 5-3 in Chapter 5 for the VLAN/IP addressing assignments designed for the XYZ network.
To access the CallManager Administration page from a web browser, use the following URL:
http://IP_Address_of_Publisher/ccmadmin
The CallManager cluster in Sydney consists of two CallManager servers, as shown in Figure 6-2. Table 6-5 shows the server names, IP addresses, and server roles.
Table 6-5. Australia CallManager Server Function
CallManagerName | CallManagerIP Address | Server Role | Auto-RegistrationInformation |
---|---|---|---|
SYDCCMA-PUB | 10.4.1.5/27 | Publisher, TFTP server, MoH server, and DHCP server | Auto-Registration Disabled on This CallManager: Checked Partition: <None> |
SYDCCMB-SUB1 | 10.4.1.36/27 | Subscriber—primary call processing for all devices | Auto-Registration Disabled on This CallManager: Unchecked Partition: p-autoregphone |
From now on, the CallManager cluster in San Jose will be called cluster 1, and the CallManager cluster in Sydney will be called cluster 2.
As shown in Tables 6-4 and 6-5, the XYZ network scenario enables auto-registration only for the primary CallManager servers. Auto-registration enables new phones to register with the CallManager server and get a directory number from the range specified in the CallManager configuration. The partition for the auto-registered phones is the partition (p-autoregphone) specified on the CallManager Configuration page.
You can use this auto-registration feature during the initial phase of the deployment to auto-register the IP Phones. The “Implementation of IP Phones Using BAT” section of Chapter 8, “Implementation,” discusses the IP Phone implementation methods using auto-registration and the Tool for Auto-Registered Phones Support (TAPS) service. Disable auto-registration after you complete the deployment, to avoid rogue phones registering to the cluster.
Many types of devices can register with CallManager, such as IP Phones, voice-mail ports, Computer Telephony Integration (CTI) ports, voice gateways, and DSP resources such as transcoding and conferencing. Each of these devices carries a different weight based on the amount of resources it requires from the server platform with which it is registered. The required resources include memory, the processor, and I/O. Each device then consumes additional server resources during transactions, which are normally in the form of calls. For example, a device that makes only 6 calls per hour consumes fewer resources than a device that makes 12 calls per hour. As a common starting point, the base weight of a device is calculated with the assumption that it makes six or fewer calls per hour during its busiest hour, or six busy hour call completions (BHCC). Refer to Table 1-3 in Chapter 1, “Cisco IP Telephony Solution Overview,” to get the base device weights for the various device types.
Tables 6-1 and 6-2 outline the hardware deployed in the IPT network. Table 5-1 in Chapter 5 provides the number of IP Phones required at each location. This information is useful in calculating the total device weight of the cluster. Table 6-6 shows the device weight calculation in the U.S. cluster.
Table 6-6. Device Weight Calculation of Cluster 1
Device Type | Weight per Session/Voice Channel [b] | Sessions/DS0sper Device[c] | Device Total [d] | CumulativeDevice Weightat XYZ Cluster 1e = b × c × d |
---|---|---|---|---|
IP Phone | 1 | 1 | 1180 | 1180 |
Analog SCCP ports (3 VG248s, 48 analog ports each) | 1 | 48 | 3 | 144 |
Analog MGCP ports (FXO/FXS) | 3 | 1 | 10 (10 FXO + FXS ports) | 30 |
CTI route point | 2 | 1 | 5 (5 CTI route points: AA, IVR, IP-ICD, IPMA, and TAPS) | 10 |
CTI client port | 2 | 1 | 60 CTI ports | 120 |
ICT gateway | 3 | 1 | 1 | 3 |
Digital MGCP T1 | 3 per DS0 | 23 | 7 T1s (6 in San Jose, 1 in Seattle) | 483 |
Conferencing resource(hardware) | 3 per session | 96 conferencing channels per ACT | 2 ACTs (one in each CMM Module deployed with separate chassis) | 576 |
36 conference channels (NMHDV) in Seattle | 1 | 108 | ||
Transcoding resource(hardware) | 3 per session | 32 transcoding channels per ACT | 2 ACTs (one in each CMM Module deployed in separate chassis) | 192 |
Total | 2846 |
Starting with CallManager 3.3, Cisco has a Cisco CallManager Capacity tool to size the CallManager clusters. This is a web-based tool and is currently not available on Cisco.com. The calculations shown in Tables 6-6 and 6-7 are valid for CallManager versions prior to 3.3. Because the CallManager Capacity tool is not available on Cisco.com, we have used the old method (by using device weights) to size the CallManager cluster. Until the tool is available on Cisco.com (when you are dealing with complex Cisco IPT deployments involving large number of IP Phones, gateways, multiple lines per IP Phone and so forth), contact your local Cisco sales team to help size the CallManager cluster(s) for your IPT deployments.
Table 6-7. Device Weight Calculation in Cluster 2
Device Type | Weight per Session/Voice Channel [b] | Sessions/DS0s perDevice [c] | Device Total[d] | CumulativeDeviceWeightat XYZCluster 2e = b × c × d |
---|---|---|---|---|
IP Phone (includes Unity ports) | 1 | 1 | 609 | 609 |
Analog SCCP ports (2 VG248s; 48 analog ports each) | 1 | 48 | 2 | 96 |
Analog MGCP ports (FXO/FXS) | 3 | 1 | 10 | 30 |
CTI route point | 2 | 1 | 2 (2 CTI route points: AA, IVR) | 4 |
CTI client port | 2 | 1 | 40 (CTI ports) | 80 |
ICT gateway | 3 | 1 | 1 | 3 |
Digital MGCP E1 | 3 per DS0 | 30 DS0s per E1 port | 5 (4 E1s in Sydney, 1 E1 inMelbourne) | 450 |
Conference resource (hardware) | 3 per session | 32 per port | 2 E1 ports | 192 |
36 conference channels (NM-HDV) in Melbourne | 1 | 108 | ||
Transcoding resource (hardware) | 3 per session | 32 per port | 2 E1 ports | 192 |
Total | 1764 |
The total number of device units that a single Cisco CallManager can control varies, depending on the server platform. The Media Convergence Server model MCS-7835 supports up to 5000 device weight units. From Table 6-6, with a total device weight of 2846, the CallManager cluster designed with MCS-7835 servers can handle the load of all the registered devices and also gives enough room for future expansion of the IPT network.
Similarly, Table 6-7 shows the device weight calculation for cluster 2. A cluster of two MCS-7835 servers can handle the calculated load.
The Customer Response Solution (CRS) server is deployed to roll out a small call center and an AA. The call center script application uses the default icd.aef script provided with the CRS platform plus other additions that consist of including the time of the day and the day of the week routing.
Effective with release 3.0, Cisco Customer Response Application (CRA) has been renamed Cisco Customer Response Solution and, effective with release 3.1, the CRS product is marketed under the names IPCC Express and IP IVR.
In this chapter and the rest of the book, the names CRS, CRA, and IPCC Express are used interchangeably.
Sizing a call center consists of sizing the following items:
Number of agents—. Agents that handle incoming calls
Number of IVR ports—. Ports that handle sessions such as prompting and collecting information at the front end of a call center system
Number of gateway/PSTN trunks—. Ports handling calls originating from the PSTN
To size the call center parameters, two types of traffic models are used (which are named after A. K. Erlang, a Danish scientist):
Erlang-B—. Use to size IVR ports and gateway trunks. This model assumes the following:
—Calls arrive randomly into the network.
—A percentage of calls is lost or blocked if the trunks are busy. This percentage is not queued.
Erlang-C—. Use to size the number of agents in call centers in which calls are queued before being presented to agents. This model assumes the following:
—Calls are presented randomly to the servers.
—Callers who find all agents busy are queued, not blocked.
The first step to size a call center is to determine the number of agents using the Erlang-C traffic model. This model relies on the following parameters:
Busy hour call attempts (BHCA)—. The number of calls received in the busy hour
Average handle time (AHT)—. The average duration (talk time) of the call
Average work time (AWT)—. The average agent wrap-up time after the caller hangs up
Service level goal—. The percentage of the calls to be answered within a certain number of seconds
Table 6-8 shows the values of these parameters as provided by XYZ. The telecom department provided these numbers by analyzing the historical reports from the legacy call center.
Table 6-8. Erlang-C Value Parameters for Agent Sizing
Parameter | Value |
---|---|
BHCA | 200 |
AHT | 180 seconds |
AWT | 30 seconds |
Service-level goal | 90% of calls answered within 15 seconds |
To determine the number of agents and other parameters, insert the values in Table 6-8 in the Call Center Calculator, available at http://www.erlang.co.uk/ccc.htm.
As the highlighted row in Figure 6-3 shows, the service-level goal that is nearer to the requirement of 90 percent (refer to Table 6-8) is 93 percent. This requires 17 agents, and XYZ already plans to have 20 agents in the call center. Table 6-9 lists other parameters and values that resulted from this calculation.
Table 6-9. Call Center Calculator Results
Parameter | Description | Value |
---|---|---|
Agents | Number of agents needed to meet the service-level goal | 17 |
Srv Lvl | Percentage of the calls that will be answered within the service level time | 93% |
Queued | Percentage of calls that will have to queue for a period of time before being answered by an agent | 10% |
Q Time | The average time spent in the queue for those calls that have to queue (when no agents are available) | 39 seconds |
In Figure 6-3, the Trunks column shows the number of PSTN trunks required for this call center. This number is irrelevant in this calculation because sizing the PSTN trunks uses the Erlang-B model, not the Erlang-C model. This calculator is based on the Erlang-C model used for call center sizing.
The second step is to determine the number of IVR ports needed for the XYZ call center. In the case of the Cisco IPT solution, IVR ports are the CTI ports. A CTI port is a computer telephony logical device that handles telephony devices, such as ports used for queuing and handling IVR sessions.
Use the Erlang-B model to calculate the IVR ports. This model relies on the following parameters:
BHCA—. Number of calls received in a busy hour.
AHT—. The average duration of the call for self-service applications, which includes both the initial treatment or information gathering and the queuing time:
—Initial waiting period when a caller reaches the system—. In the case of XYZ, the only call treatment done when a caller enters the application script is in the prompt time, which lasts 15 seconds. Hence, initial treatment time + information gathering time = 15 seconds
—Wait time in the IVR queue—. The number of seconds the user has to wait in the queue. The percentage of queued calls must also be considered, because this affects the number of IVR ports required. The average queue time (Q Time) is taken from the Erlang-C calculation in Table 6-9. This time equals 39 seconds.
Busy hour traffic (BHT) in Erlangs—. Each subcategory of the AHT is calculated through the following formula:
BHT = (BHCA × AHT seconds) ÷ 3600
In calculating the BHT for the wait time in the IVR queue, a BHCA of 20 is used in Table 6-10 because with the 17 agents (refer to Table 6-9), only 10 percent of the total calls is queued (10 percent of 200 is 20).
Table 6-10. Erlang-B Values for IVR Sizing
Parameter | Value |
---|---|
BHCA | Total BHCA: 200 Queued BHCA: 20 (10%, taken from Table 6-9) |
IVR AHT | Call treatment: 15 sec Average queue time: 39 sec |
BHT in Erlangs | BHT1 = 200 × 15 ÷ 3600 = 0.833 BHT2 = 20 × 39 ÷ 3600 = 0.216 Total IVR BHT = 1.049 |
Blockage | 0.1% |
Blockage or grade of service—. The percentage of calls that is blocked due to unavailability of IVR ports.
Table 6-10 shows the values of BHCA, AHT, BHT, and blockage for XYZ.
To determine the number of IVR ports, use one of the Erlang-B calculators available at these URLs:
Figure 6-4 shows that the number of IVR ports required for the call treatment is 5.9, or 6. As mentioned earlier, in the Cisco IPT solution, the IVR ports are equivalent to CTI ports. Hence, a minimum of six CTI ports is required for the call center solution.
The third step is to determine the number of PSTN trunks needed for the XYZ call center. As mentioned earlier, you use the Erlang-B model to size the gateway trunks.
This model relies on the following parameters:
BHCA—. The number of calls received in a busy hour.
AHT—. The average time of a call for IVR treatment, queuing, and agent talk time. Wrap-up time is not included in the calculation because a PSTN trunk is not used.
BHT in Erlangs—. BHT = (BHCA × AHT seconds) ÷ 3600.
Blockage or grade of service—. The percentage of calls that will get a busy tone (because no trunks are available) out of the total BHCA.
Table 6-11 shows the values of BHCA, AHT, BHT, and blockage for XYZ.
Table 6-11. Erlang-B Values for PSTN Trunk Sizing
Parameter | Value |
---|---|
BHCA | 200 |
AHT | 180 seconds |
BHT in Erlangs | BHT3 = 200 × 180 ÷ 3600 = 10 BHT = IVR BHT + BHT3 = 11.049 |
Blockage | 1% |
To determine the number of PSTN trunks, use one of the Erlang-B calculators available at the following URLs:
As shown in Figure 6-5, the number of PSTN trunk ports required for the XYZ call center is 18.8, or approximately 19. XYZ already has six PRIs in which the required trunks for the call center have been included. When you are sizing call center IVR ports and PSTN trunks, it is better to over-provision; cost of extra capacity is much cheaper than loss of revenue.
Cisco has introduced Cisco IPC Resource Calculator to size the contact center resources such as number of agents, IVR ports, PSTN trunks and so forth. This calculator is an integrated tool that uses the call center calculator, Erlang B and Erlang C calculators discussed in this section and provides you with the same results with a single click of a button.
This calculator is currently available on Cisco.com and is currently accessible by only Cisco partners. Cisco is working on making this tool available to all other Cisco customers. Cisco Partners can use the following URL to access the Cisco IPC resource calculator:
The CallManager group lists the CallManager servers in the order of priority. IP Phones and other endpoints attempt to register with the first CallManager server specified in the CallManager group. If the first server is not available, the group attempts to register with the second server, followed by the tertiary server.
Tables 6-12 and 6-13 show the CallManager group naming convention and server priority within the CallManager group for XYZ. As shown, auto-registration for these CallManager groups is enabled. As discussed earlier in the “CallManager Cluster Design” section, the auto-registration feature enables new phones to register with the CallManager server and get a directory number. To enable auto-registration at the CallManager group level, you must enable it on at least one CallManager in the group.
Table 6-12. CallManager Group Configurations in Cluster 1
Cisco CallManager Group | Selected Cisco CallManagers (Ordered by Highest priority) | Priority | Auto-Registration Cisco CallManager Group |
---|---|---|---|
SJ-GRP-1 | SJCCMB-SUB1 SJCCMC-SUB2 SJCCMA-PUB | 1 2 3 | Checked |
Table 6-13. CallManager Group Configurations in Cluster 2
Cisco CallManager Group | Selected Cisco CallManagers (Ordered by Highest Priority) | Priority | Auto-Registration Cisco CallManager Group |
---|---|---|---|
SYD-GRP-1 | SYDCCMB-SUB1 SYDCCMA-PUB | 1 2 | Checked |
To avoid rogue phones registering to the cluster, you should either turn off auto-registration for the CallManager group at the end of the initial phase of IP Phone deployment or configure the CallManager such that auto-registered phones cannot make calls other than to a security number. Refer to the “Auto-Registration” section in Chapter 9, “Operations and Optimization,” for more information on restricting calling from auto-registered phones.
From Table 6-12, you can see that all the IPT endpoints, such as IP Phones and voice gateways, register to the SJCCMB-SUB1 server, which is the primary subscriber. If SJCCMB-SUB1 is not reachable, the IPT endpoints attempt to register with SJCCMC-SUB2. If both SJCCB-SUB1 and SJCCMC-SUB2 are not reachable, the devices attempt to register with the publisher server, SJCCMA-PUB, as a last resort. To define or modify CallManager group configurations, go to the Cisco CallManager Group page. (From Cisco CallManager Administration, choose System > Cisco CallManager Group.)
Table 6-13 shows the CallManager group configurations for the Sydney cluster, which has two CallManager servers. Because the SYDCCMB-SUB1 server is listed as the first priority in the CallManager group definition, IPT endpoints attempt to register with this server. If they fail, they attempt to register with the SYDCCMA-PUB server.
Several CallManager Date/Time groups must be configured, as shown in Tables 6-14 and 6-15, to accommodate the geographically distributed locations.
Table 6-14. Date/Time Group Configurations in Cluster 1
Group Name | Time Zone | Date Format | Time Format |
---|---|---|---|
PST | (GMT-08:00) Pacific Time | M/D/Y | 12-hour |
CST | (GMT-06:00) Central Time | M/D/Y | 12-hour |
To perform the date/time group configuration, go to the Date/Time Group page. (From Cisco CallManager Administration, choose System > Date/Time Group.)
CallManager synchronizes the date/time settings on the IP Phones every time the user goes off-hook/on-hook on the IP Phone. If the phone is not in use, by default, CallManager sends an SCCP message to update the phone’s date/time every day at 3 a.m.
Table 6-15 lists two different date/time group names but only one time zone. The reason is that Brisbane does not observe daylight savings but Melbourne and Sydney do.
Regions in CallManager let you specify the voice codec that can be used for calls between devices within that region and between that region and other regions. After regions are configured, each device is assigned to a region via the Device Pool Configuration page. (Refer to “Device Pool Configuration” later in this chapter).
For XYZ, calls within the same location are set to use the G.711 codec. Calls traversing the WAN use the G.729 codec type to conserve the bandwidth across the WAN links. There are three regions:
One region per physical location in each cluster.
An additional region per cluster for the remote cluster.
An additional region called MoH-FAX. The “Music on Hold” and “Fax and Modem” sections explain why this extra region is needed. The MoH-FAX region is configured to use the G.711 codec when communicating with any other region.
To perform the region configuration, go to the Region page. (From Cisco CallManager Administration, choose System > Region.) Tables 6-16 and 6-17 show the region definitions for cluster 1 and cluster 2, respectively. As an example of how to read these tables, Table 6-17 lists G.729 in the cells in which Brisbane and Melbourne intersect, meaning that an interregion call between Brisbane and Melbourne is based on the G.729 codec scheme. In the cell in which Brisbane intersects with itself, G.711 is listed, indicating that an intraregion call in the Brisbane region is based on the G.711 codec scheme.
Locations work in conjunction with regions to define the characteristics of a network link. Regions define the type of compression (G.711, G.723, or G.729) that is used on the link, and locations define the amount of available bandwidth for the link.
Locations in the CallManager are used to implement call admission control (CAC) in a centralized call-processing model. Before permitting a call to a location, the CallManager looks up the Locations database to see if there is an available bandwidth to that location. CallManager rejects the call when there is not enough bandwidth to place the call to a location and, if Automated Alternate Routing (AAR) is configured, it routes the call through PSTN.
Figure 6-6 depicts the regions, locations, CODECs used for the calls within each region, CODECs used for the calls between the regions, and bandwidth required for the voice calls between all the sites of XYZ in cluster 1. You need to define one CallManager location per physical site within each cluster.
Tables 6-18 and 6-19 show the amount of bandwidth to be provisioned for each location based on the maximum number of calls allowed inbound and outbound. You can obtain the maximum number of calls to each site from the customers by using Table E-6 in Appendix E, “IPT Design Phase: IPT Requirement Analysis Questionnaire.” To determine these values, during the busy hour, measure the total number of calls (both inbound and outbound) from the central site and analyze how many calls were destined for any particular branch. This information gives the busy hour traffic for a site. Based on the available bandwidth for that particular branch, you can determine the maximum number of calls allowed over the IP WAN.
Table 6-18. CallManager Location Settings in Cluster 1
Location | Max. Calls | Bandwidth (kbps) |
---|---|---|
Seattle | 10 | 10 × 24 = 240 |
Dallas | 4 | 4 × 24 = 96 |
Seattle—fax | 1 | 1 × 80 = 80 |
Dallas—fax | 1 | 1 × 80 = 80 |
Table 6-19. CallManager Location Settings in Cluster 2
Location | Max. Calls | Bandwidth (kbps) |
---|---|---|
Melbourne | 8 | 8 × 24 = 192 |
Brisbane | 3 | 3 × 24 = 72 |
Melbourne—fax | 1 | 1 × 80 = 80 |
Dallas—fax | 1 | 1 × 80 = 80 |
As Table 6-18 indicates, we will allow a maximum of ten calls over the WAN link; the eleventh call is rejected and will be routed via the PSTN using the AAR mechanism. A G.729 call consumes 24 kbps and a G.711 call consumes 80 kbps. The fax endpoints at the branches will have their own locations, because we will be deploying fax pass-through without the up-speed feature. These types of calls are considered G.711 calls.
The calculations used in Tables 6-18 and 6-19 are for CallManager and are based on bandwidth consumption of 24 kbps per call for G.729 and 80 kbps per call for G.711. These numbers do not include the overhead values. However, when engineering the WAN links to ensure QoS, you must consider the overhead. Observe Table 5-9 where 30 kbps and 90 kbps of bandwidth are used for the G.729 and G.711 codec types, respectively. These values include the overhead.
To perform the location configuration, go to the Location page. (From Cisco CallManager Administration, choose System > Location.)
A device pool is a grouping of common parameters such as region, CallManager group, date/time group, and so forth that can be applied to a group of devices. Some of these parameters are also configurable at the device level. The parameters that are configured at the device level take precedence over the parameters that are configured at the device pool level.
Each cluster has four device pools. For example, device pool DP-SanJose includes all the devices in San Jose, such as IP Phones and gateways.
To perform the device pool configuration, go to the Device Pool Configuration page. (From Cisco CallManager Administration, choose System > Device Pool.) Tables 6-20 and 6-21 list the field names and the values to enter for each of the device pools.
Table 6-20. Device Pool Settings in Cluster 1
Device Pool Name | Cisco CallManager Group | Date/Time Group | Region | Calling Search Space for Auto-Registration |
---|---|---|---|---|
DP-SanJose | SJ-GRP-1 | PST | San Jose | CSS-taps |
DP-Seattle | SJ-GRP-1 | PST | Seattle | CSS-taps |
DP-Dallas | SJ-GRP-1 | CST | Dallas | CSS-taps |
DP-MOH-FAX | SJ-GRP-1 | PST | MoH-FAX | CSS-taps |
Table 6-21. Device Pool Settings in Cluster 2
Device Pool Name | Cisco CallManager Group | Date/Time Group | Region | Calling Search Space for Auto-Registration |
---|---|---|---|---|
DP-Sydney | SYD-GRP-1 | Sydney | Sydney | CSS-taps |
DP-Melbourne | SYD-GRP-1 | Sydney | Melbourne | CSS-taps |
DP-Brisbane | SYD-GRP-1 | Brisbane | Brisbane | CSS-taps |
DP-MOH-FAX | SYD-GRP-1 | Sydney | MoH-FAX | CSS-taps |
The “Calling Search Space Design” section later in this chapter discusses the details of the calling search space (CSS) and partitions. At this point, simply note that the auto-registered phones do the following:
Obtain the CSS specified in the Calling Search Space for Auto-Registration field in the Device Pool Configuration page.
Obtain the directory number and the partition information from the information specified on the CallManager Configuration page.
Media resources provide resources for media mixing (conferencing), codec conversion (transcoding), MTP, and MoH. This section discusses the design of these media resources for the XYZ network.
As mentioned in the “High-Level IPT Design” section, the conferencing resources exist only in San Jose, Sydney, Seattle, and Melbourne. This section looks into the configuration steps required to set up the conference resources for these sites.
As previously discussed, enabling any feature, such as the software conference bridge feature, on the CallManager adds to the device weights. Based on the device weights in Table 6-6, you can see that the San Jose cluster has not reached its capacity.
Even though the CallManager servers have enough capacity to host software conferencing resources, they are disabled in both clusters. The reason for this is that a misconfiguration of the media resource groups and media resource group list can lead to their usage affecting the server performance.
The ACT port adapter in the Cisco CMM will provide conferencing resources for the San Jose site. The ACT port adapter contains four DSPs. We will use the DSP partitioning technique to register the DSPs as two separate resources in the CallManager. We will partition the DSPs in the ACT port adapter between two resource pools:
Conferencing pool—. Assign three DSPs: 3 × 32 = 96 channels
Transcoding pool—. Assign one DSP: 1 × 32 = 32 channels
To configure the ACT module in this fashion, perform the following procedures:
Add the conference bridge. (From the Cisco CallManager Administration page, choose Service > Media Resource > Conference Bridge.)
Table 6-22 shows the conference bridge settings to configure on the Conference Bridge page for the San Jose site.
Table 6-22. San Jose ACT Port Adapter on CMM Conference Bridge Settings
Parameter | Value |
---|---|
Conference Bridge Type | Cisco IOS Conference Bridge |
Conference Bridge Name | CFB001122334455 001122334455 is the MAC address of the Ethernet interface that is associated with the ACT module. |
Description | Cat6k-SJ-1 CMM ACT Media Card (slot 3) |
Device Pool | DP-SanJose |
Location | <None> |
In Tables 6-22 and 6-24, the location of the conference bridge is configured as <None> because the resources are located at the central sites.
Configure the CMM from the CLI.
version 12.2 ! hostname Gateway ! ! ms dsp firmware 0 bundled ms dsp firmware 1 bundled ms dsp firmware 2 bundled ! ! Gigabit Ethernet interface on the CMM module interface GigabitEthernet1/0 ip address 10.1.10.10 255.255.255.0 ! ! Internal Ethernet interface on the ACT module. ! This interface connects the ACT module to the Switch backplane interface Ethernet2/0 ip address 10.1.1.11 255.255.255.255 ! ! ACT module is in slot3 of the CMM module mediacard 3 ! 3 DSPs will be assigned to a pool called SanJoseCFB resource-pool SanJoseCFB dsps 3 ! ! Define the IP addresses of the CallManagers in cluster 1 sccp ccm 10.1.1.6 identifier 1 sccp ccm 10.1.1.36 identifier 2 sccp ccm 10.1.1.5 identifier 3 sccp ! ! Order in which the SCCP endpoint should register sccp ccm group 1 associate ccm 2 priority 1 associate ccm 3 priority 2 associate ccm 1 priority 3 associate profile 1 register CFB001122334455 ! dspfarm ! List all the CODECS supported by this conference pool dspfarm profile 1 conference adhoc codec g711ulaw packetization-period 30 codec g711alaw packetization-period 30 codec g729r8 packetization-period 30 codec g729ar8 packetization-period 30 codec g723r63 packetization-period 30 codec g723r53 packetization-period 30 ! Associate the resource pool previously defined to the conferencing function associate resource-pool SanJoseCFB
In Seattle, the NM-HDV module provides conferencing resources. The NM-HDV module is deployed with four PVDMs. Each PVDM contains three DSPs. The number of calls that can terminate on a DSP depends on the codec complexity. Codec complexity is the grouping of different codec types according to their processing overhead. For instance, G.711 and G.729a are considered medium-complexity codecs, whereas all the flavors of the G.723.1 codec are considered high-complexity codecs.
The T1-PRI circuit from the PSTN terminates on the NM-HDV module. DSP modules on NM-HDV convert the voice-call information received from the PSTN into the IP packet format. Two PVDMs are required for the T1 circuit, based on the following calculations: Under the medium-complexity codec mode, one DSP can provide four channels, so two PVDMs provide 2 × (3 DSPs × 4 channels per DSP) = 24 channels.
The two remaining PVDMs are assigned to the conferencing function. Each DSP has the capacity to handle one conference call of up to six participants. With the two PVDMs, this site can hold up to six conference calls, which is 36 sessions.
To configure the DSP partitioning, perform the following procedures:
Add the conference bridge. (From the Cisco CallManager Administration page, choose Service > Media Resource > Conference Bridge.)
Table 6-23 shows the conference bridge settings to configure in the CallManager for the Seattle site.
Table 6-23. Seattle NM-HDV Conference Bridge Settings
Parameter | Value |
---|---|
Conference Bridge Type | Cisco IOS Conference Bridge |
Conference Bridge Name | CFB00AABBCCDDEE 00AABBCCDDEE is the MAC address of the configured SCCP interface in the Cisco IOS router. |
Description | Seattle Cisco 3745 NM-HDV |
Device Pool | DP-Seattle |
Location | Seattle |
Configure the NM-HDV module on the 3745 routers from the CLI.
voice-card 1 dspfarm dsp services dspfarm ! sccp local Loopback0 sccp sccp ccm 10.1.1.6 priority 1 sccp ccm 10.1.1.36 priority 2 ! ! This command sets the IP Precedence value to be used by SCCP sccp ip precedence 5 sccp switchback timeout guard 180 ! Two PDVMs are assigned to the conferencing function for a total of 6 DSPs. dspfarm confbridge maximum sessions 6 dspfarm
In San Jose, the ACT port adapter in the CMM module provides the conferencing resources. In Sydney, the WS-X6608-E1 card in the Catalyst 6500 switch is the DSP resource used for conferencing. Referring to Table 6-1, Sydney has four E1 trunks connecting to the PSTN to route incoming and outgoing calls. We will deploy two WS-X6608-E1 modules in two different 6500 chassis to achieve redundancy and terminate two E1 trunks in each module from the PSTN. The WS-X6608-E1 module has eight E1 ports. Each port can be configured as conference, transcoder, or MTP resource.
In each WS-X6608-E1 module, port 3 is provisioned in the CallManager as a conferencing resource. In addition to provisioning the ports as hardware conference bridges on the CallManager Administration page, the only other configuration requirement in the Catalyst OS is to put the port in the right VLAN and enable DHCP.
Each port on the WS-X6608-E1 card can handle 32 participants in G.711 mode, with a maximum of 6 participants per conference call. In G.729 mode, the port can handle only 24 participants.
To provision the port on the WS-X6608-E1 card as a conference bridge, from the CallManager Administration page, choose Service > Media Resource > Conference Bridge and add the conference bridge with the settings shown in Table 6-24.
The Melbourne configuration is identical to Seattle’s configuration. We will be using the DSP partitioning technology in the NM-HDV module. In the CallManager Conference Bridge Configuration page, this conference resource belongs to the device pool DP-Melbourne and the Melbourne location. It is important to configure the device pool and location so that the right codec is chosen and the right amount of bandwidth is deducted for the CAC.
Cisco IPCC Express and IP IVR version 3.1 and higher support the G.711 codec and the G.729 codec. You have to choose one or the other, because deployment in a mixed-codec mode is not an option currently. If you deploy using the G.711 codec, all the prompts in the server are stored in the G.711 format. If a device across the WAN needs to establish a G.729 media stream to IPCC Express server, the stream has to go through a transcoder to convert the media to G.711 format. Because the IPCC Express server is collocated with the main PSTN gateway from which most of the calls will be coming, it makes more sense to deploy the server using the G.711 codec.
In addition to supporting both codec types, Cisco Unity can be deployed in a mixed-codec mode. Unity can handle the transcoding in software. We have observed that, in most cases, the quality of a stream transcoded with a hardware transcoder is much better than a stream transcoded in software. Hence, Unity will be deployed using G.711 prompts, and the transcoding capability to G.729 will be turned off to force the G.729 media streams to go through a hardware transcoder.
Transcoding devices will be deployed only in the central sites (San Jose and Sydney) because they need to be collocated with the Cisco IPCC Express and Unity server.
Recall the previous discussion of partitioning the ACT port adapter resources. The fourth DSP in the ACT module will be used for transcoding. The one that DSP configured for transcoding can handle 32 channels. Because each session uses two channels, the total number of transcoding resources is 16.
To configure the ACT module for transcoding, perform the following steps:
Add the transcoder on Transcoder page. (From the Cisco CallManager Administration page, choose Service > Media Resource > Transcoder and choose Add a New Transcoder.) Table 6-25 shows the transcoder settings to configure in the CallManager to add this transcoder for the San Jose site.
Table 6-25. San Jose ACT Port Adapter on CMM—Hardware Transcoder Settings
Parameter | Value |
---|---|
Transcoder Type | Cisco IOS Media Termination Point |
Device Name | MTP001122334455 001122334455 is the MAC address of the Ethernet interface that is associated with the ACT module. |
Description | Cat6k-SJ-1 CMM ACT Media Card (slot 3) |
Device Pool | DP-SanJose |
Configure the Cisco CMM from the CLI.
version 12.2 ! hostname Gateway ! ! ms dsp firmware 0 bundled ms dsp firmware 1 bundled ms dsp firmware 2 bundled ! interface GigabitEthernet1/0 ip address 10.1.10.10 255.255.255.0 !Internal Ethernet Interface on the ACT Module. ! This interface connects the ACT module to the Switch backplane interface Ethernet2/0 ip address 10.1.10.11 255.255.255.0 ! ! ACT Module is in slot3 mediacard 3 ! One DSP will be assigned to a pool called SanJoseXcode resource-pool SanJoseXcode dsps 1 ! Define the IP addresses of the CallManagers in San Jose cluster 1 sccp ccm 10.1.1.6 identifier 1 sccp ccm 10.1.1.36 identifier 2 sccp ccm 10.1.1.5 identifier 3 sccp ! Order in which the SCCP endpoint should register. sccp ccm group 1 associate ccm 2 priority 1 associate ccm 3 priority 2 associate ccm 1 priority 3 associate profile 2 register MTP001122334455 ! dspfarm ! ! ! List all the CODECS supported by this conference pool dspfarm profile 2 transcode codec g711ulaw packetization-period 30 codec g711alaw packetization-period 30 codec g729r8 packetization-period 30 codec g729ar8 packetization-period 30 codec g723r63 packetization-period 30 codec g723r53 packetization-period 30 ! Associate the resource pool previously defined to the transcoding function associate resource-pool SanJoseXcode
The WS-X6608-E1 card in the Catalyst 6500 switch is the DSP resource used for transcoding in Sydney. Port 4 in each chassis will be provisioned in the CallManager as a transcoding resource. The only other configuration requirement in the Catalyst OS is to put the port in the right VLAN and enable DHCP. Note in the WS-X6608-E1 module that each port can handle 24 transcoding sessions.
Add the transcoder on the Transcoder page. (From the Cisco CallManager Administration page, choose Service > Media Resource > Transcoder and choose Add a New Transcoder.) Table 6-26 shows the transcoder settings to configure in the CallManager to add this transcoder for the Sydney site.
According to the XYZ requirements, the central and remote locations will use the MoH integrated feature with CallManager in the following manner:
San Jose users will use the second CallManager subscriber (SJCCMC-SUB2) as the MoH server.
Sydney users will use the CallManager publisher (SYDCCMA-PUB) as the MoH server.
Seattle and Melbourne will use the Cisco IOS MoH feature in the router. That will prevent MoH streams from traversing the WAN and will save bandwidth.
Brisbane and Dallas users will not use the MoH feature. Instead, users of Brisbane and Dallas will hear a Beep/Tone on Hold.
XYZ will deploy MoH using a single audio file stored in the MoH server. The default audio file that ships with the CallManager will be used in this case study.
To enable MoH for the San Jose and Sydney users, on the CallManager side, we need to configure the integrated MoH server on the backup subscribers in San Jose and on the publisher in Sydney.
To enable MoH for the Seattle and Melbourne branches, the local Cisco IOS gateway/router (3745) will be configured to stream permanently multicast RTP packets from an audio file stored locally in the Flash memory of the router. This feature is available in Cisco IOS versions 12.2.15ZJ2 and above.
The CallManager does not control the streaming part of the Cisco IOS router. The trick is to configure the Cisco IOS router to multicast the audio stream to the same IP multicast address and port as the one configured for the CallManager MoH server. When a phone in the remote site is placed on hold, the CallManager instructs that phone to join a multicast group to receive the audio. Because the multicast address to which the router is multicasting is identical to the one configured on the CallManager, the phone will start listening to the audio (MoH) sourced by the router that is sending this multicast stream.
Of course, you need to ensure that the multicast stream from the CallManager MoH server does not reach the remote sites via the IP WAN links. To achieve this, set the max hops parameter to 1 while configuring the MoH server, as shown in Table 6-27. The maximum hops parameter indicates the maximum number of routers that an audio source is allowed to cross. If the max hops parameter is set to 0, the audio source will remain in its own subnet. If max hops is set to 1, the audio source can cross up to one router to the next subnet.
Table 6-27. MoH Server Configuration in Cluster 1
Parameter | Value |
---|---|
Device Information | |
Host Server | IP address of the second subscriber: 10.1.1.36 |
Music on Hold Server Name | Generic name of the MoH entity: MOH-SJCCMC |
Device Pool | DP-MOH-FAX |
Location | <None> |
Max Half Duplex Streams | 30 (Recommended value for MoHcollocated with CallManager) |
Run Flag | Yes |
Multicast Audio Source Information | |
Enable Multicast Audio Sources on This MoH Server | Checked |
Base Multicast IP Address | 239.1.1.1 |
Base Multicast Port Number | 16384 |
Increment Multicast On | IP Address |
Selected Multicast Audio Sources | |
Audio Source Name | SampleAudioSource |
Max Hops | 1 |
To take advantage of this design, you have to do the following:
Configure the MoH server in the cluster and enable multicasting.
Configure the audio source file for multicasting.
Configure the remote-site router for MoH.
Configure the media resource groups (MRGs) and media resource group lists (MRGLs).
The next few sections cover the procedures to complete the preceding tasks.
To configure the MoH server in the San Jose CallManager cluster, from CallManager Administration, choose Service > Media Resources > Music On Hold Server. Use the values in Table 6-27 to configure the MoH server.
All the servers in the CallManager cluster have the MoH server enabled by default. To disable this service on the CallManager servers other than the servers designated as MoH servers, set the Run flag to No.
Another way to deactivate the MoH server is to deactivate IP Voice Media Streaming Service and MoH Audio Translator Service on the CallManager Serviceability page. However, disabling IP Voice Media Streaming Service also disables the software conferencing and MTP services. Setting the Run flag to No is a good option if you just want to disable the MoH server and keep the software conference and MTP resources running on the CallManager servers.
Note that even though the multicast MoH is turned on, unicast can still be used. Whether a device uses unicast or multicast depends on how the MRG and MRGL options are configured.
Another important point to discuss is the effect of the Increment Multicast On option. This setting affects the configuration required on the Cisco IOS router at the remote site. The result of setting this option to Increment Multicast on IP Address is that each MoH audio source and codec combination are multicasted to a different IP address but uses the same port number. The result of setting this option to Increment Multicast on Port Number is that each MoH audio source and codec combination is multicasted to the same IP address but uses a different destination port number. Table 6-28 illustrates this distinction, assuming base IP address 239.1.1.1 and base port 16384.
Table 6-28. Effect of Increment Multicast On Option
Increment Multicast onIP Address | Increment Multicast on PortNumber | ||||
---|---|---|---|---|---|
AudioStream | Codec | Dst. IPAddress | Dst. Port | Dst. IP Address | Dst. Port |
1 | G.711 ulaw | 239.1.1.1 | 16384 | 239.1.1.1 | 16384 |
1 | G.711 Alaw | 239.1.1.2 | 16384 | 239.1.1.1 | 16386 |
1 | G.729 | 239.1.1.3 | 16384 | 239.1.1.1 | 16388 |
1 | Wideband | 239.1.1.4 | 16384 | 239.1.1.1 | 16390 |
2 | G.711 ulaw | 239.1.1.5 | 16384 | 239.1.1.1 | 16392 |
2 | G.711 Alaw | 239.1.1.6 | 16384 | 239.1.1.1 | 16394 |
2 | G.729 | 239.1.1.7 | 16384 | 239.1.1.1 | 16396 |
2 | Wideband | 239.1.1.8 | 16384 | 239.1.1.1 | 16398 |
It is important to know exactly which audio stream and codec CallManager will choose when you are placing on hold a device that will receive Cisco IOS MoH. After these are known, you specify the correct multicast IP address and port number when configuring the Cisco IOS router at the remote site.
MoH on Cisco IOS routers supports G.711 only. Therefore, you have to make sure that the MoH server is situated in a region that is configured to open a G.711 MoH connection when a device at the Seattle site is placed on hold. Table 6-20 defines a separate device pool called DP-MOH-FAX for this purpose. As Table 6-27 indicates, the MoH server is in the device pool DP-MOH-FAX.
By default, the audio sources are configured for unicast only. To configure the audio source file for multicast, go to the MoH Audio Source page. (From CallManager Administration, choose Service > Media Resource > Music on Hold Audio Source.) Choose Allow Multicasting to enable the multicasting for the audio source.
Table 6-29 shows the other settings for configuring the MoH audio source.
Table 6-29. MoH Audio Source Configuration Settings
Parameter | Value |
---|---|
MoH Audio Stream Number | 1 |
MoH Audio Source File | SampleAudioSource |
MoH Audio Source Name | SampleAudioSource |
Play Continuously (repeat) | Checked |
Allow Multicasting | Checked |
After configuring the audio source, you need to assign it to the devices. As mentioned before, CallManager supports two types of hold: Network Hold and User Hold. You can specify the same or different audio source files for each type of hold. In the CallManager, there are four ways to assign the audio source file to the devices:
Directory number level
Device level
Device pool level
Cluster-wide default setting; two parameters define the default values:
—Default Network Hold MoH Audio Source ID (Default 1)
—Default User Hold MoH Audio Source ID (Default 1)
CallManager chooses the audio source specified at directory number level as a first choice. If none is specified, it checks at the device level. If none is found at this level, it moves to device pool level. If no audio sources are specified in any of these three levels, CallManager chooses the audio source specified in the service parameters.
To access the default settings, from the CallManager Administration page, choose Service > Service Parameters. The default value 1 means play Audio Source File 1.
The best practice is to assign the audio sources to the device pool level. Tables 6-20 and 6-21 define the device pools configured for both clusters. We will assign the SampleAudioSource ID 1 for the Network Hold MoH audio source and User Hold MoH audio source options.
After you configure the MoH server and the audio source, the next step is to configure the remote-site router to stream the audio file from Flash memory.
Example 6-1 shows an example of the Cisco IOS router configured for multicast MoH.
Example 6-1. Multicast MoH Cisco IOS CLI Configuration
ccm-manager music-on-hold interface Loopback0 ip address 10.2.11.1 255.255.255.255 interface FastEthernet0/0.33 ip address 10.2.1.1 255.255.255.0 call-manager-fallback ip source-address 10.2.1.1 port 2000 max-ephones 48 max-dn 96 ! Defining the filename in the flash to be played moh music.au ! Defining the multicast base address. ! It has to match the one configured in the CallManagerRefer to Table 6-27. multicast moh 239.1.1.1 port 16384 route 10.2.1.1 10.2.11.1
A media resource group is a group of media resources (conference bridges, transcoder, and MoH server), possibly of different types, that is logically bundled for load-sharing purposes. A media resource group list is an ordered list of MRGs used for redundancy purposes.
In XYZ, different media resources are deployed throughout the network. To ensure the right media resources are selected, we will design different MRGs and MRGLs.
Before you design the MRGs and MRGLs, you need to understand the media resource access requirements per site. For cluster 1, the requirements are as follows:
San Jose local endpoints should use the following:
—Conferencing resources in San Jose
—Transcoding resources in San Jose
—MoH resources in San Jose—unicast
Seattle endpoints should use the following:
—Conferencing resources on the local router as a primary choice, resources in San Jose as a backup if the primary resources on the local router are unavailable or exhausted
—Transcoding resources in San Jose
—MoH streamed from the local Cisco IOS router—multicast
Dallas endpoints should use the following
—Conferencing resources in San Jose
—Transcoding resources in San Jose
—No MoH; instead, play a Beep on Hold/Tone on Hold
Tables 6-30 and 6-31 show the design details of the MRGs and MRGLs, respectively, to meet the cluster 1 requirements.
Table 6-30. MRG Settings in Cluster 1
Media Resource Group Name | Devices for This Group – Selected Media Resources | Description/Comment |
---|---|---|
MRG_SJ | CFB001122334455(CFB) CFB001122334456(CFB) MOH-SJCCMC(MOH) | Cat6k-SJ-1 CMM ACT CFB Cat6k-SJ-2 CMM ACT CFB MOH Server (Use Multicast for MoH Audio—unchecked) |
MRG_Seattle | CFB00AABBCCDDEE(CFB) MTP001122334455(XCODE) MTP001122334456(XCODE) MOH-SJCCMC(MOH) | 3745 NM-HDV Cat6k-SJ-1 CMM ACT MTP Cat6k-SJ-2 CMM ACT MTP MOH Server (Use Multicast for MoH Audio—checked) |
MRG_Xcode | MTP001122334455(XCODE) MTP001122334456(XCODE) | Cat6k-SJ-1 CMM ACT MTP Cat6k-SJ-2 CMM ACT MTP |
MRG_CFB_SJ | CFB001122334455(CFB) CFB001122334456(CFB) | Cat6k-SJ-1 CMM ACT CFB Cat6k-SJ-2 CMM ACT CFB |
Table 6-31. MRGL Settings in Cluster 1
Media Resource Group List Name | Media Resource Groups for This List - Selected Media Resource Groups | Endpoints That Use This MRGL |
---|---|---|
MRGL_SJ | MRG_SJ | San Jose |
MRGL_Seattle | MRG_Seattle MRG_CFB_SJ | Seattle |
MRGL_Dallas | MRG_Xcode MRG_CFB_SJ | Dallas |
To configure the MRGs, from CallManager Administration, choose Service > Media Resource > Media Resource Group.
To configure the MRGLs, from CallManager Administration, choose Service > Media Resource > Media Resource Group List.
Table 6-31 indicates that the devices in Dallas do not have access to any MRGs that contain an MoH resource, per XYZ’s requirements. As a result, when Dallas users are placed on hold, they hear beeps only.
If a user in Dallas initiates an Ad Hoc conference call, all the media streams are moved to the central site. In the worse-case scenario, all participants are in Dallas, which results in most if not all the bandwidth allocated to this site being used; consequently, no one can call out of the site while the conference is in progress. If this becomes an issue, deploy local conferencing resources at the Dallas site. This also applies to the Brisbane site.
The design of the MRGs and MRGLs for cluster 2 is similar to that of the design of cluster 1. The only difference is that in cluster 2, we use E1 ports on the 6608 module as conferencing and transcoding resources, whereas for cluster 1, the conferencing and transcoding resources reside on the ACT port adapter on the CMM module. The configuration of MRGs and MRGLs is the same regardless of the use of different hardware.
The following are the requirements for cluster 2:
Sydney local endpoints should use the following:
—Conferencing resources in Sydney
—Transcoding resources in Sydney
—MoH resources in Sydney—unicast
Melbourne endpoints should use the following:
—Conferencing resources on the local router as a primary choice, resources in Sydney as a backup if the primary resources on the local router are either unavailable or exhausted
—The transcoding resources in Sydney
—MoH streamed from the local Cisco IOS router—multicast
Brisbane endpoints should use the following:
—Conferencing resources in Sydney
—Transcoding resources in Sydney
—No MoH; instead, play a Beep on Hold/Tone on Hold
Tables 6-32 and 6-33 show the design details of the MRGs and MRGLs, respectively, to meet the cluster 2 requirements.
Table 6-32. MRG Settings in Cluster 2
Media Resource Group Name | Devices for This Group - Selected Media Resources | Description/Comment |
---|---|---|
MRG_SYD | CFB00EEDDCCBBA9(CFB) CFB01EEDDCCBBA9(CFB) MOH-SYDCMA(MOH) | Cat6k-SYD-1 6608 4/3 Cat6k-SYD-2 6608 4/3 MOH Server (Use Multicast for MoH Audio—unchecked) |
MRG_MEL | CFB01AABBCCDDEE(CFB) MTP011122334455(XCODE) MTP011122334456(XCODE) MOH-SYDCMA(MOH) | 3745 NM-HDV Cat6k-SYD-1 6608 4/4 MTP Cat6k-SYD-2 6608 4/4 MTP MOH Server (Use Multicast for MoH Audio—checked) |
MRG_Xcode | MTP011122334455(XCODE) MTP011122334456(XCODE) | Cat6k-SYD-1 6608 4/4 MTP Cat6k-SYD-2 6608 4/4 MTP |
MRG_CFB_SYD | CFB00EEDDCCBBA9(CFB) CFB01EEDDCCBBA9(CFB) | Cat6k-SYD-1 6608 4/3 Cat6k-SYD-2 6608 4/3 |
Table 6-33. MRGL Settings in Cluster 2
Media Resource Group List Name | Media Resource Groups for This List - Selected Media Resource Groups | Endpoints That Use This MRGL |
---|---|---|
MRGL_SYD | MRG_SYD | Sydney |
MRGL_MEL | MRG_MEL MRG_CFB_SYD | Melbourne |
MRGL_BRI | MRG_Xcode MRG_CFB_SYD | Brisbane |
To configure the MRGLs, from CallManager Administration, choose Service > Media Resource > Media Resource Group List.
After designing the MRGs and MRGLs, you need to assign the MRGLs to endpoints. MRGLs determine what MRGs the device will access when requesting the media resources. The MRGLs can be assigned at the following levels:
Device level
Device pool level
Default MRGL—Contains the media resources that are not assigned to an MRG
CallManager chooses the MRGL at the device level if specified, and then checks at the device pool level. If no MRGL is specified at either level, it chooses the MRGs in the default MRGL list.
If you are not planning to use media resources, a best practice is to put them in an MRG and MRGL and not assign that MRGL to a device. Leaving the media resources without putting them in an MRG puts them into the default MRGL, where they remain accessible by the devices as a last resort.
The best practice is to apply the MRGL at the device pool level, so that all the devices using that device pool use the same MRGL. Tables 6-34 and 6-35 update Tables 6-20 and 6-21, respectively, by adding the settings of the Network Hold MoH Audio Source, User Hold MoH Audio Source, and MRGL fields to the device pool definitions. To configure or update the device pools, from CallManager Administration, choose System > Device Pool.
Table 6-34. Updated Device Pool Settings in Cluster 1
Device Pool Name | Cisco CallManager Group | Date/Time Group | Region | Calling Search Space for Auto-Registration | MRGL | Network Hold MoH Audio Source; User Hold MoH Audio Source |
---|---|---|---|---|---|---|
DP-SanJose | SJ-GRP-1 | PST | San Jose | CSS-taps | MRGL_SJ | 1-SampleAudio Source; 1-SampleAudioSource |
DP-Seattle | SJ-GRP-1 | PST | Seattle | CSS-taps | MRGL_Seattle | 1-SampleAudio Source; 1-SampleAudioSource |
DP-Dallas | SJ-GRP-1 | CST | Dallas | CSS-taps | MRGL_Dallas | 1-SampleAudio Source; 1-SampleAudioSource |
DP-MOH-FAX | SJ-GRP-1 | PST | San Jose | CSS-taps | None | <None> |
Table 6-35. Updated Device Pool Settings in Cluster 2
Device Pool Name | Cisco CallManager Group | Date/Time Group | Region | Calling Search Space for Auto-Registration | MRGL | Network Hold MoH Audio Source; User Hold MoH Audio Source |
---|---|---|---|---|---|---|
DP-Sydney | SYD-GRP-1 | Sydney | Sydney | CSS-taps | MRGL_SYD | 1-SampleAudio Source; 1-SampleAudioSource |
DP-Melbourne | SYD-GRP-1 | Sydney | Melbourne | CSS-taps | MRGL_MEL | 1-SampleAudio Source; 1-SampleAudioSource |
DP-Brisbane | SYD-GRP-1 | Brisbane | Brisbane | CSS-taps | MRGL_BRI | 1-SampleAudio Source; 1-SampleAudioSource |
DP-MOH-FAX | SYD-GRP-1 | Sydney | Sydney | CSS-taps | None | <None> |
Each site within the U.S. and Australian clusters has a local gateway to access the PSTN. Each gateway is deployed for different purposes. Tables 6-36 and 6-37 show the function of each gateway in both clusters. These same tables show the signaling protocol used on the gateways to communicate with CallManager.
Table 6-36. Cluster 1 Voice Gateways—Functions and Signaling
Location | Endpoint Name | Function | Signaling and OtherConfiguration Parameters |
---|---|---|---|
San Jose | S1/DS1-0@SJ-CMM1 S1/DS1-1@SJ-CMM1 S1/DS1-0@SJ-CMM2 S1/DS1-1@SJ-CCM2 | PSTN access for San Jose users PSTN access for Dallas users (except 911 calls) Backup PSTN access for Seattle | Signaling: MGCP Device Pool: DP-SanJose Location: San Jose AAR Group: San Jose MRGL: MRGL_SJ |
S1/DS1-2@SJ-CMM1 S1/DS1-2@SJ-CMM2 | Access to the PBX for all sites | ||
Gatekeeper | Intercluster calls | ICT | |
Seattle | S1/DS1-0@R3745-SEA | PSTN access for Seattle users | MGCP with H.323 Fallback Device Pool: DP-Seattle Location: Seattle AAR Group: Seattle MRGL: MRGL_Seattle |
AALN/S2/SU0/0@R3745-SEA AALN/S2/SU0/1@R3745-SEA | Fax machines | ||
Dallas | AALN/S1/SU0/4@R2650-DAL AALN/S1/SU0/5@R2650-DAL AALN/S1/SU0/6@R2650-DAL AALN/S1/SU0/7@R2650-DAL | FXO: PSTN emergency FXO: All PSTN calls under SRST | MGCP with H.323 FallBack Device Pool: DP-Dallas Location: Dallas AAR Group: Dallas MRGL: None |
AALN/S1/SU0/0@R2650-DAL | Fax machine |
Table 6-37. Cluster 2 Voice Gateways—Functions and Signaling
Location | Name | Function | Signaling |
---|---|---|---|
Sydney | S0/DS1-0@SDA00EEDDCCBBA7 S0/DS1-0@SDA00EEDDCCBBA8 S0/DS1-0@SDA01EEDDCCBBA7 S0/DS1-0@SDA01EEDDCCBBA8 | PSTN access for Sydney PSTN access for Brisbane Backup PSTN access for Melbourne | Device Pool: DP-Sydney Location: Sydney AAR Group: Sydney MRGL: MRGL_SYD |
Gatekeeper | Interclustrer calls | ICT | |
Melbourne | S0/DS1-0@R3725-MEL | PSTN access for Melbourne users | MGCP with H.323 Fallback |
AALN/S2/SU0/0@R3725-MEL AALN/S2/SU0/1@R3725-MEL | Fax machines | ||
Brisbane | AALN/S1/SU0/4@R2650-BRI AALN/S1/SU0/5@R2650-BRI AALN/S1/SU0/6@R2650-BRI AALN/S1/SU0/7@R2650-BRI | FXO: PSTN emergency FXO: All PSTNs under SRST | MGCP with H.323 FallBack |
AALN/S1/SU0/0@R2650-BRI | FXS Fax machine |
A centralized Cisco IOS gatekeeper is deployed to provide call routing and CAC between the U.S. and Australia clusters. Calls between the two countries are routed primarily across the IP WAN and considered on-net calls. Under a WAN failure or insufficient bandwidth, calls are routed through the PSTN gateway in the central site.
To configure a gateway, from CallManager Administration, choose Device > Gateway. Click the Add New Gateway option on the Gateway configuration page. On the Add a New Gateway page, select the gateway type and device protocol used for signaling.
As an example, to add a T1/E1 port on a CMM module, choose Communication Media Module as the gateway type. To add a T1/E1 port on a WS-6608 module, choose Catalyst 6000 T1 (E1) VoIP Gateway. The preceding example is to configure the gateways to use the MGCP protocol. To configure a gateway to use the H.323 protocol, choose the H.323 gateway from the Gateway Type drop-down menu.
In Table 6-36, S1/DS1-0@SJ-CMM1 represents the MGCP digital endpoint for the T1 controller T1 1/0. Because the signaling protocol in use is MGCP and the T1 trunk is digital, these endpoints are called MGCP digital endpoints.
SJ-CMM1 is the Domain Name field configured when configuring the CMM module. This domain name must match the host name configured on the CMM module. The naming convention SJ-CMM1 indicates that this DS1 is located on the Cisco Communication Media Module CMM1, in a Cisco Catalyst 6500 switch located in San Jose.
S1/DS1-1@SJ-CMM1 represents the MGCP digital endpoint for the controllers T1 1/1.
AAL/S1/SU0/4@R2650-DAL represents the MGCP analog endpoint for the analog port 1/0/4. S1/SU0/4 represents the analog port 1/0/4 located in the NM-HDA of Cisco 2651XM.@R2650-DAL indicates that this is a Cisco 2651XM router located in Dallas.
These endpoints are called MGCP analog endpoints, because MGCP is the signaling protocol and the port is an analog port.
One of the naming conventions used in Table 6-37 differs from Table 6-36. In Table 6-37, the gateways use a different naming pattern. The reason is that the T1 gateways in San Jose are provisioned via the CMM module, and the E1 gateways in Sydney are provisioned using the WS-X6608-E1 module.
S0/DS1-0@SDA00EEDDCCBBA7 represents the MGCP digital endpoint for the T1 controller T1 1/0, where 00EEDDCCBBA7 is the MAC address of the T1 port. SDA stands for Selsius Digital Access.
Refer to Appendix F to order new T1/E1 circuits or modify the configurations on the existing circuits if required for deploying IPT.
All the PRI trunks in the U.S. and Australia are provisioned for ISDN User side, and the clocking is provided from the telco or the PBX.
The line coding in the U.S. is set to B8ZS and the framing to Extended Super Frame (ESF). In Australia, the line coding is set to HDB3 and the framing to CRC4.
The detailed configuration of the Cisco IOS router is provided, in the next section. The detailed configuration of the Cisco IOS voice gateways is provided in the “Survivable Remote Site Telephony” section, later in this chapter.
The other important parameters when designing the gateways are the inbound call routing settings such as significant digits, CSS, AAR CSS, and prefix DN. These parameters are discussed in the “Inbound Call Routing” section later in this chapter.
MGCP with H.323 Fallback in Tables 6-36 and 6-37 means that the MGCP gateway falls back to an H.323 session application when the WAN TCP connection to the primary Cisco CallManager server is lost and no backup Cisco CallManager server is available. When the WAN link is functional, the gateway communicates with CallManager via MGCP. During the WAN failure, the gateway loses the connectivity with the CallManager at the central site and acts as an H.323 gateway to route the calls.
An ICT is an H.323 connection that connects two Cisco CallManager clusters.
As you know, the XYZ IPT design consists of two CallManager clusters: cluster 1 and cluster 2. In this section, while discussing the dial plan architecture for XYZ, we focus specifically on cluster 1, and generally on cluster 2 only for clarity and simplicity. The dial plan architecture topics and detailed dial plan presented in Tables 6-38 to 6-53 cover all aspects of the dial plan for cluster 1. After you understand the methodology used in building the dial plan for cluster 1, building the dial plan for cluster 2 is not difficult, which is why the dial plan for cluster 2 is not presented specifically.
Table 6-38. DID and Numbering Plan at XYZ
Site Name | DID Range | Station Directory Range |
---|---|---|
San Jose | +1 408 555 3000 to +1 408 555 4999 | IP Phone DNs 3000–4999 |
+1 408 555 2500 to +1 408 555 2999 | PBX stations DNs 2500–2999 | |
Seattle | +1 206 555 2100 to +1 206 555 2199 | 2100–2199 |
Dallas | +1 972 555 5600 (Grouped line) +1 972 555 5611 (Fax) | 5601–5619 (non-DID numbers, private numbering plan) |
Sydney | +61 2 5555 6000 to +61 2 5555 6999 | 6000–6999 |
Melbourne | +61 3 5555 4300 to +61 3 5555 4399 | 4300–4399 |
Brisbane | +61 7 5555 8680 (Grouped line) | 8681–8699 (non-DID numbers, private numbering plan) |
The CallManager dial plan architecture handles two general types of calls:
Internal calls to IP Phones and other devices registered to the CallManager cluster
External calls through a PSTN or PBX gateway to another Cisco CallManager cluster over the IP WAN
The dial plan for internal calls registered with CallManager is simple. Configuring CallManager to handle external calls requires the use of a route pattern. In most cases, CallManager matches the dialed number against a route pattern for directing calls out to a PSTN gateway.
Before designing a dial plan, you need to obtain the existing numbering plan. The numbering plan provides the following information:
The Direct Inward Dial (DID) ranges per site
The length of the phone number extensions that are used internally
The number of digits forwarded by the local telephone company
If implementing Tail-End Hop-Off (TEHO), the local calling area codes for each site
In a private enterprise network, TEHO is the routing of a voice call over the internal network to the closest gateway to the destination of the call, and then connecting into the public network as a local phone call. In the XYZ network scenario, consider an employee in San Jose making a call to a phone number that is local to the Seattle office. With TEHO implementation, this call would go over the internal IP WAN from San Jose to Seattle to reach the PSTN gateway in Seattle. This makes the call a local call instead of a long-distance call. This solution eliminates long-distance calls between offices and achieves significant savings on telecom bills.
XYZ currently uses a four-digit numbering plan at every site, and the new IPT design keeps the same scheme. All the locations except for Dallas and Brisbane have DID numbers. This means that a call coming from a PSTN cannot directly reach the IP Phone or any other application without going through an operator.
Because Dallas and Brisbane sites do not have DID numbers, a private numbering scheme is required for these two locations. These two sites have four FXO trunks for inbound calling and for routing the outbound emergency calls. Table 6-38 provides the information on the existing DID and station-numbering plan collected during the planning phase through the questionnaire in Appendix C, “IPT Planning Phase: Telecom Infrastructure Analysis Questionnaire,” in the section “Telephony Numbering Plan.”
For XYZ, we will design the TEHO calling between the San Jose and Seattle locations. To design the TEHO, you need to obtain the local area codes for each site, as shown in Table 6-39. The San Jose site has three in-state local area codes, and you need to dial 11 digits to reach these numbers. Similarly, Seattle has two local area codes, and 11 digits are required to dial these numbers.
Table 6-39. Local Calling Area Codes
Site Name | Local Calling | In-State Toll Calling | ||
---|---|---|---|---|
Area Code/Exchange | Number of Digits to Dial | Area Codes/Exchange | Number of Digits to Dial | |
San Jose | 408 | 10 | 650 510 925 | 11 |
Seattle | 206 | 10 | 425 253 | 11 |
Besides the station numbering, you need another range of internal directory numbers for any device that does not require direct access from the PSTN. These can be CTI ports, CTI route points, Meet-Me conferences, Group Pickup, and Call Park numbers. Table 6-40 provides the details of the internal dial plan of cluster 1.
Table 6-40. Internal Dial Plan in Cluster 1
Station DN | Device Type | Description |
---|---|---|
3101-3999 | IP Phones | San Jose IP Phones |
4000–4199 | IP Phones | San Jose main extension for managers |
4800–4899 | IP Phones | San Jose proxy lines for managers |
4201–4299 | VG248 | San Jose fax machines |
2101–2150 | IP Phones | Seattle IP Phones |
2151–2152 | MGCP FXS | Seattle fax machines |
2100 | IP Phone | Seattle operator |
5602–5610 | IP Phones | Dallas IP Phones |
5601 | IP Phone | Dallas operator |
7XXX | ICD lines, intercom lines for managers and assistants | Secondary line for an ICD agent, an intercom line for a manager or assistant, or a proxy line for a manager; XXX is the last three digits of the main number |
5611 | MGCP FXS | Dallas fax machine |
3555 | voice mail pilot | Voice mail pilot number to reach the Octel voice-mail system |
1999 | MWI on | Turns the MWI on |
1998 | MWI off | Turns the MWI off |
1900–1997 | Voice-mail ports | Voice-mail ports |
1601–1610 | CTI ports | CTI ports for ICD |
1611–1630 | CTI ports | CTI port for AA |
3877 | CTI route point | AutoAttendant |
3888 | CTI route point | IP ICD |
3800 | CTI route point | IP IVR General number |
3889 | CTI route point | TAPS number |
40XX, 41XX, 210[1-4] | CTI route point | IPMA-Manager extensions in San Jose and Seattle locations |
1701–1720 | Meet-Me | Meet-Me conference |
1721–1740 | Call Park | Call Park |
1741–1760 | Group Pickup | Group Pickup |
80000-81000 | Auto-registered DN range | DN range for auto-registered phones |
You need to add a CTI port for each active voice line that you intend to use on an IP SoftPhone. The CTI port is actually a virtual device that allows you to create a virtual line.
Cisco IP Interactive Call Distribution (ICD) is an application that runs on Cisco CallManager to offer queuing and dispatch services for a call center or help desk environment. ICD can be used as part of IP Contact Center (IPCC) Express, but IPCC is not required to use ICD. In normal use, agents log into ICD using an application on their PC that signals to Cisco CallManager that they are ready to accept calls from a shared call-in number.
You are ready to begin designing the dial plan for cluster 1. The first step is to identify the types of calls in the network and come up with call-routing requirements. Cluster 1 has three kinds of calls:
Cluster 1 internal calls—. Internal calls originating from an IP Phone in one location calling to any other internal location reach the called party’s IP Phone directly (IP Phone-to-IP Phone calls within cluster 1). These types of calls must use IP WAN as the first preference and then use the local PSTN trunks to route the calls transparently to the user if the WAN link is not available or bandwidth is too exhausted to route the new calls.
Cluster 1 external calls—. Calls to any external numbers that are not part of the CallManager numbering plan.
San Jose Site:
—External calls that are local to Seattle use the PSTN trunks in Seattle but fall back to the San Jose gateway as a long-distance call if all the Seattle trunks are busy or unavailable (TEHO implementation).
—All other external calls (local, long distance, international) use San Jose PSTN trunks.
—All emergency calls use local PSTN trunks in San Jose.
—Incoming calls to the San Jose site arrive on the PSTN trunks in San Jose and reach any IP Phone or extension directly, because San Jose numbers are DID numbers.
—TEHO calls originating from Seattle and bound for the San Jose area are routed out via the PSTN trunks in San Jose.
—Calls that are not answered by IP Phone users are forwarded to voice mail.
—Calls made to the San Jose main number are forwarded to an AutoAttendant application on the CRS server.
—Calls made to reach the contact support personnel are forwarded to an IP-ICD application on the CRS server.
—External calls that are local to San Jose use the PSTN trunks in San Jose but fall back to the Seattle gateway as a long-distance call if all the San Jose trunks are busy or unavailable (TEHO implementation).
—All other external calls (local, long distance, international) use Seattle PSTN trunks as first preference and use San Jose trunks as a backup.
—All emergency calls use local PSTN trunks in Seattle.
—Incoming calls to the Seattle site arrive on the PSTN trunks in Seattle and reach any IP Phone or extension directly, because Seattle numbers are DID numbers.
—TEHO calls originating from San Jose and bound for the Seattle area are routed out via the PSTN trunks in Seattle.
—Calls that are not answered by IP Phone users are forwarded to voice mail.
Dallas Site:
—All external calls (local, long distance, international) use San Jose PSTN trunks to route the calls. If San Jose PSTN trunks are busy or unavailable (including WAN failure), no external calls can be made from the Dallas site.
—All emergency calls use local PSTN trunks in Seattle (two FXO trunks).
—Incoming calls to the Dallas site arrive on the PSTN trunks in Dallas (two FXO trunks). Because Dallas numbers are non-DID, the incoming calls are forwarded to the operator. The extension for the operator is 5601. Refer to the section “SRST for Dallas and Brisbane Remote Sites,” later in this chapter, to see which configuration is needed on the SRST-enabled Dallas router for this functionality.
—Calls that are not answered by IP Phone users are forwarded to voice mail.
Intercluster calls between cluster 1 and cluster 2—. Intercluster calls use IP WAN, using ICT as the first preference and PSTN trunks as the second preference.
The route plan determines all aspects of call handling. Many elements, as shown in Figure 6-7, define the route plan in CallManager. A brief description of all these elements follows:
Route patterns identify different groups of telephone numbers. For example, a route pattern of 3xxx matches any digits from 3000 to 3999. A route pattern of 3000 matches exactly the number 3000.
Route lists provide multiple paths to route a call. It is an ordered list of route groups. You associate a route pattern with a route list. When a dialed number matches a route pattern, CallManager routes the call via the route groups that are specified in the route lists.
A route group is an ordered list of devices/gateways that can route the call to different destinations. The route group can direct all calls to the primary device and then use the secondary devices when the primary device is unavailable. One or more route lists can point to the same route group. Because a gateway can be assigned to only one route group, the best practice is to assign each gateway to one route group if you want to use this gateway more than once in your dial plan or within different route patterns.
As shown in Figure 6-7, when you are configuring the route plan elements, the configuration order is a bottom to top approach, which means that the devices and gateways are configured first, followed by the route group, route list, and route patterns. On the other hand, CallManager process the call in a top to bottom approach. For example, when a user dials a number, CallManager checks whether it matches a route pattern. If there is a match, CallManager sends the call to the route list. CallManager checks the list of route groups in the route list. If there are multiple route groups, it sends the call out via the first route group. If the call cannot be completed (because no trunks are available in the devices in the route group), CallManager selects the second route group to route the call.
After you identify the call routing paths, the next step in designing the dial plan is to devise the partitions. A partition is a group of devices with similar reachability characteristics. The entities that you can place in partitions are the route patterns and directory numbers of IP Phones, voice-mail ports, CTI route points, CTI ports, messaging waiting indicator (MWI) On/Off devices, and so forth. The route patterns can match internal or external PSTN destinations.
We will define the partitions that group the route patterns that match the following criteria:
All internal numbers, CTI ports, and voice-mail ports
Special partitions required by applications such as Cisco IPMA
Emergency numbers per site
Local calling (within the same area code) per site
Long-distance calling per site
International dialing per site
Toll-free numbers per site
TEHO numbers per site
Because each site has local gateways that connect to the PSTN, you need to define the same route patterns per each site. For example, to route 911 calls, you need three route patterns in three different partitions, one per site. This allows you to route the 911 calls through the local gateways.
Also, note that in the previous classification, local, long-distance, and international route patterns are separated, which provides more flexibility in defining classes of restrictions (CoRs) on the end-user phones. As an example, to give an IP Phone access to call local numbers only, you would include only the local calling partition in the phone’s CSS. To give both local and long-distance access, you include the local and long-distance partitions in the CSS. The next section describes CSSs in greater detail.
Referring to Table 6-38, you can see that XYZ has nonoverlapping station directory ranges. The last four digits used for numbering the IP Phones for each site are unique. If you are designing a multisite network, you might be in a situation in which the last four digits are the same for two or more sites. To avoid the overlapped numbers, you should consider increasing the number of digits used for internal IP Phone numbering. For example, you should consider using four digits instead of three digits or using five digits instead of four digits to represent the directory numbers for the phones. If you still see overlaps, you cannot assign all the IP Phone numbers a single partition, as shown in Table 6-41; instead, assign the phones within each site to a different partition. If you put two or more lines that have the same directory number in a single partition, those numbers become shared lines.
Table 6-41. Partitions in Cluster 1
Partition Name | Description |
---|---|
P-Internal | Contains all IP Phones, fax machines, CTI ports, CTI route points, voice-mail ports, and Group Pickup |
P-Internal-Managers | Contains all managers’ directory numbers; needed to implement IPMA |
P-IPMA | Contains IPMA CTI route point |
P-Emergency-SJ | E911 dialing in San Jose |
P-Emergency-SEA | E911 dialing in Seattle |
P-Emergency-DAL | E911 dialing in Dallas |
P-TEHO-SJ | Contains area codes that are local to the San Jose office to implement TEHO calling for other sites |
P-TEHO-SEA | Contains area codes that are local to the Seattle office to implement TEHO calling for other sites |
P-Local-SJ | Contains local calling area codes in San Jose |
P-Local-SEA | Contains local calling area codes in Seattle |
P-LD-SJ | Contains long-distance area codes in San Jose |
P-LD-SEA | Contains long-distance area codes in Seattle |
P-INT-SJ | International calling in San Jose |
P-INT-SEA | International calling in Seattle |
P-Block | Blocked numbers, if any |
P-Block-Local | Block local calling |
P-Block-LD | Block long-distance calling |
P-Block-INT | Block international calling |
P-LD-AAR-SEA | Long-distance AAR for Seattle |
P-INT-AAR-SEA | International AAR for Seattle |
P-LD-AAR-DAL | Long-distance AAR for Dallas |
P-INT-AAR-DAL | International AAR for Dallas |
P-Autoregphone | Partition for the Autoregistered Phones and the TAPS CTI route point |
P-TollFree-SJ | Partition for toll free number access for San Jose users |
P-TollFree-SEA | Partition for toll free number access for Seattle users |
Table 6-41 provides the partitions created in the XYZ for the U.S. cluster to accommodate the dial plan.
To add partitions, from CallManager Administration, choose Route Plan > Partition and click the Add a New Partition option.
Observe in Table 6-41 that Dallas has its own partitions even though the PSTN trunks in San Jose are used to route local and long-distance calls originating from Dallas. This is required because we are routing the calls to different route lists depending on whether the call originates from Dallas or San Jose. Calls originating from San Jose use the San Jose partitions, whereas calls originating from Dallas use the Dallas partitions.
A CSS is an ordered list of partitions that a user’s phone searches before being allowed to place a call. CallManager uses CSS to define CoR levels. CSSs are assigned to devices that can initiate calls. These include IP Phones, Cisco SoftPhones, and gateways. Dialing restrictions are simple to invoke because users can dial only the partitions in the CSS to which they are assigned. Dialing a directory number outside an allowed partition causes the caller to receive a fast busy tone.
To reach a certain destination, the called party’s partition must be part of the calling party’s CSS.
With the help of the questionnaire in Appendix E, specifically the “Class of Restrictions Requirements” section, XYZ requires the four levels of CoRs listed in Table 6-42 in the IPT network.
Table 6-42. Classes of Restrictions Required
Class of Restriction Level | Which Calls Are Users Allowed to Make? | Which User Phones Require this CoR? |
---|---|---|
1 (Default) | Calls to all IP Phones, 911 and other services like 611, toll-free numbers (800, 866, 877), and voice mailNot allowed to dial 900 numbers | Lobby phones |
2 (Default + Local) | Level 1 access, plus local calls and TEHO calls to other locations | Break room phones |
3 (Default + Local + LD) | Level 2 access, plus long-distance calls | All employee phones, conference room phones |
4 (No restriction) | Level 3 access, plus international calls | All executives phones |
In CallManager, for an IP Phone, you can assign the CSS at two levels:
Line level (directory number level)
Device level (on the IP Phone itself)
When you define a CSS at both levels, as shown in Figure 6-8, CallManager does the following:
Combines the list of partitions at the line level and the device level.
Places the list of partitions in the line level ahead of those listed in the device level (beginning with CallManager release 3.1). In prior releases, the partitions in the device level are placed ahead of the partitions in the line level. CTI ports still use the old method. Therefore, if you are deploying applications such as IP SoftPhone, you should note this behavior.
Selects the best match from the combined list.
We will use this feature of combining the line- and device-level CSSs in CallManager to define the CoRs required for XYZ. For that, we define three types of CSSs, as follows:
CSS type 1—. Attached to line level. It gives the line a certain class of service. You need one CSS type 1 for each type of CoR required.
CSS type 2—. Attached to device level. It gives the device access to the local resources to reach the PSTN. You need one CSS type 2 for each branch.
CSS type 3—. A general type, assigned to resources suh as CTI ports, voice-mail ports, and the call-forwarding CSSs at the line level.
Table 6-43 outlines the list of CSSs to be provisioned, with a brief description for the U.S. cluster.
Table 6-43. Calling Search Space in Cluster 1
CSS Name | Selected Partitions (Ordered by Highest Priority) | Description | CSS Type |
---|---|---|---|
CSS-Line-Default | P-Block-Local P-Block-LD P-Block-INT | CSS to be attached to every line not allowed to call the PSTN except 911 and toll-free numbers. Example of such lines are in the lobby phones and IP Phones that support hot desking (enables users to “log on” to any IP Phone with just a PIN number). | 1 |
CSS-Line-Local | P-Block-LD P-Block-INT | CSS to be attached to every line that can make local calling only in addition to 911 and toll-free numbers. | 1 |
CSS-Line-LD | P-Block-INT | CSS to be attached to lines that can make any PSTN call except international calls. | 1 |
CSS-Line-Managers | P-Internal-Managers | CSS to be attached to the assistants’ lines. | 1 |
CSS-SJ | P-Block P-Internal P-IPMA P-Emergency-SJ P-TollFree-SJ P-Local-SJ P-LD-SJ P-INT-SJ P-TEHO-SJ | CSS to be attached to any device in San Jose. | 2 |
CSS-SEA | P-Block P-Internal P-IPMA P-Emergency-SEA P-TollFree-SEA P-Local-SEA P-LD-SEA P-INT-SEA P-TEHO-SEA | CSS to be attached to any device in Seattle. | 2 |
CSS-DAL | P-Block P-Internal P-IPMA P-Emergency-DAL P-TollFree-SJ P-Local-SJ P-LD-SJ P-INT-SJ | CSS to be attached to any device in Dallas. | 2 |
CSS-Restricted | P-Internal P-Block-Local P-Block-LD P-Block-INT | CSS that can reach the partition P-Internal only. This partition will be assigned to CTI ports and to CFB, CFNA, and CFA fields on the IP Phone’s directory numbers. | 3 |
CSS-AAR-SEA | P-LD-AAR-SEA P-INT-AAR-SEA | CSS to be assigned to AAR CSS in Seattle. | 3 |
CSS-AAR-DAL | P-LD-AAR-DAL P-INT-AAR-DAL | CSS to be assigned to AAR CSS in Dallas. | 3 |
CSS-Gateways | P-Internal P-Internal-Managers P-IPMA | CSS to be assigned to gateways so that they can reach the devices to extend the calls coming from the PSTN to the IPT devices. | 3 |
CSS-taps | P-autoregphone | This CSS is assigned at the device pool level. The autoregistered phones receive this CSS. | 1 |
To add CSSs, from CallManager Administration, choose Route Plan > Calling Search Space.
According to Table 6-43, you should do the following:
At the line level, assign CSS type 1 to each line depending of the class of service.
At the device level, assign CSS type 2 to each device depending on the location. For example, the device CSS for all IP Phones in San Jose will have CSS-SJ, in Seattle CSS-SEA, and in Dallas CSS-DAL.
Do not assign CSS (no CSS) for a line that has an unrestricted CoR. Such a device will inherit its calling privileges from the CSS configured at the device level (CSS type 2).
To see how the CSSs that are defined in Table 6-43 work, consider an IP Phone in San Jose that requires access only to dial 911 calls, toll-free calls, and local numbers. Figure 6-9 depicts the CSSs that are assigned to such an IP Phone at the line level and the device level to achieve the desired CoR for that IP Phone.
The line-level CSS is CSS-Line-Local, which is CSS type 1. It consists of two partitions, P-Block-LD and P-Block-INT, which comprise route patterns that block the long-distance and international dialing patterns.
The device-level CSS is CSS-SJ, which is CSS type 2. It consists of all the other partitions that permit various calls, including-long distance and international calls.
The resulting CSS includes all the partitions from the line level and the device level. If the same route pattern appears in both the line level and the device level, the partition listed in the line level takes precedence. Hence, in the example shown in Figure 6-9, the IP Phone is blocked from making any long-distance and international calls because these partitions appear before the partitions that allow the long-distance and international calls.
On the IP Phone line level, you can configure three types of call-forward settings: Call Forward Busy (CFB), Call Forward No Answer (CFNA), and Call Forward All (CFA). Table 6-43 indicates that CSS-restricted CSS is applied to all three call forward settings. CSS-restricted allows calls only to internal numbers. Thus, users cannot forward their calls to external PSTN numbers. If your company policy allows you to forward the calls to external PSTN numbers, you can add the partition that allows reaching the external numbers to the CSS-restricted calling search space.
“Enabling the AAR Service Parameter,” later in the is chapter, discusses the CSS-AAR-SEA and CSS-AAR-DAL CSSs.
A route group is analogous to a trunk group in traditional PBX terminology. Each route group is a prioritized list of gateways to which a route pattern sends the call (through a route list). Refer to Figure 6-7 for a visual depiction of this process. A route group directs all calls to the primary device and then uses the subsequent devices when the primary device is unavailable or its resources are exhausted. All devices in a route group have the same characteristics, such as discard and digit manipulation. Table 6-44 provides the details of the route group to be created to accommodate XYZ’s dial plan.
Table 6-44. Route Groups in Cluster 1
Route Group Name | Selection Order | Gateways/Devices (Route Group Members) | Description |
---|---|---|---|
RG-GW-PSTN-SJ | 1 | S1/DS1-0@SJ-CMM1 | PSTN gateway in San Jose |
2 | S1/DS1-1@SJ-CMM1 | ||
3 | S1/DS1-0@SJ-CMM2 | ||
4 | S1/DS1-1@SJ-CMM2 | ||
RG-GW-PBX-SJ | 1 | S1/DS1-2@SJ-CMM1 | PBX gateway in San Jose |
2 | S1/DS1-2@SJ-CMM2 | ||
RG-GW-PSTN-SEA | 1 | S1/DS1-0@R3745-SEA | PSTN gateway in Seattle |
RG-GW-911-DAL | 1 | AALN/S1/SU0/4@R2650-DAL | 911 gateway in Dallas |
2 | AALN/S1/SU0/5@R2650-DAL | ||
RG-GW-PSTN-DAL | 1 | AALN/S1/SU0/6@R2650-DAL | AAR trunks in Dallas |
2 | AALN/S1/SU0/7@R2650-DAL | ||
RG-Gatekeeper | 1 | Gatekeeper | ICTs between cluster 1 and cluster 2 |
To add route groups, from CallManager Administration, choose Route Plan > Route/Hunt > Route Group.
Figure 6-10 graphically depicts the list of route groups defined in Table 6-44.
A route list defines the way that a call is routed. Route lists are configured to point to one or more route groups, which effectively serve the purpose of trunk groups. The route list sends a call to a route group in a configured order of preference, as shown in Figure 6-7. Table 6-45 shows the details of the route lists configured for the U.S. cluster.
Table 6-45. Route Lists in Cluster 1
Route/Hunt List Name | Selection Order | Route Groups | Description |
---|---|---|---|
RL-PSTN-SJ | 1 | RG-GW-PSTN-SJ | All PSTN calls going through San Jose PSTN trunks |
RL-PBX-SJ | 1 | RG-GW-PBX-SJ | All calls to extensions on PBX |
RL-TEHO-SJ | 1 | RG-GW-PSTN-SEA | All PSTN calls originating from San Jose site to PSTN numbers that are within the Seattle local calling area |
2 | RG-GW-PSTN-SJ | ||
RL-PSTN-No911-SEA | 1 | RG-GW-PSTN-SEA | All PSTN calls originating from Seattle site, except 911 and AAR calls |
2 | RG-GW-PSTN-SJ | ||
RL-PSTN-911-AAR-SEA | 1 | RG-GW-PSTN-SEA | 911 and AAR calls originating from Seattle site |
RL-TEHO-SEA | 1 | RG-GW-PSTN-SJ | All PSTN calls originating from Seattle site to PSTN numbers that are within San Jose local calling area |
2 | RG-GW-PSTN-SEA | ||
RL-PSTN-No911-DAL | 1 | RG-GW-PSTN-SJ | All PSTN calls originating from Dallas site, except 911 and AAR calls |
RL-PSTN-911-AAR-DAL | 1 | RG-GW-911-DAL | 911 and AAR calls originating from Dallas site |
RL-ICT-Sydney | 1 | RG-Gatekeeper | ICT calls to Sydney originating from cluster 1 |
2 | RG-GW-PSTN-SJ | ||
RL-ICT-Brisbane | 1 | RG-Gatekeeper | ICT calls to Brisbane originating from cluster 1 |
2 | RG-GW-PSTN-SJ | ||
RL-ICT-Melbourne | 1 | RG-Gatekeeper | ICT calls to Melbourne originating from cluster 1 |
2 | RG-GW-PSTN-SJ |
To add route lists, from CallManager Administration, choose Route Plan > Route/Hunt > Route/Hunt List.
To understand how the route list design is achieved, recall the XYZ call-routing requirements. One of the requirements is that the Seattle site should primarily use the trunks in the local T1 circuit to reach a PSTN destination. When local trunks are busy or unavailable, CallManager should reroute the call via central site trunks in San Jose. Route list RL-PSTN-No911-SEA, listed in Table 6-45, satisfies this requirement. This route list consists of two route groups: RG-GW-PSTN-SEA (priority 1) and RG-GW-PSTN-SJ (priority 2). RG-GW-PSTN-SEA represents PSTN trunks in Seattle, and RG-GW-PSTN-SJ represents PSTN trunks in San Jose.
Another route list, RL-PSTN-911-AAR-SEA for Seattle, routes the emergency calls and AAR calls only. This route list includes only the trunks on the Seattle T1 circuit and does not include the San Jose trunks for the following reasons:
Routing the emergency calls originating from Seattle via the San Jose trunks results in emergency calls reaching the San Jose Public Safety Answering Point (PSAP).
CallManager invokes the AAR feature when there is not enough bandwidth across the WAN link to send the call to San Jose. Hence, there is no point in routing the call via the San Jose trunks for the AAR scenario.
The Seattle site also requires TEHO implementation for calls to San Jose. This means that all PSTN calls originating from the Seattle site to PSTN numbers that are within the San Jose local calling area (refer to Table 6-39) use route list RL-TEHO-SEA, which consists of RG-GWPSTN-SJ (first priority) and RG-GW-PSTN-SEA (second priority). Using this route list, TEHO calls from Seattle use the IP WAN to reach the San Jose site and then use San Jose local PSTN trunks to reach San Jose local calling numbers, falling back to Seattle trunks if no bandwidth is available to place the call across the WAN.
With the TEHO feature, XYZ does not have to pay for long-distance PSTN calls from Seattle to the San Jose local calling area.
The requirements for the Dallas site are to route all the calls via the San Jose trunks only and never use local trunks; therefore, route list RL-PSTN-No911-DAL includes only San Jose trunks. The emergency calls are routed via the local FXO trunks using the route list RL-PSTN-911-AAR-DAL.
Route lists RL-ICT-Sydney, RL-ICT-Melbourne, and RL-ICT-Brisbane route the intercluster calls that are destined to Sydney, Melbourne, and Brisbane (cluster 2) from any site in cluster 1. These route lists consist of two route groups: RG-Gatekeeper and RG-GW-PSTN-SJ. This indicates that calls are routed via the IP WAN after checking the availability of the bandwidth with the gatekeeper as the first preference. If there is not enough bandwidth on the IP WAN, the calls are routed through the PSTN trunks in San Jose as a second preference.
Route patterns primarily serve the following three functions:
Match dialed number for internal/external calls
Perform digit manipulation (optional)
Point to a route list for routing
Refer to Figure 6-7 for a visual representation of route patterns and their order in the hierarchy of call routing.
Before going into the route pattern design for XYZ, the next few sections discuss the important concepts regarding route patterns, such as wildcards, route filters, digit discarding instructions, and digit transformations. Understanding these concepts is important in designing a trouble-free dial plan.
In CallManager, every directory number or phone number is a route pattern. You can use wildcard characters to define the route patterns that match a group of dialed numbers. Table 6-46 shows the list of wildcard characters supported in CallManager, and Table 6-47 shows examples of defining route patterns using wildcard characters.
Table 6-46. Wildcard Characters
Wildcard | Description |
---|---|
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, *,# | Match exactly one digit |
X | Any single digit in the range 0–9 |
[xyz...] | One occurrence of any of the digits in the brackets |
[x-y] | One occurrence of any digit from x to y |
[^x-y] | Any digit that is not between x and y |
! | One or more digits in the range 0–9 |
wildcard? | Zero or more occurrences of the previous wildcard |
wildcard+ | One or more occurrences of the previous wildcard |
@ | Matches the North American Numbering Plan (NANP) |
Table 6-47. Examples of Route Patterns with Wildcard Characters
Route Pattern Definition | Description |
---|---|
2222 | Matches 2222 |
*2*2 | Matches *2*2 |
14xx | Matches numbers between 1400 and 1499 |
15[25-8]6 | Matches 1526, 1556, 1566, 1576, 1586 |
13[^3-9]6 | Matches 1306, 1316, 1326, 13*6, 13#6 |
13!# | Matches any number that begins with 13, is followed by one or more digits, and ends with #, such as 135# and 13579# |
The . and @ are special wildcard characters:
. denotes a portion of a route pattern that can be stripped when the pattern matches.
@ is a macro for many patterns that encompass the NANP or the numbering plan that is installed on the CallManager.
Route filters are applicable only when you are designing the route patterns using the @ macro. CallManager understands NANP by default. This means that CallManager knows all the elements of the NANP dial plan, so you can use the @ wildcard to design the route patterns. The NANP dial plan includes approximately 166 route patterns that are specific to NANP.
To see all the route patterns that are included when using the @ wildcard, refer to the NANP dial plan file located in C:Program FilesCiscoDial PlanNANP on the CallManager server.
If you define a route pattern 9.@ without associating it with a route filter, CallManager checks the dialed number against all the route patterns included in the NANP dial plan file. Table 6-48 shows some route patterns in NANP that match the route pattern 9.@ when defined without a route filter.
Table 6-48. 9.@ Route Pattern Without a Route Filter
No. | Route Pattern | Description |
---|---|---|
1 | 9.[2-9]11 | 311, 611, 911 SERVICEs |
2 | 9.[2-9]XX XXXXXXX | 7-digit dialing by OFFICE CODE |
3 | 9.[2-9]XX [2-9]XXXXXX | 10-digit local dialing by LOCAL AREA CODE |
4 | 9.1[2-9]XX [2-9]XXXXXX | 11-digit long-distance dialing by AREA CODE |
5 | 9.011! | International dialing by COUNTRY CODE |
You can use route filters to select fewer route patterns to match against, rather than matching against all the route patterns defined in the NANP dial plan file. For example, if you intend to define a route pattern that matches the dialed numbers for service calls only, you can define a route pattern 9.@ with a route filter SERVICE EXISTS.
To define route filters, from CallManager Administration, choose Route Plan > Route Filter.
After defining a route filter, you associate it with a route pattern to limit the number of route patterns you need to match against the dialed number.
A digit transformation in CallManager is a process wherein the modifications are made to calling party and called party numbers before handing over the call to the next system. Three types of digit transformations are available:
Calling party transformations
Connected party transformations
Called party transformations
In CallManager, you can do these digit transformations at the following levels:
Route pattern level
Route group level within a route list
The digit transformations that are done at the route group level within a route list override those that are defined at the route pattern level. The best practice is to do the manipulations at the route group level within a route list, to avoid configuration mistakes.
Figure 6-11 shows the digit transformation options available in each type of transformation at a route pattern level.
Figure 6-12 shows the digit transformation options available in each type of transformation at a route group level within a route list.
Transformations that are made to the calling party change the caller ID. The following list explains some of the important settings shown in Figure 6-11:
Use Calling Party’s External Phone Number Mask—. Checking this box tells CallManager to use the value in the External Phone Number Mask field on the IP Phone Directory Number Configuration page, shown in Figure 6-13. On this page, you can also define in the Display (Internal Caller ID) field the name that identifies the user of the phone. The AAR feature (discussed later in this chapter) in CallManager uses the value in the External Phone Number Mask field to route the call via PSTN when a location’s CAC rejects placement of the call over the IP WAN because of lack of bandwidth. If this field is blank or configured with a wrong number, AAR fails.
Calling Party Transform Mask—. Use this field to mask the calling party number before sending out the call. A mask can contain digits 0 to 9, *, X, and #.
Prefix Digits—. The field allows you to prefix digits to the calling number.
To understand when to use the calling party transformations, consider the Dallas sitenumbering plan described in Table 6-38. Dallas does not have a range of valid DID numbers to be assigned to IP Phones. Instead, the Dallas site has a single DID number, 1-972-555-5600. Internally, a four-digit private numbering plan is implemented to assign the directory numbers to IP Phones. The private directory numbering range is 5601 to 5619 (refer to Table 6-40).
When an IP Phone in Dallas with a directory number of 5601 makes an outgoing call to an external PSTN number, CallManager should send the valid DID number (1-972-555-5600) to the PSTN as the calling party number and not 1-972-555-5601.
You can accomplish this in either of two ways:
For all the IP Phones in Dallas, enter 1-972-555-5600 in the External Phone Number Mask field of the Directory Number Configuration page (refer to Figure 6-13) and check the Use Calling Party’s External Phone Number Mask box on the Route Pattern/Hunt Pilot Configuration page (refer to Figure 6-11).
Enter 19725555600 in the Calling Party Transform Mask field at the route group level in the route list (refer to Figure 6-12); the resulting number will match the DID number as shown here:
Caller ID 5601
Calling party transformation mask 197255555600
Resulting number 197255555600
The first option is used for the Dallas site IP Phones, because the AAR feature requires configuration of the external phone number mask. The Seattle and San Jose sites have valid DID numbers, so the External Phone Number Mask field on the IP Phones Directory Number Configuration page for Seattle and San Jose can be set to their actual DID number. At the route group level within the route list, check the option to use the e-Calling Party’s External Phone Number Mask.
In Figure 6-11, the Connected Party Transformations section allows you to choose whether you want Cisco CallManager to allow or restrict the display of the connected party’s phone number on the calling party’s phone display for this route pattern.
Under the Called Party Transformations sections in Figure 6-11 or 6-12, the Called Party Transform Mask and Prefix Digits fields serve the same function as the corresponding fields discussed for the Calling Party Transformations section. The additional field shown in Figure 6-12, Discard Digits, is discussed next.
CallManager uses the value chosen in the Discard Digits field of Figure 6-11 or Figure 6-12 to modify the digits in the called number before routing the call to the next system.
CallManager provides you with many digit discarding instructions (DDIs). The DDIs, with the exception of NoDigits and PreDot, work only with route patterns that are defined using the @ wildcard, placed in the NANP dial plan or any other installed international dial plan combined with route filters.
To understand the importance of the DDIs, consider Table 6-49. The number before . in each route pattern defines the access code. In North America, the access code 9 is used; in some other countries, 0 is used. You can define any access code you like. You simply need to configure the route patterns accordingly.
Table 6-49. Route Patterns in Cluster 1
Route Pattern | Partition | Route List | Description |
---|---|---|---|
2[5-9]XX | P-Internal | RL-PBX-SJ | PBX calls in San Jose |
6XXX | P-Internal | RL-ICT-Sydney | On-Network to Sydney Apply called party transformation mask of 910116125555XXXX at the RG-GW-PSTN-SJ level |
43XX | P-Internal | RL-ICT-Melbourne | On-Network to Melbourne Apply called party transformation mask of 91011613555543XX at the RG-GW-PSTN-SJ level |
86[89]X | P-Internal | RL-ICT-Brisbane | On-Network to Brisbane Apply called party transformation mask of 9101161255558681 at the RG-GW-PSTN-SJ level |
9.911 | P-Emergency-SJ | RL-PSTN-SJ | 911 calls for San Jose users |
9.911 | P-Emergency-SEA | RL-PSTN-911-AAR-SEA | 911 calls for Seattle users |
9.911 | P-Emergency-DAL | RL-PSTN-911-AAR-DAL | 911 calls for Dallas users |
9.[2-9]XXXXXX | P-Local-SJ | RL-PSTN-SJ | Local calling in San Jose |
9.1425[2-9]XXXXXX 9.1253[2-9]XXXXXX | P-Local-SJ | RL-TEHO-SJ | Local calling in Seattle |
9.[2-9]XXXXXX | P-Local-SEA | RL-PSTN-No911-SEA | Local calling in Seattle; prepend 1 at the RG-GW-PSTN-SJ |
9.1408[2-9]xxxxxx 9.1510[2-9]xxxxxx 9.1650[2-9]xxxxxx 9.1925[2-9]xxxxxx | P-Local-SEA | RL-TEHO-SEA | Local calling within San Jose |
9.[2-9]XXXXXX | P-Local-DAL | RL-PSTN-No911-DAL | Local calling in Dallas; prepend 1 plus the area code 972 at the RG-GW-PSTN-SJ |
9.1[2-9]XX[2-9]XXXXXX | P-LD-SJ | RL-PSTN-SJ | LD calls for San Jose |
9.1800[2-9]XXXXXX 9.1866[2-9]XXXXXX 9.1877[2-9]XXXXXX 9.1888[2-9]XXXXXX | P-TollFree-SJ | RL-PSTN-SJ | Toll-free calls for San Jose and Dallas |
9.1800[2-9]XXXXXX 9.1866[2-9]XXXXXX 9.1877[2-9]XXXXXX 9.1888[2-9]XXXXXX | P-TollFree-SEA | RL-PSTN-No911-SEA | Toll-free calls for Seattle |
9.1[2-9]XX[2-9]XXXXXX | P-LD-SEA | RL-PSTN-No911-SEA | Long-distance calls for Seattle |
9.1[2-9]XX[2-9]XXXXXX | P-LD-DAL | RL-PSTN-No911-DAL | Long-distance calls for Dallas |
9.1[2-9]XX[2-9]XXXXXX | P-LD-AAR-SEA | RL-PSTN-911-AAR-SEA | Long-distance AAR for Seattle |
9.1[2-9]XX[2-9]XXXXXX | P-LD-AAR-DAL | RL-PSTN-911-AAR-DAL | Long-distance AAR for Dallas |
9.011! | P-INT-SJ | RL-PSTN-SJ | International calls for San Jose |
9.011!# | P-INT-SJ | RL-PSTN-SJ | International calls for San Jose |
9.011! | P-INT-SEA | RL-PSTN-No911-SEA | International calls for Seattle |
9.011!# | P-INT-SEA | RL-PSTN-No911-SEA | International calls for Seattle |
9.011! | P-INT-DAL | RL-PSTN-No911-DAL | International calls for Dallas |
9.011!# | P-INT-DAL | RL-PSTN-No911-DAL | International calls for Dallas |
9.011! | P-INT-AAR-SEA | RL-PSTN-911-AAR-SEA | International AAR calls for Seattle |
9.011! | P-INT-AAR-DAL | RL-PSTN-911-AAR-DAL | International AAR calls for Dallas |
Typically, route patterns that have access codes point to external numbers. If the access code is not part of the actual dialed number, you have to discard it before sending out to the PSTN. You can select the appropriate DDIs listed in the Digit Discards option under the Called Party Transformations section shown in Figure 6-11 or Figure 6-12 to achieve this.
With XYZ, the DDI that is selected for the route patterns that begin with 9. is PreDot. This discards 9 and sends the remaining number to the gateway that is specified in the route list. Digit 9 is the access code used to make the external calls.
As mentioned earlier in this section, one reason for not recommending the use of digit manipulation at the route pattern level is that if you dial a number (for example, 91408...) and the Discard Digits option is set to PreDot, the number that is stored in the Placed Calls list in the IP Phone is the number after 9 is stripped. If you want to redial the number on the same IP Phone, the 9 will not be included and the redial operation will fail to complete the call. This is why you should do the digit manipulation at the route group level within a route list instead of at the route pattern level.
When designing a dial plan in CallManager, you can either use explicit route patterns or use the @ macro with route filters. In designing the route patterns for XYZ, the explicit route patterns are defined instead of using the @ macro with route filters, because the dial plan is easy to read and follow.
To implement the call-routing requirements and restrictions of XYZ described previously, you can use the route patterns defined in Tables 6-49 and 6-50 in the U.S. cluster.
Table 6-50. Blocked Route Patterns in Cluster 1
Route Pattern | Partition |
---|---|
9.[2-9]XXXXXX | P-Block-Local |
9.1[2-9]XX[2-9]XXXXXX | P-Block-LD |
9.011! | P-Block-INT |
9.011!# | P-Block-INT |
To add route patterns, from CallManager Administration, choose Route Plan > Route Pattern/Hunt Pilot.
Set the Urgent Priority flag to all the 9.911 route patterns. When this flag is set, CallManager routes the call immediately after the user dials 9911 even if there is another potential match in the digit analysis table.
Figure 6-14 shows the complete dial plan, including route patterns, route lists, and route groups for the San Jose site. CallManager matches against a list of the route patterns based on the dialed number. For an IP Phone to match a route pattern, the partition of that route pattern should be included in the phone’s CSS. Route patterns point to route lists, which point to route groups. Based on the route pattern, CallManager selects a route list and routes the call via the gateways that are specified in the route group based on the priority order.
Figures 6-15 and 6-16 show the complete dial plan, including route patterns, route lists, and route groups, for the Seattle site and Dallas site, respectively.
Figure 6-17 shows the dial plan to route the calls from the San Jose cluster to the Australia cluster. CallManager selects a different route list based on the dialed number. San Jose users dial four digits to reach the IP Phone users in the Australian cluster. No digit manipulations are necessary if the call goes through the IP WAN. However, to route the call via PSTN, you have to send the full E.164 number based on the phone location within Australia. You can accomplish this by applying the called party transformation mask specific to the site on the RG-GW-PSTN-SJ route group within each route list. For example, in Figure 6-17, 910116125555XXXX is applied on the RG-GW-PSTN-SJ route group within the route list RL-ICT-Sydney to route the call via PSTN. Because the IP Phone numbers at the Brisbane site are non-DID numbers, the mask 9101161255558681 is used. This routes the call to the operator number in Brisbane.
Figure 6-18 shows the call flow for a TEHO call originating in Seattle and going to a PSTN user in San Jose.
Table 6-50 shows the blocked route patterns for cluster 1. (The partition names are from Table 6-41.)
Intercluster trunks connect two or more CallManager clusters. These are virtual trunks. Typically, a WAN connection exists between clusters that are distributed across multiple locations. To control the number of calls across the ICT via the IP WAN, you can use a gatekeeper. Cisco CallManager uses the H.323 protocol to communicate with the gatekeeper.
For XYZ, one cluster is located in San Jose and the other is in Australia. Deploying a gatekeeper to perform CAC in a CallManager environment requires the following steps:
Select the gatekeeper hardware platform and deployment mode.
Configure the gatekeeper in the CallManager.
Configure the trunk in the CallManager.
Configure the gatekeeper.
Using a gatekeeper in the intercluster communications provides the following advantages:
Increased scalability, by reducing the number of ICTs required to communicate between clusters
Ease of management, enabling quick addition and removal of routes and devices
CAC between calls from different clusters, ensuring that the WAN bandwidth allocation is strictly enforced
Reduced configuration overhead, by eliminating the need to configure a separate H.323 device for each remote Cisco CallManager that is connected to the IP WAN
Ability to perform basic call routing in addition to CAC
The gatekeeper is a software feature in Cisco IOS software and runs on most of the routers. The selection of the hardware platform depends on the following factors:
Number of calls per second (CPS) that the gatekeeper needs to process.
Gatekeeper deployment model deploys a gatekeeper in clustering mode that reduces the performance hit and provides load sharing and redundancy in the network.
In Cisco CallManager 3.3 and above, to configure the gatekeeper, the first step is to define the gatekeeper. To define a gatekeeper, from the CallManager Administration page, choose Device >Gatekeeper. Table 6-51 shows the configuration parameters that you need to enter when defining the gatekeeper in CallManager.
After you configure the gatekeeper information, the next step is to define the trunk. From the CallManager Administration page, choose Device > Trunk and click the Add New Trunk option. Choose the Trunk Type as Inter-Cluster Trunk (Gatekeeper Controlled) and the Device Protocol as Inter-Cluster Trunk.
Table 6-52 shows the configuration parameters that you need to enter when defining the gatekeeper trunk in CallManager.
Table 6-52. Gatekeeper Trunk Configuration Parameters
Parameter | Value |
---|---|
Device Information | |
Device Name | AS_GKTrunk |
Description | Gatekeeper Trunk |
Device Pool | DP-SanJose |
MRGL | MRGL_SJ |
Location | San Jose |
AAR Group | None |
MTP Required | Unchecked |
Retry Video Call as Audio | Unchecked |
Call Routing Information—Inbound | |
Significant Digits | All |
Calling Search Space | Css-gateways |
AAR Calling Search Space | |
Prefix DN | |
Redirecting Number IE-Delivery—Inbound | Checked |
Gatekeeper Information | |
Gatekeeper Name | Name Configured in Table 6-49 |
Terminal Type | Gateway |
Technology Prefix | 1# |
Zone | Cluster 1 |
Example 6-2 shows the gatekeeper configuration at the San Jose site in cluster 1 according to the XYZ requirements. The configuration at the San Jose gatekeeper is simple, and similar configuration guidelines will be followed for the Sydney gatekeeper.
Example 6-2. San Jose Gatekeeper Configuration
Gatekeeper ! Split the GK into multiple local zones ! Define one zone for the U.S. cluster zone local Cluster1 xyz.com 10.1.19.1 ! Define one zone for the Australia cluster zone local Cluster2 xyz.com ! To prevent any other device than the U.S. CallManagers from registering zone subnet Cluster1 10.1.1.5/27 enable zone subnet Cluster1 10.1.1.6/27 enable zone subnet Cluster1 10.1.1.36/27 enable no zone subnet Cluster1 0.0.0.0/0 enable ! To prevent any other device than the Australia CallManagers from registering zone subnet Cluster2 10.4.1.5/27 enable zone subnet Cluster2 10.4.1.36/27 enable no zone subnet Cluster2 0.0.0.0/0 enable ! Define the prefixes for the U.S. zone zone prefix Cluster1 3... zone prefix Cluster1 4... zone prefix Cluster1 21.. zone prefix Cluster1 560. zone prefix Cluster1 561. ! Define the prefixes for the Australian zone zone prefix Cluster2 6... zone prefix Cluster2 43.. zone prefix Cluster2 868. zone prefix Cluster2 869. ! Maximum of 20 G.729 interclusters calls. ! We need to provision 16k for each call. bandwidth interzone Cluster1 320 bandwidth interzone Cluster2 320 ! Defines the default technology prefix that is necessary for routing decisions gw-type-prefix 1#* default-technology arq reject-unknown-prefix no shutdown
The incoming calls for the San Jose and Seattle sites come in via the PRI trunks. The PSTN trunks in San Jose terminate on T1 PRI ports on the CMM modules, and in Seattle they terminate on the T1 PRI port on the Cisco 3725 router. All the voice gateways are configured to use MGCP. The voice gateways receive all the digits from the PSTN. You need to set the Significant Digits field on the Gateway Configuration page for the San Jose and Seattle gateways to 4. This setting instructs the CallManager to use only the last four digits to route calls. Because the San Jose and Seattle sites have DID numbers, using the last four digits, CallManager extends the call to the IP Phone or to the CTI route point. We do not need to set this field on the PRI trunks that are connected to the San Jose PBX. The PBX is configured to forward four digits for the IPT network.
Another setting that is important to discuss is the CSS. To successfully route the call from the gateway to an IP Phone or to a CTI route point, the CSS on the gateway should include the partitions that contain IP Phones and CTI route points. Hence, set the CSS field on the gateway to CSS-Gateways (refer to Table 6-43).
When configuring the gateway for the Dallas site, where the numbers are non-DID numbers, you should set the Attendant Directory Number field on the Gateway Configuration page for the Dallas gateway to match the directory number of a local IP Phone in Dallas. Typically, it will be the IP Phone of the person who is fulfilling the role of the operator.
AAR is a mechanism that allows the call path for an intracluster call to be reestablished through the PSTN when the location-based CAC denies the call because of insufficient bandwidth. Remember that AAR is an intracluster feature. This means that AAR does not work between two CallManager clusters.
Configuring AAR involves the following steps:
Enable the AAR service parameter.
Define the external phone number mask.
Configure AAR groups and assign IP Phone directory numbers and gateways to the AAR groups.
Define AAR CSSs and assign them to IP Phone devices and gateways.
The first step in configuring AAR is to enable AAR on the CallManager. To enable AAR from the CallManager Administration page, choose System > Enterprise Parameters and set the Automated Alternate Routing parameter to True.
Figure 6-19 shows the AAR call-rerouting process. A Seattle user makes a call to a Dallas user by dialing four digits. However, because the bandwidth is not available, CallManager CAC denies access to route the call via the IP WAN. CallManager invokes the AAR mechanism to route the call via PSTN to reach the Dallas user.
Based on the implementation shown in Figure 6-19, you might wonder how CallManager knows what is the full E.164 number to dial to reach the Seattle user. The answer is that CallManager refers to the External Phone Number Mask field on the IP Phone Directory Number Configuration page. Configuring this field is mandatory for AAR to work. Table 6-53 shows the external phone number masks for each location for XYZ. Note that for the Dallas and Brisbane locations, the external phone number mask is configured to match the single DID number for those locations. All other locations of XYZ have valid DID number ranges for IP Phones.
Another question that you might have based on the implementation shown in Figure 6-19 is how CallManager knows what access code to dial to reach the destination via PSTN. The answer to this question is AAR groups. AAR groups specify the access code plus any long-distance code that needs to be added to the external phone number mask before making the call to the PSTN.
To configure AAR groups, from CallManager Administration, choose Route Plan > AAR Group. You need to define one AAR group (for example, AAR group name as AAR_cluster1) in cluster 1 so that CallManager prepends 91 to the external phone number mask before placing an AAR call. 9 is the PSTN access code and 1 is the prefix for the long-distance call.
In cluster 2, configure a single AAR group (for example, AAR group name as AAR_cluster2) such that CallManager prepends 0 when calling any location within Australia, where 0 is the access code used to reach the PSTN numbers.
After defining the AAR groups, you need to assign them to the directory numbers on each IP Phone. All directory numbers in cluster 1 will have AAR_cluster1 as their AAR group, and all directory numbers in cluster 2 will have AAR_cluster2 as their AAR group. The AAR groups in both clusters are simple because the length of telephone numbers across the country is the same. You might end up with multiple AAR groups if your sites use variable-length area codes.
The final step in configuring the AAR is to define a separate AAR CSS and assign it at the device level for gateways and for the IP Phones. The AAR CSS is used when placing the call through the PSTN. The AAR CSS was already defined in Table 6-43. The dial plan route patterns (refer to Table 6-49) and route lists (refer to Table 6-45) have been designed to accommodate AAR. The dial plan is designed to utilize the local gateway under AAR.
Survivable Remote Site Telephony (SRST) provides the CallManager with fallback support for the Cisco IP Phones that are attached to routers on the local Ethernet. SRST enables the routers to provide call-handling support for the IP Phones when the IP Phones lose connection to the remote primary, secondary, or tertiary CallManager or when the WAN connection is down. SRST will be deployed for every remote site in the XYZ network in cluster 1 and cluster 2 to support the IP Phones in the remote sites in case of a WAN failure.
Under SRST mode, the IP Phone users cannot use four digits to dial the other IP Phones at a different site. For example, during the failure of a WAN link between the San Jose and Seattle sites, a user in Seattle who is calling another user in San Jose with four digits hears a reorder tone. In this case, the user in Seattle must dial the full telephone number to reach the user in San Jose or any other user in any site. However, you can overcome this limitation by placing translation rules in the SRST router, as shown in the next section in Example 6-3.
If the WAN link is available but no bandwidth is available on the WAN link to route a call across the WAN, CallManager uses AAR to automatically route the call via the PSTN. This process is transparent to the user. The important point to note is that AAR kicks in only if the CallManager is unable to route the call because of CAC and the unavailability of bandwidth. It does not kick in if the WAN link fails.
Under SRST mode, all inbound calls from the PSTN to the remote sites are routed to the end stations if they have a valid DID number. The H.323 session on the remote-site routers handles the call routing under the SRST mode. Also in the SRST mode, users can access the voice-mail messages via the PSTN; however, the MWI will not work. As a workaround, users will have to call the voice-mail server to check for messages. When users press the Messages button on the IP Phone, the gateway automatically dials the voice-mail system via the PSTN. Example 6-3, discussed in the next section, shows the commands to achieve this.
In the Dallas and Brisbane sites, which have FXO trunks that are non-DID trunks, inbound calls are routed to the operator. The Dallas and Brisbane sites have only four analog connections on the routers. Under SRST mode, call routing from these sites is limited as follows:
Only two ports are allowed to route the outbound calls.
One port is always reserved for routing emergency calls.
One port can dial local, long-distance, or international calls.
Example 6-3 shows the CLI configuration for the Seattle router to support SRST. Besides the E1 PRI configuration for the Melbourne router, the rest of the Melbourne SRST configuration is identical to that of the Seattle router.
Example 6-3. Seattle Router SRST Configuration
hostname R3745-SEA ! ! ! Translation rule that converts the user extensions in San Jose ! and Dallas to a full E.164 number. voice translation-rule 1 ! Rule 1 converts any number beginning with 5 to the ! Dallas site DID number 17325555611 rule 1 /^5(...)/ /17325555611/ ! Rules 2 and 3 convert the 4-digit number beginning with 3 or 4 to a full E.164 ! number to match the DID numbers in the San Jose site. rule 2 /^4(...)/ /140855541/ rule 3 /^3(...)/ /140855531/ voice-card 1 dspfarm dsp services dspfarm ! Define the translation profile and attach Rule 1 voice translation-profile 4Digits2E164 translate called 1 ! Enables the DHCP on the router ip dhcp isdn switch-type primary-ni ip dhcp excluded-address 10.2.1.1 10.2.1.5 ! Router acts as DHCP server for IP Phones in Seattle ip dhcp pool Seattle-IPPhones network 10.2.1.0 255.255.255.0 default-router 10.2.1.1 option 150 ip 10.1.1.7 ! ccm-manager fallback-mgcp ! CallManager backup call agent in cluster 1 ccm-manager redundant-host 10.1.1.6 ccm-manager mgcp ccm-manager music-on-hold ! controller T1 1/0 framing esf linecode b8zs pri-group timeslots 1-24 service mgcp ! interface Loopback0 ip address 10.2.11.5 255.255.255.0 ! interface FastEthernet0/0 no ip address duplex auto speed auto ! interface VLAN 21 description voice subnet ip address 10.2.1.1 255.255.255.0 ! interface VLAN 211 description data subnet ip address 10.2.11.1 255.255.255.0 ! interface Serial1/0:23 no ip address no logging event link-status isdn switch-type primary-ni isdn incoming-voice voice ! Backhaul the D channel to the CallManager isdn bind-l3 ccm-manager no cdp enable ! call application alternate DEFAULT ! Use H.323 under FallBack mode ! voice-port 1/0:23 ! voice-port 2/0/0 description FAX MACHINE 2065552151 ! voice-port 2/0/1 description FAX MACHINE 2065552152 ! mgcp ! Define the primary call agent mgcp call-agent 10.1.1.6 service-type mgcp version 0.1 mgcp dtmf-relay voip codec all mode out-of-band mgcp rtp unreachable timeout 1000 action notify mgcp package-capability rtp-package mgcp package-capability sst-package no mgcp timer receive-rtcp mgcp sdp simple mgcp fax t38 inhibit no mgcp explicit hookstate ! Define the interface from where the signaling and ! audio packet will be sourced. mgcp bind control source-interface Loopback0 mgcp bind media source-interface Loopback0 mgcp rtp payload-type g726r16 static ! mgcp profile default ! ! Define local conferencing resources in Seattle sccp local Loopback0 sccp sccp ccm 10.1.1.6 priority 1 sccp ccm 10.1.1.36 priority 2 ! sccp switchback timeout guard 180 dspfarm confbridge maximum sessions 6 dspfarm ! dial-peer voice 1 pots ! Port MGCP controlled when CallManager is up and running or WAN is available application mgcpapp incoming called-number direct-inward-dial port 1/0:23 ! dial-peer voice 911 pots ! Explicit dial-peer for 911 under SRST mode destination-pattern 911 port 1/0:23 forward-digits all ! dial-peer voice 100 pots ! Explicit dial-peer for local calling under SRST mode destination-pattern 9[2-9]...... port 1/0:23 forward-digits 7 ! dial-peer voice 101 pots ! Explicit dial-peer for long distance calling under SRST mode destination-pattern 91[2-9]..[2-9]...... port 1/0:23 forward-digits 11 ! dial-peer voice 102 pots ! Explicit dial-peer for international calling under SRST ! mode destination-pattern 9011.T destination-pattern 9011.T port 1/0:23 prefix 011 ! dial-peer voice 20 pots application mgcpapp ! Fax machine1 destination-pattern 2151 port 2/0/0 ! dial-peer voice 21 pots application mgcpapp ! Fax machine2 destination-pattern 2152 port 2/0/1 ! This dial peer matches the 4-digit extension numbers for the ! San Jose and Dallas sites, Invokes the translation profile ! to translate the called numbers to valid DID numbers dial-peer voice 200 pots translation-profile outgoing 4Digits2E164 destination-pattern [3-5]... port 1/0:23 call-manager-fallback ip source-address 10.2.11.5 port 2000 max-ephones 48 max-dn 96 ! Provide secondary dial tone to IP Phone users when ! users dial 9 in SRST mode secondary-dialtone 9 ! For inbound calls, use the last 4 digits and then route the call. dialplan-pattern 1 206555.... extension-length 4 ! To access the OCTEL voice mail system in San Jose when users ! press Messages button on the Cisco IP Phone voicemail 914085553555 ! The following two commands forward the calls to a voice-mail system ! if the Cisco IP Phone user extension is busy or the call is not answered. call-forward busy 914085553555 call-forward noan 914085553555 timeout 10 ! Provide MoH to Seattle phones. Use the audio file from the local router flash moh music.au multicast moh 239.1.1.1 port 16384 route 10.2.11.1 10.2.1.1
Example 6-4 shows the CLI configuration for the Dallas router to support SRST. The Brisbane router SRST configuration will be identical to that of the Dallas router SRST configuration.
In Example 6-4, two POTS dial peers, 200 and 201, are matched when Dallas IP Phone users dial 4-digit numbers during the SRST mode to reach the San Jose and Seattle site users. The called numbers are modified by prefixing the right digits to make the called number a valid E.164 number. The same result is accomplished in Example 6-3 by using the translation rules.
Example 6-4. Dallas Router SRST Configuration
hostname R2600-DAL ! ccm-manager fallback-mgcp ! CallManager backup call agent in cluster 1 ccm-manager redundant-host 10.1.1.6 ccm-manager mgcp ccm-manager music-on-hold ! interface Loopback0 ip address 10.1.64.1 255.255.255.0 ! interface FastEthernet0/0 no ip address duplex auto speed auto ! interface FastEthernet0/0.65 description voice subnet encapsulation dot1Q 65 ip address 10.1.65.1 255.255.255.0 ! interface FastEthernet0/0.66 description data subnet encapsulation dot1Q 66 native ip address 10.1.66.1 255.255.255.0 ! call application alternate DEFAULT ! Fallback to H.323 when MGCP is down. ! voice-port 1/0/0 ! Fax Machine voice-port 1/0/1 ! voice-port 1/0/2 ! voice-port 1/0/3 ! voice-port 1/0/4 ! Outbound 911 only. No inbound ! voice-port 1/0/5 ! FXO outbound 911 calling under SRST and inbound fax connection plar opx 5611 ! voice-port 1/0/6 ! FXO outbound and inbound PSTN. ! Inbound calls routed to the operator in the site. connection plax opx 5601 ! voice-port 1/0/7 ! FXO outbound and inbound PSTN. ! Inbound calls routed to the operator in the site. connection plax opx 5601 ! mgcp mgcp call-agent 10.1.1.6 service-type mgcp version 0.1 mgcp dtmf-relay voip codec all mode out-of-band mgcp rtp unreachable timeout 1000 action notify mgcp package-capability rtp-package mgcp package-capability sst-package no mgcp timer receive-rtcp mgcp sdp simple mgcp fax t38 inhibit no mgcp explicit hookstate mgcp bind control source-interface Loopback0 mgcp bind media source-interface Loopback0 mgcp rtp payload-type g726r16 static ! mgcp profile default ! ! This dial peer is used to match the 4-digit numbers dialed by ! Dallas IP Phone users in the SRST mode. The called number is ! prefixed with 1408555 to make it a valid E.164 number and route the call. dial-peer voice 200 pots destination-pattern [3-4]... port 1/0:23 forward-digits all prefix 1408555 ! This dial peer is used for the same reason as above dial peer ! but to match the 4-digit extensions for Seattle users. dial-peer voice 201 pots destination-pattern 2... port 1/0:23 forward-digits all prefix 1206555 dial-peer voice 9111 pots ! Explicit dial peer for outbound 911. Dedicated port for 911 and inbound fax application mgcpapp destination-pattern 911 port 1/0/4 forward-digits all ! dial-peer voice 9111 pots ! Explicit dial peer for outbound 911. Dedicated port for 911 and inbound fax application mgcpapp destination-pattern 911 port 1/0/5 forward-digits all ! dial-peer voice 1001 pots ! Explicit dial peer for local calling. First port application mgcpapp destination-pattern 9[2-9]...... port 1/0/6 forward-digits 7 ! dial-peer voice 1002 pots ! Explicit dial peer for local calling. Second port application mgcpapp destination-pattern 9[2-9]...... port 1/0/7 forward-digits 7 ! dial-peer voice 1011 pots ! Explicit dial peer for LD calling. First port destination-pattern 91[2-9]..[2-9]...... port 1/0/6 forward-digits 11 ! dial-peer voice 1012 pots ! Explicit dial peer for LD calling. Second port destination-pattern 91[2-9]..[2-9]...... port 1/0/7 forward-digits 11 ! dial-peer voice 1021 pots ! Explicit dial peer for international calling. First port destination-pattern 9011.T port 1/0/6 prefix 011 ! dial-peer voice 1022 pots ! Explicit dial peer for international calling. Second port destination-pattern 9011.T port 1/0/7 prefix 011 ! dial-peer voice 100 pots ! Fax machine application mgcpapp destination-pattern 5611 port 1/0/0 ! call-manager-fallback ip source-address 10.1.65.1 port 2000 max-ephones 12 max-dn 24 voicemail 914085553555 ! The following two commands forward the calls to the ! voice-mail system if the Cisco IP Phone ! user extension is busy or the call is not answered. call-forward busy 914085553555 call-forward noan 914085553555 timeout 10
Two mechanisms are available to deploy fax and modem services over an IP network: fax and modem relay and fax and modem pass-through. The support varies from one Cisco platform to another and is highly dependent on the underlying voice-signaling protocol, whether it is SCCP, MGCP, or H.323.
Fax and modem pass-through capabilities are supported in all the gateways deployed in the XYZ network. Also with this model, pass-through V.34 modem speed can be guaranteed. Refer to the following URL for more details on fax support on various voice gateways:
While using fax and modem pass-through, you have to force the codec to be G.711. XYZ will not be able to use the up-speed feature of the pass-through mode because the CAC mechanism that is currently available in CallManager cannot dynamically adjust the bandwidth that is deducted. All fax and modem endpoints will belong to the device pool DP-MOH-FAX (refer to Table 6-20). That will force the call to be negotiated as a G.711 call from the start of the call and deduct the right amount of G.711 bandwidth from the CAC mechanism.
Implementing fax up-speed allows the use of high-compression codecs (such as G.729) for voice calls. However, when certain fax tones are detected, the codec is “up-speeded” or changed to G.711.
With XYZ, at the central sites in San Jose and Sydney, the incoming fax call from the PSTN comes from the WS-X6608-T1 and WS-X6608-E1 gateways. The fax machines are connected to the VG248 gateways. At the remote sites, the incoming fax calls arrive on the MGCP gateways.
Example 6-5 shows the configuration required for the MGCP Cisco IOS voice gateway to support the fax and modem pass-through features. This configuration is required on all the remote-site gateways.
Example 6-5. Cisco IOS MGCP Gateway Configuration for Fax and Modem Pass-Through Features
Mgcp ! Enables MGCP support on the gateway mgcp call-agent 10.1.2.1 service-type mgcp version 0.1 ! Point the MGCP daemon on the gateway to a call control agent i.e. CallManager no ccm-manager fax protocol cisco mgcp modem passthrough voip mode nse ! Enables peer-to-peer RTP NSE (Named Signaling Events) to coordinate ! the following between the originating and terminating gateways: ! codec switchover and the disabling of ! the echo canceller and voice activity detection (VAD). mgcp modem passthrough voip codec g711ulaw no mgcp timer receive-rtcp mgcp sdp simple mgcp fax t38 inhibit ! This is used to disable MGCP support for T.38 fax. ! By default, T.38 is enabled. ! mgcp profile default ccm-manager fallback-mgcp ccm-manager mgcp ! This command is required for the CallManager ! to be able to control the gateway. ! dial-peer voice 100 pots ! Fax machine application mgcpapp ! This voice port is controlled by CallManager via MGCP destination-pattern 5611 port 1/0/0
After you configure the fax settings on the MGCP gateway for fax pass-through, you can verify the settings by using the show mgcp command on the voice gateway, as shown in Example 6-6.
Example 6-6. Verifying the Fax Pass-Through Configurations on the Cisco IOS MGCP Gateways
#Show mgcp MGCP voip modem passthrough mode: NSE, codec: g711ulaw, redundancy: DISABLED, MGCP voaal2 modem passthrough disabled MGCP voip modem relay: Disabled. MGCP T.38 Fax is DISABLED MGCP T.38 Fax ECM is DISABLED MGCP T.38 Fax NSF Override is DISABLED MGCP T.38 Fax Low Speed Redundancy: 0MGCP T.38 Fax High Speed Redundancy: 0 MGCP Upspeed payload type for G711ulaw: 0, G711alaw: 8
Figure 6-20 shows the configuration of the Catalyst WS-X6608 gateway, which is a non-IOS-based MGCP gateway to enable fax pass-through. The same configuration settings are required even with the 6624 FXS card.
Figure 6-21 shows the configuration of VG248, which is an SCCP-based gateway to enable fax pass-through. When configuring the VG248 for fax, observe the following:
If Cisco fax relay is enabled on the VG248 and the far-end gateway supports only fax passthrough, the VG248 can negotiate fax pass-through.
Disable call waiting on the port that is enabled for fax.
The VG248 has a legacy mode setting for fax pass-through so that it is backward compatible with old devices. If the other end gateway is a Cisco IOS router, change the pass-through signaling parameter to IOS Mode (refer to Figure 6-21). Maintain the passthrough signaling as IOS Mode throughout the network on all non–IOS gateway configurations—that is, VG248, 6608, and 6624 if all the other voice gateways in your network are based on Cisco IOS.
XYZ will be taking different security measures at every layer and at every different component of the network, as shown in Figure 6-22. With the layered approach, if the security is compromised, the problem is contained at one level.
The next few sections examine the following components of the network and security measures that you can implement in the IPT network:
Securing CallManager and application servers
Using a firewall and access control lists (ACLs)
Securing the IPT network from the outside world
Securing IPT endpoints
Securing campus network devices
Securing voice gateways
Establishing physical security
Installing host-based intrusion detection
You can secure the CallManager operating system by disabling the Windows services that are not used, disabling Internet Information Services (IIS) on subscribers, and so forth. Beginning with CallManager OS upgrade release 2.6, an optional security script, CCM-OS-OptionalSecurity.cmd, is provided in the C:UtilsSecurityTemplates directory on the CallManager servers. When this script is executed, it runs predefined commands to perform all of these tasks automatically to secure the OS. You should read the instructions from the file CCM-OS-OptionalSecurity-Readme.htm, located in the same directory, before you run the security script.
You should also install the operating system updates on CallManager, Unity, and other application servers regularly. Refer to the “Software Upgrades” section in Chapter 9 for more information on operating system upgrade procedures and best practices.
Antivirus software is not bundled with the CallManager software. Third-party virus-scanning products such as McAfee or Norton AntiVirus are currently supported, and Cisco recommends that you install one of these antivirus products on CallManager and other application servers and schedule them to run during nonpeak hours.
You should also place the CallManager servers, IP Phones, voice gateways, and application servers on different subnets. In addition, when you are deploying a CallManager cluster, you should consider separating the members of the CallManager cluster into different VLANs and thus into different IP subnets. That way, even if a virus attack or DoS attack occurs in one subnet, affecting the functioning of servers in that subnet, the servers in the other subnet are not affected, and you will not experience a major network outage.
Use of a firewall and ACLs in front of the CallManager cluster and other IPT application servers adds an extra layer of security. For instance, you can configure the ACLs to allow only known traffic to reach the servers in the CallManager cluster and block the rest of the traffic from reaching the servers. Refer to the following URL on Cisco.com to obtain a list of TCP and UDP ports used by the CallManager. This list helps you to build the required ACLs.
The list of TCP and UDP ports used by the Cisco Unity server is available from the following URL:
When you place a firewall in front of your voice network, make sure that it supports stateful inspection of the voice-signaling protocol. Voice can run on any UDP port that ranges between 16384 and 32767, and you need to make sure the firewall opens only the ports needed to support that particular application. Make sure that the firewall you are using supports Application Layer Gateway (ALG) capabilities. ALG inspects signaling packets to discover what UDP port the RTP stream is going to use and dynamically opens a pinhole for that UDP port.
While using private addressing (RFC 1918) for your IP Phones (recommended), do not use Network Address Translation (NAT) to translate these private addresses. When you are deploying IP Phone eXtensible Markup Language (XML) applications, you should use proxy servers to reach the Internet to provide the content rather than allow your CallManager servers to reach the Internet directly.
As an example, consider the stock quote application that gets stock quotes from the Internet. In this example, the application server is running on a separate server and you have an XML application running on an IP Phone. When you use your IP Phone to select the ticker symbol CSCO within the stock quote application to get the stock quote update, that request does not go directly to the Internet. Instead, the request goes to the application server, which gets the information for you by using a proxy server. Hence, the IP Phones do not need to reach the Internet directly.
In the Cisco IPT solution, endpoints are Cisco IP Phones, voice gateways, media resource devices, and so forth. In addition to protecting the critical servers, you should take necessary steps to secure these endpoints. You should completely isolate the data and voice networks by using separate voice and data VLANs. Using this type of separation increases the security of your voice network.
Several security features are available to protect the IP Phones. You can configure all of these features in the CallManager Administration page for each Cisco IP Phone device, shown in Figure 6-23, by setting the following fields to Disabled:
Gratuitous ARP—. By default, Cisco IP Phones accept Gratuitous Address Resolution Protocol (GARP) packets. Some devices use GARP to announce their presence on the network. However, attackers can also use GARP to spoof a valid network device. For instance, an attacker could send out a GARP message claiming to be the default router. Setting this field to Disabled makes Cisco IP Phones ignore the GARP packets.
PC Voice VLAN Access—. By default, Cisco IP Phones pass all packets received on the switch port (the port connected to the upstream switch) to the PC port, including 802.1q tagged packets that are destined for the Cisco IP Phone. Setting this field to Disabled makes the Cisco IP Phone stop forwarding the packets tagged with the voice VLAN to the PC port and prevents the attached PC from sending and receiving data on the voice VLAN. You should enable this feature only if you want to capture the voice packets sent on the voice VLAN by using the capture application that is being run on the PC for troubleshooting and monitoring purposes.
PC Port—. You should disable the PC port on the back of the Cisco IP Phone for those IP Phones that are in the common areas, such as the lobby or break rooms.
Settings Access—. Disabling this field prevents users from viewing or modifying the network configuration values on the IP Phones.
Secure the access to campus network devices such as switches and routers by using TACACS+ and RADIUS authentication methods in your campus network. You can perform configurations for your campus network devices from the CLI via Telnet sessions, but you should use Secure Shell (SSH) to access these devices. Disable unused switch ports on the LAN switches and place them in unused VLAN so that they are not misused. Use Spanning Tree Protocol (STP) attack mitigation tools such as BPDU Guard and Root Guard. Refer to the following URL to get more information on securing the routers in your network:
You can increase the security for voice gateways by accepting VoIP call-control messages only from CallManager servers that are members of the CallManager cluster, and block such messages from all other sources. Also, the VoIP gateways should deny H.323, MGCP, Skinny, or SIP connection attempts from the data network. If any PC can use VoIP gateways for calling, it will be hard for you to enforce a centralized dial plan. Lack of this policy can cause a possible DoS vulnerability.
Physical security is sometimes taken lightly, but permission to access network equipment should be given in a controlled manner. Network equipment should be well within recommended environmental limits. All the mission-critical resources might require dispersion to provide effective redundancy. Turning off power is an effective DoS attack; give controlled and limited access to power switches.
In addition to deploying the firewall, you should install Cisco Security Agent (CSA) software on the CallManager, Unity, and other application servers to ensure security and integrity of the server applications.
Instead of focusing on attacks, CSA focuses on preventing malicious and undesired activities on the host. CSA detects and blocks the damaging activities, regardless of the attack. CSA ships with predefined policies that prevent most types of malicious activity from occurring. You can download the CSA standalone-installation version for CallManager, Unity, CRS, and other applications at no charge from Cisco.com.
For more in-depth information on securing IPT networks, refer to the white paper “SAFE: IP Telephony Security in Depth” (Jason Halpern, primary author):
Cisco posts security advisories and notices as and when vulnerabilities are detected in Cisco products. You can access this information from the following URL:
This chapter provided detailed information about designing the call-processing architecture for XYZ. The detailed configurations and configuration procedures should help you to apply to real-world networks based on the example design discussed. Your requirements might be different from what was described in this chapter, but the methodology and processes described should still apply to all IPT designs.
The next chapter takes you through the Cisco Unity design steps for XYZ.