Cisco Unified Communications SRND Based on Cisco Unified CallManager 4.x
Dial Plan
Downloads: This chapterpdf (PDF - 1.23MB) The complete bookPDF (PDF - 12.58MB) | Feedback

Dial Plan

Table Of Contents

Dial Plan

Planning Considerations

Dialed Pattern Recognition

On-Net versus Off-Net Dialing

Abbreviated Dialing

Avoiding Overlap of Extension Dialing

Dialing String Length

Uniform On-Net Dial Plan

Variable Length On-Net Dial Plan

On-Net and Off-Net Access Codes

Plan Ahead

Dial Plan Elements

User Input on SCCP Phones

Call Routing in Cisco Unified CallManager

Route Patterns

Route Lists

Route Groups

Route Group Devices

Calling Privileges in Cisco Unified CallManager

Partitions

Calling Search Spaces

Digit Manipulation in Cisco Unified CallManager

Automated Alternate Routing

Establish the Phone Number of the Destination

Prefix the Required Access Codes

Voicemail Considerations

Select the Proper Dial Plan and Route

Special Considerations for Sites Located Within the Same Local Dialing Area

Device Mobility

Extension Mobility

Hunt Lists and Line Groups

Hunt Pilot

Hunt List

Line Group

Hunt Group Logout

Line Group Devices

Time-of-Day Routing

Call Routing in Cisco IOS with H.323 Dial Peers

Call Routing in Cisco IOS with a Gatekeeper

Centralized Gatekeeper Configuration

Distributed Gatekeeper Configuration

Distributed Gatekeeper Configuration with Directory Gatekeeper

Calling Privileges in Cisco IOS with H.323 Dial Peers

Digit Manipulation in Cisco IOS with H.323 Dial Peers

Design Considerations

Design Guidelines for Multisite Deployments

Choosing a Dial Plan Approach

Deploying Uniform On-Net Dial Plans

Inter-Site Calls Within a Cluster

Outgoing PSTN and IP WAN Calls

Emergency Calls

Incoming Calls

Voicemail Calls

Deploying Variable-Length On-Net Dial Plans with Partitioned Addressing

Inter-Site Calls Within a Cluster

Outgoing PSTN and IP WAN Calls

Incoming Calls

Voicemail Calls

Deploying Variable-Length On-Net Dial Plans with Flat Addressing

Inter-Site Calls Within a Cluster

Outgoing PSTN and IP WAN Calls

Incoming Calls

Voicemail Calls

Special Considerations for Deployments Without Site Codes

Building Classes of Service for Cisco Unified CallManager

Classes of Service with the Traditional Approach

Classes of Service with the Line/Device Approach

Guidelines for the Line/Device Approach

Extension Mobility Considerations for the Line/Device Approach

Building Classes of Service in Cisco IOS with H.323

Deploying Call Coverage

Deploying Call Coverage in a Multisite Centralized Call Processing Model

Deploying Call Coverage in a Multisite Distributed Call Processing Model

Hunt Pilot Scalability


Dial Plan


Last revised on: February 13, 2008

 

The dial plan is one of the key elements of an IP Telephony system, and an integral part of all call processing agents. Generally, the dial plan is responsible for instructing the call processing agent on how to route calls. Specifically, the dial plan performs the following main functions:

Endpoint addressing

Reachability of internal destinations is provided by assigning directory numbers (DNs) to all endpoints (such as IP phones, fax machines, and analog phones) and applications (such as voicemail systems, auto attendants, and conferencing systems)

Path selection

Depending on the calling device, different paths can be selected to reach the same destination. Moreover, a secondary path can be used when the primary path is not available (for example, a call can be transparently rerouted over the PSTN during an IP WAN failure).

Calling privileges

Different groups of devices can be assigned to different classes of service, by granting or denying access to certain destinations. For example, lobby phones might be allowed to reach only internal and local PSTN destinations, while executive phones could have unrestricted PSTN access.

Digit manipulation

In some cases, it is necessary to manipulate the dialed string before routing the call; for example, when rerouting over the PSTN a call originally dialed using the on-net access code, or when expanding an abbreviated code (such as 0 for the operator) to an extension.

Call coverage

Special groups of devices can be created to handle incoming calls for a certain service according to different rules (top-down, circular hunt, longest idle, or broadcast).

This chapter examines the following main aspects of dial plan:

Planning Considerations

This section analyzes the thought process involved in planning an IP Telephony dial plan, ranging from the number of digits used for internal extensions to the overall architecture of a company's internal dial plan. (Prerequisite: Some familiarity with dial plans in general.)

Dial Plan Elements

This section provides detailed explanations of the elements of a Cisco Unified Communications dial plan. Covered topics include call routing logic, calling privileges, and digit manipulation techniques for various Cisco products. (Prerequisite: A working knowledge of Cisco Unified CallManager and Cisco IOS is recommended.)

Design Considerations

This section contains design and deployment guidelines related to multisite IP Telephony networks, endpoint addressing methods, approaches to building classes of service, and call coverage functionality. (Prerequisite: A working knowledge of Cisco Unified CallManager and Cisco IOS is recommended.)

For more details, refer to the Cisco Unified CallManager System Guide, the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2, and other product documentation available at

http://www.cisco.com

Planning Considerations

The dial plan is the most fundamental attribute of a telephony system. It is at the very core of the user experience because it defines the rules that govern how a user reaches any destination. These rules include:

Extension dialing — how many digits must be dialed to reach an extension on the system

Extension addressing — how many digits are used to identify extensions

Dialing privileges — allowing or not allowing certain types of calls

Path selection — for example, using the IP network for on-net calls, or using one carrier for local PSTN calls and another for international calls

Automated selection of alternate paths in case of network congestion — for example, using the local carrier for international calls if the preferred international carrier cannot handle the call

Blocking of certain numbers— for example, pay-per-minute calls

Transformation of the called number — for example, retaining only the last five digits of a call dialed as a ten-digit number

Transformation of the calling number — for example, replacing a caller's extension with the office's main number when calling the PSTN

A dial plan suitable for an IP telephony system is not fundamentally different from a dial plan designed for a traditional TDM telephony system; however, an IP-based system presents the dial plan architect with some new possibilities. For example, because of the flexibility of IP-based technology, telephony users in separate sites who used to be served by different, independent TDM systems can now be included in one, unified IP-based system. These new possibilities afforded by IP-based systems require some rethinking of the way we look at dial plans. This section examines some of the elements that the system planner must consider to properly establish the requirements that drive the design of the dial plan.

Dialed Pattern Recognition

Digit strings dialed by a user on a telephone generally follow patterns. For instance, many enterprises implement a five-digit abbreviated dialing pattern for calls made within the same office location. Also, many enterprises rely on a single-digit access code to represent outside dialing, followed by some quantity of digits to reach a local PSTN number or a long-distance PSTN number (for example, 9 followed by seven digits to reach a local number, or 9 followed by 1 and ten digits to reach a long-distance destination).

The system administrator must plan the system's recognition of these patterns to ensure that the system will act promptly upon detection of a string that corresponds to a predetermined pattern so that users experience no (or minimal) post-dialing delay.

In Cisco Unified CallManager 4.2, you can implement pattern recognition by configuring route patterns, translation patterns, phone DNs, and so forth. With each digit dialed by the user, the phone sends a signaling message to Cisco Unified CallManager, which performs the incremental work of recognizing a matching pattern. As each key press from the user input is collected, Cisco Unified CallManager's digit analysis provides appropriate user feedback, such as:

Playing dial tone when the phone first goes off-hook

Stopping dial tone once a digit has been dialed

Providing secondary dial tone if an appropriate sequence of digits has been dialed, such as when the off-net access code 9 is dialed

Once digit dialing is completed, Cisco Unified CallManager provides user feedback in the form of call progress tones, such as ringback tone if the destination is in the alerting stage or reorder tone if the destination is invalid.

On-Net versus Off-Net Dialing

Calls that originate and terminate on the same telephony network are considered to be on-network (or on-net). By contrast, if a call originates in company A and terminates at company B, it probably has to be routed through different telephony networks: first company A's network, followed by the PSTN, and finally into company B's network. From the caller's perspective, the call was routed off-network (or off-net); from the called party's perspective, the call originated off-net.

In TDM systems, the on-net boundaries of a telephony system are established by the PBX or Centrex system, and they typically do not extend outside of a single site. When they do, they typically do not include sites not immediately on the periphery of a large system hub.

One of the key attributes of IP telephony is its ability to expand the boundaries of calls that can be considered on-net. For instance, telephony users in an enterprise with six dispersed branch offices might be used to reaching one colleague with abbreviated dialing (for example, four-digit dialing) if the called party is located in the same site but dialing a full PSTN number to reach another colleague located in a different site. With an IP-based system where all users are served by the same IP network, it now becomes economically feasible to unite all six branches under a four-digit abbreviated dialing plan, with the IP network as the preferred path and automated overflow to the PSTN as a secondary path if the IP network is congested.

Abbreviated Dialing

Consider an extension with direct inward dial (DID) capability, which can be reached directly from the PSTN. An off-net PSTN caller has to dial the fully qualified PSTN number (for example, 1 415 555 1234) to reach a DID extension. An on-net caller might, however, prefer the ability to reach that same extension by simply dialing the last few digits of the DID number. In a four-digit abbreviated dial plan, the on-net caller would dial only 1234 in this example to reach the same extension.

Avoiding Overlap of Extension Dialing

A telephony system must be configured so that any extension can be reached in an unambiguous manner. To accomplish this goal, the dial plan must satisfy the following requirements:

All on-net extension dialing must be globally unique. For instance, in a system using an abbreviated four-digit on-net dial plan, there cannot be an extension 1000 in site A and another extension 1000 in site B if the requirement is to reach either of them by dialing only four digits from site C.

There cannot be any partial overlap between different dial strings.

For instance, if 9 is used as an off-net access code in a four-digit abbreviated dial plan (for example, to make PSTN calls), there cannot be any extensions in the 9XXX range. Attempting to do so would create situations where calls are not routed immediately. For example, if a user dialed 9141, the system would have to wait for either more digits (if the user were dialing 9 1 415 555 1234, for example) or the expiration of the interdigit timeout before routing the call to extension 9141. Likewise, if an operator code is used (for example, 0), the entire 0XXX extension range would have to be excluded from a four-digit uniform dial plan.

There cannot be overlapping strings of different length. For example, a system with extensions 1000 and 10000 would force users to wait for the interdigit timeout when they dial 1000.

Dialing String Length

The number of dialable extensions determines the quantity of digits needed to dial extensions. For example, a four-digit abbreviated dial plan cannot accommodate more than 10000 extensions (from 0000 to 9999). If 0 and 9 are reserved as operator code and off-net access code, respectively, the number range is further reduced to 8000 (1000 to 8999).

Uniform On-Net Dial Plan

A dial plan can be designed so that all extensions within the system are reached in a uniform way; that is, a fixed quantity of digits is used to reach a given extension from any on-net origination point. Uniform dialing is desirable because of the simplicity it presents to users. A user does not have to remember different ways to dial a number when calling from various on-net locations.

For example, if phone A is reached by dialing 1234 from any on-net location, whether the calling phone is in the same office or at a different site, the enterprise's dial plan is deemed uniform.

When the enterprise consists of few sites, this approach can be used with few complications. The larger the enterprise, in terms of number of extensions and sites, the more of the following challenges it faces in designing a uniform dial plan:

The number of extensions can exceed the range afforded by the quantity of digits being considered for the dial plan. For instance, if more than 8000 extensions are required (considering the exclusions of the 0XXX and 9XXX ranges), the system may require that an abbreviated dial plan use more than four digits.

Matching on-net abbreviated extensions to DID numbers means that, when a new DID range is obtained from a local exchange carrier, it cannot conflict with the pre-existing on-net abbreviated dial ranges. For example, if the DID range of 415 555 1XXX exists in a system using a four-digit uniform abbreviated dial plan, and DID range 650 556 1XXX is also being considered, it might be desirable to increase the quantity of digits for on-net dialing to five. In this example, the five-digit on-net ranges 51XXX and 61XXX would not overlap.

Most systems require the exclusion of certain ranges due to off-net access codes and operator dialing. In such a system where 9 and 0 are reserved codes, no dial plan (uniform or not) could accommodate on-net extension dialing that begins with 9 or 0. This means that DID ranges could not be used if they would force the use of 9 or 0 as the first digit in the dial plan. For instance, in a five-digit abbreviated dial plan, the DID range 415 559 XXXX (or any subset thereof) could not be used. In this example, alternatives include increasing the length of the abbreviated dialing to six or more digits, or avoiding any DID range whose last five digits start with 9.

Once a given quantity of digits has been selected and the requisite ranges have been excluded (for example, ranges beginning with 9 or 0), the remaining dialing space has to be divided between all sites.

Most systems require that two ranges be excluded, thus leaving eight different possibilities for the leading digit of the dial range. Table 10-1 exemplifies the distribution of the dialing space for a typical four-digit uniform dial plan.

 

Table 10-1 Distribution of Digits in a Typical Four-Digit Uniform Dial Plan 

Range
Use
DID Ranges
Non-DID Ranges

0XXX

Excluded; 0 is used as off-net access code

   

1XXX

Site A extensions

418 555 1XXX

N/A

2XXX

Site B extensions

919 555 2XXX

N/A

3XXX

Site C extensions

415 555 30XX

3[1-9]XX

4[0-4]XX

Site D extensions

613 555 4[0-4]XX

N/A

4[5-9]XX

Site E extensions

450 555 4[5-9]XX

N/A

5XXX

Site A extensions

418 555 5XXX

N/A

6XXX

Site F extensions

514 555 6[0-8]XX

69XX

7XXX

Future

XXX XXX 7XXX

7XXX

8XXX

Future

XXX XXX 8XXX

8XXX

9XXX

Excluded; 9 is used as off-net access code

   

For the example in Table 10-1, the various sites were assigned numbers in the following ways:

Site A, the company headquarters, requires more than 1000 extensions, so two entire ranges of numbers have been retained (1XXX and 5XXX). Note that the corresponding DID ranges must also be retained from the site's local exchange carrier.

Site B has been assigned an entire range (2XXX), allowing for up to 1000 extensions.

Site C was also assigned an entire range, but it has been split between 100 DID extensions (415 555 30XX) and up to 900 non-DID extensions. If growth requires more extensions for DID, any unassigned numbers from the non-DID range could be used.

Sites D and E were each assigned 500 numbers from the 4XXX range. Note that their corresponding DID ranges must match each of the site's respective portions of the 4XXX range. Because the DID ranges are for different sites (probably from different PSTN service providers), more coordination effort is required to split ranges between sites. As the quantity of sites assigned within a given range increases, it becomes increasingly difficult (sometimes impossible) to make full use of an entire range.

Site F's range is split between 900 DID numbers (6[0-8]XX) and 100 non-DID numbers (69XX).

The ranges 7XXX and 8XXX are reserved for future use.

When implementing a new dial plan, one of the main desires of any planner is to avoid having to change phone numbers. In addition, the extension ranges of any existing phone systems may have overlapped without any problems in the past, but they could be incompatible with a uniform dial plan.

Variable Length On-Net Dial Plan

Systems with many sites or overlapping site extension ranges can benefit from the use of a variable-length dial plan with the following characteristics:

Within a site, the system retains the use of abbreviated dialing for calls to on-net extensions (for example, four-digit dialing).

Between sites, users dial an access code followed by a site code and the destination's on-net extension.

Off-net calls require an access code followed by a PSTN number.

The use of access and site codes (see Table 10-2) enables the on-net dial plan to differentiate between extensions that would overlap if a uniform abbreviated dial plan were implemented.

 

Table 10-2 Typical Use of Site Codes 

Site Code
Range
Use
DID Ranges
Non-DID Ranges

1

1XXX

Site A extensions

418 555 10XX

1[1-9]XX

2

1XXX

Site B extensions

919 555 1XXX

N/A

3

1XXX

Site C extensions

907 555 1XXX

N/A


In Table 10-2, sites A, B, and C are independently assigned the four-digit range 1XXX. For calls from site A to site B under the old telephony system, the calls had to be routed as off-net calls. With the new system, these calls can be dialed as on-net calls.

From site A, users simply dial 1234 to reach extension 1234. But from site B, the dial plan must accommodate the ability to reach extension 1234 at site A without conflicting with site B's own extension 1234. Therefore, each site is assigned a site code.

From site B, merely dialing the combination of site A's code with the desired extension is not feasible: in this case because 11234 would partially overlap with site B's extension 1123, thus causing interdigit timeout issues. If, instead, we assign 8 as an inter-site on-net access code, this would allow site B to dial 81234 to reach site A's extension 1234.

The following factors determine the quantity of digits required to dial an on-net, off-site extension:

One digit for the inter-site access code

N digits for the site code, where N is chosen to satisfy the quantity of site codes required (For example, if a system has 13 sites, then a minimum of two digits are required for the site code.)

The quantity of digits required by the destination site's local dial plan

For example, a system with 75 sites which each use four-digit abbreviated dialing would require a format of 8 + SS + XXXX, where 8 is the on-net access code, SS is a two-digit site code, and XXXX is a four-digit extension number, giving a total of seven digits.

On-Net and Off-Net Access Codes

It is common practice in most enterprise telephony systems to dedicate a digit (for example, 9) as an off-net access code to steer calls to an off-net destination. In the variable-length on-net dial plan, another steering digit (for example, 8) is also required as an on-net access code to dial calls to on-net extensions at other sites. These two access codes, along with the use of an operator access code (for example, 0), implicitly exclude three of the ten possible leading digits of any dialed string. This restriction might not prove convenient for either of the following reasons:

The users would be required to know the difference between on-net and off-net destinations, and to select the proper access code.

The exclusion of three entire dialing ranges can become too restrictive or can conflict with some pre-assigned extension ranges. For instance, if a site already uses an abbreviated dialing range beginning with 8, the use of that same digit as an access code would require a change.

In systems where the same off-net access code (for example, 9) is already in use by all sites, it might be desirable to use the same code for both off-net and on-net off-site destinations. This approach has two main implications:

To avoid partial overlap and interdigit timeout situations, the quantity of digits expected after the access code should be uniform.

The telephony system must be able to recognize all on-net numbers dialed as off-net numbers and to route them over the IP network. This task can be simple for small systems with only one Cisco Unified CallManager cluster but complex for large systems with multiple Cisco Unified CallManager clusters.

Plan Ahead

Implementing an IP-based system might require changing certain existing user practices. Although it is preferable to plan a new system so that the implementation is as transparent as possible to users, dialing habits might have to be adapted to accommodate the integration of multiple sites that used to be on separate telephony systems. For instance, adapting to a new global, enterprise-wide dial plan might require changing the way a user reaches another user at a different site, the quantity of digits used to make intra-site calls and, in some cases, the extension numbers. To avoid exposing users to multiple generations of dial plan changes, try to anticipate expansion of the enterprise, which could result in the addition of sites in different dialing regions, an increase in the required number of on-net extensions, PSTN renumbering (for example, an area code split), or business expansion into different countries.

Dial Plan Elements

This section provides design and configuration guidelines for the following dial plan elements within a Cisco Unified Communications system:

User Input on SCCP Phones

Call Routing in Cisco Unified CallManager

Calling Privileges in Cisco Unified CallManager

Digit Manipulation in Cisco Unified CallManager

Automated Alternate Routing

Device Mobility

Extension Mobility

Hunt Lists and Line Groups

Call Routing in Cisco IOS with H.323 Dial Peers

Calling Privileges in Cisco IOS with H.323 Dial Peers

Digit Manipulation in Cisco IOS with H.323 Dial Peers

User Input on SCCP Phones

IP phones using SCCP report every single user input event to Cisco Unified CallManager immediately. For instance, as soon as the user goes off-hook, a signaling message is sent from the phone to the Cisco Unified CallManager server with which it is registered. The phone can be considered to be a terminal, where all decisions resulting from the user input are made by the Cisco Unified CallManager server's configured dial plan.

As other user events are detected by the phone, they are relayed to Cisco Unified CallManager individually. A user who goes off-hook and then dials 1000 would trigger five individual signaling events from the phone to Cisco Unified CallManager. All the resulting feedback provided to the user, such as screen messages, playing dial tone, secondary dial tone, ring back, reorder, and so forth, are commands issued by Cisco Unified CallManager to the phone in response to the dial plan configuration. (See Figure 10-1.)

