Table Of Contents
Understanding Route Plans
Automated Alternate Routing
Route Plan Overview
Line Groups
Route Groups and Route/Hunt Lists
Route Patterns and Hunt Pilots Overview
Route Patterns
Closest Match Routing
Using Wildcard Characters in Route Patterns
Special Characters and Settings
Route Pattern Wildcards and Special Characters
Discard Digits Instructions
Calling and Called Party Transformations
Calling Party Number Transformations Settings
Called Party Number Transformations Settings
Caller Identification and Restriction
Calling Party Presentation and Restriction Settings
Connected Party Presentation and Restriction Settings
Caller Identification Support with Device Control Protocols in Cisco CallManager
External Route Plan Wizard
Generated Route Filters
Generated Route Groups
Generated Route Lists
Generated Route Patterns
Route Plan Report
Where to Find More Information
Understanding Route Plans
The Route Plan drop-down list on the menu bar allows you to configure Cisco CallManager route plans by using route patterns, route filters, route lists, and route groups.
This section describes the following route plan topics:
•Automated Alternate Routing
•Route Plan Overview
•Route Patterns
•Closest Match Routing
•Special Characters and Settings
•Calling and Called Party Transformations
•Caller Identification and Restriction
•External Route Plan Wizard
•Route Plan Report
•Where to Find More Information
Automated Alternate Routing
Automated alternate routing (AAR) provides a mechanism to reroute calls through the PSTN or other network by using an alternate number. As a subset of the AAR feature, Cisco CallManager automatically reroutes calls through the PSTN or other networks when Cisco CallManager blocks a call due to insufficient location bandwidth. With automated alternate routing, the caller does not need to hang up and redial the called party.
When a call is made from the device of one location to the device of another location, location bandwidth gets deducted from the maximum available bandwidth that is available for the call at either location. If not enough location bandwidth for the call exists at either location, instead of blocking the call, Cisco CallManager uses the table of AAR groups and the external number of the terminating directory number to supply the alternate number that is used to reroute the call through the PSTN or other network. The Cisco IP Phone displays the message "Network congestion, rerouting." (Configure this message by using Service Parameters Configuration for the Cisco CallManager service.) Cisco CallManager automatically attempts to reroute the call by using the alternate number. If the reroute is successful, the caller connects to the called party.
AAR supports the following call scenarios for insufficient bandwidth:
•Call originates from a line or directory number (DN) of an IP phone within one location and terminates to a line or DN of another IP phone within another location. This scenario includes calls that terminate at the shared line with terminating IP phone devices that are resident in multiple locations and calls that terminate at the Cisco voice-mail port.
•Incoming call through a gateway device within one location terminates to a line or DN of an IP phone within another location. This scenario includes calls that terminate at the shared line with terminating IP phone devices that are resident in multiple locations and calls that terminate at the Cisco voice-mail port.
Cisco CallManager automatically attempts to reroute calls, due to insufficient bandwidth, through the PSTN or other network only when the AAREnable enterprise parameter is set to true. Cisco CallManager uses the device-based AAR calling search space, which is assigned to Cisco IP Phone station devices and gateway devices, when it attempts to route the call to the gateway device that connects to the PSTN or other network. Cisco CallManager uses the external phone number mask and the directory number of the line or DN and the Cisco voice-mail port to derive the alternate number that is used to reroute the call.
Automated Alternate Routing Example
In the following scenario, line/DN 5000 in the Richardson AAR group calls line 5001 in the San Jose AAR group. If not enough location bandwidth exists, the call attempts to reroute through the PSTN or other network. To route the call from AAR group Richardson to AAR group San Jose, Cisco CallManager needs to know the access digit(s) to dial out to the PSTN or other network, the long-distance dialing requirement, if any, and the alternate number. Cisco CallManager retrieves the information from the AAR dial prefix matrix table, which is indexed by the originating line AAR group value and the terminating line AAR group value. Table 14-1 shows how the AAR group field is data filled in the line/DN table:
Table 14-1 Line/DN and AAR Group Association
Line/DN
|
AAR Group
|
5000
|
Richardson
|
5001
|
San Jose
|
5002
|
Dallas
|
Cisco CallManager retrieves the prefix digits from the AAR dial prefix matrix table based on the AAR group value of the originating line/DN and gateway device and the AAR group value of the terminating line, and Cisco voice-mail port, to transform the derived alternate number. Table 14-2 shows an example of how the AAR dial prefix matrix table is data filled:
Table 14-2 AAR Dial Prefix Matrix Table Example
From AAR Group
|
To AAR Group
|
Prefix Digits
|
Richardson
|
San Jose
|
91
|
Richardson
|
Dallas
|
9
|
Richardson
|
Richardson
|
9
|
San Jose
|
Richardson
|
91
|
San Jose
|
Dallas
|
91
|
San Jose
|
San Jose
|
9
|
Dallas
|
Richardson
|
9
|
Dallas
|
San Jose
|
91
|
Dallas
|
Dallas
|
9
|
Cisco CallManager prepends the prefix digits that are retrieved from the AAR dial prefix matrix table to the derived alternate number. Digit analysis uses the transformed digits, plus the AAR calling search space, to route the call to the PSTN or other network.
A much greater rate of success for automated alternate routing occurs when a gateway is located in the same location as the originating or terminating device. Therefore, a call that is outgoing to the PSTN or other network from a gateway that is located in the same location as the originating device and that is also incoming from a gateway located in the same location as the terminating device describes the best scenario. In other scenarios, the call remains subject to location bandwidth validation between the originating device and outgoing gateway, and between the terminating device and incoming gateway.
Automated Alternate Routing Enable Service Parameter
Besides configuring AAR groups, ensure that the Automated Alternate Routing Enable clusterwide service parameter is set to True. (The default value for this service parameter is False.)
Route Plan Overview
Cisco CallManager uses route plans to route internal calls within a Cisco CallManager cluster, and external calls to a private network or the public switched telephone network (PSTN).
Route patterns, route filters, route lists, and route groups provide flexibility in network design. Route patterns work in conjunction with route filters to direct calls to specific devices and to include or exclude specific digit patterns. Use route patterns to include and exclude digit patterns. Use route filters primarily to include digit patterns. Route lists control the selection order of the route groups. Route groups set the selection order of the gateway devices.
You can assign route patterns to gateways or to a route list that contains one or more route groups. Route groups determine the order of preference for gateway and port usage. Route groups allow overflows from busy or failed devices to alternate devices.
Route lists determine the order of preference for route group usage. If a route list is configured, you must configure at least one route group. One or more route lists can point to one or more route groups.
Route filters may restrict certain numbers that are otherwise allowed by a route pattern from being routed. Tags, or clauses, provide the core component of route filters. A tag applies a name to a portion of the dialed digits. For example, the North American Numbering Plan (NANP) number 972-555-1234 contains the LOCAL-AREA-CODE (972), OFFICE-CODE (555), and SUBSCRIBER (1234) tags.
Note The NANP designates the numbering plan for the PSTN in the United States and its territories, Canada, Bermuda, and many Caribbean nations. NANP includes any number that can be dialed and is recognized in North America.
Route patterns represent all valid digit strings. When you assign a directory number to a Cisco IP Phone, you assign it a route pattern (the directory number designates the route pattern). Cisco Analog Access Trunk Gateways, Cisco Digital Access Trunk Gateways, Cisco MGCP gateways, and H.323-compliant gateways also use route patterns. Cisco gateways can route ranges of numbers with complex restrictions and manipulate directory numbers before the Cisco CallManager passes them on to an adjacent system. The adjacent system can include a central office (CO), a private branch exchange (PBX), or a gateway on another Cisco CallManager system.
Line Groups
Line groups contain one or more directory numbers. A distribution algorithm, such as Top Down, Circular, Longest Idle Time, or Broadcast, is associated with a line group. Line groups also have an associated Ring No Answer reversion timeout value.
The following descriptions apply to the members of a line group:
•An idle member is not serving any call.
•An available member is serving an active call but can accept a new call(s).
•A busy member cannot accept any calls.
For information on creating line groups, refer to the "Line Group Configuration" section in the Cisco CallManager Administration Guide.
Route Groups and Route/Hunt Lists
Route Groups contain one or more devices, and route/hunt lists contain one or more line groups and/or one or more route groups. Cisco CallManager restricts the gateways that you can include in the same route group and the route groups that you can include in the same route/hunt list. For the purpose of route group and route/hunt list restrictions, Cisco CallManager divides gateways into three types
•Type 1—MGCP QSIG gateways
•Type 2—MGCP non-QSIG, Skinny, T1-CAS gateways; and non-gatekeeper-controlled intercluster trunks
•Type 3—H.225 and H.323 gateways, and all other trunk types
You can create route groups with Type 1 gateways only, Type 2 gateways only, Type 3 gateways only, or a combination of Type 2 and Type 3 gateways. You cannot combine Type 1 gateways with any other type of gateway in a route group.
Figure 14-1 provides examples of valid route groups.
Figure 14-1 Valid Route Groups Example
Cisco CallManager does not allow you to add route groups that contain gateways that use the H.323 or H.225 protocol (Type 3) and route groups that contain MGCP gateways that use a QSIG protocol (Type 1) to the same route list. You can create route lists with any combination of Type 1 route groups and Type 2 route groups as well as with any combination of Type 2 route groups and Type 3 route groups and line groups, as illustrated in Figure 14-2.
Figure 14-2 Valid Route Lists Example
For more information on creating route groups, refer to the "Adding a Route Group" section in the Cisco CallManager Administration Guide. For more information on creating route lists, refer to the "Adding a Route/Hunt List" section in the Cisco CallManager Administration Guide.
Route Patterns and Hunt Pilots Overview
You can assign a route pattern directly to a Cisco Access Gateway, or you can assign it to a route list for more flexibility. For example, Figure 14-3 shows Cisco Digital Access Gateway 1 designated as the first choice for routing outgoing calls to the PSTN when a matching route pattern is dialed.
Tip If a gateway does not have a route pattern, it cannot place calls to the PSTN or to a PBX. To assign a route pattern to an individual port on a gateway, you must assign a route list and a route group to that port.
Note A gateway port can belong to only one route group; however, you can assign a route group to multiple route lists.
Figure 14-3 shows the effects of using route patterns with Cisco Digital Access Gateways. This example assigns the route pattern to a route list, and that route list associates with a single route group. The route group supports a list of devices that are selected based on availability. If all ports on the first-choice gateway are busy or out of service, the call routes to the second-choice gateway in the route group.
Note If a route pattern is associated with a gateway, and all the resources of that gateway are used, then the call does not get routed.
Figure 14-3 Route Plan Summary Diagram for Cisco Digital Access Gateways
Figure 14-4 shows the effects of using route patterns with Cisco Analog Access Gateways. This example assigns the route pattern to a route list, and that route list associates with two route groups. Route group 1 associates with ports 1 through 8 on gateway 1, which routes all calls to interexchange carrier 1 (IXC 1). Route group 1 also associates with ports 1 through 4 on gateway 2. Route group 2 associates with ports 5 through 8 on gateway 2 and all ports on gateway 3.
Each route group supports a list of devices that are chosen on the basis of availability. For route group 1, if ports 1 through 8 on the first-choice gateway are busy or out of service, calls route to ports 1 through 4 on the second-choice gateway. If all routes in route group 1 are unavailable, calls route to route group 2. For route group 2, if ports 5 through 8 on the first-choice gateway are busy or out of service, calls route to ports 1 through 8 on the second-choice gateway. If no ports on any gateway in either route group are available, the call routes to an all trunks busy tone.
Figure 14-4 Route Plan Summary Diagram for Cisco Analog Access Gateways
Route Patterns
Cisco CallManager uses route patterns to route or block both internal and external calls. A directory number specifies a type of specific route pattern that is applied to a Cisco IP Phone.
The simplest route pattern specifies a set of one or more digits. For example, the number 8912 specifies a route pattern. When assigned to a Cisco Access gateway or a route list, the Cisco CallManager directs calls to 8912 to the assigned device.
Gateways and Cisco IP Phones can also use more complex route patterns that can contain wildcards. A wild card represents a range of numbers, for example X represents any digit 0 through 9.
Caution If a gateway has no route pattern associated with it, or it does not belong to a route group, it cannot route any calls.
You can use route patterns to invoke network-specific services/facilities on a call-by-call basis by configuring the fields in the ISDN Network-Specific Facilities Information Element section on the Route Pattern Configuration window. Cisco CallManager uses the network-specific services/facilities when the user dials the route pattern.
Note Cisco CallManager only uses the network-specific information with PRI protocol gateways. H.323 gateways do not support network-specific facilities.
Cisco CallManager codes the bearer capability as Speech for the ACCUNET service.
Closest Match Routing
Closest match routing process routes a call by using the route pattern that most closely matches the dialed number. When the Cisco CallManager encounters a dialed number that matches multiple route patterns, it uses closest match routing to determine which route pattern most closely matches the number and directs the call by using that route pattern.
When two configured route patterns exactly match the same number of addresses in different partitions, Cisco CallManager chooses the route pattern on the basis of the order in which the partitions are listed in the calling search space. (Cisco CallManager chooses the route pattern from the partition that appears first in the calling search space.)
If two configured route patterns exactly match the same number of addresses in a partition, the Cisco CallManager arbitrarily chooses one. The following paragraphs explain why such exact matches signify an unusual occurrence.
Several route patterns can match a single number. For instance, the number 8912 matches all the following route patterns: 8912, 89XX, and 8XXX.
In this example, the route pattern 8912 matches exactly one address. The route pattern 89XX matches 8912 plus 99 other addresses, and the route pattern 8XXX matches 8912 plus 999 other addresses.
If the user dials 8913, the call routes differently. Using the preceding example, this address matches only the routing patterns 89XX and 8XXX. Because 89XX matches a narrower range of addresses than 8XXX, the Cisco CallManager delivers the call to the device that is assigned the routing pattern 89XX.
Using Wildcard Characters in Route Patterns
Using the @ wildcard character in a route pattern provides a single route pattern to match all NANP numbers, and requires additional consideration.
The number 92578912 matches both of the following route patterns: 9.@ and 9.XXXXXXX. Even though both these route patterns seem to equally match the address, the 9.@ route pattern actually provides the closest match. The @ wildcard character encompasses many different route patterns, and one of those route patterns is [2-9][02-9]XXXXX. Because the number 2578912 more closely matches [2-9][02-9]XXXXX than it does XXXXXXX, the 9.@ route pattern provides the closest match for routing.
When configuring route patterns, take the following considerations into account:
•When @ is used in a routing pattern, the system recognizes octothorpe (#) automatically as an end-of-dialing character for international calls. For routing patterns that do not use @, you must include the # in the routing pattern to be able to use the # character to signal the end of dialing.
•If the route pattern contains an at symbol (@), the Discard Digits field can specify any discard digits instructions (DDIs).
The "Special Characters and Settings" section lists DDIs and describes the effects of applying each DDI to a dialed number.
Discard Digits Instructions
A discard digits instruction (DDI) removes a portion of the dialed digit string before passing the number on to the adjacent system. Portions of the digit string must be removed, for example, when an external access code is needed to route the call to the PSTN, but the PSTN switch does not expect that access code.
Note With non-@ patterns, you can use only Discard Digits instructions <None>, NoDigits, and PreDot.
Special Characters and Settings
Cisco CallManager Administration allows you to use special characters and settings to perform the following tasks:
•Allowing a single route pattern to match a range of numbers
•Removing a portion of the dialed digit string
•Manipulating the appearance of the calling party number for outgoing calls
•Manipulating the dialed digits, or called party number, for outgoing calls
For more information on how to use special characters and settings, see the following topics:
•Route Pattern Wildcards and Special Characters
•Discard Digits Instructions
Route Pattern Wildcards and Special Characters
Route pattern wildcards and special characters allow a single route pattern to match a range of numbers (addresses). Use these wildcards and special characters also to build instructions that enable the Cisco CallManager to manipulate a number before sending it to an adjacent system.
Table 14-3 describes the wildcards and special characters that Cisco CallManager supports.
Table 14-3 Wildcards and Special Characters
Character
|
Description
|
Examples
|
@
|
The at symbol (@) wildcard matches all NANP numbers.
Each route pattern can have only one @ wildcard.
|
The route pattern 9.@ routes or blocks all numbers that the NANP recognizes.
The following route patterns examples show NANP numbers that the @ wildcard encompasses:
•0
•1411
•19725551234
•101028819725551234
•01133123456789
|
X
|
The X wildcard matches any single digit in the range 0 through 9.
|
The route pattern 9XXX routes or blocks all numbers in the range 9000 through 9999.
|
!
|
The exclamation point (!) wildcard matches one or more digits in the range 0 through 9.
|
The route pattern 91! routes or blocks all numbers in the range 910 through 91999999999999999999999.
|
?
|
The question mark (?) wildcard matches zero or more occurrences of the preceding digit or wildcard value.
|
The route pattern 91X? routes or blocks all numbers in the range 91 through 91999999999999999999999.
|
+
|
The plus sign (+) wildcard matches one or more occurrences of the preceding digit or wildcard value.
|
The route pattern 91X+ routes or blocks all numbers in the range 910 through 91999999999999999999999.
|
[ ]
|
The square bracket ([ ]) characters enclose a range of values.
|
The route pattern 813510[012345] routes or blocks all numbers in the range 8135100 through 8135105.
|
-
|
The hyphen (-) character, used with the square brackets, denotes a range of values.
|
The route pattern 813510[0-5] routes or blocks all numbers in the range 8135100 through 8135105.
|
^
|
The circumflex (^) character, used with the square brackets, negates a range of values. Ensure that it is the first character following the opening bracket ([).
Each route pattern can have only one ^ character.
|
The route pattern 813510[^0-5] routes or blocks all numbers in the range 8135106 through 8135109.
|
.
|
The dot (.) character, used as a delimiter, separates the Cisco CallManager access code from the directory number.
Use this special character, with the discard digits instructions, to strip off the Cisco CallManager access code before sending the number to an adjacent system.
Each route pattern can have only one dot (.) character.
|
The route pattern 9.@ identifies the initial 9 as the Cisco CallManager access code in an NANP call.
|
*
|
The asterisk (*) character can provide an extra digit for special dialed numbers.
|
You can configure the route pattern *411 to provide access to the internal operator for directory assistance.
|
#
|
The octothorpe (#) character generally identifies the end of the dialing sequence.
Ensure the # character is the last character in the pattern.
|
The route pattern 901181910555# routes or blocks an international number that is dialed from within the NANP. The # character after the last 5 identifies this digit as the last digit in the sequence.
|
Table 14-4 lists Cisco CallManager Administration fields that require route patterns and shows the valid entries for each field.
Table 14-4 Field Entries
Field
|
Valid entries
|
Call Park Number/Range
|
[ ^ 0 1 2 3 4 5 6 7 8 9 - ] X * #
|
Calling Party Transform Mask
|
0 1 2 3 4 5 6 7 8 9 X * #
|
Called Party Transform Mask
|
0 1 2 3 4 5 6 7 8 9 X * #
|
Caller ID DN (Gateways)
|
0 1 2 3 4 5 6 7 8 9 X * #
|
Directory Number
|
[ ^ 0 1 2 3 4 5 6 7 8 9 - ] + ? ! X * # +
|
Directory Number (Call Pickup Group)
|
0 1 2 3 4 5 6 7 8 9
|
External Phone Number Mask
|
0 1 2 3 4 5 6 7 8 9 X * #
|
Forward All
|
0 1 2 3 4 5 6 7 8 9 * #
|
Forward Busy
|
0 1 2 3 4 5 6 7 8 9 * #
|
Forward No Answer
|
0 1 2 3 4 5 6 7 8 9 * #
|
Meet-Me Conference Number
|
[ ^ 0 1 2 3 4 5 6 7 8 9 - ] X * #
|
Prefix Digits
|
0 1 2 3 4 5 6 7 8 9 * #
|
Prefix DN (Gateways)
|
0 1 2 3 4 5 6 7 8 9 * #
|
Route Filter Tag Values
|
[ ^ 0 1 2 3 4 5 6 7 8 9 - ] X * #
|
Route Pattern
|
[ ^ 0 1 2 3 4 5 6 7 8 9 - ] + ? ! X * # + . @
|
Translation Pattern
|
[ ^ 0 1 2 3 4 5 6 7 8 9 - ] + ? ! X * # + . @
|
Discard Digits Instructions
A discard digits instruction (DDI) removes a portion of the dialed digit string before passing the number on to the adjacent system. A DDI must remove portions of the digit string, for example, when an external access code is needed to route the call to the PSTN, but the PSTN switch does not expect that access code.
Table 14-5 lists DDIs and describes the effects of applying each DDI to a dialed number.
Table 14-5 Discard Digits Instructions
DDI
|
Effect
|
Example
|
10-10-Dialing
|
This DDI removes
•IXC access code
|
Route pattern: 9.@
Dialed digit string: 910102889728135000
After applying DDI: 99728135000
|
10-10-Dialing Trailing-#
|
This DDI removes
•IXC access code
•End-of-dialing character for international calls
|
Route pattern: 9.@
Dialed digit string: 9101028801181910555#
After applying DDI: 901181910555
|
11/10D->7D
|
This DDI removes
•Long-distance direct-dialing code
•Long-distance operator-assisted dialing code
•IXC access code
•Area code
•Local area code
This DDI creates a 7-digit local number from an 11- or 10-digit dialed number.
|
Route pattern: 9.@
Dialed digit string: 919728135000 or 99728135000
After applying DDI: 98135000
|
11/10D->7D Trailing-#
|
This DDI removes
•Long-distance direct-dialing code
•Long-distance operator-assisted dialing code
•IXC access code
•Area code
•Local area code
•End-of-dialing character for international calls
This DDI creates a 7-digit local number from an 11- or 10-digit dialed number.
|
Route pattern: 9.@
Dialed digit string: 919728135000 or 99728135000
After applying DDI: 98135000
|
11D->10D
|
This DDI removes
•Long-distance direct-dialing code
•Long-distance operator-assisted dialing code
•IXC access code
|
Route pattern: 9.@
Dialed digit string: 919728135000
After applying DDI: 99728135000
|
11D->10D Trailing-#
|
This DDI removes
•Long-distance direct-dialing code
•Long-distance operator-assisted dialing code
•End-of-dialing character for international calls
•IXC access code
|
Route pattern: 9.@
Dialed digit string: 919728135000
After applying DDI: 99728135000
|
Intl TollBypass
|
This DDI removes
•International access code
•International direct-dialing code
•Country code
•IXC access code
•International operator-assisted dialing code
|
Route pattern: 9.@
Dialed digit string: 901181910555
After applying DDI: 9910555
|
Intl TollBypass Trailing-#
|
This DDI removes
•International access code
•International direct-dialing code
•Country code
•IXC access code
•International operator-assisted dialing code
•End-of-dialing character
|
Route pattern: 9.@
Dialed digit string: 901181910555#
After applying DDI: 9910555
|
NoDigits
|
This DDI removes no digits.
|
Route pattern: 9.@
Dialed digit string: 919728135000
After applying DDI: 919728135000
|
Trailing-#
|
This DDI removes
•End-of-dialing character for international calls
|
Route pattern: 9.@
Dialed digit string: 901181910555#
After applying DDI: 901181910555
|
PreAt
|
This DDI removes all digits prior to the NANP portion of the route pattern, including
•Cisco CallManager external access code
•PBX external access code
|
Route pattern: 8.9@
Dialed digit string: 899728135000
After applying DDI: 9728135000
|
PreAt Trailing-#
|
This DDI removes all digits prior to the NANP portion of the route pattern, including
•Cisco CallManager external access code
•PBX external access code
•End-of-dialing character for international calls
|
Route pattern: 8.9@
Dialed digit string: 8901181910555#
After applying DDI: 01181910555
|
PreAt 10-10-Dialing
|
This DDI removes all digits prior to the NANP portion of the route pattern, including
•Cisco CallManager external access code
•PBX external access code
•IXC access code
|
Route pattern: 8.9@
Dialed digit string: 8910102889728135000
After applying DDI: 9728135000
|
PreAt 10-10-Dialing Trailing-#
|
This DDI removes all digits prior to the NANP portion of the route pattern, including
•Cisco CallManager external access code
•PBX external access code
•IXC access code
•End-of-dialing character for international calls
|
Route pattern: 8.9@
Dialed digit string: 89101028801181910555#
After applying DDI: 01181910555
|
PreAt 11/10D->7D
|
This DDI removes all digits prior to the NANP portion of the route pattern, including
•Cisco CallManager external access code
•PBX external access code
•Long-distance direct-dialing code
•Long-distance operator-assisted dialing code
•IXC access code
•Area code
•Local area code
This DDI creates a 7-digit local number from an 11- or 10-digit dialed number.
|
Route pattern: 8.9@
Dialed digit string: 8919728135000 or 899728135000
After applying DDI: 8135000
|
PreAt 11/10D->7D Trailing-#
|
This DDI removes all digits prior to the NANP portion of the route pattern, including
•Cisco CallManager external access code
•PBX external access code
•Long-distance direct-dialing code
•Long-distance operator-assisted dialing code
•IXC access code
•Area code
•Local area code
•End-of-dialing character for international calls
This DDI creates a 7-digit local number from an 11- or 10-digit dialed number.
|
Route pattern: 8.9@
Dialed digit string: 8919728135000 or 899728135000
After applying DDI: 8135000
|
PreAt 11D->10D
|
This DDI removes all digits prior to the NANP portion of the route pattern, including
•Cisco CallManager external access code
•PBX external access code
•Long-distance direct-dialing code
•Long-distance operator-assisted dialing code
•IXC access code
|
Route pattern: 8.9@
Dialed digit string: 8919728135000
After applying DDI: 9728135000
|
PreAt 11D->10D Trailing-#
|
This DDI removes all digits prior to the NANP portion of the route pattern, including
•Cisco CallManager external access code
•PBX external access code
•Long-distance direct-dialing code
•Long-distance operator-assisted dialing code
•IXC access code
•End-of-dialing character for international calls
|
Route pattern: 8.9@
Dialed digit string: 8919728135000
After applying DDI: 9728135000
|
PreAt Intl TollBypass
|
This DDI removes all digits prior to the NANP portion of the route pattern, including
•Cisco CallManager external access code
•PBX external access code
•International access code
•International direct-dialing code
•Country code
•IXC access code
•International operator-assisted dialing code
|
Route pattern: 8.9@
Dialed digit string: 8901181910555
After applying DDI: 910555
|
PreAt Intl TollBypass Trailing-#
|
This DDI removes all digits prior to the NANP portion of the route pattern, including
•Cisco CallManager external access code
•PBX external access code
•International access code
•International direct-dialing code
•Country code
•IXC access code
•International operator-assisted dialing code
•End-of-dialing character
|
Route pattern: 8.9@
Dialed digit string: 8901181910555#
After applying DDI: 910555
|
PreDot
|
This DDI removes
•Cisco CallManager external access code
|
Route pattern: 8.9@
Dialed digit string: 899728135000
After applying DDI: 99728135000
|
PreDot Trailing-#
|
This DDI removes
•Cisco CallManager external access code
•End-of-dialing character for international calls
|
Route pattern: 8.9@
Dialed digit string: 8901181910555#
After applying DDI: 901181910555
|
PreDot 10-10-Dialing
|
This DDI removes
•Cisco CallManager external access code
•IXC access code
|
Route pattern: 8.9@
Dialed digit string: 8910102889728135000
After applying DDI: 99728135000
|
PreDot 10-10-Dialing Trailing-#
|
This DDI removes
•Cisco CallManager external access code
•IXC access code
•End-of-dialing character for international calls
|
Route pattern: 8.9@
Dialed digit string: 89101028801181910555#
After applying DDI: 901181910555
|
PreDot 11/10D->7D
|
This DDI removes
•Cisco CallManager external access code
•Long-distance direct-dialing code
•Long-distance operator-assisted dialing code
•IXC access code
•Area code
•Local area code
This DDI creates a 7-digit local number from an 11- or 10-digit dialed number.
|
Route pattern: 8.9@
Dialed digit string: 8919728135000 or 899728135000
After applying DDI: 98135000
|
PreDot 11/10D->7D Trailing-#
|
This DDI removes
•Cisco CallManager external access code
•Long-distance direct-dialing code
•Long-distance operator-assisted dialing code
•IXC access code
•Area code
•Local area code
•End-of-dialing character for international calls
This DDI creates a 7-digit local number from an 11- or 10-digit dialed number.
|
Route pattern: 8.9@
Dialed digit string: 8919728135000 or 899728135000
After applying DDI: 98135000
|
PreDot 11D->10D
|
This DDI removes
•Cisco CallManager external access code
•Long-distance direct-dialing code
•Long-distance operator-assisted dialing code
•IXC access code
|
Route pattern: 8.9@
Dialed digit string: 8919728135000
After applying DDI: 99728135000
|
PreDot 11D->10D Trailing-#
|
This DDI removes
•Cisco CallManager external access code
•Long-distance direct-dialing code
•Long-distance operator-assisted dialing code
•IXC access code
•End-of-dialing character for international calls
|
Route pattern: 8.9@
Dialed digit string: 8919728135000
After applying DDI: 99728135000
|
PreDot Intl TollBypass
|
This DDI removes
•Cisco CallManager external access code
•International access code
•International direct-dialing code
•Country code
•IXC access code
•International operator-assisted dialing code
|
Route pattern: 8.9@
Dialed digit string: 8901181910555
After applying DDI: 9910555
|
PreDot Intl TollBypass Trailing-#
|
This DDI removes
•Cisco CallManager external access code
•International access code
•International direct-dialing code
•Country code
•IXC access code
•International operator-assisted dialing code
•End-of-dialing character
|
Route pattern: 8.9@
Dialed digit string: 8901181910555#
After applying DDI: 9910555
|
Calling and Called Party Transformations
Cisco CallManager Administration allows you to manipulate the calling party number and the called party number that Cisco CallManager sends with each call setup message.
The following topics provide information on these settings:
•Calling Party Number Transformations Settings
•Called Party Number Transformations Settings
Calling Party Number Transformations Settings
Calling party transformations settings allow you to manipulate the appearance of the calling party number for outgoing calls. Cisco CallManager uses the calling party number for calling line identification (CLID). During an outgoing call, the CLID passes to each private branch exchange (PBX), central office (CO), and interexchange carrier (IXC) as the call progresses. The called party receives the calling line identification (CLID) when the call is offered to the called party.
Configuration for calling party transformations settings that are used in route lists occurs in the individual route groups that comprise the list. The calling party transformations settings that are assigned to the route groups in a route list override any calling party transformations settings that are assigned to a route pattern that is associated with that route list.
You can set the following calling party transformation settings in the route group configuration:
•Use Calling Party's External Phone Number Mask
•Calling Party Transform Mask
•Prefix Digits (Outgoing Calls)
Table 14-6 describes the fields, options, and values that are used to specify calling party number transformations.
Table 14-6 Calling Party Number Transformations Settings
Field Name
|
Description
|
Use Calling Party's External Phone Number Mask
|
This field determines whether the full, external phone number is used for calling line identification (CLID) on outgoing calls. (Configure the external number by using the Directory Number Configuration window.)
The following list gives the options for this field:
•Default: This setting indicates that the route group does not govern the calling party external phone number and calling party transform masks. If a calling party external phone number mask or transform mask is chosen for the route pattern, calls that are routed through this route group use those masks.
•Off: This setting indicates that the calling party external phone number is not used for CLID. If no transform mask is entered for this route group, calls that are routed through this group do not get associated with a CLID.
•On: This setting indicates that the calling party full, external number is used for CLID.
|
Calling Party Transform Mask
|
This field specifies the calling party transform mask for all calls that are routed through this route group. Valid values for this field range from 0 through 9, the wildcard character X, and the characters * and #. You can also leave this field blank. If it is blank and the preceding field is set to Off, this means that no calling party number is available for CLID.
The calling party transform mask can contain up to 50 digits.
|
Prefix Digits (Outgoing Calls)
|
This field contains a prefix digit or a set of Prefix Digits (Outgoing Calls) that are appended to the calling party number on all calls that are routed through this route group. Valid values for this field range from 0 through 9, the characters * and #, and blank. Prefix Digits (Outgoing Calls) can contain up to 50 digits.
|
Called Party Number Transformations Settings
Called party transformations settings allow you to manipulate the dialed digits, or called party number, for outgoing calls. Examples of manipulating called numbers include appending or removing prefix digits (outgoing calls), appending area codes to calls dialed as seven-digit numbers, appending area codes and office codes to interoffice calls dialed as four- or five-digit extensions, and suppressing carrier access codes for equal access calls.
Called party transformations settings that are used in route lists are configured in the individual route groups comprising the list. The called party transformations settings that are assigned to the route groups in a route list override any called party transformations settings that are assigned to a route pattern or translation pattern that is associated with that route list.
You can set the following called party transformation settings in the route group, route pattern, and translation pattern configuration:
•Discard Digits
•Called Party Transform Mask
•Prefix Digits (Outgoing Calls)
Table 14-7 describes the fields, options, and values that are used to specify called party number transformations.
Table 14-7 Called Party Number Transformations Settings
Field Name
|
Description
|
Route Group Configuration
|
Discard Digits
|
This field contains a list of discard patterns that control the discard digit instructions. For example, in a system where users must dial 9 to make a call to the public switched telephone network (PSTN), the PreDot discard pattern causes the 9 to be stripped from the dialed digit string. See the "Closest Match Routing" section for more information.
Note Any setting other than the default setting of <None> overrides the setting in the route pattern. The <None> setting means "do not discard digits."
|
Called Party Transform Mask
|
This field specifies the called party transform mask for all calls that are routed through this route group. Valid values for this field range from 0 through 9, the wildcard character X, and characters * and #. You can also leave this field blank. If this field is blank, no transformation takes place; Cisco CallManager sends the dialed digits exactly as dialed.
The called party transform mask can contain up to 50 digits.
|
Prefix Digits (Outgoing Calls)
|
This field contains a prefix digit or a set of Prefix Digits (Outgoing Calls) that are appended to the called party number on all calls that are routed through this route group. Valid values for this field range from 0 through 9, the characters * and #, and blank. Prefix Digits (Outgoing Calls) can contain up to 50 digits.
|
Related Topics
•Special Characters and Settings
•Closest Match Routing
•Caller Identification and Restriction
•Understanding Route Plans
Caller Identification and Restriction
Cisco CallManager provides the following types of caller identification information:
•Calling Line Identification (CLID)—Provides the called party with the calling party's extension or directory number on a display.
•Calling Name Identification—Provides the called party with the calling party's name on a display.
•Connected Line Identification—Provides the calling party with the connected party's phone number on a display.
•Connected Name Identification—Provides the calling party with the connected party's name on a display
Cisco CallManger provides flexible configuration options to allow and to restrict the display of the line and name information for both calling and connected parties.
For more information on how to use caller identification settings, see the following topics:
•Calling Party Presentation and Restriction Settings
•Connected Party Presentation and Restriction Settings
Calling Party Presentation and Restriction Settings
Calling party presentation information controls whether to display the phone number and name information that Cisco CallManager sends with setup messages for an outgoing call. Cisco CallManager uses the following fields to provide these supplementary services:
•Calling Line ID Presentation field—Calling line identification presentation (CLIP) or calling line identification restriction (CLIR)
•Calling Name Presentation field—Calling name presentation (CNIP) or calling name restriction (CNIR)
You can use the Calling Line ID Presentation field in the Gateway Configuration window to control whether the CLID displays for all outgoing calls on the gateway. To control the CLID display on a call-by-call basis, you use the Calling line ID Presentation field in Route Pattern Configuration or Translation Pattern Configuration windows.
The following example describes how calling line ID presentation works. When a user makes a call, Cisco CallManager checks whether the dialed number matches a translation pattern. Cisco CallManager finds a match, and sets the presentation indicator to the value in the translation pattern Calling Line ID Presentation field, which specifies "restricted" in this example. Next, Cisco CallManager checks and finds a match on a route pattern that is configured for the dialed number. Cisco CallManager checks the Calling Line ID Presentation field and finds that the value specifies "default." The presentation indicator remains as "restricted," because the previous setting is unchanged when default is set.
The gateway Calling Line ID Presentation field gets checked last. In this example, the value specifies "allowed" and overrides the previous calling line ID presentation indicator to allow the calling party number to display on the called party phone. Therefore, the calling line ID presentation field indicator changed from "restricted" at the time that the calling party initiated the call, to "allowed" by the time that Cisco CallManager sends the call setup message to the endpoint device.
You can configure line and name presentation or restriction on a call-by-call basis for outgoing calls and incoming calls by using the Route Pattern Configuration or Translation Pattern Configuration pages.
For the gateway, you can only configure calling line ID presentation for outgoing calls. For incoming calls, Cisco CallManager uses the Connected Line ID Presentation field for the gateway to specify whether to allow or restrict the connected party number to display on the calling party phone. Gateway settings only apply in these two situations and these settings override all other settings. For the gateway, you can only configure calling and connected line presentation. There are no settings to control name presentation on the gateway.
Caller name and number information is limited by the type of device control protocol that handles the call. See Table 14-10 for a list of protocols with the supported caller name and number information.
Note To control the name display for non-QSIG trunks, you must enable or disable the Display IE Delivery field or Send Calling Name in Facility IE field in the Gateway Configuration window.
Table 14-8 describes the fields, options, and values that are used to specify calling party presentations.
Table 14-8 Calling Party Presentation Settings
Field Name
|
Description
|
Calling Line ID Presentation (outgoing call)
|
This field determines whether the calling party phone number displays on the called party phone display screen. The Gateway Configuration, the Route Pattern Configuration, and the Translation Pattern Configuration windows use the Calling Line Presentation field.
The following list gives the options for this field:
•Default: If default is set, calling line ID presentation does not get modified.
•Allowed: Use this setting to permit the calling party phone number to display in the called party phone display screen.
•Restricted: Use this setting to display "Private" in the called party phone display screen and block the display of the calling party phone number.
|
Calling Name Presentation (outgoing call)
|
This field determines whether the calling party's name displays on the called party phone display screen. The Route Pattern Configuration and Translation Pattern Configuration windows use the Calling Name Presentation field.
The following list gives the options for this field:
•Default: If default is set, calling name presentation does not get modified.
•Allowed: Use this setting to display the calling party name in the called party phone display screen.
•Restricted: Use this setting in the route patterns or translation patterns configuration displays "Private" in the called party phone display screen.
Note The gateway has no setting for calling name presentation.
|
Calling Line ID Presentation (incoming call)
|
If the incoming call goes through a translation pattern or route pattern and the calling line ID presentation setting is allowed or restricted, the calling line presentation gets modified with the translation or route pattern setting. If the call comes into the Cisco CallManager system and then goes out to a PBX or the PSTN, the outgoing call rules apply as stated in the "Calling Party Presentation and Restriction Settings" section.
Note The gateway calling line ID presentation setting controls outgoing calls only.
|
Calling Name Presentation (incoming call)
|
If the incoming call goes through a translation pattern or route pattern and the calling name presentation setting is allowed or restricted, the calling name presentation gets modified with the translation or route pattern setting. If the call comes into the Cisco CallManager system and then goes out to a PBX or the PSTN, the outgoing call rules apply as stated in the "Calling Party Presentation and Restriction Settings" section.
Note The gateway has no settings to control name information.
|
Connected Party Presentation and Restriction Settings
Connected party presentation information controls whether to display the phone number and name information that Cisco CallManager receives with an incoming call. Cisco CallManager uses the following fields to provide these supplementary services:
•Connected Line ID Presentation field—Connected line identification presentation (COLP) or connected line identification restriction (COLR)
•Connected Name Presentation field—Connected name presentation (CONP) or calling name restriction (CONR)
Connected party settings allow you to display or restrict the display of the phone number and name of the connected party on the calling party's phone.These two settings are only available in Translation Patterns Configuration and Route Patterns Configuration windows. The calling party receives the connected name information after the call connects to Cisco CallManager and the terminating phone.
The following example describes how connected line ID works. When Cisco CallManager receives an incoming call, it checks whether a translation pattern is configured for the incoming number. Cisco CallManager uses the value in the Connected Line ID Presentation field which specifies "restricted" for this example. Next, if a route pattern is configured for the incoming call, the value in the Connected Line ID Presentation field gets checked. In this example, the value specifies "default," so the indicator remains as "restricted" which prevents the connected party number from displaying on the calling party's phone.
For incoming calls only, the gateway Connected Line ID Presentation field value gets checked last and is set for "allowed" in this example. The gateway setting specifies whether the connected party number can display on the calling party phone. In this case, Cisco CallManager sends "allowed" in the CONNECT message so that the connected line can display on the originating caller's phone display.
You can configure connected line and name presentation or restriction on a call-by-call basis for outgoing calls and incoming calls by using the Route Pattern Configuration or Translation Pattern Configuration pages.
For incoming calls on the gateway, you use the Connected Line ID Presentation field to specify whether to allow or restrict the display of the connected party number on the calling party's phone. Gateway settings only apply to line presentation settings and override all other settings.
Note For the gateway, you can only configure calling and connected line presentation options. There are no settings for name presentation on the gateway.
Table 14-9 describes the fields, options, and values that are used to specify connected party presentations.
Table 14-9 Connected Party Presentation Settings
Field Name
|
Description
|
Connected Line ID Presentation (outgoing call)
|
In the Route Pattern Configuration and the Translation Pattern Configuration windows, this field determines whether the connected party number displays on the calling party phone display screen.
The following list gives the options for this field:
•Default: If default is set, connected line ID presentation does not get modified.
•Allowed: Use this setting to display the connected line number that Cisco CallManager received in protocol messages on the calling party phone display.
•Restricted: Use this setting to block the connected party number from displaying in the calling party phone display screen, and "Unknown Number" displays instead.
Note This setting applies to internal calls and calls on QSIG connections only.
|
Connected Name Presentation (CONP/CONR) (outgoing call)
|
This field determines whether the connected party name displays on the calling party phone display screen. The Route Pattern Configuration and Translation Pattern Configuration windows use the Connected Name Presentation field.
The following list gives the options for this field:
•Default: If default is set, calling name presentation does not get modified.
•Allowed: Use this setting to display the connected party name that Cisco CallManager received in protocol messages in the calling party phone display screen.
•Restricted: Use this setting to block the connected party name from displaying, and display "Unknown" in the calling party phone display screen.
|
Connected Line ID Presentation (incoming call)
|
If the incoming call goes through a translation or route pattern and the connected line ID presentation field is set to allowed or restricted, the connected line presentation indicator gets modified with the translation or route pattern setting.
Note The Connected Line ID Presentation setting on the gateway determines if the connected party number can display on the originating party's phone.
If the call comes into the Cisco CallManager system and then goes out to a PBX or the PSTN, the outgoing call rules apply as stated in the "Connected Party Presentation and Restriction Settings" section.
|
Connected Name Presentation (incoming call)
|
If the incoming call goes through a translation or route pattern and the connected name presentation setting is set to allowed or restricted, the connected name presentation gets modified with the translation or route pattern setting. If the call comes into the Cisco CallManager system and then goes out to a PBX or the PSTN, the outgoing call rules apply as stated in the "Connected Party Presentation and Restriction Settings" section.
Note The gateway has no settings to control name information.
|
Caller Identification Support with Device Control Protocols in Cisco CallManager
Cisco CallManager provides support for caller name and number identification presentation based on the device control protocols that handle the call. Not all device protocols provide caller number and name information in the protocol messages. Table 14-10 summarizes which protocols support caller identification services.
Table 14-10 Caller Identification Information Supported by Device Control Protocols
Device Control Protocol
|
Calling Line
|
Calling Name
|
Connected Line
|
Connected Name
|
IP Phones with SCCP
|
provides line number
|
provides name associated with DN
|
displays number when received
|
displays name when received
|
MGCP Stations (FXS)
|
provides line number
|
provides name associated with DN
|
not supported
|
displays name when received
|
MGCP Trunk (FXO, T1 CAS)
|
not supported
|
not supported
|
not supported
|
not supported
|
H.323 Trunk
|
calling line sent in H.225 SETUP
|
supported by using DISPLAY IE in H.225 messages for intercluster trunks only
|
supported by H.225 NOTIFY for intercluster trunks only
|
supported by DISPLAY IE in H.225 messages for intercluster trunks only
|
PRI Trunk
|
calling line in PRI SETUP
|
supported by using FACILITY IE in PRI messages
|
not supported
|
supported by using FACILITY IE in PRI messages
|
QSIG Trunk
|
calling line in QSIG SETUP
|
supported by using FACILITY IE in QSIG messages
|
supported by QSIG CONNECT
|
supported by using FACILITY IE in QSIG messages
|
SIP Trunk
|
calling line included in From and Remote-Party- ID headers
|
calling name included in From and Remote-Party-ID headers
|
connected line included in Remote-Party-ID header
|
connected name included in Remote-Party-ID header
|
Related Topics
•Calling and Called Party Transformations
•Special Characters and Settings
•Enhanced Call Identification Services, page 37-10
External Route Plan Wizard
The external route plan wizard generates a single-tenant, multilocation, partitioned route plan for the North American Numbering Plan (NANP) area by using information that the administrator provides through a series of prompts.
The route plan that the external route plan wizard generates includes the following elements:
•Route filters
•Route groups
•Route lists
•Route patterns
•Partitions
•Calling search spaces
•Calling party and calling party transformations
•Access code manipulation
The following topics describe the basic concepts that are used when you generate route plans with the external route plan wizard:
•Generated Route Filters
•Generated Route Groups
•Generated Route Lists
•Generated Route Patterns
Generated Route Filters
A generated route filter permits or restricts access through a route list by using route patterns. The external route plan wizard associates each route list with a particular route filter. It names route filters by using the TenantLocationCalltype convention and appends the suffix RF to each route filter for easy identification.
Table 14-11 shows the seven types of route lists that use route filters. The table shows examples that use specific route filter names and actual access and area codes for better readability.
Table 14-11 Route Lists and Associated Route Filters
Route List Type
|
Route Filter Name and Content Examples
|
911 calls
|
Name: CiscoDallas911RF
Content: 9.@ where (SERVICE == 911)
|
Local calls with metro (7- and 10-digit) dialing
|
Name: CiscoDallasLocalRF
Content: 9.@ where (INTERNATIONAL-ACCESS DOES-NOT-EXIST) AND (LOCAL-AREA-CODE DOES-NOT-EXIST) AND (AREA-CODE DOES-NOT-EXIST) AND (SERVICE DOES-NOT-EXIST) OR (LOCAL-AREA-CODE == 972) OR (LOCAL-AREA-CODE == 214)
|
Local calls with 10-digit dialing
|
Name: CiscoDallasLocal10DCallRF
Content: 9.@ where (LOCAL-AREA-CODE == 972) OR (LOCAL-AREA-CODE == 214)
|
Local calls with 7-digit dialing
|
Name: CiscoDallasLocal7DCallRF
Content: 9.@ where (INTERNATIONAL-ACCESS DOES-NOT-EXIST) AND (AREA-CODE DOES-NOT-EXIST) AND (SERVICE DOES-NOT-EXIST)
|
Toll bypass calls
|
Name: CiscoTollByPassToDallasRF
Content: 9.@ where (AREA-CODE == 972) OR (AREA-CODE == 214)
|
Long-distance calls
|
Name: CiscoDallasLongDistanceRF
Content: 9.@ where (AREA-CODE EXISTS)
|
International calls
|
Name: CiscoDallasIntlRF
Content: 9.@ where (INTERNATIONAL-ACCESS EXISTS)
|
Generated Route Groups
A generated route group sets the order of preference for gateway and port usage. The external route plan wizard assigns one gateway to each generated route group. The wizard uses all ports on the gateways. It does not support using partial resources for generated external route plans.
The external route plan wizard names route filters by using the TenantLocationGatewayTypeNumber convention for easy identification. The following list shows the gateway type abbreviations:
•AA: analog access
•DA: digital access
•HT: H.323 trunk
•MS: MGCP station
•MT: MGCP trunk
The external route plan wizard identifies route groups that are associated with multiple gateways of the same type by attaching a number suffix to all route groups. For example, if three MGCP trunk gateways exist at the Cisco Dallas location, the external route plan wizard names the associated route groups CiscoDallasMT1, CiscoDallasMT2, and CiscoDallasMT3.
If a route list includes more than one route group and more than one gateway (with one gateway for each route group), an arbitrary order designates how the external route plan wizard lists the route groups. The only order that is imposed ensures that route groups that are associated with the local gateways are listed before the route groups that are associated with remote gateways. If needed, manually change the order after the route plan is generated.
Note Cisco CallManager treats all gateways that belong to a location as shared resources for that location.
Generated Route Lists
A generated route list sets the order of preference for route group usage and defines the route filters that are applied to those route groups. The external route plan wizard creates between five and seven route lists for each location depending on the types of local dialing choices that are available. Therefore, the total number of route lists depends on the local dialing scheme and the number of locations that the route plan serves.
Using the TenantLocationCalltype convention, the external route plan wizard names route lists and appends the suffix RL to each route list for easy identification.
Table 14-12 shows the eight types of route lists. The examples shown in this table use specific route list names for better readability.
Table 14-12 Route List Types
Route List Type
|
Example Route List Name and Usage
|
911 calls
|
Name: CiscoDallas911RL
Use: This route list type applies for 911 emergency calls.
|
Enterprise calls
|
Name: CiscoDallasEnterpriseRL
Use: This route list type applies for route plans that include Cisco CallManager to adjacent PBX calls. If the route plan does not include routing to an adjacent PBX, the wizard does not generate this route list type.
|
Local calls with metro dialing
|
Name: CiscoDallasLocalRL
Use: This route list type applies for route plans that encompass both 7- and 10-digit dialing areas. This route list type generates two route lists: one for 7-digit dialing and another for 10-digit dialing. If you chose to generate a route plan that uses metro route lists, you cannot also choose 7- or 10-digit dialing route lists.
|
Local calls with 10-digit dialing
|
Name: CiscoDallasLocal10DCallRL
Use: This route list type applies for route plans that use 10-digit dialing. This route list type generates one route list for 10-digit dialing. If you chose to generate a route plan that uses a 10-digit dialing route list, you cannot also choose 7-digit or metro dialing route lists.
|
Local calls with 7-digit dialing
|
Name: CiscoDallasLocal7DCallRL
Use: This route list type applies for route plans that use 7-digit dialing. This route list type generates one route list for 7-digit dialing. If you chose to generate a route plan that uses a 7-digit dialing route list, you cannot also choose 10-digit or metro dialing route lists.
|
Toll bypass calls
|
Name: CiscoTollByPassToDallasRL
Use: This route list type applies for intracluster calls that originate from a remote location and that get routed out the local gateway as local calls.
|
Long-distance calls
|
Name: CiscoDallasLongDistanceRL
Use: This route list type applies for long-distance toll calls.
|
International calls
|
Name: CiscoDallasIntlRL
Use: This route list type applies for international toll calls.
|
Generated Route Patterns
A generated route pattern directs calls to specific devices and either includes or excludes specific dialed-digit strings. The external route plan wizard only generates route patterns that require an access code prefix. The typical route pattern for routing a call to the PSTN includes the prefix construction 9.@. The typical route pattern for routing a call to the PBX includes the prefix construction 9.9@.
The external route plan wizard associates a route list, a route filter, and a partition with each route pattern. The route pattern provides the appropriate calling party transform mask, called party transform mask, digit discard instructions, and prefix digits for the associated route list.
The wizard bases route patterns for calls to an adjacent PBX on the access code and the range of directory numbers that are served by that PBX. For example, if the access code that is used to direct calls to the adjacent PBX is 9 and the range of directory numbers that is served by that PBX is 1000 through 1999, the external route plan wizard generates the route pattern 9.1XXX for enterprise calls.
Route Plan Report
The route plan report comprises a listing of all unassigned directory numbers (DN), call park numbers, call pickup numbers, conference numbers (Meet-Me numbers), directory numbers, route patterns, translation patterns, voice-mail ports, message-waiting indicators, and attendant console numbers in the system.
The route plan report allows you to view either a partial or full list and to go directly to the associated configuration windows by choosing a route pattern, partition, route group, route list, directory number, call park number, call pickup number, conference number (Meet-Me number), or gateway.
Using the route plan report, you can get a list of unassigned directory numbers and delete those numbers from the Cisco CallManager database, if required.
In addition, the route plan report allows you to save report data into a .csv file that you can import into other applications such as the Bulk Administration Tool (BAT). The .csv file contains more detailed information than the web pages, including directory numbers (DN) for phones, route patterns, and translation patterns. Refer to the "Route Plan Report" section in the Cisco CallManager Administration Guide for more information.
Where to Find More Information
Related Topic
•Partitions and Calling Search Spaces
Related Cisco Documentation
•Partition Configuration, Cisco CallManager Administration Guide
•Calling Search Space Configuration, Cisco CallManager Administration Guide
•Cisco IP Telephony Network Design Guide