Dial Plan

CH A P T E R 9
Dial Plan
Revised: July 31, 2012; OL-21733-18
The dial plan is one of the key elements of a Unified Communications system, and an integral part of all
call processing agents. Generally, the dial plan is responsible for instructing the call processing agent on
how to route calls. Specifically, the dial plan performs the following main functions:
• Endpoint addressing
Reachability of internal destinations is provided by assigning directory numbers (DNs) to all
endpoints (such as IP phones, fax machines, and analog phones) and applications (such as voicemail
systems, auto attendants, and conferencing systems)
• Path selection
Depending on the calling device, different paths can be selected to reach the same destination.
Moreover, a secondary path can be used when the primary path is not available (for example, a call
can be transparently rerouted over the PSTN during an IP WAN failure).
• Calling privileges
Different groups of devices can be assigned to different classes of service, by granting or denying
access to certain destinations. For example, lobby phones might be allowed to reach only internal
and local PSTN destinations, while executive phones could have unrestricted PSTN access.
• Digit manipulation
In some cases, it is necessary to manipulate the dialed string before routing the call; for example,
when rerouting over the PSTN a call originally dialed using the on-net access code, or when
expanding an abbreviated code (such as 0 for the operator) to an extension. Digit manipulation is
also used to adapt the local dialing habits of a user to the global routes used to select a path for a
call. For example, a French user may dial 0 00 1 212 555 1234 to call a number in New York. That
same number is reachable to a caller in Chicago by dialing 9 1 212 555 1234. Both localized user
inputs can be translated to a global form of +1 212 555 1234, so that a single route is used to select
a path for the call.
• Call coverage
Special groups of devices can be created to handle incoming calls for a certain service according to
different rules (top-down, circular hunt, longest idle, or broadcast). The dial plan information
covered in this chapter applies to any Unified Communications deployment model; in particular,
when deploying multi-site systems, the system designer should pay close attention to the
site-specific dialing habits as well as site-specific routing of calls, such as the use of a gateway
co-located with a specific group of users.
Cisco Unified Communications System 8.x SRND

OL-21733-18 9-1
Chapter 9 Dial Plan
What's New in This Chapter
This chapter presents information intended to guide the system designer toward a dial plan that
accommodates the legacy dialing habits of telephony users, while also taking advantage of new
functionality afforded by the increasing integration between computing technology and telephony, such
as dialing from contacts, click-to-call actions from computers and smart phones, and adoption of
mobility-related features. The chapter is structured to offer information of the following main areas:
• Planning Considerations, page 9-5
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.)
• Design Considerations, page 9-11
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 Communications Manager and
Cisco IOS is recommended.)
• Dial Plan Elements, page 9-78
This section provides detailed background 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 Communications Manager and Cisco IOS is recommended.) This section does not
supersede product-specific documentation, nor does it present all the information available in the
Cisco Unified Communications Manager help files. It does highlight some fundamental
functionality elements essential to the understanding of design-related concepts presented herein.
For more details, refer to the Cisco Unified Communications Manager System Guide, the Cisco IOS
Voice, Video, and Fax Configuration Guide, Release 12.2, and other product documentation available at
http://www.cisco.com
What's New in This Chapter

Table 9-1 lists the topics that are new in this chapter or that have changed significantly from previous
releases of this document.
Table 9-1 New or Changed Information Since the Previous Release of This Document
New or Revised Topic Described in Revision Date

Calling party number globalization Phone Calling Party Number Globalization, July 31, 2012
page 9-17
Calling party number in missed and received calls Phone Calling Party Number Localization, July 31, 2012
directories on Type-A phones page 9-20
Class of service in +E.164 dial plans Building Classes of Service for Unified CM for July 31, 2012
+E.164 Dial Plans with the Traditional Approach
and Local Route Group, page 9-66
Routing SIP requests Routing of SIP Requests in Unified CM, July 31, 2012
page 9-100
Various other minor updates Numerous sections throughout this chapter July 31, 2012
+ dialing Support for + Dialing on the Phones, page 9-80 February 28, 2011

9-2 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Architecture
Table 9-1 New or Changed Information Since the Previous Release of This Document (continued)
New or Revised Topic Described in Revision Date

Cisco Business Edition 3000 Dial Plan Considerations for Business February 28, 2011
Edition 3000, page 9-146
Intercompany Media Engine (IME) Dial Plan Considerations for the Intercompany April 2, 2010
Media Engine, page 9-33
Service Advertisement Framework (SAF) Call Call Control Discovery, page 9-24 April 2, 2010
Control Discovery (CCD)
Service Advertisement Framework (SAF) Call
Control Discovery (CCD), page 9-144
Dial Plan Architecture

Figure 9-1 illustrates the fundamental architecture of dial plans based on Cisco Unified Communications
Manager (Unified CM).
Figure 9-1 Basic Dial Plan Architecture
Digit analysis: Call routing:

What can be dialed, What path will be
by whom, and in chosen to take a call
what form. to its destination. 253918
The digit analysis function controls which calls are allowed to a user, to a gateway, or to an application.
This function is where call privileges (also known as classes of service) are implemented. The following
fundamental constructs are used to implement digit analysis:
• Patterns (such as directory number patterns and translation patterns)
Patterns are numerical representations of telephone numbers which, when matched, trigger call
routing.
• Partitions
Partitions are used to separate patterns into logical groups. For instance, partitions allow the
provisioning of two separate extensions set to 1000.
• Calling search spaces
Calling search spaces allow control over what groups of patterns a device (such as a phone) can
access. For instance, devices at one site can be given access to the local partition containing
extension 1000, without having access to a different site's extension 1000.
The call routing function controls the path selection for a call. This function is where IP trunks, PSTN
trunks, or even connections to legacy PBXs, are chosen to carry a particular call. The call routing
function also allows for the automated failover of calls from, for example, an IP connection as a first
choice to a PSTN connection as a backup choice, in case the first choice is not available because no
bandwidth is available or because a particular portion of the network is not available.

OL-21733-18 9-3
Chapter 9 Dial Plan
High Availability for Dial Plans
For both of these functions, Unified CM offers the system designer many tools with which digit
manipulation can be effected and with which control over the call processing can be performed for
different situations. For example, the system administrator can configure the types of calls allowed from
a phone when it is roaming between different sites, how a call is processed when the phone is busy or
when it rings with no answer, or which destinations a phone can use when call-forwarding all calls.
The fundamental elements of the individual features of this architecture are presented in multiple
documents. The product-specific documentation, along with the help files in Unified CM, offer the most
fundamental descriptions of the features. The section on Dial Plan Elements, page 9-78, in this chapter
offers the next level of functionality description. The section on Design Considerations, page 9-11 in this
document offers the system designer top-down architectural information to be considered when
designing a dial plan.
High Availability for Dial Plans

In Cisco Unified CM, dial plan functionality is inherently made available by the clustering capabilities
of Unified CM servers. All dial plan configuration is made redundant by the same mechanisms that allow
other Unified CM services to be redundant. Specifically, Unified Communications Manager groups are
used to control phones, route lists, and gateways, so that a single failure of a Unified CM server does not
render any dial plan function unavailable.
For call paths relying on external trunks, an additional level of availability is afforded by the use of
alternate routes. For instance, a route list can be used to establish a primary path to a given off-cluster
destination, followed by a secondary or even a tertiary choice. If the higher-order choice (such as an IP
trunk) is not available, the next order choice will be attempted, until either the call is established
successfully or all preconfigured choices have been exhausted.
For calls between on-cluster endpoints, such as calls between two IP phones, if the IP path is not
available due to a network failure, the Call Forward Unregistered feature is invoked, allowing the routing
of the call through an alternate network such as the PSTN. If the IP path is not available due to lack of
bandwidth on the network, the Automated Alternate Routing (AAR) feature is invoked to route the call
through an alternate network.
External dial plan resolution subsystems such as H.323 gatekeepers or SIP proxies should also be
provisioned with applicable redundancy capabilities, to offer yet another level of high availability.
Capacity Planning for Dial Plans

The configuration of dial plans is typically not onerous on the Unified CM configuration when compared
to other capacity-affecting aspects such as the number of gateways, the number of CTI connections, or
the rate of call attempts (BHCA). The Cisco Unified Communications Sizing Tool does incorporate dial
plan information in its calculations for system provisioning. This tool is available to Cisco employees
and partners, with proper login authentication, at http://tools.cisco.com/cucst.

9-4 OL-21733-18
Chapter 9 Dial Plan
Planning Considerations
The dial plan is the most fundamental attribute of a telephony system. It is at the very core of the user
experience because it defines the rules that govern how a user reaches any destination. These rules
include:
• Extension dialing — how many digits must be dialed to reach an extension on the system
• Extension addressing — how many digits are used to identify extensions
• Dialing privileges — allowing or not allowing certain types of calls
• Path selection — for example, using the IP network for on-net calls, or using one carrier for local
PSTN calls and another for international calls
• Automated selection of alternate paths in case of network congestion — for example, using the local
carrier for international calls if the preferred international carrier cannot handle the call
• Blocking of certain numbers— for example, pay-per-minute calls
• Transformation of the called number — for example, retaining only the last five digits of a call
dialed as a ten-digit number
• Transformation of the calling number — for example, replacing a caller's extension with the office’s
main number when calling the PSTN
A dial plan suitable for an IP telephony system is not fundamentally different from a dial plan designed
for a traditional TDM telephony system; however, an IP-based system presents the dial plan architect
with some new possibilities. For example, because of the flexibility of IP-based technology, telephony
users in separate sites who used to be served by different, independent TDM systems can now be
included in one, unified IP-based system. These new possibilities afforded by IP-based systems require
some rethinking of the way we look at dial plans. This section examines some of the elements that the
system planner must consider to properly establish the requirements that drive the design of the dial plan.
Dialed Pattern Recognition

Digit strings dialed by a user on a telephone generally follow patterns. For instance, many enterprises
implement a five-digit abbreviated dialing pattern for calls made within the same office location. Also,
many enterprises rely on a single-digit access code to represent outside dialing, followed by some
quantity of digits to reach a local PSTN number or a long-distance PSTN number (for example, 9
followed by seven digits to reach a local number, or 9 followed by 1 and ten digits to reach a
long-distance destination).
The system administrator must plan the system's recognition of these patterns to ensure that the system
will act promptly upon detection of a string that corresponds to a predetermined pattern so that users
experience no (or minimal) post-dialing delay.
For phones using the Skinny Client Control Protocol (SCCP) and for SIP phones using the Key Press
Markup Language (KPML) during dialing, you can implement pattern recognition in Cisco Unified
Communications Manager (Unified CM) 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 Unified CM,
which performs the incremental work of recognizing a matching pattern. As each key press from the user
input is collected, Unified CM's digit analysis provides appropriate user feedback, such as:
• Playing dial tone when the phone first goes off-hook
• Stopping dial tone once a digit has been dialed

OL-21733-18 9-5
Chapter 9 Dial Plan
• Providing secondary dial tone if an appropriate sequence of digits has been dialed, such as when the
off-net access code 9 is dialed
Once digit dialing is completed, Unified CM 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.
IP phones running the Session Initiation Protocol (SIP) can be configured with pattern recognition
instructions called SIP dial rules. When used, they accomplish the bulk of the task of pattern recognition
within the phone. Once a pattern is recognized, the SIP phone sends an invitation to Unified CM to place
a call to the number corresponding to the user's input. That action, called a SIP INVITE, is subjected to
the Unified CM dial plan in the same way a call from an IP phone running the SCCP protocol would be,
except that Unified CM's digit analysis is presented with a completed dial string (that is, all of the digits
entered by the user are presented as a block to Unified CM for processing). In this mode of operation,
user feedback during the dialing of the digit string is limited to what the phone can provide (see SIP Dial
Rules, page 9-84). Once the string has been composed, user feedback can still be provided by
Unified CM in the form of call progress tones.
Grouping by Dialing Habits

Most telephony users are used to dialing telephone numbers according to local habits. These are
composed of various dialing rules applicable to calls placed to destinations within an office location
(intra-site calls), destinations within a company but between different sites (inter-site calls), and
destinations outside the company (off-net calls). The form used in dialing these different types of calls
varies according to user preferences and local PSTN dialing requirements.
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.

9-6 OL-21733-18
Chapter 9 Dial Plan
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.
Dialing can typically be separated into four types:
• Intra-site, on-net abbreviated dialing
Many systems accommodate four- or five-digit dialing within a site. For example, Cisco employees
located in San Jose, California can call the main Cisco reception number using the five-digit string
64000.
• Inter-site, abbreviated on-net dialing
For example, Cisco employees at any Cisco office can dial the San Jose reception number as 8 526
4000. The digit 8 serves as the inter-site access code, and 52 serves as the site code for San Jose.
This form is shorter than the alternative of using an off-net form to route the calls on-net (for
example, allowing Cisco employees in Canada to reach the Cisco reception in San Jose by dialing 9
1 408 526 4000 while routing the call on-net). Even though the dialing form is similar to that used
to reach an off-net destination, the system is configured to keep calls to on-net destinations dialed
in the off-net form within the system.
• Inter-site, off-net dialing
Routing of calls between sites can be handed off to the PSTN. For example, calls made from one
site in San Francisco to another site in New York can be dialed either in the on-net or off-net form
described above, but routed off-net through the PSTN.
• Off-net dialing
For calls where the destination is off-net and outside of the company's dial plan, the Unified
Communications system must offer a simple, locally significant dialing form to the users.
Avoiding Overlap of Extension Dialing

A telephony system must be configured so that any extension can be reached in an unambiguous manner.
To accomplish this goal, the dial plan must satisfy the following requirements:
• All on-net extension dialing must be globally unique. For instance, in a system using an abbreviated
four-digit on-net dial plan, there cannot be an extension 1000 in site A and another extension 1000
in site B if the requirement is to reach either of them by dialing only four digits from site C.
• There cannot be any partial overlap between different dial strings.
– For instance, if 9 is used as an off-net access code in a four-digit abbreviated dial plan (for
example, to make PSTN calls), there cannot be any extensions in the 9XXX range. Attempting
to do so would create situations where calls are not routed immediately. For example, if a user
dialed 9141, the system would have to wait for either more digits (if the user were dialing 9 1
415 555 1234, for example) or the expiration of the interdigit timeout before routing the call to
extension 9141. Likewise, if an operator code is used (for example, 0), the entire 0XXX
extension range would have to be excluded from a four-digit uniform dial plan.
– There cannot be overlapping strings of different length. For example, a system with extensions
1000 and 10000 would force users to wait for the interdigit timeout when they dial 1000.

OL-21733-18 9-7
Chapter 9 Dial Plan
Dialing String Length

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

A dial plan can be designed so that all extensions within the system are reached in a uniform way; that
is, a fixed quantity of digits is used to reach a given extension from any on-net origination point. Uniform
dialing is desirable because of the simplicity it presents to users. A user does not have to remember
different ways to dial a number when calling from various on-net locations.
For example, if phone A is reached by dialing 1234 from any on-net location, whether the calling phone
is in the same office or at a different site, the enterprise's dial plan is deemed uniform.
When the enterprise consists of few sites, this approach can be used with few complications. The larger
the enterprise, in terms of number of extensions and sites, the more of the following challenges it faces
in designing a uniform dial plan:
• The number of extensions can exceed the range afforded by the quantity of digits being considered
for the dial plan. For instance, if more than 8000 extensions are required (considering the exclusions
of the 0XXX and 9XXX ranges), the system may require that an abbreviated dial plan use more than
four digits.
• Matching on-net abbreviated extensions to DID numbers means that, when a new DID range is
obtained from a local exchange carrier, it cannot conflict with the pre-existing on-net abbreviated
dial ranges. For example, if the DID range of 415 555 1XXX exists in a system using a four-digit
uniform abbreviated dial plan, and DID range 650 556 1XXX is also being considered, it might be
desirable to increase the quantity of digits for on-net dialing to five. In this example, the five-digit
on-net ranges 51XXX and 61XXX would not overlap.
• Most systems require the exclusion of certain ranges due to off-net access codes and operator
dialing. In such a system where 9 and 0 are reserved codes, no dial plan (uniform or not) could
accommodate on-net extension dialing that begins with 9 or 0. This means that DID ranges could
not be used if they would force the use of 9 or 0 as the first digit in the dial plan. For instance, in a
five-digit abbreviated dial plan, the DID range 415 559 XXXX (or any subset thereof) could not be
used. In this example, alternatives include increasing the length of the abbreviated dialing to six or
more digits, or avoiding any DID range whose last five digits start with 9, or even not requiring that
the DID numbers match the on-net abbreviated extensions.
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 9-2 exemplifies the distribution of the dialing space for a typical
four-digit uniform dial plan.

9-8 OL-21733-18
Chapter 9 Dial Plan
Table 9-2 Distribution of Digits in a Typical Four-Digit Uniform Dial Plan
Range Use DID Ranges Non-DID Ranges

0XXX Excluded; 0 is used as
off-net access code
1XXX Site A extensions 418 555 1XXX N/A
2XXX Site B extensions 919 555 2XXX N/A
3XXX Site C extensions 415 555 30XX 3[1-9]XX
4[0-4]XX Site D extensions 613 555 4[0-4]XX N/A
4[5-9]XX Site E extensions 450 555 4[5-9]XX N/A
5XXX Site A extensions 418 555 5XXX N/A
6XXX Site F extensions 514 555 6[0-8]XX 69XX
7XXX Future XXX XXX 7XXX 7XXX
8XXX Future XXX XXX 8XXX 8XXX
9XXX Excluded; 9 is used as
off-net access code
For the example in Table 9-2, the various sites were assigned numbers in the following ways:
• Site A, the company headquarters, requires more than 1000 extensions, so two entire ranges of
numbers have been retained (1XXX and 5XXX). Note that the corresponding DID ranges must also
be retained from the site's local exchange carrier.
• Site B has been assigned an entire range (2XXX), allowing for up to 1000 extensions.
• Site C was also assigned an entire range, but it has been split between 100 DID extensions (415 555
30XX) and up to 900 non-DID extensions. If growth requires more extensions for DID, any
unassigned numbers from the non-DID range could be used.
• Sites D and E were each assigned 500 numbers from the 4XXX range. Note that their corresponding
DID ranges must match each of the site's respective portions of the 4XXX range. Because the DID
ranges are for different sites (probably from different PSTN service providers), more coordination
effort is required to split ranges between sites. As the quantity of sites assigned within a given range
increases, it becomes increasingly difficult (sometimes impossible) to make full use of an entire
range.
• Site F's range is split between 900 DID numbers (6[0-8]XX) and 100 non-DID numbers (69XX).
• The ranges 7XXX and 8XXX are reserved for future use.
When implementing a new dial plan, one of the main desires of any planner is to avoid having to change
phone numbers. In addition, the extension ranges of any existing phone systems may have overlapped
without any problems in the past, but they could be incompatible with a uniform dial plan.

OL-21733-18 9-9
Chapter 9 Dial Plan
Variable Length On-Net Dial Plan

Systems with many sites or overlapping site extension ranges can benefit from the use of a
variable-length dial plan with the following characteristics:
• Within a site, the system retains the use of abbreviated dialing for calls to on-net extensions (for
example, four-digit dialing).
• Between sites, users dial an access code followed by a site code and the destination's on-net
extension.
• Off-net calls require an access code followed by a PSTN number.
The use of access and site codes (see Table 9-3) enables the on-net dial plan to differentiate between
extensions that would overlap if a uniform abbreviated dial plan were implemented.
Table 9-3 Typical Use of Site Codes
Site Code Range Use DID Ranges Non-DID Ranges

1 1XXX Site A extensions 418 555 10XX 1[1-9]XX
2 1XXX Site B extensions 919 555 1XXX N/A
3 1XXX Site C extensions 907 555 1XXX N/A
In Table 9-3, sites A, B, and C are independently assigned the four-digit range 1XXX. For calls from site
A to site B under the old telephony system, the calls had to be routed as off-net calls. With the new
system, these calls can be dialed as on-net calls.
From site A, users simply dial 1234 to reach extension 1234. But from site B, the dial plan must
accommodate the ability to reach extension 1234 at site A without conflicting with site B's own
extension 1234. Therefore, each site is assigned a site code.
From site B, merely dialing the combination of site A's code with the desired extension is not feasible:
in this case because 11234 would partially overlap with site B's extension 1123, thus causing interdigit
timeout issues. If, instead, we assign 8 as an inter-site on-net access code, this would allow site B to dial
81234 to reach site A's extension 1234.
The following factors determine the quantity of digits required to dial an on-net, off-site extension:
• One digit for the inter-site access code
• N digits for the site code, where N is chosen to satisfy the quantity of site codes required (For
example, if a system has 13 sites, then a minimum of two digits are required for the site code.)
• The quantity of digits required by the destination site's local dial plan
For example, a system with 75 sites which each use four-digit abbreviated dialing would require a format
of 8 + SS + XXXX, where 8 is the on-net access code, SS is a two-digit site code, and XXXX is a
four-digit extension number, giving a total of seven digits.
On-Net and Off-Net Access Codes

It is common practice in most enterprise telephony systems to dedicate a digit (for example, 9) as an
off-net access code to steer calls to an off-net destination. In the variable-length on-net dial plan, another
steering digit (for example, 8) is also required as an on-net access code to dial calls to on-net extensions

9-10 OL-21733-18
Chapter 9 Dial Plan
Design Considerations
at other sites. These two access codes, along with the use of an operator access code (for example, 0),
implicitly exclude three of the ten possible leading digits of any dialed string. This restriction might not
prove convenient for either of the following reasons:
• The users would be required to know the difference between on-net and off-net destinations, and to
select the proper access code.
• The exclusion of three entire dialing ranges can become too restrictive or can conflict with some
pre-assigned extension ranges. For instance, if a site already uses an abbreviated dialing range
beginning with 8, the use of that same digit as an access code would require a change.
In systems where the same off-net access code (for example, 9) is already in use by all sites, it might be
desirable to use the same code for both off-net and on-net off-site destinations. This approach has two
main implications:
• To avoid partial overlap and interdigit timeout situations, the quantity of digits expected after the
access code should be uniform.
• The telephony system must be able to recognize all on-net numbers dialed as off-net numbers and
to route them over the IP network. This task can be simple for small systems with only one
Unified CM cluster but complex for large systems with multiple Unified CM clusters.
Plan Ahead
Implementing an IP-based system might require changing certain existing user practices. Although it is
preferable to plan a new system so that the implementation is as transparent as possible to users, dialing
habits might have to be adapted to accommodate the integration of multiple sites that used to be on
separate telephony systems. For instance, adapting to a new global, enterprise-wide dial plan might
require changing the way a user reaches another user at a different site, the quantity of digits used to
make intra-site calls and, in some cases, the extension numbers. To avoid exposing users to multiple
generations of dial plan changes, try to anticipate expansion of the enterprise, which could result in the
addition of sites in different dialing regions, an increase in the required number of on-net extensions,
PSTN renumbering (for example, an area code split), or business expansion into different countries.
This section presents the following dial plan design considerations for multisite deployments:
• Globalized Design Approach, page 9-12, covers guidelines and best practices that apply to
deployments using the globalization dial plan features of Cisco Unified Communications Manager.
• Call Control Discovery, page 9-24, explains how the Service Advertisement Framework (SAF) Call
Control Discovery (CCD) service allows clusters to advertise their own hosted DN ranges into the
network as well as to subscribe to advertisements generated by other call agents in the network.
• Dial Plan Considerations for the Intercompany Media Engine, page 9-33, describes the Cisco
Intercompany Media Engine (IME), which allows participating enterprises to route calls over the
Internet between them.
• Design Guidelines for Multisite Deployments, page 9-35, covers guidelines and best practices that
apply to all multisite deployment models.
• Choosing a Dial Plan Approach, page 9-38, presents the various approaches to organizing a dial plan
for uniform versus variable-length on-net dialing and, for this second option, partitioned versus flat
addressing.

OL-21733-18 9-11
Chapter 9 Dial Plan
• Deploying Dialed Pattern Recognition in SIP Phones, page 9-52, explains how SIP dial rules can be
employed to enable SIP phones to recognize certain dialing patterns.
• The following sections analyze in detail two dial plan approaches and provide configuration
guidelines for each:
– Deploying Uniform On-Net Dial Plans, page 9-40
– Deploying Variable-Length On-Net Dial Plans with Flat Addressing, page 9-43
• The following sections present two alternative ways of configuring classes of service within
Unified CM:
– Building Classes of Service for Unified CM with the Traditional Approach, page 9-54
– Building Classes of Service for Unified CM with the Line/Device Approach, page 9-58
• Building Classes of Service in Cisco IOS with H.323, page 9-71, explains how to implement classes
of service within a Cisco IOS router running the H.323 protocol.
• Deploying Call Coverage, page 9-75, provides guidelines and best practices for implementing call
coverage functionality using hunt lists and line groups with Unified CM.
Globalized Design Approach

This section describes dial plan features used to implement simplified call routing based on globalized
numbers. The simplification is primarily obtained through the use of a single routing structure for off-net
calls, no matter the source of the call. For example, two users in separate countries could use the same
route patterns to carry calls to their respective local gateways, instead of requiring site-specific route
patterns, each configured to match their respective dialing habits.
The main architectural approach used to attain this globalization can be summarized as follows:
• When a call enters the system, the destination number and the calling number are accepted in their
local format but are then immediately globalized by the system.
• Once globalized, the called number is used to route the call to its destination through the use of route
patterns expressed in the global form. The global form may be a combination of a global internal,
enterprise-specific form such as 81001234 and/or a globalized PSTN representation of a DID
number, such as the +E.164 form (for example, +12125551234).
• Once a destination has been identified, the calling and called numbers are localized to the form
required by the endpoint, the network, or the system to which the call is to be delivered.
Thus, the guiding principle is:
Accept localized forms upon call ingress, and globalize them; route the call based on the globalized
form; and localize the call to comply to the form required by the destination.
Cisco Unified Communications Manager (Unified CM) offers the following dial plan globalization
capabilities:
• Local Route Group, page 9-13
• Support for + Dialing, page 9-13
• Calling Party Number Transformations, page 9-14
• Called Party Number Transformations, page 9-14
• Incoming Calling Party Settings (per Gateway), page 9-14
• Logical Partitioning, page 9-15

9-12 OL-21733-18
Chapter 9 Dial Plan
Together, these new features enable a Unified CM system to:

• Route calls based on the physical location context of the caller.
• Represent calling and called party numbers in a global form such as that described by the
International Telecommunications Union's E.164 recommendation.
• Present calls to users in a format based on local dialing habits.
• Present calls to external networks (for example, the PSTN) in a manner compatible with the local
requirements for calling party number, called party number, and their respective numbering types.
• Derive the global form of the calling party number on incoming calls from gateways, based on the
calling number digits and the numbering type.
• Control the establishment of calls, as well as the initiation of mid-call features, between endpoints
based on policies acting on each endpoint's geolocation, to comply with regulatory requirements in
certain countries.
Local Route Group

The Local Route Group offers the ability to create patterns that route off-net calls to a gateway chosen
for its proximity to the originating party. For example, a single pattern can be defined to route off-net,
intra-country calls for all sites within a given country. Phones at every site can be configured to match
this pattern, which then would route the call based on the Local Route Group associated with the calling
phone. This allows a phone in site 1 to route calls through the gateway at site 1, while a phone at site 2,
still using the same pattern, would route calls through the gateway at site 2. This feature simplifies the
configuration of site-specific routing of off-net calls when compared to releases prior to Unified CM 7.0.
Support for + Dialing

Telephone numbers can use the + sign to represent the international dialing access code needed to reach
a destination from different countries. For example, +1 408 526 4000 is the international notation for
Cisco's main corporate office in the United States. To call this number, an enterprise telephony user from
France typically would have to dial 0 00 1 408 526 4000, whereas a caller from the United Kingdom
would have to dial 9 00 1 408 526 4000. In each case, + must be replaced with the appropriate off-net
access code (as required by the enterprise telephony system) and international access code (as required
by the PSTN carrier) relevant for each caller.
The system can route calls directly to destinations defined with +. For example, a user could program a
WiFi phone’s speed-dial entry for Cisco's main US office as +1 408 526 4000 and dial it directly when
roaming in France, the UK, or anywhere else in the enterprise. In each location, the system would
translate the destination number into the locally required digit string to allow the call to be routed
properly.
Likewise, phone numbers dialed from a dual-mode phone are routable directly over the mobile carrier
network when the phone is in GSM mode, or over the enterprise network when the phone is in WiFi
mode, if the called number is represented in the +E.164 form. This allows a user to store a single
destination number for a particular contact entry, and dial it no matter to which network the phone is
currently attached.
This feature allows users to rely on the system to interpret phone numbers represented in the form
described by the ITU E.164 recommendation and to route them properly without requiring the user to
edit the number to adapt it manually to the local dialing habits.

OL-21733-18 9-13
Chapter 9 Dial Plan
Calling Party Number Transformations

The calling party number associated with a call routed through Unified CM might sometimes have to be
adapted before it is presented to a phone or to the PSTN. For example, a call from +1 408 526 4000
might have to be presented as coming from 408 526 4000 if the destination phone is in the US or Canada,
whereas a call from the same number might have to be presented to a destination phone in France as
coming from 00 1 408 526 4000. This is mainly to offer users a presentation of the calling party in the
customary form offered by their local PSTN, to maintain user familiarity with identification of the origin
of calls ringing in.
Calls offered to gateways might require that the calling party number be manipulated to adapt it to the
requirements of the telephony carrier to which the gateway is connected. For example, a call from
+1 408 526 4000 offered to a gateway located in France might have to represent the calling number as
1 408 526 4000, with a Calling Party Number Type set to International. Similarly, a call from the same
number offered to a gateway located in Canada might have to be represent the calling party number as
408 526 4000, with the Calling Party Number Type set to National.
This feature allows the calling party number to be adapted from the form used to route calls within the
Unified CM system, to the form required by phone users or off-cluster networks.
Note Some service providers might not be able to accept calling party numbers representing foreign telephone
numbers, due to either technical limitations of their equipment, company policies, or governmental
regulations. If calling party numbers cannot be accepted by the provider, the provider will either screen
and overwrite the calling party number or reject the call. In some networks two calling party identities
can exist for a call: user provided and network provided.
Called Party Number Transformations

The called number associated with a call routed through Unified CM might sometimes have to be
adapted before it is presented to the PSTN. For example, a call placed to +1 408 526 4000 requires the
called party number be transformed to 1 408 562 4000 with the numbering type set to National if it
egresses to the PSTN through a gateway located in Canada. If the same call were re-routed toward a
French gateway, the called party number would have to be transformed to 00 1 408 526 4000 with the
numbering type set to International.
By manipulating the called party number as well as setting the numbering type for the called number,
this feature allows the called party number to be adapted to the form required by off-cluster networks.
Incoming Calling Party Settings (per Gateway)

The calling party number associated with a call as it enters a gateway through a digital interface (for
example, ISDN PRI) is also associated with an attribute identifying the calling number’s numbering type
as either Unknown, Subscriber, National, or International. When combined, the incoming call's calling
number and its associated numbering type allow the system to determine the identity of the caller by
stripping and prefixing appropriate digits to the incoming call's calling party number. Incoming Calling
Party Settings allow the system to apply separate combinations of stripped and/or prefixed digits to the
calling party number for each of the four calling number types.
For example, assume two calls come into a gateway located in Hamburg, Germany. Both feature a calling
party number of 691234567. The first call is associated with a numbering type of Subscriber. This means
the caller is located in Hamburg, thus the city code of Hamburg (40) is implied, as is the country code

9-14 OL-21733-18
Chapter 9 Dial Plan
of Germany (49). Therefore, a full representation of the incoming call is +49 40 69 1234567, which can
be obtained by prefixing +49 40 to the incoming call's calling party number for numbering type
Subscriber.
The second call is associated with a numbering type of National. This means the caller is located in
Germany, and the number already contains the applicable city code (69 is the city code of Frankfurt),
but the country code of Germany (49) is implied. A full representation of the second incoming call is
thus +49 69 1234567, which can be obtained by prefixing +49 to the second incoming call's calling party
number for numbering type National.
This feature allows the system to globalize incoming calls' calling party numbers based on the incoming
party number and numbering type. In previous versions of Unified CM, these settings were implemented
through the use of cluster-wide service parameters. Unified CM 7.0 introduced per-gateway settings for
this feature, which allow different prefixes for each numbering type to be applied to calls entering
different gateways. The settings can be configured on the gateway itself, on the gateway's device pool,
or through the cluster-wide service parameters, in order of precedence. A blank entry signifies that no
digits will be prefixed; to inherit the settings from the lower-precedence setting, the entry must be set to
Default.
For all calls within a given numbering type, the prefix and strip-digits operations are applied, with no
consideration for the calling party number originally received.
Note Calls coming from SIP trunks or from SIP gateways are all associated with calling party numbering type
Unknown.
In particular, the SIP protocol as implemented on SIP gateways and SIP trunks effectively places the
incoming calling party number of all calls in the numbering type Unknown. This prevents Unified CM
from applying different calling party number modifications for different calling party number categories.
Unified CM 7.1 and later releases allow the use of Incoming Calling Party Settings Calling Search
Spaces (CSSs) for each number type. These CSSs are used to apply modifications to the calling party
based on Calling Party Transformation Patterns. These patterns use regular expressions to match a subset
of cases, followed by separate digit manipulation operations for each subset. This new capability enables
Unified CM to apply different calling party number modifications for different calling party number
categories. For example, a SIP trunk used to connect to the PSTN could present calls from local,
national, and international parties with the numbering type set to Unknown; then each call's calling party
number would be used to match a Calling Party Transformation Pattern in the trunk's CSS associated
with number type Unknown, thus allowing Unified CM to apply different calling party number
modifications for different calling party number categories.
Logical Partitioning
Some countries such as India have Telecom regulations requiring an enterprise's voice infrastructure to
use the local PSTN exclusively when connecting calls outside the enterprise. This requires that the voice
system be partitioned logically into two systems: one for Closed User Group (CUG) communications
within the enterprise, and a second one to access the local PSTN. A call from an enterprise user in
location A to another enterprise user in location B could be made within the CUG system; however, a
call from an enterprise user in location A to a PSTN destination, no matter the location, must be made
through local access to the PSTN in location A.
While existing dial plan tools can be used to prevent a call from completing if it were placed between
endpoints outside the CUG, they are not able to prevent new call legs from being established while the
call is in progress. For example, assume that an enterprise user in London, England, calls a co-worker in
Delhi, India, over the enterprise network. Once the call is established, the user in Delhi conferences in

OL-21733-18 9-15
Chapter 9 Dial Plan
a customer in India, from the same line on which the call from London was received. This mid-call
addition (on the same line) of a destination outside the closed user group is not preventable solely by
using the existing dial plan tools in Unified CM (such as Calling Search Spaces and Partitions).
Unified CM 7.1 and later releases offer logical partitioning functionality, which allows the establishment
and enforcement of policies that apply not only to the initial onset of calls, but also to mid-call features
such as conference and transfer.
The combination of globalization features available in Unified CM allows the system to accept calls in
the local format preferred by the originating users and carriers, to route the calls on-net using global
representations of the called and calling numbers, and to deliver the calls to phones or gateways in the
local format required by the destination user or network. These three aspects of the dial plan design
approach can be summarized as:
• Localized Call Ingress, page 9-16
• Globalized Call Routing, page 9-20
• Localized Call Egress, page 9-20
Localized Call Ingress