Figure 10-1 User Input and Feedback for SCCP Phones

It is neither required nor possible to configure dial plan information on IP phones running SCCP. All dial plan functionality is contained in the Cisco Unified CallManager cluster, including the recognition of dialing patterns as user input is collected.

If the user dials a pattern that is denied by Cisco Unified CallManager, reorder tone is played to the user as soon as that pattern becomes the best match in Cisco Unified CallManager's digit analysis. For instance, if all calls to the pay-per-minute Numbering Plan Area (or area code) 976 are denied, reorder tone would be sent to the user's phone as soon as the user dials 91976.

Call Routing in Cisco Unified CallManager

All dialing destinations configured in Cisco Unified CallManager are added to its internal call routing table as patterns. These destinations include IP phone lines, voicemail ports, route patterns, translation patterns, and CTI route points.

When a number is dialed, Cisco Unified CallManager uses closest-match logic to select which pattern to match from among all the patterns in its call routing table. In practice, when multiple potentially matching patterns are present, the destination pattern is chosen based on the following criteria:

It matches the dialed string, and

Among all the potentially matching patterns, it matches the fewest strings other than the dialed string.

For example, consider the case shown in Figure 10-2, where the call routing table includes the patterns 1XXX, 12XX, and 1234.

Figure 10-2 Cisco Unified CallManager Call Routing Logic Example

When user A dials the string 1200, Cisco Unified CallManager compares it with the patterns in its call routing table. In this case, there are two potentially matching patterns, 1XXX and 12XX. Both of them match the dialed string, but 1XXX matches a total of 1000 strings (from 1000 to 1999) while 12XX matches only 100 strings (from 1200 to 1299). Therefore, 12XX is selected as the destination of this call.

When user B dials the string 1212, there are three potentially matching patterns, 1XXX, 12XX and 121X. As mentioned above, 1XXX matches 1000 strings and 12XX matches 100 strings. However, 121X matches only 10 strings; therefore it is selected as the destination of the call.

When user C dials the string 1234, there are three potentially matching patterns, 1XXX, 12XX, and 1234. As mentioned above, 1XXX matches 1000 strings and 12XX matches 100 strings. However, 1234 matches only a single string (the dialed string); therefore it is selected as the destination of this call.


Note Whenever a directory number (DN) is configured in Cisco Unified CallManager Release  4.0 and later, it is placed in the call routing table, regardless of whether the respective device (for example, an IP phone) is registered or not. This behavior differs from previous Cisco Unified CallManager versions, where patterns were added to the call routing table only if the respective devices were registered. An implication of this modified behavior is that it is no longer possible to rely on secondary, identical patterns to provide failover capabilities to applications when the application (and hence the primary pattern) is unregistered. Because the primary pattern is now permanently in the call routing table, the secondary pattern will never be matched. It is, however, possible to achieve the same effect by using the Forward No Answer field on primary patterns such as CTI route points because this field accepts wildcards in Cisco Unified CallManager Release 4.0 and later.


Cisco Unified CallManager automatically "knows" how to route calls to internal destinations within the same cluster. For external destinations such as PSTN gateways, H.323 gatekeepers, or other Cisco Unified CallManager clusters, you have to use the external route construct (described in the following sections) to configure explicit routing. This construct is based upon a three-tiered architecture that allows for multiple layers of call routing as well as digit manipulation. Cisco Unified CallManager searches for a configured route pattern that matches the external dialed string and uses it to select a corresponding route list, which is a prioritized list of the available paths for the call. These paths are known as route groups and are very similar to trunk groups in traditional PBX terminology. Figure 10-3 depicts the three-tiered architecture of the Cisco Unified CallManager external route construct.

Figure 10-3 External Route Pattern Architecture

The following sections describe the individual elements of the external route construct in Cisco Unified CallManager:

Route Patterns

Route Lists

Route Groups

Route Group Devices

Route Patterns

Route patterns are strings of digits and wildcards, such as 9.[2-9]XXXXXX, configured in Cisco Unified CallManager to route calls to external entities. The route pattern can point directly to a gateway for routing calls or point to a route list, which in turn points to a route group and finally to a gateway.

Cisco strongly recommends that you use the complete route pattern, route list, and route group construct because it provides the greatest flexibility for call routing, digit manipulation, route redundancy, and future dial plan growth.

The @ Wildcard

The @ wildcard is a special macro function that expands into a series of patterns representing the entire national numbering plan for a certain country. For example, configuring a single unfiltered route pattern such as 9.@ with the North American Numbering Plan really adds 166 individual route patterns to the Cisco Unified CallManager internal dial plan database.

It is possible to configure Cisco Unified CallManager to accept other national numbering plans. Once this is done, the @ wildcard can be used for different numbering plans even within the same Cisco Unified CallManager cluster, depending on the value selected in the Numbering Plan field on the Route Pattern configuration page. For more information, please refer to the Cisco Unified CallManager Dial Plan Deployment Guide, available at

http://www.cisco.com/en/US/products/sw/voicesw/ps5629/prod_maintenance_guides_list.html

The @ wildcard can be practical in several small and medium deployments, but it can become harder to manage and troubleshoot in large deployments because adopting the @ wildcard forces the administrator to use route filters to block certain patterns (see Route Filters).

Route Filters

Use route filters only with the @ route pattern to reduce the number of route patterns created by the @ wildcard. A route filter applied to a pattern not containing the @ wildcard has no effect on the resulting dial plan.

The logical expression you enter with the route filter can be up to 1024 characters, excluding the NOT-SELECTED fields.

As you increase the number of logical clauses in a route filter, the refresh time of the configuration page also increases and can become unacceptably long.

For large-scale deployments, use explicit route patterns rather than the @ wildcard and route filters. This practice also facilitates management and troubleshooting because all patterns configured in Cisco Unified CallManager are easily visible from the Route Pattern configuration page.

International and Variable-Length Route Patterns

International destinations are usually configured using the ! wildcard, which represents any quantity of digits. For example, in North America the route pattern 9.011! is typically configured for international calls. In most European countries, the same result is accomplished with the 0.00! route pattern.

The ! wildcard is also used for deployments in countries where the dialed numbers can be of varying lengths. In such cases, Cisco Unified CallManager does not know when the dialing is complete and will wait for 15 seconds (by default) before sending the call. You can reduce this delay in any of the following ways:

Reduce the T302 timer (Service Parameter TimerT302_msec) to indicate end of dialing, but do not set it lower than 4 seconds to prevent premature transmission of the call before the user is finished dialing.

Configure a second route pattern followed by the # wildcard (for example, 9.011!# for North America or 0.00!# for Europe), and instruct the users to dial # to indicate end of dialing. This action is analogous to hitting the "send" button on a cell phone.

Overlap Sending and Overlap Receiving

In countries whose national numbering plan is not easily defined with static route patterns, you can configure Cisco Unified CallManager for overlap sending and overlap receiving.

Overlap sending means that Cisco Unified CallManager keeps collecting digits as they are dialed by the end users, and passes them on to the PSTN as they are dialed. To enable overlap sending in Cisco Unified CallManager Release 4.0 or later, check the Allow Overlap Sending box on the Route Pattern Configuration page. (In earlier Cisco Unified CallManager releases, overlap sending is enabled by setting the SendingCompleteIndicator service parameter to False.) The route pattern needs only to include the PSTN access code (for example, "9." in North America or "0." in many European countries).

Overlap receiving means that Cisco Unified CallManager receives the dialed digits one-by-one from a PRI PSTN gateway, and it then waits for completion of the dialed string before attempting to route the call to an internal destination. To enable overlap receiving in Cisco Unified CallManager Release 3.3(3) or later, set the OverlapReceivingFlagForPRI service parameter to True. (In earlier Cisco Unified CallManager releases, the parameter name was OverlapReceivingForPriFlag.)

Digit Manipulation in Route Patterns

Configure digit manipulation only in the route list's view of its member route group and not in the route pattern.

Digit manipulation in the route group completely overrides any digit manipulation done in the route pattern.

If you configure digit manipulation in the route pattern, the Call Detail Record (CDR) records the dialed number after the digit manipulation has occurred. If you configure digit manipulation only in the route group, the CDR records the actual dialed number prior to the digit manipulation.

Similarly, if you configure digit manipulation in the route pattern, the IP phone display of the calling party will show the manipulated number. If you configure digit manipulation only in the route group, the manipulations will be transparent to the end user.

Calling Line ID

The calling line ID presentation can be enabled or disabled on the gateway and also can be manipulated in the route pattern, based on site requirements.

If you select the option Use Calling Party's External Phone Number Mask, then the external call uses the calling line ID specified for the IP phone placing the call. If you do not select this option, then the mask placed in the Calling Party Transform Mask field is used to generate the calling party ID.

Urgent Priority

The Urgent Priority checkbox is often used to force immediate routing of certain calls as soon as a match is detected, without waiting for the T302 timer to expire. For example, in North America, if the patterns 9.911 and 9.[2-9]XXXXXX are configured and a user dials 9911, Cisco Unified CallManager has to wait for the T302 timer before routing the call because further digits may cause the 9.[2-9]XXXXXX to match. If Urgent Priority is enabled for the 9.911 route pattern, Cisco Unified CallManager makes its routing decision as soon as the user has finished dialing 9911, without waiting for the T302 timer.

It is important to note that the Urgent Priority checkbox forces the T302 timer to expire as soon as the configured pattern is the best match for the dialed number. This does not mean that the urgent pattern has a higher priority than other patterns; the closest-match logic described in the section on Call Routing in Cisco Unified CallManager, still applies.

For example, assume the route pattern 1XX is configured as urgent and the pattern 12! is configured as a regular route pattern. If a user dials 123, Cisco Unified CallManager will not make its routing decision as soon as it receives the third digit because even though 1XX is an urgent pattern, it is not the best match (10 total patterns matched by 12! versus 100 patterns matched by 1XX). Cisco Unified CallManager will have to wait for inter-digit timeout before routing the call because the pattern 12! allows for more digits to be input by the user.

Consider another example, where pattern 12[2-5] is marked as urgent and 12! is configured as a regular pattern. If the user dials 123, the pattern 12[2-5] is the best match (4 total patterns matched by 12[2-5] versus 10 patterns matched by 12!). Because the urgent-priority pattern is the best match, the T302 timer is aborted and no further user input is expected. Cisco Unified CallManager routes the call using pattern 12[2-5].

Call Classification

Calls using this route pattern can be classified as on-net or off-net calls. This route pattern can be used to prevent toll fraud by prohibiting off-net to off-net call transfers or by tearing down a conference bridge when no on-net parties are present. (Both of these features are controlled by Service Parameters within Cisco Unified CallManager Administration.)

When the "Allow device override" box is enabled, the calls are classified based on the call classification settings on the associated gateway or trunk.

Forced Account Codes (FAC)

The Forced Account Codes (FAC) checkbox is used to restrict the outgoing calls when using a particular route pattern. If you enable FAC through route patterns, users must enter an authorization code to reach the intended recipient of the call.

When a user dials a number that is routed through a FAC-enabled route pattern, the system plays a tone that prompts for the authorization code. To complete the call, the user authorization code must meet or exceed the level of authorization that is specified to route the dialed number.

Only the authorization name appears in the call detail records (CDR); the authorization code does not appear in the CDR.

The FAC feature is not available if the "Allow overlap sending" checkbox is enabled.

Client Matter Codes (CMC)

The Client Matter Code (CMC) checkbox is used to track calls to certain numbers when using a particular route pattern. (For example, a company can use it to track calls to certain clients.)

If you enable CMC for a route pattern, users must enter a code to reach the intended destination.

When a user dials a number that is routed through a CMC-enabled route pattern, the system plays a tone that prompts for the code. The user must enter the correct code in order to complete the call.

Client Matter Codes appear in the call detail records so that they can be used by the CDR analysis and reporting tool to generate reports for client billing and accounting.

The CMC feature is not available if the "Allow overlap sending" checkbox is enabled.

If both CMC and FAC are enabled, the user dials a number, enters the FAC when prompted to do so, and then enters the CMC at the next prompt.

Route Lists

A route list is a prioritized list of eligible paths (route groups) for an outbound call. Typically, a route list is associated with a remote location, and multiple route patterns may point to it. A typical use of a route list is to specify two paths for a remote destination, where the first-choice path is across the IP WAN and the second-choice path is through the local PSTN gateways.

Route lists have the following characteristics:

Multiple route patterns may point to the same route list.

A route list is a prioritized list of route groups that function as alternate paths to a given destination. For example, you can use a route list to provide least-cost routing, where the primary route group in the list offers a lower cost per call and the secondary route group is used only if the primary is unavailable due to an "all trunks busy" condition or insufficient IP WAN resources.

Each route group in the route list can have its own digit manipulation. For example, if the route pattern is 9.@ and a user dials 9 1 408 555 4000, the IP WAN route group can strip off the 9 1 while the PSTN route group may strip off just the 9.

Multiple route lists can contain the same route group. The digit manipulation for the route group is associated with the specific route list that points to the route group.

If you are performing several digit manipulations in a route pattern or a route group, the order in which the transformations are performed can impact the resulting E.164 address. Cisco Unified CallManager performs the following major types of digit manipulations in the order indicated:

1. Discarding digits

2. Called party transformations

3. Prefixing digits

Route Groups

Route groups control and point to specific devices, which are typically gateways (MGCP or H.323), H.323 trunks to a gatekeeper or remote Cisco Unified CallManager cluster, or SIP trunks to a SIP proxy. (In Cisco CallManager Release 3.2 and earlier, the role of the H.323 trunk was performed by the Anonymous Device gateway and by H.323 gateways configured using the Intercluster Trunk protocol.)

Cisco Unified CallManager sends calls to the devices according to the distribution algorithm assigned. Cisco Unified CallManager supports top-down and circular algorithms.

Route Group Devices

The route group devices are the endpoints accessed by route groups, and they typically consist of gateways or H.323 trunks to a gatekeeper or to remote Cisco Unified CallManagers. You can configure the following types of devices in Cisco Unified CallManager:

Media Gateway Control Protocol (MGCP) gateways

H.323 gateways

H.225 trunk, gatekeeper controlled — trunk to standard H.323 gateways, via a gatekeeper

Intercluster trunk, not gatekeeper controlled — direct trunk to another Cisco Unified CallManager cluster

Intercluster trunk, gatekeeper controlled — trunk to other Cisco Unified CallManager clusters and/or H.323 gateways, via a gatekeeper

SIP trunk — trunk to a SIP proxy (available with Cisco Unified CallManager Release 4.0 or later)


Note Both the H.225 and intercluster trunk (gatekeeper controlled) will automatically discover if the other endpoint is a standard H.323 gateway or a Cisco Unified CallManager and will select H.225 or Intercluster Trunk protocol accordingly.


Calling Privileges in Cisco Unified CallManager

Dialing privileges are configured in order to control which types of calls are allowed (or prevented) for a particular endpoint (such as phones, gateways, or CTI applications). All calls handled by Cisco Unified CallManager are subjected to the dialing privileges implemented through the configuration of the following elements:

Partitions

Calling Search Spaces

A partition is a group of directory numbers (DNs) with similar accessibility, and a calling search space defines which partitions are accessible to a particular device. A device can call only those DNs located in the partitions that are part of its calling search space.

As illustrated in Figure 10-4, items that can be placed in partitions all have a dialable pattern, and they include phone lines, route patterns, translation patterns, CTI route group lines, CTI port lines, voicemail ports, and Meet-Me conference numbers. Conversely, items that have a calling search space are all devices capable of dialing a call, such as phones, phone lines, gateways, and applications (via their CTI route groups or voicemail ports).

Figure 10-4 Partitions and Calling Search Spaces

Partitions

The dial plan entries that you may place in a partition include IP phone directory numbers, translation patterns, route patterns, CTI route points, and voicemail ports. As described in the section on Call Routing in Cisco Unified CallManager, if two or more dial plan entries (directory numbers, route patterns, or so forth) overlap, Cisco Unified CallManager selects the entry with the closest match (most specific match) to the dialed number. In cases where two dial plan entries match the dialed pattern equally, Cisco Unified CallManager selects the dial plan entry that appears first in the calling search space of the device making the call.

For example, consider Figure 10-5, where route patterns 1XXX and 23XX are part of Partition_A and route patterns 12XX and 23XX are part of Partition_B. The calling search space of the calling device lists the partitions in the order Partition_A:Partition_B. If the user of this device dials 2345, Cisco Unified CallManager selects route pattern 23XX in Partition_A as the matching entry because it appears first in the calling device's calling search space. However, if the user dials 1234, Cisco Unified CallManager selects route pattern 12XX in Partition_B as the matching entry because it is a closer match than 1XXX in Partition_A. Remember that the partition order in a calling search space is used exclusively as a tie-breaker in case of equal matches based on the closest-match logic.

Figure 10-5 Impact of Partition Order on the Matching Logic


Note When multiple equal-precision matches occur in the same partition, Cisco Unified CallManager selects the entry that is listed first in its local dial plan database. Since you cannot configure the order in which the dial plan database lists dial plan entries, Cisco strongly recommends that you avoid any possibility of equal-precision matches coexisting within the same partition because the resulting dial plan logic is not predictable in such cases.


Beginning with Cisco Unified CallManager Release 4.1, partitions can be activated or deactivated based on the time and date. You can activate or deactivate partitions by first configuring time periods and schedules within Cisco Unified CallManager Administration and then assigning a specific time schedule to each partition. Outside of the times and days specified by the schedule, the partition is inactive, and all patterns contained within it are ignored by the Cisco Unified CallManager call routing engine. For more information on this feature, see Time-of-Day Routing.

Calling Search Spaces

A calling search space defines which partitions are accessible to a particular device. Devices that are assigned a certain calling search space can access only the partitions listed in that calling search space. Attempts to dial a DN in a partition outside that calling search space will fail, and the caller will hear a busy signal.

If you configure a calling search space both on an IP phone line and on the device (phone) itself, Cisco Unified CallManager concatenates the two calling search spaces and places the line's calling search space in front of the device's calling search space, as shown in Figure 10-6.

Figure 10-6 Concatenation of Line and Device Calling Search Spaces for IP Phones


Note In versions of Cisco Unified CallManager prior to Release 4.2, the device calling search space remains the same as the device is moved to different parts of the network. With Cisco Unified CallManager 4.2, the device calling search space can be determined dynamically based on where in the network the phone is physically located, as determined by the phone's IP address. See Device Mobility, for more details.


