This chapter provides information about the Route Plan drop-down
list on the menu bar which allows you to configure
Cisco Unified Communications Manager route plans by using route patterns, route
filters, route lists, and route groups, as well as hunt pilots, hunt lists, and
line groups.
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 Unified Communications Manager automatically reroutes calls through the PSTN
or other networks when
Cisco Unified Communications Manager 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 Unified Communications Manager 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 Unified IP Phone displays the message
"Network congestion, rerouting." (Configure this message by using
Service Parameters Configuration for the Cisco CallManager service.)
Cisco Unified Communications Manager 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 Unified Communications Manager automatically attempts to reroute
calls, due to insufficient bandwidth, through the PSTN or other network only
when the Automated Alternate Routing Enable enterprise parameter is set to
true.
Cisco Unified Communications Manager uses the device-based AAR calling search
space, which is assigned to
Cisco Unified 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 Unified Communications Manager 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 Unified Communications Manager 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 Unified Communications Manager 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. The following shows how the AAR group
field is data filled in the line/DN table:
Table 1 Line/DN and AAR Group Association
Line/DN
AAR Group
5000
Richardson
5001
San Jose
5002
Dallas
Cisco Unified Communications Manager 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. The following
shows an example of how the AAR dial prefix matrix table is data filled:
Table 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 Unified Communications Manager 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 specifies False.)
The Clusterwide Parameters (System - CCMAutomated Alternate
Routing) section of the service parameters for the Cisco CallManager service
includes the parameter.
Automated Alternate Routing and hunt pilots
In previous
Cisco Unified Communications Manager releases, if the voice-messaging system is in
a central location and the user is in a remote location, when the remote user
tries to reach the voice-messaging system and bandwidth is not available on the
WAN link,
Cisco Unified Communications Manager can reroute the call through the PSTN to the
voice-messaging system.
In the current
Cisco Unified Communications Manager release, AAR does not automatically work with
hunt pilots. Because the fully qualified directory number (DN) of the remote
agent is unknown, AAR cannot initiate the reroute.
To enable AAR to work with hunt pilots, two additional
fields display in the Hunt Pilot Configuration window: AAR Group and External
Number Mask. For each hunt pilot, you must configure these fields in the Hunt
Pilot Configuration window for AAR groups to work with hunt pilots.
Automated Alternate Routing and remote gateways
AAR exhibits the limitation that calls routed over a remote
gateway during a high-bandwidth situation fail, and the calls cannot be routed
over the local gateway when AAR is used. This functionality is important to
customers who use Tail-End Hop Off (TEHO) for toll bypass.
See the
Troubleshooting Guide for
Cisco Unified Communications Manager for details of a workaround to avoid the use
of AAR in remote-gateway, high-bandwidth situations.
Route plan overview
Cisco Unified Communications Manager uses route plans to route internal
calls, and to route external calls to a private network or the public switched
telephone network (PSTN).
Route patterns, route filters, route lists, route groups,
line groups, hunt lists, and hunt pilots 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, to trunks, or to
a route list that contains one or more route groups. Route groups determine the
order of preference for gateway and trunk 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. Cisco
Analog Access Trunk Gateways, Cisco Digital Access Trunk Gateways, Cisco MGCP
gateways, H.323-compliant gateways, and trunks also use route patterns. Cisco
gateways can route ranges of numbers with complex restrictions and manipulate
directory numbers before the
Cisco Unified Communications Manager 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 Unified Communications Manager system.
A line group comprises a list of DNs. Line groups specify a
distribution algorithm (such as Top Down) for the members of the line group.
Line groups also specify the hunt options to use in cases where the line group
members do not answer, are busy, or are not available. A directory number may
belong to more than one line group.
Hunt lists comprise ordered groupings of line groups. A line
group may belong to more than one hunt list. A hunt list must specify at least
one line group before the hunt list can accept calls.
Hunt pilots represent route patterns that are used for
hunting. A hunt pilot can specify a partition, numbering plan, route filter,
and hunt forward settings. A hunt pilot must specify a hunt list.
Route groups and route lists
Route groups contain one or more devices, and route lists
contain one or more route groups.
Cisco Unified Communications Manager may restrict the gateways that you can include
in the same route group and the route groups that you can include in the same
route list. For the purpose of route group and route list restrictions,
Cisco Unified Communications Manager divides gateways into three types:
Type 1-MGCP QSIG gateways and QSIG-enabled intercluster trunks
Type 2-MGCP non-QSIG, Skinny, T1-CAS gateways; non-QSIG
intercluster trunks
Type 3-H.225 and H.323 gateways, and all other trunk types
Route lists can contain a mixture of route group types,
although you cannot combine an H225 trunk with a Type 1 (QSIG) route group.
Cisco Unified Communications Manager 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, as illustrated below.
Figure 1. Valid Route Lists Example
Note
You cannot combine route groups and line groups, and route lists and
hunt lists become separate entities. Thus, route groups make up route lists,
and line groups make up hunt lists. If an existing route/hunt list includes a
line group as a member,
Cisco Unified Communications Manager migrates the route/hunt list to a hunt list.
Route lists can simultaneously run on all nodes and
Cisco Unified Communications Manager can randomly choose from any of the available
route lists that can reach a given node. The system ensures that, over time and
on average, all 16 nodes in the core cluster are used equally. This prevents
system resources on some nodes from being idle while other nodes are dealing
with an unsustainable call burden.
Route patterns
Cisco Unified Communications Manager uses route patterns to route or block
both internal and external calls.
Note
Route group and route lists are part of route pattern configuration.
Line groups and hunt lists are part of hunt pilot configuration. Route patterns
and hunt pilots are configured separately. Route groups or route lists cannot
be added to hunt pilot and line groups. Hunt lists cannot be added to route
pattern. If an existing route pattern/hunt pilot associates with a hunt list,
Cisco Unified Communications Manager migrates the route pattern/hunt pilot to a
hunt pilot.
The simplest route pattern specifies a set of one or more
digits. For example, the number 8912 specifies a route pattern.
Gateways and
Cisco Unified IP Phones can also use more complex route patterns that can contain
wildcards. A wildcard represents a range of numbers; for example, X represents
any digit 0 through 9.
To classify a call as OnNet or OffNet, administrators can
set the Call Classification field to OnNet or OffNet, respectively, on the
Route Pattern Configuration window. Administrators can override the route
pattern setting and use the trunk or gateway setting by checking the Allow
Device Override check box on the Route Pattern Configuration window.
Caution
If a gateway has no route pattern that is 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 Unified Communications Manager uses the network-specific services/facilities
when the user dials the route pattern.
Note
Cisco Unified Communications Manager only uses the network-specific information
with PRI protocol gateways. H.323 gateways do not support network-specific
facilities, but they support SDN when the dial peers are configured
accordingly.
Cisco Unified Communications Manager codes the bearer capability as Speech for the
ACCUNET service.
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, the figure 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.
The following figure shows the effects of using route
patterns with Cisco Digital 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.
Figure 2. Route Plan Summary Diagram for Cisco Digital Gateways
When the system initially presents a call to a member of a
route list,
Cisco Unified Communications Manager reroutes for all cause codes other than Out of
Bandwidth, User Busy, and Unallocated Number. The value of the associated
service parameters for the Cisco CallManager service determines the rerouting
decision for those cause codes. The Clusterwide Parameters (Route Plan)
grouping includes the Stop Routing on Out of Bandwidth Flag, Stop Routing on
User Busy Flag, and Stop Routing on Unallocated Number Flag service parameters.
You can set each service parameter to True or False.
After a route list locks onto a trunk, no rerouting occurs.
The media connect time of the endpoints and the Stop Routing service parameters
determine when a route list stops hunting for the next route group. When media
negotiation begins, the route list or hunt list loses the ability to reroute.
The Stop Routing on Q.931 Disconnect Cause Code service
parameter for the Cisco CallManager service determines routing behavior when a
call that is being routed to a remote site through a route list gets released
and a Q.931 cause code gets sent to
Cisco Unified Communications Manager. If the cause code that is encountered in the
message matches a cause code that this parameter specifies, a local
Cisco Unified Communications Manager stops routing the call. (The call does not get
sent to the next device in the route list).
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.
The following figure shows the effects of using route
patterns with Cisco Analog 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.
Figure 3. Route Plan Summary Diagram for Cisco Analog Access
Gateways
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.
Local route groups and called party transformations
The Local Route Group feature helps reduce the complexity
and maintenance efforts of provisioning in a centralized
Cisco Unified Communications Manager deployment that uses a large number of
locations. The fundamental breakthrough in the Local Route Group feature
comprises decoupling the location of a PSTN gateway from the route patterns
that are used to access the gateway.
The Local Route Group feature provides the ability to reduce
the number of route lists and route patterns that need to be provisioned for
implementations of
Cisco Unified Communications Manager where each of N sites needs to have access to
the local gateways of the other N-1 remote sites. One such scenario occurs with
Tail End Hop Off (TEHO).
Line groups
Line groups contain one or more directory numbers. A
distribution algorithm, such as Top Down, Circular, Longest Idle Time, or
Broadcast, associates 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 designates one that is not serving any call.
An available member designates one that is serving an active call
but can accept a new call(s).
A busy member cannot accept any calls.
A directory number may belong to more than one line group.
Hunt lists
Hunt lists comprise ordered groupings of line groups. A line
group may belong to more than one hunt list. Hunt pilots associate with hunt
lists. A hunt list may associate with more than one hunt pilot.
Note
Configuration of hunt lists and route lists occurs separately. if an
existing route/hunt list has a line group as a member,
Cisco Unified Communications Manager migrates the route/hunt list to a hunt list.
Note
TOD settings comes into effect when the lines are included in a hunt
list. The settings only apply to the hunt pilot and not to the lines within
that hunt list.
Hunt pilots
Hunt pilots comprise sets of digits. They comprise lists of
route patterns that are used for hunting. A hunt pilot can specify a partition,
numbering plan, route filter, and hunt forward settings. A hunt pilot must
specify a hunt list.
Note
Configuration of hunt pilots and route patterns occurs separately.
If an existing route pattern/hunt pilot associates with a hunt list,
Cisco Unified Communications Manager migrates the route pattern/hunt pilot to a
hunt pilot.
Note
TOD settings comes into effect when the lines are included in a hunt
list. The settings only apply to the hunt pilot and not to the lines within
that hunt list.
Call coverage
The Call Coverage feature comprises the following
Cisco Unified Communications Manager capabilities:
Forwarding provides separate configuration based on whether the
call originator is an internal user or an external user. See the
Internal and external calls.
The concept of hunting differs from that of call forwarding.
Hunting allows
Cisco Unified Communications Manager to extend a call to one or more lists of
numbers, where each such list can specify a hunting order that is chosen from a
fixed set of algorithms. When a call extends to a hunt party from these lists
and the party fails to answer or is busy, hunting resumes with the next hunt
party. (The next hunt party varies depending on the current hunt algorithm.)
Hunting thus ignores the Call Forward No Answer (CFNA), Call Forward Busy
(CFB), or Call Forward All (CFA) settings for the attempted party.
Call forwarding allows detailed control as to how to extend
(divert and redirect represent equivalent terms for extend) a call when a
called party fails to answer or is busy and hunting is not taking place. For
example, if the CFNA setting for a line is set to a hunt-pilot number, a call
to that line that is not answered diverts to the hunt-pilot number and thus
begins hunting.
Cisco Unified Communications Manager offers the ability to redirect a call
when hunting fails (that is, when hunting terminates without any hunt party
answering, due either to exhausting the list of hunt numbers or to timing out).
If used, this final redirection comprises a Call Forwarding action. Therefore,
the Hunt Pilot Configuration window includes Call Forwarding configuration
concepts that are similar to those found on the Directory Number Configuration
window.
Although hunting differs from forwarding, hunting often
originates as a call that gets forwarded to a hunt-pilot number. The call
coverage feature extends hunting to allow final forwarding after hunting either
exhausts or times out.
A typical call that invokes hunting can include the
following phases:
A call extends to the original called party.
The call forwards to hunting (for example, due to the Call Forward
All [CFA], CFNA, or CFB setting for the original called line).
The call hunts through provisioned hunt groups according to
provisioned algorithms for each group. Hunting either succeeds (if a hunt party
answers), exhausts (if all hunt parties are attempted, but none answer), or
times out (if the time specified in the Maximum Hunt Timer runs out before all
parties are attempted, and none of the parties that were attempted answer).
For the purpose of this example, we assume that hunting does not
succeed.
If some form of final forwarding is configured, the call forwards
to a next destination; otherwise, the call gets released.
Maximum hunt timer
The Maximum Hunt Timer field on the Hunt Pilot Configuration
window allows the administrator to enter a value (in seconds) to limit the time
for hunting through a hunt list. After the specified time lapses, if hunting
has not succeeded, the call gets forwarded to a voice-messaging system, a
specific dialed number, or some personal treatment (if configured), or the call
gets released.
finalCalledPartyNumber field service parameter
This service parameter for the Cisco CallManager service
allows you to specify either the line group directory number (DN) that picks up
a call to a hunt pilot number or the hunt pilot number as the final called
party number in the Call Detail Record (CDR).
Internal and external calls
Forwarding provides separate configuration based on whether
the originator of a call is an internal user or an external user. This
distinction applies to Call Forward Busy (CFB), Call Forward No Answer (CFNA),
and Call Forward No Coverage (CFNC) cases.
Personal preferences
Hunting supports the capability to provide a final
forwarding treatment to voice-messaging system, a specific dialed number, or
some personal treatment (based on the original called party) when hunting
either exhausts or times out. The capability to provide separate final
forwarding treatment based on whether the call was internal or external also
exists. Hunting supports a separate, configurable maximum hunt timer for each
hunt-pilot number.
In the Hunt Pilot configuration settings, Use Personal
Preferences, Destination fields are available to enable the Call Forward No
Coverage (CFNC) settings for the original called number that forwarded the call
to the hunt pilot.
Log out of hunt groups
The Log Out of Hunt Groups feature allows users of phones
that are running SCCP and phones that are running SIP to log out their phones
from receiving calls that get routed to directory numbers that belong to line
groups to which the phone lines are associated.
Regardless of the phone status, the phone rings normally for
incoming calls that are not calls to the line group(s) that are associated with
the phone.
The phone provides a visual status of the login state, so
the user can determine by looking at the phone whether they are logged in to
their line group(s).
System administrators can configure phones to be
automatically logged into hunt groups by using the Logged Into Hunt Group check
box on the Phone Configuration window in
Cisco Unified Communications Manager Administration. By default, this check box
gets checked for all phones. Users log in and out of hunt groups by using the
HLog softkey (see the
Log out of hunt groups softkey).
Log Out of Hunt Groups has the following limitations for
phones that are running SIP:
When a phone that is running SIP (7906, 7911, 7941, 7961, 7970,
and 7971) is logged into hunt groups, and Call Forward All is activated, the
call gets presented to the phone that is running SIP.
When 7940 and 7960 phones that are running SIP are logged into
hunt groups, and Call Forward All is activated, the phone will get skipped and
the next phone in the line group will be rung.
7940 and 7960 phones that are running SIP and third-party phones
that are running SIP can be logged into/out of hunt groups by using the Phone
Configuration window, but no softkey support exists.
7940 and 7960 phones that are running SIP and third-party phones
that are running SIP will not show
"Logged out of hunt groups" on the status line.
7940 and 7960 phones that are running SIP and third-party phones
that are running SIP will not play the hunt group logoff notification tone
regardless of whether the tone is configured.
Cisco Unified Communications Manager provides the HLog softkey that allows
a phone user to log a phone out of all line groups to which the phone directory
numbers belong. The user uses the HLog softkey to toggle between logon and
logoff. After the feature is enabled (logoff) on a phone, calls that come into
line groups that are associated with this phone skip this phone and go directly
to the next line in the hunt list.
Because the Log Out of Hunt Groups feature is device-based,
when the user enables the feature by pressing the HLog softkey, the phone gets
logged off from all associated line groups. If a phone has directory numbers
that belong to multiple line groups, pressing the HLog softkey logs the phone
out of all associated line groups. The default phone state specifies logon.
The HLog softkey does not get added to any standard softkey
template, but the HLog softkey displays as a selectable softkey in the
Connected, Off Hook, and On Hook states in the
Cisco Unified Communications Manager Administration Softkey Layout Configuration
window for a new softkey template. The HLog softkey displays on the phone when
the phone is in the Connected, Off Hook, and On Hook states if the
administrator adds the HLog softkey to the softkey template that the phone
uses. If necessary, the softkey label gets translated to a different language.
A prompt status message displays the status of the feature
when the softkey is pressed to log off, if the new softkey is selected in the
Softkey Template that the device is currently using. If necessary, the prompt
status message gets translated to a different language.
See the
Cisco Unified Communications Manager Administration Guide for the details of
configuring softkey templates in
Cisco Unified Communications Manager Administration.
Hunt group logoff notification service parameter
The Hunt Group Logoff Notification service parameter in the
Clusterwide Parameters (Device - Phone) section of the Service Parameters
Configuration window for the Cisco CallManager service provides the option to
turn audible ring tones on or off when calls that come in to a line group
arrive at the phone and the current status of the phone is logoff. The default
value specifies None, which causes the phone not to ring.
Non-shared-line operation
If a phone is logged out of a line group and an extension on
the phone is not shared, the line group does not ring that directory number in
the line group. When the line group would normally offer the call to the
directory number, call processing skips the directory number and acts as if the
directory number does not belong to the line group.
Shared-line operation
Because the Log Out of Hunt Group feature is device-based,
when a user logs a phone out, the feature affects only the logged-out phone.
Calls to a line group that contains a shared-line directory number (DN) behave
as follows:
The DN does not ring if all phones that share that DN are logged
out.
The DN does ring if one or more phone that is sharing the DN is
logged in.
The audible ring on a phone that is logged out gets turned off by
default.
Cisco Unified Communications Manager provides a system parameter that can be set,
so a different ring tone plays when a call comes in to a logged-off hunt group
member.
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 Unified Communications Manager 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 Unified Communications Manager chooses the route pattern on the basis of the
order in which the partitions are listed in the calling search space. (Cisco Unified Communications Manager 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 Unified Communications Manager 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 Unified Communications Manager delivers the call to the device that is
assigned the routing pattern 89XX.
Use wildcard character in route patterns
Using the @ wildcard character in a route pattern provides a
single route pattern to match all National Numbering Plan 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
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.
Translation patterns
Cisco Unified Communications Manager uses translation patterns to determine
how to route a call after it is placed. Configuring translation patterns allows
Cisco Unified Communications Manager to manipulate calling and called digits as
appropriate. During digit analysis when
Cisco Unified Communications Manager identifies that a pattern match has occurred,
Cisco Unified Communications Manager uses the calling search space that is
configured for the translation pattern to perform the subsequent match.
Because
Cisco Unified Communications Manager supports local route groups, calling party
normalization, and the international escape character +, which allow you to
globalize, route, and localize calling party numbers, you can configure
translation patterns as urgent or non-urgent to ensure that
Cisco Unified Communications Manager does not route the call before it should be
routed.
For example, if a caller in the 408 area code dials
95551212, this number gets globalized to +14085551212 through the use of
translation patterns; that is, digit analysis does a pattern match for that
string to determine where to route the call. In this example, a translation
pattern takes 9.[2-9]XXXXXX, translates that string to +1408XXXXXXX, and then
maps that value to a calling search space that contains the globalized
patterns. This example works as long as you do not use variable length dialing,
as is the case with international calls. If you want to route an international
call, you need a translation pattern for 9011.! that disregards the predot and
adds the prefix +. If you configure the translation pattern as urgent priority,
9011! matches with the first digit after the 9011 and
Cisco Unified Communications Manager attempts to route the call without waiting to
match more digits. As a result, international and any other variable length
calls do not route correctly.
Because you can configure translation patterns as non-urgent
in
Cisco Unified Communications Manager, you can configure similar translation
patterns in the same partition and ensure that digit analysis can accurately
match the patterns. Even if digit analysis identifies a match with a
translation pattern,
Cisco Unified Communications Manager attempts to match more digits in other
translation patterns if you configure the translation pattern as non-urgent.
Tip
To route international and variable length calls correctly, make
sure that you configure the translation patterns as non-urgent.
In
Cisco Unified Communications Manager Administration, you can configure any
translation pattern as urgent priority or non-urgent priority. The Urgent
Priority check box displays in the Translation Pattern Configuration
(Call Routing > Translation
Pattern) and Intercom Translation Pattern
Configuration (Call
Routing > Intercom > Intercom
Translation Pattern) windows. If you do not check
this check box and if the dial plan contains overlapping patterns,
Cisco Unified Communications Manager does not route the call until the interdigit
timer expires (even if it is possible to dial a sequence of digits to choose a
current match). To interrupt interdigit timing when
Cisco Unified Communications Manager must route a call immediately, check this
check box.
After you install or upgrade
Cisco Unified Communications Manager, the Urgent Priority check box in translation
patterns displays as checked and enabled. Update your translation patterns, if
necessary, to accommodate your dial plan.
Static digit analysis
Static digit analysis (DA) ensures that whether a phone is
registered or not, the device remains in the DA table, and the directory number
intercepts the call.
Configuration Tip
Tip
Cisco Unified Communications Manager Assistant does not use translation patterns for failover.
Instead, set up Call Forward No Answer (CFNA) with the data that was in the
translation pattern for all Unified CM Assistant failed route points, and these
route points must be removed.
The digit analysis process builds a static digit analysis
engine with the patterns that are configured in the database during system
initialization. This digit analysis engine reduces the propagation of patterns
within a cluster of
Cisco Unified Communications Managers and makes
Cisco Unified Communications Manager more scalable.
In previous releases, the individual device control process
read pattern information from the database and dynamically registered the
patterns to the digit analysis process to build its digit analysis engine. Each
pattern had a mapping to its control process ID in the digit analysis engine.
The control process ID of a pattern got changed dynamically if its associated
device was reset or if a
Cisco Unified Communications Manager server restarted. If a change to the control
process ID took place, the digit analysis engine had to be changed dynamically,
and its contents required propagation to other
Cisco Unified Communications Manager servers. During call processing, the digit
analysis engine returned the control process ID of a matched pattern.
The digit analysis process reads the pattern information
directly from the database to build the static digit analysis engine during
Cisco Unified Communications Manager initialization. With the static digit analysis
engine, each pattern has a mapping to its callable endpoint name, which is a
NumPlanPkID of the pattern in the database, a unique identifier to a configured
pattern in
Cisco Unified Communications Manager. The static digit analysis engine no longer
holds the control process ID of a pattern.
Static digit analysis integrates with the changes to the
device manager to support all existing functions and features. The device
manager includes a table where a NumPlanPkID shows a one-to-one mapping to the
control process ID of a pattern. When processing a call, digit analysis asks
the device manager to get the control process ID for a matched pattern.
Feature Description
Cisco Unified Communications Manager includes these pattern types: Call
Park, Call Forward, Meet-Me Conference, Device, Translation, Call Pickup Group,
Route, and Message Waiting. The Device, Translation, and Route pattern types
represent static patterns. The digit analysis process reads these patterns
directly and inserts them into the static digit analysis engine during the
initialization of a
Cisco Unified Communications Manager. Other pattern types (Call Park, Call Forward,
Meet-Me Conference, Call Pickup Group, and Message Waiting), which are
intercept patterns, remain dynamic patterns. Their individual control process
reads the pattern information from the database and then asks the digit
analysis process to insert the pattern into the static digit analysis engine
via registration messages.
All static patterns remain unchanged until their records are
changed in the database. Static patterns do not require propagation because the
database change notification is broadcast to the servers within a cluster.
Dynamic patterns still use the existing propagating and updating mechanism to
update the static digit analysis engines.
Regardless of its pattern type, each static pattern in the
static digit analysis engine has a mapping to its PkID in the NumPlan table in
the database. When a device registers its patterns to the device manager, the
same PkID gets saved and mapped to its control process ID in the device
manager. A new interface between the digit analysis and device manager
retrieves the control process ID when a matched pattern is found in the static
digit analysis engine during call processing.
Caveat 1
A potential loss of change notification exists in the
current
Cisco Unified Communications Manager release. This loss could cause a device that
is registered with
Cisco Unified Communications Manager to become unreachable by other devices. The
following paragraphs provide troubleshooting for this potential problem.
The most common cause for this problem occurs when the DN
that is assigned to the device belongs to a partition that is not contained in
the calling search space of other devices. If the calling search space of other
devices does contain the partition for that DN, other reasons may apply. For
example, the DN changed only for that device, and the change notification from
the database to
Cisco Unified Communications Manager was lost. Resetting the device may not resolve
the problem.
To resolve this problem, remove the DN and add the DN to the
system again. Remove the DN from its device on the Directory Number
Configuration window and on the Route Plan Report window. After you remove the
DN, add it back in with the same partition, pattern, and other configuration
information. The process should resolve the problem after you add the new DN to
Cisco Unified Communications Manager again.
The same workaround applies to route patterns and
translation patterns if similar problems exist.
Tip
Be sure to document all configurations before removing the patterns.
Caveat 2
Static digit analysis disables the configuration of several
applications. These applications rely on the provision of duplicate patterns in
the same calling search space. For example, the CTI application may be pattern
5000 in partition A, and a particular phone may be pattern 5000 in partition B.
In previous releases, if the CTI route point is down, the phone will ring. With
static digit analysis, however, the caller receives a busy tone. This
limitation implies that the application failure does not get handled.
Administrators would normally use Call Forward No Answer and
Call Forward on failure to handle application failure, but when the pattern on
the CTI route point is 5XXX, you cannot configure a forward destination of
5XXX. To resolve this limitation, you can now perform configuration of X
characters in Call Forward destinations.
The following example demonstrates the functionality of
digit analysis for the
Cisco Unified Communications Manager Assistant application.
Cisco Unified Communications Manager Assistant Example with Static Digit
Analysis
You must make the following modification: configure 1xxx as
a CFNA mask and CSS-E as a CFNA calling search space for the CTI route point to
handle the CTI route point failure case.
When static digit analysis gets used, the following
processing takes place:
If the CTI route point (RP) is up, 1000/IPMA:EveryOne calls 1001.
The call routes through CTI route point IPMA/1XXX. (Routing does not change
from previous releases.)
If the CTI route point is down, 1000/IPMA:EveryOne calls 1001. The
call goes to the CTI route point, and its CFNA is triggered. The forwarding
feature routes the call through the translation pattern Everyone/1xxx, and the
call reaches Manager/1001 after translation.
Without configuring the CFNA in the CTI route point, the
translation pattern never gets matched, and the
Cisco Unified Communications Manager Assistant application fails.
Calling party normalization
In line with E.164 standards, calling party normalization,
which adds the support of international escape character, +, to
Cisco Unified Communications Manager, enhances the dialing capabilities of some
phones and improves call back functionality when a call is routed to multiple
geographical locations; that is, the feature ensures that the called party can
return a call without having to modify the directory number in the call log
directories on the phone. Additionally, calling party normalization allows you
to globalize and localize phone numbers, so the appropriate calling number
presentation displays on the phone.
Tip
Configuring calling party normalization alleviates issues with toll
bypass where the call is routed to multiple locations over the IP WAN. In
addition, it allows
Cisco Unified Communications Manager to distinguish the origin of the call to
globalize or localize the calling party number for the phone user.
Configuring the international escape character, +, in
Cisco Unified Communications Manager Administration allows your phone users to
place calls without having to remember and enter the international direct
dialing prefix/international escape code that is associated with the called
party. Depending on the phone model, for example, dual-mode phones, your phone
users can dial + on the keypad of the phone. In other cases, the phone user can
return calls by accessing the call log directory entries that contain +. In
addition, using the international escape character allows you to support
globalization of calling party numbers, which is part of the calling party
normalization feature; for information on the calling party normalization
feature, see the
Cisco Unified Communications Manager Features and Services Guide.
The international escape character, +, signifies the
international access code in a complete E.164 number format. For example, NANP
numbers have an E.164 global format in the format +1 214 555 1234. The + is a
leading character that gets replaced by service providers in different
countries with the international access code to achieve global dial plans.
In cases where you define a pattern with a dialable + digit
in
Cisco Unified Communications Manager Administration, a plus sign preceded by a
backslash, that is, \+, indicates that you want to configure the international
escape character +. In other cases in
Cisco Unified Communications Manager Administration, for example, in prefix or mask
fields, you can enter + to indicate the international escape character.
See the following sections for more information on the
international escape character, +:
Configuring \+ for the International Escape Character +
To configure the international escape character, +, for
patterns and directory numbers, you configure \+ in the windows in the
following table:
Table 3 Entering \+ in
Cisco Unified Communications Manager Administration
Configuration Window
Fields that Support Entering \+ for International Escape
Character
Route Pattern, Hunt Pilot, and Translation Pattern
Route Pattern, Hunt Pilot, and Translation Pattern
Directory Number
Directory Number
Intercom Translation Pattern
Intercom Translation Pattern
Calling Party Transformation
Pattern
Called Party Transformation
Pattern
Entering + in the windows in the previous table does not
configure the international escape character; instead, entering the + in the
pattern fields means that the system should match one or more of the previous
characters during digit analysis. Consider the following information for
configuring the international escape character in the windows in the previous
table:
To configure the
international escape character for supported patterns, make sure that you enter
\+ in the pattern or Directory Number field.
For all patterns in the
previous table except for the directory number, you can configure the
international escape character, \+, at the beginning, in the middle, or at the
end of a pattern. For example, you can configure \+91! or 0\+23! in the pattern
fields.
For directory numbers, you can configure the international escape
character, \+, at the beginning of the number only.
You can configure \+ as a
dialable character and a + wildcard within a single pattern; for example, you
can configure a pattern like 1234\+56+, where \+ equals the dialable character
and + serves as the wildcard.
You can configure multiple
international escape characters \+ in a single pattern; for example, you can
configure a pattern like 147\+56\+89\+.
Tip
Meet-Me patterns, Call Park (and related call park features; for
example, Directed Call Park) patterns, and Call Pickup patterns do not support
the international escape character, +, so you cannot enter \+ in the pattern
fields that are configured for these features.
Configuring + for the International Escape Character
The following table provides the configuration windows and
fields where you can enter + to indicate the international escape character +.
Table 4 Configuring + for the International Escape Character in
Cisco Unified Communications Manager Administration
Configuration Window
Fields that Support Entering + for International Escape
Character
Device Pool
Incoming Calling Party Settings (Prefix fields for Unknown,
Subscriber, International Number, National Number)
Incoming Called Party Settings (Prefix fields for Unknown,
Subscriber, International Number, National Number)
Service Parameter
all Incoming Calling Party prefix service parameters and
Incoming Called Party service parameters for H.323
Route Pattern, Hunt Pilot, Intercom Translation Pattern, and
Translation Pattern
Calling Party Transform Mask, Called Party Transform Mask, and
Prefix Digits (Outgoing Calls)
Directory Number
External Phone Number Mask and all Call Forwarding fields
Calling Party Transformation
Calling Party Transform Mask and Prefix Digits (Outgoing
Calls)
Called Party Transformation
Called Party Transform Mask and Prefix Digits
Voice Mail Port and Voice Mail Port Wizard
External Number Mask
Message Waiting
Message Waiting Number
Voice Mail Pilot
Voice Mail Pilot Number
Gateway
Incoming Calling Party Settings (Prefix fields for Unknown,
Subscriber, International Number, National Number)
Incoming Called Party Settings (Prefix fields for Unknown,
Subscriber, International Number, National Number)-H.323 gateways
Caller ID DN, and Prefix DN
Tip
MGCP gateways support sending the international
escape character + ; H.323 gateways do not support the +, so the gateway strips
the + when a calling or called party offers it to the gateway.
Trunk
Incoming Calling Party Settings (Prefix fields for Unknown,
Subscriber, International Number, National Number)
Incoming Called Party Settings (Prefix fields for Unknown,
Subscriber, International Number, National Number)-H.323 trunks
Caller ID DN and Prefix DN
Speed Dial and Abbreviated Dial
Number (allows the international escape character, +, to
display as part of the speed dial number on the phone)
Gateways and Trunks that Support International Escape Character
+
SIP and MGCP gateways can support sending the international
escape character, +, for calls. H.323 gateways do not support the +. QSIG
trunks do not attempt to send the +, but SIP trunks can support sending the +.
For outgoing calls through a gateway that supports +,
Cisco Unified Communications Manager can send the + with the dialed digits to the gateway. For
outgoing calls through a gateway that does not support +, the gateway strips
the + when
Cisco Unified Communications Manager sends the call information to the gateway.
When + is not supported but the global calling party number
includes +, configure the called party transformations and route patterns to
send the outdial digits in a format that the device supports.
Tip
If you want to do so, you can configure the Strip + on Outbound
Calls service parameter, which supports the Cisco CallManager service. This
parameter determines whether
Cisco Unified Communications Manager strips the international escape character, +,
from the calling and called parties for outgoing calls through MGCP gateways
and SIP trunks. If your network or far-end gateway does not recognize the + as
a digit, set this parameter to False; if you set this parameter to True and the
+ is not supported in network or by the receiving gateway, calls that use + may
drop. Ensure that calls over QSIG trunks do not utilize + because QSIG does not
send the +. This parameter does not impact H.323 outbound calls because H.323
gateways unconditionally strip the + when they route outbound calls.
If you set the Strip + on Outbound Calls service parameter to True,
Cisco Unified Communications Manager strips the + for the calling and called
parties for all outgoing calls through all MGCP gateways and SIP trunks. To
ensure that
Cisco Unified Communications Manager does not strip the + for outgoing calls
through particular MGCP gateways and SIP trunks, configure the calling party
and called party transformation patterns for outgoing gateways to include the +
prefix for international calls.
The H.323 protocol does not support the international escape
character, +. To ensure that correct prefixes, including the international
escape character, +, get applied for inbound calls over H.323 gateways/trunks,
you must configure the incoming called party settings in the service parameter,
device pool, H.323 gateway, or H.323 trunk windows; that is, configuring the
incoming called party settings ensures that when a inbound call comes from a
H.323 gateway or trunk,
Cisco Unified Communications Manager transforms the called party number back to the value that was
originally sent over the trunk/gateway.
For example, to ensure that the correct DN patterns get used
with SAF/call control discovery for inbound calls over H.323 gateways/trunks,
you must configure the incoming called party settings in the service parameter,
device pool, or H.323 (non-gatekeeper controlled) trunk window. See the
following example for more information.
A caller places a call to +19721230000 to
Cisco Unified Communications Manager A.
Cisco Unified Communications Manager A receives +19721230000 and transforms the
number to 55519721230000 before sending the call to the H.323 trunk. In this
case, your configuration indicates that the international escape character +
should be stripped and 555 should be prepended for calls of International type.
For this inbound call from the trunk,
Cisco Unified Communications Manager B receives 55519721230000 and transforms the
number back to +19721230000 so that digit analysis can use the value as it was
sent by the caller. In this case, your configuration for the incoming called
party settings indicates that you want 555 to be stripped and +1 to be
prepended to called party numbers of International type.
The service parameters support the Cisco CallManager
service. To configure the service parameters, click Advanced in the Service
Parameter Configuration window for the Cisco CallManager service; then, locate
the H.323 pane for the following parameters:
Incoming Called Party National Number Prefix - H.323
Incoming Called Party International Number Prefix - H.323
Incoming Called Party Subscriber Number Prefix - H.323
Incoming Called Party Unknown Number Prefix - H.323
These service parameters allow you to prefix digits to the
called number based on the Type of Number field for the inbound offered call.
You can also strip a specific number of leading digits before the prefix gets
applied. To prefix and strip digits by configuring these parameter fields, use
the following formula, x:y, where x represents the exact prefix that you want
to add to called number and y represents the number of digits stripped; be
aware that the colon separates the prefix and the number of stripped digits.
For example, enter 91010:6 in the field, which means that you want to strip 6
digits and then add 901010 to the beginning of the called number. In this
example, a national call of 2145551234 becomes 910101234. You can strip up to
24 digits and prefix/add up to than 16 digits.
Phones that Support International Escape Character +
The following
Cisco Unified IP Phones, which run SIP or SCCP unless noted otherwise, can display +
on the phone screen, speed dials, directory numbers, and in call log (Redial,
Missed Calls, and so on) directories on the phone.
7906 and 7911
7921 (SCCP only) and 7931
7941, 7942, 7945
7961, 7965
7970, 7971, 7975
7985 (SCCP only)
The Nokia S60, a dual-mode phone, also supports + dialing
from the keypad on the phone. For example, a caller in the United States calls
an international number in India. If the caller uses a dual-mode phone, the
caller can directly dial + to represent the international number. The caller
may call 0+91802501523 or +918025010523, depending on the outgoing route
pattern settings. Dialing the + on the keypad assumes that the outgoing gateway
can support the +; if the outgoing gateway does not support +, you must
configure the route pattern like \+!, where
Cisco Unified Communications Manager strips the \+ and prefixes 011 to transform the international
number to 011 91 8025010523.
Consider the following information about + and the phone:
If a phone displays the + in a call log directory entry on the
phone, the end user can place a call without having to edit the entry in the
call log directory. If the outgoing gateway does not support the +, configure
the outgoing route pattern so that
Cisco Unified Communications Manager can strip the international escape code and
prefix the international access code to the directory number in the call log
directory.
If you do not configure transformation patterns to localize the
calling party number, a called party may receive an international call that
contains + in the calling party number, for example, 0+494692022002 or
+4940692022002, depending on the configuration of the incoming gateway. If the
called party does not answer the call, the calling party number gets stored
with the + in the call log directories on the phone. The called party can
return the call without having to edit the entry in the call log directory.
A caller can place a call to a speed dial number that is
configured as an E.164 number that contains the +.
Cisco Unified IP Phones 7902, 7905, 7912, 7920, 7940, and 7960 that run SCCP can
receive calls from directory numbers that contain the international escape
character, +, although these phones do not display the + on the phone because
Cisco Unified Communications Manager strips the + before the call completes.
SRST does not work for phones that are running SIP that display
the + in the call alerting pane or the call log directories on the phone;
therefore, phones that are running SIP that display the + cannot register with
SRST-enabled gateways, and calls to the SRST-enabled gateway fail if a
directory number that is used for the call includes the +. SCCP phones that
display the + on the phone can register with SRST.
Wildcards and special characters in route patterns and hunt pilots
Wildcards and special characters in route patterns and hunt
pilots allow a single route pattern or hunt pilot to match a range of numbers
(addresses). Use these wildcards and special characters also to build
instructions that enable the
Cisco Unified Communications Manager to manipulate a number before sending it to an
adjacent system.
The following table describes the wildcards and special
characters that
Cisco Unified Communications Manager supports.
Table 5 Wildcards and Special Characters
Character
Description
Examples
@
The at symbol (@) wildcard matches all National Numbering Plan numbers.
Each route pattern can have only one @ wildcard.
The route pattern 9.@ routes or blocks all numbers that the National Numbering Plan recognizes.
The following route patterns examples show National Numbering Plan 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 Unified Communications Manager access code from the directory number.
Use this special character, with the discard digits
instructions, to strip off the
Cisco Unified Communications Manager 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 Unified Communications Manager access code in a National Numbering Plan 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 National Numbering Plan. The # character after
the last 5 identifies this digit as the last digit in the sequence.
\+
A plus sign preceded by a backslash, that is, \+, indicates
that you want to configure the international escape character +.
Using \+ means that the international escape character + is
used as a dialable digit, not as a wildcard.
The following table lists
Cisco Unified Communications Manager Administration fields that require route
patterns or hunt pilots and shows the valid entries for each field.
Table 6 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 A B C D * # +
Called Party Transform Mask
0 1 2 3 4 5 6 7 8 9 X A B C D * # +
Caller ID DN (Gateways and Trunks)
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 Number)
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 A B C D * # +
Prefix DN (Gateways and Trunks)
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 A B C D - ] + ? ! X * # + . @ \+
Translation Pattern
[ ^ 0 1 2 3 4 5 6 7 8 9 A B C D - ] + ? ! X * # + . @ \+
Hunt Pilot
[ ^ 0 1 2 3 4 5 6 7 8 9 A B C D - ] + ? ! 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.
The following table lists DDIs and describes the effects of
applying each DDI to a dialed number.
Table 7 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 National Numbering Plan portion of the
route pattern, including
Cisco Unified Communications Manager Administration allows you to manipulate the
calling party number and the called party number that
Cisco Unified Communications Manager sends with each call setup message.
Tip
You configure calling and called party transformation patterns to
provide context-sensitive modifications to a calling or called party;
Cisco Unified Communications Manager does not use these patterns for routing calls.
Note
Both calling party transformations and called party transformations
can be used with the
Cisco Intercompany Media Engine (Cisco IME). See the
Cisco Intercompany Media Engine Installation and Configuration Guide for
details.
Calling party transformations settings allow you to
manipulate the appearance of the calling party number for outgoing calls.
Cisco Unified Communications Manager 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)
Calling Party Number Type
Calling Party Numbering Plan
Table 14-8 describes the fields, options, and values that
are used to specify calling party number transformations.
Table 8 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.)
You can set the following Calling Party Transformations
settings for the route group by clicking the members in the Route List Details
panel of the Route List Configuration window:
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.
The external phone number mask can contain up to 24 digits.
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 on route patterns or up to 24
digits on DNs.
Calling Line ID Presentation
Cisco Unified Communications Manager uses calling line ID presentation
(CLIP/CLIR) as a supplementary service to allow or restrict the originating
caller phone number on a call-by-call basis.
Choose whether you want the
Cisco Unified Communications Manager to allow or restrict the display of the
calling party phone number on the called party phone display for this route
pattern.
Choose Default if you do not want to change calling line ID
presentation. Choose Allowed if you want
Cisco Unified Communications Manager to allow the display of the calling number.
Choose Restricted if you want
Cisco Unified Communications Manager to block the display of the calling number.
Calling Name Presentation
Cisco Unified Communications Manager uses calling name presentation
(CNIP/CNIR) as a supplementary service to allow or restrict the originating
caller name on a call-by-call basis.
Choose whether you want the
Cisco Unified Communications Manager to allow or restrict the display of the
calling party name on the called party phone display for this route pattern.
Choose Default if you do not want to change calling name
presentation. Choose Allowed if you want
Cisco Unified Communications Manager to display the calling name information.
Choose Restricted if you want
Cisco Unified Communications Manager to block the display of the calling name
information.
Calling Party Number Type
Choose the format for the number type in calling party
directory numbers.
Cisco Unified Communications Manager sets the calling directory number (DN)
type. Cisco recommends that you do not change the default value unless you have
advanced experience with dialing plans such as NANP or the European dialing
plan. You may need to change the default in Europe because
Cisco Unified Communications Manager does not recognize European national dialing
patterns. You can also change this setting when you are connecting to a PBX
that expects the calling directory number to be encoded to a non-national type
numbering plan.
Choose one of the following options:
Cisco Unified Communications Manager-Use when the
Cisco Unified Communications Manager sets the directory number type.
Unknown-Use when
the dialing plan is unknown.
National-Use when
you are dialing within the dialing plan for your country.
International-Use
when you are dialing outside the dialing plan for your country.
Subscriber-Use
when you are dialing a subscriber by using a shortened subscriber number.
Calling Party Numbering Plan
Choose the format for the numbering plan in calling party
directory numbers.
Cisco Unified Communications Manager sets the calling DN numbering plan.
Cisco recommends that you do not change the default value unless you have
advanced experience with dialing plans such as NANP or the European dialing
plan. You may need to change the default in Europe because
Cisco Unified Communications Manager does not recognize European national dialing
patterns. You can also change this setting when you are connecting to PBXs by
using routing as a non-national type number.
Choose one of the following options:
Cisco Unified Communications Manager-Use when the
Cisco Unified Communications Manager sets the Numbering Plan in the
directory number.
ISDN-Use when you
are dialing outside the dialing plan for your country.
National
Standard-Use when you are dialing within the dialing plan for your country.
Private-Use when
you are dialing within a private network.
Unknown-Use when
the dialing plan is unknown.
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.
Configuration of called party transformations settings that
are used in route lists occurs in the individual route groups that comprise 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)
Called Party Number Type
Called Party Numbering Plan
The following table describes the fields, options, and
values that are used to specify called party number transformations.
Table 9 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.
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 Unified Communications Manager 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 on route patterns or up to 24 digits on DNs.
Called Party Number Type
Choose the format for the number type in called party
directory numbers.
Cisco Unified Communications Manager sets the called directory number (DN) type.
Cisco recommends that you do not change the default value unless you have
advanced experience with dialing plans such as NANP or the European dialing
plan. You may need to change the default in Europe because
Cisco Unified Communications Manager does not recognize European national dialing
patterns. You can also change this setting when you are connecting to a PBX
that expects the called directory number to be encoded to a non-national type
numbering plan.
Choose one of the following options:
Cisco Unified Communications Manager-Use when the
Cisco Unified Communications Manager sets the directory number type.
Unknown-Use when
the dialing plan is unknown.
National-Use when
you are dialing within the dialing plan for your country.
International-Use
when you are dialing outside the dialing plan for your country.
Subscriber-Use
when you are dialing a subscriber by using a shortened subscriber number.
Called Party Numbering Plan
Choose the format for the numbering plan in called party
directory numbers.
Cisco Unified Communications Manager sets the called DN numbering plan. Cisco
recommends that you do not change the default value unless you have advanced
experience with dialing plans such as NANP or the European dialing plan. You
may need to change the default in Europe because
Cisco Unified Communications Manager does not recognize European national dialing
patterns. You can also change this setting when you are connecting to PBXs by
using routing as a non national type number.
Choose one of the following options:
Cisco Unified Communications Manager-Use when the
Cisco Unified Communications Manager sets the Numbering Plan in the directory
number.
ISDN-Use when you
are dialing outside the dialing plan for your country.
National
Standard-Use when you are dialing within the dialing plan for your country.
Private-Use when
you are dialing within a private network.
Cisco Unified Communications Manager provides the following types of caller
identification information:
Calling Line Identification (CLID)-Provides the called party with
the extension or directory number of the calling party on a display.
Calling Name Identification-Provides the called party with the name
of the calling party on a display.
Connected Line Identification-Provides the calling party with the
phone number of the connected party on a display.
Connected Name Identification-Provides the calling party with the
name of the connected party on a display
Cisco Unified Communications Manager provides flexible configuration
options to allow and to restrict the display of the line and name information
for both calling and connected parties.
Calling party presentation and restriction settings
Calling party presentation information controls whether to
display the phone number and name information that
Cisco Unified Communications Manager sends with setup messages for an outgoing call.
Cisco Unified Communications Manager 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 Party 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. You can also
configure the Calling Line ID Presentation field in the Calling Party
Transformation Pattern Configuration window.
Note
Configure Calling Line ID Presentation and Connected Line ID
Presentation, in combination with the Ignore Presentation Indicators (internal
calls only) device-level parameter, to set up call display restrictions.
Together, these settings allow you to selectively present or block calling
and/or connected line display information for each call.
The following example describes how calling line ID
presentation works. When a user makes a call,
Cisco Unified Communications Manager checks whether the dialed number matches a translation
pattern.
Cisco Unified Communications Manager 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 Unified Communications Manager checks and finds a match on a route pattern that is
configured for the dialed number.
Cisco Unified Communications Manager 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 Party 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 Unified Communications Manager 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 windows.
For the gateway, you can only configure calling line ID
presentation for outgoing calls. For incoming calls,
Cisco Unified Communications Manager 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. No settings
exist to control name presentation on the gateway.
The type of device control protocol that handles the call
limits caller name and number information. See Table 14-12 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 the
Display IE Delivery field or Send Calling Name in Facility IE field in the
Gateway Configuration window.
Table 14-10 describes the fields, options, and values that
are used to specify calling party presentations.
Table 10 Calling Party Presentation Settings
Field Name
Description
Calling Party 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.
Restricted: Use
this setting to display
"Private" in the called party phone display and block
the display of the calling party phone number.
Calling Name Presentation (outgoing call)
This field determines whether the name of the calling party
displays on the called party phone display. 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.
Restricted: Use
this setting in the route patterns or translation patterns configuration
displays
"Private" in the called party phone display.
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 Unified Communications Manager system and then goes out to a PBX or the PSTN,
the outgoing call rules apply.
Note
The Calling Party 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 Unified Communications Manager system and then goes out to a PBX or the PSTN,
the outgoing call rules apply.
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 Unified Communications Manager receives with an incoming call.
Cisco Unified Communications Manager 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 phone. Translation Pattern Configuration and Route Pattern Configuration
windows include these two settings. The calling party receives the connected
name information after the call connects to
Cisco Unified Communications Manager and the terminating phone.
The following example describes how connected line ID
works. When
Cisco Unified Communications Manager receives an incoming call, it checks whether a translation
pattern is configured for the incoming number.
Cisco Unified Communications Manager uses the value in the Connected Line ID Presentation field
that 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 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 Unified Communications Manager sends
"allowed" in the CONNECT message, so the connected line can
display on the originating caller 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
windows.
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 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. No settings exist for name presentation on the gateway.
When a call routes through a translation or route pattern
and connected line presentation is allowed, the phone updates the connected
number presentation for the modified number.
To turn off phone display updates so that the phone displays only the dialed digits, set the Cisco CallManager service parameter "Always Display Original Dialed Number" to true. When this service parameter specifies true, the originating phone displays only the dialed digits for the duration of the call.
You can choose if the name for the original dialed number or the number after translation is displayed using the Cisco CallManager service parameter called "Name Display for Original Dialed Number When Translated". The default setting displays the name for the original dialed number before translation. This parameter is not applicable if the "Always Display Original Dialed Number" service parameter is set to false.
This table describes the fields, options, and values that are used
to specify connected party presentations.
Table 11 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.
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 Unified Communications Manager 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, 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. 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 Unified Communications Manager received in protocol messages in the calling
party phone display.
Restricted: Use
this setting to block the connected party name from displaying, and display
"Unknown" in the calling party phone display.
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
phone.
If the call comes into the
Cisco Unified Communications Manager system and then goes out to a PBX or the PSTN,
the outgoing call rules apply.
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 Unified Communications Manager system and then goes out to a PBX or the PSTN,
the outgoing call rules apply.
Note
The gateway has no settings to control name information.
Caller Identification support with device control protocols in Cisco Unified Communications Manager
Cisco Unified Communications Manager 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-12 summarizes which protocols support caller
identification services.
Table 12 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)
supported on FXO incoming ports only
supported on FXO incoming ports only
supported on FXO incoming ports only
supported on FXO incoming ports only
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
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, and message-waiting indicators.
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 Unified Communications Manager 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,
including directory numbers (DN) for phones, route patterns, and translation
patterns. See the
Cisco Unified Communications Manager Administration Guide for more information.