Unified Communications systems with multiple sites located in different regions or countries must
satisfy different dialing habits from users and different signaling requirements from the service providers
to which gateways are connected. Each local case can be different; this requires that the system be able
to "translate" the local dialing habits and signaling requirements into a form that allows for the calls to
be routed properly. Therefore, the systems must not only provide for many localized ingress
requirements but also yield a single globalized form of any destination pattern.
Localized Call Ingress on Phones
Calls originating on endpoints such as phones or video terminals are typically dialed by users
accustomed to a certain set of local dialing habits. Enterprise users in the US are used to dialing
9 1 408 526 4000 to reach Cisco's world headquarters in San Jose, California, whereas users in the UK
would dial 9 00 1 408 526 4000 and users in France would dial 0 00 1 408 526 4000. Each of those three
dialing forms features an enterprise off-net access code (9 for the US and UK, 0 for France), an
international access code (00 for the UK and France, none needed for the US because the destination is
intra-country), and a representation of the destination number, including the country code (1). Each of
those three groups of users are dialing the same globalized destination number (+1 408 526 4000), but
each with their own local dialing habits. In each of the three cases, + can be used as a global abstraction
of the local dialing habits.
An enterprise telephony system must allow for the local dialing customs of users to be interpreted
correctly. In all three cases above, the users are using a local dialing form to reach a common destination.
The system must be configured to recognize user input and then route and deliver the call to the proper
destination. Because the call can originate in many different forms, the system must provide pattern
recognition to match each of those different forms.
Unified CM's translation patterns are used to convert localized user input as dialed from phones, to the
global form used to route the calls within the Unified Communications system. These patterns must
allow all localized dialing habits to be recognized, including:
• Intra-site on-net dialing
• Off-net local, national, and international dialing
• Local services such as emergency calling, directory and operator services
• Carrier selection codes, and so forth

9-16 OL-21733-18
Chapter 9 Dial Plan
For the three example calls mentioned above, the following translation patterns would be configured in
separate partitions and placed in the calling search space (CSS) of:
• US phones: 9.1!, strip pre-dot, prefix +
• UK phones: 900.!, strip pre-dot, prefix +
• French phones: 000.!, strip pre-dot, prefix +
In each case, the locally significant dialed string is translated into a globalized form of
+ 1 408 526 4000.
For on-net destinations, such as calls between two users in the same site or calls between users at
different sites, translation patterns should be used to derive the globalized on-net form of the destination
number. This is applicable whether on-net dialing is achieved using site codes or the fully qualified
PSTN address of the phone is used as the on-net number.
For example, assume two users in the San Jose site use five-digit abbreviated dialing to call each other.
User A calls User B by dialing 51234. A translation pattern specific to this site is configured to recognize
any five-digit string beginning with 5 and to translate the called number to the globalized on-net form of
800151234. The translation pattern is configured as: 5XXXX, prefix 8001.
The translation pattern must be site-specific (included in the CSS of only the phones in site San Jose) to
avoid confusion with extension 51234 at other sites in the system. In the example above, the on-net
global form is implemented using an inter-site access code (8) and a site code (001). If the system used
the fully qualified PSTN address of the phone as the on-net number, the translation pattern would instead
prefix +140855, to yield a globalized on-net number of +1 408 555 1234.
Note Variable Length On-net Dialing (VLOD) with flat addressing is the recommended approach where
possible, because it simplifies configuration. While VLOD with partitioned addressing is supported, it
entails extra configuration complexity.
Phone Calling Party Number Globalization

The calling party number for calls originating from phones is set to the number configured as the
directory number of the line from which the call originates. Following the concepts of a globalized dial
plan design approach, the calling party information of all calls should be globalized. If the DN format is
not identical to the format chosen for the globalized internal calling party information (typically
+E.164), then the correct handling of calling party information can be achieved by either making sure
that all calling party transformations implemented in the system accept both the directory number format
and the globalized +E.164 format as input or by making sure that the calling party information for calls
from phones is also correctly set to +E.164. This can be achieved by setting the external phone number
mask on the line to +E.164 and then setting the use external phone number mask option in a translation
pattern that is matched. Using the use external phone number mask option on a route pattern will not
work because device-level calling party transformations using a calling party transformation calling
search space on the gateway or the gateway's device pool override the calling party transformation
configured on route patterns, so that the input to the calling party transformation calling search space
would be the untransformed directory number.
Allowing Call Ingress Using the Global Form

Phones can also provide dialed strings in the global form of the dialed number. In the case of software
endpoints such as Cisco Unified Personal Communicator, + dialing can be accommodated directly from
the Telephony User Interface (TUI) of the phone or can be derived from click-to-dial actions taken by
the user. On Type-B IP phones, dialing + from the keypad can be achieved by pressing and holding either

OL-21733-18 9-17
Chapter 9 Dial Plan
the * or 0 key, depending on the phone model. Also, the missed and received calls directories can contain
entries where the number includes a +. As the user dials from those directories, the resulting call into
Unified CM will have a called number beginning with +.
Note For definitions of Type-A and Type-B phones, see Dial Plan Elements, page 9-78.
To allow such calls to be handled properly by the phone's dial plan, you must ensure that not only the
localized form of dialed numbers is allowed, but also the globalized form. Figure 9-2 illustrates how to
accomplish this.
Figure 9-2 Allowing Localized and Globalized TUI
CSS’s Partitions Route Lists Route Groups
DN
SJCInternational All IP Phone DNs (+E.164)
4-digit intra-site dialing
SJCIntra
DN 1XXX, Prefix +1408555 7-digit dialing
SJCtoE164local
SJCE164Local 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408
Locally significant
translations to
UStoE164International globalize user input
USE164International 9011.!, Urgent, Pre-Dot, Prefix +
XYZ RG
9011.!#, Urgent, Pre-Dot, Prefix +
9.1[2-9]XX[2-9]XXXXXX, V
Pre-Dot, Prefix + V
PSTNInternational
\+[^1]!
PSTN USPSTNNational Local

route \+1XXXXXXXXXX, Urgent LOC RL Route
patterns group
SJCPSTNLocal
\+1408[2-9]XXXXXX, Urgent 292520
In Figure 9-2, a US IP phone user dials 9011496100773, connects to the destination in Germany, and
then releases the call. The called party calls the US user back, connects, and then releases the call. The
US user then goes into the Received calls directory, selects the entry for the last received call
(+49 6100 773), and presses Dial. In this example, the US user initiates two separate calls to the same
destination. For the first call, the form of the destination number localized for US dialing habits is used,
and the corresponding translation pattern 9011.! is matched by the user's input. Once translated, the route
pattern \+[^1]! is used to route the call. For the second call, the globalized form of the destination number
is used and the route pattern \+[^1]! is used directly.

9-18 OL-21733-18
Chapter 9 Dial Plan
The calling search spaces configured for each site should generally allow for:
• Localized intra-site dialing habits of the site
• Localized off-net dialing habits of the users at the site
• Applicable local telephony services such as emergency calls, directory and operator services
• The globalized form of on-net and off-net numbers
Except for the first item in the list above, the localized patterns used to achieve call routing can typically
be reused between sites in the same dialing domain. (All sites in France dial off-net numbers the same
way, as do all sites in the UK, in the US, and so forth.) However, each site must be configured with its
own intra-site abbreviated dialing translation patterns so that there will be no confusion when a user in
San Jose, for example, dials 51234, compared to when a user in New York dials 51234. The translation
from the abbreviated intra-site form of a number to the globalized on-net form of the same destination
must be achieved with site-specific translation patterns, which requires that each site be configured with
its own site-specific calling search space.
Localized Call Ingress on Gateways
The called and calling numbers delivered into the Unified Communications system by external networks
(for example, the PSTN) are typically localized. The form of the numbers may vary, depending on the
service provider’s configuration of the trunk group. As a gateway is connected to a PSTN trunk group,
the system administrator must work with the PSTN service provider to determine the applicable
signaling rules to be used for this specific trunk group. As calls are delivered into the system from the
trunk group, some of the information about the calling and called numbers will be provided explicitly
and some of it will be implied. Using this information, the system must derive the calls' globalized
calling and called party numbers.
The globalization of the called party number can be implemented through one of the following methods:
• In the gateway configuration, configure Call Routing Information > Inbound Calls, where the
quantity of significant digits to be retained from the original called number and the prefix digits to
be added to the resulting string are used to globalize the called number. The prefix digits should be
used to add the applicable + sign and country, region, and city codes.
• Place translation patterns in partitions referenced by the gateway's calling search space. The
translation patterns should be configured to match the called party number form used by the trunks
connected to the gateway, and should translate it into the global form. The prefix digits should be
used to add the applicable + sign and country, region, and city codes.
• On H.323 trunks and gateways, use the incoming call’s called party transformation settings available
on the gateway and on the gateway's device pool. There you can define strip and prefix digit
instructions or alternatively configure a called party transformation calling search space per
numbering type.
The globalization of the calling party number should be implemented by using the Incoming Calling
Party Settings configured either on the gateway directly or in the device pool controlling the gateway.
Note If the administrator sets the prefix to Default, this indicates call processing will use the prefix at the next
level setting (device pool or service parameter). Otherwise, the value configured is used as the prefix
unless the field is empty, in which case there is no prefix assigned.
For example, assume a call is placed to Cisco's US headquarters (+1 408 526 4000) from a US number,
and the call is delivered to a gateway located in San Jose, California. The called number provided to the
gateway is 526 4000. This information is sufficient for the Cisco Unified Communications system to
derive the full destination number for the call. A call delivered by the service provider on this specific

OL-21733-18 9-19
Chapter 9 Dial Plan
trunk group should inherit an implied country code and area code based on the characteristics of the
trunk group connected to the gateway, which presumes that all destination DID numbers handled by the
trunk group are from the North American Numbering Plan country code (1) and from area code 408.
Therefore, the derived global form of the number is +1 408 526 4000. The calling number provided to
the gateway is 555 1234, with the numbering type set to Subscriber. The numbering type allows the
system to infer the country code and area code from the configured characteristics of the trunk group.
Thus, the system knows that the calling number is +1 408 555 1234.
On a different call, if the calling number is 33158405858 with numbering type International, this is an
indication that the global form of the calling number should represented as +33158405858.
Globalized Call Routing

For the destination to be represented in a global form common to all cases, we must adopt a global form
of the destination number from which all local forms can be derived. The + sign is the mechanism used
by the ITU's E.123 recommendation to represent any global E.164 PSTN number in a global, unique way.
This form is sometimes referred to as a fully qualified PSTN number.
The system can be configured with route patterns that match globalized called numbers including the +
sign. These same route patterns can point to route lists and route groups featuring the Standard Local
Route Group. This allows for the creation of truly global route patterns because the egress gateway can
be determined from the calling endpoint’s device pool at the time of the call. All the necessary tasks of
adapting the calls (both the calling and the called party numbers) to the local preferences and
requirements are performed once a destination has been selected.
Localized Call Egress

When calls are routed to a destination using a global form of the called and the calling numbers, you
might have to consider the following localization actions when the call is delivered to its destination.
Phone Calling Party Number Localization

As a call is delivered to a phone, the calling number will be in its global form, which might not be
recognizable to the called party. Typically, users prefer to see calls from callers within their country
presented with an abbreviated form of the caller's number.
For example, users in the US want to see incoming calls from US callers with a ten-digit national
number, without the + sign or the country code (1). If a user whose global phone number is
+1 408 555 1234 calls +1 408 526 4000, the called phone would like to receive 408 555 1234 as the
calling party number while the phone is ringing. To achieve this, the system administrator should
configure a Calling Party Transformation Pattern of: \+1.!, strip pre-dot. The Calling Party
Transformation Pattern is placed in a partition included in the destination phone's Calling Party
Transformation Pattern CSS, configured at the device-pool level. As a call from +1 408 555 1234 is
offered to the phone, it matches the configured Calling Party Transformation Pattern, which removes the
+1 and presents a calling party number of 408 555 1234 as the call rings in.
Note The calling party number stored in the missed and received calls directories of Type-B phones is left in
its globalized form to allow one-touch dialing from the directories without requiring manual editing of
the directory's stored number string. The calling party number stored in the missed and received calls
directories of Type-A phones is the transformed calling party number. For Type-A phones, the
transformed calling party number needs to be in the form of a supported dialing habit to make sure the
user can call back from the missed and received calls directory. This behavior permits implementation
of globalized dial plans even with older Type-A phones present in the network.

9-20 OL-21733-18
Chapter 9 Dial Plan
Note Many phone users are becoming accustomed to the globalized form of PSTN numbers, mainly due to the
common use of mobile phones across international boundaries. The system administrator can forego the
configuration of Calling Party Transformation Patterns for phones if displaying the global form of
incoming numbers is preferred.
Gateway Calling Party Number Localization

As a call is delivered to a gateway, the calling party number must be adapted to the requirements of the
PSTN service provider providing the trunk group to which the gateway is connected. Calling Party
Number Transformation patterns can be used to change the calling party number digit string and
numbering type. Typically, a calling party number featuring the gateway's country code should be
changed to remove the + sign and the explicit country code, and they should be replaced with the national
prefix. Also, the numbering type of the calling party number should be changed to National. If the
gateway is connected to a trunk group featuring a specific area, region, or city code, the specific
combination of + sign, country code, and local area code usually must be replaced by the applicable local
prefix. Also, the numbering type must be adjusted to Subscriber.
For example, assume that a call from a San Francisco user (+1 415 555 1234) is routed through a route
list featuring a San Francisco gateway as a first choice and a Chicago gateway as a second choice. The
San Francisco gateway is configured with two Calling Party Transformation Patterns:
• \+1415.XXXXXXX, strip pre-dot, numbering type: subscriber
• \+1.!, strip pre-dot, numbering type: national
As the call is delivered to the San Francisco gateway, the calling party number matches both Calling
Party Transformation Patterns. However, the first one is a more precise match and is selected to process
the calling party number. Thus, the resulting transformed number is 5551234, with a calling party type
set to Subscriber.
If the gateway had not been able to process the call (for example, if all ports were busy), the call would
have been sent to the Chicago gateway to egress to the PSTN. The Chicago gateway is configured with
the following two Calling Party Transformation Patterns:
As the call is delivered into the Chicago gateway, the calling party number matches only the second
Calling Party Transformation Pattern. Therefore, the resulting calling party number offered to the
gateway is 4155551234, with a calling party number type set to National.
Gateway Called Party Number Localization

As a call is delivered to a gateway, the called party number must be adapted to the requirements of the
PSTN service provider providing the trunk group to which the gateway is connected. Called Party
Number Transformation patterns can be used to change the called party number digit string and
numbering type. Typically, a called party number featuring the gateway's country code should be
changed to remove the + sign and the explicit country code, and they should be replaced with the national
prefix. Also, the numbering type of the called party number should be changed to National. If the
gateway is connected to a trunk group featuring a specific area, region, or city code, the specific
combination of + sign, country code, and local area code usually must be replaced by the applicable local
prefix. Also, the numbering type must be adjusted to Subscriber.

OL-21733-18 9-21
Chapter 9 Dial Plan
For example, assume that a call to a San Francisco user (+1 415 555 2222) is routed through a route list
featuring a San Francisco gateway as a first choice and a Chicago gateway as a second choice. The San
Francisco gateway is configured with two Called Party Transformation Patterns:
As the call is delivered to the San Francisco gateway, the called party number matches both of the Called
Party Transformation Patterns. However, the first one is a more precise match and is selected to process
the called party number. Thus, the resulting transformed number is 5552222, with a called party type set
to Subscriber.
If the gateway had not been able to process the call (for example, if all ports were busy), the call would
have been sent to the Chicago gateway to egress to the PSTN. The Chicago gateway is configured with
the following two Called Party Transformation Patterns:
As the call is delivered into the Chicago gateway, the called party number matches only the second
Called Party Transformation Pattern. Therefore, the resulting called party number offered to the gateway
is 4155552222, with a called party number type set to National.
Note When a call egresses to a gateway, the calling and called party transformation patterns are applied to the
calling and called numbers respectively.
Note SIP does not offer an indication of the numbering type. Therefore, SIP gateways will not be able to
receive an indication of the called or calling party number type set by Unified CM.
Benefits of the New Design Approach

The benefits of the dial plan design approach enabled by the new globalization features in
Unified CM 7.x include:
• Simplified configuration of call routing, especially when considering local egress to the PSTN
• Simplified configuration and enhanced functionality of system functions such as:
– Automated Alternate Routing (AAR)
– Emergency Responder (ER) site-specific failover
– Call Forward Unregistered (CFUR)
– Tail End Hop Off (TEHO)
– Click-to-dial of E.164 numbers (including the + sign) from soft clients such as Cisco Unified
Personal Communicator
– Adaptive call routing for speed dials originating from roaming extension mobility users or
roaming devices
– One-touch dialing from phone directory entries, including dual-mode phones
– One-touch dialing from missed and received call lists in IP phone directories

9-22 OL-21733-18
Chapter 9 Dial Plan
Automated Alternate Routing (AAR)
If the AAR destination mask is entered in the globalized form, and if every AAR CSS is able to route
calls to destinations in the globalized form, then the system administrator can forego the configuration
of AAR groups because their sole function is to determine what digits to prefix based on the local
requirements of the calling phone's PSTN access to reach the specific destination.
Furthermore, in most cases the sole function of the AAR CSS is to route the call to the calling phone's
co-located gateway; therefore, it can be configured with only a single route pattern (\+!) pointing to a
route list that contains the Standard Local Route Group. Because calls routed by this single route pattern
will always be routed through the Local Route Group associated with the calling endpoint, that unique
AAR CSS can be used by all phones at all sites, no matter in which region or country they are located.
Cisco Emergency Responder
Call routing to Cisco Emergency Responder (ER) is typically implemented by configuring a 911 CTI
route point to connect to the primary ER server and a 912 CTI route point to connect to the backup ER
server.
If both ER servers are unavailable, 911 calls can be directed to the PSTN egress gateway co-located with
the calling phone by configuring:
• The 911 CTI route point to Call Forward No Answer (CFNA) and Call Forward Busy (CFB) to 912,
through a calling search space that contains the partition of the 912 CTI route point
• The 912 CTI route point to CFNA and CFB to 911, through a calling search space that contains a
global partition, itself containing a route pattern 911 pointing to a route list that contains the
Standard Local Route Group
If both CTI route points become unregistered, calls to 911 will be forwarded through the local route
group as determined by the calling phone's device pool. If Device Mobility is configured, roaming
phones will be associated with the visited site's device pool, and thus associated with the visited site's
Local Route Group.
Call Forward Unregistered (CFUR)
To allow calls handled by the Call Forward Unregistered function to use a gateway co-located with the
calling phone, configure the CFUR destination of phones using the globalized + form of their PSTN
number. The CFUR CSS can be configured with only a single route pattern (\+!) pointing to a route list
that contains the Standard Local Route Group. Because calls routed by this single route pattern will
always be routed through the Local Route Group associated with the calling endpoint, the same CSS can
be used as the CFUR CSS by all phones at all sites, no matter in which region or country they are located.
Tail End Hop Off (TEHO)
To reduce PSTN connectivity charges, system administrators might want to route calls to off-net
destinations by using the IP network to bring the egress point to the PSTN as close as possible to the
called number. At the same time, if the call's preferred TEHO route is not available, it might be necessary
to use the calling phone's local gateway to send the call to the PSTN. This can be achieved by allowing
all phones partaking in TEHO routing for a given type of number to match the same route pattern that
matches the specific destination number and that points to a route list containing the TEHO egress
gateway-of-choice as the first entry and the Standard Local Route Group as the second entry.

OL-21733-18 9-23
Chapter 9 Dial Plan
Call Control Discovery

In environments where multiple call clusters are deployed, the dial plan must be engineered to route calls
between clusters over the IP network where possible, and to use the PSTN as a backup route where
required.
Configuration of a cluster to allow intercluster call routing requires the addition of sets of patterns
describing the DN ranges hosted in remote clusters. For each remote DN range, the local cluster must be
configured with:
• Number range pattern(s) to be recognized as hosted on a remote cluster
• The primary route to reach each remote cluster destination number range, along with associated
trunks and protocols
• Secondary route(s) to the destination number ranges, with their associated digit manipulation to
transform the destination number to a form acceptable by the PSTN carrier.
This configuration can be done manually, by using static dial plan entries such as route patterns. When
done manually, the configuration effort increases with the quantity of remote ranges to be routed. This
increase is linear when all clusters are pointed to a centralized dial plan resolution platform, such as a
gatekeeper, a SIP proxy, or Cisco Unified CM Session Management Edition. However, this introduces a
dependency on a central control point.
The alternative is to create a full mesh, where each cluster pair is configured with intercluster trunks
referenced by route patterns defining the remote DN ranges of the cluster on the other side. In this mode,
no central point controls the intercluster dial plan resolution, but the configuration effort grows
exponentially with the quantity of clusters because a full mesh of trunks and associated DN ranges is
required to link all cluster pairs.
Cisco Unified Communications Manager offers the ability for clusters to automatically exchange the DN
ranges they host by subscribing to a network-based Service Advertisement Framework (SAF) Call
Control Discovery (CCD) service. SAF CCD enables clusters to advertise their own hosted DN ranges
into the network as well as to subscribe to advertisements generated by other call agents in the network.
The main benefits of using SAF CCD are:
• Automated distribution of call routing information between call agents participating in the same
SAF CCD network, thus avoiding incremental configuration work when new call agents are added
or when new DN ranges are added to a call agent
• No reliance on a centralized dial plan resolution control point
• Automated recovery of inter-call agent call routing information when routing changes occur,
including when multiple Unified CM clusters are combined
The section on Dial Plan Elements, page 9-78, presents some fundamental systemic functionality aspects
of SAF CCD to complement the product information available in the latest version of the Cisco Unified
Communications Manager Administration Guide, available at
http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html
For more detailed information on the Service Advertisement Framework and Call Control Discovery, see
Call Routing and Dial Plan Distribution Using Call Control Discovery for the Service Advertisement
Framework, page 5-64.
This section of the chapter is not meant to present the exhaustive product configuration of Unified CM
for participation in the SAF CCD service. Rather, it focuses on the fundamental system implications of
using Unified CM as a call agent in a network offering the SAF CCD service. Design considerations for
the dial plan aspects of the SAF CCD service are presented in the following section.

9-24 OL-21733-18
Chapter 9 Dial Plan
SAF CCD Design Considerations

SAF CCD allows for the exchange of directory number (DN) information between call agents such as
Cisco IOS Gateways, Unified CME, and Unified CM. To ensure optimal performance, the system should
be designed with the following criteria in mind:
• Advertising Globalized Numbers, page 9-25
• Learning Remote DN Ranges Through the SAF CCD Requesting Service, page 9-30
• Placing Calls to SAF CCD Learned DN Ranges, page 9-31
Advertising Globalized Numbers
Because the DN ranges exchanged between the call agents participating in the SAF CCD service are sent
to all call agents, with no regard to site-specific dialing habits, the form of the DNs exchanged through
the SAF CCD service should be a global one; that is, a form that is unique among all call agents. This
form can be used from any device, on any call agent, in any location in the network. Cisco recommends
that all patterns advertised into a SAF CCD service be globally unique within the enterprise.
For example, assume user Paul in Liverpool, England, can be reached by calling the following numbers:
• 1234 if called by coworker John, also located in Liverpool, England
• 85551234 if called by co-worker Wolfgang from Vienna, Austria, or by any other coworker in any
on-net enterprise office location worldwide, no matter what call agent controls their phone
User Brian in Hawthorne, CA, can be reached by calling the following numbers:
• 1234 if called by coworker Carl, also located in Hawthorne, CA
• 84441234 if called by coworker Bono located in Dublin, Ireland, or by any other coworker in any
on-net enterprise office location worldwide, no matter what call agent controls their phone
In this example, the localized, four-digit abbreviated intra-site form of the number associated with Paul
cannot be used as a global identification to be sent to all call agents because it conflicts with that of user
Brian. If Paul's call agent were to send a SAF CCD advertisement into the network for DN 1234, it would
conflict with that advertised by Brian's call agent in the same SAF CCD network. If user Carl were to
dial 1234, there would be some conflict as to whom (Paul or Brian) he is trying to reach.
To avoid such conflicts, call agents should always advertise numbers in a form that is global; that is, a
form which does not rely on a context specific to a site or a cluster. It should be a form that can be dialed
from any phone on the network, and that uniquely identifies the destination DN in the entire network.
The following two main forms of global DNs can be used for this purpose:
• Site-Code Based On-Net Form, page 9-25
• +E.164 Based On-Net Form, page 9-26
Site-Code Based On-Net Form

In systems where the majority of inter-site calls are dialed by using an on-net scheme based on site codes,
it is better to advertise DNs in their site-code form, along with a set of rules to allow their failover to the
PSTN.
Each DN is globally reachable within the system by dialing an inter-site access code, followed by a site
code, followed by a local extension. For example, user Paul in Liverpool can be reached from anywhere
on the enterprise network by dialing inter-site access code 8, followed by site code 555 (Liverpool,
England), followed by the local extension 1234. Combined, these parts yield a global DN of 85551234,
which is globally unique within the network.

OL-21733-18 9-25
Chapter 9 Dial Plan
In systems using site codes implemented with Variable Length On-Net Dialing (VLOD) with flat
addressing, the DN ranges advertised by the cluster to the rest of the network directly match the DN form
configured on the lines. This ensures that, when calls are received from other call agents into a SAF CCD
trunk, no digit manipulation is required to adapt the called number to the form used internally on the
lines. For example, if the cluster advertised 855512XX and it receives a call for 85551234 on a SAF CCD
trunk, a match can be made directly into the single partition containing the phones.
In systems using site codes implemented with Variable Length On-Net Dialing (VLOD) with partitioned
addressing, the DN ranges advertised by the cluster to the rest of the network do not directly match the
DN form configured on the lines. When calls are received from other call agents into a SAF CCD trunk,
the called number must be translated from the globalized form to the site-specific abbreviated form used
internally on the lines. For example, if the cluster advertised 855512XX and it receives a call for
85551234 on a SAF CCD trunk, a match must first be made into the single partition containing a series
of translation patterns that can adapt the called number from the incoming global form to the localized
form 1234 used in the destination phone's site-specific partition.
+E.164 Based On-Net Form

In systems where the majority of inter-site calls are dialed by using the PSTN form of DNs, it is better
to advertise DNs in their associated +E.164 form. The +E.164 form carries in it all the information that
allows any user in any system (on-net or off-net) to reach the destination DN across any network. Cisco
recommends that the DN ranges learned from the SAF CCD service be stored as-is, in their +E.164 form,
and that local user input be globalized to match it.
For example: user Paul in Liverpool uses a phone whose line DN is defined as 1234 in the Liverpool
partition in the English cluster. However, any coworker in a different site calls Paul by dialing the locally
significant form of Paul's +E.164 form DID (+44 15 4555 1234). For Wolfgang in Austria, it is
0 00 44 15 4555 1234, and for Elvis in Memphis, TN, it is 9 011 44 15 4555 1234. User Ringo, calling
from a different site in Liverpool, dials 9 0154 555 1234 to reach Paul. For user Edge, on the road
somewhere in the world, the call to Paul takes on the form of a click-to-call action from a laptop, to
+44 15 4555 1234.
The literal form in which Paul's +E.164 is advertised is not necessarily used as-is by users in the other
clusters on the network. All but user Edge in the example above used a localized form of Paul's number.
But in every case, the local form dialed can be globalized to arrive at the global form advertised by Paul's
cluster.
Each cluster must accept user input in a local, habitual form. For example, for user Elvis in the United
States, the habitual manual enterprise user input to reach a user in another country involves dialing an
off-net access code (9), followed by an international routing code (011), followed by the E.164 number
of the destination (44 15 4555 1234). In this case, the globalization of the user input requires the
matching of a pattern such as 9011.!, strip pre-dot, prefix +. This one translation pattern can be used for
all calls from any USA user to any destination outside the NANP country code 1.
For all users in all clusters, the locally-significant globalization rules required to globalize habitual user
input to an +E.164 form are few. They must cover the globalization of local PSTN calls, national calls,
and international calls. In many countries, there is only one form for all intra-country, national calls.
Note Advertising DN ranges in the +E.164 form does not require that the DNs themselves be defined as
+E.164 numbers in their host cluster.
In systems using the +E.164 form implemented with Variable Length On-Net Dialing (VLOD) with flat
addressing, the DN ranges advertised by the cluster to the rest of the network directly match the DN form
configured on the lines. This ensures that, when calls are received from other call agents into a SAF CCD

9-26 OL-21733-18
Chapter 9 Dial Plan
trunk, no digit manipulation is required to adapt the called number to the form used internally on the
lines. For example, if the cluster advertised +4415455512XX and it receives a call for +441545551234
on a SAF CCD trunk, a match can be made directly into the single partition containing the phones.
In systems using the +E.164 form implemented with Variable Length On-Net Dialing (VLOD) with
partitioned addressing, the DN ranges advertised by the cluster to the rest of the network do not directly
match the DN form configured on the lines. When calls are received from other call agents into a SAF
CCD trunk, the called number must be translated from the globalized form to the site-specific
abbreviated form used internally on the lines. For example, if the cluster advertised +4415455512XX
and it receives a call for +441545551234 on a SAF CCD trunk, a match must first be made into the single
partition containing a series of translation patterns that can adapt the called number from the incoming
global form to the localized form 1234 used in the destination phone's site-specific partition.
When Both Forms Are Required

In some systems, users reach each other by both approaches listed above. For these situations, the host
clusters should advertise both the site-code form of the DN ranges as well as the +E.164 form. Because
the two forms are differentiated by the use of the + sign, no overlap situation can occur between the two
DN ranges advertised for a given group of phones.
Special Considerations for Non-DID Numbers

When the system requires the inter-cluster reachability of non-DID numbers, the non-DID DN ranges
can be configured to use SAF CCD. However, the PSTN failover functionality will not work in the same
manner as for DNs associated with a DID. For example, if a non-DID DN range such as 800033XX is
advertised and there is no associated DID range to route calls through the PSTN to the lines in the host
cluster, you can do either of the following:
• Configure the PSTN failover digits to yield a call to an annunciator message in the calling cluster,
indicating that the call should be re-attempted later due to network congestion, or
• Configure the PSTN failover digits to yield a call to an IVR, reception phone, or other device.
Note The +E.164 format allows the use of the +0 range to designate non-DID numbers. The +0 range can thus
be used to route the calls in the +E.164 form on-net only; the PSTN will not route calls to country code 0.
Tip When configuring non-DID ranges, subdivide the +0 range into the actual country, area, and/or city
codes where the DNs are hosted. For example, a non-DID range in Chicago, IL, could start with
+01708XXXXXXX, allowing for 10 million non-DID numbers. In Frankfurt, Germany, the range could
be +04969XXXXXXX, and so forth.
PSTN Failover Considerations for SAF CCD Outgoing Calls

When a call is placed to a SAF CCD discovered number, the call is routed through one of the SAF CCD
trunks associated with the requesting service, as configured under Call Control > Call Control
Discovery > Requesting Service in Unified CM. (See Figure 9-3.) If the trunk cannot accept the call
(for example, if call admission control denies the call or if the trunk is down), then the call will be sent
to the PSTN through the AAR calling search space (CSS) of the calling device. Because the destination
number might not be in a form directly compatible with the PSTN, the destination number must first be
adapted.

OL-21733-18 9-27
Chapter 9 Dial Plan
Figure 9-3 SAF CCD and PSTN Failover
Calling Search Spaces Partitions Route Lists Route Groups
Call +14085551234 SAF has notified

CCD engine that
SAF_CCD_part
8408XXXX is
8408XXXX [4:+1408555] unreachable via IP
8919XXXX [4:+1919392]
8212XXXX [4:+1212666] CCD
8611XXXX [4:+6123456]
8611XXXX [4:+6123456] HQ_RG
V
Paris_css OnCluster_part V
1st preference
Call All IP Phone DNs (833XXXXX)
84081234 HQ Gateways
IP
Paris
Phone Paris_RG
Local
French_PSTN_part Route
AAR_CSS French V
V
112 group
\+33XXXXXXXXXX Loc RL
Paris Gateways
\+! French 2nd
preference
253822
Intl RL
The DN range records injected into the SAF CCD service by each call agent must carry the rules required
to adapt the on-net form of the number to a form acceptable to the PSTN. The rules include what quantity
of digits to strip from the left of the range (PSTN Failover Strip Digits), what digits to prefix to the
post-strip called number (PSTN Failover Prepend Digits), and whether to use the DN range as-is when
rerouting calls to the PSTN (Use HostedDN as PSTN Failover checkbox).
For example, in Figure 9-3 a Unified CM cluster discovers routes to other clusters. The discovered routes
are placed into the partition named SAF_CCD_part. If the Paris user dials 84081234, the best-match
routing logic will route the call using the SAF CCD discovered pattern 8408XXXX. If the IP route is not
available, the dialed number will be combined with the ToDID information, which instructs Unified CM
to strip the left-most four digits (in this case, 8408) and to prefix +1408555. This yields +14085551234,
which is used to find a match through the calling phone's AAR calling search space. The call then
matches the \+! route pattern and is routed through the French INtl RL route list; the first attempt will
be to route the call through the HQ_RG route group, followed by an attempt to use the calling phone's
local route group (in this case, Paris_RG).
These rules are configured for each advertised DN range under Call Routing > Call Control Discovery
> Hosted DN pattern in Unified CM. They can also be configured for groups of DN ranges under Call
Routing > Call Control Discovery > Hosted DN group in Unified CM.
Cisco recommends configuring the PSTN failover digits at the Hosted DN pattern level because it
provides more granular control of the failover digits for each range and avoids another configuration step
at the Hosted DN group level.

9-28 OL-21733-18
Chapter 9 Dial Plan
When Advertising DN Ranges Using Site Codes

For instance, the users in Liverpool can be reached on-net by dialing a number in the 855512XX range.
Nothing in this form inherently defines the associated DID number required to route a call to this
destination across the PSTN. To transform this site-code form into the +E.164 form required by the
PSTN, (+44 15 4555 12XX), the advertised DN range should be stripped of its first (left-most) digit and
prefixed with +44154. This is sometimes represented as S:PP, where S represents the quantity of digits
to be stripped from the left and PP represents the literal digits to be prefixed to the post-strip called
number. In this example, the transformation would be 1:+44154.
Note The cluster advertising the DN range must provide the SAF CCD records with the appropriate
information to fail-over to the PSTN. If this information is not provided as the routes are injected into
the SAF CCD service, each of the CCD client clusters would have to be configured to adapt the PSTN
failover characteristics of the learned routes. This creates an additional configuration burden and
requires multiple clusters be modified if any changes are required.
Once the called number form is changed to the +E.164 form, the call is routed through the calling
device's AAR CSS. A match must be made on the +E.164 form of the number. Once a route pattern is
matched, the call is routed through a route list, a route group, and eventually a trunk or gateway, where
called party transformation patterns are used to adapt the number from the +E.164 to the localized form
required by the PSTN carrier.
When Advertising DN Ranges Using the +E.164 Form