If the same route pattern appears in two partitions, one contained in the line's calling search space and one contained in the device's calling search space, then according to the rules described in the section on Partitions, Cisco Unified CallManager selects the route pattern listed first in the concatenated list of partitions (in this case, the route pattern associated with the line's calling search space).

For recommendations on how to set the line and device calling search spaces, refer to the sections on Building Classes of Service for Cisco Unified CallManager, and Classes of Service with the Line/Device Approach.

The maximum length of the combined calling search space (device plus line) is 1024 characters, including separator characters between each partition name. (For example, the string "partition_1:partition_2:partition_3" contains 35 characters.) Thus, the maximum number of partitions in a calling search space varies, depending on the length of the partition names. Also, because the calling search space clause combines the calling search space of the device and that of the line, the maximum character limit for an individual calling search space is 512 (half of the combined calling search space clause limit of 1024 characters).

Therefore, when you are creating partitions and calling search spaces, keep the names of partitions short relative to the number of partitions that you plan to include in a calling search space. For more details on configuring calling search spaces, refer to the Cisco Unified CallManager Administration Guide, available online at

http://www.cisco.com

Before you configure any partitions or calling search spaces, all DNs reside in a special partition named <None>, and all devices are assigned a calling search space also named <None>. When you create custom partitions and calling search spaces, any calling search space you create also contains the <None> partition, while the <None> calling search space contains only the <None> partition.


Note Any dial plan entry left in the <None> partition is implicitly reachable by any device making a call. Therefore, to avoid unexpected results, Cisco strongly recommends that you do not leave dial plan entries in the <None> partition.



Note Cisco strongly recommends that you do not leave any calling search space defined as <None>. Doing so can introduce dial plan behavior that is difficult to predict.


Call-Forward Calling Search Spaces

While the main calling search space configured on the line is concatenated with the device calling search space, the calling search spaces configured for the various types of call forward (Forward All, Forward Busy, Forward No Answer, Forward No Coverage, and Forward Unregistered) are standalone values not concatenated with any other calling search space.

Call Forward settings (except Forward All) can be configured separately for internal or external call types. For example, a user might want to have their phone Call Forward No Answer to voicemail for external callers but to a cell phone number if the caller is a co-worker calling from another Cisco Unified CallManager phone on the network. You can implement this behavior by using different configurations for the Internal and External Call Forward settings.

When Forward All is initiated from an IP phone running SCCP, user input is simultaneously compared to the patterns allowed in the configured Forward All calling search space. If an invalid destination is entered by the phone user, reorder tone is heard.

When the Forward All calling search space is left as <None>, the results are difficult to predict and depend on the Cisco Unified CallManager release. Therefore, Cisco recommends the following best practices when configuring call-forward calling search spaces:

Always provision the Forward All, Forward Busy, Forward No Answer, Forward No Coverage, and Forward Unregistered calling search spaces with a value other than <None>. This practice avoids confusion and facilitates troubleshooting because it enables the network administrator to know exactly which calling search space is being used for forwarded calls.

Configure the Call Forward Busy and Call Forward No Answer calling search spaces with values that allow them to reach the DNs for the voicemail pilot and voicemail ports but not external PSTN numbers.

Configure the Call Forward All calling search space according to your company's policy. Many companies choose to restrict forwarded calls to internal numbers only, to prevent users from forwarding their IP phone lines to a long-distance number and dialing their local IP phone number from the PSTN to bypass long-distance toll charges on personal calls.

Cisco Unified CallManager 4.2 introduces the Call Forward Unregistered (CFUR) feature as a way to reroute calls placed to a temporarily unregistered destination phone. The configuration of CFUR consists of two main elements:

Destination selection

When the DN is unregistered, calls can be rerouted to either of the following destinations:

Voicemail

Calls can be sent to voicemail by selecting the voicemail checkbox and configuring the CFUR calling search space to contain the partition of the voicemail pilot number.

A directory number used to reach the phone through the PSTN

This approach is preferred when a phone is located within a site whose WAN link is down. If the site is equipped with Survivable Remote Site Telephony, the phone (and its co-located PSTN gateway) will re-register with the co-located SRST router. The phone is then able to receive calls placed to its PSTN DID number.

In this case, the appropriate CFUR destination is the corresponding PSTN DID number of the original destination DN. Configure this PSTN DID in the destination field, along with applicable access codes and prefixes (for example, 9 1 415 555 1234).

Calling search space

Cisco Unified CallManager attempts to route the call to the configured destination number by using the called DN's CFUR calling search space. The CFUR calling search space is configured on the target phone and is used by all devices calling the unregistered phone. This means that all calling devices will use the same combination of route pattern, route list, route group, and gateway to place the call, and that all CFUR calls to a given unregistered device will be routed through the same unique gateway regardless of where the calling phone is located. Cisco recommends that you select a centralized gateway as the egress point to the PSTN for CFUR calls and that you configure the CFUR calling search space to route calls to the CFUR destination to this centralized gateway.

The Call Forward Unregistered functionality can result in telephony routing loops if a phone is unregistered while the gateway associated with the phone's DID number is still under control of Cisco Unified CallManager, as is the case if a phone is simply disconnected from the network. In such a case, the initial call to the phone would prompt the system to attempt a first CFUR call to the phone's DID through the PSTN. The resulting incoming PSTN call would in turn trigger another CFUR attempt to reach the same phone's DN, triggering yet another CFUR call from the central PSTN gateway through the PSTN. This cycle could repeat itself until system resources are exhausted.

The new service parameter MaximumForwardUnRegisteredHopsToDn controls the maximum number of CFUR calls that are allowed for a DN at the same time. The default value of 0 means the counter is disabled. If any DNs are configured to reroute CFUR calls through the PSTN, loop prevention is required. Configuring this service parameter to a value of 1 would stop CFUR attempts as soon as a single call is placed through the CFUR mechanism. This setting would also allow only one call to be forwarded to voicemail, if CFUR is so configured. Configuring this service parameter to a value of 2 would allow for up to two simultaneous callers to reach the voicemail of a DN whose CFUR setting is configured for voicemail, while also limiting potential loops to two for DNs whose CFUR configuration sends calls through the PSTN.


Note Extension Mobility DNs should not be configured to send Call Forward Unregistered calls to the PSTN DID associated with the DN. The DNs of Extension Mobility profiles in the logged-out state are deemed to be unregistered, therefore any calls to the PSTN DID number of a logged-out DN would trigger a routing loop. To ensure that calls made to Extension Mobility DNs in the logged-out state are sent to voicemail, ensure that their corresponding Call Forward Unregistered parameters are configured to send calls to voicemail.


Digit Manipulation in Cisco Unified CallManager

The following tools provide digit manipulation capability in Cisco Unified CallManager:

The external route construct (route patterns, route lists, and route groups)

Translation patterns

The external route construct can be used to introduce some digit manipulation while routing calls to external devices, and it is described in the section on Call Routing in Cisco Unified CallManager.

Translation patterns are the most powerful tool in Cisco Unified CallManager to manipulate digits for any type of call. They follow the same general rules and use the same wildcards as route patterns. As with route patterns, you assign a translation pattern to a partition. However, when the dialed digits match the translation pattern, Cisco Unified CallManager does not route the call to an outside entity such as a gateway; instead, it performs the translation first and then routes the call again, this time using the calling search space configured within the translation pattern.

Translation patterns can be used for a variety of applications, as shown by the example in Figure 10-7.

Figure 10-7 Application Example for Translation Patterns

In this example, the administrator wishes to provide users with an operator service that is reached by dialing 0, while also maintaining a fixed-length internal numbering plan. The IP phones are configured with the Phone_css calling search space, which contains the Translations_pt partition (among others). A translation pattern 0 is defined in this partition, and the configured Called Party Transform Mask instructs Cisco Unified CallManager to replace the dialed string (0) with the new string 2001, which corresponds to the DN of the operator phone. A second lookup (of 2001 this time) is forced through the call routing engine, using the Internal_css calling search space, and the call can now be extended to the real operator DN of 2001, which resides in the AllPhones_pt partition.


Note When a dialed number is manipulated using a translation pattern, the translated number is recorded in the call detail record (CDR). However, when the digit manipulation occurs within a route list, the CDR will show the originally dialed number, not the translated one. The Placed Calls directory on the IP phone always shows the string as it was dialed by the user.


Automated Alternate Routing

The automated alternate routing (AAR) feature enables Cisco Unified CallManager to establish an alternate path for the voice media when the preferred path between two endpoints within the same cluster runs out of available bandwidth, as determined by the locations mechanism for call admission control.

The AAR feature applies primarily to centralized call processing deployments. For instance, if a phone in branch A calls a phone in branch B and the available bandwidth for the WAN link between the branches is insufficient (as computed by the locations mechanism), AAR can reroute the call through the PSTN. The audio path of the call would be IP-based from the calling phone to its local (branch A) PSTN gateway, TDM-based from that gateway through the PSTN to the branch B gateway, and IP-based from the branch B gateway to the destination IP phone.

AAR can be transparent to the users. You can configure AAR so that users dial only the on-net (for example, four-digit) directory number of the called phone and no additional user input is required to reach the destination through the alternate network (such as the PSTN).


Note AAR does not support CTI route points as the origin or the destination of calls. Also, AAR is incompatible with the Extension Mobility feature when users roam across different sites. Refer to Extension Mobility, for more details.


You must provide the following main elements for AAR to function properly:

Establish the Phone Number of the Destination

Prefix the Required Access Codes

Select the Proper Dial Plan and Route


Note Beginning with Cisco Unified CallManager Release 4.1.3, automated alternate routing (AAR) can be applied to voicemail hunt group members.


Establish the Phone Number of the Destination

The rerouting of calls requires using a destination directory number (DN) that can be routed through the alternate network (for example, the PSTN). Prior to Cisco Unified CallManager 4.2, AAR uses the dialed digits to establish the on-cluster destination of the call and then combines them with the called party's External Phone Number Mask. The combination of these two elements must yield a fully qualified number that can be routed by the alternate network.

In Cisco Unified CallManager 4.2, two new features are available to determine the AAR destination:

The AAR configuration allows for calls to be directed to the voicemail pilot number if you select the voicemail checkbox. This choice does not rely on the numbers originally dialed by the caller, but routes the call according to the Voice Mail profile configuration.


Note By default, the directory number configuration retains the AAR leg of the call in the call history, which ensures that the AAR forward to the voice messaging system will select the proper voice mailbox. If you choose Remove this destination from the call forwarding history, the AAR leg of the call is not present in the call history, which would prevent the automated voice mailbox selection and would offer the caller the generic voicemail greeting.


The AAR Destination Mask allows the destination phone number to be determined independently of the External Phone Number mask. For example, if the Caller ID policy for a company required a phone's external phone number mask to be the main directory number of an office (for example, 415 555 1000), the AAR destination mask could be set to 415 555 1234 to provide AAR with the phone's specific PSTN number.

For example, assume phone A in San Francisco (DN = 2345) dials an on-net DN (1234) configured on phone B located in New York. If locations-based call admission control denies the call, AAR retrieves the External Phone Number Mask of the New York phone (212555XXXX) and uses it to derive the fully qualified number (2125551234) that can be routed on the PSTN.

The PSTN routing of a call from San Francisco to New York requires a "1" as a prefix to the phone number. Cisco recommends that you do not include this prefix as part of the External Phone Number Mask of phones because it would be displayed as part of the Calling Party Identification (CallerID) for any calls made by the phones to an off-net destination. Instead, Cisco recommends that you add the "1" as part of the AAR group configuration.

For deployments that cover multiple countries within the same Cisco Unified CallManager cluster, keep in mind that the external phone number mask needs to be configured in such a way that the destination phone can be reached from the same country or from a different country by simply prefixing digits. This means that any in-country prefixes (such as 0 in many countries) should not be included in the external phone number mask if they are not part of the E.164 address.

In order to better understand this, consider an example where a Cisco Unified CallManager cluster has a site in London (United Kingdom), one in Paris (France), and one in Nice (France). The E.164 address of the DID range in Paris is +33145678XXX, but these extensions are usually reached as 0145678XXX when calling from within the French PSTN.

When somebody in the London office wishes to dial the Paris office via the PSTN, the dialed string is 90033145678XXX. However, when somebody in the Nice office wishes to dial the Paris office via the PSTN, the dialed string is 00145678XXX. Therefore, in this case the external phone number mask for the Paris office phones must be set to 145678XXX and not to the usual French national number of 0145678XXX because, if the 0 were included in the mask, it would not be possible to obtain the string 90033145678XXX by simply prefixing additional digits.

Prefix the Required Access Codes

The destination number might require a prefix for an off-net access code (for example, 9) to be routed properly by the origination branch's dial plan. Furthermore, if the point of origin is located in a different area code (also known as Numbering Plan Area, or NPA), then a prefix of "1" might be required as part of the dialed string. When configuring AAR, you place the DNs in AAR groups. For each pair of AAR groups, you can then configure prefix digits to add to the DNs for calls between the two groups, including prefix digits for calls originating and terminating within the same AAR group.

As a general rule, place DNs in the same AAR group if they share all of the following characteristics:

A common off-net access code (for example, 9)

A common PSTN dialing structure for inter-area calls (for example, 1-NPA-NXX-XXXX in North America)

A common External Phone Number Mask format

For example, assume that both the San Francisco and New York sites share all of the preceding characteristics. We could place the DNs for San Francisco and New York into a single AAR group (for example, US) and configure the group such that AAR calls placed within this same AAR group are prefixed with 91. For phone A in San Francisco to reach phone B in New York (at 212 555 1234), the AAR group configuration prefixes 91 to the dialed string, yielding a completed string of 91 212 555 1234.

For deployments that cover multiple countries, you will typically need at least one AAR group per country. Considering the example introduced in the previous section, two AAR groups could be defined: the UK AAR group (assigned to all DNs in London) and the France AAR group (assigned to all DNs in Paris and Nice). The UK AAR group configuration prefixes 90033 for calls to the France AAR group, while the France AAR group simply prefixes 00 for calls within the same AAR group.

Voicemail Considerations

With Cisco Unified CallManager 4.2, AAR can direct calls to voicemail. The voicemail pilot number is usually dialed without the need for an off-net access code (if the voicemail pilot number is a fully qualified on-net number, such as 8 555 1000). When AAR is configured to send calls to voicemail, the AAR group mechanism will still prefix the configured access code(s). This configuration requires the creation of an AAR group to be used by all DNs whose desired AAR destination is voicemail (for example, vmail_aar_grp). Ensure that the configuration for this voicemail AAR group uses no prefix numbers when receiving calls from other AAR group DNs.

For example: Assume that DNs located in sites San Francisco and New York are configured with AAR group US, which prefixes 91 to calls made between any two DNs in the group. If a DN in San Francisco is configured to send AAR calls to voicemail (for example, 8 555 1000), a call would be placed to 9185551000, which would result in a failed call. Instead, the San Francisco DN should be configured with AAR group vmail_aar_grp. The prefix digits for calls from AAR group US to AAR group vmail_aar_grp are <none>, as shown in the following table. The call will be placed successfully to 85551000.

 

AAR Group
Destination

US

vmail_aar_grp

Source

US

91

<none>

vmail_aar_grp

91

<none>



Note In versions of Cisco Unified CallManager prior to Release 4.2, the AAR group configuration of a DN remains the same as the device is moved to different parts of the network. With Cisco Unified CallManager 4.2, the AAR group can be determined dynamically based on where in the network the phone is physically located, as determined by the phone's IP address. See Device Mobility, for more details.


Select the Proper Dial Plan and Route

AAR calls should egress through a gateway within the same location as the calling phone, thus causing the completed dial string to be sent through the origination site's dial plan. To ensure that this is the case, select the appropriate AAR calling search space on the device configuration page in Cisco Unified CallManager Administration. Configure the off-net dial plan entries (for example, route patterns) in the AAR calling search space to point to co-located gateways and to remove the access code before presenting the call to the PSTN.

For example, phones at the San Francisco site can be configured with an AAR calling search space that permits long distance calls dialed as 91-NPA-NXX-XXXX but that delivers them to the San Francisco gateway with the access code (9) stripped.


Note If you have configured additional route patterns to force on-net internal calls dialed as PSTN calls, ensure that these patterns are not matched by the AAR feature. Refer to Design Guidelines for Multisite Deployments, for more details.



Note To avoid denial of re-routed calls due to call admission control, AAR functionality requires the use of a LAN as the IP path between each endpoint and its associated gateway to the PSTN. Therefore, AAR dial plans cannot rely on centralized gateways for PSTN access.



Note In versions of Cisco Unified CallManager prior to Release 4.2, the AAR calling search space configuration of a device remains the same as the device is moved to different parts of the network. With Cisco Unified CallManager 4.2, the AAR calling search space can be determined dynamically based on where in the network the phone is physically located, as determined by the phone's IP address. See Device Mobility, for more details.


Special Considerations for Sites Located Within the Same Local Dialing Area

In some instances, the AAR dial string might have to be modified locally to allow for local area dialing. For example, assume two separate sites located in New York share the same area code of 212. (See Figure 10-8.) In this case, a number dialed as 91 212 555 1234 would have to be transformed to 9 555 1234.

This transformation is best done with a site-specific translation pattern of 91212.555XXXX (to strip the pre-dot digits and prepend 9). This translation pattern should be placed in a member partition of the AAR calling search space for the New York sites only; the San Francisco site still needs to reach this same destination as 91 212 555 1234. This translation pattern should also be placed in the New York sites' dial plan to provide proper routing of locally reachable numbers dialed as long distance calls. The New York sites' dial plan is responsible for accepting 9 555 1234 as a valid string and transforming it to 555 1234 before delivering the call to the PSTN.

Figure 10-8 Dialed Number Transformations for AAR Calls Between Sites


Note The AAR functionality is not triggered upon detection that the destination phone is unreachable. Therefore, WAN failures do not trigger AAR functionality.


Device Mobility

Cisco Unified CallManager 4.2 introduces new functionality designed to enhance the mobility of devices within an IP network (for example, a phone initially configured for use in San Francisco is physically moved to New York). Although the device still registers with the same Cisco Unified CallManager cluster, it now will adapt some of its behavior based on the new site where it is located. Those changes are triggered by the IP subnet in which the phone is located.

From a dial-plan perspective, the functionality of the following four main configuration parameters can be modified due to the physical location of the phone. For these parameters to be modified, the device must be deemed as roaming outside its home physical location but within its home device mobility group.

Device calling search space

The roaming device pool's Device Mobility calling search space is used instead of the device calling search space configured on the device's configuration page. For example, if a device is roaming from San Francisco to New York, the Device Mobility calling search space of the New York device pool is used as the roaming phone's device calling search space. If you use the line/device approach to classes of service, this approach will establish the path taken for PSTN calls, routing them to the local New York gateway.

AAR calling search space

The roaming device pool's AAR calling search space is used instead of the AAR calling search space configured on the device's configuration page. For example, if a device is roaming from San Francisco to New York, the AAR calling search space of the New York device pool is used as the roaming phone's AAR calling search space. This calling search space will establish the path taken for outgoing AAR PSTN calls, routing them to the local New York gateway.

DN's AAR group

For incoming AAR calls, the AAR group assigned to a DN is retained, whether or not the DN's host phone is roaming. This ensures that the reachability characteristics established for the AAR destination number are retained.

For outgoing AAR calls, the calling DN's AAR group uses the roaming device pool's AAR group instead of the AAR group selected on the DN's configuration page. Note that this AAR group will be applied to all DNs on the roaming device. For example, all DNs on a device roaming from New York to Paris (assuming both locations are in the same Device Mobility group) would inherit the AAR group configured for outgoing calls in the Paris device pool. This AAR group would be applied to all DNs on the roaming device and would allow for the appropriate prepending of prefix digits to AAR calls made from DNs on the roaming phone.

The chapter on Device Mobility, page 22-1, explains the details of this feature.

Extension Mobility

The Extension Mobility feature enables a user to log in to an IP phone and automatically apply his or her profile to that phone, including extension number, speed dials, message waiting indicator (MWI) status, and calling privileges. This mechanism relies on the creation of a device profile associated with each Extension Mobility user. The device profile is effectively a virtual IP phone on which you can configure one or more lines and define calling privileges, speed dials, and so on.

When an IP phone is in the logged-out state, (that is, no Extension Mobility user has logged into it), the phone characteristics are determined by the device configuration page and the line configuration page(s). When a user logs in to an IP phone, the device configuration does not change, but the existing line configuration is saved in the Cisco Unified CallManager database and is replaced by the line configuration of the user's device profile.

One of the key benefits of Extension Mobility is that users can be reached at their own extensions regardless of where they are located, provided that they can log in to an IP phone controlled by the same Cisco Unified CallManager cluster. When Extension Mobility is applied to multisite deployments with centralized call processing, this capability is extended to multiple sites geographically separated from each other.

However, if you combine the Extension Mobility feature with the AAR feature described in the section on Automated Alternate Routing, some limitations exist. Consider the example shown in Figure 10-9, where Extension Mobility and AAR are deployed in a centralized call processing Cisco Unified CallManager cluster with one site in San Jose and one in New York.

Figure 10-9 Extension Mobility and AAR

In this example, assume that an Extension Mobility user who is normally based in San Jose has a DN of 1000 and a DID number of (408) 555-1000. That user's external phone number mask (or the AAR mask in Cisco Unified CallManager 4.2) is therefore configured as 4085551000. The user now moves to the New York site and logs in. Also, assume that the IP WAN bandwidth between San Jose and New York has been entirely utilized.

When the user in San Jose with extension 1001 tries to call 1000, AAR is triggered and, based on the AAR calling search space of the calling party and the AAR groups of both parties, a new call to 914085551000 is attempted by the San Jose phone. This call uses the San Jose gateway to access the PSTN, but because the DID (408) 555-1000 is owned by that same gateway, the PSTN sends the call back to it. The San Jose gateway tries to complete the call to the phone with extension 1000, which is now in New York. Because no bandwidth is available to New York, the AAR feature is invoked again, and one of the following two scenarios will occur:

If the gateway's AAR calling search space contains external PSTN route patterns, this is the beginning of a loop that eventually uses all the PSTN trunks at the San Jose site.

If, on the other hand, the gateway's AAR calling search space contains only internal numbers, the call fails and the caller hears a fast-busy tone. In this case, one PSTN call is placed and one is received, so two PSTN trunks are utilized on the San Jose gateway for the duration of the call setup.


Tip To prevent routing loops such as the one described here, always configure all calling search spaces on the gateway configuration pages to include only internal destinations and no route patterns pointing to route lists or route groups containing that same gateway.


This example highlights the fact that Extension Mobility leverages the dynamic aspect of Cisco IP Communications and, therefore, requires that the call routing between sites use the IP network. Because the E.164 numbers defined in the PSTN are static and the PSTN network is unaware of the movements of the Extension Mobility users, the AAR feature, which relies on the PSTN for call routing, cannot be used to reach Extension Mobility users who move to a site other than their home site.


Note However, if the Extension Mobility user moves to a remote site that belongs to the same AAR group as his or her home site, he or she can use the AAR feature to place calls to other sites when the available IP WAN bandwidth is not sufficient. This is because the path of such a call is determined by the AAR calling search space of the phone from which the call originates. This AAR calling search space does not change when users log in/out of Extension Mobility, and it should be configured to use the visited remote site's gateway.



Tip Configure unregistered Extension Mobility profile DNs to send calls to voicemail. See Call-Forward Calling Search Spaces, for details.


Hunt Lists and Line Groups

The hunt pilot is typically used for call coverage, or distributing a call through a list of phones. For call distribution, you can use a hunt construct. This hunt construct is based upon a three-tiered architecture, similar to that used to route external calls, that allows for multiple layers of call routing as well as digit manipulation.

Cisco Unified CallManager searches for a configured hunt pilot that matches an incoming called number and uses it to select a corresponding hunt list, which is a prioritized list of the available paths for the call. These paths are known as line groups. Figure 10-10 depicts the three-tiered architecture of the hunt construct in Cisco Unified CallManager Release 4.1 or later.


Note In Cisco CallManager Release 3.3 and earlier, call coverage functionality was provided by hunt groups, which are controlled by the Telephony Call Dispatcher (TCD) service, also used by the Cisco Attendant Console. Cisco Unified CallManager Release 4.0 introduced hunt pilots, hunt lists, and line groups, but in that release the hunt pilot structure was combined with the route pattern structure and the hunt list was combined with the route list. Starting with Cisco Unified CallManager Release 4.1, these structures are independent. Table 10-3 summarizes a feature comparison of the hunt lists and line groups in Cisco Unified CallManager Releases 4.0 and 4.1 and hunt groups using the Attendant Console in Cisco Unified CallManager Releases 3.3 and earlier.


 

Table 10-3 Comparison of Features Supported by Route/Hunt List, Hunt Pilot, and Hunt Groups 

Feature
Hunt Groups in Cisco CallManager Release 3.3 and Earlier
Route/Hunt List in Cisco Unified CallManager Release 4.0
Hunt Pilot in Cisco Unified CallManager Release 4.1
Hunt Pilot in Cisco Unified CallManager Release 4.2

Skinny Client Control Protocol (SCCP) endpoints

Yes

Yes (line groups)

Yes

Yes

Gateways and trunks (off-net destinations)

No

Yes (route groups)

No

No

Top-down algorithm

Yes

Yes

Yes

Yes

Circular algorithm

Yes

Yes

Yes

Yes

Longest-idle algorithm

Yes

Yes

Yes

Yes

Broadcast algorithm

Yes

Yes

Yes

Yes

Hunt options

No

Yes

Yes

Yes

Ring-no-answer reversion

No

Yes

Yes

Yes

Performance monitoring (PerfMon)

No

Yes

Yes

Yes

SCCP voicemail port (Cisco Unity)

No

Yes (line groups)

Yes

Yes

Simplified Message Desk Interface (SMDI) voicemail systems

Yes

Yes

Yes

Yes

Queuing

Yes

No

No

No

Linked hunt groups and hunt pilot

Yes

No

Yes

Yes

Log out of hunt groups

No

No

No

Yes


For comparison purposes, Figure 10-10 illustrates the hunt pilot architecture in Cisco Unified CallManager 4.1 and above, while Figure 10-11 shows the hunt pilot architecture in Cisco Unified CallManager 4.0.

Figure 10-10 Three-Tiered Architecture for the Hunt Construct in Cisco Unified CallManager Releases 4.1 and 4.2

Figure 10-11 Hunt Construct in Cisco Unified CallManager Release 4.0

Hunt Pilot

Hunt pilots are strings of digits and wildcards similar to route patterns, such as 9.[2-9]XXXXXX, configured in Cisco Unified CallManager to route calls to directory numbers. The hunt pilot points directly to a hunt list. Hunt lists point to line groups, which finally point to SCCP endpoints.

Beginning with Cisco Unified CallManager Release 4.1, calls can be redirected to a final destination when the hunting fails because of one or both of the following reasons:

All hunting options have been exhausted and the call still is not answered.

A time-out period has expired.

This call redirection is configured in the Hunt Forward Settings section of the Hunt Pilot configuration page, and the destination for this redirect can be either of the following options:

A specific pattern in the internal call routing table of Cisco Unified CallManager

Personal preferences, which point to the Call Forward No Coverage settings for the originally called number when hunting on behalf of that number fails

For example, you can implement the personal preferences option by configuring a user's phone so that the Forward No Answer field redirects the call to a hunt pilot, in order to search for someone else who can answer the call. If the call hunting fails, either because all the hunting options were exhausted or because a time-out period expired, the call can be sent to a destination personalized for the person who was originally called. For example, if you set the Forward No Coverage field within the person's DN configuration page to the voicemail number, the call will be sent to that person's voicemail box if hunting fails.


Note Cisco Unified CallManager Release 4.0 does not support call redirection.


The following considerations apply to calls handled by hunt pilots:

Call Pickup and Group Call Pickup are not supported on calls distributed by a hunt pilot. A member of the line group cannot pick up the hunt pilot call offered to another member in the line group, even if they belong to the same call pickup group.

Calls distributed by the hunt pilot number do not support separate call-forward treatment configured on a directory number in a line group. Thus, the Immediate Divert (iDivert) softkey or any call-forward configurations on the directory number do not work for calls distributed by the hunt pilot. Only the call-forward conditions available as hunt options in a line group configuration apply to the hunt pilot call. However, the iDivert softkey or call-forward configurations work for all incoming calls other than those distributed by the hunt pilot.

The hunt pilot can distribute calls to any of its line group members, even if the members and the hunt pilot reside in different partitions. A call distributed by the hunt pilot overrides all the partitions and calling search space restrictions.

Hunt List

A hunt list is a prioritized list of eligible paths (line groups) for call coverage. Hunt lists have the following characteristics:

Multiple hunt pilots may point to the same hunt list.

A hunt list is a prioritized list of line groups that function as alternate sets of phones which are offered a call placed to the hunt pilot number. For example, you can use a hunt list to attempt to find a taker for the call within a set of phones at a particular site. If the call is not taken, then the hunt list attempts to offer the call through a second line group pointing to phones at a second site.

Hunt lists do not do any digit manipulation.

Multiple hunt lists can contain the same line group.

Line Group

Line group members are user extension numbers that are controlled by Cisco Unified CallManager. Thus, when the call is being distributed through the line group members, Cisco Unified CallManager is in control of the call. Hunt options can be applied to the call when it is not answered or if the extension is busy or unregistered.

Line groups control the order in which the call is distributed, and they have the following characteristics:

Line groups point to specific extensions, which are typically IP phone extensions or voicemail ports.

A single extension may be present in multiple line groups.

Computer Telephony Integration (CTI) ports and CTI route points cannot be added within a line group. Therefore, calls cannot be distributed to endpoints controlled through CTI applications such as Cisco Customer Response Solution (CRS), IP Interactive Voice Response (IP IVR), and so forth

Cisco Unified CallManager distributes calls to the devices according to the distribution algorithm assigned. Cisco Unified CallManager supports the following algorithms:

Top-down

Circular

Longest idle time

Broadcast

In the event of No-Answer, Busy, or Not-Available, line groups redirect a call distributed to an extension based on the hunt options. Cisco Unified CallManager supports the following hunt options:

Try next member, then try next group in hunt list.

Try next member, but do not go to next group.

Skip remaining members and go directly to next group.

Stop hunting.

Hunt Group Logout

In Cisco Unified CallManager 4.2, a user can log out of a hunt group by activating the HLog softkey. Once activated, this function effectively makes all lines configured on the phone act as though they are not part of any hunt group. The phone displays "Logged out of Hunt Group." If a line group contains a shared line, all instances of the shared line that are on devices in the logged-out state will not ring; conversely, all instances of the shared line on devices in the logged-in state will ring.

Lines that are not part of any hunt groups will continue to ring normally, no matter the state of the HLog function.

The HLog function can be activated from Cisco Unified CallManager Administration. By default, the HLog softkey is not configured on the softkey templates. Once added to a phone's softkey template, the HLog button appears in the display when the phone is in the connected, off-hook, or on-hook state.

The Hunt Group Logoff Notification service parameter provides the option of audible ring tones when calls that come in from a line group arrive at the phone in the logged-off state. The Hunt Group Logoff Notification service parameter is in the Clusterwide Parameters (Device - Phone) section of the Service Parameters Configuration window. For enabling the function, specify a valid ring tone file (which must be present on the TFTP server under the C:\Program Files\Cisco\TFTPPath directory). If an invalid file name is provided, no tone will be played.

For more information about hunt algorithms and hunt options, refer to the Cisco Unified CallManager Administration Guide, available at

http://www.cisco.com

Line Group Devices

The line group devices are the endpoints accessed by line groups, and they can be of any of the following types:

Any Skinny Client Control Protocol (SCCP) endpoints, such as Cisco Unified IP Phones, VG248, or ATA 188

Voicemail ports (for Cisco Unity)

H.323 clients

FXS extensions attached to an MGCP gateway

Time-of-Day Routing

Cisco Unified CallManager Release 4.1 introduces the time-of-day (ToD) routing feature. To use this feature, configure the following elements:

Time period

Time schedule

The time period allows you to configure start and end times for business hours. The start and end times indicate the times during which the calls can be routed. In addition to these times, you can set the event to repeat itself on a weekly or yearly basis. Moreover, you can also configure non-business hours by selecting "No business hours" from the Start Time and End Time options. All incoming calls will be blocked when this option is selected.

A time schedule is a group of specific time periods assigned to the partition. It determines whether the partition is active or inactive during the specified time periods. A matching/dialing pattern can be reached only if the partition in which the dialing pattern resides is active.

As illustrated in Figure 10-12, two hunt pilots with the same calling pattern (8000) are configured in two partitions (namely, RTP_Partition and SJC_Partition). Each of these partitions is assigned a time schedule, which contains a list of defined time periods. For example, RTP phones can be reached using Hunt Pilot 1 from 8:00 AM to 12:00 PM EST (GMT - 5.00) Monday through Friday as well as 8:00 AM to 5:00 PM on Sundays. In the same way, SJC phones can be reached using Hunt Pilot 2 from 8:00 AM to 5:00 PM PST (GMT - 8.00) Monday through Friday and 8:00 AM to 5:00 PM on Saturdays. Both of the hunt pilots in this example are inactive on July 4th.

Figure 10-12 Time-of-Day Routing

For the example in Figure 10-12, an incoming call to the hunt pilot (8000) on Wednesday at 3:00  PM will be forwarded to the SJC phones, while a person calling the hunt pilot on July 4th will get a fast busy tone unless there is another pattern that matches 8000.

Call Routing in Cisco IOS with H.323 Dial Peers

The call routing logic on Cisco IOS routers using the H.323 protocol relies on the dial peer construct. Dial peers are similar to static routes; they define where calls originate and terminate and what path the calls take through the network. Dial peers are used to identify call source and destination endpoints and to define the characteristics applied to each call leg in the call connection. Attributes within the dial peer determine which dialed digits the router collects and forwards to telephony devices.

For a detailed description of dial peers and their configuration, refer to Configuring Dial Plans, Dial Peers, and Digit Manipulation, part of the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2, available at

http://www.cisco.com

One of the keys to understanding call routing with dial peers is the concept of incoming versus outgoing call legs and, consequently, of incoming versus outgoing dial peers. Each call passing through the Cisco IOS router is considered to have two call legs, one entering the router and one exiting the router. The call leg entering the router is the incoming call leg, while the call leg exiting the router is the outgoing call leg.

Call legs can be of two main types:

Traditional TDM telephony call legs, connecting the router to the PSTN, analog phones, or PBXs

IP call legs, connecting the router to other gateways, gatekeepers, or Cisco Unified CallManagers

For all calls going through the router, Cisco IOS associates one dial peer to each call leg. Dial peers are also of two main types, according to the type of call leg with which they are associated:

POTS dial peers, associated with traditional TDM telephony call legs

VoIP dial peers, associated with IP call legs

Figure 10-13 shows the following examples of different types of calls going through a Cisco IOS router:

Call 1 is from another H.323 gateway across the IP network to a traditional PBX connected to the router (for example, via a PRI interface). For this call, an incoming VoIP dial peer and an outgoing POTS dial peer are selected.

Call 2 is from an analog phone connected to an FXS port on the router to a Cisco Unified CallManager cluster across the IP network. For this call, an incoming POTS dial peer and an outgoing VoIP dial peer are selected by the router.

Call 3 is from an IP phone controlled by Cisco Unified CallManager Express or SRST to a PSTN interface on the router (for example, a PRI interface). For this call, an automatically generated POTS dial peer (corresponding to the ephone configured on the router) and an outgoing POTS dial peer are selected.

Figure 10-13 Incoming and Outgoing Dial Peers

To match incoming call legs to incoming dial peers, the router selects a dial peer by matching the information elements in the setup message (called number/DNIS and calling number/ANI) with four configurable dial peer attributes. The router attempts to match these items in the following order:

1. Called number with incoming called-number

2. Calling number with answer-address

3. Called number with destination-pattern

4. Incoming voice port with configured voice port

The router must match only one of these conditions. It is not necessary for all the attributes to be configured in the dial peer or that every attribute match the call setup information; only one condition must be met for the router to select a dial peer. The router stops searching as soon as one dial peer is matched, and the call is routed according to the configured dial peer attributes. Even if there are other dial peers that would match, only the first match is used.

How the router selects an outbound dial peer depends on whether direct-inward-dial (DID) is configured in the inbound POTS dial peer:

If DID is not configured in the inbound POTS dial peer, the router performs two-stage dialing and collects the incoming dialed string digit-by-digit. As soon as one dial peer matches the destination pattern, the router immediately places the call using the configured attributes in the matching dial peer.

If DID is configured in the inbound POTS dial peer, the router uses the full incoming dial string to match the destination pattern in the outbound dial peer. With DID, the setup message contains all the digits necessary to route the call, so no additional digit collection is required. If more than one dial peer matches the dial string, all of the matching dial peers are used to form a hunt group. The router attempts to place the outbound call leg using all of the dial peers in the hunt group until one is successful.

By default, dial peers in a hunt group are selected according to the following criteria, in the order listed:

1. Longest match in phone number

This method selects the destination pattern that matches the greatest number of dialed digits. For example, if one dial peer is configured with a dial string of 345.... and a second dial peer is configured with 3456789, the router would first select 3456789 because it has the longest explicit match of the two dial peers.

2. Explicit preference

This method uses the priority configured with the preference dial peer command. The lower the preference number, the higher the priority. The highest priority is given to the dial peer with preference order 0. If the same preference is defined in multiple dial peers with the same destination pattern, a dial peer is selected randomly.

3. Random selection

In this method, all destination patterns are weighted equally.

You can change this default selection order or choose different methods for hunting dial peers by using the dial-peer hunt global configuration command. An additional selection criterion is least recent use, which selects the destination pattern that has waited the longest since being selected (equivalent to longest idle for Cisco Unified CallManager line groups).

Observe the following best practices when configuring H.323 dial peers on a Cisco IOS router:

To ensure that incoming PSTN calls are directly routed to their destination based on the DNIS information, create a default POTS dial peer with the direct-inward-dial attribute, as follows:

dial-peer voice 999 pots
  incoming called-number .
  direct-inward-dial
  port 1/0:23

When using the router as an H.323 gateway connected to a Cisco Unified CallManager cluster, provide redundancy by configuring at least two VoIP dial peers with the same destination pattern pointing to two different Cisco Unified CallManager servers. Use the preference attribute to select the priority order between primary and secondary Cisco Unified CallManager servers. The following example shows the use of the preference attribute:

dial-peer voice 100 voip
 preference 1                     
 
!--- Make this the first choice dial peer.

 ip precedence 5 
 destination-pattern 1...
 session target ipv4:10.10.10.2   
 
!--- This is the address of the primary Cisco Unified CallManager.

 dtmf-relay h245-alpha 
 
 
dial-peer voice 101 voip
 preference 2                     
 
!--- This is the second choice.

 ip precedence 5 
 destination-pattern 1...               
 session target ipv4:10.10.10.3   
 
!--- This is the address of the secondary Cisco Unified CallManager.
 
 dtmf-relay h245-alpha

Call Routing in Cisco IOS with a Gatekeeper

An H.323 gatekeeper is an optional node that manages endpoints (such as H.323 terminals, gateways, and Multipoint Control Units (MCUs), as well as Cisco Unified CallManager Express and Cisco Unified CallManager clusters) in an H.323 network, providing them with call routing and call admission control functions. The endpoints communicate with the gatekeeper using the H.323 Registration Admission Status (RAS) protocol.

Endpoints attempt to register with a gatekeeper on startup. When they want to communicate with another endpoint, they request admission to initiate a call using a symbolic alias for the endpoint, such as an E.164 address or an email address. If the gatekeeper decides that the call can proceed, it returns a destination IP address to the originating endpoint. This IP address might not be the actual address of the destination endpoint, but instead it might be an intermediate address, such as the address of an IP-to-IP gateway or a gatekeeper that routes call signaling.

For more details about the H.323 protocol and the message exchange between H.323 endpoints and gatekeepers, refer to the Cisco IOS H.323 Configuration Guide, available at

http://www.cisco.com

The Cisco 2600, 3600, 3700, 2800, 3800, and 7200 Series routers all support the gatekeeper feature. You can configure Cisco IOS gatekeepers in a number of different ways for redundancy, load balancing, and hierarchical call routing. This section focuses on the call routing capabilities of the gatekeeper feature. For redundancy and scalability considerations, refer to Gatekeeper Redundancy, page 8-18; for call admission control considerations, refer to Cisco IOS Gatekeeper Zones, page 9-15.

Call routing in Cisco IOS gatekeeper is based on the following types of information:

Statically configured information, such as zone prefixes and default technology prefixes

Dynamic information, such as E.164 addresses and technology prefixes provided by H.323 devices during the registration phase

Per-call information, such as called number and technology prefix

A zone is a collection of H.323 devices (such as endpoints, gateways, or MCUs) that register with a gatekeeper. There can be only one active gatekeeper per zone, and you can define up to 100 local zones on a single gatekeeper.

When an H.323 endpoint registers with the gatekeeper, it is assigned to a zone and it can optionally register one or more E.164 addresses for which it is responsible, as well as a technology prefix that specifies which kinds of calls it can handle (for example, voice, video, fax, and so on).

For each zone, you can configure one or more zone prefixes on the gatekeeper. Zone prefixes are strings that contain digits and wildcards and are used by the gatekeeper to facilitate call routing decisions. The following characters are allowed in a zone prefix string:

All numbers between 0 and 9, which match a single specific digit

The dot (.) wildcard, which matches one digit between 0 and 9

The * wildcard, which matches one or more digits between 0 and 9

To understand the gatekeeper call routing behavior, it is helpful to consider the message parsing logic. Figure 10-14 illustrates the parsing logic for an Admission Request (ARQ). To initiate a call, an endpoint sends an Admission Request (ARQ) to the gatekeeper. The ARQ contains either an H.323 ID or the E.164 address of the destination, or called party, as well as the E.164 address or H.323 ID of the source, or calling party.

If the ARQ contains the E.164 address (with Cisco Unified CallManager, the ARQ always contains an E.164 address), the ARQ may or may not contain a technology prefix. If the ARQ contains a technology prefix, the gatekeeper strips it from the called number. If the ARQ does not contain a technology prefix, the gatekeeper uses the default technology prefix if one is configured (see the gw-type-prefix command in the section on Centralized Gatekeeper Configuration). The technology prefix thus obtained is stored in memory, and the gatekeeper continues with the call routing algorithm.

Next, the gatekeeper tries to match the called number with one of the configured zone prefixes. Longest-match is used if multiple potential matches exist. If no zone prefix can be matched, and if the gatekeeper is configured to accept calls with an unknown prefix, the gatekeeper then assumes that the destination zone is equal to the source zone.

At this point, the gatekeeper searches in the chosen destination zone for a registered E.164 address that matches the called number. If there is a match, the gatekeeper can send an Admission Confirm (ACF), provided that the requested bandwidth for the call is available and that the called endpoint is registered with the gatekeeper. The ACF will contain the IP address of the destination endpoint. If the bandwidth is unavailable or the called endpoint is not registered, the gatekeeper returns an Admission Reject (ARJ) to the calling endpoint.

If there is no matching E.164 address registered in the destination zone, the gatekeeper will use the previously stored technology prefix to choose a gateway registered in that zone as the destination for the call. The same considerations regarding bandwidth availability and endpoint registration dictate whether the gatekeeper will send an ACF or an ARJ to the calling endpoint.

Upon receipt of an ACF from the gatekeeper, the source endpoint can send a setup message directly to the destination endpoint by using the IP address returned in the ACF.

Figure 10-14 Gatekeeper Address Resolution for an ARQ

Figure 10-15 illustrates the parsing logic for a Location Request (LRQ). LRQ messages are exchanged between gatekeepers and are used for inter-zone (remote zone) calls. For example, gatekeeper A receives an ARQ from a local zone gateway requesting call admission for a remote zone device. Gatekeeper A then sends an LRQ message to gatekeeper B. Gatekeeper B replies to the LRQ message with either a Location Confirm (LCF) or Location Reject (LRJ) message, depending on whether it is configured to admit or reject the inter-zone call request and whether the requested resource is registered.

Figure 10-15 Gatekeeper Address Resolution for an LRQ

Traditional Cisco IOS gatekeeper functionality has been extended to accommodate for IP-to-IP gateways through the concept of a via-zone gatekeeper. (Refer to Cisco IOS Gatekeeper and IP-to-IP Gateway with RSVP, page 9-17, for some deployment examples.)

A via-zone gatekeeper differs from legacy gatekeepers in how it uses LRQ and ARQ messages for call routing. Using via-zone gatekeepers will maintain normal clusters and functionality. Legacy gatekeepers examine incoming LRQs based on the called number, and more specifically the dialedDigits field in the destinationInfo portion of the LRQ. Via-zone gatekeepers look at the origination point of the LRQ before looking at the called number. If an LRQ comes from a gatekeeper listed in the via-zone gatekeeper's remote zone configurations, the gatekeeper checks to see that the zone remote configuration contains an invia or outvia keyword. If the configuration contains either of these keywords, the gatekeeper uses the new via-zone behavior; if not, it uses legacy behavior.

For ARQ messages, the gatekeeper determines if an outvia keyword is configured on the destination zone. If the outvia keyword is configured and the zone named with the outvia keyword is local to the gatekeeper, the call is directed to an IP-IP gateway in that zone by returning an ACF pointing to the IP-IP gateway. If the zone named with the outvia keyword is remote, the gatekeeper sends a location request to the outvia gatekeeper rather than the remote zone gatekeeper. The invia keyword is not used in processing the ARQ.

Centralized Gatekeeper Configuration

A single gatekeeper can support call routing between clusters and call admission control for up to 100 Cisco Unified CallManager clusters. Figure 10-16 illustrates a distributed call processing environment with two Cisco Unified CallManager clusters and a single, centralized gatekeeper.

Figure 10-16 Centralized Gatekeeper Supporting Two Clusters

Example 10-1 shows the gatekeeper configuration for the example in Figure 10-16.

Example 10-1 Configuration for Centralized Gatekeeper

gatekeeper
 zone local GK-Site1 customer.com 10.1.10.100
 zone local GK-Site2 customer.com
 zone prefix GK-Site1 408.......
 zone prefix GK-Site2 212.......
 bandwidth interzone GK-Site1 160
 bandwidth interzone GK-Site2 160
 gw-type-prefix 1#* default-technology
 arq reject-unknown-prefix
 no shutdown

The following notes also apply to Figure 10-16:

Each Cisco Unified CallManager cluster has a local zone configured to support Cisco Unified CallManager trunk registrations.

A zone prefix is configured for each zone to allow inter-zone and inter-cluster call routing.

Bandwidth statements are configured for each site. Cisco recommends that you use the bandwidth interzone command because using the bandwidth total command can cause issues in some configurations. Bandwidth is measured in kilobits per second (kbps).

The gw-type-prefix 1# default-technology command allows all locally unresolved calls to be forwarded to a device registered with a technology prefix of 1# in the local zone. In this example, all Cisco Unified CallManager trunks have been configured to register with a 1# prefix.

Technology prefixes indicate the type of call being made. The specific values used as technology prefixes are arbitrary and are defined by the network administrator. The same values should be used consistently throughout the entire deployment.

Technology prefixes are sent as a prefix to the E.164 address (phone number) to indicate whether the call is voice, video, or some other type. The # symbol is generally used to separate the prefix from the E.164 number. If a prefix is not included, the default technology prefix is used to route the call. There can be only one default technology prefix for the entire deployment.

Cisco IOS gateways automatically add a technology prefix to outbound calls if the gateway has a prefix configured. The gateway also automatically strips the prefix from incoming H.323 calls. Cisco Unified CallManager can register with the gatekeeper using a technology prefix, as specified on the configuration page for gatekeeper-controlled H.323 trunks. However, this technology prefix is not automatically added to outgoing calls to the gatekeeper, and is not automatically stripped from inbound calls to Cisco Unified CallManager. You can use translation patterns and significant digits to manipulate the called number so as to add or strip the technology prefix as needed.

The arq reject-unknown-prefix command guards against potential call routing loops across redundant Cisco Unified CallManager trunks.

Distributed Gatekeeper Configuration

Gatekeepers can be distributed to conserve bandwidth or to provide local call routing for H.323 gateways in case of a WAN failure. Figure 10-17 illustrates a distributed call processing environment with two clusters and two gatekeepers.

Figure 10-17 Distributed Gatekeepers Supporting Two Clusters

Example 10-2 shows the gatekeeper configuration for Site 1 in Figure 10-17.

Example 10-2 Gatekeeper Configuration for Site 1

gatekeeper
 zone local GK-Site1 customer.com 10.1.10.100
 zone remote GK-Site2 customer.com 10.1.11.100
 zone prefix GK-Site1 408.......
 zone prefix GK-Site2 212.......
 bandwidth remote 160
 gw-type-prefix 1#* default-technology
 arq reject-unknown-prefix
 no shutdown

The following notes apply to Example 10-2:

A local zone is configured for registration of local Cisco Unified CallManager cluster trunks.

A remote zone is configured for routing calls to the Site 2 gatekeeper.

Zone prefixes are configured for both zones for inter-zone call routing.

The bandwidth remote command is used to limit bandwidth between the local zone and any other remote zone.

The gw-type-prefix 1# default-technology command allows all locally unresolved calls to be forwarded to a device registered with a technology prefix of 1# in the local zone. In this example, all Cisco Unified CallManager trunks have been configured to register with a 1# prefix.

The arq reject-unknown-prefix command guards against potential call routing loops across redundant Cisco Unified CallManager trunks.

Example 10-3 shows the gatekeeper configuration for Site 2 in Figure 10-17.

Example 10-3 Gatekeeper Configuration for Site 2

gatekeeper
 zone local GK-Site2 customer.com 10.1.11.100
 zone remote GK-Site1 customer.com 10.1.10.100
 zone prefix GK-Site2 212.......
 zone prefix GK-Site1 408.......
 bandwidth remote 160
 gw-type-prefix 1#* default-technology
 arq reject-unknown-prefix
 no shutdown

The following notes apply to Example 10-3:

A local zone is configured for registration of local Cisco Unified CallManager cluster trunks.

A remote zone is configured for routing calls to the Site 1 gatekeeper.

Zone prefixes are configured for both zones for inter-zone call routing.

The bandwidth remote command is used to limit bandwidth between the local zone and any other remote zone.

The gw-type-prefix 1# default-technology command allows all locally unresolved calls to be forwarded to a device registered with a technology prefix of 1# in the local zone. In this example, all Cisco Unified CallManager trunks have been configured to register with a 1# prefix.

The arq reject-unknown-prefix command guards against potential call routing loops across redundant Cisco Unified CallManager trunks.

Distributed Gatekeeper Configuration with Directory Gatekeeper

Because there is no gatekeeper protocol available to update gatekeeper routing tables, use of a directory gatekeeper can help make distributed gatekeeper configurations more scalable and more manageable. Implementing a directory gatekeeper makes gatekeeper configurations at each site simpler and moves most of the configuration for inter-zone communication into the directory gatekeeper.

Without a directory gatekeeper, you would have to add an entry in every gatekeeper on the network every time you add a new zone on one of the gatekeepers. However, with a directory gatekeeper, you can add the new zone in the local gatekeeper and the directory gatekeeper only. If the local gatekeeper cannot resolve a call request locally, it forwards that request to the directory gatekeeper with a matching zone prefix.

Figure 10-18 illustrates a Cisco Unified CallManager distributed call processing environment with distributed gatekeepers for local call routing and a directory gatekeeper to provide call routing between gatekeepers.

Figure 10-18 Distributed Gatekeepers with a Directory Gatekeeper

Example 10-4 shows the gatekeeper configuration for Site 1 in Figure 10-18. Because the Site 1 and Site 2 gatekeeper configurations are almost identical in this example, only Site 1 is covered here.

Example 10-4 Gatekeeper Configuration for Site 1, with Directory Gatekeeper

gatekeeper
 zone local GK-Site1 customer.com 10.1.10.100
 zone remote DGK customer.com 10.1.10.101
 zone prefix GK-Site1 408.......
 zone prefix DGK ..........
 bandwidth remote 160
 gw-type-prefix 1#* default-technology
 arq reject-unknown-prefix
 no shutdown

The following notes also apply to Example 10-4:

A local zone is configured for registration of local Cisco Unified CallManager cluster trunks.

A remote zone is configured for the directory gatekeeper.

Zone prefixes are configured for both zones for inter-zone call routing.

The directory gatekeeper zone prefix is configured with 10 dots. This pattern matches any unresolved 10-digit dial strings. Multiple zone prefixes can be configured for a single zone, allowing matches on different length dial strings. A wildcard (*) can also be used for a directory gatekeeper zone prefix, but this method can cause call routing issues in some instances.

The bandwidth remote command is used to limit bandwidth between the local zone and any other remote zone.

The gw-type-prefix 1# default-technology command allows all locally unresolved calls to be forwarded to a device registered with a technology prefix of 1# in the local zone. In this example, all Cisco Unified CallManager trunks have been configured to register with a 1# prefix.

The arq reject-unknown-prefix command guards against potential call routing loops across redundant Cisco Unified CallManager trunks.

Example 10-5 shows the directory gatekeeper configuration for the example in Figure 10-18.

Example 10-5 Directory Gatekeeper Configuration

gatekeeper
 zone local DGK customer.com 10.1.10.101
 zone remote GK-Site1 customer.com 10.1.10.100
 zone remote GK-Site2 customer.com 10.1.11.100
 zone prefix GK-Site1 408*
 zone prefix GK-Site2 212*
 lrq forward-queries
 no shutdown

The following notes also apply to Example 10-5:

A local zone is configured for the directory gatekeeper.

Remote zones are configured for each remote gatekeeper.

Zone prefixes are configured for both remote zones for inter-zone call routing. The wildcard (*) is used in the zone prefix to simplify configuration. Calls will not be routed to the DGK zone, so no prefix is required for it.

The lrq forward-queries command allows the directory gatekeeper to forward an LRQ received from another gatekeeper.

Calling Privileges in Cisco IOS with H.323 Dial Peers

Use the class of restriction (COR) functionality to implement calling privileges with Cisco IOS-based systems using H.323, including H.323 gateways, SRST, and Cisco Unified CallManager Express. This functionality provides flexibility in network design, allows administrators to block calls for all users (for example, calls to 900 numbers), and applies different calling privileges to call attempts from different originators (for example, it allows some users but not others to call international numbers).

The fundamental mechanism at the center of the COR functionality relies on the definition of incoming and outgoing corlists that are associated to existing dial peers, where the concepts of incoming and outgoing are relative to the Cisco IOS router (as in the case of dial peers). Each corlist is defined to include a number of members, which are simply tags previously defined within Cisco IOS.

When a call goes through the router, an incoming dial peer and an outgoing dial peer are selected based on the Cisco IOS dial peer routing logic. If corlists are associated with the selected dial peers, the following additional check is performed before extending the call:

If the members of the outgoing corlist associated with the outgoing dial peer are a subset of the members of the incoming corlist associated with the incoming dial peer, the call is permitted.

If the members of the outgoing corlist associated with the outgoing dial peer are not a subset of the members of the incoming corlist associated with the incoming dial peer, the call is rejected.

If no corlist statements are applied to some dial peers, the following properties apply:

When no incoming corlist is configured on a dial-peer, the default incoming corlist is used. The default incoming corlist has the highest possible priority, and it therefore allows this dial-peer to access all other dial-peers, regardless of their outgoing corlist.

When no outgoing corlist is configured on a dial-peer, the default outgoing corlist is used. The default outgoing corlist has the lowest possible priority, and it therefore allows all other dial-peers to access this dial-peer, regardless of their incoming corlist.

This behavior is best illustrated with an example as shown in Figure 10-19, where one VoIP dial-peer and two POTS dial-peer are defined.

Figure 10-19 Example of COR Behavior

The VoIP dial-peer is associated with the c1 incoming corlist, with members A, B, and C. You can think of members of the incoming corlist as "keys."

The first POTS dial-peer has a destination-pattern of 1.. and is associated with the c2 outgoing corlist, with members A and B. The second POTS dial-peer has a destination-pattern of 2.. and is associated with the c3 outgoing corlist, with members A, B, and D. You can think of members of the outgoing corlists as "locks."

For the call to succeed, the incoming corlist of the incoming dial-peer must have all the "keys" needed to open all the "locks" of the outgoing corlist of the outgoing dial-peer.

In the example shown in Figure 10-19, a first VoIP call with destination 100 is received by the router. The Cisco IOS call routing logic matches the incoming call leg with the VoIP dial-peer and the outgoing call leg with the first POTS dial-peer. The COR logic is then applied; because the c1 incoming corlist has all the keys needed for the c2 outgoing corlist locks (A and B), the call succeeds.

A second VoIP call with destination 200 is then received by the router. The Cisco IOS call routing logic matches the incoming call leg with the VoIP dial-peer and the outgoing call leg with the second POTS dial-peer. The COR logic is then applied; because the c1 incoming corlist is missing one "key" for the c3 outgoing corlist (D), the call is rejected.

Follow these steps when configuring the COR functionality in Cisco IOS:


Step 1 Define "tags" to be used as corlist members with the command dial-peer cor custom.

Step 2 Define corlists with the command dial-peer cor list corlist-name.

Step 3 Associate corlists with existing VoIP or POTS dial-peers by using the command corlist {incoming | outgoing} corlist-name within the dial-peer configuration.


With Cisco IOS Release 12.2(8)T and later, you can apply the COR functionality to SRST-controlled IP phones. Because IP phones register with the SRST router dynamically, SRST has no prior knowledge of the individual phones until they lose connectivity to the Cisco Unified CallManager cluster. Therefore, the COR feature configuration for SRST is based on the phone DNs instead. When the IP phones register with the SRST router, they communicate their DN to it, thus allowing the SRST router to assign them to the appropriate corlist.

Configure COR for IP phones controlled by SRST by using the command cor {incoming | outgoing} corlist-name {corlist-number starting-number - ending-number | default} within the call-manager-fallback configuration mode.

The following limitations apply to this command:

The maximum number of cor {incoming | outgoing} statements under call-manager-fallback is 5 (plus the default statement) in SRST version 2.0, available on Cisco IOS Release 12.2(8)T or later.

The maximum number of cor {incoming | outgoing} statements under call-manager-fallback is 20 (plus the default statement) in SRST version 3.0, available on Cisco IOS Release 12.3(4)T) or later.

