|
|
This chapter discusses the architecture and operation of the Cisco CallManager dial plan and provides design recommendations. A dial plan is essentially a telephony system interface that allows users to reach each other easily by dialing strings that can be routed to diverse locations by the system.
This chapter contains the following major sections:
This section gives an explanation of the dial plan architecture and functional components. Since a dial plan can be configured in many ways, recommended configurations are also described.
Dial plan requirements can include support for abbreviated dialing, such as four- or five-digit extensions, as well as redundant paths that are transparent to the calling party. The dial plan in Cisco CallManager Release 3.0 is enhanced to allow for greater scalability, flexibility, and ease of use, while tighter integration of Cisco CallManager and Cisco IOS gateways allows for larger network deployments.
The Cisco CallManager dial plan architecture is set up to handle two general types of calls.
Figure 5-1 shows a network designed to handle these two types of calls. With a well-designed dial plan, voice calls preferentially use the IP WAN and are routed to the PSTN only if the IP WAN is down or unavailable. This routing is transparent to the user.
The dial plan for internal calls to IP phones registered with a Cisco CallManager cluster is fairly simple. On initial configuration, an IP phone is assigned a directory number (DN), which it maintains wherever it resides. Whenever the IP phone registers with the Cisco CallManager cluster, it effectively updates the Cisco CallManager cluster dynamically with its new IP address while maintaining its same directory number. The internal dial length (number of digits dialed) for internal calls is configurable.
 |
