Cisco.IP.Telephony.Planning.Design.Implementation.Operation.and.Optimization [Electronic resources] نسخه متنی

Figure 6-1. U.S. ClusterCluster 1 of XYZ

Figure 6-2. Australia ClusterCluster 2 of XYZ

Figure 6-3. Call Center Calculator

[View full size image]

Figure 6-4. Erlang-B Calculations for IVR Ports

[View full size image]

Figure 6-5. Erlang-B Calculations for the PSTN Trunk Ports

[View full size image]

Figure 6-6. Summary of XYZ Locations and Regions

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 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.)

Device Pool Configuration

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.

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 Configuration

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.

Conferencing

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.

Conferencing Resources in San Jose

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 x 32 = 96 channels

Transcoding pool Assign one DSP: 1 x 32 = 32 channels

To configure the ACT module in this fashion, perform the following procedures:

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

Conferencing Resources in Seattle

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 x (3 DSPs x 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:

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

Conferencing Resources in Sydney

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.

Conferencing Resources in Melbourne

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.

Transcoding

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.

Transcoding Resources in San Jose

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:

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

Transcoding Resources in Sydney

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.

Music on Hold

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.

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.

Configuring the MoH Server

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.

Note

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.

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.

Note

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.

Configuring the Audio Source

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.

Assigning the Audio Source to the Devices

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.

Configuring the Remote-Site Router for MoH

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

Note

In Sydney, the CallManager publisher (SYDCCMA-PUB) is the MoH server. The configuration of the Sydney cluster is similar to that of the San Jose cluster. Ensure that the multicast address used is different from the one used in San Jose, to avoid address conflict.

Configuring the MRGs and MRGLs

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.

Designing MRGs and MRGLs for Cluster 1

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 Joseunicast

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 routermulticast

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.

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.

Note

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.

Designing MRGs and MRGLs for Cluster 2

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 Sydneyunicast

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 routermulticast

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.

To configure the MRGLs, from CallManager Administration, choose Service > Media Resource > Media Resource Group List.

Assigning MRGs and MRGLs to the Devices

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 MRGLContains 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.

Note

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.

Gateway Selection and Sizing

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.

Note

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.

Dial Plan Architecture

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.

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.

Numbering Plan

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

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.

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.

Note

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.

Note

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.

Call-Routing Requirements

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.

Seattle Site:

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.

CallManager Route Plan

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.

Partition Design

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 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.

Note

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.

Calling Search Space Design

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.

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.

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.

Route Groups

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.

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.

Route Lists

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.

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

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.

Wildcards

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.

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

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.

Note

To see all the route patterns that are included when using the @ wildcard, refer to the NANP dial plan file located in C:\Program Files\Cisco\Dial Plan\NANP 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.

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.

Digit Transformations

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.

Calling Party Transformations

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.

Connected Party Transformations

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.

Called Party Transformations

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.

Digit Discarding Instructions

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.

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.

To add route patterns, from CallManager Administration, choose Route Plan > Route Pattern/Hunt Pilot.

Note

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.)

Gatekeeper

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:

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.

Defining a Gatekeeper in CallManager

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.

Defining a Gatekeeper Trunk

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.

Gatekeeper Configuration

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

Inbound Call Routing

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.

Automated Alternate Routing

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:

Enabling the AAR Service Parameter

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.

Defining the External Phone Number Mask

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.

Configuring AAR Groups

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.

Defining AAR Calling Search Spaces

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

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.

SRST for Seattle and Melbourne Remote Sites

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\(...\)/ /14085554\1/
rule 3 /^3\(...\)/ /14085553\1/
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

SRST for Dallas and Brisbane Remote Sites

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