The COR functionality can also be deployed with Cisco Unified CallManager Express, using Cisco IOS Release 12.2(8)T and later. Because the individual IP phones are specifically configured within Cisco Unified CallManager Express, you can apply corlists directly to the IP phones themselves by using the command cor {incoming | outgoing} corlist-name within the ephone-dn dn-tag configuration mode of each IP phone.

Refer to the section on Building Classes of Service in Cisco IOS with H.323, for an example of how to apply all these concepts in practice.

For more details on configuration of Cisco SRST and Cisco Unified CallManager Express, refer to the Cisco SRST 3.0 System Administrator Guide and the Cisco Unified CallManager Express 3.1 System Administrator Guide available at

http://www.cisco.com

Digit Manipulation in Cisco IOS with H.323 Dial Peers

In Cisco IOS routers running H.323, digit manipulation is performed via voice translation profiles, which are used to manipulate the calling number (ANI) or called number (DNIS) digits for a voice call or to change the numbering type of a call.

Voice translation profiles are available starting with Cisco IOS Release 12.2(11)T, and they are used to convert a telephone number into a different number before the call is matched to an incoming dial peer or before the call is forwarded by the outgoing dial peer. For example, within your company you might dial a five-digit extension to reach an employee at another site. If the call is routed through the PSTN to reach the other site, the originating gateway must use voice translation profiles to convert the five-digit extension into the ten-digit format that is recognized by the central office switch.

