Further resources related to this subject:

Introduction

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

   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.