-
Cisco Unified Communications SRND Based on Cisco Unified CallManager 4.x
-
Preface
-
Introduction
-
IP Telephony Deployment Models
-
Network Infrastructure
-
Gateways
-
Cisco Unified CallManager Trunks
-
Media Resources
-
Music on Hold
-
Call Processing
-
Call Admission Control
-
Dial Plan
-
Emergency Services
-
Third-Party Voicemail Design
-
Cisco Unity
-
Cisco Unity Express
-
Cisco Unified MeetingPlace Integration
-
Cisco Unified MeetingPlace Express
-
IP Video Telephony
-
LDAP Directory Integration
-
IP Telephony Migration Options
-
Voice Security
-
IP Telephony Endpoints
-
Device Mobility
-
Recommended Hardware and Software Combinations
-
Glossary
-
Index
-
Table Of Contents
Avoiding Overlap of Extension Dialing
Variable Length On-Net Dial Plan
On-Net and Off-Net Access Codes
Call Routing in Cisco Unified CallManager
Calling Privileges in Cisco Unified CallManager
Digit Manipulation in Cisco Unified CallManager
Establish the Phone Number of the Destination
Prefix the Required Access Codes
Select the Proper Dial Plan and Route
Special Considerations for Sites Located Within the Same Local Dialing Area
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 Guidelines for Multisite Deployments
Deploying Uniform On-Net Dial Plans
Inter-Site Calls Within a Cluster
Outgoing PSTN and IP WAN Calls
Deploying Variable-Length On-Net Dial Plans with Partitioned Addressing
Inter-Site Calls Within a Cluster
Outgoing PSTN and IP WAN Calls
Deploying Variable-Length On-Net Dial Plans with Flat Addressing
Inter-Site Calls Within a Cluster
Outgoing PSTN and IP WAN 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 in a Multisite Centralized Call Processing Model
Deploying Call Coverage in a Multisite Distributed Call Processing Model
Dial Plan
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)
•
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).
•
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.
•
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.
•
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:
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.)
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.)
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
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:
•
•
•
•
•
•
•
•
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:
•
•
•
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:
•
•
–
–
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:
•
•
•
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.
For the example in Table 10-1, the various sites were assigned numbers in the following ways:
•
•
•
•
•
•
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:
•
•
•
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.
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:
•
•
•
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:
•
•
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:
•
•
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
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:
•
•
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
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 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
•
•
http://www.cisco.com/en/US/products/sw/voicesw/ps5629/prod_maintenance_guides_list.html
•
Route Filters
•
•
•
•
International and Variable-Length Route Patterns
•
•
–
–
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
•
•
•
•
Calling Line ID
•
•
Urgent Priority
•
•
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
•
•
Forced Account Codes (FAC)
•
•
•
•
Client Matter Codes (CMC)
•
•
•
•
•
•
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:
•
•
•
•
•
1.
2.
3.
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:
•
•
•
•
•
•
Note
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:
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
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
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
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
Note
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:
•
•
•
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:
•
When the DN is unregistered, calls can be rerouted to either of the following destinations:
–
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.
–
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).
•
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
Digit Manipulation in Cisco Unified CallManager
The following tools provide digit manipulation capability in Cisco Unified CallManager:
•
•
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
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
You must provide the following main elements for AAR to function properly:
•
•
•
Note
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:
•
Note
•
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:
•
•
•
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.
Note
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
Note
Note
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
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.
•
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.
•
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.
•
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:
•
•
Tip
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
Tip
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
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:
•
•
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:
•
•
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
The following considerations apply to calls handled by hunt pilots:
•
•
•
Hunt List
A hunt list is a prioritized list of eligible paths (line groups) for call coverage. Hunt lists have the following characteristics:
•
•
•
•
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:
•
•
•
•
–
–
–
–
•
–
–
–
–
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
Line Group Devices
The line group devices are the endpoints accessed by line groups, and they can be of any of the following types:
•
•
•
•
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:
•
•
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
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:
•
•
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:
•
•
Figure 10-13 shows the following examples of different types of calls going through a Cisco IOS router:
•
•
•
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.
2.
3.
4.
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:
•
•
By default, dial peers in a hunt group are selected according to the following criteria, in the order listed:
1.
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.
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.
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:
•
dial-peer voice 999 potsincoming called-number .direct-inward-dialport 1/0:23•
dial-peer voice 100 voippreference 1!--- Make this the first choice dial peer.ip precedence 5destination-pattern 1...session target ipv4:10.10.10.2!--- This is the address of the primary Cisco Unified CallManager.dtmf-relay h245-alphadial-peer voice 101 voippreference 2!--- This is the second choice.ip precedence 5destination-pattern 1...session target ipv4:10.10.10.3!--- This is the address of the secondary Cisco Unified CallManager.dtmf-relay h245-alphaCall 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
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:
•
•
•
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:
•
•
•
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
gatekeeperzone local GK-Site1 customer.com 10.1.10.100zone local GK-Site2 customer.comzone prefix GK-Site1 408.......zone prefix GK-Site2 212.......bandwidth interzone GK-Site1 160bandwidth interzone GK-Site2 160gw-type-prefix 1#* default-technologyarq reject-unknown-prefixno shutdownThe following notes also apply to Figure 10-16:
•
•
•
•
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.
•
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
gatekeeperzone local GK-Site1 customer.com 10.1.10.100zone remote GK-Site2 customer.com 10.1.11.100zone prefix GK-Site1 408.......zone prefix GK-Site2 212.......bandwidth remote 160gw-type-prefix 1#* default-technologyarq reject-unknown-prefixno shutdownThe following notes apply to Example 10-2:
•
•
•
•
•
•
Example 10-3 shows the gatekeeper configuration for Site 2 in Figure 10-17.
Example 10-3 Gatekeeper Configuration for Site 2
gatekeeperzone local GK-Site2 customer.com 10.1.11.100zone remote GK-Site1 customer.com 10.1.10.100zone prefix GK-Site2 212.......zone prefix GK-Site1 408.......bandwidth remote 160gw-type-prefix 1#* default-technologyarq reject-unknown-prefixno shutdownThe following notes apply to Example 10-3:
•
•
•
•
•
•
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
gatekeeperzone local GK-Site1 customer.com 10.1.10.100zone remote DGK customer.com 10.1.10.101zone prefix GK-Site1 408.......zone prefix DGK ..........bandwidth remote 160gw-type-prefix 1#* default-technologyarq reject-unknown-prefixno shutdownThe following notes also apply to Example 10-4:
•
•
•
•
•
•
•
Example 10-5 shows the directory gatekeeper configuration for the example in Figure 10-18.
Example 10-5 Directory Gatekeeper Configuration
gatekeeperzone local DGK customer.com 10.1.10.101zone remote GK-Site1 customer.com 10.1.10.100zone remote GK-Site2 customer.com 10.1.11.100zone prefix GK-Site1 408*zone prefix GK-Site2 212*lrq forward-queriesno shutdownThe following notes also apply to Example 10-5:
•
•
•
•
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 no corlist statements are applied to some dial peers, the following properties apply:
•
•
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
Step 2
Step 3
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 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
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:
•
•
•
•
•
Note
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.
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 1rule 1 /^81/ /91408555/rule 2 /^83/ /91212555/rule 3 /^84/ /91972555/voice translation-profile on-net-xlatetranslate called 1call-manager-fallbacktranslation-profile outgoing on-net-xlatedial-peer voice 2 potsdestination-pattern 91[2-9]..[2-9]......port 1/0:0direct-inward-dialforward-digits 11With 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
For a thorough explanation of regular expression syntax in Cisco IOS, refer to the document on Regular Expressions, available at
Design Considerations
This section presents the following dial plan design considerations for multisite deployments:
•
•
•
–
–
–
•
–
–
•
•
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.
•
•
•
•
•
–
–
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.
•
–
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.
–
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.
•
•
Note
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):
•
•
•
•
•
•
•
–
–
–
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:
•
•
To help you decide which approach is best suited for your needs, consider the following high-level design questions:
•
•
•
•
•
•
•
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:
•
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.
•
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:
•
•
•
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 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
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
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
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.
Use this approach if one or more of the following conditions apply:
•
Note
•
•
•
Note
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
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:
•
•
•
•
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
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:
•
•
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
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:
Use this approach if one or more of the following conditions apply:
•
•
•
•
Note
The following considerations apply to this approach:
•
•
•
•
•
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
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
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:
•
•
•
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
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
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:
•
•
•
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:
•
•
•
•
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:
•
•
•
•
•
•
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
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:
•
•
•
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:
•
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.
•
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:
•
•
•
•
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
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:
•
•
•
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:
•
•
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:
•
•
•
Note
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:
•
•
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:
•
•
Follow these guidelines to implement the line/device approach in a multisite deployment with centralized call processing:
•
•
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
Note
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:
Guidelines for the Line/Device Approach
Consider the following guidelines when using the line/device approach:
•
•
•
–
–
–
•
•
Note
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:
•
•
•
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:
•
•
•
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:
•
•
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:
•
•
•
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
dial-peer cor customname Emergencyname VMailname Localname LDname IntlStep 2
dial-peer cor list EmPtmember Emergencydial-peer cor list VMailPtmember VMaildial-peer cor list LocalPtmember Localdial-peer cor list LDPtmember LDdial-peer cor list IntlPtmember IntlStep 3
dial-peer cor list InternalCSSmember Emergencymember VMaildial-peer cor list LocalCSSmember Emergencymember VMailmember Localdial-peer cor list LDCSSmember Emergencymember VMailmember Localmember LDdial-peer cor list IntlCSSmember Emergencymember VMailmember Localmember LDmember IntlStep 4
dial-peer voice 100 potscorlist outgoing EmPtdestination-pattern 911no digit-stripdirect-inward-dialport 1/0:23dial-peer voice 101 potscorlist outgoing VMailPtdestination-pattern 914085551234forward-digits 11direct-inward-dialport 1/0:23dial-peer voice 102 potscorlist outgoing LocalPtdestination-pattern 9[2-9]......forward-digits 7direct-inward-dialport 1/0:23dial-peer voice 103 potscorlist outgoing LDPtdestination-pattern 91[2-9]..[2-9]......forward-digits 11direct-inward-dialport 1/0:23dial-peer voice 104 potscorlist outgoing IntlPtdestination-pattern 9011Tprefix-digits 011direct-inward-dialport 1/0:23Step 5
call-manager-fallbackcor incoming InternalCSS defaultcor incoming LocalCSS 1 3001 - 3003cor incoming LDCSS 2 3004cor incoming IntlCSS 3 3010When deploying COR for SRST, keep in mind the following limitations:
•
•
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:
•
•
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:
•
•
Note
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:
•
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
•
–
–
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
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:
•
•
Note
•
