Expert Reference Series of White Papers

CUCM v7 Dial Plan

Enhancements and
Their Effect on the Dial
Plan

1-800-COURSES www.globalknowledge.com
CUCM v7 Dial Plan Enhancements
and Their Effect on the Dial Plan
Berni Gardiner, Certified Cisco Instructor

Introduction
The dial plan is a key element in Cisco Unified Communications Manager (CUCM) environments. The dial plan is
at the very core of the user experience. For companies that have multiple locations, or that are global, a com-
prehensive dial plan can become large and very complex. These companies will see the greatest benefits when
implementing the new dial plan elements of CUCM7.

Changes to CUCM7
For each location, administrators must configure a separate set of dial plan components such as route patterns,
route groups, route lists, Tail End Hopoff (TEHO) patterns, and Automatic Alternate Routing (AAR) groups to
handle location prefixing. For a company that has many locations, either national or global, this configuration
can become extremely cumbersome and difficult to create and manage.

CUCM 7 addresses this challenge and provides new dial plan elements that dramatically simplify dial plan
configuration. These new elements allow administrators to improve both the end-user experience and the
administrative task of creating and maintaining the dial plan. There are two major changes in the way dial plan
administration can be handled using new configuration elements of CUCM 7.

The first change is to decouple specific route group configuration from route list configuration. The route list
can now be configured to point to a generic route group called the Standard Local Route Group. This will
eliminate the need for a set of route patterns and route lists per location and is discussed in more detail in the
Local Route Group section below.

The second change is to perform call route processing using a “normalized number” format. The idea is that
each location will take a “locally formatted number” and convert it to a number in “standard format” for call
route processing. The chosen standard format is the “globalized notation,” which presents numbers in E.164
format. Once a call is routed to the destination device – either gateway, another CUCM cluster, or phone – the
number is converted back into a local format based on the location of the device.

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 2

 Figure 1. Example of Number Normalization

The new configuration components that support number normalization include the following:
• Support for “+” dialing
• Calling Party Number Transformations
• Called Party Number Transformations
• Incoming Calling Party Settings per Gateway

Collectively, these new features enable a CUCM system to:

• R
 oute calls based on the physical location of the caller using the local route group assigned through the
component’s device pool.
• R
 epresent calling and called party numbers in a global format conforming to the International Telecom-
munications Union’s E.164 recommendation.
• P resent calls to external networks (for example, the PSTN) in a manner compatible with the local re-
quirements for calling party number, called-party number, and their respective numbering types.
• P resent callers with both the local and global form of the calling party number on incoming calls from
gateways, based on the calling number digits and the numbering type.

Overall improvements include:

• Significantly fewer route patterns, route lists, and AAR group configurations.
• U
 sers who roam outside of their normal dialing area will no longer need to know the dialing require-
ments of each country as they travel through it. Users can now dial an E.164 formatted number and
have the dial plan determine what digit manipulation is required for the local PSTN to process the call.
• A
 s new locations are added to the dial plan, using localization and globalization techniques, the admin-
istrator needs only to be concerned with the local dial requirements of that site and how to globalize
the number for CUCM processing.
• Digit manipulation has been removed from the route list and moved to each local gateway.

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 3

Local Route Group
The Challenge: Prior to the availability of local route groups, the administrator had to configure, per location,
multiple route patterns pointing to a location’s route list, which pointed to the location’s route group, which
pointed to the local gateway for each site.

For example the configuration could contain the following route patterns.
1. 911
2. 9.911
3. 9.[2-9]11 (3 digit service calls)
4. 9.[2-9][02-9]XXXXX (local 7 digit dialing)
5. 9.[2-9]X[02-9]XXXX (local 7 digit dialing)
6. 9.313XXXXXXX (local 10 digit dialing)
7. 9.1[2-9]XXXXXXXXX (long distance dialing)
8. 9.011! (international dialing)
9. 9.011# (international dialing)

This would result in nine route patterns per location, one route list per location, and one route group per loca-
tion – assuming only one gateway or multiple gateways requiring the same digit manipulation, giving a total
of eleven elements to be configured per location. Multiply that by just ten locations and the total elements
required would be 110 configuration components.

