Cisco Unified Communications Manager 8: Call Routing, Dial Plan, and E.164

Further resources related to this subject:


Even if you're not interested in E.164, the recipes in this article can be applied to building any style of dial plan while utilizing some of the feature benefits to make dial plan management easier than before.

Implementing local route groups with device pools for E.164 call routing

To simplify call routing and dial plan management, local route groups provide a logical way to process calls according to settings specific to the device pool of the originating device.

Getting ready

This recipe assumes you have a gateway or trunk device configured.

How to do it...

To implement a local route group for use with a device pool, perform the following:

  1. Add a new route list that will serve as the link to the local route groups (Call Routing Route/Hunt | Route List|).
  2. Click on Add New to add a new route list.
  3. Type in a name and select a Call Manager Group in the drop-down with which the route list will be associated:

  4. Click on Save.
  5. Once the page reloads, click on Add Route Group and a new page will open.
  6. Select Standard Local Route Group from the Route Group drop-down menu then click on Save. You will be returned to the Route List page:

  7. Finally, click on Save to save the Route List.
  8. Add a new route group containing the gateway or trunk (Call Routing Route/Hunt | Route Group|).
  9. Find and select your gateway or trunk under the Find Devices to Add to Route Group section. Then click on Add to Route Group. You should now see the device in the Selected Devices list:

  10. Click on Save. The device will show up under Route Group Members.
  11. Assign the route group you created in the previous step to the device pool by navigating to the device pool (From the menu, System Device Pool|) configuration page and selecting the route group from the Local Route Group drop-down under the Device Pool Settings section:

  12. Click on Save.

    These changes will not take effect until you reset the devices in the device pool.

How it works...

Prior to the introduction of local route groups in CUCM, dial plans relied on route patterns pointing to specific gateways and route lists in site-specific partitions. By utilizing local route groups with device pools we can simplify call routing and reduce the number of route patterns needed throughout the system, thereby making the overall system simpler and maintenance easier.

There's more...

When a call is placed on the system it matches a route pattern that informs the system where to send the call, typically a route list containing trunks and gateways. When the system is told to send the call to a route list containing the Standard Local Route Group, the egress gateway is determined by information pulled from the device pool settings of the device that initiated the call, and routes it accordingly.

Implementing E.164 route patterns and partitions

An advantage of an E.164 dial plan is that it requires only a single route pattern to make it all work, though additional route patterns are still needed to allow users to dial using traditional dialing and TEHO. Here we will create the route partition to be used by the E.164 route pattern.

How to do it...