You configure voice translation profiles by using the voice translation-rule and voice translation-profile Cisco IOS commands, which use regular expressions to define the digit strings to be modified. You then specify if the manipulations should be associated to calling numbers, called numbers, or redirected called numbers. After you define a voice translation profile, you can apply it to any of the following elements:

All incoming POTS call legs that terminate on a specific voice port

All incoming VoIP call legs into the router

Outgoing call legs associated with a specific VoIP or POTS dial peer

All incoming or outgoing call legs that terminate on the IP phones controlled by SRST

Incoming call legs for calls originated by all IP phones controlled by SRST


Note Voice translation profiles using the voice translation-rule command replace and enhance the functionality previously provided by the translation-rule command. The syntax of the new command differs from that used by the old command. For more details, refer to voice translation-rule in the Cisco IOS Voice Command Reference, Release 12.2(11)T or later, available at http://www.cisco.com.


A typical application of voice translation profiles is to enable the preservation of on-net inter-site dialing habits from a branch site even when the IP WAN is unavailable and the router is running in SRST mode. For example, consider a simple deployment with a central site in San Jose and three remote sites in San Francisco, New York, and Dallas. Table 10-4 shows the DID ranges and the internal site codes for this example.

 

Table 10-4 Example of DID Ranges and Site Codes for Translation Rule Application 

 
San Jose
San Francisco
New York
Dallas

DID Range

(408) 555-1XXX

(415) 555-1XXX

(212) 555-1XXX

(972) 555-1XXX

Site Code

1

2

3

4


Inter-site calls are normally placed across the IP WAN by dialing the on-net access code 8 followed by the one-digit site code and the four-digit extension of the called party. To preserve these dialing habits even when the IP WAN is down and Cisco SRST is active, the internal numbers must be converted back into the E.164 numbers before being sent to the PSTN. A sample configuration for the San Francisco router is as follows:

voice translation-rule 1
  rule 1 /^81/ /91408555/
  rule 2 /^83/ /91212555/
  rule 3 /^84/ /91972555/

voice translation-profile on-net-xlate
  translate called 1

call-manager-fallback
  translation-profile outgoing on-net-xlate

dial-peer voice 2 pots
  destination-pattern 91[2-9]..[2-9]......
port 1/0:0
  direct-inward-dial
  forward-digits 11

With this configuration, when the San Francisco site is in SRST mode and a user dials 831000, the router will match rule 2 of voice translation-rule 1 and translate the called number to 912125551000. This new number will then be used to match the outgoing dial peer (dial-peer voice 2).