The biggest issue is that the only way to send calls out of a local gateway is to point each copy of the route pat-
tern to each location’s gateway through a route list –> route group –>gateway combination.

The Solution: The new standard local route group element changes the approach of defining which gate-
way a call exits out through. The local gateway is applied to each phone through local route group assignment
in the device pool configuration and defines what gateway is local to the phone initiating the call. The assump-
tion is that when a call originates on a particular phone, the call should be routed out through that phone’s local
gateway.

Figure 2. Device Pool Settings

The number of route groups will not change. There will still be at least one route group per location. However,
the benefits will be in the number of route patterns and route lists required. In this instance, administrators will

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 4

only need to configure one set of route patterns that will be used across all locations. The route patterns will
point to a single route list, which in turn will point to the new generic standard local route group element.

Figure 3. Route List Information and Route List Information

When a call is initiated on a particular phone a route pattern would be matched. If the route pattern points to
a route list whose only element is the standard local route group, then CUCM looks to the device pool of
the originating phone to determine which gateway is local to the phone. The call will be routed through that
gateway.

Figure 4. Pattern Definition

The Result: Assuming the same nine route patterns defined in the challenge and the same ten locations, the
configuration would require nine route patterns (instead of nine route patterns per location), one route list
pointing to the standard local route group (instead of one route list per location), and one route group per loca-
tion. The total number of configuration elements would total 20 elements (9+1+10) as opposed to 110 prior to
using local route groups. This equals 90 configuration elements the administrative group doesn’t have to define.
If we extrapolate the numbers to a company with 100 locations, the requirement would be nine route patterns,
one route list, 100 route groups, giving a significant configuration savings of 990 configuration elements.

Support For “+” Dialing

The Challenge: Consider a phone user who is traveling to several European corporate locations and wishes
to use their Cisco IP Communicator to place calls back to headquarters in the United States. As the user travels

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 5

through different countries, she must be aware of and dial the correct access codes used by that country to con-
nect an international call.

For example, to reach the corporate HQ number (313) 555-1002 when traveling through the UK, the user would
have to dial 9 00 13135551002. Contrast that to the requirement of dialing 0 00 13135551002 when traveling
through France. Phone users may find it difficult to remember the correct access codes

Another challenge lies in the fact that in a multi-site environment, the dial plan format may vary across sites.
Some sites may use five-digit local dialing, while others may require location codes plus extensions to reach
those locations, while dialing to the PSTN may require yet another set of access codes. In an increasingly com-
plex environment, it may be difficult to keep track of variable dial plans and the interactions between dialing
requirements across locations.

The Solution: E.164 is an ITU-T recommendation that defines the international public numbering plan used in
PSTNs around the world. It also defines country codes and the format of telephone numbers. E.164 numbers can
have a maximum of fifteen digits and are usually written with a + prefix.

CUCM7 now supports the use of the + prefix to address the challenge of roaming users. A route pattern can
be defined to recognize when the user has dialed a number including the + prefix. In each location, the system
would translate the destination number into the locally required digit string to allow the call to be routed prop-
erly.

The + prefix indicates that the number that follows contains the country code and subscriber number. If a PSTN
accepts a dialed number that starts with the + prefix, then the user does not need to enter the international
prefix required for international calls being placed in that country. If the PSTN does not accept a dialed number
that starts with the + prefix, then the system can perform the appropriate digit manipulation.

For example, for the call being placed from the UK to the US head office, the user no longer needs to dial the “9
00” as the international access code prior to dialing 13135551002. He simply dial +13135551002 (perhaps by
selecting a speed dial entry containing the +) and the local PSTN would recognize that this is an international
call destined for the country using country code 1 (North America being part of that country code).

Figure 5. Pattern Definition

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 6

For those components, such as a route pattern, where the + sign has alternate meaning, the configuration al-
lows for the use of the “\” character to signify that the + sign is meant to denote the E.164 number format.

Not all phones allow the user to actually dial the + prefix as part of the dialed number, but it can be entered as
part of a speed dial entry.