To create the route pattern to support an E.164 dial plan, we will do the following:

  1. Add a new partition, which will be globally accessible, by clicking Add New on the Partitions page located in the Class of Control submenu under the Call Routing menu.

  2. Enter in a partition name and a description in the text box and then click on Save.
  3. Add the E.164 Route Pattern and assign the Route List to it (Call Routing Route/ Hunt | Route Pattern|).
  4. Click on Add New.
  5. Enter \+.! for the Route Pattern and select the route partition previously created in the Route Partition drop-down:

  6. From the Gateway/Route List* drop-down, select the route list containing the Standard Local Route Group.
  7. Ensure that the Call Classification is OffNet and the Route Option is set to Route this pattern.
  8. Click on Save.
      1. Add the calling party transformation pattern (Call Routing | Transformation | Transformation Pattern | Calling Party Transformation Pattern|).
      2. Add the transformation pattern appropriate to your environment and location:

      3. Prefix any necessary digits and select the appropriate digit discard field. In the case of the previous example, Discard Digits is set to PreDot with no digits being prefixed.
      4. Add the called party transformation pattern (Call Routing Transformation | Transformation Pattern | Called Party Transformation Pattern|).
      5. Add the appropriate transformation pattern and any prefix digits necessary. In this case, we again choose PreDot for Discard Digits and set Prefix Digits to 9. Refer to the There's more... section for further explanation if required.

      6. Navigate to the configuration page for the port or device.
      7. On a MGCP controlled gateway, transformations are configured on a per port basis. The configuration page for the port is found by navigating to the configuration page for the gateway, then selecting the appropriate T1 port under the Configured Slots, VICs and Endpoints section as indicated in the following screenshot:

      8. This is configured at the device level for trunks and gateways.
      9. Next we apply the transformations to our trunks or gateways. Calling party transformations are configured under the section titled Incoming Calling Party Settings.

        The type of device we are configuring will determine the fields available to us. On gateway devices we see National, International, Unknown, and Subscriber. On trunk devices we see Incoming Number.

      10. Select the Calling Search Space that contains the partitions you assigned to the called and calling party transformation patterns and apply it to all applicable fields:

        The previous screenshot is for an SIP trunk. Here we uncheck Use Device Pool CSS as we are not using the device pool for number transformation.

      11. Finally, called party transformations are configured under different sections depending on the type of device.
        On the gateways configuration page, this section is called Call Routing Information - Outbound Calls, and Outbound Calls for trunks.

        Again, we are not using the device pool for number transformation, so we uncheck boxes for both calling and called device pool transformations.

        The calling search space selected for the Called and Calling Party Transformation CSS must contain the partitions used when creating the transformation patterns.

      • How many locations?
      • Multinational?
      • Will short dials (or hot numbers) be used?
      • What about multinational dialing considerations?
      • PT-Line
      • PT-System
      • PT-Global-E164
      • PT-US-DialPlan
      • PT-UK-DialPlan
      • PT-US-SFO-DialPlan
      • Calling party transformation patterns: In the example from the recipe you see a calling party transformation pattern using \+1.!. As we explain in the example, we discard digits PreDot. We do this to normalize the number users see when their phone is ringing and connected, as users in the United States may not be accustomed to seeing +1 before the number.
        Alternatively, say we have an office in San Francisco where users are accustomed to seeing only seven digits for local calls and ten for everything else. We still use the \+1.! PreDot pattern to remove the +1 for calls but we add another pattern to strip the area code off. In this case that pattern would be \+1415.!, stripping PreDot with a partition of PT-SFO-Inbound-ANI, or something similar. By doing this, calls from 415 numbers will show as seven digits on the display when ringing and connected.
      • Called party transformation patterns: Prior to local route groups and called party transformations, you would prepare the dialed number to be sent to the gateway or route list on the route pattern itself. Called party transformation patterns would then be used to prepare the dialed digits to be accepted by the gateway, trunk, or PSTN. In many cases this involves stripping the plus sign and prefixing an access code before sending it out to the gateway or trunk to route the call to the PSTN.
        How we modify the number depends on the type of gateways or trunks we are using. With MGCP gateways, we format the number so that it can be sent across to the PSTN. In some cases this means removing the plus, and appending or removing digits depending on what the carrier expects. For instance, if the carrier expects seven digits for local calls and 1 + 10 digits for long distance calls, we might strip the +1 and area code for local calls and strip only the plus for all other calls.
        For gateways and trunks, access codes are typically configured to inform the gateway or trunk to send the call to the PSTN. Typically these are 9, or 91. In this situation we would strip the necessary digits and prefix the access code appropriate to the call. For example, say our carrier requires seven digits for local and eleven digits for long distance calls; assuming we require an access code of 9 for local and 91 for long distance calls, we might implement the following called party transformations:
        • \+1.!
          Partition: PT-SFO-Outbound-DNIS
          Prefix digits: 91
        • \+1415.!
          Partition: PT-SFO-Outbound-DNIS
          Prefix digits: 9

        Now, when a call is made to +1 415 555 1234, for example, the transformation pattern will remove +1415 and append a 9, sending the call to the gateway or trunk as 95551234 where it would match a dial peer before being sent out to the PSTN. While it is possible to do these transformations on the gateway themselves, managing them in UCM provides a central point for configuration and can help reduce dial plan maintenance.

      • CSS-SFO-Outbound-ANI
        • PT-SFO-Outbound-ANI
        • PT-US-Outbound-ANI
      • CSS-SFO-Outbound-DNIS
        • PT-SFO-Outbound-DNIS
        • PT-US-Outbound-DNIS
      • CSS-SFO-Inbound-ANI
        • PT-SFO-Inbound-ANI
        • PT-US-Inbound-ANI
      • CSS-US-Inbound-ANI
        • PT-US-Inbound-ANI
      • DID ranges of locations for which we are implementing LCR
      • Site codes of locations for which we are implementing LCR
      • Local numbers per location for Tail End Hop Off
      • DID Range for this location: +1 415 555 1000 to 1099
      • Site code for this location: 11
      • Local numbers for this location: 415 XXX XXXX
      • Add a new route list that will contain the route group with the gateway or trunk device local to the location for which we are implementing LCR, as well as the Standard Local Route Group:

        The order here is important. Ensure the local route group is above the Standard Local Route Group in the list.

      • Add a new route pattern to send local calls to our new route list. Key fields to note here are Route Pattern, Route Partition, and Gateway/Route List*:

        Here we have unchecked Provide Outside Dial Tone as it is unused, but feel free to leave it checked.

      • Next add a translation pattern (Call Routing Translation Pattern|, then click on Add New) that is responsible for converting E.164 numbers to their internal extensions.
        • Here the Translation Pattern must match only the DID range for the location. For our recipe the pattern is \+1415555.10XX. For the partition use something that is globally accessible, for example PT-Global-E164:

      • First, create the partitions with the necessary descriptions (Call Routing Class of Control | Partition|):

      • Next, create the calling search spaces (Call Routing Class of Control | Calling Search Space|):

      • Finally, add the translation pattern for the blocking patterns (Call Routing Translation Pattern|):

        It is important to note here that we have used the Partition PT-US-Block-National with a Route Option set to Block this pattern.

      • National/long distance
      • International
      • Premium
      • CSS-US-Line-National
        • PT-US-Block-National
        • PT-US-Block-International
        • PT-US-Block-Premium
      • CSS-US-Line-International
        • PT-US-Block-International
        • PT-US-Block-Premium
      • CSS-US-Line-Premium
        • PT-US-Block-Premium
      • CSS-US-Line-Unrestricted
        • No partitions selected
      • For seven digit dial plans:
        • 91.[2-9]XXXXXXXXX
        • \+1[2-9]XXXXXXXXX
      • 9.011!
      • 9.011!#
      • \+[^1]

        The pattern \+[^1] will match any E.164 number that does not start with a one. For instance, the pattern will match +44 but not +1.

      • 9.1900XXXXXXX
      • \+1900XXXXXXX
      • 124[26][2-9]XXXXXX
      • 126[48][2-9]XXXXXX
      • 1284[2-9]XXXXXX
      • 134[05][2-9]XXXXXX
      • 1441[2-9]XXXXXX
      • 1473[2-9]XXXXXX
      • 1649[2-9]XXXXXX
      • 1664[2-9]XXXXXX
      • 1758[2-9]XXXXXX
      • 1767[2-9]XXXXXX
      • 178[47][2-9]XXXXXX
      • 1809[2-9]XXXXXX
      • 186[89][2-9]XXXXXX
      • 1876[2-9]XXXXXX
      • 1976[2-9]XXXXXX
    2. How it works...

      When an E.164 number is dialed, the system will match it against the route pattern. The purpose of this pattern is to get the call to route to the local gateway or trunk where number normalization occurs, before sending the call out to the local gateway. Call Classification is set to OffNet for this pattern because we expect any calls that match this pattern to be routed out to the PSTN.

      There's more...

      Implementing a successful dial plan requires a few considerations from a technical perspective as well as a user experience standpoint.

      Dial plan considerations and partitions

      Partitions are a crucial part of both the dial plan and the implementation of calling restrictions. Having a well designed partition scheme can make management easier and it isn't difficult to implement. Some things to consider when planning your partition scheme are as follows:

      Common system partitions

      In most systems there are a few basic requirements from a partitioning perspective and at the very least we want to separate user directory numbers from system numbers. To accomplish this we might have the following partitions:

      If this is an E.164 dial plan, we want to separate the partitions from the rest of the system. That is why we also include:

      Partitioning at a national level

      In order to support a basic multinational dial plan we need partitions for dialing rules specific to each nation, for example:

      We would typically use these partitions for any patterns that reach the PSTN, including emergency and information services, as well as regular outbound calls.

      Partitioning at a local level

      If location specific dial rules are required, we might have partitions for each location. For example:

      By doing this at the location level, we can allow for location specific short dials or dialing rules. For example, if we wanted to implement extension 4357 as a short dial to reach the local help desk, we would use a location specific partition such as that shown previously.

      Dial plan considerations and route patterns

      It's important to define how users will access the outside world based on what they are familiar with. In many corporations, dial plan rules exist to allow local calls to be dialed first with a 9 or 91, followed by seven or ten digits; other companies may require nine or ten digits for all calls. We call this seven digit and ten digit dialing, respectively.

      Regardless of which dialing method is used, the setup is the same and thanks to E.164 you only need one route pattern to support all locations.

      Seven digit dialing

      To implement seven digit dialing we will add another route pattern as explained earlier, which is the 9.[2-9]XXXXXX pattern:

      Unlike the earlier example, we want to strip the 9 off and append a plus sign. This is necessary so the call will match the \+.! pattern before it can be routed to the local gateway or trunk:

      In situations where you are not using an E.164 dial plan but want to implement seven digit dialing, you need to only put the pattern in a location specific partition and point the Gateway/Route List* to the appropriate route list or gateway. In this situation, you would not prefix the plus sign.

      Don't forget to include a pattern for non-local calls!

      Ten digit dialing

      To configure ten digit dialing, follow the previous steps and instead use a pattern of 9.[2-9]XXXXXXXXX.