In this case, the DN ranges are advertised directly in the +E.164 form, therefore no PSTN failover digit
configuration is required. It is best to check the Use HostedDN as PSTN Failover checkbox under the
Hosted DN Range configuration to prevent any failover PSTN digit configuration done at the Hosted DN
group level from taking precedence. This may be useful when a system requires both the site-code and
the +E.164 forms of a number range to be advertised through the same Hosted DN Group, to
accommodate both dialing forms between clusters. In such a case, the Hosted DN group PSTN Failover
configuration would apply to the site-code DN ranges and would be ignored for the +E.164 DN ranges.
Note In SAF CCD PSTN failover digit configuration, the + sign is used to perform two main tasks: it allows
the adapted PSTN failover number to avoid overlap with any other intra-site valid range in any other
cluster (for instance, a cluster where 4415 is a valid intra-site extension would not overlap with
+441545551234), and it allows the use of + as a differentiator in matching called party transformation
patterns in situations where local calls could overlap with some country codes (for example, India
country code 91 overlapping with local ten-digit dialing in Raleigh, NC, Morocco country code 212
overlapping with local ten-digit dialing in New York, NY, and so forth).
Configuring Multiple Advertising Services

Hosted DN groups are a collection of hosted DN patterns that you group together in Cisco Unified
Communications Manager Administration. You assign a hosted DN group to a CCD advertising service
in Unified CM Administration, and the CCD advertising service publishes all the hosted DN patterns
that are a part of the hosted DN group.
You can configure multiple advertising services in Unified CM. Each advertising service establishes a
unique relationship between Hosted DN ranges and the group of call processing nodes that will advertise
themselves as responsible for the reception of calls to the DNs in those ranges.
An advertising service is associated with a Hosted DN group, which itself is common to a set of Hosted
DN ranges. The advertising service is also associated with one SIP SAF trunk and/or one H.323 SAF
trunk. Each of those trunks is associated with a device pool, which itself is associated with a Unified CM

OL-21733-18 9-29
Chapter 9 Dial Plan
server group. The constituent members of the Unified CM server group will be advertised as responsible
for calls to any of the DN ranges in the Hosted DN group. In systems where the call processing servers
are deployed as a cluster across the WAN (clustering over the WAN), Cisco recommends that the
Unified CM server groups used to serve the phones be used also to advertise the DN ranges
corresponding to the lines configured on the phones. This will ensure that calls made by remote SAF
CCD clients to those phones are sent to the Unified CM servers co-located with the phone's controlling
servers.
Learning Remote DN Ranges Through the SAF CCD Requesting Service
The SAF CCD Requesting Service is used to learn the DN ranges hosted in other call agents participating
in the SAF CCD service. The Requesting Service is associated with SAF CCD trunks, and it is used to
select the trunks associated with the Requesting Service when calls are placed to SAF CCD learned DN
ranges.
Each DN range is associated with multiple attributes, such as:
• DN Range — For example: 8555XXXX, +1408555XXXX
• ToDID info — Representing the PSTN failover information provided by the advertising call agent.
For example: 1:+1408
• IP address — Representing the signaling destination of the call agent hosting the advertised DN
range. This field carries the address of the trunk used by the advertising cluster to inject the DN
range into the SAF CCD service. For example: 10.0.0.1.
• Protocol — Representing the signaling protocol required to contact the call agent responsible for the
hosted DN range. For example: SIP, H.323
Note If an advertising service is associated with a trunk whose device pool features a Cisco Unified
Communications Manager Group with more than one member, one SAF CCD record is advertised per
member. This means that, if a single hosted DN range is advertised through a trunk with three
Unified CM group members, three SAF CCD records are advertised. Load balancing is used by the
calling cluster between all the records advertising the same hosted DN range.
The SAF CCD Partition

In a cluster, a single SAF CCD partition is configured and is used to contain all learned patterns, no
matter the source of the advertised DN range, the required protocol, or the DN range form (site-code or
+E.164) used in the advertisement. (See Figure 9-4.)
Note The SAF CCD partition is not listed for searches under Call Routing > Class of Control > partition.

9-30 OL-21733-18
Chapter 9 Dial Plan
Figure 9-4 Integration of SAF Call Control Discovery with Static Routing
Calling Search Spaces Partitions Route Lists Route Groups

CCD selects
“Intercept patterns SAF-enabled
SAF_CCD_part OnNet_RG
learned through CCD“ H.323/SIP trunks
8408XXXX [4:+1408555]
8919XXXX [4:+1919392]
8212XXXX [4:+1212666] CCD
8611XXXX [4:+6123456] Gatekeeper-controlled
8611XXXX [4:+6123456] Trunk
Paris Devices
HQ_RG
Paris_css OnCluster_part
All IP Phone DNs (833XXXXX) V
V
OnNet
RL
HQ Gateways
1st preference
Intercluster_part
8271XXXX Paris_RG
8971XXXX
Nice Devices
8200XXXX V
V
Local Paris Gateways
French_PSTN_part Route
Nice_css French
112 group Nice_RG
\+33XXXXXXXXXX Loc RL
\+! French 2nd V
253821
preference V
Intl RL
Nice Gateways
The fact that all learned patterns are placed in the single call control discovery partition means that a
phone cannot be given access to only a subset of learned patterns. Access to all the patterns is effected
by inclusion of the Call Control Discovery Partition in a CSS used by a phone or in the CSS of a
translation pattern used to adapt the dialed, localized form of a number into the globalized form
advertised into the SAF CCD service.
For example, the Paris user in Figure 9-4 dials 84081234. None of the statically configured patterns
matches the dialed string. However, the SAF_CCD_Part partition has been populated with DN ranges
learned from the SAF CCD requesting service. The pattern 8408XXXX matches the dialed string
directly and allows the user's call to be placed through a SAF CCD-enabled IP trunk. Note that the Paris
and Nice users in this example have access to all the patterns in the SAF_CCD_part partition.
Placing Calls to SAF CCD Learned DN Ranges
In general, calls placed to SAF CCD learned DN ranges should match the range either directly, if the
user dialed the advertised globalized number, or through a globalization translation pattern, if the user
dialed the number in a local form. SAF CCD learned patterns are always learned as non-urgent. This
might cause partial overlaps when the SAF CCD learned patterns are global +E.164 patterns and there
is an alternative match on a \+! PSTN route pattern. In this case dialing the global on-net destination
learned through SAF CCD either directly or by dialing the habitual local form that is transformed by
appropriate translations will be subject to inter-digit timeout (T302).

OL-21733-18 9-31
Chapter 9 Dial Plan
The calling party number should be sent as-is if the DN of the caller is already in a global form (site-code
or +E.164). If the calling party number is in a local form, it should be globalized before egressing the
local cluster. This is best done through the use of calling party transformation patterns on the SAF CCD
trunk used to place the call.
When a user dials a number corresponding to a DN range advertised by a remote call agent, the following
events occur:
1. The dialed string is processed through the calling phone's effective CSS. The best-match process is
used, as usual. This means that, if a call is placed to a destination matching several SAF CCD learned
routes and/or patterns locally configured in the cluster, the most precise match will be chosen to
match the call. In cases where multiple equal-precision matches are found, the order in which the
associated partitions are listed in the effective CSS will be used. In the special case where multiple
Unified CM nodes belonging to the same cluster advertise the same route, multiple equal-precision
patterns will be found in the SAF CCD partition of all clusters participating in the SAF CCD service.
In this case, the calls to this pattern are load-balanced between all the equal-precision matches.
2. Either a match is found directly on the dialed pattern (for example, the user dials 84081234 and this
matches a pattern found in the SAF CCD partition as included in the phone's CSS), or a match is
made with a translation pattern used to adapt the local form to the global form advertised in the SAF
CCD partition (for example, the user in Memphis, TN, dials 9011441545551234, matches a
translation pattern that adapts the called number to +441545551234, and then matches the
+441545551234 found in the SAF CCD partition located in the translation pattern's CSS).
3. The call is extended through the IP trunk used to learn the pattern in the local cluster, to the trunk
used to advertise the pattern in the remote cluster.
4. Upon egressing the calling cluster, the called number is in the form advertised by the remote cluster.
5. Upon egressing the calling cluster, the calling number should be provided in a global form. If the
local cluster's DNs were not provisioned in a global form, calling party transformation patterns
should be used to adapt the local form to the global form to be sent to the remote cluster. This is
especially important to allow remote users to use the dial function from the missed and received calls
lists. Note also that globalizing the calling party number should be done by the calling cluster to
simplify configuration. The alternative requires configuring all remote clusters with the rules
required to recognize calls coming from other clusters and globalize the calling party numbers.
6. If the IP route between the calling and the called cluster is available, the call will be received at the
remote cluster into the trunk associated with the advertising service used to inject the DN range into
the SAF CCD service.
7. The remote cluster's SAF CCD trunk receiving the call will look for a match in the trunk's Inbound
Calls CSS.
8. If the DNs as configured in the cluster are in the same global form as that advertised into the SAF
CCD service, a match is found by including the DN partitions into the SAF CCD trunk's Inbound
Calls CSS. The call is offered to the called line.
9. If the DNs as configured in the cluster are in a form different than the global form advertised into
the SAF CCD service, a match is found by including, in the SAF CCD trunk's Inbound Calls CSS,
a partition containing translation patterns matching the global form to the local form configured on
the DNs of the lines. The call is offered to the called line.
10. In step 6., if the IP route between the two clusters is not available, the PSTN failover digit
transformation rules (ToDID rules) are applied to the called number, and the resulting destination
number will be used to find a match in the calling device's AAR CSS.
11. At this point, the called number should be in +E.164 form and should be used to match a route
pattern pointing to a route list, route group, and gateway (or trunk) combination.

9-32 OL-21733-18
Chapter 9 Dial Plan
12. Once the call egresses on a gateway or trunk, transformation patterns should be used to adapt both
the calling and called party numbers to the form required by the PSTN carrier. At this point, the call
is launched into the PSTN.
13. Once the call reaches the remote cluster, the call is processed as usual for incoming PSTN calls.
Note If the design intent were to route all calls to SAF CCD learned routes through the PSTN, such as is the
case when deploying the VoPSTN approach, simply put the SAF requesting service's associated trunk(s)
in a call admission control static location configured with 1 kbps of bandwidth. This will force all calls
to be routed through the calling device's AAR CSS.
Dial Plan Considerations for the Intercompany Media Engine

The Cisco Intercompany Media Engine (IME) allows participating enterprises to route calls over the
Internet between them. When a phone participates in the IME and places calls through trunks or
gateways marked as PSTN Access, a record of the call is sent to the enterprise's IME server, including
the calling and called numbers. This record serves to flag the pairing of numbers in two different
IME-participating companies for future call routing over the Internet; if another call between these same
two numbers is detected by the IME server, it instructs Cisco Unified Communications Manager
(Unified CM) to route the call over the Internet.
One challenge in such pairings is ensuring the consistent normalization of numbers in all the
participating IME-enabled Unified CM clusters. Because the calls are initially placed over the PSTN and
because these calls can traverse the boundaries of different cities, provinces or states, or even countries,
the form of the number dialed by the user will vary greatly. Similarly, different companies might have
adopted different approaches when assigning DNs to lines.
Cisco recommends using the +E.164 form to identify the calling and the called numbers for calls
participating in the IME service. The +E.164 form affords the normalization (for example, every number
begins with + followed by the country code of the associated DID number) and the globalization required
to ensure consistent results.
When calls are placed toward trunks or gateways marked as PSTN Access, the trunk or gateway's
associated IME E.164 transformation profile is applied. This in turn applies a set of transformation
patterns to the calling party number, as well as a set of transformation patterns to the called party number.
For outgoing calls, the post-transformation numbers are used in the records sent to the IME server.
Note The IME E.164 Transformation Profile is configured in Unified CM under Advanced Features >
Intercompany Media Services > E.164 Transformation.
The Intercompany Media Services E.164 Transformation configuration allows the application of
transformation patterns to outgoing calls, segregated between calling party and called party. For each, a
CSS can be configured, which itself contains the partitions in which the calling/called party
transformation patterns are contained. The transformations are applied to either the original number (the
form the number was in as it matched the route pattern) or the routing transformed number (the form the
number was in once route list transformations were applied).

OL-21733-18 9-33
Chapter 9 Dial Plan
For the calling party number:

The original number is the DN of the phone as it matched a route pattern, when considering the
calling party settings. The routing transformed number is the DN of the phone after any calling party
digit manipulations are performed through route lists.
For example, a DN configured as 85551234 is placing a call to the PSTN, to 91415551000. The call
is placed through a translation pattern 91[2-9]XX[2-9]XXXXXX. The translation pattern is
configured to modify the called party number to +14155551000, while changing the calling party
number to +14085551234. This call then matches a route pattern \+!, configured with a route list
that modifies the calling party number to 408 555 1234 and the called party number to
415 555 1000.
If the Outgoing Calling Party Settings are set to apply the transformations to the original number,
then +14085551234 will be used to match a calling party transformation pattern in the Outgoing
Party E.164 Transformation CSS.
If the Outgoing Calling Party Settings are set to apply the transformations to the routing transformed
number, then 4085551234 will be used to match a calling party transformation pattern in the
Outgoing Party E.164 Transformation CSS.
For the called party number:
The original number is the dialed number as it matches the route pattern, when considering the
called party settings. In the example above, the original number is +14155551000.
The routing transformed number is the destination of the phone after any digit manipulations are
performed through route lists. In the example above, it is 4155551000.
No matter to which form of the number the transformations are applied, they must yield a normalized,
globalized number to be sent to the IME service.
When calls are received from trunks and gateways marked as PSTN Access, the form in which the calling
and called numbers are received must be normalized and globalized before they are sent to the IME
service. The Incoming Transformation Profile Settings can be used to adapt the incoming form of the
calling and called numbers to the +E.164 form required by the IME service. It features an Incoming
Calling Party Transformation Profile as well as an Incoming Called Party Transformation Profile. For
each, a CSS can be configured, which itself contains the partitions in which the calling/called party
transformation patterns are contained.
The transformations for the calling number are applied to the routing transformed number; that is, the
number as processed through the Incoming Calling Party Settings at the trunk or gateway level.
The transformations for the called number are applied to the number as it is presented into the gateway
or trunk's CSS for inbound calls.

9-34 OL-21733-18
Chapter 9 Dial Plan
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 Unified CM cluster, also refer to the section on Additional
Considerations for Multi-Cluster Systems, page 9-37.
• To prevent routing loops, make sure the calling search spaces of all PSTN gateways do not include
any partitions that contain external route patterns assigned to route lists and route groups that can
send calls out the same gateway.
• When choosing DID ranges with your Local Exchange Carrier (LEC), try to select them so that no
overlap occurs within a site. For example, if you use four-digit dialing within a site and you need
two blocks of 1000 DIDs, the blocks (408)555-1XXX and (408)444-1XXX would overlap when
reduced to four-digit numbers and would introduce additional complexity due to inbound and
outbound translations.
• Allow for multiple ways of dialing emergency numbers. For example, in North America, configure
both 911 and 9.911 as emergency route patterns within Unified CM.
• When automated alternate routing (AAR) is deployed, ensure that the external phone number mask
or AAR Destination Mask configured on the IP phones is compatible with all the prefixes added by
the various AAR groups. For example, in a multi-national deployment, do not include national
access codes such as 0 in the mask unless they are part of the global E.164 address. The simplest
way to configure AAR relies on the configuration of the AAR destination mask as the full E.164
address of the phone, including the + sign.
• You can force calls to on-net destinations, but dialed as PSTN calls, to be routed on-net within the
cluster by adding translation patterns that match the E.164 DID ranges for each site and that
manipulate the digits so they match the destination's internal extension. For example, if a DN is
reachable on-net by dialing 1234, but someone within the system dials this same destination as 9 1
415 555 1234, you can force the call to be kept on-net by creating a translation pattern 9 1 415
555.1XXX, which removes all digits pre-dot and routes the call on-net to the resulting number.
However, remember to configure the AAR calling search space to exclude the partition containing
the "force on-net" translation patterns but to include a partition containing the regular route patterns
pointing to the PSTN, so that automated PSTN failover is possible when the IP WAN is out of
bandwidth.
• Within a centralized call processing cluster with N sites, you can implement Tail End Hop Off
(TEHO) using one of the following methods:
– TEHO with centralized failover
This method involves configuring a set of N route patterns in a global partition, with each
pattern pointing to a route list that has the appropriate remote site route group as the first choice
and the central site route group as the second choice.
– TEHO with local failover
This method involves configuring N sets of N route patterns in site-specific partitions, with each
pattern pointing to a route list that has the appropriate remote site route group as the first choice
and the local site route group as the second choice. For the example in Figure 9-5, in order to
implement local failover TEHO routes to Brazil, a site in Paris, France would require a
dedicated route pattern and route list to route the calls to the TEHO gateways in Brazil as a first
choice or to the Paris gateways as a second choice. Because the pattern is linked to a
site-specific route list, it cannot be reused at any other site. Likewise, the site in Ottawa, Canada
requires its own dedicated route pattern pointing to an Ottawa-specific route list to allow local
failover to a gateway in Ottawa.

OL-21733-18 9-35
Chapter 9 Dial Plan
Figure 9-5 TEHO Without Local Route Group
CSSs Partitions Route Lists Route Groups

Paris Devices
CDG_BRZ_TEHO CDG RG
CDG2BRZ
CDGDevices TEHO
00055! 2nd choice
V
V
CDG Gateways
BRZ RG
1st choice
V
V
1st choice
BRZ Gateways
Ottawa Devices
YOW RG
YOW_BRZ_TEHO YOW2BRZ
YOWDevices V
901155! TEHO 2nd choice
V
YOW Gateways
271562
While this 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.
– TEHO with local failover with Local Route Group
The Local Route Group allows for the local failover of TEHO routes to be implemented without
having to create route patterns for each site. For the example in Figure 9-6, a single TEHO
pattern and route list is used by both the Paris and Ottawa sites. Because the user input for these
two sites is not the same (French users dial Brazilian destinations differently that Canadian
users do), the configuration relies on translation patterns to globalize the user input. The global
form is then used to match a single, cluster-wide route pattern pointing to a route list whose first
entry is the Brazil route group and whose second entry is the Standard Local Route Group. The
local route group is resolved to the Paris route group when the calling device is in a Paris device
pool, and to an Ottawa route group when the calling device is in an Ottawa device pool.

9-36 OL-21733-18
Chapter 9 Dial Plan
Figure 9-6 TEHO With Local Route Group
Paris Devices
CDG RG
Cent_EU_loc2glob V
CDGDevices V
000.!, strip pre-dot, prefix +
CDG
First Gateways
choice
BRZ RG
BRZ_TEHO Local
BRZ Route
glob_dial \+55 TEHO group V
V
Second BRZ
choice Gateways
Ottawa Devices
NANP_loc2glob
YOWDevices 9011.!, strip pre-dot, prefix + YOW RG
V
V
254270
YOW
Gateways
• When appropriate for your national numbering plan, you may configure an additional translation
pattern at each site to catch local PSTN calls dialed as long-distance calls and to translate them into
the proper abbreviated form. This translation pattern should be accessible only from phones located
within the site. Such a configuration also helps simplify the AAR configuration (see Special
Considerations for Sites Located Within the Same Local Dialing Area, page 9-111).
• Do not use the multilevel precedence and preemption (MLPP) feature to assign higher priority to
emergency calls. An emergency-related call might not appear as such to the IP Telephony system,
and you would risk terminating an existing emergency call to place another call to the main
emergency service routing number. For example, an emergency situation might prompt someone to
place a call to a regular ten-digit number to reach a medical professional. Preemption of this call
would abort the ongoing emergency communication and could delay handling of the emergency.
Also, incoming calls from emergency service personnel would be at risk of preemption by MLPP.
Note A Unified CM cluster with a very large dial plan containing many gateways, route patterns, translation
patterns, and partitions can take an extended amount of time to initialize when the Cisco CallManager
Service is first started. If the system does not initialize within the default time, there are service
parameters that you can increase to allow additional time for the configuration to initialize. For details
on the service parameters, refer to the online help for Service Parameters in Unified CM Administration.
Additional Considerations for Multi-Cluster Systems

In addition to the considerations made in the previous section, observe the following best practices when
designing a dial plan for a multisite deployment involving multiple Unified CM clusters:
• Avoid splitting DID ranges across multiple Unified CM clusters. This practice would make
intercluster routing very difficult because summarization would not be possible. Each DID range
should belong to a single Unified CM cluster.

OL-21733-18 9-37
Chapter 9 Dial Plan
• Avoid splitting devices within a remote site between multiple Unified CM clusters using call
admission control based on static locations. Static locations-based call admission control is
significant only within a cluster, and having devices belong to different clusters at the same remote
site would lead to poor utilization of the IP WAN bandwidth because you would have to split the
available bandwidth between the clusters. Each remote site should belong to a single Unified CM
cluster. Locations can be configured in Unified CM to use RSVP as the call admission control
mechanism, which allows the efficient sharing of a single site's total WAN bandwidth between
phones belonging to different clusters. To take full advantage of the efficiency of RSVP-based call
admission control, all phones within the remote site must be configured to use RSVP.
• Use gatekeeper-controlled intercluster trunks to route calls between Unified CM clusters. This
practice enables you to add or modify clusters easily in your network without reconfiguring all other
clusters.
• Implement redundancy in the connection between Unified CM and the gatekeeper by using a
gatekeeper cluster and by assigning the intercluster trunk to a device pool that uses a Unified CM
group with multiple servers configured.
• When sending calls to the gatekeeper, expand the called number to the full E.164 address. This
practice simplifies PSTN failover when the IP WAN is not available because no additional digit
manipulation is required to reroute the call via a PSTN gateway. Also, this practice eliminates the
need to configure the local (calling) Unified CM with dial length information for each remote site.
• Within the gatekeeper, configure one zone per Unified CM cluster. For each cluster/zone, add zone
prefix statements to match all DN ranges owned by that cluster.
• You can implement Tail-End Hop-Off (TEHO) across multiple Unified CM clusters by following
these guidelines:
– Add specific route patterns for the relevant E.164 ranges to the source (originating) Unified CM
cluster, and point them to a route list that has the IP WAN route group as the first choice and the
Standard Local Route Group as the second choice
– Within the Cisco IOS gatekeeper configuration, add zone prefix statements for all the relevant
E.164 ranges and point them to the appropriate Unified CM cluster
– Ensure that the intercluster trunk calling search space in the destination Unified CM cluster
includes partitions featuring route patterns that match the local PSTN numbers, and that digit
manipulation is applied as needed (for example, stripping the area code before sending the call
to the PSTN) by using appropriate Called Party Number Transformation Patterns.
For details on how to configure a Cisco IOS gatekeeper for distributed call processing deployments, see
Gatekeeper Design Considerations, page 8-37.
Choosing a Dial Plan Approach

As introduced in Planning Considerations, page 9-5, there are two main approaches to a dial plan for
internal destinations within an IP Telephony system:
• Uniform on-net dial plan, where each internal destination is dialed in the same way regardless of
whether the caller is located in the same site or in a different site.
• Variable-length on-net dial plan, where internal destinations are dialed differently within a site than
across sites. Typically, this approach uses four or five-digit abbreviated dialing for calls within a site
and either full E.164 addresses or an on-net access code followed by a site code and the extension
for calls across sites.

9-38 OL-21733-18
Chapter 9 Dial Plan
To help you decide which approach is best suited for your needs, consider the following high-level
design questions:
• How many sites will eventually be served by the IP Telephony system?
• What are the calling patterns between sites or branches?
• What do users dial within a site and to reach another site?
• Are there any calling restrictions applied to on-net inter-site calls?
• What transport network (PSTN or IP WAN) will be used for most inter-site calls?
• What (if any) CTI applications are being used?
• Is there a desire for a standardized on-net dialing structure using site codes?
Uniform on-net dial plans are the easiest to design and configure; however, they work best for small to
medium deployments, and they become impractical when the number of sites and users increases. They
are described and analyzed in detail in the section on Deploying Uniform On-Net Dial Plans, page 9-40.
Variable-length on-net dial plans are more scalable but also more complex to design and configure.
Figure 9-7 shows the typical requirements for a large-scale deployment using the variable-length on-net
dial plan approach.
Figure 9-7 Typical Dialing Requirements for Large Multisite Deployments
M
Unified CM
Voice
Cluster M M
mail
M M
IP
IP
IP WAN
IP IP IP IP IP IP
DN 1XXX DN 1XXX DN 1XXX

Site 1 Site 2 Site N
4-digit dialing within site
114727
E.164 or Site Code dialing between sites

OL-21733-18 9-39
Chapter 9 Dial Plan
With Unified CM, the main method for implementing a variable-length on-net dial plan relies on flat
addressing. In this method, 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, page 9-43. 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, page 9-50.
Deploying Uniform On-Net Dial Plans

You can implement a uniform on-net dial plan by following these guidelines:
• Uniquely identify all phones with an abbreviated extension.
• Place all the phone DNs in a single partition.
• At each site, place PSTN route patterns in one or more site-specific partitions, according to the
chosen class-of-service approach.
Figure 9-8 shows an example implementation for a single Unified CM cluster deployment.

9-40 OL-21733-18
Chapter 9 Dial Plan
Figure 9-8 Example of Uniform On-Net Dial Plan Deployment
Calling Search Route Route

Spaces Partitions Lists Groups Devices
Route
Site1PSTN_pt Patterns
911
9.911
PSTN
9.[2-9]XXXXXX S1 S1
Site1_css PSTN PSTN
IP 9.1 [2-9]XX [2-9]XX XXXX RL RG V
Site 1
Site 1 Phones 9.011!
Gateways
Extensions: 9.011!#
1XXXX
Internal_pt
10000
All
10001 IP Phone
DN’s
20000
Site2PSTN_pt
911
9.911
PSTN
9.[2-9]XXXXXX S2 S2
IP Site2_css PSTN PSTN
9.1 [2-9]XX [2-9]XX XXXX RL RG V
Site 2 Phones Site 2
9.011! Gateways
Extensions:
114948
2XXXX 9.011!#
Use this approach if both of the following conditions apply:

• The DID ranges available do not overlap when considering the number of digits chosen to identify
internal extensions.
• The number of sites covered by the IP Telephony system is not expected to grow significantly over
time.
The following sections analyze implementation details and best practices for different types of calls
within the framework of uniform on-net dial plans:
• Inter-Site Calls Within a Cluster, page 9-42
• Outgoing PSTN and IP WAN Calls, page 9-42
• Incoming Calls, page 9-42
• Voicemail Calls, page 9-42

OL-21733-18 9-41
Chapter 9 Dial Plan
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
Unified CM.
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 9-8) 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. To allow the reuse of route patterns between sites for PSTN calls while still
allowing site-specific routing of the calls, route lists referencing the Standard Local Route Group can be
used.
Abbreviated dialing to another Unified CM cluster or Cisco Unified Communications Manager Express
(Unified CME) 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 9-8. 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 10-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 Unified CM. 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 Unified CM.
However, when users access the voicemail system from the PSTN, they need to be trained to enter their
abbreviated extension to access their voicemail boxes.

9-42 OL-21733-18
Chapter 9 Dial Plan
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 9-4 illustrates the basic relationship between calling search spaces and partitions at each site,
without taking into account additional elements required to implement classes of service:
Table 9-4 Calling Search Spaces and Partitions for Variable-Length Dial Plans with Flat
Addressing
Calling Search Space Partition Partition Contents

Site1_css Site1Translations_pt Translation patterns for Site 1's abbreviated
dialing
Site1PSTN_pt PSTN route patterns for Site 1 (more partitions
may be needed based on classes of service)
Internal_pt All IP phone DNs (unique form)
… … …
SiteN_css SiteNTranslations_pt Translation patterns for Site N's abbreviated
dialing
SiteNPSTN_pt PSTN route patterns for Site N (more partitions
may be needed based on classes of service)
Internal_pt All IP phone DNs (unique form)
Use this approach if one or more of the following conditions apply:

• No dialing restrictions are needed for on-net inter-site calls.
• A global on-net numbering plan using site codes is desired.
• Inter-site calls are normally routed over the IP WAN.
• CTI-based applications, such as Cisco Emergency Responder, are used across sites.
Note If dialing restrictions need to be applied to on-net inter-site calls, or an on-net numbering plan using site
codes is not desired, refer to the section on Special Considerations for Deployments Without Site Codes,
page 9-50, for a variant of this approach that can accommodate these needs.
The following considerations apply to this approach:

• The destination numbers of intra-site four-digit calls get expanded to the unique internal DN on the
IP phone display.
• The Placed Calls directory will display the original four-digit string as dialed by the user.

OL-21733-18 9-43
Chapter 9 Dial Plan
• Calling number, and numbers in the Missed Calls and Received Calls directories, appear as the
unique internal DN.
• To preserve the four-digit dialing feature when the IP WAN is unavailable and the branch phones are
in SRST mode, you need to apply a translation rule to the call-manager-fallback configuration
within the SRST router.
• When the branch phones are in SRST mode, the Line Text Label that masks the unique internal DN
as a four-digit number on the IP phone display is not available, so the users will see their full internal
DN appear instead.
To better understand how to deploy the flat addressing approach, consider again the hypothetical
customer network shown in Figure 9-9. 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 9-5 summarizes the site codes chosen.
Table 9-5 Site Codes for the Customer Network in Figure 9-9
San Jose New York Dallas London Paris Milan

Site Code 408 212 972 442 331 392
Using the US cluster from this example, the following sections analyze implementation details and best
practices for different types of calls within the framework of the flat addressing approach:
• Inter-Site Calls Within a Cluster, page 9-45
• Outgoing PSTN and IP WAN Calls, page 9-46
• Incoming Calls, page 9-49
• Voicemail Calls, page 9-49
• Special Considerations for Deployments Without Site Codes, page 9-50

9-44 OL-21733-18
Chapter 9 Dial Plan
Inter-Site Calls Within a Cluster

Figure 9-9 shows an example configuration for inter-site calls within the US cluster.
Figure 9-9 Inter-Site Calls Within a Cluster for the Flat Addressing Method
Calling Search
Spaces Partitions
Delivers 82121XXX
82121000 NYC_Translations_pt
1 Translation
IP NYC_Internal_css 1XXX [Prefix 8212] Pattern per site
for “local”
New York Internal_pt 4-digit dialing
Site code: 212
Extensions: 1XXX 82121000
82121000
Phone DN’s are
84081000 directly reachable
84081000
84081000
IP SJC_Translations_pt
SJC_Internal_css
1XXX [Prefix 8408]
114733
San Jose
Site code: 408
Extensions: 1XXX Delivers 84081XXX
To provide connectivity between sites and partitions, use the following guidelines:
• Place all unique DNs, including the on-net access code 8, in a global partition (named Internal_pt
in this example).
• Create one partition per site, each containing a translation pattern that expands four-digit numbers
into the fully qualified eight-digit number for that site, thus enabling abbreviated dialing within the
site.
• For each site, include both the Internal_pt partition and the local translation partition in the phone’s
calling search space.
The inclusion of the on-net access code in the DN configured in Unified CM enables you to place all
internal extensions in a partition directly accessible by all phones, and at the same time ensures that all
call directories on the IP phones are populated with numbers that can be directly redialed.
Note You must ensure that the on-net access code and site code combinations do not overlap with the local
abbreviated dialing range at any site.

OL-21733-18 9-45
Chapter 9 Dial Plan
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 9-10, 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.

9-46 OL-21733-18
Chapter 9 Dial Plan
Figure 9-10 Outgoing PSTN and IP WAN Calls for the Flat Addressing Method with Centralized PSTN Failover for IP WAN
Calls

Spaces Partitions Lists Groups Devices
Internal_pt
Intercluster_pt
8442.XXXX
8331.XXXX
8392.XXXX
Delivers E.164
SJC_PSTN_pt
PSTN
SJC
for San Jose site
9.[2-9]XXXXXX SJC PSTN

Device CSS
9.1 [2-9]XX [2-9]XX XXXX PSTN RG V

RL
SJC_css \+1.[2-9]XX[2-9]XX XXXX Second
choice IP
9.011! WAN
SJC First IPWAN
choice RG GK
114731
9.011!# IPWAN
RL
\+.[^1]!
Note The configuration example in Figure 9-10 assumes that the line/device approach to building classes of
service is being used, but the same considerations apply when using the traditional approach.
This solution requires a little more configuration and maintenance than that outlined in Option 1 because
it requires that you configure and maintain information about other clusters' site codes and E.164 ranges.
On the other hand, it provides automatic PSTN failover when the IP WAN is unavailable. PSTN failover
is provided using the central site's gateway only, so the IP WAN bandwidth usage is not optimal.
Also observe that calls to the Europe sites dialed as PSTN calls will automatically be placed on-net if
the IP WAN is available, with an automatic PSTN failover that in this case uses the local gateway.
Option 3: Eight-Digit Numbers and E.164 Addresses with Distributed PSTN Failover
This option, illustrated in Figure 9-11, uses a global set of translation patterns matching the Europe
eight-digit ranges and translating them into the corresponding E.164 numbers. The translation patterns
use a global calling search space (used by all sites within the North American Numbering Plan), and the
call then matches the international PSTN route pattern within the NANP's PSTN partition. The
international PSTN route patterns point to a route list with the IP WAN route group as a first choice and
the Standard Local Route Group as a second choice. The gatekeeper is configured to use the E.164
ranges as zone prefixes.

OL-21733-18 9-47
Chapter 9 Dial Plan
Figure 9-11 Outgoing PSTN and IP WAN Calls for the Flat Addressing Method with Distributed PSTN Failover for IP WAN
Calls
Calling Search Spaces Partitions Route Lists Route Groups Devices
Internal_pt
Intercluster_pt
8442.XXXX
8331.XXXX
8392.XXXX
Delivers E.164
Device CSS for NANP sites
NANP_PSTN_pt
PSTN
9.[2-9]XXXXXX Standard
NANP local route
9.1 [2-9]XX [2-9]XX XXXX
NANP_CSS PSTN RL group V
\+1.[2-9]XX[2-9]XX XXXX
Second
choice
9.011!
NANP IPWAN
9.011!# WAN RL First RG GK
\+.[^1]! choice
IP WAN
271564
This solution 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. Because of the advent of the Local Route Group
construct, this approach practically supersedes Option 2, as it requires the same level of configuration
but provides local PSTN failover.
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. This
in effect offers a form of TEHO functionality to all off-net European calls originating in the NANP sites.
If only the calls dialed as on-net destinations are to be sent to the IP WAN, the approach can be modified
to send calls to the IP WAN only if they were originally dialed as on-net inter-cluster destinations.
Figure 9-12 illustrates this approach.

9-48 OL-21733-18
Chapter 9 Dial Plan
Figure 9-12 IP WAN Access for Inter-Cluster Calls Only
Calling Search Spaces Partitions Route Lists Route Groups Devices
Internal_pt
Intercluster_pt
8442.XXXX
8331.XXXX
8392.XXXX
First IP WAN
Delivers E.164 WAN
choice IPWAN
WAN_CSS 9.011! IP WAN
RG GK
\+.[^1]! RL
Second
Device CSS for NANP sites
NANP_PSTN_pt choice
9.[2-9]XXXXXX NANP Standard
PSTN RL local route
9.1 [2-9]XX [2-9]XX XXXX group V
NANP_CSS
PSTN
9.011!
9.011!# NANP
WAN RL
271565
\+1.[2-9]XX[2-9]XX XXXX
Incoming Calls
Incoming PSTN calls require that the E.164 number be manipulated to obtain the eight-digit internal
number in order to reach the destination phone. You can implement this requirement in any of the
following ways:
• Configure the Num Digits and Prefix Digits fields within the Gateway Configuration page in
Unified CM to strip and then prefix the needed digits.
• If you have configured translation patterns to force on-net inter-site calls within the cluster, you can
reuse these patterns by simply prefixing the PSTN access code to the incoming called number on the
gateway.
• If you are using an H.323 gateway, you can use translation rules within the gateway to manipulate
the digits before sending the call to Unified CM.
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 Unified CM. Note that
users are required to use their eight-digit on-net number when prompted for the mailbox number.

OL-21733-18 9-49
Chapter 9 Dial Plan
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 Unified CM.
To implement this mechanism, follow these guidelines, illustrated in Figure 9-13:
• Define the phone DNs as the full E.164 addresses and place them all in the same partition (named
OnCluster_phones in this example).
• Configure translation patterns to accept localized user input and globalize it so that a full E.164
number is obtained. The resulting globalized numbers are routed through the CSS E164Routing. In
this example, only two device calling search spaces are required: one accepts localized user input
from the Paris site, but could be reused across all French sites. The other accepts user input from the
Ottawa site, but could be reused across all NANP sites.
• Configure an E.164 routing partition (E164_part in this example). Create the appropriate set of route
patterns and route lists to route PSTN calls. In this example, we rely on a single, cluster-wide route
pattern \+!, which is able to route all globalized destination PSTN calls to the local route group. In
addition, create translation patterns that match the existing on-cluster E.164 prefixes and route calls
back to the OnCluster_phones partition.
As a user in Paris dials a number, it is globalized through the translation patterns located in the
French_loc2glob_part partition, and the resulting number is then routed through the E164Routing CSS.
If the destination number is an on-cluster DN, it will simultaneously match the generic pattern \+! and
the urgent translation pattern with the respective specific site prefix in the E164_part partition. The more
specific site prefix will be selected, and the call will be extended to the on-cluster DN by means of the
OnCluster calling search space. This two-step routing is required to avoid the T.302 interdigit timeout
when dialing on-net destinations. If the dialed destination is not a phone on the cluster, the globalized
number routed through the E164Routing CSS will match only the \+! pattern in the E164_part partition,
and the resulting call will be routed to the PSTN.

9-50 OL-21733-18
Chapter 9 Dial Plan
Figure 9-13 Variable-Length Dial Plans with Flat Addressing Without Site Codes
OnCluster_phones
\+33 123456789
OnCluster \+1 613 555 1234
...
NANP_loc2glob_part
9.1[2-9]XX[2-9]XXXXXX, pre-dot, prepend +
9011.!, pre-dot, prepend +
9011.!#, pre-dot, prepend +, strip trailing #
E164Routing
CDG RG
Devices
French_loc2glob_part
Paris
CDGDevices 00.XXXXXXXXX, pre-dot, prepend +33 V

000.!, pre-dot, prepend + V
000.!#, pre-dot, prepend +, strip trailing # CDG
Gateways
Devices
Ottawa
E164_part Local YOW RG

YOWDevices PSTN Route
\+!
LOC RL group V
\+16135551XXX V
\+33123456XXX
YOW
254272
Gateways
This configuration variant allows you to simplify the dialing rules to be followed by the users. If the
destination is located within the site, use abbreviated dialing (omitted from Figure 9-13 for clarity). If
the destination is outside the site, whether it is on-net or off-net, dial it in the off-net PSTN form.
• Because you are effectively forcing on-net PSTN calls, remember to configure AAR so that calls
can still be placed across the PSTN when the IP WAN bandwidth is not sufficient.
• The placed-calls directory displays digit strings as they were dialed by the user. For example, if the
user dialed 1000 and a call was placed to phone +16135551000, the placed-calls directory would
display 1000, thus allowing for direct redialing of the number without having to edit the dial string.
• The missed-calls and received-calls directories display phone numbers as they appeared when the
call was offered to the phone. Because the DNs are configured as E.164 numbers with +, one-touch
dialing is possible. In Figure 9-13, note that the device CSS of the phones can route calls directly to
the DNs using the globalized E.164 form, including the + sign.

OL-21733-18 9-51
Chapter 9 Dial Plan
Deploying Dialed Pattern Recognition in SIP Phones

The dialed pattern recognition capabilities of SIP phones need to take into account the typical dialing
habits to be expected from users within the enterprise. Typically any combination of the following
patterns may be in use in most enterprises:
• An abbreviated dialing pattern for calls within the same site (In the case of uniform on-net dial plans,
the abbreviated dialing pattern could be used for inter-site calls.)
• An inter-site dialing pattern, typically used in variable on-net dial plans when using site codes and
an on-net access code such as 8
• An off-net dialing pattern for local calls
• An off-net dialing pattern for long-distance calls
• Emergency call patterns, with and without the off-net access code
• An off-net dialing pattern for international calls
Table 9-6 and Table 9-7 show an example of the SIP dial rules that could be employed in an enterprise
with the following dial plan characteristics:
• Abbreviated dialing is four digits (irrespective of whether abbreviated dialing is used for inter-site
calls or not)
• Inter-site calls use 8 as an on-net access code, followed by seven digits representing the site code
and DN
• Emergency dialing is allowed as 911 and as 9911
• Local seven-digit calls use 9 as an off-net access code, followed by the seven digits
• Local ten-digit calls use 9 as an off-net access code, followed by the ten digits
• Long-distance calls are dialed as 91 and ten digits
• International calls are dialed as 9011 followed by a variable quantity of digits, and dialing can be
terminated by #.
Pattern recognition is concerned only with automating the collection of user digit input, to be forwarded
automatically to Unified CM without requiring inter-digit timeout or pressing the Dial key. All
enforcement of class of service is handled by the various calling search spaces chosen from within
Unified CM. That is why all phones are configured with SIP dial rules allowing the recognition of
international dialing, for example, even if not all phones will be assigned to an unrestricted class of
service.
The dial plan characteristics listed above are representative of the variable-length on-net dial plan with
flat addressing (see Deploying Variable-Length On-Net Dial Plans with Flat Addressing, page 9-43).
From the standpoint of pattern recognition, this dial plan is compatible with the uniform on-net dial plan
and the variable-length on-net dial plan with partitioned addressing (see Deploying Uniform On-Net
Dial Plans, page 9-40).
For each pattern in Table 9-6 and Table 9-7, the description provides the pattern in equivalent
Unified CM notation. The tables provide the SIP dial rules for both the 7905_7912 and
7940_7960_OTHER cases.
Note The 7905_7912 SIP dial rules are limited to 128 characters, and the 7940_7060_OTHER SIP dial rules
are limited to 8K (8,192) characters.

9-52 OL-21733-18
Chapter 9 Dial Plan
Table 9-6 7940_7960_OTHER Dial Rule
Description Pattern Timeout Effect

Abbreviated 2XXX 2... 0 The combination of these six ranges represents the four-digit
Abbreviated 3XXX 3... 0 abbreviated dialing patterns that could be used at any site. As
any string matching [2-7]XXX is dialed, it is sent to Unified CM
Abbreviated 4XXX 4... 0 immediately (timeout = 0).
Abbreviated 5XXX 5... 0
Inter-site dialing 8,....... 0 Upon recognition of 8, secondary dial tone is played and seven
8.XXXXXXX more digits are collected, followed by immediate forwarding to
Unified CM (timeout = 0).
Emergency 911 9,11 0 Upon recognition of 9, secondary dial tone is played and the
digits 11 are collected, with immediate forwarding to
Emergency 9.911 9,911 0 Upon recognition of 9, secondary dial tone is played and the
digits 911 are collected, with immediate forwarding to
Local PSTN 7-digits 9,....... 3 Upon recognition of 9, secondary dial tone is played and seven
more digits are collected. Timeout of 3 seconds allows the user
to continue dialing when local PSTN ten-digits dialing is
configured.
Local PSTN 10-digits 9,........... 0 Upon recognition of 9, secondary dial tone is played and ten
more digits are collected, with immediate forwarding to
Long Distance 9,1.......... 0 Upon recognition of 9, secondary dial tone is played and ten
more digits are collected, with immediate forwarding to
International with 9,011* 6 Upon recognition of 9, secondary dial tone is played, then 011
6 seconds inter-digit and a variable quantity of digits are collected. Timeout of
timeout 6 seconds allows for user to pause dialing without triggering a
call to an incomplete string.
International with # as 9,011*# 0 Upon recognition of 9, secondary dial tone is played, then 011
end of dialing and a variable quantity of digits are collected, terminated by #.
Immediate forwarding to Unified CM (timeout = 0).
Operator 0 0 As soon as 0 is detected, immediate forwarding to Unified CM
(timeout = 0).

OL-21733-18 9-53
Chapter 9 Dial Plan
Table 9-7 7905_7912 Dial Rule
Description Pattern Effect

Abbreviated 2XXX 2...t0 The combination of these six ranges represents the four-digit abbreviated
Abbreviated 3XXX 3...t0 dialing patterns that could be used at any site. As any string matching
[2-7]XXX is dialed, it is sent to Unified CM immediately (t 0).
Abbreviated 4XXX 4...t0
Inter-site dialing 8.......t0 The digit 8 and seven more digits are collected, followed by immediate
8.XXXXXXX forwarding to Unified CM (t0).
Emergency 911 911t0 The digits 911 are collected, with immediate forwarding to Unified CM
(t0).
Emergency 9.911 9911t0 The digits 9911 are collected, with immediate forwarding to Unified CM
(t0).
Local 7-digits and LD 9.......t4>#....t1 The digit 9 and seven more digits are collected, with 4 seconds allowed
for up to four other digits to be dialed. If another four digits are entered,
they are sent to Unified CM after 1 second. The # would be recognized
as the terminating character after 9 and seven digits are entered.
International 9011>#t6- The digits 9 011 and a variable quantity of other digits are collected.
Timeout of 6 seconds allows for user to pause dialing without triggering
a call to an incomplete string. The # is allowed as terminating character.
Operator 0 As soon as 0 is detected, immediate forwarding to Unified CM (timeout
= 0).
Building Classes of Service for Unified CM

Unified CM 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 Unified CM systems to implement classes of service. Both approaches are based on
the fundamental functionality of the line and device calling search space.
The device calling search space can be determined dynamically based on where in the network the phone
is physically located, as determined by the phone's IP address, if Device Mobility is configured. See
Device Mobility, page 9-112, for more details.
Building Classes of Service for Unified CM with the Traditional Approach

With Unified CM, you can define classes of service for IP Telephony users by combining partitions and
device calling search spaces with external route patterns, as follows:
• Place external route patterns in partitions associated with the destinations they can call. While you
could place all route patterns in a single partition, you can achieve more refined call restriction
policies by associating the route patterns with partitions according to the destinations they can call.

9-54 OL-21733-18
Chapter 9 Dial Plan
For example, if you place local and international route patterns in the same partition, then all users
can reach both local and international destinations, which might not be desirable. Cisco recommends
that you group route patterns in partitions according to the reachability policies for the various
classes of service.
• Configure each calling search space to be able to reach only the partitions associated with its call
restriction policy. For example, configure the local calling search space to point to the internal and
local partitions, so that users assigned to this calling search space can place only internal and local
calls.
• Assign these calling search spaces to the phones by configuring them on the Unified CM device
pages. In this way, all lines configured on the device automatically receive the same class of service.
Figure 9-14 shows a simple example for a single-site deployment.
Figure 9-14 Basic Example of Classes of Service Using the Traditional Approach

Calling Spaces Partitions Lists Groups Devices
Search
Space
assigned Internal_pt
to device All IP Phones
Internal_css
based on
911
class of Route
service 9.911 Patterns
Local_css Local_pt
9.[2-9]XXXXXX
IP
PSTN PSTN PSTN
LD_css LD_pt RL RG V
9.1[2-9]XX
[2-9]XX XXX
Intl_pt
9.011!
Intl_css 9.011!#
114720
With this approach, the device calling search space performs two distinct logical functions:
• Path selection
The calling search space contains specific partitions, which in turn contain specific route patterns
that point to specific PSTN gateways through route lists and their associated route groups.
• Class of service
By selectively including certain partitions and not others in the device calling search space, you
effectively apply calling restrictions to certain groups of users.
As a consequence, when you apply this approach to a multisite deployment with centralized call
processing, you have to replicate partitions and calling search spaces for each site because for each site
you have to create classes of service and, at the same time, route the PSTN calls out of the local branch
gateways, as illustrated in Figure 9-15. Alternatively, you can configure the route patterns to point to

OL-21733-18 9-55
Chapter 9 Dial Plan
route lists referencing the Standard Local Route Group, thus allowing the actual egress gateway to be
determined by the calling phone's device pool. This allows for the pattern to be reused between sites
while retaining site specificity of call routing.
Figure 9-15 Calling Search Spaces and Partitions Needed with the Traditional Approach
Calling Search
Spaces Partitions Route Lists/Route Groups
OnCluster
IP Phones
Site1Internal
Shared
Device Calling Search
VM ports, MeetMe...
Spaces (4 for site 1)
Site1Local
Site1Emergency
9.11
Site1National 9.911
Site1Local
9.[2-9]XXXXXX
Site1International Site1National 1RL 1RG
• 9.1 [2-9]XX [2-9]XX XXXX
• Site1International
• 9.011! V
SiteNInternal 9.011!# V
Site 1
•
Device Calling Search
SiteNEmergency Gateways
Spaces (4 for site N)
9.11 •
SiteNLocal •
9.911
SiteNLocal
9.[2-9]XXXXXX
SiteNNational
SiteNNational NRL NRG
9.1 [2-9]XX [2-9]XX XXXX
SiteNInternational SiteNInternational 141883
9.011! V
9.011!# V
Site 1
Gateways
To facilitate on-net dialing between sites when applying this dial plan approach to a multisite
deployment with centralized call processing, place all IP phone DNs in an on-cluster or internal partition
that can be reached from the calling search spaces of all sites. Note that this is not possible if the IP phone
DNs overlap.

9-56 OL-21733-18
Chapter 9 Dial Plan
Extension Mobility Considerations with the Traditional Approach

When using the Extension Mobility feature, the dialing restrictions of a phone are a function of the
logged-in (or logged-out) status of the phone. Typically, a logged-out phone should be restricted to
calling other phones and services (such as 911), but access to local or toll calls through the PSTN are
restricted. Conversely, a phone where a user is logged-in should allow calls according to that user's
dialing privileges and should route those calls to the appropriate gateway (for example, a co-located
branch gateway for local calls).
With the traditional approach for building classes of service, consider the following guidelines to apply
calling restrictions when using Extension Mobility:
• At each site, configure the device calling search space for all IP phones to point to only PSTN
emergency services (using the local gateway).
• Configure the line calling search spaces for IP phones used for Extension Mobility in a logged-out
state to point to internal numbers only.
• For each Extension Mobility user, configure the line calling search space within the device profile
to point to internal numbers and the additional PSTN route patterns allowed for their specific class
of service (again, using an appropriate gateway according to company policy).
Note that, when an Extension Mobility user who is normally based in Site 1 logs into an IP phone in
Site 2, the path selection for PSTN calls will change as follows:
• Emergency calls will be correctly routed using Site 2's PSTN gateway because the emergency
services are provided by the device calling search space of the IP phone at Site 2.
• All other PSTN calls will be routed according to the Extension Mobility user's profile (more
specifically, the line calling search space configured in the device profile). Typically, this means that
these PSTN calls will traverse two WAN links and use Site 1's gateway to access the PSTN.
You can use one of the following methods to modify this behavior and ensure that PSTN calls are always
routed via the local PSTN gateway even when Extension Mobility users roam across different sites:
• Include local PSTN route patterns in the device calling search space and remove them from the line
calling search space within the device profile. This method ensures that local PSTN calls will be
routed via the co-located branch gateway, but it also means that users will be able to dial these calls
even without logging into the IP phones. Long-distance and international calls will still be routed
according to the Extension Mobility user's device profile, so this solution is suitable only if these
calls are usually routed via a centralized gateway.
• Define multiple device profiles for each user, one for each site to which they usually roam. Each
device profile is configured so that its line calling search space points to PSTN route patterns that
use the local gateway for that site. This method might prove burdensome to configure and manage
if a significant number of users roam to a significant number of sites.
• Implement the line/device approach described in the next section on Building Classes of Service for
Unified CM with the Line/Device Approach, page 9-58.
Note When Cisco Emergency Responder is used, the site-specific calling search space configured on the
device should include the partition containing the 911 CTI route point pointing to Cisco Emergency
Responder. This same partition can also contain a translation pattern 9.911 pointing to the same 911 CTI
route point, to allow users to dial 9911 when trying to reach emergency services.

