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.
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.
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:
These changes will not take effect until you reset the devices in the device pool.
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:
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.
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.
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.
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.
The order here is important. Ensure the local route group is above the Standard Local Route Group in the list.
Here we have unchecked Provide Outside Dial Tone as it is unused, but feel free to leave it checked.
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.
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.
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:
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:
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.
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.
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.
Don’t forget to include a pattern for non-local calls!
To configure ten digit dialing, follow the previous steps and instead use a pattern of 9.[2-9]XXXXXXXXX.
I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…
Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…
Once we learn how to deploy an Ubuntu server, how to manage users, and how…
Key-takeaways: Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…
While developing a web application, or setting dynamic pages and meta tags we need to deal with…
Software architecture is one of the most discussed topics in the software industry today, and…