Often the features of a product can cause headaches for those responsible for maintaining the product. It seems the more advanced the features, the more complex the configurations. This is especially true with products that offer the administrator greater flexibility and control. Cisco Communication Manger is not free of this issue. It is a very powerful system that offers great flexibility.
One of the issues that administrators run into as their environment grows is within the dial plan. If you administer a Communications Manager system, you already know that the dial plan is one of the most important and unforgiving components of the system. If you configure it correctly, things will run smoothly and users will be happy. If not, you will be sure to hear about it and your life will not be a peaceful one until the issue is corrected.
One thing that tends to make dial plans become complicated is a multi-site deployment. For example, let’s take an environment that has a location in Detroit, Chicago, and San Jose. All three locations are part of a single cluster. All three locations use 11 digit dialing and use a 9 for an outside line. This means that you need to configure a pattern that looks like 9.1[2-9]XX[2-9]XXXXXX. Since users from all three locations will need to use this pattern, you need to make sure all have access to it. The problem is that when people in Chicago dial the number, you want the call to go out the Chicago PSTN gateway, but when users in Detroit dial the number, you want it to go out the Detroit PSTN gateway. The way this is normally accomplished is to configure a pattern for each location and place it in a partition that only users of the desired location have access to. In this example, this triples the amount of patterns you need for 11 digit dialing. Imagine if you had ten or twenty locations.
Well, there is good news. As of Communications Manager 7.0, a new component called, “Local Route Groups” has been added. The concept is quite simple. A Route Group can be assigned to device pool. Devices pools can be associated with a physical location (this is done by associating them with a subnet). You can then configure a pattern to point to a Route List that points to what is referred to as “Standard Local Route Group.” When configured this way, the call will be routed to the Local Route Group in the Device Pool of the device that the call originated from.
This allows you to configure one pattern for all users, and the call will be routed based on the device pool the device is associated with. In the next article I will illustrate how this works with the example above as well as how to configure it.