For a detailed description of dial peers and their configuration, refer to Configuring Dial Plans, Dial Peers, and Digit Manipulation, part of the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2, available at

http://www.cisco.com

For a thorough explanation of regular expression syntax in Cisco IOS, refer to the document on Regular Expressions, available at

http://www.cisco.com/en/US/docs/ios/termserv/configuration/guide/tsv_reg_express_ps6441_TSD_Products_Configuration_Guide_Chapter.html

Design Considerations

This section presents the following dial plan design considerations for multisite deployments:

Design Guidelines for Multisite Deployments, covers guidelines and best practices that apply to all multisite deployment models.

Choosing a Dial Plan Approach, presents the various approaches to organizing a dial plan for uniform versus variable-length on-net dialing and, for this second option, partitioned versus flat addressing.

The following sections analyze in detail three dial plan approaches and provide configuration guidelines for each:

Deploying Uniform On-Net Dial Plans

Deploying Variable-Length On-Net Dial Plans with Partitioned Addressing

Deploying Variable-Length On-Net Dial Plans with Flat Addressing

The following sections present two alternative ways of configuring classes of service within Cisco Unified CallManager:

Building Classes of Service for Cisco Unified CallManager

Classes of Service with the Line/Device Approach

Building Classes of Service in Cisco IOS with H.323, explains how to implement classes of service within a Cisco IOS router running the H.323 protocol.

Deploying Call Coverage, provides guidelines and best practices for implementing call coverage functionality using hunt lists and line groups with Cisco Unified CallManager.

Design Guidelines for Multisite Deployments

The following guidelines and best practices apply in common to all multisite IP Telephony deployments. For deployments that involve more than one Cisco Unified CallManager cluster, also refer to the section on Additional Considerations for Distributed Call Processing Deployments.

To prevent routing loops, make sure the calling search spaces of all PSTN gateways do not include any partitions that contain external route patterns.

When choosing DID ranges with your Local Exchange Carrier (LEC), try to select them so that no overlap occurs within a site. For example, if you use four-digit dialing within a site and you need two blocks of 1000 DIDs, the blocks (408)555-1XXX and (408)999-1XXX would overlap when reduced to four-digit numbers and would introduce additional complexity due to inbound and outbound translations.

Allow for multiple ways of dialing emergency numbers. For example, in North America, configure both 911 and 9.911 as emergency route patterns within Cisco Unified CallManager.

When automated alternate routing (AAR) is deployed, ensure that the external phone number mask configured on the IP phones (or the AAR Destination Mask configured on the DN in Cisco Unified CallManager 4.2) is compatible with all the prefixes added by the various AAR groups. For example, in a multi-national deployment, do not include national access codes such as 0 in the mask unless they are part of the global E.164 address.

You can force calls to on-net destinations, but dialed as PSTN calls, to be routed within the cluster by adding translation patterns that match the E.164 DID ranges for each site and that manipulate the digits so they match the destination's internal extension. For example, if a DN is reachable on-net by dialing 1234, but someone within the system dials this same destination as 9 1 415 555 1234, you can force the call to be on-net by creating a translation pattern 9 1 415 555.1XXX, removing all pre-dot digits, and routing the call on-net to the resulting number. However, remember to provision AAR accordingly, using one of the following methods, so that automated PSTN failover is possible when the IP WAN is out of bandwidth:

Configure the AAR calling search space to exclude the partition containing the "force on-net" translation patterns but to include a partition containing the regular route patterns pointing to the PSTN.

Configure the AAR group to prefix digits with a special character such as *, and configure additional route patterns such as *9.! and *9.!# (or *0.! and *0.!#) in the regular partition.

The second approach is preferable because it does not require additional calling search spaces to be defined for AAR. The additional * route patterns also provide a good troubleshooting and testing tool that allows for overriding the "force on-net" configuration and placing calls over the PSTN even when AAR is not invoked, or to force a call through the PSTN when the destination number is located in a branch under SRST mode.

Within a centralized call processing cluster with N sites, you can implement Tail-End Hop-Off (TEHO) using one of the following methods:

TEHO with centralized failover

This method involves configuring a set of N route patterns in a global partition, with each pattern pointing to a route list that has the appropriate remote site route group as the first choice and the central site route group as the second choice.

TEHO with local failover

This method involves configuring N sets of N route patterns in site-specific partitions, with each pattern pointing to a route list that has the appropriate remote site route group as the first choice and the local site route group as the second choice.

While the second approach allows for an optimal failover scenario when the remote gateway or the IP WAN is unavailable, it also introduces a high level of complexity into the dial plan because it requires a minimum of N2 route patterns and N2 route lists, as opposed to the N route patterns and N route lists needed with the first approach.

When appropriate for your national numbering plan, you may configure an additional translation pattern at each site to catch local PSTN calls dialed as long-distance calls and to translate them into the proper abbreviated form. This translation pattern should be accessible only from phones located within the site. Such a configuration also helps simplify the AAR configuration (see Special Considerations for Sites Located Within the Same Local Dialing Area).

Do not use the multilevel precedence and preemption (MLPP) feature to assign higher priority to emergency calls. An emergency-related call might not appear as such to the IP Telephony system, and you would risk terminating an existing emergency call to place another call to the main emergency service routing number. For example, an emergency situation might prompt someone to place a call to a regular ten-digit number to reach a medical professional. Preemption of this call would abort the ongoing emergency communication and could delay handling of the emergency. Also, incoming calls from emergency service personnel would be at risk of preemption by MLPP.


Note A Cisco Unified CallManager cluster with a very large dial plan containing many gateways, route patterns, translation patterns, and partitions can take an extended amount of time to initialize when the Cisco CallManager Service is first started. If the system does not initialize within the default time, there are service parameters that you can increase to allow additional time for the configuration to initialize. For details on the service parameters, refer to the online help for Service Parameters in Cisco Unified CallManager Administration.


Additional Considerations for Distributed Call Processing Deployments

In addition to the considerations made in the previous section, observe the following best practices when designing a dial plan for a distributed call processing deployment (that is, any multisite deployment involving multiple Cisco Unified CallManager clusters):

Avoid splitting DID ranges across multiple Cisco Unified CallManager clusters. This practice would make intercluster routing very difficult because summarization would not be possible. Each DID range should belong to a single Cisco Unified CallManager cluster.

Avoid splitting devices within a remote site between multiple Cisco Unified CallManager 4.x clusters using call admission control based on locations. Locations-based call admission control is significant only within a cluster, and having devices belong to different clusters at the same remote site would lead to poor utilization of the IP WAN bandwidth because you would have to split the available bandwidth between the clusters. Each remote site should belong to a single Cisco Unified CallManager cluster.

Use gatekeeper-controlled intercluster trunks to route calls between Cisco Unified CallManager clusters. This practice enables you to add or modify clusters easily in your network without reconfiguring all other clusters.

Implement redundancy in the connection between Cisco Unified CallManager and the gatekeeper by using a gatekeeper cluster and by assigning the intercluster trunk to a device pool that uses a Cisco Unified CallManager group with multiple servers configured.

When sending calls to the gatekeeper, expand the called number to the full E.164 address. This practice simplifies PSTN failover when the IP WAN is not available because no additional digit manipulation is required to reroute the call via a PSTN gateway. Also, this practice eliminates the need to configure the local (calling) Cisco Unified CallManager with dial length information for each remote site.

Within the gatekeeper, configure one zone per Cisco Unified CallManager cluster. For each cluster/zone, add zone prefix statements to match all DN ranges owned by that cluster.

You can implement Tail-End Hop-Off (TEHO) across multiple Cisco Unified CallManager clusters by following these guidelines:

Add specific route patterns for the relevant E.164 ranges to the source (originating) Cisco Unified CallManager cluster, and point them to a route list that has the IP WAN route group as the first choice and a local PSTN route group as the second choice

Within the Cisco IOS gatekeeper configuration, add zone prefix statements for all the relevant E.164 ranges and point them to the appropriate Cisco Unified CallManager cluster

Ensure that the intercluster trunk calling search space in the destination Cisco Unified CallManager cluster includes partitions featuring route patterns that match the local PSTN numbers, and that digit manipulation is applied as needed (for example, stripping the area code before sending the call to the PSTN).

For details on how to configure a Cisco IOS gatekeeper for distributed call processing deployments, see Gatekeeper Design Considerations, page 8-18.

Choosing a Dial Plan Approach

As introduced in Planning Considerations, there are two main approaches to a dial plan for internal destinations within an IP Telephony system:

Uniform on-net dial plan, where each internal destination is dialed in the same way regardless of whether the caller is located in the same site or in a different site.

Variable-length on-net dial plan, where internal destinations are dialed differently within a site than across sites. Typically, this approach uses four or five-digit abbreviated dialing for calls within a site and either full E.164 addresses or an on-net access code followed by a site code and the extension for calls across sites.

To help you decide which approach is best suited for your needs, consider the following high-level design questions:

How many sites will eventually be served by the IP Telephony system?

What are the calling patterns between sites or branches?

What do users dial within a site and to reach another site?

Are there any calling restrictions applied to on-net inter-site calls?

What transport network (PSTN or IP WAN) will be used for most inter-site calls?

What (if any) CTI applications are being used?

Is there a desire for a standardized on-net dialing structure using site codes?

Uniform on-net dial plans are the easiest to design and configure; however, they work best for small to medium deployments, and they become impractical when the number of sites and users increases. They are described and analyzed in detail in the section on Deploying Uniform On-Net Dial Plans.

Variable-length on-net dial plans are more scalable but also more complex to design and configure. Figure 10-20 shows the typical requirements for a large-scale deployment using the variable-length on-net dial plan approach.

Figure 10-20 Typical Dialing Requirements for Large Multisite Deployments

With Cisco Unified CallManager, there are two main methods for implementing a variable-length on-net dial plan:

Partitioned addressing

The internal extensions are placed in different partitions according to the site where they are located. This method is typically based on full E.164 addresses for inter-site calls and is analyzed in detail in the section on Deploying Variable-Length On-Net Dial Plans with Partitioned Addressing.

Flat addressing

All internal extensions are placed in the same partition. This method is typically based on on-net site codes for inter-site calls and is analyzed in detail in the section on Deploying Variable-Length On-Net Dial Plans with Flat Addressing. In some cases it is possible to use this approach even when using full E.164 addresses for inter-site calls, as described in the section on Special Considerations for Deployments Without Site Codes.

Deploying Uniform On-Net Dial Plans

You can implement a uniform on-net dial plan by following these guidelines:

Uniquely identify all phones with an abbreviated extension.

Place all the phone DNs in a single partition.

At each site, place PSTN route patterns in one or more site-specific partitions, according to the chosen class-of-service approach.

Figure 10-21 shows an example implementation for a single Cisco Unified CallManager cluster deployment.

Figure 10-21 Example of Uniform On-Net Dial Plan Deployment

Use this approach if both of the following conditions apply:

The DID ranges available do not overlap when considering the number of digits chosen to identify internal extensions.

The number of sites covered by the IP Telephony system is not expected to grow significantly over time.

The following sections analyze implementation details and best practices for different types of calls within the framework of uniform on-net dial plans:

Inter-Site Calls Within a Cluster

Outgoing PSTN and IP WAN Calls

Incoming Calls

Voicemail Calls

Inter-Site Calls Within a Cluster

Because all internal DNs are directly reachable from every device's calling search space, all on-net calls (intra-site and inter-site) are automatically enabled and need no additional configuration within Cisco Unified CallManager.

Outgoing PSTN and IP WAN Calls

PSTN calls are enabled via the site-specific partitions and route patterns, so that emergency and local calls can be routed via the local branch gateway. Long-distance and international calls may be routed via the same branch gateway (as shown in Figure 10-21) or via a centralized gateway, depending on company policy. This second option would simply require an additional route list per site, with the first-choice route group pointing to the central site gateway and, optionally, a second-choice route group pointing to the local branch gateway.

Abbreviated dialing to another Cisco Unified CallManager cluster or Cisco Unified CallManager Express is also possible via a gatekeeper. For these IP WAN calls, Cisco recommends that you expand the abbreviated string to the full E.164 via a translation pattern before sending it to the gatekeeper.

Emergency Calls

If Cisco Emergency Responder is used for managing emergency calls, the partition containing the CTI route point used to send calls to Cisco Emergency Responder should be part of the calling search space of all phones in all branches instead of the site-specific 911 patterns as illustrated in Figure 10-21. Cisco Emergency Responder will be able to identify the calling phone because there is no duplicity of DNs allowed in the internal partition. For more information on Cisco Emergency Responder considerations, refer to the chapter on Emergency Services, page 11-1, and to the Cisco Emergency Responder product documentation available at

http://www.cisco.com

Incoming Calls

Incoming PSTN calls simply require stripping the excess digits in order to match the extension length configured in Cisco Unified CallManager. This can be done within the gateway configuration or, alternatively, via a translation pattern included in the gateway's calling search space.

Voicemail Calls

Because every extension is unique within the system, the extension itself can be used to configure voicemail boxes within the voicemail system. No translations are necessary to send calls to the voicemail system or to enable a Message Waiting Indicator (MWI) within Cisco Unified CallManager.

However, when users access the voicemail system from the PSTN, they need to be trained to enter their eight-digit extension to access their voicemail boxes.

Deploying Variable-Length On-Net Dial Plans with Partitioned Addressing

You can implement a variable-length on-net dial plan with partitioned addressing by placing the abbreviated DNs for phones at each site in a different partition (one partition per site), and by relying on a set of translation patterns placed in a global partition (one translation pattern per site) to perform the inter-site call routing.

This method enables you to satisfy the key requirement of supporting abbreviated dialing (typically four or five digits) within a site and full E.164 dialing between sites, at the price of higher complexity in the dial plan.


Note These deployments are also known as overlapping dial plans or dial plans with overlapping extensions because the abbreviated DNs defined at the various sites usually overlap with each other.


Table 10-5 illustrates the basic relationship between calling search spaces and partitions at each site, without taking into account additional elements required to implement classes of service.

 

Table 10-5 Calling Search Spaces and Partitions for Variable-Length Dial Plans with Partitioned Addressing 

Calling Search Space
Partition
Partition Contents

Site1_css

Site1Phones_pt

Site 1 phone DNs (abbreviated form)

 

Site1PSTN_pt

PSTN route patterns for Site 1 (more partitions may be needed based on classes of service)

 

Translations_pt

Translation patterns for inter-site calling within the cluster

...

...

...

SiteN_css

SiteNPhones_pt

Site N phone DNs (abbreviated form)

 

SiteNPSTN_pt

PSTN route patterns for Site N (more partitions may be needed based on classes of service)

 

Translations_pt

Translation patterns for inter-site calling within the cluster


Use this approach if one or more of the following conditions apply:

A global on-net numbering plan using site codes is not desired


Note While this approach can also be used in the presence of an on-net internal numbering plan using site codes, for this scenario Cisco recommends that you follow the flat addressing approach described in the section on Deploying Variable-Length On-Net Dial Plans with Flat Addressing, because it enables you to greatly simplify the dial plan structure and to better manage and troubleshoot the system.


Policy restrictions must be applied to on-net inter-site calls (that is, some or all users are not allowed to dial other sites on-net).

Inter-site calls are always routed over the PSTN (as described in the section on Voice Over the PSTN as a Variant of Centralized Call Processing, page 2-10).

CTI-based applications are not used across sites.


Note Some CTI-based applications (such as Cisco Emergency Responder), as well as Cisco Attendant Console, do not support overlapping extensions and cannot be deployed with the partitioned addressing approach. Other applications, such as Cisco Personal Assistant and Cisco Unified CallManager Assistant, require additional dial plan configuration that becomes more complex and might be impaired in presence of overlapping extensions. If you are planning to deploy these applications, Cisco recommends that you choose the flat addressing approach described in the next section.


To better understand how to deploy the partitioned addressing approach, consider the hypothetical customer network shown in Figure 10-22. This network has a main site (San Jose) and a number of smaller branch sites (New York and Dallas) in the United States, and a similar topology with a main site (London) and several smaller branch sites (Paris and Milan) in Europe. Given the user count, the administration needs, and the network topology, two Cisco Unified CallManager clusters with centralized call processing are deployed, one in the United States and one in Europe. A Cisco IOS gatekeeper cluster is used to provide E.164 address resolution and call admission control between the two clusters. It has also been decided that a variable-length on-net dial plan is required, with four-digit dialing within each site (the 1XXX extension range is chosen at each site) and full E.164 dialing between sites.

Figure 10-22 Example of a Large Multisite Deployment

Using the United States (US) cluster from Figure 10-22 as an example, the following sections analyze implementation details and best practices for different types of calls within the framework of the partitioned addressing approach:

Inter-Site Calls Within a Cluster

Outgoing PSTN and IP WAN Calls

Incoming Calls

Voicemail Calls

Inter-Site Calls Within a Cluster

Figure 10-23 shows an example configuration for inter-site calls within the US cluster.

Figure 10-23 Inter-Site Calls Within a Cluster for the Partitioned Addressing Method

To provide connectivity between sites and partitions, use translation patterns according to the following guidelines:

Define one translation pattern for each site, and place them all in the Translations_pt partition.

Each pattern should match a site's E.164 address range, including the PSTN access code (9 in the example).

The resulting called numbers after translation should match the site's extensions (1XXX in the example).

The calling search space where the call is sent after translation should include the partition that contains the destination site's IP phone DNs.

Outgoing PSTN and IP WAN Calls

Depending on how the various types of PSTN calls need to be routed (centralized gateways versus distributed gateways), the configuration may vary. In the example shown in Figure 10-24, all domestic PSTN calls are routed via the local branch gateway. International calls are first routed through the gatekeeper to intercept calls toward the sites controlled by the Europe cluster, and then through the local PSTN gateway.

Figure 10-24 Outgoing PSTN and IP WAN Calls for the Partitioned Addressing Method.

As Figure 10-24 illustrates, for outgoing PSTN and IP WAN calls, there are no special considerations due to the partitioned nature of the internal addressing.


Note Figure 10-24 uses the traditional approach for building classes of service. However, the line/device approach can also be combined with the partitioned addressing approach. Class-of-service approaches and endpoint addressing approaches are independent and interchangeable.


Incoming Calls

To dispatch incoming PSTN or IP WAN calls to the appropriate extension, you can reuse the translation patterns in the Translations_pt partition mentioned previously. It is sufficient to assign all PSTN gateways a calling search space that contains only the Translations_pt partition, making sure that the gateways also prefix a 9 or a 91 to the incoming dialed number to match the already defined translation patterns. This approach assumes that the PSTN delivers the fully qualified number of each phone to the gateways, so that if an incoming dialed number is prefixed with 91, Cisco Unified CallManager will be presented with a number that matches the global translation patterns located in the Translations_pt partition.

Voicemail Calls

Voicemail integration requires special attention to the following requirements with the partitioned addressing approach:

Voicemail boxes must have unique identifiers. This means that the IP phone extension cannot be used as a voicemail box, and some sort of digit manipulation is needed to obtain a unique number.

Message waiting indicator (MWI) messages from the voicemail system must be able to reach the right IP phone even in the presence of non-unique extensions.

The first issue is addressed in Cisco Unified CallManager by the use of the Voice Mail Box Mask field in the Voice Mail Profile Configuration page. This parameter, when configured, is used to communicate with the voicemail system and to uniquely identify the user. For example, the Voice Mail Box Mask parameter can be set to the full E.164 number associated with the user.

The second issue is addressed by reusing the translation patterns in the on-cluster partition. If the voicemail system has been configured with the full E.164 numbers, it is sufficient to prepend 9 to the E.164 number in order to match the translation patterns previously defined in the Translations_pt partition and to ensure proper inter-site communication. In this way, the MWI messages coming from the voicemail system with the full E.164 number will be translated to the appropriate extension in the specific partition. For example, the voicemail ports can be configured with a calling search space that contains a VM_Translations_pt partition with a single translation pattern that prefixes 9 to the E.164 numbers dialed by the voicemail system. The calling search space of this translation pattern contains the Translations_pt partition, which then provides access to all the extensions via the previously defined translation patterns.


Note This approach requires the configuration of two service parameters within Cisco Unified CallManager. The MultiTenantMwiMode parameter within the Cisco CallManager service must be set to True, and the ValidateDNs parameter within the Cisco Messaging Interface (CMI) service must be set to False.