OL-21733-18 9-57
Chapter 9 Dial Plan
Building Classes of Service for Unified CM 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 Unified CM, and how the line calling search space partitions appear first in
the resulting calling search space (see Calling Privileges in Unified CM, page 9-101), you can apply the
following general rules to the line/device approach:
• Use the device calling search space to provide call routing information (for example, which gateway
to select for PSTN calls).
• Use the line calling search space to provide class-of-service information (for example, which calls
to allow).
To better understand how to apply these rules, consider the example shown in Figure 9-16, 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 9-16 Key Concepts in the Line/Device Approach
Line CSS “Blocked”

Line CSS Route/Translation Pattern
selectively blocks 15644
15644
Block Int'l Partition
15644
undesired routes
9.011! Resulting CSS
(according to Your current options
Redail NewCall CFwdAll more
class of service) Line Block Int'l Partition

9.011!
PSTN Partition
Device CSS
PSTN Partition ...
9.011!
Device CSS 9.[2-9]XXXXXX

allows access to
114722
IP 9.1 [2-9]XX [2-9]XX XXXX

all external routes “Routed” Route Patterns
Device 9.011!
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.

9-58 OL-21733-18
Chapter 9 Dial Plan
It is possible to use route patterns instead of translation patterns to block calls within the line calling
search space. To configure a blocked route pattern, first create a "dummy" gateway with an unused IP
address and place it into a "dummy" route list and route group construct. Then point the route pattern to
the dummy route list. The main difference between using a route pattern and a translation pattern to
block calls is the end-user experience when trying to dial a blocked number, as follows:
• When a route pattern is used, the end users will be able to dial the entire number and only then will
they hear a fast-busy tone.
• When a translation pattern is used, the end users will hear a fast-busy tone as soon as the number
they are dialing can no longer match any allowed pattern. This behavior assumes an IP phone
running SCCP, or an Type-B IP phone running SIP with no SIP dial rules configured in the phone.
Follow these guidelines to implement the line/device approach in a multisite deployment with
centralized call processing:
• Create an unrestricted calling search space for each site and assign it to the phone's device calling
search space. This calling search space should contain a partition featuring route patterns that route
the calls to the appropriate gateway for the phone's location (for example, a co-located branch
gateway for emergency services and a centralized gateway for long-distance calls).
• Create calling search spaces containing partitions featuring blocked translation/route patterns for
those types of calls not part of the user's dialing privileges, and assign them to the user's lines. For
instance, if a user has access to all types of calls except international, that user's line (or lines) should
be configured with a calling search space that blocks the 9.011! route pattern.
Figure 9-17 shows an example of how these guidelines can apply to a multisite deployment with N sites.

OL-21733-18 9-59
Chapter 9 Dial Plan
Figure 9-17 Calling Search Spaces and Partitions Needed with the Line/Device Approach

Spaces Partitions Lists Groups
OnCluster
IP Phones
Shared
Device CSS (1 for site 1)
VM Ports, MeetMe...
Site1PSTN
Site1Devices 911
9.911
9.[2-9]XXXXXX
1 RL 1 RG
9.1 [2-9]XX [2-9]XX XXXX
9.011! V
Site 1
9.011!#
Device CSS (1 for site N)
Gateways
SiteNPSTN
911
SiteNDevices 9.911
9.[2-9]XXXXXX
N RL N RG
9.1 [2-9]XX [2-9]XX XXXX
9.011! V
Site N
9.011!# Gateways
BlockLocalPSTN
Internal
9.[2-9]XXXXXX
Line CSSs (4 Global)
BlockNationalPSTN
Local
9.1 [2-9]XX [2-9]XX XXXX
BlockIntlPSTN
9.011!
National
9.011!#
Empty
114723
International NoBlock
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.

9-60 OL-21733-18
Chapter 9 Dial Plan
Consequently, you can use the following formulas to calculate the total number of calling search spaces
and partitions needed:
Total Partitions = (Number of classes of service) + (Number of sites) + (1 Partition for all IP phone
DNs)
Total Calling Search Spaces = (Number of classes of service) + (Number of sites)
Note These values represent the minimum numbers of partitions and calling search spaces required. You may
need additional partitions and calling search spaces for special devices and applications, as well as for
on-net patterns for other call processing agents.
Note If Cisco Emergency Responder is used, the 911 CTI route pattern and 9.911 translation pattern can be
placed in the global On-Cluster partition.
When applied to centralized call processing deployments with large numbers of sites, the line/device
approach drastically reduces the number of partitions and calling search spaces needed. For example, a
deployment with 100 remote sites and 4 classes of service requires at least 401 partitions and 400 calling
search spaces with the traditional approach but only 105 partitions and 104 calling search spaces with
the line/device approach.
However, the line/device approach relies on the fact that you can globally identify the types of PSTN
calls that must be restricted for certain classes of service (for example, local, long-distance, and
international calls). If the national numbering plan of your country does not allow this global
identification of the different types of calls, the efficiency of this approach (in terms of configuration
savings) is lower than that indicated in the formulas above.
For example, in France the numbering plan is based on five area codes, from 01 to 05 (plus the 06 area
code for cellular phones), followed by eight digits for the subscriber number. The key characteristic is
that each PSTN destination is reached by dialing exactly the same number (for example,
01XXXXXXXX for Paris numbers, 04XXXXXXXX for Nice numbers, and so on), whether calling from
the same local area or from a different area. This means that it is not possible to block access to
long-distance calls with a single partition and a single route pattern because the concept of
"long-distance call" changes depending on the area where the calling party is located. (For example, a
call to 014455667788 is a local call if the caller is in Paris but a long-distance call is the caller is in Nice
or Lyon.)
In such cases, you will have to configure additional sets of blocking calling search spaces and partitions,
one for each area within which local and long distance calls are dialed the same way. In the example of
France, you would have to defining five additional blocking calling search spaces and partitions, one for
each area code, as shown in Table 9-8:
Table 9-8 The Line/Device Approach Applied to the French National Numbering Plan
Calling Search Space Partition Blocked Route Patterns

Internal_css BlockAllNational_pt 0.0[1-6]XXXXXXXX
BlockIntl_pt 0.00!, 0.00!#
Local01_css BlockLD01_pt 0.0[2-6]XXXXXXXX

OL-21733-18 9-61
Chapter 9 Dial Plan
Table 9-8 The Line/Device Approach Applied to the French National Numbering Plan
Calling Search Space Partition Blocked Route Patterns

LD_css BlockIntl_pt 0.00!, 0.00!#
Intl_css NoBlock_pt none
Guidelines for the Line/Device Approach
Consider the following guidelines when using the line/device approach:

• For this approach to work, the blocked patterns configured within the line calling search space must
be at least as specific as the route patterns configured within the device calling search space.
Wherever possible, Cisco recommends that you configure the blocked patterns as more specific than
the routed ones, to avoid any possibility of error. Use extra care when dealing with the @ wildcard
because the patterns defined within it are very specific.
• AAR is triggered when on-net DNs are dialed. Access to these DNs can be controlled by the same
processes described previously. AAR uses a different calling search space for rerouted calls. In most
cases, the AAR calling search space can be the same as the site-specific, unrestricted device calling
search space because it can never be dialed directly by end users.
• Refer to the section on Call-Forward Calling Search Spaces, page 9-104, for guidance on using the
line/device approach for Call Forward All actions.
Note The priority order between line and device is reversed for CTI devices (CTI route points and CTI ports).
For these devices, the partitions in the device calling search space are placed before the line calling
search space in the resulting calling search space. Therefore, the line/device approach cannot be applied
to CTI devices such as Cisco IP SoftPhone unless you are careful not to rely solely on the concatenation
order for pattern selection but instead ensure that the desired blocked pattern's precision is greater in all
cases than that of the permitted pattern(s).
Globalized Numbers and Class of Service
System administrators using the line-device approach for calling search spaces should be aware that the
blocked patterns used in the line CSS of endpoints might have to block not only the localized form but
also the globalized form of calls. While the localized form of a number lends itself to classification as
local, regional, or national, the globalized form does not. This can lead to class-of-service disparities,
where direct user dialing is subjected to a class of service while one-touch dialing from the missed and
received calls lists is not.
For example, consider creating a local class of service for the city of Ottawa, Ontario, Canada. All local
calls in Ottawa fall into the area codes 613 and 819, and local calling is implemented using 10-digit
dialing. If only localized user input is allowed on a phone in Ottawa, the class of service "local" can be
imposed on a phone by allowing only calls made in the form 9[2-9]XX[2-9]XXXXXX. Any call made

9-62 OL-21733-18
Chapter 9 Dial Plan
to a national (long distance) destination would start with a different dialing form (off-net access code 9
followed by the national steering code 1, followed by the number), as would international calls (9
followed by 011). The form of the call defines its class.
If one-touch redial is to be implemented, the global form of local numbers is to be allowed in the phone's
dial plan. For a dial plan based on line-device approach, where class-of-service is implemented through
blocked patterns addressed by line calling search spaces, this means that a series of blocked patterns has
to be implemented to allow only calls to area codes 613 and 819. This could be achieved, for example,
by the following blocked patterns:
\+1[^68]!
\+16[^1]!
\+161[^3]!
\+18[^1]!
\+181[^9]!
Typically we require a blocked pattern per significant digit and digit string to be allowed. The above set
of blocked patterns would allow local calls to be one-touch dialed from the missed or received calls list.
The situation becomes more complicated, however, because not all 613 and 819 area code destinations
are local calls. While the localized patterns will permit a user to initiate a call only to local destinations
(by dialing 9 819 or 9 613 as the beginning of the dial string), the globalized patterns will allow a user
to receive a call from a non-local number in area code 613 or 819, go to the received calls list, and
one-touch dial the number back, matching the globalized patterns. In such instances, the global form
blocked patterns should be refined to represent exactly the local calling area. For the example above, this
would entail defining the exact subset of area codes 613 and 819 that are within the local calling area for
Ottawa. The set of refined blocked patterns can become very complex, depending on the structure of the
local calling area.
Also, these +E.164 blocked patterns, in contrast to the localized form, are site-specific and cannot be
reused for other sites. The line calling search space inherits this site specificity, so that the line calling
search space implementing class-of-service "local" for Ottawa in the above example is specific to the
site in Ottawa. This fundamentally breaks the whole idea of the line-device approach to decrease the
number of required calling search spaces by creating classes of services through site-unspecific calling
search spaces that can be used universally for all sites.
Extension Mobility Considerations for the Line/Device Approach
When using the Extension Mobility feature, the line/device approach provides a natural way to
implement the dialing restrictions of a phone as a function of the logged-in (or logged-out) status of the
phone. Typically, a logged-out phone should be restricted to calling other phones and services (such as
911), but access to local or toll calls through the PSTN are restricted. Conversely, a phone where a user
is logged-in should allow calls according to that user's dialing privileges and should route those calls to
the appropriate gateway (for example, a co-located branch gateway for local calls).
With the line/device approach for building classes of service, you can simply apply the same rules
described in the previous section to the Extension Mobility device profile construct. Consider the
following guidelines to apply calling restrictions when using Extension Mobility:
• At each site, configure the device calling search space for all IP phones to point to a site-specific
partition that contains all possible PSTN route patterns and that routes them appropriately (for
example, using the local gateway for emergency and local calls and a centralized gateway for long
distance calls).

OL-21733-18 9-63
Chapter 9 Dial Plan
• Configure the line calling search space for all IP phones (or the line calling search space for the
default logout device profile) to point to a global calling search space featuring blocked
translation/route patterns that block all calls except those to be allowed when no user is logged in
(for example, internal extensions and emergency services).
• For each Extension Mobility user, configure the line calling search space within the device profile
to point to a global calling search space featuring blocked translation/route patterns to selectively
block the PSTN calls that are not to be allowed for their specific class of service (for example, block
only international calls). If some users must have unrestricted calling privileges, assign them to a
line calling search space featuring an empty partition.
The key advantage of using the line/device approach for extension mobility is that, in a multisite
deployment with centralized call processing, appropriate call routing is ensured even when users log in
to IP phones located at branch sites different from their home site, as illustrated in Figure 9-18.
Figure 9-18 Extension Mobility with the Line/Device Approach
Headquarters
M Unified CM
M M
Cluster
Line CSS PSTNBlock M M
Device CSS HQ_all IP
V
Line CSS NoBlock IP
Device Profile
PSTN IP WAN
Line CSS PSTNBlock PSTNBlock

114724
Device CSS Br1_all Br2_all

IP IP
Branch 1 Branch 2
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).

9-64 OL-21733-18
Chapter 9 Dial Plan
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 9-19, 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 9-19 Call Forwarding Considerations for Extension Mobility with the Line/Device
Approach
IP WAN
PSTN 1 PSTN 2 Device profile CSS’s
CFwdAll: Site1_all
Line: NoBlocks
Site 1 Site 2
EM user
moves IP
IP IP IP IP
A B C D
Physical Device CSS’s

Line: BlockPSTN
114725
Device: Site2_all
As described in the section on Call-Forward Calling Search Spaces, page 9-104, 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.

OL-21733-18 9-65
Chapter 9 Dial Plan
If the user now configures the phone to forward all calls to a PSTN number, any forwarded call will use
the Site1_all calling search space, which still points to the Site 1 gateway. This condition results in the
following behavior:
• Incoming PSTN calls enter the IP network at the Site 1 gateway and are hairpinned back into the
PSTN within the same gateway.
• Calls originating from Site 1 phones (such as phone A) are correctly forwarded to the PSTN via the
Site 1 gateway.
• Calls originating from Site 2 phones (such as phone C) traverse the WAN to Site 1 and access the
PSTN via the Site 1 gateway. The same behavior applies to calls originating from other sites within
the same Unified CM cluster.
Keep this behavior in mind when designing the network and training the users.
Building Classes of Service for Unified CM for +E.164 Dial Plans with the
Traditional Approach and Local Route Group
Trying to support globalized +E.164 dialing with the line-device approach has the problem that the
required blocked patterns for some classes of service make the line calling search spaces site-specific,
which negates the design goal of the line-device approach to minimize the number of required calling
search spaces by using site-unspecific line calling search spaces addressing the appropriate blocked
patterns. With that in mind, the advantage of the line-device approach over the traditional approach
seems to be minimal, especially since the introduction of the concept of local route groups with
Unified CM 7.0. The use of local route groups allows the administrator to move the site-specific egress
gateway selection from the route pattern to the local group selection specific to the calling device. This
selection process uses the local route group configured in the calling device's device pool.
The main difference of this approach is that the effective class of service is not the result of combining
route patterns on the device blocked patterns on the line, but is the direct result of any pattern addressed
by the single class-of-service specific calling search space. (See Figure 9-20.)

9-66 OL-21733-18
Chapter 9 Dial Plan
Figure 9-20 Class of Service "International" for +E.164 Dial Plans
DN
SJCInternational All IP Phone DNs (+E.164)
SJCIntra
SJCtoE164local
Locally significant
translations to
XYZ RG
9.1[2-9]XX[2-9]XXXXXX, V
Pre-Dot, Prefix + V
PSTNInternational
\+[^1]!

patterns group
SJCPSTNLocal
\+1408[2-9]XXXXXX, Urgent
292520
Figure 9-20 shows an example of how to implement class of service "international" for a single site in
the US. In this concept, the local habitual dialing is normalized to +E.164 through translation patterns
in partitions SJCIntra, SJCtoE164local, and UStoE164International.
The translation in partition SJCIntra implements 4-digit intra-site dialing, assuming that all local DIDs
of the site are in the range +1 408 555 1XXX. Local dialing (9+7) for the site in San Jose is implemented
by the translation pattern in partition SJCtoE164local by again transforming the local habitual dialing to
+E.164. The same is true for partition UStoE164International, which implements the globalization of
US habitual PSTN dialing to international and national destinations.
The naming convention used here helps to identify which pieces of the dial plan need to be replicated to
support multiple classes of service, sites, and dialing domains. If the name includes the specification of
a site (for example, SJC in partition name SJCE164Local), then this element needs to be replicated for
every site. If the name includes the specification of a class of service (for example, International in
USE164International), then it needs to be replicated for every class of service. If the name does not
include the specification of a site (for example, partition USPSTNNational), then it can be reused for all
sites.
The single calling search space creating the requested class of service can be used as a line or device
calling search space. In deployments that support mobility features such as extension mobility or device
mobility, the line calling search space has to be used to enable the user to keep his class of service when
roaming.

OL-21733-18 9-67
Chapter 9 Dial Plan
Using Non +E.164 Directory Numbers

The above example assumes that all directory numbers are configured as +E.164 so that the directory
numbers can be matched directly after normalizing the local habitual dialing to +E.164. In cases where
directory numbers are not configured as +E.164, an intermediate routing step is required to again map
from the internal +E.164 routing to the format of the configured DNs. (See Figure 9-21.)
Figure 9-21 Indirection to Support Non +E.164 Directory Numbers

nonE164DN
nonE164DN All IP Phone DNs (+E.164)
DN
SJCInternational +E.164 patterns of DN ranges
SJCIntra
SJCtoE164local
Locally significant
translations to
XYZ RG
9.1[2-9]XX[2-9]XXXXXX, V
Pre-Dot, Prefix + V
PSTNInternational
\+[^1]!

patterns group
SJCPSTNLocal
292521
The additional indirection step shown in Figure 9-21 makes sure that all directory numbers not in +E.164
format can be reached by dialing either the local habitual format or +E.164. Partition DN in this case
does not hold the actual directory numbers but a set of urgent translation patterns matching all on-net
DID ranges. If, for example, a site uses DID range +1 408 555 1XXX and the directory numbers are
configured as E.164 without the leading +, then an urgent translation pattern \+.14085551XXX needs to
be created in partition DN with the digit discard instruction set to discard pre-dot. A user with extension
+1 408 555 1234 can now be reached from other users using the calling search space in the example by
dialing:
• 1234: Translation pattern in partition SJCIntra transforms dialed digits to +14085551234,
translation pattern +14085551XXX in partition DN transforms to 14085551234, and then we get a
match on the directory number in partition nonE164DN.
• 95551234: Translation pattern in partition SJCtoE164local globalizes the dialed digits and then the
call flow is the same as for 4-digit intra-site dialing.

9-68 OL-21733-18
Chapter 9 Dial Plan
• 914085551234: Translation pattern in partition UStoE164International globalizes the dialed digits

and then the call flow is the same as for 4-digit intra-site dialing.
• +14085551234: Translation pattern +14085551XXX in partition DN transforms to 14085551234
and then we get a match on the directory number in partition nonE164DN.
Keep in mind that, when using non +E.164 directory numbers, you will have to make sure that the calling
party number for calls originating from these lines is set to +E.164 to ensure that correct calling party
information can be delivered for all call flows. This can be achieved by setting the external phone number
mask to +E.164 for all line appearances and configuring the calling party transformations on the
translation patterns in partition DN to use the external phone number mask. Another option to globalize
non +E.164 directory numbers is to use the incoming call’s calling party transformation calling search
space on the phone or phone's device pool. This method is supported in Cisco Unified CM 9.0 and later
releases, and is the recommended way to globalize directory numbers. Using globalization based on this
calling search space has the advantage of also working with URI-dialed call flows for which number
transformations configured on translation patterns are not applicable.
Overlaps Between Directory Numbers and International PSTN Dialing