Further resources related to this subject:

Implementing E.164 called and calling party transformations

By using cluster-wide E.164 route patterns, number localization is no longer done on the route pattern. Instead, localization must occur prior to sending the call to the gateway or trunk device. This is accomplished with called and calling party transformations.

Getting ready

In this recipe we assume you already have the necessary partitions and calling search spaces for called and calling party transformations created. Refer to the There's more... section for an example partition and calling search space scheme.

How to do it...

To implement called and calling party transformation on either a gateway or trunk device, perform the following:

How it works...

When a call enters through a gateway or trunk device, the calling and called party transformations are applied depending on transformation patterns available to the calling search space used:

There's more...

Calling and called party transformations are primarily used to localize the ANI displayed for calls entering the system and localizing calls for the gateway before sending it out to the PSTN.

Partitions and calling search spaces for called and calling transformation patterns

In this recipe you will see a few partitions and calling search spaces that may not immediately make sense. In order to accomplish these transformations on a per location basis we have six partitions and three calling search spaces.

The partitions and calling search spaces we use are:

  • CSS-SFO-Outbound-ANI
    • PT-SFO-Outbound-ANI
    • PT-US-Outbound-ANI
  • CSS-SFO-Outbound-DNIS
    • PT-SFO-Outbound-DNIS
    • PT-US-Outbound-DNIS
  • CSS-SFO-Inbound-ANI
    • PT-SFO-Inbound-ANI
    • PT-US-Inbound-ANI