The Result: A user traveling across Europe can configure a speed dial entry for commonly called numbers that
includes the + prefix, followed by the country code and subscriber number. Once traveling, she can then simply
choose the same speed dial, regardless of which country she is traveling through. This dramatically improves the
user experience and simplifies the administrative tasks for support of international calling.

Calling Party Transformation Pattern

The Challenge: When a call arrives at a destination phone, the caller id associated with the originating phone
will be displayed. If a user wishes to call this number back, perhaps by selecting it from the missed calls list, he
must ensure that all the required codes and digits are present for the callback. This normally requires effort on
the part of the user to edit the number prior to placing the call.

For example, a long-distance call arrives at the destination phone with a caller id of 313-555-1234. In order for
the user to dial that number back, they will need to edit the number and prefix the access code “9” as well as
the “1” needed for a long-distance call.

CUCM may have globalized the calling number into an E.164 format when the call came into the CUCM for pro-
cessing. In that case, the calling number may have the format of +13135551234 just prior to being presented to
the phone. It may need to be presented as 913135551234 for callback to succeed.

The Solution: When calls are routed from CUCM to an internal phone or out to a gateway, the administrator
can configure a new element called the Calling Number Transformation Pattern to control the format
of the calling number. This is a global transformation pattern that is placed into a partition and is associated to
internal telephones or gateways via a Calling Party Transformation CSS.

Thus, when CUCM is routing the call to a phone or gateway, it will check the existing calling number against the
configured Calling Number Transformation Patterns to determine if there is a match. It will then check the Trans-
formation CSS of the phone or gateway to determine if that phone or gateway has access to that Transformation
Pattern. If the phone’s Calling Party Transformation CSS contains the partition of the Calling Party Transforma-
tion Pattern, then the transformation parameters will be applied to the calling number prior to presentation.

In the following example, the calling party transformation pattern is used to localize the calling number to a
seven-digit number and prefix the access code 9 for outbound calls.

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 7

 Figure 6. Pattern Definition and Calling Party Transformation

This Calling Party Transformation Pattern partition must be part of the phone’s Calling Party Transformation CSS
as shown below.

Figure 7. Calling Search Space Information and Route Partitions for this Calling Search Space

The Calling Party Transformation CSS is applied to the phone.

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 8

 !

Figure 8. Phone Type and Device Information

The Result: End-users will be able to return missed calls or place calls from call lists without having to edit the
number with conforming access codes and formats. This will improve the user experience and lessen the chance
for mis-dialed calls

Called Party Transformation Pattern

The Challenge: When a call is routed to a local gateway for delivery to the PSTN, the administrator must
ensure that the number is presented to the PSTN in the expected format.

For example, say a call is placed to +14085551234, which is an area code in San Jose. If the call was placed
from a San Jose gateway, the forwarded digits would need to be 4085551234. If the call was placed from a New
York gateway, the forwarded digits would need to be 14085551234. If the call was placed from a UK gateway,
the forwarded digits would need to be 0014085551234. In prior configurations, this digit manipulation was
done for each route group in a route list. Now that we can point the route list to the generic standard local
route group, we need to perform the digit manipulation elsewhere.

The Solution: Digit manipulation for outbound calls can now be associated with each outbound gateway or
trunk via the use of Called Party Transformation Patterns.

Called Party Transformation Patterns are configured globally and are placed in specific partitions. As a call is
routed out a gateway or trunk, the Called Party Transformation CSS is checked to see if there is potential digit
manipulation required for the called number of the outbound call.

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 9

 !

Figure 9. Device Information

If a Called Party Transformation CSS is configured, either directly in the gateway or through the device pool, then
the called number is matched against all Called Party Transformation Patterns whose partitions are in the CSS. If
one is matched, the digit manipulation configured in that pattern is applied to the called number. That number is
then forwarded as the new called number out the gateway or trunk.

The Result: Digit manipulation is now configured as a global definition and can be associated with individual
gateways or trunks through CSS assignment. This more modular approach allows potentially less configura-
tion as you can associate a single pattern with multiple gateways or trunks. It also provides a way to configure
outbound digit manipulation when route lists point to the generic local route group.

Incoming Calling Party Prefix Settings per Gateway