Deploying Variable-Length On-Net Dial Plans with Flat Addressing

You can implement a variable-length on-net dial plan with flat addressing by defining phone DNs as unique strings containing an on-net access code, a site code, and the extension (for example, 8-123-1000). You can place all these DNs in the same global partition, thus enabling inter-site calls using the site code, and you can define translation patterns in site-specific partitions (one translation pattern and one partition per site) to enable abbreviated dialing within a site.

This internal structure can be hidden from the end users by configuring the Line Text Label parameter within the Directory Number configuration page with the four or five-digit number that users are accustomed to dialing within the site. The external phone number mask should also be provisioned with the corresponding PSTN number in order to enable AAR and to give users a visual indication of their own DID number on the IP phone display.

Table 10-6 illustrates the basic relationship between calling search spaces and partitions at each site, without taking into account additional elements required to implement classes of service:

 

Table 10-6 Calling Search Spaces and Partitions for Variable-Length Dial Plans with Flat Addressing 

Calling Search Space
Partition
Partition Contents

Site1_css

Site1Translations_pt

Translation patterns for Site 1's abbreviated dialing

 

Site1PSTN_pt

PSTN route patterns for Site 1 (more partitions may be needed based on classes of service)

 

Internal_pt

All IP phone DNs (unique form)

...

...

...

SiteN_css

SiteNTranslations_pt

Translation patterns for Site N's abbreviated dialing

 

SiteNPSTN_pt

PSTN route patterns for Site N (more partitions may be needed based on classes of service)

 

Internal_pt

All IP phone DNs (unique form)


Use this approach if one or more of the following conditions apply:

No dialing restrictions are needed for on-net inter-site calls.

A global on-net numbering plan using site codes is desired.

Inter-site calls are normally routed over the IP WAN.

CTI-based applications are used across sites.


Note If dialing restrictions need to be applied to on-net inter-site calls, or an on-net numbering plan using site codes is not desired, refer to the section on Special Considerations for Deployments Without Site Codes, for a variant of this approach that can accommodate these needs.


The following considerations apply to this approach:

The destination numbers of intra-site four-digit calls get expanded to the unique internal DN on the IP phone display.

The Placed Calls directory will display the original four-digit string as dialed by the user.

Calling number, and numbers in the Missed Calls and Received Calls directories, appear as the unique internal DN.

If you wish to preserve the four-digit dialing feature when the IP WAN is unavailable and the branch phones are in SRST mode, you need to apply a translation rule to the call-manager-fallback configuration within the SRST router.

When the branch phones are in SRST mode, the Line Text Label that masks the unique internal DN as a four-digit number on the IP phone display is not available, so the users will see their full internal DN appear instead.

To better understand how to deploy the flat addressing approach, consider again the hypothetical customer network shown in Figure 10-22. In this case, it has been decided that a variable-length on-net dial plan is required, with four-digit dialing within each site (the 1XXX extension range is chosen at each site) and inter-site dialing with an eight-digit string consisting of an on-net access code (8 in this example), a three-digit site code, and the four-digit extension. The three-digit site code is derived from the NANP area code for the sites located in the United States, and from the E.164 country code followed by a site identifier for the sites located in Europe. Table 10-7 summarizes the site codes chosen.

 

Table 10-7 Site Codes for the Customer Network in Figure 10-22 

 
San Jose
New York
Dallas
London
Paris
Milan

Site Code

408

212

972

442

331

392


Using the US cluster from this example, the following sections analyze implementation details and best practices for different types of calls within the framework of the flat addressing approach:

Inter-Site Calls Within a Cluster

Outgoing PSTN and IP WAN Calls

Incoming Calls

Voicemail Calls

Special Considerations for Deployments Without Site Codes

Inter-Site Calls Within a Cluster

Figure 10-25 shows an example configuration for inter-site calls within the US cluster.

Figure 10-25 Inter-Site Calls Within a Cluster for the Flat Addressing Method

To provide connectivity between sites and partitions, use the following guidelines:

Place all unique DNs, including the on-net access code 8, in a global partition (named Internal_pt in this example).

Create one partition per site, each containing a translation pattern that expands four-digit numbers into the fully qualified eight-digit number for that site, thus enabling abbreviated dialing within the site.

For each site, include both the Internal_pt partition and the local translation partition in the phone's calling search space.

The inclusion of the on-net access code in the DN configured in Cisco Unified CallManager enables you to place all internal extensions in a partition directly accessible by all phones, and at the same time ensures that all call directories on the IP phones are populated with numbers that can be directly redialed.


Note You must ensure that the on-net access code and site code combinations do not overlap with the local abbreviated dialing range at any site.


Outgoing PSTN and IP WAN Calls

Depending on how the various types of PSTN calls need to be routed (centralized gateways versus distributed gateways), the configuration may vary.

To provide on-net connectivity for inter-site calls to the Europe (EU) cluster, the following options are possible:

Option 1: Eight-Digit Numbers Only

This option relies on a single route pattern that matches all eight-digit ranges (8XXXXXXX) and points to a route list or route group that contains only a gatekeeper-controlled intercluster trunk. The gatekeeper is configured to use the site codes as zone prefixes.

This solution is simple and easy to maintain because no information is needed about other clusters' site codes or E.164 ranges. However, no automatic PSTN failover is provided when the IP WAN is unavailable, and users are expected to redial manually using the PSTN access code and the E.164 address of the destination.

Option 2: Eight-Digit Numbers and E.164 Addresses with Centralized PSTN Failover

This option, illustrated in Figure 10-26, uses a global set of translation patterns that match the Europe eight-digit ranges and translate them into the corresponding E.164 numbers. The translation patterns use the central site's calling search space (in this case, San Jose), and the call then matches the international PSTN route pattern within the central site's PSTN partition. At each site, the international PSTN route pattern points to a route list with the IP WAN route group as a first choice and the local PSTN route group as a second choice. The gatekeeper is configured to use the E.164 ranges as zone prefixes.

Figure 10-26 Outgoing PSTN and IP WAN Calls for the Flat Addressing Method with Centralized PSTN Failover for IP WAN Calls


Note The configuration example in Figure 10-26 assumes that the line/device approach to building classes of service is being used, but the same considerations apply when using the traditional approach.


This solution requires a little more configuration and maintenance than that outlined in Option 1 because it requires that you configure and maintain information about other clusters' site codes and E.164 ranges. On the other hand, it provides automatic PSTN failover when the IP WAN is unavailable. PSTN failover is provided using the central site's gateway only, so the IP WAN bandwidth usage is not optimal.

Also observe that calls to the Europe sites dialed as PSTN calls will automatically be placed on-net if the IP WAN is available, with an automatic PSTN failover that in this case uses the local gateway.

Option 3: Eight-Digit Numbers and E.164 Addresses with Distributed PSTN Failover

This option, illustrated in Figure 10-27, uses a set of translation patterns per site. Each set matches the Europe eight-digit ranges and translates them into the corresponding E.164 numbers. The translation patterns use the originating site's calling search space, and the call then matches the international PSTN route pattern within the originating site's PSTN partition. At each site, the international PSTN route pattern points to a route list with the IP WAN route group as a first choice and the local PSTN route group as a second choice. The gatekeeper is configured to use the E.164 ranges as zone prefixes.

Figure 10-27 Outgoing PSTN and IP WAN Calls for the Flat Addressing Method with Distributed PSTN Failover for IP WAN Calls

This solution requires a lot more configuration and maintenance than that outlined in Option 2 because it requires that you configure and maintain information about other clusters' site codes and E.164 ranges, and that you repeat the configuration for each remote site within the cluster. On the other hand, it provides automatic PSTN failover when the IP WAN is unavailable, using the local site's gateway so that the IP WAN bandwidth usage is optimal.

Also in this case, as for Option 2, calls to the Europe sites dialed as PSTN calls will automatically be placed on-net if the IP WAN is available, with an automatic PSTN failover using the local gateway.

Incoming Calls

Incoming PSTN calls require that the E.164 number be manipulated to obtain the eight-digit internal number in order to reach the destination phone. You can implement this requirement in any of the following ways:

Configure the Num Digits and Prefix Digits fields within the Gateway Configuration page in Cisco Unified CallManager to strip and then prefix the needed digits.

If you have configured translation patterns to force on-net inter-site calls within the cluster, you can reuse these patterns by simply prefixing the PSTN access code to the incoming called number on the gateway.

If you are using an H.323 gateway, you can use translation rules within the gateway to manipulate the digits before sending the call to Cisco Unified CallManager.

The third approach has the advantage that the translation rules you configured can be reused to provide incoming PSTN connectivity to the IP phones when the branch is in SRST mode.

Voicemail Calls

Because every eight-digit extension is unique within the system, the extension itself can be used to configure voicemail boxes within the voicemail system. No translations are necessary to send calls to the voicemail system or to enable Message Waiting Indicators (MWIs) within Cisco Unified CallManager. Note that users are required to use their eight-digit on-net number when prompted for the mailbox number.

Special Considerations for Deployments Without Site Codes

This scenario is a variant of the flat addressing approach that does not rely on the definition of an on-net numbering plan based on site codes. In this scenario, intra-site calls are still dialed as four-digit numbers, while inter-site calls are dialed as regular PSTN calls and are then intercepted and routed across the IP WAN by Cisco Unified CallManager.

To implement this mechanism, follow these guidelines, illustrated in Figure 10-28:

Define the phone DNs as the full E.164 addresses and place them all in the same partition (named Internal_pt in this example).

Configure the phones' calling search spaces so that they do not have direct access to the Internal_pt partition. Instead, they point to a global partition named Global_Translations_pt, which contains one translation pattern per site or DID range.

Configure the translation patterns to strip the PSTN access code and country code (for example, 91) and send the call to the Internal_pt partition via the Hidden_css calling search space.

Abbreviated four-digit dialing within each site can still be provided via site-specific partitions containing translation patterns (one partition and one translation pattern per site or DID range).

Figure 10-28 Variable-Length Dial Plans with Flat Addressing Without Site Codes

This configuration variant allows you to establish dialing restrictions for inter-site calls. For example, if you must prevent a certain group of users from calling other sites, configure their calling search space so that it does not contain the Global_Translations_pt partition. However, keep in mind the following factors when choosing this approach:

Additional complexity is introduced in the form of translation patterns.

Because you are effectively forcing on-net PSTN calls, remember to configure AAR so that calls can still be placed across the PSTN when the IP WAN bandwidth is not sufficient. Refer to Design Guidelines for Multisite Deployments, for details.

The placed-calls directory displays digit strings as they were dialed by the user. For example, if the user dialed 1000 and a call was placed to phone 4085551000, the placed-calls directory would display 1000, thus allowing for direct redialing of the number without having to edit the dial string.

The missed-calls and received-calls directories display phone numbers as they appeared when the call was offered to the phone. The calling number thus offered depends on the Calling Number configuration parameters of the translation patterns and the line configuration of the calling phone.

The configuration shown in Figure 10-28 assumes that PSTN calls are dialed in the same way in all sites, which is usually true for deployments contained within a single country. International deployments require one additional set of translation patterns per country in order to intercept inter-site calls.

International deployments also introduce the complexity of having to deal with variable-length internal DNs because E.164 addresses have different lengths in different countries (and even within a single country in some cases).

Building Classes of Service for Cisco Unified CallManager

Cisco Unified CallManager offers two main approaches to defining and applying classes of service to users and devices: the traditional approach and the line/device approach. The fundamental elements addressed for each approach include the types of calls to be allowed (for example, local, national, or international) and the path taken by the calls (for example, IP network, local gateway, or central gateway). Both elements depend on the calling search space configuration. The following sections describe the two main approaches used in Cisco Unified CallManager systems to implement classes of service. Both approaches are based on the fundamental functionality of the line and device calling search space.


Note In versions of Cisco Unified CallManager prior to Release 4.2, the device calling search space configuration of a phone remains the same as the device is moved to different parts of the network. With Cisco Unified CallManager 4.2, the device calling search space can be determined dynamically based on where in the network the phone is physically located, as determined by the phone's IP address. See Device Mobility, for more details.


Classes of Service with the Traditional Approach

With Cisco Unified CallManager, you can define classes of service for IP Telephony users by combining partitions and device calling search spaces with external route patterns, as follows:

Place external route patterns in partitions associated with the destinations they can call. While you could place all route patterns in a single partition, you can achieve more refined call restriction policies by associating the route patterns with partitions according to the destinations they can call. For example, if you place local and international route patterns in the same partition, then all users can reach both local and international destinations, which might not be desirable. Cisco recommends that you group route patterns in partitions according to the reachability policies for the various classes of service.

Configure each calling search space to be able to reach only the partitions associated with its call restriction policy. For example, configure the local calling search space to point to the internal and local partitions, so that users assigned to this calling search space can place only internal and local calls.

Assign these calling search spaces to the phones by configuring them on the Cisco Unified CallManager device pages. In this way, all lines configured on the device automatically receive the same class of service.

Figure 10-29 shows a simple example for a single-site deployment.

Figure 10-29 Basic Example of Classes of Service Using the Traditional Approach

With this approach, the device calling search space performs two distinct logical functions:

Path selection

The calling search space contains specific partitions, which in turn contain specific route patterns that point to specific PSTN gateways through route lists and their associated route groups.

Class of service

By selectively including certain partitions and not others in the device calling search space, you effectively apply calling restrictions to certain groups of users.

As a consequence, when you apply this approach to a multisite deployment with centralized call processing, you have to replicate partitions and calling search spaces for each site because for each site you have to create classes of service and, at the same time, route the PSTN calls out of the local branch gateways, as illustrated in Figure 10-30.

Figure 10-30 Calling Search Spaces and Partitions Needed with the Traditional Approach

Follow these additional guidelines when applying this dial plan approach to a multisite deployment with centralized call processing:

To facilitate on-net dialing between sites, place all IP phone DNs in an on-cluster or internal partition that can be reached from the calling search spaces of all sites. Note that this is not possible if the IP phone DNs overlap. For more details on dial plans that use overlapping extensions, refer to Deploying Variable-Length On-Net Dial Plans with Partitioned Addressing.

Give each remote site its own set of partitions and route patterns. The number of partitions per remote site depends on the number of calling restriction policies associated with the route patterns.

Give each site its own set of calling search spaces for its IP phones. The calling search spaces point to the on-cluster partition as well as to the appropriate local route pattern partitions.

Depending on your company's call forwarding restriction policy, you can reuse one of the site-specific device calling search spaces for the Forward All calling search space.

As a general rule, use the following formulas to calculate the total number of calling search spaces and partitions needed:

Total Partitions = (Number of classes of service) * (Number of sites) + (1 Partition for all IP phone DNs)

Total Calling Search Spaces = (Number of classes of service) * (Number of sites)


Note These values represent the minimum number of partitions and calling search spaces required. You may need additional partitions and calling search spaces for special devices and applications, as well as for on-net patterns for other call processing agents.


Extension Mobility Considerations with the Traditional Approach

When using the Extension Mobility feature, the dialing restrictions of a phone are a function of the logged-in (or logged-out) status of the phone. Typically, a logged-out phone should be restricted to calling other phones and services (such as 911), but access to local or toll calls through the PSTN are restricted. Conversely, a phone where a user is logged-in should allow calls according to that user's dialing privileges and should route those calls to the appropriate gateway (for example, a co-located branch gateway for local calls).

With the traditional approach for building classes of service, consider the following guidelines to apply calling restrictions when using Extension Mobility:

At each site, configure the device calling search space for all IP phones to point to only PSTN emergency services (using the local gateway).

Configure the line calling search spaces for IP phones used for Extension Mobility in a logged-out state to point to internal numbers only.

For each Extension Mobility user, configure the line calling search space within the device profile to point to internal numbers and the additional PSTN route patterns allowed for their specific class of service (again, using an appropriate gateway according to company policy).

Note that, when an Extension Mobility user who is normally based in Site 1 logs into an IP phone in Site 2, the path selection for PSTN calls will change as follows:

Emergency calls will be correctly routed using Site 2's PSTN gateway because the emergency services are provided by the device calling search space of the IP phone at Site 2.

All other PSTN calls will be routed according to the Extension Mobility user's profile (more specifically, the line calling search space configured in the device profile). Typically, this means that these PSTN calls will traverse two WAN links and use Site 1's gateway to access the PSTN.

You can use one of the following methods to modify this behavior and ensure that PSTN calls are always routed via the local PSTN gateway even when Extension Mobility users roam across different sites:

Include local PSTN route patterns in the device calling search space and remove them from the line calling search space within the device profile. This method ensures that local PSTN calls will be routed via the co-located branch gateway, but it also means that users will be able to dial these calls even without logging into the IP phones. Long-distance and international calls will still be routed according to the Extension Mobility user's device profile, so this solution is suitable only if these calls are usually routed via a centralized gateway.

Define multiple device profiles for each user, one for each site to which they usually roam. Each device profile is configured so that its line calling search space points to PSTN route patterns that use the local gateway for that site. This method might prove burdensome to configure and manage if a significant number of users roam to a significant number of sites.

Implement the line/device approach described in the next section on Classes of Service with the Line/Device Approach.


Note When Cisco Emergency Responder is used, the site-specific calling search space configured on the device should include the partition containing the 911 CTI route point pointing to Cisco Emergency Responder. This same partition can also contain a translation pattern 9.911 pointing to the same 911 CTI route point, to allow users to dial 9911 when trying to reach emergency services.


Classes of Service with the Line/Device Approach

The traditional approach outlined in the preceding section can result in a large number of partitions and calling search spaces when applied to large multisite deployments with centralized call processing. This configuration is required because the device calling search space is used to determine both the path selection (which PSTN gateway to use for external calls) and the class of service.

It is possible to significantly decrease the total number of partitions and calling search spaces needed by dividing these two functions between the line calling search space and the device calling search space, in what is called the line/device approach.

Keeping in mind how the line calling search space and the device calling search space for each given IP phone are combined within Cisco Unified CallManager, and how the line calling search space partitions appear first in the resulting calling search space (see Calling Privileges in Cisco Unified CallManager), you can apply the following general rules to the line/device approach:

Use the device calling search space to provide call routing information (for example, which gateway to select for PSTN calls).

Use the line calling search space to provide class-of-service information (for example, which calls to allow).

To better understand how to apply these rules, consider the example shown in Figure 10-31, where the device calling search space contains a partition with route patterns to all PSTN numbers, including international numbers. The route patterns point to a PSTN gateway via the route list and route group construct.

Figure 10-31 Key Concepts in the Line/Device Approach

At the same time, the line calling search space contains a partition with a single translation pattern that matches international numbers and that has been configured as a blocked pattern.

The resulting calling search space therefore contains two identical patterns matching international numbers, with the blocked pattern in the line calling search space appearing first. The result is that international calls from this line will be blocked.

It is possible to use route patterns instead of translation patterns to block calls within the line calling search space. To configure a blocked route pattern, first create a "dummy" gateway with an unused IP address and place it into a "dummy" route list and route group construct. Then point the route pattern to the dummy route list. The main difference between using a route pattern and a translation pattern to block calls is the end-user experience when trying to dial a blocked number, as follows:

When using a translation pattern, the end users will be able to dial the entire number and only then will they hear a fast-busy tone.

When using a route pattern, the end users will hear a fast-busy tone as soon as the number they are dialing can no longer match any allowed pattern.

Follow these guidelines to implement the line/device approach in a multisite deployment with centralized call processing:

Create an unrestricted calling search space for each site and assign it to the phone's device calling search space. This calling search space should contain a partition featuring route patterns that route the calls to the appropriate gateway for the phone's location (for example, a co-located branch gateway for emergency services and a centralized gateway for long-distance calls).

Create calling search spaces containing partitions featuring blocked translation/route patterns for those types of calls not part of the user's dialing privileges, and assign them to the user's lines. For instance, if a user has access to all types of calls except international, that user's line (or lines) should be configured with a calling search space that blocks the 9.011! route pattern.

Figure 10-32 shows an example of how these guidelines can apply to a multisite deployment with N sites.

Figure 10-32 Calling Search Spaces and Partitions Needed with the Line/Device Approach

