Cisco Unified Communications Manager 7 Dial Plan Enhancements and Their Effect on the Dial Plan

Abstract

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. These new elements allow dial plans to contain fewer configuration components and provide more flexibility by moving appropriate configurations to the edge devices such as gateways, trunks, and IP phones. This white paper presents the changes to CUCM7 and some of the challenges and solutions CUCM7 provides.

Sample

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 comprehensive 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.

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:

Route calls based on the physical location of the caller using the local route group assigned through the component's device pool.
Represent calling and called party numbers in a global format conforming to the International Telecommunications Union's E.164 recommendation.
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.
Present 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.
Users who roam outside of their normal dialing area will no longer need to know the dialing requirements 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.
As new locations are added to the dial plan, using localization and globalization techniques, the administrator 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.

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 location - 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.