In chapter 1 we dive straight into the dial plan with recipes on E.164 globalization, call routing, and call restrictions. We will cover:
Implementing local route groups with device pools for E.164 call routing
Implementing E.164 route patterns and partitions
Implementing E.164 called and calling party transformations
Implementing least cost call routing using Tail End Hop Off
Implementing call restrictions with line blocking patterns and calling search spaces
Implementing short dial numbers
Implementing time-of-day call routing
Implementing Forced Authorization Codes
Implementing Client Matter Codes
In this chapter, we will focus on implementing local route groups, device pools, route patterns, and various other call routing technologies with a specific focus on building an E.164 compatible dial plan. All the recipes in this chapter require administrator access to the Unified Communications Manager (UCM). It is strongly recommended you get comfortable performing these recipes in a lab environment before implementing them into production.
Even if you're not interested in E.164, the recipes in this chapter 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.
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.
To implement a local route group for use with a device pool, perform the following:
Add a new route list that will serve as the link to the local route groups (Call Routing | Route/Hunt | Route List).
Click on Add New to add a new route list.
Type in a name and select a Call Manager Group in the drop-down with which the route list will be associated:
Click on Save.
Once the page reloads, click on Add Route Group and a new page will open.
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:
Finally, click on Save to save the Route List.
Add a new route group containing the gateway or trunk (Call Routing | Route/Hunt | Route Group).
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:
Click on Save. The device will show up under Route Group Members.
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:
Click on Save.
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.
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.
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.
To create the route pattern to support an E.164 dial plan, we will do the following:
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.
Enter in a partition name and a description in the text box and then click on Save.
Add the E.164 Route Pattern and assign the Route List to it (Call Routing | Route/Hunt | Route Pattern).
Click on Add New.
Enter
\+.!for the Route Pattern and select the route partition previously created in the Route Partition drop-down:
From the Gateway/Route List* drop-down, select the route list containing the Standard Local Route Group.
Ensure that the Call Classification is OffNet and the Route Option is set to Route this pattern.
Click on Save.
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.
Implementing a successful dial plan requires a few considerations from a technical perspective as well as a user experience standpoint.
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:
How many locations?
Multinational?
Will short dials (or hot numbers) be used?
What about multinational dialing considerations?
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:
PT-Line
PT-System
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:
PT-Global-E164
In order to support a basic multinational dial plan we need partitions for dialing rules specific to each nation, for example:
PT-US-DialPlan
PT-UK-DialPlan
We would typically use these partitions for any patterns that reach the PSTN, including emergency and information services, as well as regular outbound calls.
If location specific dial rules are required, we might have partitions for each location. For example:
PT-US-SFO-DialPlan
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.
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.
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.
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.
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.
To implement called and calling party transformation on either a gateway or trunk device, perform the following:
Add the calling party transformation pattern (Call Routing | Transformation | Transformation Pattern | Calling Party Transformation Pattern).
Add the transformation pattern appropriate to your environment and location:
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.
Add the called party transformation pattern (Call Routing | Transformation | Transformation Pattern | Called Party Transformation Pattern).
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.
Navigate to the configuration page for the port or device.
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:
This is configured at the device level for trunks and gateways.
Next we apply the transformations to our trunks or gateways. Calling party transformations are configured under the section titled Incoming Calling Party Settings.
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.
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.
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:
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.
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.
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:
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.
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.
Before we begin this recipe it is helpful to have some information:
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
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:
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
To implement Least Cost Routing for a location, we need to perform the following:
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:
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*:
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:
For our pattern, it is necessary to set Discard Digits to PreDot and Prefix Digits to the site code—12 in this recipe.
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.
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.
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.
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.
To implement calling restrictions, perform the following:
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.
Repeat this process for all the necessary blocking translation patterns.
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.
While each environment is unique, there are some design considerations that apply to most. Calling restrictions is one of them.
In general, external calls fall in to one of these three classes:
National/long distance
International
Premium
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:
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
This setup is not overly complex and can be easily used to expand calling restrictions to suit most environments.
There are two ways in which we can implement translation patterns for call restrictions, neither of which are mutually exclusive.
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.
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.
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.
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:
For seven digit dial plans
91.[2-9]XXXXXXXXX
\+1[2-9]XXXXXXXXX
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.
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
In this recipe we will set up basic short dials on a per location basis.
We will need a location-specific partition for the location for which we are implementing short dials. In this recipe we use PT-SFO-DialPlan.
To implement short dials for a location, perform the following:
Add the short dials partition to the calling search space of the device for the relevant location (Call Routing | Class of Control | Calling Search Space):
Create and save a translation pattern for the short dial in an appropriate partition (Call Routing | Translation Pattern):
Fill in Translation Pattern and Partition as appropriate. Here we use
4357and PT-SFO-DialPlan, respectively.Calling Search Space is of special note. Here, we apply a device calling search space appropriate to the location, CSS-SFO-Device.
Finally, under the Called Party Transformations section, we change Called Party Transform Mask to the final number,
2222in this recipe.
When a call matches the translation pattern, the called number is translated as per our rule to 2222, and the call continues to be routed normally.
It is important to remember that the number we are translating must be accessible from the translation pattern.
How call routing works with short dials
When a user enters a short dial number, it is modified by the appropriate translation pattern and then routed normally. However, in the case of short dials, calling search spaces and, to a lesser extent, partitions play a vital role in routing the call properly.
Before a number is modified by a translation pattern and routed, the pattern will first attempt to match a pattern or number in the same partition as the translation pattern. If no match is found the applied calling search space will be used to search partitions for a match. It is because of this behavior that it is important for the short dial translation pattern to have access to the same partitions as the device, and that is why we choose to use a device calling search space appropriate to the location.
Time-of-day routing has various uses in the typical production environment. In this recipe we will focus on implementing time-of-day routing on a location's main number.
For this recipe we need to know the hours and/or days we are considered open and closed, and the appropriate action to take. In this recipe we apply a standard Monday through Friday work week, opening at 8 a.m. and closing at 5 p.m.
This recipe assumes the time-of-day partition for the location is already created. In this recipe, we will use PT-SFO-TimeOfDay.
Add the time-of-day partition to your device and gateway calling search spaces (Call Routing | Class of Control | Calling Search Space):
Create a new time period and configure it with the appropriate settings (Call Routing | Class of Control | Time Period):
Click on Add New.
Click on Save and repeat this process for each time period as appropriate.
Create a new time schedule containing the previously created time period(s):
Ensure only the time periods we want are under Selected Time Periods.
Finally, apply the previously created time schedule to the time-of-day partition (Call Routing | Class of Control | Partition).
Click on Add New.
Select the appropriate time schedule from the Time Schedule drop-down:
For Time Zone, select the time zone from the drop-down that is appropriate to the location.
Click on Save.
By applying a time schedule to the partition, we are setting the foundation for time-of-day call routing. Now any patterns in the time-of-day partition will only be matched if they occur during the time period(s) we've specified.
Time-of-day routing is a valuable feature, though it lacks flexibility.
As the complexity of time-of-day routing grows, so do the configuration requirements. CUCM lacks any means to specify gaps during time periods. For example, let's assume users take lunch from 12 p.m. to 1 p.m. with a typical 8 a.m. to 5 p.m. schedule.
If we wanted to use CUCM's time-of-day routing features, it would require the creation of two time periods for that office, one beginning at 8 a.m. and ending at noon Monday to Friday, the other beginning at 1 p.m. and ending at 5 p.m. Monday to Friday.
This can become extremely tedious when configuring time-of-day routing for offices that close at different hours depending on the day. Drawing on our previous example, say on Wednesday the office closes early at 4 p.m. This now requires six time periods as follows:
Monday to Tuesday, starting at 8:00 and ending at 12:00
Monday to Tuesday, starting at 13:00 and ending at 17:00
Thursday to Friday, starting at 08:00 and ending at 12:00
Thursday to Friday, starting at 13:00 and ending at 17:00
Wednesday to Wednesday, starting at 08:00 and ending at 12:00
Wednesday to Wednesday, starting at 13:00 and ending at 16:00
As the time-of-day routing requirements become more complex, so does the implementation. In some cases it may be more appropriate to use third party software to handle complex time-of-day routing, such as Cisco Unified Contact Center Express, Unity, and Unity Connections.
Implementing holidays with time-of-day routing is generally not a recommended use of the provided time-of-day routing features.
If we are limited to CUCM's time-of-day routing features and must implement specific routing for holidays, we can do so. To configure time-of-day routing so that a location is 'closed' during holidays, perform the following:
Add each holiday as a time period, select No Office Hours for these and select the appropriate Repeat Every option.
Add the previously created holiday time periods to a time schedule, SFO-Holidays for this example.
Add a new partition; we'll call it PT-SFO-TimeOfDay-Holiday.
Assign the holiday time schedule to the newly created partition.
Assign the partition to the appropriate calling search spaces.
From here add a translation pattern using the previously created holiday partition as the partition and an appropriate calling search.
In general this is used for specific numbers such as the main call in number for a location.
Forced Authorization Codes (FAC) are another method of call restriction, requiring a user to enter in a code prior to the call being connected. However, the primary use of Forced Authorization Codes is call accounting and billing.
We need to know which patterns will be requiring Forced Authorization Codes, and the codes themselves.
To implement Forced Authorization Codes, perform the following:
Add a new Forced Authorization Code (Call Routing | Forced Authorization Codes).
Click on Add New.
For this recipe we will name it
John Smith - Internationalwith an Authorization Code of1234and the default Authorization Level of0.Click on Save and repeat for any additional Forced Authorization Codes.
Find the route pattern (Call Routing | Route/Hunt | Route Pattern).
Check Require Forced Authorization Code and then click on Save:
When a user attempts to use a route pattern that requires Forced Authorization Codes, he will hear a tone prior to entering the code. Once the correct code is entered, the call is routed and that call is specifically marked in call records with the Forced Authorization Code used.
Forced Authorization Codes are primarily for billing and accounting purposes.
Depending on requirements, we may have a situation where it is necessary to allow the management unfettered access to international calls, while requiring other employees to use Forced Authorization Codes.
If we require Forced Authorization Codes for segments of users but not for all, we need to create one partition for each group that requires their use. In the previous example, we needed only one partition, which we will call PT-FAC.
For each FAC partition created, that same partition will need to exist in a calling search space. Those using Forced Authorization Codes will need to be assigned the appropriate calling search space.
How we implement Forced Authorization Codes depends heavily on the environment in which they are being deployed.
In environments with traditional call routing, using route patterns pointing to specific gateways, the route patterns' pattern will match the digits dialed by the user.
In environments where E.164 call routing is implemented because translation patterns are used to convert the dialed digits into an E.164 compatible format, the pattern we use must match this format and not the dialed digits. In the case of enforcing FAC for international calls, we would use the pattern \+[^1]! with an appropriate FAC partition.
We use this pattern because we assume there is a translation pattern matching 9011.!. Converting the number into +011 will match any number E.164 that doesn't begin with the US country code of 1. This is necessary, as Forced Authorization Codes do not apply to translation patterns.
Client Matter Codes are used solely for call accounting and billing purposes and are typically employed with Forced Authorization Codes.
When a user matches a route pattern with Client Matter Codes (CMC), a tone is heard and the system collects the CMC. Once collected, the Client Matter Code is recorded in CDR records along with the call.
Client Matter Codes are configured much in the same way as Forced Authorization Codes. As such, they have some of the same design considerations.
As with Forced Authorization Codes, if only a subset of users will be required to use Client Matter Codes, a new partition and route pattern will have to be created and configured appropriately.
With an E.164 dial plan, only one additional pattern may be required for each route pattern to which the Client Matter Codes will be applied. This pattern should match the E.164 compatible number and not the digits dialed by the user.
In a more traditional environment, a route pattern for each pattern per location may be required.
For more information on Client Matter Codes, see the CDR Analysis and Reporting Administration Guide (http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/8_0_2/car/CAR.html).