Directory numbers in Unified CM always are stored in digit analysis as non-urgent patterns. This can
lead to the situation that dialing an international on-net destination causes a partial overlap with the
international PSTN route pattern \+[^1]!. For example, if a user in San Jose dials +496100773 and that
happens to be a directory number configured on the system, then the call using the schema without the
additional indirection step (Figure 9-20) will hit the interdigit time-out limit because, although we have
a match on directory number \+496100773, there is another potential match on the variable length
pattern \+[^1]! in partition PSTNInternational. One way to avoid this is to add specific, urgent
fixed-length route patterns to the PSTNInternational partition for all countries where we have on-net
directory numbers. The urgent route pattern in the PSTNInternational partition will terminate digit
collection, but Unified CM will then still route the call to the best match, which in this case is the
directory number in partition DN. This approach works only for countries with a fixed-length national
numbering plan. If the national numbering plan is a variable-length numbering plan (such as in
Germany), the only way to solve the overlap between directory numbers and the variable-length PSTN
route pattern is to implement the intermediate routing step as shown in Figure 9-21. In this case the
urgent translation patterns in partition DN serve the purpose of adding urgent patterns to digit analysis
that will make sure that digit collection terminates as soon as a known on-net destination is dialed.

OL-21733-18 9-69
Chapter 9 Dial Plan
Other Classes of Service

Based on the example in Figure 9-20 and Figure 9-21, other classes of service such as "national" and
"local" are created by removing the unnecessary PSTN route patterns and recreating the dialing
normalization of the local habitual dialing habits. (See Figure 9-22.)
Figure 9-22 Class of Service "National" for +E.164 Dial Plans
DN
SJCNational All IP Phone DNs (+E.164)
SJCIntra
SJCtoE164local
Locally significant
translations to
UStoE164National globalize user input
USE164National 9011.!, Urgent, Pre-Dot, Prefix +
XYZ RG
9.1[2-9]XX[2-9]XXXXXX, V
Pre-Dot, Prefix + V
PSTN USPSTNNational
route \+1XXXXXXXXXX, Urgent
patterns
SJCPSTNLocal Local
LOC RL Route
group
292522
Figure 9-22 shows how to build class of service "national." Comparing this schema to class of service
"international" in Figure 9-20, we see that partitions SJCIntra, SJCtoE164local, USPSTNNational, and
SJCPSTNLocal can be reused and so can calling search spaces DN and SJCE164Local. The dialing
normalization in USToE164National has to be recreated because using the dialing normalization as
defined by the patterns in partition UStoE164International in Figure 9-20 would also grant access to the
international PSTN route pattern \+[^1] in partition PSTNInternational. This is a result of the fact that,
in the definition of a translation pattern, we define a single calling search space that has to be used after
applying the called and calling party transformations defined in the translation pattern. Because a calling
search space is equivalent to a class of service, the translation patterns inherit the class-of-service
specificity of the egress calling search space defined in the translation patterns and thus also become
class-of-service specific.
Dialing normalization in partition UStoE164National does include dialing normalization patterns for the
local habitual international dialing 9011 because we need to support international dialing to international
on-net destinations (directory numbers in partition DN outside the US).

9-70 OL-21733-18
Chapter 9 Dial Plan
Classes of service "local" and "internal" can be created using the same approach. Partition
SJCPSTNLocal is not really required to build class of service "international", but providing this
differentiated PSTN access from the beginning permits reuse of partitions SJCPSTNLocal and
SJCtoE164Local for class of service "local". Keep in mind that partition SJCPSTNLocal cannot be
reused for class of service "internal," which should not provide access to the PSTN. For this class of
service the dialing normalization of the local dialing has to be replicated as shown in Figure 9-23.
Figure 9-23 Class of Service "internal" for +E.164 Dial Plans
DN
SJCInternal All IP Phone DNs (+E.164)
SJCIntra
SJCtoE164Internal
9.[2-9]XXXXXX, Pre-Dot, Prefix +1408
Locally significant
translations to
UStoE164Internal globalize user input
9011.!, Urgent, Pre-Dot, Prefix +
9.1[2-9]XX[2-9]XXXXXX,
Pre-Dot, Prefix +
292523
Emergency Calls
Access to emergency services has to be granted to all users. This can be achieved either by adding the
partition with the emergency number route patterns to each calling search space or by enabling access
to the emergency number route patterns through the device-level calling search space. If access to
emergency numbers is granted through the device calling search space, then in roaming scenarios (for
example, extension mobility) the user has to dial emergency services using the habitual dialing of the
visited site, while access to emergency numbers through the line calling search space would allow the
user to dial emergency services using the habitual dialing of the home site. This differentiation obviously
is important only if the habitual dialing of emergency services differs between home and visiting site as,
for example, in the case of a European user (emergency number 112) logging into an US phone
(emergency number 911).
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:
• Unified CM multisite deployments with centralized call processing
• Cisco Unified Communications Manager Express (Unified CME) deployments

OL-21733-18 9-71
Chapter 9 Dial Plan
Under normal conditions in Unified CM multisite deployments with centralized call processing, classes
of service are implemented using partitions and calling search spaces within Unified CM. 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 Unified CME 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,
page 9-140, for details on COR).
You can adapt the COR functionality to replicate the Unified CM concepts of partitions and calling
search spaces by following these main guidelines:
• Define tags for each type of call that you want to distinguish.
• Assign "basic" outgoing corlists (equivalent to partitions), containing a single member tag, to the
respective POTS dial peers that route each type of call.
• Assign "complex" incoming corlists (equivalent to calling search spaces), containing subsets of the
member tags, to the IP phones that belong to the various classes of service.
Figure 9-24 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.

9-72 OL-21733-18
Chapter 9 Dial Plan
Figure 9-24 Building Classes of Service for Cisco SRST using COR
Incoming COR Lists (“CSS’s”) Outgoing COR Lists (“partitions”)

Other phones
call-manager-fallback dial-peer voice 1pots
IP destination-patttern 911
cor incoming InternalCSS default corlist outgoing EmPt
IP
member Emergency
IP member Emergency
dial-peer voice 2pots

2001 cor incoming 1 LocalCSS 2001 destination-pattern 9[2-9]......
member Emergency corlist outgoing LocalPt
IP
member Local member Local

destination-pattern 91[2-9].........
corlist outgoing LDPt
member LD
cor incoming 2 IntlCSS 2002

2002 member Emergency dial-peer voice 1pots
destination-pattern 9011T
member Local
IP corlist outgoing IntlPt
member LD
member Intl member Intl
114726
The following steps provide examples and guidelines for implementing a Cisco IOS solution like the one
shown in Figure 9-24.
Step 1 Using the dial-peer cor custom command, define meaningful tags for the various types of calls
(Emergency, VMail, Local, LD, Intl):
dial-peer cor custom
name Emergency
name VMail
name Local
name LD
name Intl
Step 2 Using the dial-peer cor list command, define basic corlists to be used as partitions, each containing a
single tag as a member:
dial-peer cor list EmPt
member Emergency
dial-peer cor list VMailPt

member VMail
dial-peer cor list LocalPt

member Local
dial-peer cor list LDPt

member LD

OL-21733-18 9-73
Chapter 9 Dial Plan
dial-peer cor list IntlPt

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

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

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

member Emergency
member VMail
member Local
member LD
member Intl
Step 4 Using the command corlist outgoing corlist-name, configure the basic “partition” corlists as outgoing
corlists assigned to the corresponding POTS dial peers:
dial-peer voice 100 pots
corlist outgoing EmPt
destination-pattern 911
no digit-strip
direct-inward-dial
port 1/0:23

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

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

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

corlist outgoing IntlPt
destination-pattern 9011T
prefix-digits 011

9-74 OL-21733-18
Chapter 9 Dial Plan
direct-inward-dial
port 1/0:23
Step 5 Using the cor incoming command within the call-manager-fallback configuration mode, configure the
complex corlists acting as "calling search spaces" to be incoming corlists assigned to the various phone
DNs:
call-manager-fallback
cor incoming InternalCSS default
cor incoming LocalCSS 1 3001 - 3003
cor incoming LDCSS 2 3004
cor incoming IntlCSS 3 3010
When deploying COR for SRST, keep in mind the following limitations:
• In SRST version 2.0, available on Cisco IOS Release 12.2(8)T or later, the maximum number of cor
incoming statements allowed under call-manager-fallback is 5 (plus the default statement).
• In SRST version 3.0, available on Cisco IOS Release 12.3(4)T or later, the maximum number of cor
incoming statements allowed under call-manager-fallback is 20 (plus the default statement).
Therefore, if the phone DNs of users with non-default privileges are not consecutive and the SRST site
is relatively large, you might have to reduce the number of classes of service in SRST mode to
accommodate all the DNs without exceeding these limitations.
Although the preceding example is based on Cisco SRST, the same concepts can be applied to a Cisco
Unified Communications Manager Express (Unified CME) deployment, except for the following
considerations:
• With Unified CME, the corlist expressing the class of service (equivalent to a calling search space)
can be assigned directly to the individual IP phones by using the cor {incoming | outgoing}
corlist-name command under the ephone-dn dn-tag configuration mode.
• According to COR general rules, all IP phones for which no corlist is configured have unrestricted
access to all dial peers, regardless of their outgoing corlist. Unified CME has no mechanism
equivalent to the cor incoming corlist-name default command, which applies default restrictions to
all phones.
Deploying Call Coverage

Call coverage functionality is a key feature in many IP telephony deployments. Many customer-focused
service companies have to route customer calls to the appropriate service representatives expeditiously.
This section focuses on design guidelines for using the hunting mechanism based on hunt pilots, hunt
lists, and line groups in Cisco Unified CM Release 4.1 to manage call distribution, and it covers the
following main topics:
• Deploying Call Coverage in a Multisite Centralized Call Processing Model, page 9-76
• Deploying Call Coverage in a Multisite Distributed Call Processing Model, page 9-77
Note Call coverage functionality does not offer call queues per se, and the caller is presented with ringback
tone until a destination is found for the call. To provide prompting, music on hold, and so forth, Cisco
offers many contact center technologies such as the Cisco Unified Customer Voice Portal (CVP). For
more information on the contact center technologies available from Cisco, refer to the documentation at
http://www.cisco.com/go/ucsrnd.

OL-21733-18 9-75
Chapter 9 Dial Plan
Deploying Call Coverage in a Multisite Centralized Call Processing Model

Figure 9-25 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 9-25 Call Coverage Between Multiple Sites in a Centralized Call Processing Deployment
PSTN
1 Incoming call via PSTN
to the branch router
Call sent to Central Site

2 Unified CM for routing
M
M M
IP WAN V M M
Hunt Pilot
Call sent to Branch IP Phones

3 via IP WAN for coverage first
Hunt List
IP
IP
IP First Line Line Second
Branch IP choice Group Group choice
Phones
Branch site
IP
IP
IP
126914
Central Site IP Phones
Central Site
In centralized IP telephony systems, features such as Automated Alternate Routing (AAR) and
Survivable Remote Site Telephony (SRST) may be enabled for high availability. Consider the following
guidelines when deploying call coverage functionality with AAR or SRST features enabled:
• Automated Alternate Routing (AAR)
The line group members can be assigned in different locations and regions. Call admission control
implemented through locations works as expected. However, a call being distributed from a hunt
pilot will not use AAR to reroute a call if Unified CM blocks the call to one of its line group
members due to insufficient WAN bandwidth. Instead, Unified CM distributes the call to the next
available member or next available line group.
Note Cisco strongly recommends that you use only AAR to voicemail ports within line groups.

9-76 OL-21733-18
Chapter 9 Dial Plan
• Survivable Remote Site Telephony (SRST)

– When Unified CM receives a call for the hunt pilot, and if some of its line group members are
at the remote sites operating in SRST mode, then Unified CM skips those members and
distributes the call to the next available line group member. From the perspective of
Unified CM, the members operating in SRST mode are unregistered, and hunt pilot calls are not
forwarded to unregistered members.
– When a router operating in SRST mode receives a call for the hunt pilot, call coverage
functionality is unavailable. The call fails if no configuration is added to reroute the call to a
registered and available extension. You can use the alias or the default-destination command
under the call-manager-fallback mode in Cisco IOS to reroute the call destined for the hunt
pilot to an operator extension or to voicemail.
Deploying Call Coverage in a Multisite Distributed Call Processing Model

Beginning with Cisco Unified CM 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 CM Release 4.1, can be used to match a route pattern
that in turn points to gateways or trunks.
Figure 9-26 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 9-26 Call Coverage Between Clusters in a Distributed Call Processing Deployment
M M
M M M M
M M M M
Hunt Fwd
Hunt Pilot Hunt Pilot
No Answer
Route
Hunt List Hunt List
Pattern
IP WAN
Line Group Line Group

V
Intercluster
Trunk
IP IP IP IP IP IP
126915
IP Phones IP Phones
Cluster A Cluster B

OL-21733-18 9-77
Chapter 9 Dial Plan
Dial Plan Elements
Tip In distributed call processing deployments, load sharing of incoming hunt pilot calls can be managed
using Cisco VoIP gateways and gatekeepers. In the event that the call is not answered within one cluster,
it can overflow to another cluster for service. Calls can also be sent through gateways or trunks to IVR
treatment. Tool Command Language (TCL) IVR applications can be implemented on Cisco IOS
gateways.
Guidelines
When deploying call coverage functionality in a distributed call processing model, if calls are distributed
across multiple clusters, then the route patterns should be properly configured to account for any digit
transformations that are done on the outbound or inbound route group devices. If digit transformations
are not done, then the configured route patterns and hunt pilot should be the same on all clusters,
otherwise the calls will not be distributed appropriately.
Hunt Pilot Scalability

Cisco recommends using the following guidelines when deploying call coverage using top-down,
circular, and longest-idle algorithms:
• The Unified CM cluster supports a maximum of 15,000 hunt list devices.
• The hunt list devices may be a combination of 1500 hunt lists with 10 IP phones in each hunt list,
or a combination of 750 hunt lists with 20 IP phones in each hunt list.
Note When using the broadcast algorithm for call coverage, the number of hunt list devices is limited
by the number of busy hour call attempts (BHCA). Note that a BHCA of 10 on a hunt pilot
pointing to a hunt list or hunt group containing 10 phones and using the broadcast algorithm is
equivalent to 10 phones with a BHCA of 10.
• Cisco recommends having a maximum of 35 directory numbers in a single line group configured to
send the calls simultaneously to all DNs. Additionally, the number of broadcast line groups depends
on the BHCC. If there are multiple broadcast line groups in a Unified CM system, the number of
maximum directory numbers in a line group must be less than 35. The number of busy hour call
attempts (BHCA) for all the broadcast line groups should not exceed 35 calls set up per second.
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, page 9-80
• User Input on Type-A SIP Phones, page 9-81
• User Input on Type-B SIP Phones, page 9-83
• SIP Dial Rules, page 9-84
• Call Routing in Unified CM, page 9-87
• Calling Privileges in Unified CM, page 9-101
• Translation Patterns, page 9-107

9-78 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
• Automated Alternate Routing, page 9-108

• Device Mobility, page 9-112
• Extension Mobility, page 9-114
• Immediate Divert (iDivert), page 9-120
• Hunt Lists and Line Groups, page 9-121
• Time-of-Day Routing, page 9-124
• Call Routing in Cisco IOS with H.323 Dial Peers, page 9-128
• Call Routing in Cisco IOS with a Gatekeeper, page 9-131
• Calling Privileges in Cisco IOS with H.323 Dial Peers, page 9-140
• Digit Manipulation in Cisco IOS with H.323 Dial Peers, page 9-142
User Interface on IP Phones

Different types of IP telephones accept keypad input and present visual information in different ways.
For purposes of this chapter only, we define the following phone types:
• Type-A phones — Include the Cisco Unified IP Phone 7905, 7912, 7940, and 7960.
• Type-B phones — Include the Cisco Unified IP Phone 6901, 6911, 6921, 6941, 6945, 6961, 7906,
7911, 7921, 7925, 7931, 7941, 7942, 7945, 7961, 7962, 7965, 7970, 7971, 7975, 8961, 9951, and
9971.
Calling Party Transformations on IP Phones

Calling Party Transformation Patterns allow the system to adapt the global form of the calling party's
number used to route calls to phones, into the local form preferred by users.
The transformation pattern consists of a numerical representation of the calling party number to be
matched. The syntax used is the same as that of other patterns such as route patterns, transformation
patterns, directory numbers, and so forth.
The transformation operators include discard digit instructions (for example, pre-dot), a calling party
transformation mask, prefix digits, and control over the calling party presentation (either Default,
Allowed, or Restricted). Calling party transformation patterns can be configured to use the calling party's
external phone number mask as the calling party number.
Partitions and calling search spaces control which calling party transformation patterns are applied to
which phones. Phones can use either the device pool's calling party transformation calling search space
(CSS) or the device's own calling party transformation CSS, in reverse order of precedence. Calls sent
to phones are not processed through called party transformation patterns.
For phones, calling party transformation patterns affect the number displayed while the phone is ringing.
The corresponding entry in the missed and received calls directories holds both the transformed number
and also the original pre-transformation number. The transformed number is displayed in the directories´
list, but the number used for callback is the pre-transformation number.

OL-21733-18 9-79
Chapter 9 Dial Plan
Dial Plan Elements
Support for + Dialing on the Phones

On Type-A phones, it is not possible to dial a + sign using the keypad. On Type-B phones it is possible
to dial a + sign by pressing and holding either the 0 key (Cisco Unified IP Phones 7921 and 7925) or the
* key (all other phone models). On Cisco Unified Personal Communicator endpoints, the + sign may be
typed in by the user using the computer's keyboard or entered as part of the input string when using a
click-to-dial function of the endpoint.
On Type-A phones, there is no support to display the + sign.
On Type-B phones and on Cisco Unified Personal Communicator, incoming calls can present a calling
party number including + as part of the number. When a call is offered to a phone, the number shown on
the ringing phone is processed by any configured calling party number transformation patterns. The
missed and received calls directories hold both the original pre-transformation number and the
transformed number. The number displayed in the list will be the transformed number, and the
pre-transformation number will be visible only when looking at the details of an entry. The number
dialed from the directory is the original pre-transformation number, allowing the one-touch dialing of
previously received calls featuring the + sign as part of the calling number.
Example 9-1 Calling Party Number with + Dialing
A Type-B phone in New York receives a call from +1 408 526 4000. Calling party transformation
patterns are placed in the calling party transformation CSS in the phone's device pool. One of the patterns
is configured as: \+1.!, strip pre-dot.
As the call rings in, the called phone displays an incoming calling party number of 4085264000. After
the call is answered and released, the received-calls directory displays the last call as 408 526 4000, but
the number called when the user initiated the callback from the directory entry is +1 408 526 4000.
User Input on SCCP Phones

IP phones using SCCP report every single user input event to Unified CM immediately. For instance, as
soon as the user goes off-hook, a signaling message is sent from the phone to the Unified CM 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 Unified CM server's configured dial plan.
As other user events are detected by the phone, they are relayed to Unified CM individually. A user who
goes off-hook and then dials 1000 would trigger five individual signaling events from the phone to
Unified CM. 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 Unified CM to the phone
in response to the dial plan configuration. (See Figure 9-27.)

9-80 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Figure 9-27 User Input and Feedback for SCCP Phones
SCCP message sent Dial Plan

with each user action (digit analysis)
Off-hook, digit 1, digit 0, digit0, digit 0 M

Any phone model
running SCCP IP Dial tone on/off, screen update, etc. M M
M M
Dialing actions:
141878
1000
Signaling
It is neither required nor possible to configure dial plan information on IP phones running SCCP. All dial
plan functionality is contained in the Unified CM cluster, including the recognition of dialing patterns
as user input is collected.
If the user dials a pattern that is denied by Unified CM, reorder tone is played to the user as soon as that
pattern becomes the best match in Unified CM'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.
User Input on Type-A SIP Phones

Type-A phones differ somewhat from Type-B phones in their behavior, and Type-A phones do not offer
support for Key Press Markup Language (KPML) as do Type-B phones. (See User Input on Type-B SIP
Phones, page 9-83.)
Type-A IP phones using SIP offer two distinct modes of operation:
• No SIP Dial Rules Configured on the Phone, page 9-81
• SIP Dial Rules Configured on the Phone, page 9-82
No SIP Dial Rules Configured on the Phone

Figure 9-28 illustrates the behavior of a SIP Type-A phone with no dial plan rules configured on the
phone. In this mode of operation, the phone accumulates all user input events until the user presses either
the # key or the Dial softkey. This function is similar to the "send" button used on many mobile phones.
For example, a user making a call to extension 1000 would have to press 1, 0, 0, and 0 followed by the
Dial softkey or the # key. The phone would then send a SIP INVITE message to Unified CM to indicate
that a call to extension 1000 is requested. As the call reaches Unified CM, it is subjected to the dial plan
configuration for this phone, including all the class-of-service and call-routing logic implemented in
Unified CM's dial plan.

OL-21733-18 9-81
Chapter 9 Dial Plan
Dial Plan Elements
Figure 9-28 User Input and Feedback for Type-A SIP Phones with No Dial Rules Configured
SIP INVITE message

sent when user presses Dial Plan
the Dial key (digit analysis)
"call for 1000" M

Existing SIP phone
such as 7940, 7960 IP Call in progress, call connected, call denied, etc. M M
M M
Dialing actions:
141879
1 0 0 0 Dial
Signaling
If the user dials digits but then does not press the Dial softkey or the # key, the phone will wait for
inter-digit timeout (15 seconds by default) before sending a SIP INVITE message to Unified CM. For
the example in Figure 9-28, dialing 1, 0, 0, 0 and waiting for inter-digit timeout would result in the phone
placing a call to extension 1000 after ten seconds.
Note If the user presses the Redial softkey, the action is immediate; the user does not have to press the Dial
key or wait for inter-digit timeout.
If the user dials a pattern that is denied by Unified CM, the user must enter the entire pattern and press
the Dial key, and the INVITE message must be sent to Unified CM, before any indication that the call is
rejected (reorder tone) is sent to the caller. For instance, if all calls to NPA 976 are denied, the user would
have to dial 919765551234 and press Dial before the reorder tone would be played.
SIP Dial Rules Configured on the Phone

SIP dial rules enable the phone to recognize patterns dialed by users. Once the recognition has occurred,
the sending of the SIP INVITE message to Unified CM is automated and does not require the user to
press the Dial key or wait for the inter-digit timeout. (For more details, see SIP Dial Rules, page 9-84.)
For example, if a branch location of the enterprise requires that calls between phones within the same
branch be dialed as four-digit extensions, the phone could be configured to recognize the four-digit
patterns so that the user is not required to press the Dial key or wait for the inter-digit timeout. (See
Figure 9-29.)
Figure 9-29 User Input and Feedback for Type-A SIP Phones with Dial Rules Configured
SIP INVITE message

sent when pattern Dial Plan
is recognized (digit analysis)
"call for 1000" M

Existing SIP phone
such as 7940, 7960 IP Call in progress, call connected, call denied, etc. M M
M M
Dialing actions:
141880
1000
Signaling
Pattern 1...
Timeout 0

9-82 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
In Figure 9-29, the phone is configured to recognize all four-digit patterns beginning with 1 and has an
associated timeout value of 0. All user input actions matching the pattern will trigger the sending of the
SIP INVITE message to Unified CM immediately, without requiring the user to press the Dial key.
Type-A phones using SIP dial rules offer a way to dial patterns not explicitly configured on the phone.
If a dialed pattern does not match a SIP dial rule, the user can press the Dial key or wait for inter-digit
timeout.
If a particular pattern is recognized by the phone but blocked by Unified CM, the user must dial the entire
dial string before receiving an indication that the call is rejected by the system. For instance, if a SIP dial
rule is configured on the phone to recognize calls dialed in the form 919765551234 but such calls are
blocked by the Unified CM dial plan, the user will receive reorder tone at the end of dialing (after
pressing the final 4 key).
User Input on Type-B SIP Phones

Type-B phones differ somewhat from Type-A phones in their behavior, and Type-B phones offer support
for Key Press Markup Language (KPML) but Type-A phones do not. (See User Input on Type-A SIP
Phones, page 9-81.)
Type-B IP phones running SIP offer two distinct modes of operation:
• No SIP Dial Rules Configured on the Phone, page 9-83
• SIP Dial Rules Configured on the Phone, page 9-84
No SIP Dial Rules Configured on the Phone

Type-B IP telephones offer functionality based on the Key Press Markup Language (KPML) to report
user key presses. Each one of the user input events will generate its own KPML-based message to
Unified CM. From the standpoint of relaying each user action immediately to Unified CM, this mode of
operation is very similar to that of phones running SCCP. (See Figure 9-30.)
Figure 9-30 User Input and Feedback for Type-B SIP Phones with No Dial Rules Configured
KPML events reported Dial Plan

in SIP NOTIFY messages (digit analysis)
Off-hook, digit 1, digit 0, digit 0, digit 0 M

SIP enhanced phone
such as 7971 IP Call in progress, call connected, call denied, etc. M M
M M
Dialing actions:
141881
1000
Signaling
Every user key press triggers a SIP NOTIFY message to Unified CM to report a KPML event
corresponding to the key pressed by the user. This messaging enables Unified CM's digit analysis to
recognize partial patterns as they are composed by the user and to provide the appropriate feedback, such
as immediate reorder tone if an invalid number is being dialed.
In contrast to Type-A IP phones running SIP without dial rules, Type-B SIP phones have no Dial key to
indicate the end of user input. In Figure 9-30, a user dialing 1000 would be provided call progress
indication (either ringback tone or reorder tone) after dialing the last 0 and without having to press the
Dial key. This behavior is consistent with the user interface on phones running the SCCP protocol.

OL-21733-18 9-83
Chapter 9 Dial Plan
Dial Plan Elements
SIP Dial Rules Configured on the Phone

Type-B IP phones can be configured with SIP dial rules so that dialed pattern recognition is
accomplished by the phone. (See Figure 9-31.)
Figure 9-31 User Input and Feedback for Type-B SIP Phones with Dial Rules Configured
SIP INVITE message

sent when pattern Dial Plan
is recognized (digit analysis)
"call for 1000" M

SIP enhanced phone
such as 7971 IP Call in progress, call connected, call denied, etc. M M
M M
Dialing actions:
141882
1000
Signaling
Pattern 1...
Timeout 0
In Figure 9-31, the phone is configured to recognize all four-digit patterns beginning with 1, and it has
an associated timeout value of 0. All user input actions matching these criteria will trigger the sending
of a SIP INVITE message to Unified CM.
Note As soon as SIP dial rules are implemented on Type-B IP phones, KPML-based dialing is disabled. If a
user dials a string of digits that do not match a SIP dial rule, none of the individual digit events will be
relayed to Unified CM. Instead, the entire dialed string will be sent en-bloc to Unified CM once the
dialing is complete (that is, once inter-digit timeout has occurred).
Type-B phones using SIP dial rules offer only one way to dial patterns not explicitly configured on the
phone. If a dialed pattern does not match a SIP dial rule, the user has to wait for inter-digit timeout before
the SIP NOTIFY message is sent to Unified CM. Unlike Type-A IP phones, Type-B IP phones do not
have a Dial key to indicate the end of dialing, except when on-hook dialing is used. In the latter case, the
user can press the “dial” key at any time to trigger the sending of all dialed digits to Unified CM.
Note When a Type-B phone registers with the SRST router, the configured SIP dial rules are disabled.
If a particular pattern is recognized by the phone but blocked by Unified CM, the user must dial the entire
dial string before receiving an indication that the call is rejected by the system. For instance, if a SIP dial
rule is configured on the phone to recognize calls dialed in the form 919765551234 but such calls are
blocked by the Unified CM dial plan, the user will receive reorder tone at the end of dialing (after
pressing the 4 key).
SIP Dial Rules

Cisco Unified CM offers SIP dial rule functionality to allow phones to perform pattern recognition as
user input is collected. For example, a phone can be configured to recognize the well established pattern
911 and to send a message to Unified CM to initiate an emergency call immediately, while at the same
time allowing the user to enter patterns of variable length for international numbers.

9-84 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
It is important to note that pattern recognition configuration on the phone through the use of SIP dial
rules does not supersede the Class of Service and Route Plan configurations of Unified CM. A phone
might very well be configured to recognize long-distance patterns while Unified CM is configured to
block such calls because the phone is assigned a class of service allowing only local calls.
There are two types of SIP dial rules, based on the phone model on which they will be deployed:
• 7905_7912 (Used for Cisco Unified IP Phones 7905 and 7912)
• 7940_7960_OTHER (Used for all other IP phone models))
There are four basic Dial Parameters that can be used as part of a dial rule:
• Pattern
This parameter is the actual numerical representation of the pattern. It can contain digits, wildcards,
or instructions to play secondary dial tone. The following table provides a list of values and their
effect for the two types of dial rules.
Dial Rule Type