The Challenge: If the approach to dial plan administration involves globalization of numbers as a call enters
the CUCM environment, then we need to have a way of determining what the globalized format of the caller
should be.

In North America, the problem isn’t as challenging since we have a fixed numbers of digits we expect to see. For
example, if a call comes in with a seven-digit caller id, then we know we need to prefix the plus (+), the country
code (1), and the area code (xxx) to the seven-digit number to globalize it.

However, for companies with global offices, the problem is a bit more challenging. For example, if a call with
caller id of 691234567 comes into a gateway in Hamburg, Germany, we need to know whether the “69” at the
beginning of the number is a city code (Frankfurt) or if it is part of a subscriber number in Hamburg. For the
former, we would need to prefix + 49 to the 69 1234567 in order to globalize it. For the latter, we would need to
prefix +49 40 to the 69 1234567 (40 being the city code for Hamburg). We need to identify whether the incom-
ing call is local, long-distance, or international in order to globalize it properly.

The Solution: When using ISDN connections to the PSTN, the information identifying each inbound call con-
tains not only the called and calling numbers, but also a parameter called type of number (TON). The TON
identifies whether the number came in as a subscriber number, a national number, an international number,
or is unknown. The TON values have the following meanings:
• Subscriber – the call is a local call, in North America that is either a 7 or 10 digit local number.

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 10

 • National – the call is from within the same country, but is a long-distance call.
• International – the call originated from outside the country.
• U
 nknown – the call has an unknown format (this would be the case for a PRI connecting a PBX to a
gateway where extensions are being used).

In previous versions of CUCM, calling party prefixes based on TON were only configurable through cluster-wide
service parameters. This limited the ways that the TON could be used to format the caller id.

In CUCM 7, calling party prefixes can be assigned on a per-gateway configuration. This means the TON can
now be used to globalize caller id since the prefixes may be different gateway by gateway, based on the calling
number.

Figure 10. Device Information and Incoming Calling Party Settings

The settings can be configured on the gateway itself, through the device pool assigned to the gateway, or glob-
ally in the service parameters.

The Result: By expanding the calling party prefix configuration to the gateway level, this allows the ap-
propriate prefixes for each numbering type to be applied to calls entering different gateways. This simplifies the
configuration of number globalization in the CUCM environment.

Summary
Collectively, the CUCM7 dial plan enhancements provide administrators with the tools to simplify dial plan
configuration for global environments or corporate environments with multiple locations. Use of these new
elements allows dial plans to contain fewer configuration components and provides more flexibility by moving
appropriate configurations to the edge devices such as gateways, trunks and IP phones.

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 11

Learn More
Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge.
Check out the following Global Knowledge courses:
Cisco Advanced Dial Plan and Integration (CADPI)
Implementing Cisco Unified Communications Manager 7.0 (UCM70)
Administering Cisco Unified Communications Workspace Part 1: Basic (ACUCW1)

For more information or to register, visit www.globalknowledge.com or call 1-800-COURSES to speak with a
sales representative.

Our courses and enhanced, hands-on labs offer practical skills and tips that you can immediately put to use. Our
expert instructors draw upon their experiences to help you understand key concepts and how to apply them to
your specific work situation. Choose from our more than 1,200 courses, delivered through Classrooms, e-Learn-
ing, and On-site sessions, to meet your IT and business training needs.

About the Author

Berni Gardiner is a Certified Cisco Instructor and has taught for Global Knowledge since 1998. Berni’s 30+ years
of technical expertise spans software development, network design and implementation, and Voice over IP
design and implementation. Over the past nine years, Berni has focused on converged network design, integrat-
ing voice technologies into data networks. Berni teaches a variety of Cisco courses including Implementing Cisco
QoS, CVoice, Cisco IP Telephony I and II, Administering Unity and Unity Connection, and Implementing Cisco
Gateways and Gatekeepers. Berni has worked with Global Knowledge and Cisco as the Subject Matter Expert
(SME) to develop material for multiple Cisco training courses in the voice arena. Her real-world experience in-
cludes working with local and national ISPs for network provisioning, as well as consulting on VoIP implementa-
tions across North America.

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 12