If you have no need to localize the ANI on a per location basis you might have a single calling search space and partition instead:

These are only some suggestions; make sure you apply the appropriate calling search spaces and partitions for your cluster.

Implementing least cost call routing using Tail End Hop Off

Least Cost Routing (LCR) is not strictly limited to calls destined for the PSTN, instead LCR can be used to prevent OnNet calls from being routed OffNet. In this recipe we will cover both uses.

Getting ready

Before we begin this recipe it is helpful to have some information:

In this recipe we will implement LCR and Tail End Hop Off for calls destined to an office in San Francisco. We will assume the following:

How to do it...

To implement Least Cost Routing for a location, we need to perform the following:

For our pattern, it is necessary to set Discard Digits to PreDot and Prefix Digits to the site code—12 in this recipe.

How it works...

Least cost routing with Tail End Hop off is accomplished by sending calls to locations where the call would cost the least. In addition to Tail End Hop Off, we can accomplish least cost routing by recognizing when a user dials the DID to another user on the same cluster by converting the E.164 number to the local extension and routing over the IP network.

There's more...

Once more we see the benefits of the logical nature of local route groups. By having localization settings at the gateway level, we don't have to worry about formatting and allow the local gateway to normalize the call as required by the PSTN. In the event that the call cannot be made through the gateway or trunk device at the local site, the call will fall back to the gateway or trunk device local to the originating caller.

Do remember that Tail End Hop Off is not legal in all countries. Check with local regulations before implementing it.

Implementing calling restrictions with line blocking partitions and calling search spaces