This approach has the significant advantage that only a single site-specific, unrestricted calling search space is required for each site (that is, one per branch). Because the dialing privileges are implemented through the use of blocked route patterns (which are not site-dependent), the same set of blocking calling search spaces can be used in all branches.

Consequently, you can use the following formulas to calculate the total number of calling search spaces and partitions needed:

Total Partitions = (Number of classes of service) + (Number of sites) + (1 Partition for all IP phone DNs)

Total Calling Search Spaces = (Number of classes of service) + (Number of sites)


Note These values represent the minimum numbers of partitions and calling search spaces required. You may need additional partitions and calling search spaces for special devices and applications, as well as for on-net patterns for other call processing agents.



Note If Cisco Emergency Responder is used, the 911 CTI route pattern and 9.911 translation pattern can be placed in the global On-Cluster partition.


When applied to centralized call processing deployments with large numbers of sites, the line/device approach drastically reduces the number of partitions and calling search spaces needed. For example, a deployment with 100 remote sites and 4 classes of service requires at least 401 partitions and 400 calling search spaces with the traditional approach but only 105 partitions and 104 calling search spaces with the line/device approach.

However, the line/device approach relies on the fact that you can globally identify the types of PSTN calls that must be restricted for certain classes of service (for example, local, long-distance, and international calls). If the national numbering plan of your country does not allow this global identification of the different types of calls, the efficiency of this approach (in terms of configuration savings) is lower than that indicated in the formulas above.

For example, in France the numbering plan is based on five area codes, from 01 to 05 (plus the 06 area code for cellular phones), followed by eight digits for the subscriber number. The key characteristic is that each PSTN destination is reached by dialing exactly the same number (for example, 01XXXXXXXX for Paris numbers, 04XXXXXXXX for Nice numbers, and so on), whether calling from the same local area or from a different area. This means that it is not possible to block access to long-distance calls with a single partition and a single route pattern because the concept of "long-distance call" changes depending on the area where the calling party is located. (For example, a call to 014455667788 is a local call if the caller is in Paris but a long-distance call is the caller is in Nice or Lyon.)

In such cases, you will have to configure additional sets of blocking calling search spaces and partitions, one for each area within which local and long distance calls are dialed the same way. In the example of France, you would have to defining five additional blocking calling search spaces and partitions, one for each area code, as shown in Table 10-8:

 

Table 10-8 The Line/Device Approach Applied to the French National Numbering Plan 

Calling Search Space
Partition
Blocked Route Patterns

Internal_css

BlockAllNational_pt

0.0[1-6]XXXXXXXX

BlockIntl_pt

0.00!, 0.00!#

Local01_css

BlockLD01_pt

0.0[2-6]XXXXXXXX

BlockIntl_pt

0.00!, 0.00!#

Local02_css

BlockLD02_pt

0.0[13-6]XXXXXXXX

BlockIntl_pt

0.00!, 0.00!#

Local03_css

BlockLD03_pt

0.0[124-6]XXXXXXXX

BlockIntl_pt

0.00!, 0.00!#

Local04_css

BlockLD04_pt

0.0[1-356]XXXXXXXX

BlockIntl_pt

0.00!, 0.00!#

Local05_css

BlockLD05_pt

0.0[1-46]XXXXXXXX

BlockIntl_pt

0.00!, 0.00!#

LD_css

BlockIntl_pt

0.00!, 0.00!#

Intl_css

NoBlock_pt

none


Guidelines for the Line/Device Approach

Consider the following guidelines when using the line/device approach:

The Forward Busy and Forward No Answer calling search spaces are not concatenated with the line or device calling search space.

Set the Forward Busy and Forward No Answer calling search spaces to a global calling search space that can reach the voicemail pilot number and ports.

Set the Forward All calling search space(s) according to your company's policy:

If forwarded calls must have unrestricted privileges, set the Forward All calling search space to match the site-specific device calling search space. (For additional considerations with Extension Mobility, see Extension Mobility Considerations for the Line/Device Approach.)

If forwarded calls must be restricted to internal numbers only, set the Forward All calling search space to a global calling search space that can reach only internal numbers.

If forwarded calls must have some intermediate restriction (such as access to local PSTN numbers but not international numbers), the line/device approach might become less efficient because additional site-specific calling search spaces would be required. As a result, the total quantity of configured calling search spaces in this case would be similar to that of the traditional approach described above.

Remember that, for this approach to work, the blocked patterns configured within the line calling search space must be at least as specific as the route patterns configured within the device calling search space. Wherever possible, Cisco recommends that you configure the blocked patterns as more specific than the routed ones, to avoid any possibility of error. Use extra care when dealing with the @ wildcard because the patterns defined within it are very specific.

AAR is triggered when on-net DNs are dialed. Access to these DNs can be controlled by the same processes described previously. AAR uses a different calling search space for rerouted calls. In most cases, the AAR calling search space can be the same as the site-specific, unrestricted device calling search space because it can never be dialed directly by end users.


Note The priority order between line and device is reversed for CTI devices (CTI route points and CTI ports). For these devices, the partitions in the device calling search space are placed before the line calling search space in the resulting calling search space. Therefore, the line/device approach cannot be applied to CTI devices such as Cisco IP SoftPhone unless you are careful not to rely solely on the concatenation order for pattern selection but instead ensure that the desired blocked pattern's precision is greater in all cases than that of the permitted pattern(s).


Extension Mobility Considerations for the Line/Device Approach

When using the Extension Mobility feature, the line/device approach provides a natural way to implement the dialing restrictions of a phone as a function of the logged-in (or logged-out) status of the phone. Typically, a logged-out phone should be restricted to calling other phones and services (such as 911), but access to local or toll calls through the PSTN are restricted. Conversely, a phone where a user is logged-in should allow calls according to that user's dialing privileges and should route those calls to the appropriate gateway (for example, a co-located branch gateway for local calls).

With the line/device approach for building classes of service, you can simply apply the same rules described in the previous section to the Extension Mobility device profile construct. Consider the following guidelines to apply calling restrictions when using Extension Mobility:

At each site, configure the device calling search space for all IP phones to point to a site-specific partition that contains all possible PSTN route patterns and that routes them appropriately (for example, using the local gateway for emergency and local calls and a centralized gateway for long distance calls).

Configure the line calling search space for all IP phones (or the line calling search space for the default logout device profile) to point to a global calling search space featuring blocked translation/route patterns that block all calls except those to be allowed when no user is logged in (for example, internal extensions and emergency services).

For each Extension Mobility user, configure the line calling search space within the device profile to point to a global calling search space featuring blocked translation/route patterns to selectively block the PSTN calls that are not to be allowed for their specific class of service (for example, block only international calls). If some users must have unrestricted calling privileges, assign them to a line calling search space featuring an empty partition.

The key advantage of using the line/device approach for extension mobility is that, in a multisite deployment with centralized call processing, appropriate call routing is ensured even when users log in to IP phones located at branch sites different from their home site, as illustrated in Figure 10-33.

Figure 10-33 Extension Mobility with the Line/Device Approach

As described previously in this chapter, the line calling search space configured within the device profile replaces the line calling search space configured on the physical IP phone when a user logs in through Extension Mobility. Because the call routing is correctly determined by the device calling search space, the login operation is used merely to "unlock" the phone by removing the phone's line calling search space (which contains blocked patterns) and replacing it with the device profile's line calling search space (which does not contain blocked patterns in this simplified example).

Because all the call routing is done within the device calling search space while the line calling search space only introduces blocked patterns, whenever a user logs in at a different site from their home site, they will automatically inherit all the local dialing habits for that site. For example, assume that phone DNs are defined as eight-digit numbers, but four-digit dialing is provided within each site by local translation patterns. In this case, a user roaming to a different site will not be able to dial a colleague at the home site by using only four digits because the four-digit number will now be translated according to the rules of the host site where the user logged in.

In summary, when you use the line/device approach for Extension Mobility, end-users have to adopt the dialing behavior of the site where they logged in.

Call Forwarding Considerations

When applying the Line/Device calling search space approach to a centralized call processing environment with Extension Mobility, you should be aware of the call forwarding behavior if users need to be allowed to forward all their calls to external PSTN numbers.

In Figure 10-34, an Extension Mobility user is normally based in Site 1, with a device profile allows the user to place unrestricted PSTN calls and to forward all incoming calls to any PSTN number.

Figure 10-34 Call Forwarding Considerations for Extension Mobility with the Line/Device Approach

As described in the section on Call-Forward Calling Search Spaces, the Forward All calling search space is not concatenated with the line or the device calling search spaces and therefore needs to be set to Site1_all, which includes all PSTN routes using the Site 1 gateway.

When this user moves to Site 2 and logs into phone D, the user's device profile applies its line calling search space and Forward All calling search space(s) to the physical device. For direct PSTN calls, the calling search space used is the concatenation of the line and device calling search space, and phone D's device calling search space (Site2_all) correctly points to the Site 2 gateway.

If the user now configures the phone to forward all calls to a PSTN number, any forwarded call will use the Site1_all calling search space, which still points to the Site 1 gateway. This condition results in the following behavior:

Incoming PSTN calls enter the IP network at the Site 1 gateway and are hairpinned back into the PSTN within the same gateway.

Calls originating from Site 1 phones (such as phone A) are correctly forwarded to the PSTN via the Site 1 gateway.

Calls originating from Site 2 phones (such as phone C) traverse the WAN to Site 1 and access the PSTN via the Site 1 gateway. The same behavior applies to calls originating from other sites within the same Cisco Unified CallManager cluster.

Keep this behavior in mind when designing the network and training the users.

Building Classes of Service in Cisco IOS with H.323

The following scenarios require you to define classes of service within Cisco IOS routers running the H.323 protocol:

Cisco Unified CallManager multisite deployments with centralized call processing

Cisco Unified CallManager Express deployments

Under normal conditions in Cisco Unified CallManager multisite deployments with centralized call processing, classes of service are implemented using partitions and calling search spaces within Cisco Unified CallManager. However, when IP WAN connectivity is lost between a branch site and the central site, Cisco SRST takes control of the branch IP phones, and all the configuration related to partitions and calling search spaces is unavailable until IP WAN connectivity is restored. Therefore, it is desirable to implement classes of service within the branch router when running in SRST mode.

Similarly, in Cisco Unified CallManager Express deployments, the router needs a mechanism to implement classes of service for the IP phones.

For both of these applications, define classes of service in Cisco IOS routers by using the class of restriction (COR) functionality (refer toCalling Privileges in Cisco IOS with H.323 Dial Peers, for details on COR).

You can adapt the COR functionality to replicate the Cisco Unified CallManager concepts of partitions and calling search spaces by following these main guidelines:

Define tags for each type of call that you want to distinguish.

Assign "basic" outgoing corlists (equivalent to partitions), containing a single member tag, to the respective POTS dial peers that route each type of call.

Assign "complex" incoming corlists (equivalent to calling search spaces), containing subsets of the member tags, to the IP phones that belong to the various classes of service.

Figure 10-35 illustrates an implementation example based on SRST, where the IP phone with DN 2002 is configured to have unrestricted PSTN access, the IP phone with DN 2001 is configured to have only local PSTN access, and all other IP phones are configured to have access only to internal numbers and emergency services.

Figure 10-35 Building Classes of Service for Cisco SRST using COR

The following steps provide examples and guidelines for implementing a Cisco IOS solution like the one shown in Figure 10-35.


Step 1 Using the dial-peer cor custom command, define meaningful tags for the various types of calls (Emergency, VMail, Local, LD, Intl):

dial-peer cor custom
  name Emergency
  name VMail
  name Local
  name LD
  name Intl

Step 2 Using the dial-peer cor list command, define basic corlists to be used as partitions, each containing a single tag as a member:

dial-peer cor list EmPt
  member Emergency

dial-peer cor list VMailPt
  member VMail

dial-peer cor list LocalPt
  member Local

dial-peer cor list LDPt
  member LD

dial-peer cor list IntlPt
  member Intl

Step 3 Using the dial-peer cor list command, define more complex corlists to be used as calling search spaces, each containing a subset of the tags as members according to the classes of service needed:

dial-peer cor list InternalCSS
  member Emergency
  member VMail

dial-peer cor list LocalCSS
  member Emergency
  member VMail
  member Local

dial-peer cor list LDCSS
  member Emergency
  member VMail
  member Local
  member LD

dial-peer cor list IntlCSS
  member Emergency
  member VMail
  member Local
  member LD
  member Intl

Step 4 Using the command corlist outgoing corlist-name, configure the basic "partition" corlists as outgoing corlists assigned to the corresponding POTS dial peers:

dial-peer voice 100 pots
  corlist outgoing EmPt
  destination-pattern 911
  no digit-strip
  direct-inward-dial
  port 1/0:23

dial-peer voice 101 pots
  corlist outgoing VMailPt
  destination-pattern 914085551234
  forward-digits 11
  direct-inward-dial
  port 1/0:23

dial-peer voice 102 pots
  corlist outgoing LocalPt
  destination-pattern 9[2-9]......
  forward-digits 7
  direct-inward-dial
  port 1/0:23

dial-peer voice 103 pots
  corlist outgoing LDPt
  destination-pattern 91[2-9]..[2-9]......
  forward-digits 11
  direct-inward-dial
  port 1/0:23

dial-peer voice 104 pots
  corlist outgoing IntlPt
  destination-pattern 9011T
  prefix-digits 011
  direct-inward-dial
  port 1/0:23

Step 5 Using the cor incoming command within the call-manager-fallback configuration mode, configure the complex corlists acting as "calling search spaces" to be incoming corlists assigned to the various phone DNs:

call-manager-fallback
  cor incoming InternalCSS default
  cor incoming LocalCSS 1 3001 - 3003
  cor incoming LDCSS 2 3004
  cor incoming IntlCSS 3 3010


When deploying COR for SRST, keep in mind the following limitations:

In SRST version 2.0, available on Cisco IOS Release 12.2(8)T or later, the maximum number of cor incoming statements allowed under call-manager-fallback is 5 (plus the default statement).

In SRST version 3.0, available on Cisco IOS Release 12.3(4)T or later, the maximum number of cor incoming statements allowed under call-manager-fallback is 20 (plus the default statement).

Therefore, if the phone DNs of users with non-default privileges are not consecutive and the SRST site is relatively large, you might have to reduce the number of classes of service in SRST mode to accommodate all the DNs without exceeding these limitations.

Although the preceding example is based on Cisco SRST, the same concepts can be applied to a Cisco Unified CallManager Express deployment, except for the following considerations:

With Cisco Unified CallManager Express, the corlist expressing the class of service (equivalent to a calling search space) can be assigned directly to the individual IP phones by using the cor {incoming | outgoing} corlist-name command under the ephone-dn dn-tag configuration mode.

According to COR general rules, all IP phones for which no corlist is configured have unrestricted access to all dial peers, regardless of their outgoing corlist. Cisco Unified CallManager Express has no mechanism equivalent to the cor incoming corlist-name default command, which applies default restrictions to all phones.

Deploying Call Coverage

Call coverage functionality is a key feature in many IP telephony deployments. Many customer-focused service companies have to route customer calls to the appropriate service representatives expeditiously. This section focuses on design guidelines for using the hunting mechanism based on hunt pilots, hunt lists, and line groups in Cisco Unified CallManager Release 4.1 to manage call distribution, and it covers the following main topics:

Deploying Call Coverage in a Multisite Centralized Call Processing Model

Deploying Call Coverage in a Multisite Distributed Call Processing Model


Note Call coverage functionality does not offer call queues per se, and the caller is presented with ringback tone until a destination is found for the call. To provide prompting, music on hold, and so forth, Cisco offers many contact center technologies such as the Cisco Unified Customer Voice Portal (CVP). For more information on the contact center technologies available from Cisco, refer to the documentation at http://www.cisco.com/go/designzone.


Deploying Call Coverage in a Multisite Centralized Call Processing Model

Figure 10-36 shows an example of configuring hunt lists for a multisite centralized call processing deployment. This example assumes that the hunt pilot call will be distributed first through the remote office operators. If the call is not answered or is rejected due to call admission control, the call will then be routed to central-site operators or voicemail.

Figure 10-36 Call Coverage Between Multiple Sites in a Centralized Call Processing Deployment

In centralized IP telephony systems, features such as Automated Alternate Routing (AAR) and Survivable Remote Site Telephony (SRST) may be enabled for high availability. Consider the following guidelines when deploying call coverage functionality with AAR or SRST features enabled:

Automated Alternate Routing (AAR)

The line group members can be assigned in different locations and regions. Call admission control implemented through locations works as expected. However, a call being distributed from a hunt pilot will not use AAR to reroute a call if Cisco Unified CallManager blocks the call to one of its line group members due to insufficient WAN bandwidth. Instead, Cisco Unified CallManager distributes the call to the next available member or next available line group.


Note Calls distributed by a hunt pilot can use AAR in Cisco Unified CallManager Release 4.1(3) and above. However, Cisco strongly recommends that you use AAR only when using voicemail ports within line groups.


Survivable Remote Site Telephony (SRST)

When Cisco Unified CallManager receives a call for the hunt pilot, and if some of its line group members are at the remote sites operating in SRST mode, then Cisco Unified CallManager skips those members and distributes the call to the next available line group member. From the perspective of Cisco Unified CallManager, the members operating in SRST mode are unregistered, and hunt pilot calls are not forwarded to unregistered members.

When a router operating in SRST mode receives a call for the hunt pilot, call coverage functionality is unavailable. The call fails if no configuration is added to reroute the call to a registered and available extension. You can use the alias or the default-destination command under the call-manager-fallback mode in Cisco IOS to reroute the call destined for the hunt pilot to an operator extension or to voicemail.

Deploying Call Coverage in a Multisite Distributed Call Processing Model

Beginning with Cisco Unified CallManager Release 4.1, route groups can no longer be added to hunt lists. Thus, a hunt list cannot be used to send the calls to other clusters or to a remote gateway. But the hunt option settings in Hunt Pilot, introduced in Cisco Unified CallManager Release 4.1, can be used to match a route pattern that in turn points to gateways or trunks.

Figure 10-37 shows an example of configuring hunt lists for a distributed call processing deployment with an intercluster trunk. This example assumes that the hunt pilot call is first distributed within Cluster A. If the call is not answered, it is rerouted to Cluster B for call distribution using the Forward Hunt No Answer setting, which matches a route pattern. The route pattern, in turn, points to an intercluster trunk to Cluster B.

Figure 10-37 Call Coverage Between Clusters in a Distributed Call Processing Deployment


Tip In distributed call processing deployments, load sharing of incoming hunt pilot calls can be managed using Cisco VoIP gateways and gatekeepers. In the event that the call is not answered within one cluster, it can overflow to another cluster for service. Calls can also be sent through gateways or trunks to IVR treatment. Tool Command Language (TCL) IVR applications can be implemented on Cisco IOS gateways.


Guidelines

If calls are distributed across multiple clusters in a distributed call processing deployment, the route patterns should be properly configured to account for any digit transformations that are done on the outbound or inbound route group devices. If digit transformations are not done, then the configured route patterns and hunt pilot should be the same on all clusters, otherwise the calls will not be distributed appropriately.

Hunt Pilot Scalability

Cisco recommends using the following guidelines when deploying call coverage using top-down, circular, and longest-idle algorithms:

The Cisco Unified CallManager cluster supports a maximum of 15,000 hunt list devices.

The hunt list devices may be a combination of 1500 hunt lists with 10 IP phones in each hunt list, or a combination of 750 hunt lists with 20 IP phones in each hunt list. However, an increase in a number of hunt lists can require increasing the dial plan initialization timer specified in the Cisco CallManager service parameters. Cisco recommends setting the dial plan initialization timer to 600 seconds if 1500 hunt lists are configured.


Note When using the broadcast algorithm for call coverage, the number of hunt list devices is limited by the number of busy hour call attempts (BHCA). Note that a BHCA of 10 on a hunt pilot pointing to a hunt list or hunt group containing 10 phones and using the broadcast algorithm is equivalent to 10 phones with a BHCA of 10.


Cisco recommends having a maximum of 35 directory numbers in a single line group configured to send the calls simultaneously to all DNs. Additionally, the number of broadcast line groups depends on the BHCC. If there are multiple broadcast line groups in a Cisco Unified CallManager system, the number of maximum directory numbers in a line group must be less than 35. The number of busy hour call attempts (BHCA) for all the broadcast line groups should not exceed 35 calls set up per second