Pattern 7905_7912 7940_7960_OTHER
Digits 0 Corresponding digit Corresponding digit
through 9
. Matches any digit (0 through 9) Matches any character (0
though 9, *, #)
- Indication that more digits can be n/a
entered. Must be at the end of an
individual rule.
# Input termination key. Place the > n/a
character in the dial rule to indicate
the character position after which the
# key will be recognized as input
termination. For instance, in 9>#...,
the # character would be recognized
any time after 9 has been pressed.
tn Indicates a timeout value of n n/a
seconds. For example, 1…t3 would
match 1000 and trigger the sending of
an invite to Unified CM after 3
seconds.
rn Repeats the last character n times. For n/a
example, 1.r3 is equivalent to 1….
S When a pattern contains the modifier n/a
S, all other dial rules after this pattern
are ignored. S effectively causes rule
matching to cease.

OL-21733-18 9-85
Chapter 9 Dial Plan
Dial Plan Elements
Dial Rule Type

Pattern 7905_7912 7940_7960_OTHER
* Input termination key. Place the > Matches one or more
character in the dial rule to indicate characters. For instance,
the character position after which the pattern 1* would match 10,
* key will be recognized as input 112, 123456, and so forth.
termination.
, n/a Cause the phone to play
secondary dial tone. For
instance, 8,…. would cause
the user to hear secondary
dial tone after 8 is pressed.
• IButton
This parameter specifies the button to which the dial pattern applies. If the user is initiating a call
on line button 1, only the dial patterns specified for Button 1 apply. If this optional parameter is not
configured, the dial pattern applies to all lines on the phone. This parameter applies only to the Cisco
SIP IP Phones 7940, 7941, 7942, 7945, 7960, 7961, 7962, 7965, 7970, 7971, and 7975. The button
number corresponds to the order of the buttons on the side of the screen, from top to bottom, with 1
being on top button.
• Timeout
This parameter specifies the time, in seconds, before the system times out and dials the number as
entered by the user. To have the number dialed immediately, specify 0. This parameter is available
only for 7940_7960_OTHER dial rules. If this parameter is omitted, the phone's default inter-digit
timeout value is used (default of 10 seconds).
• User
This parameter represents the tag that automatically gets added to the dialed number. Valid values
include IP (when SIP Call Agents other than Unified CM are deployed) and Phone. This parameter
is available only for 7940_7960_OTHER dial rules. This parameter is optional, and it should be
omitted in deployments where Unified CM is the only call agent.
Note The Cisco Unified IP Phone 7905 and 7912 choose patterns in the order in which they have been created
in the SIP dial rules, whereas all the other phone models choose the pattern offering the longest match.
The following table shows which pattern would be chosen if a user dialed 95551212.
SIP Dial Rules 7905_7912 7940_7960_OTHER

.……. Chooses first matching pattern: Chooses longest matching
9……. …….. pattern: 9…….

9-86 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Call Routing in Unified CM

All numeric dialing destinations configured in Unified CM 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, Unified CM uses closest-match logic to select which pattern to match from
among all the patterns in its numeric call routing table. In practice, when multiple potentially matching
numeric patterns are present, the destination pattern is chosen based on the following criteria:
• It matches the dialed string, and
• Among all the potentially matching patterns, it matches the fewest strings other than the dialed
string.
For example, consider the case shown in Figure 9-32, where the call routing table includes the patterns
1XXX, 12XX, and 1234.
Figure 9-32 Unified CM Call Routing Logic Example
1XXX Gateways
User A dials
"1200" 12XX
V
V
Pool of IP Phones
User B dials
"1212" 121X
IP IP
IP
IP Phone
126911
User C dials 1234

"1234" IP
When user A dials the string 1200, Unified CM 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.

OL-21733-18 9-87
Chapter 9 Dial Plan
Dial Plan Elements
Note Whenever a directory number (DN) is configured in Cisco Unified CM, it is placed in the call routing
table, regardless of whether the respective device (for example, an IP phone) is registered or not. An
implication of this behavior is that it is not possible to rely on secondary, identical patterns to provide
failover capabilities to applications when the application (and hence the primary pattern) is unregistered.
Because the primary pattern is permanently in the call routing table, the secondary pattern will never be
matched.
Support for + Sign in Patterns

The + sign can be used in all patterns within Unified CM, including route patterns, translations patterns,
and directory numbers. To use + in its literal sense, precede it with the escape character \ to differentiate
it from the regular expression operator +, which means one or more instances of the preceding character.
For example:
• \+14085264000 means +14085264000
• 2+ means 2, or 22, or 222, and so forth
External Routes in Unified CM

Unified CM 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 Unified CM 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. Unified CM 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 9-33 depicts the three-tiered architecture of the Unified CM
external route construct.

9-88 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Figure 9-33 External Route Pattern Architecture
Route Pattern
Route
• Matches dialed number for external calls
Pattern
• Performs digit manipulation (optional)
• Points to a route list for routing
Hunt/Route List
• Chooses path for call routing Route
• Per-route group digit manipulation List
• Points to prioritized route groups
1st Choice 2nd Choice

Route Group
Route Route
• Distributes calls to
Group Group
GWs/Trunks
Transformation Patterns Transformation Transformation

• Modifies calling (Cg) party Patterns Patterns
• Modifies called (Cd) party
GK
V V
Configuration Order
Devices IP WAN PSTN
• Gateways (H.323,
MGCP, SIP)
• Trunk (H.225,
ICT, SIP)
V
271554
M
The following sections describe the individual elements of the external route construct in Unified CM:
• Route Patterns, page 9-89
• Route Lists, page 9-93
• Route Groups, page 9-93
• Route Group Devices, page 9-96
Route Patterns
Route patterns are strings of digits and wildcards, such as 9.[2-9]XXXXXX, configured in Unified CM
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.

OL-21733-18 9-89
Chapter 9 Dial Plan
Dial Plan Elements
The @ Wildcard
• The @ wildcard is a special macro function that expands into a series of patterns representing the
entire national numbering plan for a certain country. For example, configuring a single unfiltered
route pattern such as 9.@ with the North American Numbering Plan really adds 166 individual route
patterns to the Unified CM internal dial plan database.
• It is possible to configure Unified CM to accept other national numbering plans. Once this is done,
the @ wildcard can be used for different numbering plans even within the same Unified CM cluster,
depending on the value selected in the Numbering Plan field on the Route Pattern configuration
page. For more information, please refer to the Cisco Unified CallManager Dial Plan Deployment
Guide, available at
• The @ wildcard can be practical in several small and medium deployments, but it can become harder
to manage and troubleshoot in large deployments because adopting the @ wildcard forces the
administrator to use route filters to block certain patterns (see Route Filters, page 9-90).
Route Filters
• Use route filters only with the @ route pattern to reduce the number of route patterns created by the
@ wildcard. A route filter applied to a pattern not containing the @ wildcard has no effect on the
resulting dial plan.
• The logical expression you enter with the route filter can be up to 1024 characters, excluding the
NOT-SELECTED fields.
• As you increase the number of logical clauses in a route filter, the refresh time of the configuration
page also increases and can become unacceptably long.
• For large-scale deployments, use explicit route patterns rather than the @ wildcard and route filters.
This practice also facilitates management and troubleshooting because all patterns configured in
Unified CM are easily visible from the Route Pattern configuration page.
International and Variable-Length Route Patterns

• International destinations are usually configured using the ! wildcard, which represents any quantity
of digits. For example, in North America the route pattern 9.011! is typically configured for
international calls. In most European countries, the same result is accomplished with the 0.00! route
pattern.
• The ! wildcard is also used for deployments in countries where the dialed numbers can be of varying
lengths. In such cases, Unified CM does not know when the dialing is complete and will wait for
15 seconds (by default) before sending the call. You can reduce this delay in any of the following
ways:
– Reduce the T302 timer (Service Parameter TimerT302_msec) to indicate end of dialing, but do
not set it lower than 4 seconds to prevent premature transmission of the call before the user is
finished dialing.
– Configure a second route pattern followed by the # wildcard (for example, 9.011!# for North
America or 0.00!# for Europe), and instruct the users to dial # to indicate end of dialing. This
action is analogous to hitting the "send" button on a cell phone.

9-90 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Overlap Sending and Overlap Receiving

In countries whose national numbering plan is not easily defined with static route patterns, you can
configure Unified CM for overlap sending and overlap receiving.
Overlap sending means that Unified CM 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, check the Allow Overlap
Sending box on the Route Pattern Configuration page. (In some early Unified CM 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 Unified CM 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, set the OverlapReceivingFlagForPRI service
parameter to True. (In some early Unified CM releases, the parameter name was
OverlapReceivingForPriFlag.)
Digit Manipulation in Route Patterns

• Digit manipulations configured on a route pattern affect the calling and called party number, no
matter what route group the call eventually takes. Digit manipulations configured in the route list's
view of its member route groups have a route-specific effect: only the transformations configured
on the route group used to place the call will be performed.
• Digit manipulation in the route list's view of its member route group overrides any digit
manipulation done in the route pattern.
• The calling and called party numbers resulting from the digit transformations configured in the route
pattern and/or route lists are then processed by any Transformation Patterns configured for the
devices contained in the chosen Route Group.
• If you configure digit manipulation in the route pattern, the Call Detail Record (CDR) records the
dialed number after the digit manipulation has occurred. If you configure digit manipulation only in
the route group, the CDR records the actual dialed number prior to the digit manipulation.
• Similarly, if you configure digit manipulation in the route pattern, the IP phone display of the calling
party will show the manipulated number. If you configure digit manipulation only in the route group,
the manipulations will be transparent to the end user.
Calling Line ID
• The calling line ID presentation can be enabled or disabled on the gateway and also can be
manipulated in the route pattern, based on site requirements.
• If you select the option Use Calling Party's External Phone Number Mask, then the external call uses
the calling line ID specified for the IP phone placing the call. If you do not select this option, then
the mask placed in the Calling Party Transform Mask field is used to generate the calling party ID.
Urgent Priority
• The Urgent Priority checkbox is often used to force immediate routing of certain calls as soon as a
match is detected, without waiting for the T302 timer to expire. For example, in North America, if
the patterns 9.911 and 9.[2-9]XXXXXX are configured and a user dials 9911, Unified CM has to
wait for the T302 timer before routing the call because further digits may cause the
9.[2-9]XXXXXX to match. If Urgent Priority is enabled for the 9.911 route pattern, Unified CM
makes its routing decision as soon as the user has finished dialing 9911, without waiting for the T302
timer.

OL-21733-18 9-91
Chapter 9 Dial Plan
Dial Plan Elements
• It is important to note that the Urgent Priority checkbox forces the T302 timer to expire as soon as
the configured pattern is the best match for the dialed number. This does not mean that the urgent
pattern has a higher priority than other patterns; the closest-match logic described in the section on
Call Routing in Unified CM, page 9-87, still applies.
For example, assume the route pattern 1XX is configured as urgent and the pattern 12! is configured
as a regular route pattern. If a user dials 123, Unified CM 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). Unified CM 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 T302 timer is aborted and because the
urgent-priority pattern is the best match, no further user input is expected. Unified CM routes the
call using pattern 12[2-5].
Call Classification
• Calls using this route pattern can be classified as on-net or off-net calls. This route pattern can be
used to prevent toll fraud by prohibiting off-net to off-net call transfers or by tearing down a
conference bridge when no on-net parties are present. (Both of these features are controlled by
Service Parameters within Unified CM Administration.)
• When the "Allow device override" box is enabled, the calls are classified based on the call
classification settings on the associated gateway or trunk.
Forced Account Codes (FAC)

• The Forced Account Codes (FAC) checkbox is used to restrict the outgoing calls when using a
particular route pattern. If you enable FAC through route patterns, users must enter an authorization
code to reach the intended recipient of the call.
• When a user dials a number that is routed through a FAC-enabled route pattern, the system plays a
tone that prompts for the authorization code. To complete the call, the user authorization code must
meet or exceed the level of authorization that is specified to route the dialed number.
• Only the authorization name appears in the call detail records (CDR); the authorization code does
not appear in the CDR.
• The FAC feature is not available if the "Allow overlap sending" checkbox is enabled.
Client Matter Codes (CMC)

• The Client Matter Code (CMC) checkbox is used to track calls to certain numbers when using a
particular route pattern. (For example, a company can use it to track calls to certain clients.)
• If you enable CMC for a route pattern, users must enter a code to reach the intended destination.
• When a user dials a number that is routed through a CMC-enabled route pattern, the system plays a
tone that prompts for the code. The user must enter the correct code in order to complete the call.
• Client Matter Codes appear in the call detail records so that they can be used by the CDR analysis
and reporting tool to generate reports for client billing and accounting.
• The CMC feature is not available if the "Allow overlap sending" checkbox is enabled.
• If both CMC and FAC are enabled, the user dials a number, enters the FAC when prompted to do so,
and then enters the CMC at the next prompt.

9-92 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
SIP Route Pattern

SIP route patterns are configured in Unified CM to route or block calls to external entities based on the
host portion (right-hand side) of SIP URIs. A SIP route pattern can point directly to a SIP trunk. SIP
route patterns matching on the host piece of a SIP URI can match on a domain name or an IP address,
both of which are possible as the right-hand side of a SIP URI. Wildcards can be used in domain name
SIP route patterns to match on multiple domains (for example, *.cisco.com and ccm[1-4].uc.cisco.com).
In IP address SIP route patterns, a subnet notation can be used (for example, 192.168.10.0/24).
Route Lists
A route list is a prioritized list of eligible paths (route groups) for an outbound call. 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 a PSTN gateway.
Route lists have the following characteristics:
• Multiple route patterns may point to the same route list.
• A route list is a prioritized list of route groups that function as alternate paths to a given destination.
For example, you can use a route list to provide least-cost routing, where the primary route group in
the list offers a lower cost per call and the secondary route group is used only if the primary is
unavailable due to an "all trunks busy" condition or insufficient IP WAN resources.
• Each route group in the route list can have its own digit manipulation. For example, if the route
pattern is 9.@ and a user dials 9 1 408 555 4000, the IP WAN route group can strip off the 9 1 while
the PSTN route group may strip off just the 9.
• Multiple route lists can contain the same route group. The digit manipulation for the route group is
associated with the specific route list that points to the route group.
• If you are performing several digit manipulations in a route pattern or a route group, the order in
which the transformations are performed can impact the resulting calling and called party numbers
used for the call. Unified CM performs the following major types of digit manipulations in the order
indicated:
1. Discarding digits
2. Called/calling party transformations
3. Prefixing digits
4. Called/calling party transformation patterns
Route Groups
Route groups control and point to specific devices, which are typically gateways (MGCP, SIP, or H.323),
H.323 or SIP trunks to a gatekeeper, remote Unified CM cluster, or Cisco Unified Border Element.
Unified CM sends calls to the devices according to the distribution algorithm assigned. Unified CM
supports top-down and circular algorithms.
Calling and Called Party Transformation Patterns

A calling party transformation pattern allows the system to adapt the global form of the calling party's
number into the local form required by off-cluster networks connected to the route group devices, such
as gateways or trunks.
A called party transformation pattern allows the system to adapt the global form of the called party's
number into the local form required by off-cluster networks connected to the route group devices.

OL-21733-18 9-93
Chapter 9 Dial Plan
Dial Plan Elements
Note Called party transformation patterns do not have any effect on phones. The called party transformation
pattern CSS of the device pool does not impart any effects on the phones to which it is assigned.
Both pattern types consist of a numerical representation of the calling or called party number to be
matched. The syntax used is the same as that of other patterns such as route patterns, transformation
patterns, directory numbers, and so forth. (See Figure 9-34.)
The transformation operators include discard digit instructions (for example, pre-dot), a calling party
transformation mask, prefix digits, and control over the calling party presentation (either Default,
Allowed, or Restricted). Calling party transformation patterns can be configured to use the calling party's
external phone number mask as the calling party number.
Partitions and calling search spaces control which calling party transformation patterns are applied to
which gateways or trunks. Gateways or trunks can use either their associated device pool's calling party
transformation CSS or the device's own calling party transformation CSS, in reverse order of precedence.
The same mechanism is used to control the applicability of called party transformation patterns.
Calling and called party transformation patterns configured on a Gateway Configuration page under Call
Routing Information - Outbound Calls affect the calling or called party number sent to the gateway,
as well as the calling or called party's numbering type and numbering plan. Calling party transformation
patterns applied under Incoming Calling Party Settings apply to calls coming from the gateway.

9-94 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Figure 9-34 Calling and Called Party Transformation Patterns
CSSs Partitions
NANP_called_xforms
pattern discard prefix type
France_CdPTP \+.1! pre-dot national
V \+.! pre-dot 011 national
V
French
HQ Gateways YOW_called_xforms
\+1.613[2-9]XXXXXX pre-dot subscriber
France_CgPTP
France_called_xforms
V pattern discard prefix type
V \+.! pre-dot 00 international

Nice
Gateways \+33.! pre-dot 0 national
NANP_calling_xforms
YOW_CdPTP pattern discard prefix type
\+1.! pre-dot national
V \+.! pre-dot 011 international
V
Ottawa
France_calling_xforms
Gateways
NANP_CgPTP \+.! pre-dot 00 international
271556
\+33.! pre-dot 0 national
Figure 9-34 illustrates how calling and called party transformation patterns would be applied to different
groups of gateways connected to the PSTN in different parts of the PSTN.
Within the North American Numbering Plan (NANP), gateways located in Ottawa, Canada (airport code
YOW) are assigned to the Calling Party Transformation CSS NANP_CgPTP, which contains partition
NANP_calling_xforms. Any call with a calling party number beginning with +1 (that is, originating from
within the NANP) would match both patterns configured within partition NANP_calling_xforms.
Following the best-match logic, the first pattern will be chosen, and the calling party number will be
stripped of the + sign and NANP country code 1. The remaining part of the calling party number will be
used as the calling party number sent to the PSTN, with numbering type set to National.
For example, if a call from +1 613 555 1234 were sent out the YOW gateways, the calling party number
would be transformed to 613 555 1234 with a numbering type set to National.
If a call from the same caller were to be sent to a French gateway, a different set of calling party
transformation patterns would apply. For example, if a call from +1 613 555 1234 were sent out a
gateway located in Nice, France (airport code NCE), the calling party transformation patterns contained
in partition France_calling_xforms would be applied. In this case, the calling party number would be
transformed to 001 613 555 1234 with the numbering type set to International.

OL-21733-18 9-95
Chapter 9 Dial Plan
Dial Plan Elements
Note Calling party number transformations may be overridden once the call is sent out the gateway. Many
service providers will not permit calling party numbers outside a given range, as determined by local
service agreements or regulations.
The same process applies to the called party number transformation patterns. For Ottawa gateways, the
assigned called party transformation CSS is YOW_CdPTP, which contains partitions
NANP_Called_xforms and YOW_Called_xforms. A call placed to a destination number within the
Numbering Plan Area 613 would match all patterns contained in these two partitions. However, the best
match process would select pattern \+1.613[2-9]XXXXXX.
For example, on a call placed to +1 613 555 9999 through the Ottawa gateways, the called party number
would be transformed to 516 555 9999 with a numbering type set to Subscriber.
Incoming Calling Party Settings (per Gateway)

Incoming calling party settings can be configured on individual gateways, at the device pool level, or at
the service parameter level, in order of precedence. For each numbering type (Subscriber, National,
International, or Unknown), Unified CM allows for the appropriate prefix digits to be configured.
Digits can be stripped from and prefixed to the string provided as the incoming party number. The
notation takes the form PP:SS, where PP represents the digits to be prefixed and SS represents a quantity
of digits to be stripped. The digit stripping operation is performed first on the incoming calling party
number, and then the prefix digits are added to the resulting string. For example, if the prefix digits field
is configured as +33:1 and the incoming calling party number is 01 58 40 58 58, the resulting string will
be +33 1 58 40 58 58.
In Cisco Unified CM 7.1, each numbering type can be configured with a Calling Search Space used to
apply Calling Party Transformation Patterns to the calls. The calling search space should contain
partitions containing calling party transformation patterns exclusively. This allows the modifications
applied to the calling party number to be based on the structure of the calling party number rather than
strictly on its numbering type. The calling party transformation patterns use regular expressions to match
the calling party number. The best-match process is used to choose between multiple matches, and the
selected pattern's Calling Party Transformations are applied to the call.
Route Group Devices

The route group devices are the endpoints accessed by route groups, and they typically consist of
gateways or trunks to a gatekeeper or to remote Unified CMs. You can configure the following types of
devices in Unified CM:
• Media Gateway Control Protocol (MGCP) gateways
• SIP gateways
• H.323 gateways
• H.225 trunk, gatekeeper controlled — trunk to standard H.323 gateways, via a gatekeeper
• Intercluster trunk, not gatekeeper controlled — direct trunk to another Unified CM cluster
• Intercluster trunk, gatekeeper controlled — trunk to other Unified CM clusters and/or H.323
gateways, via a gatekeeper
• SIP trunk — trunk to another Unified CM cluster, a Cisco Unified Border Element, a Session Border
Controller, or a SIP proxy

9-96 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Note Both the H.225 and intercluster trunk (gatekeeper controlled) will automatically discover if the other
endpoint is a standard H.323 gateway or a Unified CM and will select H.225 or Intercluster Trunk
protocol accordingly.
Local Route Group

Device pools can be associated with a local route group. Route patterns using the local route group offer
a unique characteristic: they allow for dynamic selection of the egress gateway, based on the device
originating the call. By contrast, calls routed by route patterns using static route groups will route the
call to the same gateway, no matter what device originated the call.
Example 9-2 Comparison of Local and Non-Local Route Groups
In Figure 9-35, a route pattern defined as 9.1[2-9]XX[2-9]XXXXXX points to a route list referencing a
non-local route group containing San Francisco gateways. If this route pattern is placed in a partition
contained in the calling search spaces of phones in Dallas, San Francisco, and New York, national calls
from devices in those three cities will egress to the PSTN in San Francisco.

OL-21733-18 9-97
Chapter 9 Dial Plan
Dial Plan Elements
Figure 9-35 Non-Local Route Group Behavior
CSSs Partitions Route Lists Route Groups
DFWDevices
DFWDevices
SFODevices
SFO RG
US_pstn_part US LOC
SFODevices RL V
9.1[2-9]XX[2-9]XXXXXX
V
SFO Gateways
JFKDevices
JFKDevices
271557
By contrast, if this same route pattern is modified to point to a route list containing the Standard Local
Route Group, then calls made from the Dallas site would egress to the PSTN through the Dallas gateway,
calls made from the New York site would egress to the PSTN through the New York gateway, and calls
made from the San Francisco site would egress to the PSTN through the San Francisco gateway.
The Device Mobility feature allows the device pool to be assigned to an endpoint based on the current
subnet to which it has roamed. This permits assignment of the local route group to be based on the site
where the phone is currently located.
Example 9-3 Device Mobility
A phone is moved from the San Francisco site to the New York site. Based on the phone's new IP address
(part of the IP subnet associated with the New York site), a New York device pool is assigned to the
phone. If the next call placed by the roaming phone matches a route pattern using a route list containing
the Standard Local Route Group, it will be routed through the New York gateway.
If a local route group is used in forwarded call scenarios where, for example, phone A calls phone B and
B is forwarded to a destination in the PSTN, then the route pattern in the call forward calling search
space of phone B determines the class of service for calls forwarded by phone B, whereas the local route

9-98 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
group associated with phone A's device pool is used to determine the egress gateways when hitting
Standard Local Route group in the route list selected by the route pattern found using phone B's call
forward calling search space. As a result, typically a gateway local to phone A is used for the forwarded
call. This makes sure that the caller ID of the initial caller (phone A) can be sent to the PSTN and that
this caller ID will not be screened by the provider.
Centralized Gateway with Local Failover to the PSTN

Local route groups simplify the local failover to the PSTN for systems where a centralized gateway is
configured. A single route list can be used to route PSTN calls for multiple sites while allowing local
failover to the gateway at the site of origin.
Example 9-4 Centralized Gateways and Local Failover
A company negotiates a favorable PSTN interconnection rate for a group of trunks located in Chicago.
If a route list includes a route group containing gateways in Chicago as its first entry and the Standard
Local Route Group as the second choice, then any call it processes will first be sent to the preferred
lower-cost gateways in Chicago. If a Chicago gateway is not available, if no ports are free, or if there is
not enough bandwidth to allow the call between the calling phone and the Chicago gateway, then the next
choice will be to attempt to route the call through the gateway co-located with the calling phone, as
determined by the local route group in the calling phone's device pool configuration. (See Figure 9-36.)
Figure 9-36 Centralized Gateway with Local Failover to the PSTN

ORD RG
V
V
ORD
Gateways
DFW Devices
DFW RG
First V
DFWDevices choice V
DFW
Gateways
SFO Devices
SFO RG
US_pstn_part Local
US LOC Route
SFODevices 9.1[2-9]XX[2-9]XXXXXX RL group V
V
Second SFO
choice Gateways
JFK Devices
JFKDevices Choice of local route JFK RG

group based on calling
device’s Device Pool
configuration V
V
254268
JFK
Gateways

OL-21733-18 9-99
Chapter 9 Dial Plan
Dial Plan Elements
Routing of SIP Requests in Unified CM

Routing of SIP requests received from SIP trunks or SIP endpoints follows certain rules to make sure
that both local and intercluster routing requirements are met. SIP requests are handled according to the
flowchart shown in Figure 9-37.
Figure 9-37 Call Routing Logic for numeric SIP Request
Is RHS the no Does RHS no Does RHS no Match RHS

IP address of a match match against SIP Route Route or block
cluster member? CFQDN? OTLD? Pattern?
yes yes yes
Does LHS no
Analyze LHS
find a match?
yes
292528
Route or block Offer call
The first step is to check whether the right-hand side of the SIP URI is an IP address of any server that
is a member of the Unified CM cluster or matches the cluster fully qualified domain name configured in
Unified CM enterprise parameters. In this case the left-hand side of the URI is considered to be a local
directory number and will be routed as a number using the calling device's calling search space.
The next step is to check whether the right-hand side of the SIP URI matches the organization’s top-level
domain configured in Unified CM enterprise parameters. If this is the case, again Unified CM will try to
route the call using the calling device's calling search space. But if no match can be found, then routing
will fall back to route the call by matching the right-hand side of the SIP URI against the configured SIP
route patterns.
Assuming a Unified CM cluster with cluster members having IP addresses 192.168.10.10,
192.168.10.11, 192.168.20.10, and 192.168.20.11, cluster fully qualified domain name configured as
ucm1.cisco.com, and organization top-level domain configured as cisco.com, then all of the following
SIP URIs would be routed to local directory number 1234:
• 1234@192.168.10.10
• 1234@192.168.10.11
• 1234@192.168.20.10
• 1234@192.168.20.11
• 1234@ucm1.cisco.com
• 1234@cisco.com
Assuming that no local directory number 1234 exists, the first five calls would fail immediately while
Unified CM would try to route the sixth call by matching cisco.com against the configured SIP route
patterns.

9-100 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Calling Privileges in Unified CM

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 Unified CM
are subjected to the dialing privileges implemented through the configuration of the following elements:
• Partitions, page 9-101
• Calling Search Spaces, page 9-102
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 9-38, 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 9-38 Partitions and Calling Search Spaces
CSS1 PartitionA
IP
PartitionA 2002 Lines
Phones 2001
PartitionB (Directory Numbers)
2000
Translation
15644
7 [Trans Mask: 2001] Patterns
15644
15644
"Dialable" devices
911
"Dialing" devices
Your current options

Redial NewCall CFwdAll more
CSS2
Lines PartitionB \+.! Route Patterns
9.[2-9]XX[2-9]XXXXXX
PartitionB
Application Numbers
CSS3 5000 (CTI Route Points, CTI Ports)
V
PartitionB
Gateways 900X Special numbers
PartitionA 99XX (MeetMe, CallPickup...)
8001
8001 Voice Mail Ports
CSS4
271555
PartitionA 9.011! Route Patterns

Applications
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 Unified CM, page 9-87, if two or more numeric dial plan entries (directory numbers, route
patterns, or so forth) overlap, Unified CM 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, Unified CM
selects the dial plan entry that appears first in the calling search space of the device making the call.

OL-21733-18 9-101
Chapter 9 Dial Plan
Dial Plan Elements
For example, consider Figure 9-39, 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, Unified CM
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, Unified CM 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 9-39 Impact of Partition Order on the Matching Logic
Calling Search Space

Partition_A
1XXX
User dials 23XX

"2345"
Device
IP
Partition_B
User dials
12XX
"1234"
23XX
114715
Note When multiple equal-precision matches occur in the same partition, Unified CM selects the entry that is
listed first in its local dial plan database. Since you cannot configure the order in which the dial plan
database lists dial plan entries, Cisco strongly recommends that you avoid any possibility of
equal-precision matches coexisting within the same partition because the resulting dial plan logic is not
predictable in such cases.
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 Unified CM 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 Unified CM call
routing engine. For more information on this feature, see Time-of-Day Routing, page 9-124.
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,
Unified CM 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 9-40.

9-102 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Figure 9-40 Concatenation of Line and Device Calling Search Spaces for IP Phones
Line CSS
15644
15644
Partition L1
15644
Partition L2 Resulting CSS

Your current options
Redial NewCall CFwdAll more
Partition L3 Partition L1
Line
Partition L2
Partition L3
Partition D1
Device CSS Partition D2
Partition D1 Partition D3
IP Partition D2
114716
Device Partition D3
Note When device mobility is not used, the device calling search space is static and remains the same even as
the device is moved to different parts of the network. When device mobility is enabled, the device calling
search space can be determined dynamically based on where in the network the phone is physically
located, as determined by the phone's IP address. See Device Mobility, page 9-112, for more details.
If the same route pattern appears in two partitions, one contained in the line's calling search space and
one contained in the device's calling search space, then according to the rules described in the section
on Partitions, page 9-101, Unified CM 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 Unified CM with the Traditional Approach, page 9-54, and Building
Classes of Service for Unified CM with the Line/Device Approach, page 9-58.
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 Communications Manager
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 Any dial plan entry left in the <None> partition is implicitly reachable by any device making a call.
Therefore, to avoid unexpected results, Cisco strongly recommends that you do not leave dial plan
entries in the <None> partition.

OL-21733-18 9-103
Chapter 9 Dial Plan
Dial Plan Elements
Note Cisco strongly recommends that you do not leave any calling search space defined as <None>. Doing so
can introduce dial plan behavior that is difficult to predict.
Special Considerations for Transformation Patterns
Calling and called transformation patterns are also placed in partitions, and those partitions are included
in calling search spaces (CSSs) but not in order to control calling privileges. The partitioning of
transformation patterns serves to choose which transformations are applied to which gateways, trunks,
or phones. Partitions contained in calling party transformation pattern CSSs should contain only calling
party transformation patterns. Likewise, partitions contained in called party transformation pattern CSSs
should contain only called party transformation patterns.
Call-Forward Calling Search Spaces
Note Call Forward All actions are different than any other call-forward action in that the destination number
is entered by each individual user when the feature is activated from a phone.
The system allows you to decide how call-forward calling search spaces take effect. There are three
possible options, as selected by the Calling Search Space Activation policy:
• Use System Default
If you configure the Calling Search Space Activation Policy to Use System Default, then the CFA
CSS Activation Policy cluster-wide service parameter determines which Forward All Calling Search
Space will be used. The CFA CSS Activation Policy service parameter can be set to With Configured
CSS or to With Activating Device/Line CSS (see below). By default, the CFA CSS Activation Policy
service parameter is set to With Configured CSS.
• With Configured CSS
If you select the With Configured CSS option, the Forward All Calling Search Space and Secondary
Calling Search Space for Forward All explicitly configured in the Directory Number Configuration
window control the forward-all activation and call forwarding. If the Forward All Calling Search
Space is set to None, no CSS gets configured for Forward All. A forward-all activation attempt to
any directory number with a partition will fail. No change in the Forward All Calling Search Space
and Secondary Calling Search Space for Forward All occurs during the forward-all activation.
• With Activating Device/Line CSS
If you prefer to use the combination of the Directory Number Calling Search Space and Device
Calling Search Space without explicitly configuring a Forward All Calling Search Space, select
With Activating Device/Line CSS for the Calling Search Space Activation Policy. With this option,
when Forward All is activated from the phone, the Forward All Calling Search Space and Secondary
Calling Search Space for Forward All are automatically populated with the Directory Number
Calling Search Space and Device Calling Search Space for the activating device. When you set the
Forward All Destination from Unified CM Administration, the Forward All Calling Search Space
and Secondary Calling Search Space are not automatically populated and have to be configured
explicitly. The two calling search spaces are concatenated, and the resulting calling search space is
used to validate the number entered as a Call Forward All destination. For further details, see
Building Classes of Service for Unified CM with the Line/Device Approach, page 9-58.

9-104 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
With this configuration (Calling Search Space Activation Policy set to With Activating
Device/Line), if the Forward All Calling Search Space is set to None when forward-all is activated
through the phone, the combination of Directory Number Calling Search Space and activating
Device Calling Search Space is used to verify the forward-all attempt.
Note Call Forward All configuration typically has to satisfy two requirements: controlling the destinations to
which the device is allowed to forward calls, and ensuring that optimum call routing is achieved when
calls originating from various points of origin are forwarded to the Call Forward All destination. To
achieve both requirements, Cisco recommends using the With Configured CSS activation policy, which
allows for controlling the destinations through the Line-Device dial plan approach; the Call Forward All
CSS is used to implement a set of restrictions through the use of blocked patterns, and it can be set to
the same calling search space configured on the line if the regular class of service is to be used for Call
Forward All. The Secondary Calling Search Space for Call Forward All should then be configured to
route calls to the Standard Local Route Group; the actual route group used to route the call will be
determined at the time of the call, based on the calling (forwarded) device's local route group as
configured on its device pool.
On Type-A IP phones running SIP, if Call Forward All is invoked from the phone itself, the device's
Rerouting Calling Search Space is used for forwarded calls. If Forward All actions are invoked from the
Unified CM User page or the Unified CM Administrative page, then any Forward All action initiated
from the phone is irrelevant.
For example, assume an Type-A IP phone running SIP is configured with Forward All to extension 3000
from the Unified CM User page. At the same time, the phone itself is configured to Forward All to
extension 2000. All calls made to that phone will be forwarded to extension 3000.
Note On Type-A IP phones running SIP, invoking Forward All from the Unified CM User or Administrative
pages will not be reflected on the phone. The phone does not display any visual confirmation that calls
are forwarded.
When Forward All is initiated from an IP phone running SCCP or from an Type-B IP phone running SIP,
user input is simultaneously compared to the patterns allowed in the configured Forward All calling
search space(s). If an invalid destination pattern is configured, the user will be presented with reorder
tone. When Forward All is invoked from an Type-A IP phone running SIP, Forward All user input is
stored locally on the phone and is not verified against any calling search space in Unified CM. If user
input corresponds to an invalid destination, no notification is offered to the user. Calls made to that phone
will be presented with reorder tone as the phone tries to initiate a SIP re-route action to an invalid
destination number.
Other Call Forward Types
The calling search spaces configured for the various other types of call forward (Forward Busy, Forward
No Answer, Forward No Coverage, forward on CTI failure, 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 forward to a cell phone number if the caller is a co-worker calling from another IP
phone on the network. This is possible by using different configurations for the Internal and External
Call Forward settings.

OL-21733-18 9-105
Chapter 9 Dial Plan
Dial Plan Elements
When the Forward All calling search space is left as <None>, the results are difficult to predict and
depend on the Unified CM release. Therefore, Cisco recommends the following best practices when
configuring call-forward calling search spaces:
• Always provision the call-forward calling search spaces with a value other than <None>. This
practice avoids confusion and facilitates troubleshooting because it enables the network
administrator to know exactly which calling search space is being used for forwarded calls.
• Configure the Call Forward Busy and Call Forward No Answer calling search spaces with values
that allow them to reach the DNs for the voicemail pilot and voicemail ports but not external PSTN
numbers.
• Configure both the Call Forward All calling search space and the Secondary Calling Search Space
for Forward All, according to your company's policy. Many companies choose to restrict forwarded
calls to internal numbers only, to prevent users from forwarding their IP phone lines to a
long-distance number and dialing their local IP phone number from the PSTN to bypass
long-distance toll charges on personal calls.
The Call Forward Unregistered (CFUR) feature is a way to reroute calls placed to a temporarily
unregistered destination phone. The configuration of CFUR consists of two main elements:
• Destination selection
When the DN is unregistered, calls can be rerouted to either of the following destinations:
– Voicemail
Calls can be sent to voicemail by selecting the voicemail checkbox and configuring the CFUR
calling search space to contain the partition of the voicemail pilot number.
– A directory number used to reach the phone through the PSTN
This approach is preferred when a phone is located within a site whose WAN link is down. If
the site is equipped with Survivable Remote Site Telephony (SRST), 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, preferably in E.164
format, including the + sign (for example, +1 415 555 1234). This allows the CFUR destination
to be processed by the calling phone's local route group, whether or not it uses the same off-net
access code and PSTN prefixes as the unregistered phone.
• Calling search space
Unified CM 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, and route group to place the call. Cisco recommends
that you configure the CFUR calling search space to route calls to the CFUR destination using
patterns pointing to route lists referencing the Standard Local Route Group. This will ensure that
the egress gateway to the PSTN is chosen based on the calling device.
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
Unified CM, 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.

9-106 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
The service parameter MaximumForwardUnRegisteredHopsToDn controls the maximum number of

CFUR calls that are allowed for a DN at the same time. The default value of 0 means the counter is
disabled. If any DNs are configured to reroute CFUR calls through the PSTN, loop prevention is
required. Configuring this service parameter to a value of 1 would stop CFUR attempts as soon as a
single call is placed through the CFUR mechanism. This setting would also allow only one call to be
forwarded to voicemail, if CFUR is so configured. Configuring this service parameter to a value of 2
would allow for up to two simultaneous callers to reach the voicemail of a DN whose CFUR setting is
configured for voicemail, while also limiting potential loops to two for DNs whose CFUR configuration
sends calls through the PSTN.
Note Extension Mobility DNs should not be configured to send Call Forward Unregistered calls to the PSTN
DID associated with the DN. The DNs of Extension Mobility profiles in the logged-out state are deemed
to be unregistered, therefore any calls to the PSTN DID number of a logged-out DN would trigger a
routing loop. To ensure that calls made to Extension Mobility DNs in the logged-out state are sent to
voicemail, ensure that their corresponding Call Forward Unregistered parameters are configured to send
calls to voicemail.
Translation Patterns
Translation patterns are one of the most powerful tools in Unified CM 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, Unified CM 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 9-41.
Figure 9-41 Application Example for Translation Patterns
Calling Search
Spaces Partitions
Translation Pattern
Translations_pt transforms “0” in
IP Phone_css 2001 and forces
0 [Transform Mask: 2001]
second lookup
Dials "0" Delivers "2001"
to reach
operator AllPhones_pt
Internal_css
114717
All IP Phones DN's
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 Unified CM 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.

OL-21733-18 9-107
Chapter 9 Dial Plan
Dial Plan Elements
Note When a dialed number is manipulated using a translation pattern, the translated number is recorded in
the call detail record (CDR). However, when the digit manipulation occurs within a route list, the CDR
will show the originally dialed number, not the translated one. The Placed Calls directory on the IP phone
always shows the string as it was dialed by the user.
Automated Alternate Routing

The automated alternate routing (AAR) feature enables Unified CM 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 deployments with sites connected via a WAN. For instance, if a
phone in branch A calls a phone in branch B and the available bandwidth for the WAN link between the
branches is insufficient (as computed by the Locations mechanism), AAR can reroute the call through
the PSTN. The audio path of the call would be IP-based from the calling phone to its local (branch A)
PSTN gateway, TDM-based from that gateway through the PSTN to the branch B gateway, and IP-based
from the branch B gateway to the destination IP phone.
AAR can be transparent to the users. You can configure AAR so that users dial only the on-net (for
example, four-digit) directory number of the called phone and no additional user input is required to
reach the destination through the alternate network (such as the PSTN).
Note AAR does not support CTI route points as the origin or the destination of calls. Also, AAR is
incompatible with the Extension Mobility feature when users roam across different sites. Refer to
Extension Mobility, page 9-114, for more details.
You must provide the following main elements for AAR to function properly:
• Establish the PSTN Number of the Destination, page 9-108
• Prefix the Required Access Codes, page 9-109
• Select the Proper Dial Plan and Route, page 9-111
Establish the PSTN Number of the Destination

The rerouting of calls requires using a destination number that can be routed through the alternate
network (for example, the PSTN). AAR uses the dialed digits to establish the on-cluster destination of
the call and then combines them with the called party's AAR Destination Mask; if it is not configured,
the External Phone Number Mask is used instead. The combination of the dialed digits and the
applicable mask must yield a fully qualified number that can be routed by the alternate network.
Alternatively, by selecting the voicemail checkbox in the AAR configuration, you can allow calls to be
directed to the voicemail pilot number. This choice does not rely on the numbers originally dialed by the
caller, but routes the call according to the voicemail profile configuration.
Note By default, the directory number configuration retains the AAR leg of the call in the call history, which
ensures that the AAR forward to the voice messaging system will select the proper voice mailbox. If you
choose "Remove this destination from the call forwarding history," the AAR leg of the call is not present
in the call history, which would prevent the automated voice mailbox selection and would offer the caller
the generic voicemail greeting.

9-108 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
The AAR Destination Mask is used to allow the destination phone number to be determined
independently of the External Phone Number mask. For example, if Caller ID policy for a company
required a phone's external phone number mask to be the main directory number of an office (such as
415 555 1000), the AAR destination mask could be set to+1 415 555 1234, to provide AAR with the
phone's specific PSTN number.
For example, assume phone A in San Francisco (DN = 2345) dials an on-net DN (1234) configured on
phone B located in New York. If locations-based call admission control denies the call, AAR retrieves
the AAR Destination Mask of the New York phone (+1212555XXXX) and uses it to derive a number
(+12125551234) that can be used to route the call on the PSTN.
It is best to configure the AAR destination mask to yield a fully qualified E.164 number, including the
+ sign, because this will greatly simplify the overall configuration of AAR. For example, a phone in
Paris is configured with an AAR destination mask of +33 1 58 04 58 58. Because this number is a fully
qualified E.164 number, it contains all the information required for the Cisco Unified Communications
system to derive a routable PSTN number as required by the calling phone's gateway to the PSTN,
regardless of whether it is located in France, in Canada, or anywhere else in the world. The following
sections elaborate on this approach.
Prefix the Required Access Codes

If the AAR Destination Yields a Fully Qualified E.164 Number Including the + Sign
This is the simplest case; the AAR destination contains + as a wildcard to be replaced by the appropriate
access codes require at each gateway. The destination number is ready to be routed to an appropriate
route pattern and then transformed at the point of egress to the PSTN by the appropriate called party
transformation patterns.
Example 1: A phone in Ottawa, Canada calls a phone in Paris, which triggers AAR due to a lack of
bandwidth on the WAN. The AAR destination is +33 1 58 04 58 58. The AAR calling search space of
the calling phone contains a route pattern \+!, which routes the call to the Standard Local Route Group.
The call is routed to the local gateway in Ottawa, where called party transformation patterns will replace
the + with the applicable international access code 011. The resulting call is placed to 011 33 1 58 04 58
58.
Example 2: A phone in Nice, France calls a phone in Paris, which triggers AAR due to a lack of
bandwidth on the WAN. The AAR destination is +33 1 58 04 58 58. The AAR calling search space of
the calling phone contains a route pattern \+!, which routes the call to the Standard Local Route Group.
The call is routed to the local gateway in Nice, where called party transformation patterns will replace
the + 33 with the applicable national access code 0. The resulting call is placed to 01 58 04 58 58.
If the AAR Destination Mask Yields a Number Including the Country Code
The destination number (assumed to include the country code) might require a prefix to be routed
properly by the origination branch's dial plan. Furthermore, if the point of origin is located in a different
area code or even a different country, then other prefixes such as international dialing access codes (for
example, 00 or 011) 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 the same inter-country dialing
structure. For example, all phones in the UK dial numbers outside the UK with 9 as a PSTN access code,
followed by 00 for international access; all phones in France and Belgium use 0 as a PSTN access code,
followed by 00 for international access; all phones in the NANP use 9 as a PSTN access code, followed
by 011 for international access.

OL-21733-18 9-109
Chapter 9 Dial Plan
Dial Plan Elements
This yields the following AAR group configuration:
AAR Group NANP Cent_EU UK

NANP 9 9011 9011
Cent_EU 000 000 000
UK 900 900 9
Example 3: A phone in Ottawa, Canada calls a phone in Paris, which triggers AAR due to a lack of
bandwidth on the WAN. The AAR destination is 33 1 58 04 58 58. The AAR group of the calling phone
is NANP and that of the destination phone is Cent-EU, thus yielding a prefix of 9011. The AAR calling
search space of the calling phone contains a site-specific route pattern 9011!, which routes the call to a
route list in Ottawa, stripping the 9. The call is routed to the local gateway in Ottawa. The resulting call
is placed to 011 33 1 58 04 58 58.
Example 4: A phone in Brussels, Belgium calls a phone in Paris, which triggers AAR due to a lack of
bandwidth on the WAN. The AAR destination is 33 1 58 04 58 58. The AAR group of the calling phone
and that of the destination phone is Cent-EU, thus yielding a prefix of 000. The AAR calling search space
of the calling phone contains a site-specific route pattern 000!, which routes the call to a route list in
Brussels, stripping the leading 0. The call is routed to the local gateway in Brussels. The resulting call
is placed to 00 33 1 58 04 58 58.
Voicemail Considerations
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 NANP, which prefixes 9 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
985551000, which would result in a failed call. Instead, the San Francisco DN should be configured with
AAR group vmail. The prefix digits for calls from AAR group NANP to AAR group vmail are <none>,
as shown in the following table. The call will be placed successfully to 85551000.
AAR Group NANP Cent_EU UK vmail

NANP 9 9011 9011 <none>
Cent_EU 000 000 000 <none>
UK 900 900 9 <none>
Note When Device Mobility is not used, the AAR group configuration of a DN remains the same even as the
device is moved to different parts of the network. With Device Mobility, the AAR group can be
determined dynamically based on where in the network the phone is physically located, as determined
by the phone's IP address. See Device Mobility, page 9-112, for more details.

9-110 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
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 Unified CM
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.
The AAR calling search space configuration can be greatly simplified if the local route group is used in
conjunction with using a fully qualified E.164 address (including the + sign) as the AAR destination
mask. A single calling search space configured with a single partition, containing a single route pattern
\+!, pointing to a single route list featuring the Standard Local Route Group, can be used to route the
calls of all phones at all sites in an entire cluster. This relies on the pre-configuration of the appropriate
gateway-specific called party transformation patterns to adapt the universal form of the destination
number to the localized form required by the service provider networks to which the call is delivered at
each site.
Note If you have configured additional route patterns to force on-net internal calls dialed as PSTN calls,
ensure that these patterns are not matched by the AAR feature. Refer to Design Guidelines for Multisite
Deployments, page 9-35, for more details.
Note To avoid denial of re-routed calls due to call admission control, AAR functionality requires the use of a
LAN as the IP path between each endpoint and its associated gateway to the PSTN. Therefore, AAR dial
plans cannot rely on centralized gateways for PSTN access.
Note When Device Mobility is configured, the AAR calling search space can be determined dynamically
based on where in the network the phone is physically located, as determined by the phone's IP address.
See Device Mobility, page 9-112, for more details.
Special Considerations for Sites Located Within the Same Local Dialing Area
In some instances, the AAR dial string might have to be modified locally to allow for dialing between
sites whose phones belong to the same AAR group. For example, assume two separate sites located in
France share the same country code of 33. (See Figure 9-42.) In this case, a number dialed as 0 00 33 1
58 04 58 58 would have to be transformed to 01 58 04 58 58. Note that this is required only if the AAR
configuration does not rely on called party transformation patterns.
This transformation is best done with a site-specific translation pattern of 00033.[1-6]XXXXXXXX to
strip the pre-dot digits and prepend 0. This translation pattern should be placed in a member partition of
the AAR calling search space for the French sites only; the Belgian site still needs to reach this same
destination as 0 00 33 1 58 04 58 58.

OL-21733-18 9-111
Chapter 9 Dial Plan
Dial Plan Elements
Figure 9-42 Dialed Number Transformations for AAR Calls Between Sites
Unified CM Cluster Destination site’s dial

M
plan responsible to adapt
DID digits delivered by the
M M LEC to internal dial plan
(e.g: 10 digit DID to Paris
4 digit on-net extensions. Phone B
M M
5858
Call Denied by
Locations CAC IP
Brussels
External Phone
V Number Mask:
V IP WAN
8 33 1 58 04 58 58
85
0 45
Phone A 58
01 58 Nice
2345 4 58
5 80
IP 01
00 33 1 58 04 58 58 V
Site’s dial plan strips PSTN
Phone C
the off-net access code (0)
1234
before call egresses to PSTN
User dials 5858.
String 0 00 33 1 58 04 58 58 IP
is sent through this phone’s 01 58 04 58 58
AAR Calling Search Space Site’s dial plan strips the
off-net access code (0), User dials 5858.
All sites are in the same international access (00) String 0 00 33 1 58 04 58 58
AAR group. All AAR calls and French country code is sent through this phone’s
are prefixed with 000. (33) then prefixes national AAR Calling Search Space
254269
access code (0) before
call egresses to PSTN
Note The AAR functionality is not triggered upon detection that the destination phone is unreachable.
Therefore, WAN failures do not trigger AAR functionality.
In order to understand this better, consider an example where a Unified CM 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.
To allow all three cases above with a single, simple AAR configuration, it is best to configure the AAR
Destination Mask with the E.164 notation (including the + sign); this creates a destination number which
can be interpreted by the system differently for each calling phone.
Device Mobility
Device Mobility offers 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 Unified CM 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.

9-112 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
When roaming, a phone will inherit the parameters associated with the device pool associated with the
device's current subnet. From a dial-plan perspective, the functionality of the following five 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.
• Local route group
the roaming device pool's Local Route Group is used. For example, if a device is roaming from San
Francisco to New York, the local route group of the New York device pool is used to route calls to
the PSTN whenever a pattern points to a route list invoking the Standard Local Route Group.
• Calling party transformation CSS
The roaming device pool's calling party transformation CSS is used. This allows a phone to inherit
the calling party presentation mode that is customary for the phones of the visited location.
• Device calling search space
The roaming device pool's Device Mobility calling search space is used instead of the device calling
search space configured on the device's configuration page. For example, if a device is roaming from
San Francisco to New York, the Device Mobility calling search space of the New York device pool
is used as the roaming phone's device calling search space. If you use the line/device approach to
classes of service, this approach will establish the path taken for PSTN calls, routing them to the
local New York gateway.
• AAR calling search space
The roaming device pool's AAR calling search space is used instead of the AAR calling search space
configured on the device's configuration page. For example, if a device is roaming from San
Francisco to New York, the AAR calling search space of the New York device pool is used as the
roaming phone's AAR calling search space. This calling search space will establish the path taken
for outgoing AAR PSTN calls, routing them to the local New York gateway.
• DN's AAR group
For incoming AAR calls, the AAR group assigned to a DN is retained, whether or not the DN's host
phone is roaming. This ensures that the reachability characteristics established for the AAR
destination number are retained.
For outgoing AAR calls, the calling DN's AAR group uses the roaming device pool's AAR group
instead of the AAR group selected on the DN's configuration page. Note that this AAR group will
be applied to all DNs on the roaming device. For example, all DNs on a device roaming from New
York to Paris (assuming both locations are in the same Device Mobility group) would inherit the
AAR group configured for outgoing calls in the Paris device pool. This AAR group would be applied
to all DNs on the roaming device and would allow for the appropriate prepending of prefix digits to
AAR calls made from DNs on the roaming phone.
Call Forward All When Roaming

When a device is roaming in the same device mobility group, Unified CM uses the Device Mobility CSS
to reach the local gateway. If a user sets Call Forward All at the phone, if the CFA CSS is set to None,
and if the CFA CSS Activation Policy is set to With Activating Device/Line CSS, then:
• The Device CSS and Line CSS get used as the CFA CSS when the device is in its home location.
• If the device is roaming within the same device mobility group, the Device Mobility CSS from the
Roaming Device Pool and the Line CSS get used as the CFA CSS.
• If the device is roaming within a different device mobility group, the Device CSS and Line CSS get
used as the CFA CSS.

OL-21733-18 9-113
Chapter 9 Dial Plan
Dial Plan Elements
The section on Device Mobility, page 25-16, 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 Unified CM 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
Unified CM 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, page 9-108, some limitations exist. Consider the example shown in
Figure 9-43, where Extension Mobility and AAR are deployed in a centralized call processing
Unified CM cluster with one site in San Jose and one in New York.
Figure 9-43 Extension Mobility and AAR
IP WAN
San Jose New York
PSTN PSTN
San Jose New York

DN: 1000
Ext. mask: 4085551000
EM user
moves IP
DN: 1001 DN: 2000

Ext. mask: 4085551001 Ext. mask: 2125552000
IP IP IP
114718
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 AAR mask, if
used) 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

9-114 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
PSTN, but because the DID (408) 555-1000 is owned by that same gateway, the PSTN sends the call
back to it. The San Jose gateway tries to complete the call to the phone with extension 1000, which is
now in New York. Because no bandwidth is available to New York, the AAR feature is invoked again,
and one of the following two scenarios will occur:
• If the gateway's AAR calling search space contains external PSTN route patterns, this is the
beginning of a loop that eventually uses all the PSTN trunks at the San Jose site.
• If, on the other hand, the gateway's AAR calling search space contains only internal numbers, the
call fails and the caller hears a fast-busy tone. In this case, one PSTN call is placed and one is
received, so two PSTN trunks are utilized on the San Jose gateway for the duration of the call setup.
Tip To prevent routing loops such as the one described here, always configure all calling search spaces on
the gateway configuration pages to include only internal destinations and no route patterns pointing to
route lists or route groups containing that same gateway.
This example highlights the fact that Extension Mobility leverages the dynamic aspect of Cisco IP
Communications and, therefore, requires that the call routing between sites use the IP network. Because
the E.164 numbers defined in the PSTN are static and the PSTN network is unaware of the movements
of the Extension Mobility users, the AAR feature, which relies on the PSTN for call routing, cannot be
used to reach Extension Mobility users who move to a site other than their home site.
Note However, if the Extension Mobility user moves to a remote site that belongs to the same AAR group as
his or her home site, he or she can use the AAR feature to place calls to other sites when the available
IP WAN bandwidth is not sufficient. This is because the path of such a call is determined by the AAR
calling search space of the phone from which the call originates. This AAR calling search space does
not change when users log in or out of Extension Mobility, and it should be configured to use the visited
remote site's gateway.
Tip Configure unregistered Extension Mobility profile DNs to send calls to voicemail. See Call-Forward
Calling Search Spaces, page 9-104, for details.
Special Considerations for Cisco Unified Mobility

Cisco Unified Mobility (see the section on Cisco Unified Mobility, page 25-38) relies on functionality
that has a direct impact on call routing. To understand the effects of the Cisco Unified Mobility
parameters related to dial plans, consider the following example:
Note Only those parameters required in the discussion are mentioned here.
User Paul has an IP phone configured as follows:

DN: 8 555 1234
DID number: +1 408 555 1234
External Phone Number Mask: 408 555 1234
Line Calling Search Space: P_L_CSS
Device Calling Search Space: P_D_CSS

OL-21733-18 9-115
Chapter 9 Dial Plan
Dial Plan Elements
Paul's DN is associated with a Remote Destination Profile configured as follows:

Calling Search Space: P_RDP_CSS
Rerouting Calling Search Space: P_RDP_Rerouting_CSS
Calling Party Transformation CSS: P_CPT_CSS
Paul's RDP is associated with a Remote Destination configured as follows:
Destination Number: +1 514 000 9876 (This is Paul's mobile phone number, on either a
single-mode or dual-mode phone.)
Calls from the PSTN placed to Paul or Ringo's DID number are handled by a gateway configured as
follows:
Calling Search Space: GW_CSS
Significant digits: 7
Prefix DN: 8
User Ringo has an IP phone configured as follows:
DN: 8 555 0001
DID number: 408 555 0001
External Phone Number Mask: 408 555 0000 (This is the enterprise's main business number.)
Line Calling Search Space: R_L_CSS
Device Calling Search Space: R_D_CSS
The following sections explain the effects of the above mobility parameters on call routing.
Remote Destination Profile
Remote destination profiles (RDPs) are associated with directory numbers (for example, the DN of a
user's IP phone) and with remote destinations (for example, the mobile phone number of a user). The
RDP controls the interaction between the IP phone and the external numbers (for example, a mobile
phone) configured as remote destinations.
Note Remote destinations cannot be configured with on-cluster DNs as destination numbers.
Remote Destination Profile's Rerouting Calling Search Space
When a call is placed to a DN associated with a remote destination profile, the call has the effect of
ringing both the DN and the number(s) configured as remote destination(s).
The ability of the caller to reach the destination IP phone is controlled by the caller's Calling Search
Space settings. However, the ability for the call to be forked toward the remote destination (for example,
a mobile phone) is controlled by the called mobility user's Rerouting Calling Search Space.
For example:
Ringo calls Paul from his IP phone by dialing 8 555 1234. Paul's IP phone rings, as well as his mobile
phone.
Here, the ability for Ringo to reach Paul's DN is controlled by the Line and Device calling search spaces
on Ringo's IP phone. The dialed destination (8 555 1234) must be in a partition found in the concatenated
calling search spaces R_L_CSS and R_D_CSS.

9-116 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
For this same call to be forked to ring Paul's mobile phone, the configured remote destination (+1 514
000 9876) must match a pattern found in the calling search space P_RDP_Rerouting_CSS.
Note Even if the dialing privileges assigned to Ringo's phone do not allow for external calls, the call to the
remote destination is handled by the rerouting calling search space associated with Paul's remote
destination profile.
Remote Destination Profile's Calling Search Space
In Cisco Unified CM 6.0, the RDP's calling search space is used to route calls originating from numbers
defined as remote destinations. It is concatenated with the associated DN's Line CSS. The order of
concatenation is Line CSS followed by the RDP's CSS.
When the calling party number of an external call made into the cluster matches a number defined as a
remote destination, the calling party number is replaced with the DN of the line associated with the
matching remote destination. Also, the calling search space used to route the call is the concatenation of:
• The Line calling search space of the DN associated with the matched remote destination number
• The calling search space of the RDP associated with the matched remote destination
In Unified CM 6.1 and later releases, a new service parameter (Inbound Calling Search Space for
Remote Destination) controls which calling search space is used to route calls originating from one of
the cluster's remote destinations. Its default setting is Trunk or Gateway Inbound Calling Search Space,
which routes all incoming calls using the trunk’s or gateway's configured CSS. If the service parameter
is set to Remote Destination Profile + Line Calling Search Space, then the behavior is identical for all
Unified CM 6.x releases. This new service parameter has no effect on the calling party number
replacement.
Note The default behavior of Unified CM 6.1 and later releases is different than the behavior of
Unified CM 6.0 with regard to the routing of incoming calls originating from numbers defined as remote
destinations. Cisco recommends using the default setting of Unified CM 6.1 because it simplifies call
routing.
All the numbers defined as remote destinations within the same cluster will be searched to find a match
for any external call coming into the cluster.
The following examples assume Unified CM 6.1 and later releases with the service parameter Inbound
Calling Search Space for Remote Destination set to Trunk or Gateway Inbound Calling Search Space.
For example:
Paul uses his mobile phone to call Ringo at his desk. The call comes into the gateway from the PSTN,
with a calling party number of 514 000 9876 and a called party number of 408 555 0001. The call is
routed to Ringo's phone. The number displayed as the calling party number on Ringo's phone is Paul's
desk phone number, 8 555 1234. This allows Paul's mobile phone number to remain confidential and
allows Ringo's calls placed from the missed and received calls lists to ring into Paul's IP phone, thus
making the full set of enterprise mobility features available.
When the call comes into the gateway, the PSTN offers a calling party number of 514 000 9876 and a
called party of 408 555 0001. The gateway’s configuration will retain the last seven significant digits of
the called number and prefix 8, yielding 8 555 0001 as the destination number.

OL-21733-18 9-117
Chapter 9 Dial Plan
Dial Plan Elements
The system detects that the calling party number matches Paul's remote destination number. Upon
detecting this match, the system will:
1. Change the calling party number to Paul's DN, 8 555 1234.
2. Route the call to the called number using the incoming gateway's calling search space. Specifically,
the routing is done through the GW_CSS calling search space.
The destination (called) number presented by the gateway should be the DN of the phone, and the calling
party substitution illustrated in step 1 above renders possible the use of one-touch dialing from the
missed/received calls lists.
Note There is no way to partition remote destination numbers. This is worth noting in case multiple user
groups (such as different companies, sub-contractors, and so forth) are using the same cluster. In
Unified CM 6.1 and later releases, when the service parameter Inbound Calling Search Space for
Remote Destination is set to Trunk or Gateway Inbound Calling Search Space, the call routing is based
on the incoming trunk’s or gateway's CSS, regardless of whether or not the calling number matches a
remote destination. However, the calling party number substitution still occurs if the calling party
matches any remote destination. This means that calls from one tenant's remote destination numbers to
another tenant's DID numbers will be presented with a transformed calling party number that matches
the caller's on-net extension DN.
Note Any incoming external call where Calling Party Number is not available will be routed according to the
incoming gateway's CSS. This also applies to incoming calls from IP trunks, such as SIP or H.323 trunks.
Remote Destination Profile's Calling Party Transformation CSS and Transformation Patterns
Calls originating from an enterprise IP phone to a mobility-enabled DN are forked to both the enterprise
destination IP phone's DN and one (or multiple) external destinations. One challenge this creates is to
deliver calling party numbers adapted to each destination phone's dial plan. This is to allow for redialing
of calls from missed calls and received calls lists. For an enterprise phone, the calling party numbers
should be redialable enterprise phone numbers. For a remote destination on the PSTN (such as a home
phone or a mobile phone), the calling party number should be transformed from the enterprise number
associated with the calling IP phone to a number redialable from the PSTN (generally, the DID number
of the calling phone).
When a call is placed to a mobility-enabled enterprise DN, the associated remote destination profile's
calling party transformation calling search space is used to find a match to the caller's calling party
number. It contains partitions which themselves contain transformation patterns.
Transformation patterns control the adaptation of calling party numbers from enterprise format to PSTN
format. They differ from all other patterns in Unified CM in that they match on the calling number, not
the called number. The matching process is done through a regular expression (for example, 8 555
XXXX), and the transformation process allows for the optional use of the calling DN's external phone
number mask as well as transformation patterns and digit prefixing.
Once matched, they perform all configured transformations, and the resulting calling party number is
used to reach all remote destinations associated with the Remote Destination Profile for which the match
occurred.

9-118 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
For example:
When Ringo calls Paul, we want Paul's IP phone to display the calling party number as 8 555 0001 and
Paul's mobile phone to display 408 555 0001.
For this case, we create a transformation pattern with the following parameters:
Pattern: 8 555 XXXX
Partition: SJ_Calling_Transform
Use calling party's external phone number mask: un-checked
Calling Party Transformation mask: 555 XXXX
Prefix Digits (outgoing calls): 408
We also have to ensure that partition SJ_Calling_Transform is placed in calling search space
P_CPT_CSS.
When the call from Ringo is anchored on Paul's phone, two separate call legs are attempted. The first
rings Paul's IP phone and offers the caller's DN as Calling Party Number (that is, 8 555 0001). The
second call leg is attempted through Paul's Remote Destination Profile. The RDP's calling party
transformation CSS, P_CPT_CSS, is used to find a match for 8 555 0001 in all the referenced partition's
transformation patterns. Pattern 8 555 XXXX is matched in partition SJ_Calling_Transform. The
transformation mask is applied to the calling party number and yields 555 0001. The prefix digits are
added, and the resulting calling party number 408 555 0001 is used when placing the call to the remote
destinations.
Note that, in this example, we chose not to use the external phone number mask because it is set to a
number different than that of Ringo's DID. This offers flexibility in situations where the calling party
number offered to off-net destinations is required to be different based on the relationship of the caller
to the called party. The call from Ringo to Paul is between co-workers, thus the disclosure of Ringo's
DID number is deemed acceptable. Ringo's next call could be to a customer, in which case the main
enterprise number 408 555 0000 is the desired Calling Party Number to be offered to the destination.
Note Calling Party Transformation calling search spaces do not implicitly include the <none> partition;
therefore, transformation patterns left in the <none> partition do not apply to any Calling Party
Transformation calling search space. This is different from all other patterns in Unified CM, where all
patterns left in the <none> partition are implicitly part of every calling search space.
Application Dial Rules
Numbers defined as remote destinations are also used to identify and anchor incoming calls as enterprise
mobility calls. Often, the form in which the PSTN identifies calls differs from the form in which an
enterprise dial plan requires that calls to external numbers be dialed. Application dial rules can be used
to adapt the form in which remote destinations are configured to the form required when forking a call
to the remote destination. They allow for the removal from, and prefixing of digits to, the numbers
configured as remote destinations.
For example:
Assume the number 514 000 9876 is configured as Paul's remote destination number. This corresponds
to the form used by the PSTN to identify calls coming into the enterprise. But it differs from the form
used by the enterprise dial plan for outgoing calls, which requires that 91 be prefixed. In this case, we
need to create an application dial rule to adapt the remote destination form to the enterprise dial plan's
form:
Application Dial Rule:
Name: 514000_ten

OL-21733-18 9-119
Chapter 9 Dial Plan
Dial Plan Elements
Description: Used to prefix 91 to ten-digit numbers beginning with 514000

Number begins with: 514000
Number of Digits: 10
Total digits to be removed: 0
Prefix with Pattern: 91
In this example, calls made from Paul's mobile phone into the enterprise are identified as coming from
514 000 9876. This matches the form in which his number is configured as a remote destination, thus
allowing the match to be made and triggering the anchoring of the call on Paul's desk phone as well as
adapting the Calling Party Number offered to the on-net destination. (For example, when a call is placed
to Ringo's DID number, he sees the call as coming from 8 555 1234.)
When a call is placed to Paul's enterprise DN number, the call leg forked to his remote destination
number will be processed by the application dial rule above. The string 514 000 matches the beginning
of Paul's remote destination number, and it is ten digits long, so no digits are removed and 91 is prefixed.
This yields 91 514 000 9876 as a number to be routed through Paul's Remote Destination Profile calling
search space (P_RDP_CSS in this case).
Note This approach offers the ability to reuse calling search spaces already defined to route calls made from
IP phones. Creating new calling search spaces not requiring prefixes for outbound calls (that is, ones
able to route calls to 514 000 9876 directly) is less preferable because it can create situations where
external patterns overlap with on-net patterns.
Immediate Divert (iDivert)

The Immediate Divert (iDivert) function is used to send calls directly to voicemail. It can be invoked
when the call is ringing (incoming), when a call is on hold, or when a call is connected. The iDivert
function allows incoming calls to be diverted to either the invoking phone's voicemail box or the
voicemail box of the originally called party. The enhanced functionality is applicable only to diverted
calls such as forwarded calls or calls redirected by an application.
iDivert Enhancements in Cisco Unified CM 5.1

The iDivert function has been augmented in Cisco Unified CM 5.1 to allow incoming calls to be diverted
to either the invoking phone's voicemail box (legacy behavior) or the voicemail box of the originally
called party (enhanced behavior). The enhanced functionality is applicable only to diverted calls such as
forwarded calls or calls redirected by an application.
For example:
Assume that phone A calls phone B, whose calls are forwarded to phone C. As phone C is ringing,
the user at phone C activates the iDivert softkey, which offers two choices. The first choice results
in the call being sent to the original called party's voicemail (in this case, phone B's voicemail box),
while the second choice results in the call being sent to the iDivert invoker's voicemail (in this case,
phone C's voicemail box). The same choices are available whether phone C invokes the feature while
the call is ringing, connected, or placed on hold.
If a call is handled by Auto Call Pickup, Call Transfer, Call Park, Call Park Reversion, Conference, or a
MeetMe Conference prior to the invocation of the iDivert function, the call is no longer considered to be
a "diverted" call, and the only iDivert functionality available in this case is the legacy iDivert behavior
(that is, sending the call to the invoker’s voicemail). For example, assume phone A calls phone B, whose

9-120 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
calls are forwarded to phone C, and then phone C transfers the call to phone D. This is not a diverted call
because the last action applied to the call was the transfer to phone D. If phone D invokes the iDivert
function, the call will be sent to phone D's voicemail box.
To enable the full iDivert functionality described above, set the Unified CM service parameter Use
Legacy Immediate Divert to False. When enabled, enhanced iDivert automatically allows the use of
the feature over QSIG trunks, thus allowing an invoker's voicemail box to be hosted in a telephony
system connected via QSIG.
In cases where iDivert is used in a cluster connected to other telephone systems using QSIG, there might
be situations in which only the legacy iDivert functionality (where the only available choice is to send
the call to the invoker’s voicemail) is offered to a phone when receiving a call. For instance, assume
phones A and B are in cluster 1, and phone X is another QSIG-connected telephony system. Phone A
calls phone X, which is call-forwarded to phone C. After the call is connected to phone C, iDivert will
offer both the legacy (invoker’s voicemail) and enhanced (original called party’s voicemail) destinations
only if QSIG path replacement has not occurred. If phone C invokes iDivert after QSIG path
replacement, the only destination available is phone C's voicemail box.
Hunt Lists and Line Groups

The hunt pilot is typically used for call coverage, or distributing a call through a list of Skinny Client
Control Protocol (SCCP) endpoints. 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.
Unified CM 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 9-44 depicts the three-tiered architecture of the hunt construct in
Unified CM.
Figure 9-44 Three-Tiered Architecture for the Hunt Construct in Unified CM
Hunt Pilot
Matches dialed number for call coverage
Performs digit manipulation Hunt Pilot
Points to a Hunt List for routing
Last-resort call forwarding
Hunt List Configuration Order

Chooses path for call routing Hunt List
Points to prioritized Line Groups
First Second
choice choice
Line Group
Performs digit manipulation Line Group Line Group
Points to actual extensions 1 2
Endpoints
IP
IP Phones IP IP
126913
Voicemail Ports IP Phones Voicemail

OL-21733-18 9-121
Chapter 9 Dial Plan
Dial Plan Elements
Hunt Pilot
Hunt pilots are strings of digits and wildcards similar to route patterns, such as 9.[2-9]XXXXXX,
configured in Unified CM 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.
Calls can be redirected to a final destination when the hunting fails because of one or both of the
following reasons:
• All hunting options have been exhausted and the call still is not answered.
• A time-out period has expired.
This call redirection is configured in the Hunt Forward Settings section of the Hunt Pilot configuration
page, and the destination for this redirect can be either of the following options:
• A specific pattern in the internal call routing table of Unified CM
• Personal preferences, which point to the Call Forward No Coverage settings for the originally called
number when hunting on behalf of that number fails
For example, you can implement the personal preferences option by configuring a user's phone so that
the Forward No Answer field redirects the call to a hunt pilot, in order to search for someone else who
can answer the call. If the call hunting fails, either because all the hunting options were exhausted or
because a time-out period expired, the call can be sent to a destination personalized for the person who
was originally called. For example, if you set the Forward No Coverage field within the person's DN
configuration page to the voicemail number, the call will be sent to that person's voicemail box if hunting
fails.
The following considerations apply to calls handled by hunt pilots:
• Call Pickup and Group Call Pickup are not supported on calls distributed by a hunt pilot. A member
of the line group cannot pick up the hunt pilot call offered to another member in the line group, even
if they belong to the same call pickup group.
• The hunt pilot can distribute calls to any of its line group members, even if the members and the hunt
pilot reside in different partitions. A call distributed by the hunt pilot overrides all the partitions and
calling search space restrictions.
Hunt List
A hunt list is a prioritized list of eligible paths (line groups) for call coverage. Hunt lists have the
following characteristics:
• Multiple hunt pilots may point to the same hunt list.
• A hunt list is a prioritized list of line groups that function as alternate sets of phones which are
offered a call placed to the hunt pilot number. For example, you can use a hunt list to attempt to find
a taker for the call within a set of phones at a particular site. If the call is not taken, then the hunt
list attempts to offer the call through a second line group pointing to phones at a second site.
• Hunt lists do not do any digit manipulation.
• Multiple hunt lists can contain the same line group.
Line Group
Line group members are user extension numbers that are controlled by Unified CM. Thus, when the call
is being distributed through the line group members, Unified CM 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.

9-122 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Line groups control the order in which the call is distributed, and they have the following characteristics:
• Line groups point to specific extensions, which are typically IP phone extensions or voicemail ports.
• A single extension may be present in multiple line groups.
• Computer Telephony Integration (CTI) ports and CTI route points cannot be added within a line
group. Therefore, calls cannot be distributed to endpoints controlled through CTI applications such
as Cisco Customer Response Solution (CRS), IP Interactive Voice Response (IP IVR), and so forth
• Unified CM distributes calls to the devices according to the distribution algorithm assigned.
Unified CM supports the following algorithms:
– Top-down
– Circular
– Longest idle time
– Broadcast
• In the event of No-Answer, Busy, or Not-Available, line groups redirect a call distributed to an
extension based on the hunt options. Unified CM supports the following hunt options:
– Try next member, then try next group in hunt list.
– Try next member, but do not go to next group.
– Skip remaining members and go directly to next group.
– Stop hunting.
Hunt Group Logout

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 Unified CM 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 page. For enabling the function, ensure that a valid ring tone file is present on
the TFTP server. 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
Communications Manager Administration Guide, available at

OL-21733-18 9-123
Chapter 9 Dial Plan
Dial Plan Elements
Line Group Devices

The line group devices are the endpoints accessed by line groups, and they can be of any of the following
types:
• Any Skinny Client Control Protocol (SCCP) endpoints, such as Cisco Unified IP Phones
• SIP endpoints
• Voicemail ports (for Cisco Unity)
• H.323 clients
• FXS extensions attached to an MGCP gateway
Time-of-Day Routing
To use this feature, configure the following elements:
• Time period
• Time schedule
The time period allows you to configure start and end times for business hours. The start and end times
indicate the times during which the calls can be routed. In addition to these times, you can set the event
to repeat itself on a weekly or yearly basis. Moreover, you can also configure non-business hours by
selecting "No business hours" from the Start Time and End Time options. All incoming calls will be
blocked when this option is selected.
A time schedule is a group of specific time periods assigned to the partition. It determines whether the
partition is active or inactive during the specified time periods. A matching/dialing pattern can be
reached only if the partition in which the dialing pattern resides is active.
As illustrated in Figure 9-45, 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.

9-124 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Figure 9-45 Time-of-Day Routing
Unified CM
RTP Site Cluster
M
M M
M M
SJC Hunt Pilot 2 Hunt Pilot 1 RTP

Partition DN 8000 DN 8000 Partition
Time Period Time Period

9.00 to 17.00 Hunt List Hunt List 8.00 to 12.00
Mon-Fri Mon-Fri
8.00 to 17.00 8.00 to 17.00
Line Group Line Group
Sat Sun
No Business No Business
Jul 4th IP IP IP Jul 4th
San Jose RTP IP Phones RTP
Time Schedule Time Schedule
IP WAN
IP
IP
IP
126916
San Jose
IP Phones
San Jose Site
For the example in Figure 9-45, 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.
The elements of logical partitioning include:
• Device types, where phones are classified as interior, and gateways and trunks are defined as border.
Table 9-9 lists the endpoint types for different devices.
• Geolocations, where endpoints are assigned a civic address to be used in policy decisions.
• Geolocation filters, where policy decisions can be made on a subset of the geolocation objects.
• Policies, where communications between endpoints are either allowed or denied based on their
comparative (filtered) geolocations and device types.
Note Policies are not applied if all participants in a call (or call attempt) are classified as interior. This means
that calls between phones on the same cluster are never subjected to logical partitioning policies.

OL-21733-18 9-125
Chapter 9 Dial Plan
Dial Plan Elements
Note Geolocations are not to be confused with locations configured in Unified CM, which are used for call
admission control, or with physical locations used for Device Mobility.
Table 9-9 Device Types
Logical Partitioning Device Types Cisco Unified Communications Manager Device

Border • Gateway (for example, H.323 gateway)
• Inter-luster trunk (ICT), both gatekeeper-controlled
and non-gatekeeper-controlled
• H.225 trunk
• SIP trunk
• MGCP port (E1, T1, PRI, BRI, FXO)
Interior • Phones (SCCP, SIP, or third-party)
• CTI route points
• VG224 analog phones
• MGCP port (FXS)
• Cisco Unity voicemail (SCCP)
Logical Partitioning Device Types

Unified CM classifies endpoints as either interior or border. This classification is fixed and cannot be
modified by the system administrator.
Geolocation Creation
The (RFC) 4119 standard provides the basis for geolocations. Geolocations use the civic location format
specified by the following objects:
• Name
• Description
• Country using the two-letter abbreviation
• State, Region, or Province (A1)
• County or Parish (A2)
• City or Township (A3)
• Borough or City District (A4)
• Neighborhood (A5)
• Street (A6)
• Leading Street Direction, such as N or W (PRD)
• Trailing Street Suffix, such as SW (POD)
• Address Suffix, such as Avenue, Platz (STS)
• Numeric house number (HNO)

9-126 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
• House Number Suffix, such as A, 1/2 (HNS)

• Landmark (LMK)
• Additional Location Information, such as Room Number (LOC)
• Floor (FLR)
• Name of Business or Resident (NAM)
• Zip or Postal Code (PC)
Note In Unified CM, you must define geolocations manually.
Geolocation Assignment
Devices are assigned a geolocation from either the device page, the device pool, or the default
Geolocation as configured under Enterprise Parameters, in that order of precedence.
Geolocation Filter Creation

Geolocation filters define which of the geolocation objects should be used when comparing the
geolocations of different endpoints. For example, a group of phones may be assigned identical
geolocations, except for the room and floor in which they are located. Policies may want to consider
endpoints located within the same building as being within the same Closed User Group, and thus
allowed to communicate. Even though the actual geolocations of each phone differ, the filtered
geolocation is the same. This is useful when policies need to be applied to only the top-level fields of
geolocation. For instance, a policy that denies communications between phones and gateways in
different cities but allows communications between phones and gateways in the same city, could be
based on the comparative filtered geolocations where objects more granular than the City are ignored.
Geolocation Filter Assignment

Phones inherit the filter assignment of their device pool. Gateways and trunks can be configured with a
geolocation filter at the device or device pool level, in that order of precedence.
Logical Partitioning Policy Configuration

Logical partitioning policies are configured between geolocation identifiers. A geolocation identifier is
the combination of a filtered geolocation and a device type. The filtered geolocation is obtained by taking
a device's geolocation and applying the device's associated geolocation filter.
A policy is created as the combination of a set of geolocation objects and a device type (a source
geolocation identifier) in relationship with another such combination (the target geolocation identifier).
When the relationship is matched, the configured action of "allow" or "deny" is applied to the call leg.
Note Each set of geolocation objects configured in a policy is considered in association with a single device
type. For example, a set of geolocation objects such as Country=India, State=Karnataka, City=Bangalore
needs to be associated with device type Interior for actions pertaining to Bangalore phones, and
separately associated with device type Border for actions pertaining to Bangalore gateways.

OL-21733-18 9-127
Chapter 9 Dial Plan
Dial Plan Elements
Logical Partitioning Policy Application

When user action results in the creation of a new call leg (for example, when a user conferences a third
caller into a preexisting call), Unified CM will match the geolocation identifiers of each participant pairs
to those of preconfigured policies.
Note When the geolocation identifiers of two devices are being evaluated by logical partitioning, no policy is
applied if both devices are of device type Interior. This means that no call, conference, transfer, or so
forth, between IP phones within the same cluster will ever be denied due to logical partitioning policies.
For example, consider phones A and B located in Bangalore, India, and gateway C located in Ottawa,
Canada. Phone A calls phone B. Because both devices are of type Interior, no policy is invoked. The call
is established, and then the user at phone A invokes a conference, which would bring in gateway C.
Before the action is allowed, Unified CM will check the geolocation identifiers of A and C, as well as
those of B and C, for a match with the preconfigured policies. If any of the matching policies results in
a deny action, the new call leg cannot be established.
Note The default policy in Unified CM is deny; in other words, if no policy is configured explicitly to permit
a call leg, the call leg will be denied.
In the example above, unless an explicit policy is configured to allow Bangalore Interior devices to
connect to Ottawa Border devices, the call leg will be denied.
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:
• Traditional TDM telephony call legs, connecting the router to the PSTN, analog phones, or PBXs
• IP call legs, connecting the router to other gateways, gatekeepers, or Unified CMs
For all calls going through the router, Cisco IOS associates one dial peer to each call leg. Dial peers are
also of two main types, according to the type of call leg with which they are associated:
• POTS dial peers, associated with traditional TDM telephony call legs
• VoIP dial peers, associated with IP call legs

9-128 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Figure 9-46 shows the following examples of different types of calls going through a Cisco IOS router:
• Call 1 is from another H.323 gateway across the IP network to a traditional PBX connected to the
router (for example, via a PRI interface). For this call, an incoming VoIP dial peer and an outgoing
POTS dial peer are selected.
• Call 2 is from an analog phone connected to an FXS port on the router to a Unified CM cluster across
the IP network. For this call, an incoming POTS dial peer and an outgoing VoIP dial peer are selected
by the router.
• Call 3 is from an IP phone controlled by Cisco Unified Communications Manager Express
(Unified CME) or SRST to a PSTN interface on the router (for example, a PRI interface). For this
call, an automatically generated POTS dial peer (corresponding to the ephone configured on the
router) and an outgoing POTS dial peer are selected.
Figure 9-46 Incoming and Outgoing Dial Peers
Incoming Outgoing
Call Leg Call Leg
IP
VoIP POTS
V
H.323 Gateway PBX
1
2 IP
POTS VoIP M
V Unified CM
Analog Phone 3
POTS POTS PSTN

IP
CME/SRST
IP Phone
114951
Incoming Outgoing
dial peers dial peers
To match incoming call legs to incoming dial peers, the router selects a dial peer by matching the
information elements in the setup message (called number/DNIS and calling number/ANI) with four
configurable dial peer attributes. The router attempts to match these items in the following order:
1. Called number with incoming called-number
2. Calling number with answer-address
3. Called number with destination-pattern
4. Incoming voice port with configured voice port
The router must match only one of these conditions. It is not necessary for all the attributes to be
configured in the dial peer or that every attribute match the call setup information; only one condition
must be met for the router to select a dial peer. The router stops searching as soon as one dial peer is
matched, and the call is routed according to the configured dial peer attributes. Even if there are other
dial peers that would match, only the first match is used.

OL-21733-18 9-129
Chapter 9 Dial Plan
Dial Plan Elements
How the router selects an outbound dial peer depends on whether direct-inward-dial (DID) is
configured in the inbound POTS dial peer:
• If DID is not configured in the inbound POTS dial peer, the router performs two-stage dialing and
collects the incoming dialed string digit-by-digit. As soon as one dial peer matches the destination
pattern, the router immediately places the call using the configured attributes in the matching dial
peer.
• If DID is configured in the inbound POTS dial peer, the router uses the full incoming dial string to
match the destination pattern in the outbound dial peer. With DID, the setup message contains all
the digits necessary to route the call, so no additional digit collection is required. If more than one
dial peer matches the dial string, all of the matching dial peers are used to form a hunt group. The
router attempts to place the outbound call leg using all of the dial peers in the hunt group until one
is successful.
By default, dial peers in a hunt group are selected according to the following criteria, in the order listed:
1. Longest match in phone number
This method selects the destination pattern that matches the greatest number of dialed digits. For
example, if one dial peer is configured with a dial string of 345.... and a second dial peer is
configured with 3456789, the router would first select 3456789 because it has the longest explicit
match of the two dial peers.
2. Explicit preference
This method uses the priority configured with the preference dial peer command. The lower the
preference number, the higher the priority. The highest priority is given to the dial peer with
preference order 0. If the same preference is defined in multiple dial peers with the same destination
pattern, a dial peer is selected randomly.
3. Random selection
In this method, all destination patterns are weighted equally.
You can change this default selection order or choose different methods for hunting dial peers by using
the dial-peer hunt global configuration command. An additional selection criterion is least recent use,
which selects the destination pattern that has waited the longest since being selected (equivalent to
longest idle for Unified CM line groups).
Observe the following best practices when configuring H.323 dial peers on a Cisco IOS router:
• To ensure that incoming PSTN calls are directly routed to their destination based on the DNIS
information, create a default POTS dial peer with the direct-inward-dial attribute, as follows:
incoming called-number .
direct-inward-dial
port 1/0:23
• When using the router as an H.323 gateway connected to a Unified CM cluster, provide redundancy
by configuring at least two VoIP dial peers with the same destination pattern pointing to two
different Unified CM servers. Use the preference attribute to select the priority order between
primary and secondary Unified CM servers. The following example shows the use of the preference
attribute:
dial-peer voice 100 voip
preference 1
!--- Make this the first choice dial peer.
ip precedence 5
destination-pattern 1...

9-130 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
session target ipv4:10.10.10.2
!--- This is the address of the primary Unified CM.
dtmf-relay h245-alpha
dial-peer voice 101 voip

preference 2
!--- This is the second choice.
ip precedence 5
destination-pattern 1...
session target ipv4:10.10.10.3
!--- This is the address of the secondary Unified CM.
dtmf-relay h245-alpha
Call Routing in Cisco IOS with a Gatekeeper

An H.323 gatekeeper is an optional node that manages endpoints (such as H.323 terminals, gateways,
and Multipoint Control Units (MCUs), as well as Cisco Unified Communications Manager Express
(Unified CME) and Unified CM 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 a Cisco
Unified Border Element 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-38; for call
admission control considerations, refer to Cisco IOS Gatekeeper Zones, page 11-15.
Call routing in Cisco IOS gatekeeper is based on the following types of information:
• Statically configured information, such as zone prefixes and default technology prefixes
• Dynamic information, such as E.164 addresses and technology prefixes provided by H.323 devices
during the registration phase
• Per-call information, such as called number and technology prefix
A zone is a collection of H.323 devices (such as endpoints, gateways, or MCUs) that register with a
gatekeeper. There can be only one active gatekeeper per zone, and you can define up to 100 local zones
on a single gatekeeper.

OL-21733-18 9-131
Chapter 9 Dial Plan
Dial Plan Elements
When an H.323 endpoint registers with the gatekeeper, it is assigned to a zone and it can optionally
register one or more E.164 addresses for which it is responsible, as well as a technology prefix that
specifies which kinds of calls it can handle (for example, voice, video, fax, and so on).
For each zone, you can configure one or more zone prefixes on the gatekeeper. Zone prefixes are strings
that contain digits and wildcards and are used by the gatekeeper to facilitate call routing decisions. The
following characters are allowed in a zone prefix string:
• All numbers between 0 and 9, which match a single specific digit
• The dot (.) wildcard, which matches one digit between 0 and 9
• The * wildcard, which matches one or more digits between 0 and 9
To understand the gatekeeper call routing behavior, it is helpful to consider the message parsing logic.
Figure 9-47 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 Unified CM, 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, page 9-135). 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.

9-132 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Figure 9-47 Gatekeeper Address Resolution for an ARQ
Y Y
1) Tech Prefix Match? Hop-off Tech Prefix? Send LRQ
N
N
strip tech prefix
2) Zone Prefix Match? N Y

