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.

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.

The following two types of conferencing services are available in CallManager:

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:

Table 6-3 shows the hardware deployed in each location for providing conferencing and transcoding resources.

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:

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:

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:

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:

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:

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.

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:

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.

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.

Figure 6-3. Call Center Calculator

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:

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.

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

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:

Table 6-11 shows the values of BHCA, AHT, BHT, and blockage for XYZ.

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.

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

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.

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.

According to the XYZ requirements, the central and remote locations will use the MoH integrated feature with CallManager in the following manner:

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:

The next few sections cover the procedures to complete the preceding tasks.

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 designing a dial plan, you need to obtain the existing numbering plan. The numbering plan provides the following information:

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.

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.

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:

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:

Figure 6-7. Hierarchical Route Plan Elements in CCM

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:

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.

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:

When you define a CSS at both levels, as shown in Figure 6-8, CallManager does the following:

Figure 6-8. Combining Line- and Device-Level CSSs on an IP Phone

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:

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:

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.

Figure 6-9. Two Calling Search Spaces from Table 6-43

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.

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.

Figure 6-10. Route Group Definitions

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:

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:

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.

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-11. Digit Transformations at 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.

Figure 6-12. Digit Transformations at Route Group Level