Note IP phones are not the only devices that can be accessed in this manner. Other devices that register with Cisco CallManager and maintain a directory number can include Cisco IP SoftPhones, analog phones, and fax machines attached to gateways that use MGCP or the Skinny Gateway Protocol. |
Configuring Cisco CallManager to handle external calls requires the use of a route pattern. In most cases the route pattern is used for directing calls out to a PSTN gateway, but it is also used in the case of an IP WAN call to a remote Cisco CallManager. The Cisco CallManager Release 3.0 dial plan architecture is a three-tiered decision tree that allows multiple routes for a given dialed number, as well as digit manipulation based on the network requirements. Digit manipulation is the task of adding or subtracting digits from the original dialed number to accommodate user dialing habits or gateway needs. You can also configure capabilities such as trunk groups for gateway redundancy and a form of least-cost routing.
As an example of alternate route selection, the path to a given dialed number typically takes the IP WAN as the first choice and the PSTN as the second choice if the IP WAN is down or has insufficient resources. The dial plan criteria for using an alternate route could be based on an indication by the call admission control mechanism that insufficient trunks are available on a gateway, meaning that the IP WAN cannot accept the call.
Figure 5-2 illustrates the Cisco CallManager Release 3.0 dial plan architecture that supports alternate route selection. The elements in this architecture are described in the subsections that follow.
The route pattern identifies a dialed number (E.164 numbers in North America) and uses the underlying route list and route group configurations to determine how to route the call. A route pattern can be entered as a specific number or, more commonly, a number range. Using a route pattern to represent a number range minimizes the number of entries required.
When a route pattern matches a dialed number, the call is handed to the route list associated with the route pattern. Prior to handing the call to the route list, digit manipulation can occur if digits need to be added to or removed from the matched route pattern. The route list then decides which downstream route groups (trunk groups) should receive the call based on the ordered priority.
|
Note The digit manipulation occurs in the route pattern for outbound calls only, before being sent to the route list plus route groups. Individual downstream route groups can have unique digit manipulations for the same route pattern. This is extremely useful where different routes to a given dialed number might require different manipulations. For example, users might be required to dial seven digits to reach a remote location that has a four-digit internal dial plan. Across the IP WAN the first three digits would have to be removed so that the last four digits could be delivered to the remote Cisco CallManager in its native internal dial string length. If the IP WAN were down or could not accept additional voice calls, the dialed seven digits would have to be prepended with the area code to reach the called party through the PSTN. A route pattern is associated with only one route list. |
The term route point from previous releases of Cisco CallManager has been replaced by route list in Cisco CallManager Release 3.0, though the function remains much the same. A route list defines the way a call is routed. Route lists are configured to point to one or more route groups, which effectively serve the purpose of trunk groups. The route list sends a given call to a route group in a configured order of preference. For example, the primary route group might offer a lower cost for calls, while the secondary route groups would be used only if the primary is unavailable due to an all-trunks-busy condition or insufficient IP WAN resources.
Route groups control specific devices such as gateways. Gateways can be based on the Skinny Gateway Protocol, MGCP, or H.323. Endpoints such as NetMeeting clients or remote Cisco CallManagers across the IP WAN are configured as H.323 gateways. The route group points to one or more devices and can select the devices for call routing based on preference. The route group can direct all calls to the primary device and then use the secondary devices when the primary is unavailable. This serves effectively as a trunk group.
One or more route lists can point to the same route group. All devices in a given route group have the same characteristics, such as path and digit manipulation. Route groups have the ability to perform digit manipulation and can override route pattern digit manipulation (see the "Route Pattern" section ).
All IP endpoints are viewed as devices, but only certain devices can be entered in a route group. Figure 5-3 illustrates the types of devices that can be in route groups.
The following notes apply to the devices in Figure 5-3:
An important feature of the route pattern dial structure is that it is typically used when IP phone calls are destined to go to gateways or remote Cisco CallManagers using H.323. In these cases, alternate routes can be taken in the event the primary path to a destination is not available. This is the scheme described in "Multi-Site WAN with Distributed Call Processing," where all inter-site calls take the IP WAN as the primary path and the PSTN as the secondary path.
Calls between IP phones that reside on the same Cisco CallManager or Cisco CallManager cluster do not use the route pattern dial structure and, therefore, cannot use alternate routes if connectivity is down between them. If IP connectivity is lost between two IP phones, it is probably because one of the phones has lost connectivity to its Cisco CallManager. This can happen, for example, when using multi-site WAN deployments with centralized call processing. In such cases there is no alternate routing between sites.
Cisco CallManager supports digit translation. This is the ability to translate the called and calling numbers into other numbers, including changing the number of digits. Digital translation is applicable for internal as well as external calls, inbound or outbound.
A common application of a translation table is to direct unassigned direct inward dialing (DID) numbers to an attendant when such numbers are dialed. For example, assume you have a DID range of 1000 to 1999 and want all calls to unassigned DID numbers to go to an attendant at extension 1111. You can configure a translation table of 1XXX that points to a translation mask of 1111, as follows:
| Translation Table | Translation Mask |
|---|---|
1XXX | 1111 |
In this example, Cisco CallManager performs a longest match lookup using wildcards. If there is an IP phone with a matching directory number in the 1000-1999 range, Cisco CallManager sends the call to that phone. If there is no matching IP phone number in the 1000-1999 range, then there is a match on the 1XXX translation table and the call is sent to extension 1111.
Digit translation can also be performed within the route pattern structure using called/calling party transformation, which performs the same digit translation functions for both incoming and outgoing calls. This means that within a route pattern, three types of digit manipulation can be performed on a called number:
In the following example, a route pattern of 2.XXXX is defined. The calling number is 1000, but the call needs to go to a PBX with a called party number of 444XXXX and a calling party number of 919392XXXX. The Cisco CallManager route pattern would be treated as follows:
Step 2 Discard the access code (2), leaving just XXXX.
Step 3 Prefix the digits 444.
An alternative way to accomplish steps 2 and 3 would be to use a called party transformation mask of 444XXXX.
It is important to keep in mind that the calling party transformation mask applies only to the calling numbers, while the other masks apply to the called numbers. Cisco CallManager first discards digits, then applies the transformation mask, and finally prefixes digits.
You should try to make your dial plan as simple as possible and to minimize the number of entries. The most efficient way to achieve this is to configure specific dial plans only for locations on the network (IP WAN) and to use the local PSTN gateway access code, such as 9 or 0 (zero), for locations that must be reached over the PSTN, as well as for IP WAN calls if the IP WAN is down or has insufficient resources. These are called on-net and off-net route patterns, respectively.
In a multi-site IP WAN with distributed call processing, an abbreviation of the full E.164 address is typically used for ease of dialing. For example, where an on-net location has a number range of (408) 526-1000 through 1999, there may be only a single route pattern with an entry of 61XXX. This simplifies user dialing and requires only one route pattern entry where the Xs serve as wildcards.
To present the remote Cisco CallManager with the appropriate number of digits for the internal dial plan, the Cisco CallManager route pattern can also strip or prepend digits to the dialed number. In fact, the number of digits presented to a remote Cisco CallManager for all calls across the IP WAN must match the dialed digit length that the remote site uses for internal calls. The remote Cisco CallManager simply looks at the digits and routes the call. There is no digit manipulation for incoming calls.
If the IP WAN resources are insufficient in this environment and the call has to be sent over PSTN, the route group for the PSTN gateway must insert the area code and three-digit exchange. In earlier releases of Cisco CallManager, only one digit manipulation table could be used for any given route pattern. Therefore, only Cisco IOS gateways could be used because they could insert the area code and three-digit exchange. This administrative burden has been removed in Cisco CallManager Release 3.0, which now has the ability to perform unique digit manipulations on a per-route-group basis. This allows for a single point of dial plan administration per site and for use of both Cisco IOS gateways and gateways based on the Skinny Gateway Protocol.
Figure 5-4 depicts on-net calls across the IP WAN with the PSTN as a backup, where the digit manipulation required is different for each path.
Calls out the PSTN typically require only a single route pattern. This is the PSTN trunk access code, which is usually a 9 or a 0 (zero). In North America, configuring the route pattern 9.@ allows users to make outside calls by dialing a 9 (most commonly used) and the 7-digit or 1+10-digit phone number. The concept of local area codes, which was used in earlier releases of Cisco CallManager, does not exist in Cisco CallManager Release 3.0. Local area codes are used in some heavily populated areas but do not require dialing a 1. When a local area code is required, the route pattern should be configured for the specific area code without a 1. This allows Cisco CallManager to differentiate between a local seven-digit number and a local area code to determine when the dialing is complete. Otherwise Cisco CallManager waits 10 seconds without detecting any digits before assuming the dialing is complete.
Local PSTN gateway dial plan configuration is fairly simple. The gateways based on MGCP and the Skinny Gateway Protocol have all of their dial plan information configured in Cisco CallManager, while an H.323-based Cisco IOS gateway typically requires only a minimal number of dial peers. These dial peers are used by the gateway to direct all calls from Cisco CallManager to the PSTN. For an example of this type of dial plan, see the configuration in Figure 5-8.
Outside of North America, dial strings often differ in length from one country to another. Multiple-length dial plans present a challenge in that Cisco CallManager does not know when dialing is complete unless you have a specific route pattern. Cisco CallManager by default waits 10 seconds without receiving any digits before assuming dialing is complete. Below are two common options for configuring a route pattern for PSTN access outside of North America. The local PSTN access code, 0 (zero), is commonly used.
Option 1: Route Pattern = 0.!
0. | Represents the local PSTN access code. |
|---|---|
! | Stands for any digit and any number of digits. This also means that Cisco CallManager must wait 10 seconds (the default) without receiving any digits before it assumes the dialing is complete and sends the call. |
By reducing the idle digit wait timer (to 3 seconds, for example) in the Cisco CallManager service parameters, a call can be sent without having to wait the full 10 seconds. The risk of this practice, however, is that Cisco CallManager can prematurely determine that the dialing is finished if the user simply pauses in the midst of dialing.
Option 2: Route Pattern = 0.!#
0. | Represents the local PSTN access code. |
|---|---|
! | Stands for any digit and any number of digits. This also means that Cisco CallManager must wait 10 seconds (the default) without receiving any digits before it assumes the dialing is complete and sends the call. |
# | Indicates that, when a user presses the # (pound) key, Cisco CallManager should assume dialing is complete and immediately send the call. |
In this option, users are instructed to press the # key to terminate the dial string and immediately place the call. This requires some user education and changes to existing customer dialing habits. However, this is similar in nature to pressing the send button on a cell phone.
A new feature in Cisco CallManager Release 3.0 is the ability to impose calling restrictions on a per-phone basis and to create closed dial plan groups on the same Cisco CallManager. Users on the same Cisco CallManager can be grouped into communities of interest that have the same calling restrictions and dial plans. Different communities of interest can operate independently but still share the same gateways as well as have overlapping dial plans. These new capabilities, which are of particular interest in a multi-site IP WAN with centralized call processing, are achieved with the use of partitions and calling search spaces.
A partition is a group of devices with similar reachability characteristics. Devices you can place in partitions are IP phones, directory numbers, and route patterns. Each partition name should be chosen to have some meaningful correlation to the group of users it represents. For example, for users located in Building D in San Jose, you could create a partition called SJ-D.
A calling search space is an ordered list of partitions that a user can search before being allowed to place a call. Calling search spaces are assigned to devices that can initiate calls. These include IP phones, Cisco SoftPhones, and gateways.
Dialing restrictions are simple to invoke because users can dial only the partitions in the calling search space to which they are assigned. Dialing a directory number outside an allowed partition causes the caller to receive a busy signal.
An analogy can be drawn between partitions and calling search spaces and routers with access control lists (ACLs). Think of a partition as an IP subnet where you place users. A calling search space is analogous to an inbound ACL that dictates which subnet you can reach.
Figure 5-5 illustrates the analogy of partitions and calling search spaces to ACLs.
Figure 5-6 is a simple example of how partitions and calling search spaces can be used to provide dialing restrictions.
In Figure 5-6, staff employees have unrestricted dialing, whereas the lobby phones have the ability to dial people within the local site only. All IP phones are placed in the SJ-Users partition, and the route pattern 9 associated with the PSTN is placed in the SJ-PSTN partition. Two calling search spaces are created that denote two different dialing characteristics. A calling search space called Unrestricted is created that contains both SJ-Users and SJ-PSTN partitions. A second calling search space called SJ-Only is created and contains only the SJ-Users. San Jose staff IP phones are assigned the Unrestricted calling search space, which means they are allowed to dial anywhere. The lobby phones are assigned the SJ-Only calling search space, which means they can dial only local phones within the local site.
The partition and calling search space assignments used to configure the preceding example are shown in Table 5-1 and Table 5-2. Two partitions define the reachability characteristics for the given site, one for internal local site users and one for external calls. Devices and route patterns are placed in these partitions.
| Partition Name | Designated Devices Assigned to Partition |
SJ-Users | All IP phones within San Jose |
SJ-External | All externally destined route patterns (local PSTN) |
| Calling Party Search Space | Partitions | Assigned To |
Unrestricted | SJ-Users | Devices that can make internal and external calls |
SJ-Only | SJ-Users | Devices that can make internal calls only |
This example represents perhaps the simplest configuration for the requirements of multi-site WAN local call processing. A more ambitious dial plan could include the following considerations:
Partitions and calling search spaces permit independent dial ranges on a partition basis. This means that extensions and access codes within different partitions can have overlapping numbers and yet function independently. The most common application of this is in a centralized call processing system where all sites and users share the same Cisco CallManager, yet each site can dial a 9 for local PSTN access. This is a new capability in Cisco CallManager Release 3.0. In prior releases each remote site had to have its unique PSTN access code.
The following conditions apply with regard to overlapping users and extensions at different sites with the centralized call processing system:
The complexity of a dial plan can vary, depending on the number of paths over which a call could be routed. This section describes some typical dial plan scenarios.
In a campus environment with no multi-site IP WAN connectivity, the most common dial plan considerations are concerned with providing PSTN access.
In Figure 5-7, the following dialing conventions apply:
This example also provides for gateway redundancy in the event of a gateway or trunk failure to the PSTN. The PSTN gateways are Cisco IOS gateways using H.323.
Notice that the dial plan configuration in this model requires only a single route pattern. The 9.@ signifies that 9 is the local PSTN access code, and the @ signifies the North American dialing plan in this case. The route pattern 9.@ for North American dialing includes 911 services. The route group is configured to discard the access code by digit manipulation. This strips the 9 off the string sent to the local PSTN gateway, which is a Cisco IOS gateway in this case. Cisco CallManager denotes any digits to the left of the dot (.) as the access code, so that when the discard access code feature is selected, it will strip off any digits to the left of the dot.
|
Note In the example route group, two gateways are listed in order of preference. This is how gateway redundancy is achieved in the event of an all-trunks-busy condition or a gateway failure. |
Figure 5-8 shows the configuration required in each Cisco IOS PSTN gateway. The goal is to configure the Cisco IOS H.323 gateway with as few entries as possible. Ideally, all the dial plan configuration would occur in Cisco CallManager. While this is possible with gateways based on MGCP or the Skinny Gateway Protocol, the more prominent gateways available are H.323-based.
This configuration assumes that 1+10 digit dialing would be required for long distance calls to the PSTN, and 7-digit dialing would be required for local PSTN calling.
Although the scope of the 9.@ route pattern includes emergency 911 services, the Cisco IOS H.323 gateway still requires a dial peer for 911. Various dial peers can be added for 411 and 611 services, which are included in the scope of the 9.@ route pattern as well.
As noted earlier in the "Calls out the PSTN" section, local area codes should be configured specifically with a route pattern and should not require a 1.
Dial plans for multi-site WAN systems are covered in "Multi-Site WAN with Distributed Call Processing" and "Multi-Site WAN with Centralized Call Processing."
Posted: Thu Jul 27 10:31:52 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.