Is "arq reject-unknown-prefix" set? Send ARJ
(no prefix guessing)
Y
N
target_zone=matched_zone
target_zone=src zone
N
3) Is target-zone local? Send LRQ
4) Is target address Y
Send ACF
registered?
N Y
5) Was a Tech Prefix Y Find local GW with N

Send ARJ
found in Step 1? the Tech Prefix, found?
6) Is a default Y Select local GW with Y

Send ACF
Tech Prefix set? the default Tech Prefix
N
N
90616
Send ARJ
Figure 9-48 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.

OL-21733-18 9-133
Chapter 9 Dial Plan
Dial Plan Elements
Figure 9-48 Gatekeeper Address Resolution for an LRQ
Y Y
1) Tech Prefix Match? Hop-off Tech Prefix? target_zone=hopoff zone
N
N
2) Zone Prefix Match? N Is "lrq reject-unknown-prefix" set? Y

Send LRJ
(no prefix guessing) (if N, Reset target-zone)
target_zone=matched_zone
N N
N Y
3) Is target-zone local? Is "lrq forward-querries" set? Send LRQ
4) Is target address Y
Send LCF
registered?
N Y
5) Was a Tech Prefix Y Find local GW with N

Send LRJ
found in Step 1? the Tech Prefix, found?
6) Is a default Y Select local GW with Y