In this recipe we will be implementing class of service calling restrictions using partitions and calling search spaces, as well as exploring their design considerations.

Getting ready

For this recipe, preparation is key. We will need to determine the partitions, calling search spaces, and patterns to be blocked that will be appropriate to the environment. There is more information on this in the There's more... section of this recipe.

How to do it...

To implement calling restrictions, perform the following:

Repeat this process for all the necessary blocking translation patterns.

How it works...

When a calling search space used for calling restrictions is applied to the directory number of a device, those settings override the calling search space patterns specified on the device, denying calls or access to certain numbers.

There's more...

While each environment is unique, there are some design considerations that apply to most. Calling restrictions is one of them.

Determining classes of restriction

In general, external calls fall in to one of these three classes:

While the patterns for each category may vary according to region and requirements, these set up the foundation for our calling search spaces. Sometimes we find ourselves in need of an unrestricted calling search space. While you may choose to leave this to <none> on the directory numbers, I prefer to use an empty calling search space for clarity.

An example partition and calling search space arrangement for a US-based solution would be:

This setup is not overly complex and can be easily used to expand calling restrictions to suit most environments.

Patterns required for call restrictions

There are two ways in which we can implement translation patterns for call restrictions, neither of which are mutually exclusive.

Design considerations for preventing call restriction bypass

With careful consideration it is possible to bypass calling restrictions, though this is most typical for environments using E.164 call routing. In these environments it is typical for engineers accustomed to the traditional way of blocking to block digits as the user dials them. For example, if a user dials a premium number such as a 900 number, they typically do so with a 9 or 91 first, followed by the number, before hearing a message informing the user that the call was denied.

When using E.164 for call routing, this is not enough. In this type of environment there is usually a pattern for national calls, for example, 9.1[2-9]XXXXXXXXX. It is common to strip PreDot and prefix the plus sign for final routing. While this is the most common form of dialing, it is not the only way to dial.

On second generation and later phones, which Cisco calls Type-B phones, it is possible to dial a properly formatted E.164 number directly from the keypad, such as +19005551234, and have it routed. Because of this capability, it is important to add blocking patterns for the E.164 compatible number.

Blocking in traditional environments

In environments that do not use E.164 call routing, calling restrictions are enforced primarily with route patterns set to Block this pattern, similar in setup to the translation pattern in this recipe's How to do it… section. Translation patterns may also be used for enforcing call restrictions.

Blocking in E.164 environments

In this type of environment, translation patterns are typically used to enforce call restrictions, though as with the traditional method, we may also use route patterns.

As mentioned in the Design considerations for preventing call restriction bypass section, it is possible to bypass traditional calling restrictions on Type-B phones by dialing the E.164 number directly. This is possible because of the added layer of routing associated with E.164 call routing.

To mitigate this and enforce call restrictions for these types of devices, we need to match the final number, which is in E.164 format. For example, if we want to block calls to 900 numbers we would implement the translation pattern \+1900XXXXXXX with the Route Option set to Block this pattern and a Partition of PT-US-Block-Premium.

Partitions used in call restrictions

In the previous example we have three partitions and four calling search spaces that enforce call restrictions at various levels: national, international, and premium. We include an empty calling search space to allow for unrestricted calls, called CSS-US-Line-Unrestricted for the sake of clarity, though in such cases a calling search space of <none> will suffice.


Represented by PT-US-Block-National, this class is used to prevent long distance calls or any calls on a national level that need to be blocked, such as fraud numbers. It is typically represented by the following patterns:


Represented by PT-US-Block-International, this class is used to prevent international calls. It is typically represented by the following patterns:


Represented by PT-US-Block-Premium, this class prevents calls to premium numbers. It is typically represented by the following patterns:

Mitigating fraud

In some cases it may be a requirement to proactively prevent users from dialing commonly known fraud numbers. Typically these are standard looking numbers that when called charge per minute connected. While this list is by no means complete, it is a good starting point for common fraud numbers in the US.


In this article, we took a look at recipes on E.164 globalization, call routing, and call restrictions.

Further resources on this subject:

You've been reading an excerpt of:

Cisco Unified Communications Manager 8: Expert Administration Cookbook

Explore Title