Send LCF
Tech Prefix set? the default Tech Prefix
N
N
90617
Send LRJ
Traditional Cisco IOS gatekeeper functionality has been extended to accommodate for Cisco Unified
Border Elements through the concept of a via-zone gatekeeper.
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 a Cisco Unified Border Element in that zone by returning an ACF

9-134 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
pointing to the Cisco Unified Border Element. 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
Unified CM clusters. Figure 9-49 illustrates a distributed call processing environment with two
Unified CM clusters and a single, centralized gatekeeper.
Figure 9-49 Centralized Gatekeeper Supporting Two Clusters
Site 1 Site 2
Unified CM Unified CM
M M cluster
cluster
M M M M
M M M M
IP WAN
Si Si
IP IP IP IP IP IP
90618
Gatekeeper
Example 9-5 shows the gatekeeper configuration for the example in Figure 9-49.
Example 9-5 Configuration for Centralized Gatekeeper
gatekeeper
zone local GK-Site1 customer.com 10.1.10.100
zone local GK-Site2 customer.com
zone prefix GK-Site1 408.......
bandwidth interzone GK-Site1 160
bandwidth interzone GK-Site2 160
gw-type-prefix 1#* default-technology
arq reject-unknown-prefix
no shutdown
The following notes also apply to Figure 9-49:

• Each Unified CM cluster has a local zone configured to support Unified CM trunk registrations.
• A zone prefix is configured for each zone to allow inter-zone and inter-cluster call routing.

OL-21733-18 9-135
Chapter 9 Dial Plan
Dial Plan Elements
• Bandwidth statements are configured for each site. Cisco recommends that you use the bandwidth
interzone command because using the bandwidth total command can cause issues in some
configurations. Bandwidth is measured in kilobits per second (kbps).
• The gw-type-prefix 1# default-technology command allows all locally unresolved calls to be
forwarded to a device registered with a technology prefix of 1# in the local zone. In this example,
all Unified CM trunks have been configured to register with a 1# prefix.
Technology prefixes indicate the type of call being made. The specific values used as technology
prefixes are arbitrary and are defined by the network administrator. The same values should be used
consistently throughout the entire deployment.
Technology prefixes are sent as a prefix to the E.164 address (phone number) to indicate whether
the call is voice, video, or some other type. The # symbol is generally used to separate the prefix
from the E.164 number. If a prefix is not included, the default technology prefix is used to route the
call. There can be only one default technology prefix for the entire deployment.
Cisco IOS gateways automatically add a technology prefix to outbound calls if the gateway has a
prefix configured. The gateway also automatically strips the prefix from incoming H.323 calls.
Unified CM 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 Unified CM. You can use translation patterns and significant digits to manipulate
the called number so as to add or strip the technology prefix as needed.
• The arq reject-unknown-prefix command guards against potential call routing loops across
redundant Unified CM trunks.

9-136 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
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 9-50 illustrates a distributed call processing environment with two
clusters and two gatekeepers.
Figure 9-50 Distributed Gatekeepers Supporting Two Clusters
Site 1 Site 2
M cluster M
cluster
M M M M
M M M M
IP WAN
Si Si
IP IP IP IP IP IP
90619
Gatekeeper Gatekeeper
Example 9-6 shows the gatekeeper configuration for Site 1 in Figure 9-50.
Example 9-6 Gatekeeper Configuration for Site 1
gatekeeper
zone remote GK-Site2 customer.com 10.1.11.100
bandwidth remote 160
no shutdown
The following notes apply to Example 9-6:

• A local zone is configured for registration of local Unified CM cluster trunks.
• A remote zone is configured for routing calls to the Site 2 gatekeeper.
• Zone prefixes are configured for both zones for inter-zone call routing.
• The bandwidth remote command is used to limit bandwidth between the local zone and any other
remote zone.

OL-21733-18 9-137
Chapter 9 Dial Plan
Dial Plan Elements
Example 9-7 shows the gatekeeper configuration for Site 2 in Figure 9-50.
Example 9-7 Gatekeeper Configuration for Site 2
gatekeeper
no shutdown
The following notes apply to Example 9-7:

• A remote zone is configured for routing calls to the Site 1 gatekeeper.
remote zone.
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 9-51 illustrates a Unified CM distributed call processing environment with distributed
gatekeepers for local call routing and a directory gatekeeper to provide call routing between gatekeepers.

9-138 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
Figure 9-51 Distributed Gatekeepers with a Directory Gatekeeper
Site 1 Site 2
M cluster M cluster
Directory
M M
Gatekeeper M M
M M M M
IP WAN
Si Si
IP IP IP IP IP IP
90620
Gatekeeper Gatekeeper
Example 9-8 shows the gatekeeper configuration for Site 1 in Figure 9-51. Because the Site 1 and Site 2
gatekeeper configurations are almost identical in this example, only Site 1 is covered here.
Example 9-8 Gatekeeper Configuration for Site 1, with Directory Gatekeeper
gatekeeper
zone remote DGK customer.com 10.1.10.101
zone prefix DGK ..........
no shutdown
The following notes also apply to Example 9-8:

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

OL-21733-18 9-139
Chapter 9 Dial Plan
Dial Plan Elements
Example 9-9 shows the directory gatekeeper configuration for the example in Figure 9-51.
Example 9-9 Directory Gatekeeper Configuration
gatekeeper
zone local DGK customer.com 10.1.10.101
zone prefix GK-Site1 408*
zone prefix GK-Site2 212*
lrq forward-queries
no shutdown
The following notes also apply to Example 9-9:

• A local zone is configured for the directory gatekeeper.
• Remote zones are configured for each remote gatekeeper.
• Zone prefixes are configured for both remote zones for inter-zone call routing. The wildcard (*) is
used in the zone prefix to simplify configuration. Calls will not be routed to the DGK zone, so no
prefix is required for it.
• The lrq forward-queries command allows the directory gatekeeper to forward an LRQ received
from another gatekeeper.
Calling Privileges in Cisco IOS with H.323 Dial Peers

Use the class of restriction (COR) functionality to implement calling privileges with Cisco IOS-based
systems using H.323, including H.323 gateways, SRST, and Cisco Unified Communications Manager
Express (Unified CME). This functionality provides flexibility in network design, allows administrators
to block calls for all users (for example, calls to 900 numbers), and applies different calling privileges
to call attempts from different originators (for example, it allows some users but not others to call
international numbers).
The fundamental mechanism at the center of the COR functionality relies on the definition of incoming
and outgoing corlists that are associated to existing dial peers, where the concepts of incoming and
outgoing are relative to the Cisco IOS router (as in the case of dial peers). Each corlist is defined to
include a number of members, which are simply tags previously defined within Cisco IOS.
When a call goes through the router, an incoming dial peer and an outgoing dial peer are selected based
on the Cisco IOS dial peer routing logic. If corlists are associated with the selected dial peers, the
following additional check is performed before extending the call:
• If the members of the outgoing corlist associated with the outgoing dial peer are a subset of the
members of the incoming corlist associated with the incoming dial peer, the call is permitted.
• If the members of the outgoing corlist associated with the outgoing dial peer are not a subset of the
members of the incoming corlist associated with the incoming dial peer, the call is rejected.

9-140 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
If no corlist statements are applied to some dial peers, the following properties apply:
• When no incoming corlist is configured on a dial-peer, the default incoming corlist is used. The
default incoming corlist has the highest possible priority, and it therefore allows this dial-peer to
access all other dial-peers, regardless of their outgoing corlist.
• When no outgoing corlist is configured on a dial-peer, the default outgoing corlist is used. The
default outgoing corlist has the lowest possible priority, and it therefore allows all other dial-peers
to access this dial-peer, regardless of their incoming corlist.
This behavior is best illustrated with an example as shown in Figure 9-52, where one VoIP dial-peer and
two POTS dial-peer are defined.
Figure 9-52 Example of COR Behavior

destination-patttern 1..
1. OK corlist outgoing c2
member A
dial-peer voice 1voip
member B
corlist incoming c1
1. Call 100 member A dial-peer voice 3pots
member B destination-patttern 2..
2. Call 200 member C corlist outgoing c3
2.
member A
member B
STOP
114719
? member D
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 9-52, 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.

OL-21733-18 9-141
Chapter 9 Dial Plan
Dial Plan Elements
Follow these steps when configuring the COR functionality in Cisco IOS:
Step 1 Define "tags" to be used as corlist members with the command dial-peer cor custom.
Step 2 Define corlists with the command dial-peer cor list corlist-name.
Step 3 Associate corlists with existing VoIP or POTS dial-peers by using the command corlist {incoming |
outgoing} corlist-name within the dial-peer configuration.
With Cisco IOS Release 12.2(8)T and later, you can apply the COR functionality to SRST-controlled IP
phones. Because IP phones register with the SRST router dynamically, SRST has no prior knowledge of
the individual phones until they lose connectivity to the Unified CM cluster. Therefore, the COR feature
configuration for SRST is based on the phone DNs instead. When the IP phones register with the SRST
router, they communicate their DN to it, thus allowing the SRST router to assign them to the appropriate
corlist.
Configure COR for IP phones controlled by SRST by using the command cor {incoming | outgoing}
corlist-name {corlist-number starting-number – ending-number | default} within the
call-manager-fallback configuration mode.
The following limitations apply to this command:
• The maximum number of cor {incoming | outgoing} statements under call-manager-fallback is 5
(plus the default statement) in SRST version 2.0, available on Cisco IOS Release 12.2(8)T or later.
• The maximum number of cor {incoming | outgoing} statements under call-manager-fallback is 20
(plus the default statement) in SRST version 3.0, available on Cisco IOS Release 12.3(4)T) or later.
The COR functionality can also be deployed with Cisco Unified Communications Manager Express
(Unified CME), using Cisco IOS Release 12.2(8)T and later. Because the individual IP phones are
specifically configured within Unified CME, 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, page 9-71, for an example
of how to apply all these concepts in practice.
For more details on configuration of Cisco SRST and Unified CME, refer to the Cisco SRST System
Administrator Guide and the Cisco Unified Communications Manager Express System Administrator
Guide, both 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.

9-142 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
You configure voice translation profiles by using the voice translation-rule and voice
translation-profile Cisco IOS commands, which use regular expressions to define the digit strings to be
modified. You then specify if the manipulations should be associated to calling numbers, called numbers,
or redirected called numbers. After you define a voice translation profile, you can apply it to any of the
following elements:
• All incoming POTS call legs that terminate on a specific voice port
• All incoming VoIP call legs into the router
• Outgoing call legs associated with a specific VoIP or POTS dial peer
• All incoming or outgoing call legs that terminate on the IP phones controlled by SRST
• Incoming call legs for calls originated by all IP phones controlled by SRST
Note Voice translation profiles using the voice translation-rule command replace and enhance the
functionality previously provided by the translation-rule command. The syntax of the new command
differs from that used by the old command. For more details, refer to voice translation-rule in the
Cisco IOS Voice Command Reference, Release 12.2(11)T or later, available at http://www.cisco.com.
A typical application of voice translation profiles is to enable the preservation of on-net inter-site dialing
habits from a branch site even when the IP WAN is unavailable and the router is running in SRST mode.
For example, consider a simple deployment with a central site in San Jose and three remote sites in San
Francisco, New York, and Dallas. Table 9-10 shows the DID ranges and the internal site codes for this
example.
Table 9-10 Example of DID Ranges and Site Codes for Translation Rule Application
San Jose San Francisco New York Dallas

DID Range (408) 555-1XXX (415) 555-1XXX (212) 555-1XXX (972) 555-1XXX
Site Code 1 2 3 4
Inter-site calls are normally placed across the IP WAN by dialing the on-net access code 8 followed by
the one-digit site code and the four-digit extension of the called party. To preserve these dialing habits
even when the IP WAN is down and Cisco SRST is active, the internal numbers must be converted back
into the E.164 numbers before being sent to the PSTN. A sample configuration for the San Francisco
router is as follows:
voice translation-rule 1
rule 1 /^81/ /91408555/
rule 2 /^83/ /91212555/
rule 3 /^84/ /91972555/
voice translation-profile on-net-xlate

translate called 1
call-manager-fallback
translation-profile outgoing on-net-xlate

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

OL-21733-18 9-143
Chapter 9 Dial Plan
Dial Plan Elements
With this configuration, when the San Francisco site is in SRST mode and a user dials 831000, the router
will match rule 2 of voice translation-rule 1 and translate the called number to 912125551000. This
new number will then be used to match the outgoing dial peer (dial-peer voice 2).
For a detailed description of dial peers and their configuration, refer to Configuring Dial Plans, Dial
Peers, and Digit Manipulation, part of the Cisco IOS Voice, Video, and Fax Configuration Guide,
Release 12.2, available at
For a thorough explanation of regular expression syntax in Cisco IOS, refer to the information on
Regular Expressions in the Cisco IOS Terminal Services Configuration Guide, available at
http://www.cisco.com/en/US/docs/ios/termserv/configuration/guide/tsv_reg_express_ps6441_TSD
_Products_Configuration_Guide_Chapter.html
Service Advertisement Framework (SAF) Call Control Discovery (CCD)

This section highlights some aspects of the Cisco Service Advertisement Framework (SAF) Call Control
Discovery (CCD) service configuration in Unified CM and related Unified Communications
subsystems. For more details on this subject, refer to the section on Call Routing and Dial Plan
Distribution Using Call Control Discovery for the Service Advertisement Framework, page 5-64, and to
the latest version of the Cisco Unified Communications Manager Administration Guide, available at
By participating in the framework as a CCD advertiser, a Unified CM cluster injects information into the
network about the DN ranges it hosts. This information is sent to a Service Advertisement Framework
Forwarder (SAF Forwarder), which learns the new routes and shares them with other participating SAF
Forwarders and CCD requestors in the network.
By participating in the framework as a CCD requestor, a Unified CM cluster learns the DN ranges
advertised by other call agents in the network from a SAF Forwarder.
SAF Forwarders
SAF Forwarders are configured on Cisco IOS routers and require Cisco IOS Release 15.0(1) or higher.
For more information on configuring SAF Forwarders, consult the Cisco IOS Service Advertisement
Framework Configuration Guide, available at
http://www.cisco.com/en/US/docs/ios/saf/configuration/guide/15_0/saf_15_0_book.html
SAF Forwarder Configuration

Within Unified CM, you need to configure both a SAF Security Profile (Advanced Features > SAF >
SAF Security Profile) and a SAF Forwarder (Advanced Features > SAF > SAF Forwarder).
The SAF Security Profile configuration page in Unified CM features User Name and User Password
fields. These entries must match the SAF Forwarder configuration in the Cisco IOS command line
interface (CLI).
Also, the Unified CM Client Label as configured under the SAF Forwarder configuration page must
match one of the external-client statements from the SAF Forwarder's CLI configuration. For example:
service-family ipv4 autonomous-system 1
!
topology base
external-client sample_client_label
exit-sf-topology

9-144 OL-21733-18
Chapter 9 Dial Plan
Dial Plan Elements
exit-service-family
!
service-family external-client listen ipv4 5050

external-client sample_client_label
username sample_user_name
password sample_user_password
keepalive 10000
!
For more details, refer to the Cisco IOS Service Advertisement Framework Configuration Guide,
available at
http://www.cisco.com/en/US/docs/ios/saf/configuration/guide/15_0/saf_15_0_book.html
Requesting Service
The SAF CCD learned DN ranges are populated in a dedicated CCD call routing partition in the
requesting cluster. Learned DN ranges are associated with one or more CCD trunks. Calls made to CCD
learned DN ranges are placed through CCD trunks associated with the requesting service. The
association of CCD trunks with the requesting service is done through the Selected SAF Trunks filed
under the CCD Requesting Service Info page in Unified CM, located under Call Routing > Call
Control Discovery > Requesting Service.
The CCD records exchanged between a cluster and a SAF Forwarder include information about the DN
range, the IP address of the call agent node hosting the DN range, the digit manipulation rules to adapt
a DN when rerouting the call to the PSTN, and the IP signaling protocol required to call this DN range.
For example, Cluster A hosts DN range 8555XXXX, whose corresponding DID range on the PSTN is
+1415555XXXX. The IP address of the Cluster A subscriber associated with the CCD trunk designated
to receive IP calls for this DN range is 10.1.1.1. The protocol required to reach this DN range is SIP. The
CCD record associated with this DN range can be represented as follows:
DN Range ToDID IP Protocol

8555XXXX 1:+1415 10.1.1.1 SIP
• DN range
If a user dials 85551234, a match would be made on 8555XXXX and a call to 85551234 would be
extended to the cluster that advertised the pattern.
• ToDID
This field represents the rules allowing the DN range to be reached across the PSTN. If a user dials
85551234 and the call cannot be routed through a CCD trunk, the ToDID rules are applied and the
destination number is transformed to a form compatible to the PSTN. For example, the rule 1:+1415
applied to the range 8555XXXX would require the removal of one digit and the prefixing of +1415.
The resulting +14155551234 would allow routing of the call to any gateway in the cluster of origin,
provided that it is provisioned to route calls in the +E.164 form and that gateways are provisioned
with appropriate called party transformation patterns to adapt the globalized +E.164 form of the
number to a localized form acceptable to the PSTN carrier.
• IP
The IP address of the destination DN's hosting call agent node is used when placing a call across the
associated CCD trunk, in the cluster of origin.

OL-21733-18 9-145
Chapter 9 Dial Plan
Dial Plan Considerations for Business Edition 3000
• Protocol
In this case, SIP is the protocol advertised by the call agent hosting the DN range. The other possible
choice is H.323.
To view which SAF CCD records were discovered by a particular cluster, use the Cisco Unified CM
Real-Time Monitoring Tool (RTMT). It offers information about the discovered DN ranges as well as
information about the SAF Forwarder associations with the cluster.

Cisco Business Edition 3000 comes with a highly simplified front end with a drawer user interface
(GUI). New concepts such as Site and Usage profiles have been introduced. Although the underlying
concept of dial plan still remains the same with the line/device approach and calling search spaces,
Business Edition 3000 implements the dial plan by using the concepts of sites and profiles. The calling
privileges at the device level are defined by the Site, and restrictions to the calling privileges at line level
are defined by the Usage profile, as follows:
• Site
Site represent the geographic grouping of endpoints, including phones, users, gateways, and so
forth. Privileges are given to a Site, which define the highest level of calling privileges each user at
that site can achieve. This does not mean that every user will have those privileges; instead, the
privileges govern the capability of each location to make calls. For example, a location can have
calling privileges to dial international numbers, but that does not necessarily mean that every user
at the site can make international calls.
• Usage profile
A usage profile allows the system administrator to configure most of the user settings for a phone
in one place. The administrator can edit an existing usage profile, duplicate an existing usage profile
to create a new profile, or add an entirely new usage profile. Each usage profile has a unique name.
After configuring usage profiles, the system administrator can assign them to users or to
departments, so that the settings in the usage profile apply to the phones that belong to an individual
user or to an entire department.
In the Usage profile, you can configure calling privileges for users; phone features such as barge, Cisco
Extension Mobility, and so on; phone hardware functionality; phone applications that may display on
the phone; and the phone button template, which controls the order of the buttons and the feature buttons
that display on the phone.
Note Cisco Business Edition 3000 supports a maximum of 10 usage profiles.
The combination of Site privileges and Usage calling privileges define the actual capability for a user to
dial numbers. For example, a Site can be allocated privileges to dial international calls as the highest
level of calling, which essentially means that users can dial any number including international, long
distance, and local calls. But if a user is attached to a usage profile that limits the dialing privilege to
local calls only, then that user will be able to dial only local calls even though the site has privileges to
dial international calls.
As another example, assume that the user is associated to a Usage profile and a Site that both have calling
privileges to dial international calls. If this user moves to another site where the Site level privileges are
limited to dialing local calls only, then this user will not be able to dial beyond local calls because the
current site level calling privileges do not allow it.

9-146 OL-21733-18
Chapter 9 Dial Plan
Essentially, the lower of the Site level calling privileges and the Usage profile calling privileges
determines the calling privileges for a user.
Translation Rules
Translation rules allow Cisco Business Edition 3000 to manipulate an incoming phone number that is
part of your system and transform it to an extension before routing the call. Any call coming into the
system or generated by IP phones is matched against the configured translation rule, and if the number
matches, the translation is performed.
Note Support for wild cards in translation rules is not available with Business Edition 3000.
Every phone is associated to a site based upon the IP address configured on the phone. Every site is
mapped to one or more subnet(s). If the phone IP address lies within one of those subnets, then the phone
belongs to the site to which that subnet is mapped. If the phone acquires an IP address that is not defined
in the system, then phone is assumed to be part of the central site. However, if a teleworker site is
configured, then any phone whose configured IP address does not lie within one of the configured
subnets will be assumed to be a teleworker phone.
The configured sites provide support for logical partitioning. While configuring sites, the administrator
is required to configure the PSTN privileges. If access to the central site PSTN is not configured, the
users at a remote site will not be allowed to be part of any conversation where a PSTN call leg is involved.
Also, the remote site phones will not be able to initiate PSTN calls.

OL-21733-18 9-147
Chapter 9 Dial Plan

9-148 OL-21733-18

Dial Plan

Uploaded by

Copyright:

Available Formats

Dial Plan

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dial Plan

Uploaded by

Copyright:

Available Formats

CH A P T E R 9

Revised: July 31, 2012; OL-21733-18

Cisco Unified Communications System 8.x SRND

What's New in This Chapter

New or Revised Topic Described in Revision Date

Cisco Unified Communications System 8.x SRND

New or Revised Topic Described in Revision Date

Dial Plan Architecture

Figure 9-1 Basic Dial Plan Architecture

Digit analysis: Call routing:

Cisco Unified Communications System 8.x SRND

High Availability for Dial Plans

Capacity Planning for Dial Plans

Cisco Unified Communications System 8.x SRND

Dialed Pattern Recognition

Cisco Unified Communications System 8.x SRND

Grouping by Dialing Habits

On-Net versus Off-Net Dialing

Cisco Unified Communications System 8.x SRND

Avoiding Overlap of Extension Dialing

Cisco Unified Communications System 8.x SRND

Dialing String Length

Uniform On-Net Dial Plan

Cisco Unified Communications System 8.x SRND

Table 9-2 Distribution of Digits in a Typical Four-Digit Uniform Dial Plan

Range Use DID Ranges Non-DID Ranges

Cisco Unified Communications System 8.x SRND

Variable Length On-Net Dial Plan

Table 9-3 Typical Use of Site Codes

Site Code Range Use DID Ranges Non-DID Ranges

On-Net and Off-Net Access Codes

Cisco Unified Communications System 8.x SRND

Cisco Unified Communications System 8.x SRND

Globalized Design Approach

Cisco Unified Communications System 8.x SRND

Together, these new features enable a Unified CM system to:

Local Route Group

Support for + Dialing

Cisco Unified Communications System 8.x SRND

Calling Party Number Transformations

Called Party Number Transformations

Incoming Calling Party Settings (per Gateway)

Cisco Unified Communications System 8.x SRND

Cisco Unified Communications System 8.x SRND

Localized Call Ingress

Localized Call Ingress on Phones

Cisco Unified Communications System 8.x SRND

Phone Calling Party Number Globalization

Allowing Call Ingress Using the Global Form

Cisco Unified Communications System 8.x SRND

Figure 9-2 Allowing Localized and Globalized TUI

CSS’s Partitions Route Lists Route Groups

PSTN USPSTNNational Local

Cisco Unified Communications System 8.x SRND

Localized Call Ingress on Gateways

Cisco Unified Communications System 8.x SRND

Globalized Call Routing

Localized Call Egress

Phone Calling Party Number Localization