Comparison Report for CUCM120
Table of Contents
The Comparison Report identifies changes of configuration items between two configuration reports.
To generate a comparison report, specify the earlier (base) report and
later (revised/changed) report as input. The base and revised reports
must be generated using the same version of the Report Tool.
This Comparison Report has been generated out of the following base and
changed configuration reports, format settings and Cisco audit logs:
This chapter lists the changes found for each configuration item in the base and revised reports.
The 'Status' column shows the overall comparison result which can be same, not same, not comparable or error.
The 'Records' column shows how many records of each configuration item have been Added, Updated, Deleted or remain the Same.
Within each record, there might be multiple fields that represent
configuration settings that have been affected by an update.
The 'Change Details' column may include one or multiple entries that
contain detailed information about the configuration change. Click on an
entry to navigate to the configuration item that will highlight the
change information in a yellow table. Configuration items in green have
been added, configuration items in red and strikethrough have been
deleted. A red and strikethrough value followed by a green value means
that the value has been updated and the green value has replaced the
value in red.
If Cisco Audit Logs have been provided, the following table lists the Cisco Audit Log entries found between the time of the generation of the base and the revised reports. Each Cisco Audit Log
entry can be linked to a 'detected' change of the configuration item
and list the name of the responsible user, the time of the change and
the client IP address. Cisco Audit Log entries within the configuration item are shown in an orange highlighted box.
Cisco Audit Logs need to be collected using Cisco Real Time
Monitoring Tool (RTMT) from the Cisco UC servers. The logs can be
collected manually (please see user guide of Report Tool) or
automatically by using scheduled jobs on the Cisco server, configured by
RTMT to periodically transfer the Cisco Audit Logs via (S)FTP to an (S)FTP server. Within Report Tool, the path to the folder containing the Cisco Audit Logs
files must be specified before generating the comparison report. In
order to process the log files, the UTC time of the server must be
provided.
If Cisco Audit Logs are not provided, the report will still
contain all configuration changes but without additional auditing
information such as user ID and accurate timestamps. Approximative
timestamps (from the database) will still be available for added and
modified configuration items, but not for deleted items. Therefore, to
improve the accuracy for auditing purposes it is strongly recommended to
collect and provide Cisco Audit Log files when generating comparison reports.
The following table lists the Cisco Audit Log entries found
between the time of the generation of the base to the revised reports.
The 'Detected Change' and 'Detected Config Item' columns contain a link
to the detailed change of each configuration item. 'Detected' columns
are the result of the comparison engine and link to the relevant Cisco Audit Log
entry when matched. Clicking on the link will navigate to the detected
change within the configuration item that is shown in a yellow
highlighted box.
Entries that are marked as 'Possible duplicate of' are caused by
multiple updates to the same configuration item. For these items, the
responsible user and the time of change cannot be clearly determined,
and any change could have been performed by any of the involved users.
If multiple add, delete or update actions have been performed to the
same configuration item within the comparison period, only the last edit
will be associated with the change.
If you see no Cisco Audit Logs listed below, but you think you have provided them, please check the following:
- Cisco Audit Logs are in the specified folder.
- The timestamp of the Cisco Audit Log files is from before the UPLINX comparison algorithm has been started. That means the files were present for the comparison.
- Check the entries and find entries with a timestamp that are
between the time of the generation of the base and the revised reports.
No Cisco Audit Logs loaded. To add userid and time information of changes - please add Cisco Audit Logs before comparing.
This chapter lists the configuration changes detected between the base
and revised reports. These are the 'detected' changes that the UPLINX
comparison algorithm has detected in phase 1 when comparing the base and
the revised reports. The results are the added, updated and deleted
records and added, updated and deleted fields that represent
configuration settings within a record.
If Cisco audit logs are not provided, the report will only contain
'detected' configuration changes. Timestamps are extracted from the
database and will be available for added and modified configuration
items, but not for deleted items. If multiple add or update actions have
been performed to one configuration item between the time of the
generation of the base and the revised reports, only the last update
will be associated with the change. Therefore, to improve accuracy for
auditing purposes it is strongly recommended to collect and provide the
Cisco audit log files when generating comparison reports.
All 'detected' changes found are listed in the summarized table below.
The 'Detected Change' and 'Detected Config Item' columns link to the
detailed change of each configuration item. Clicking on them will
navigate to the 'detected' change within the configuration item, shown
in a yellow highlighted box.
The 'Relevant Cisco Audit Log' column lists the matched Cisco Audit Log
entry or entries. The UPLINX comparison algorithm will try to find
matching Cisco Audit Logs for each 'detected' configuration change in
phase 2 of the UPLINX comparison algorithm. Clicking on the link will
navigate to the Cisco Audit Log within the configuration item, shown in
an orange highlighted box.
The 'Time Source' column can be one of the following values:
- Detected: The time is derived from the database timestamp.
- AuditLog: The time is derived from the matched Cisco Audit Log entry.
- AuditLog-Parent: The time is derived from the matched Cisco Audit
Log entry of the parent of the matched configuration item. For example,
if a setting (field) of a configuration item is changed but the setting
itself has no database timestamp and does not generate a Cisco Audit Log
entry, the timestamp of the main configuration item (record) will be
used.
This chapter contains one sub-chapter for each configuration item with
detected changes between base and revised reports. It shows the
comparison statistics for changes, followed by the detailed changes of
the configuration item.
The 'Status' column shows the overall comparison result which can be same, not same, not comparable or error.
The 'Records' column shows how many records of each configuration item have been Added, Updated, Deleted or remain the Same.
Within each record, there might be multiple 'Fields' that represent
configuration settings that have been affected by an update.
Configuration items in green have been added, configuration items in red
and strikethrough have been deleted. A red and strikethrough value
followed by a green value means that the value has been updated and the
green value has replaced the value in red.
The following Cisco Unified servers are present in the cluster:
No changes.
The following services are present on this server:
No changes.
The Cisco Unified Communications Manager (CUCM) cluster consists of the following servers:
No changes.
A Cisco Unified Communications Manager (CUCM) group specifies a
prioritized list of up to three Cisco Unified Communications Managers
(CUCMs).
The first Cisco Unified Communications Manager in the list serves as
the primary CUCM for that group, and the other members of
the group serve as secondary and tertiary (backup) Cisco Unified
Communications Managers.
Each device pool has one CUCM group assigned to it. When
a device registers, it attempts to connect to the primary (first) Cisco
Unified Communications Manager in the group that is assigned to its
device pool. If the primary CUCM is not available, the device tries to
connect to the next CUCM that is listed in the group, and so on.
Cisco Unified Communications Manager (CUCM) groups provide important features for your system:
-
Redundancy: This feature enables you to designate both primary and backup
Cisco Unified Communications Managers for each group.
- Call processing load balancing: This feature enables you to distribute the
control of devices across multiple Cisco Unified Communications Managers.
No changes.
A Presence Redundancy Group is comprised of two or more IM and Presence
Service nodes from the same cluster and provides both redundancy and
recovery for IM and Presence Service clients and applications.
The following Presence Redundancy Groups are defined:
This table lists the NTP servers that you want the SIP phone to use to get its date and time.
Note: Cisco Unified Communications Manager cannot be configured as Phone NTP References.
Date/Time Groups define time zones for the various devices that are connected to Cisco Unified Communications Manager (CUCM).
Cisco Unified Communications Manager (CUCM) provides a default Date/Time
Group called CMLocal that configures automatically when you install
Cisco Unified Communications Manager (CUCM); however, Cisco recommends
that you configure a group for each local time zone. CMLocal
synchronizes to the active date and time of the operating system on the
Cisco Unified Communications Manager (CUCM) server. After installing
Cisco Unified Communications Manager (CUCM), you can change the settings
for CMLocal as desired. Normally, you adjust the server date/time to
the local time zone date and time.
No changes.
Presence groups control the destinations that presence watchers can monitor.
To configure a presence group, create the group and assign one or more destinations and watchers to the same group.
Note: The system always allows presence requests within the same
presence group. You must also specify the relationships to other
presence groups by using one of the following permissions: Use System
Default: use the Default Inter-Presence Group Subscription service
parameter, Allow Subscription, Disallow Subscription.
No changes.
The Audio Codec Preference settings define the order of audio codec
preference, both for calls within a region and for between regions.
Unified CM has two default Audio Codec Preference lists, one for lossy
regions and another for low-loss regions. These are the Factory Default
lossy, and the Factory Default low loss.
The following Audio Codec Preference lists are configured:
No changes.
Regions specify the bandwidth that is used for audio and video calls within
a region and between existing regions. The audio codec determines the type of
compression and the maximum amount of bandwidth that is used per audio call.
The video call bandwidth comprises the sum of the audio bandwidth and video
bandwidth but does not include overhead.
Cisco Unified Communications Manager (CUCM) allows addition of a maximum of 2000 regions.
No changes.
Device pools define sets of common characteristics for devices. The device pool
structure supports the separation of user and location information. The device
pool now contains only device- and location-related information. The Common
Profile window records all the user-oriented information. Ensure that each device
is associated with a device pool and with a common profile for user-oriented
information.
| Device Pool |
| Name | Device Pool Configuration |
DP_1
| Detected Change ID | 0 | | Detected Change | Updated record 'DP_1' | | Detected Object | Device Pool | | Detected Date (UTC) | 2/29/2024 6:53:44 PM | | Detected Date (Local) | 2/29/2024 7:53:44 PM | | Child ID | 1 | | | Device Pool Settings | | CUCM Group | CMG_All | | Calling Search Space for Auto-registration | CSS_Perth
CSS_1
| Detected Change ID | 1 | | Detected Change | Updated field 'Device Pool Settings::Calling Search Space for Auto-registration' from CSS_Perth to CSS_1 | | Detected Object | Device Pool | | Detected Date (UTC) | 2/29/2024 6:53:44 PM | | Detected Date (Local) | 2/29/2024 7:53:44 PM | | Parent ID | 0 | | | Adjunct CSS | < None > | | Reverted Call Focus Priority | Default | | Intercompany Media Services Enrolled Group | < None > | | MRA Service Domain | < None > | | Roaming Sensitive Settings | | Date/Time Group | CMLocal | | Region | Default | | Media Resource Group List | < None > | | Location | < None > | | Network Locale | < None > | | SRST Reference | Disable | | Connection Monitor Duration | | | Single Button Barge | Default | | Join Across Lines | Default | | Physical Location | < None > | | Device Mobility Group | < None > | | Wireless LAN Profile Group | < None > | | Local Route Group Settings | | Standard Local Route Group | < None > | | Device Mobility Related Information | | Device Mobility Calling Search Space | < None > | | AAR Calling Search Space | < None > | | AAR Group | < None > | | Calling Party Transformation CSS | < None > | | Called Party Transformation CSS | < None > | | Geo Location Configuration | | Geo Location | < None > | | Geo Location Filter | < None > | | Incoming Calling Party Settings | | National Number (Prefix/Strip Digits/CSS) | Default / 0 / < None > | | International Number (Prefix/Strip Digits/CSS) | Default / 0 / < None > | | Unknown Number (Prefix/Strip Digits/CSS) | Default / 0 / < None > | | Subscriber Number (Prefix/Strip Digits/CSS) | Default / 0 / < None > | | Incoming Called Party Settings | | National Number (Prefix/Strip Digits/CSS) | Default / 0 / < None > | | International Number (Prefix/Strip Digits/CSS) | Default / 0 / < None > | | Unknown Number (Prefix/Strip Digits/CSS) | Default / 0 / < None > | | Subscriber Number (Prefix/Strip Digits/CSS) | Default / 0 / < None > | | Caller ID For Calls From This Phone | | Calling Party Transformation CSS | < None > | | Connected Party Settings | | Connected Party Transformation CSS | < None > | | Redirecting Party Settings | | Redirecting Party Transformation CSS | < None > |
|
Device mobility groups support the device mobility feature. Device
mobility groups represent the highest level geographic entities in your
network. Depending upon the network size and scope, your device mobility
groups could represent countries, regions, states or provinces, cities,
or other entities. For example, an enterprise with a worldwide network
might choose device mobility groups that represent individual countries,
whereas an enterprise with a national or regional network might define
device mobility groups that represent states, provinces, or cities.
The Device Mobility Info window specifies the subnets and device pools
that are used for device mobility. When a phone registers with Cisco
Unified Communications Manager, the system compares the IP address of
the device to device mobility subnets that are specified in the Device
Mobility Info window and associated with one of the device pools.
The matching subnet becomes the device's home subnet for the purpose of device mobility.
The following Dynamic Host Configuration Protocol (DHCP) servers are configured:
The following Dynamic Host Configuration Protocol (DHCP) subnets are configured:
The LDAP system object allows to enable LDAP synchronization and to set
up the LDAP server type and the LDAP attribute name for the user ID.
No changes.
Synchronization of Cisco Unified Communications Manager (CUCM) with a
corporate LDAP directory allows reuse of user data stored in the
LDAP directory and allows the corporate LDAP directory to serve as the
central repository for that
information. Cisco Unified Communications Manager (CUCM) has an
integrated database for storing user data and a web interface within
Cisco Unified Communications Manager (CUCM) Administration for creating
and managing user data in that database. When synchronization
is enabled, that local database is still used, but the Cisco Unified
Communications Manager (CUCM) facility to create user accounts becomes
disabled. Management of user accounts is then accomplished through the
interface of the LDAP
directory.
The user account information is imported from the LDAP directory into
the database located on the
Cisco Unified Communications Manager (CUCM) publisher server.
Information that is imported from the LDAP directory may not be changed
by Cisco Unified Communications Manager (CUCM). Additional user
information specific to the Cisco Unified Communications Manager (CUCM)
implementation is managed by
Cisco Unified Communications Manager (CUCM) and stored only within its
local database. For example, device-to-user associations, speed
dials, and user PINs are data that are managed by Cisco Unified
Communications Manager (CUCM), and they do not exist in the corporate
LDAP directory. The user data is then propagated from the Cisco Unified
Communications Manager (CUCM) publisher server to the
subscribers via the built-in database synchronization.
You can make changes to LDAP Directory information and LDAP
Authentication settings only if synchronization from the customer LDAP
directory is enabled in the Cisco Unified Communications Manager
Administration LDAP System.
The LDAP authentication feature enables Cisco Unified Communications Manager (CUCM) to authenticate end user passwords against a
corporate LDAP directory instead of using the embedded database. This authentication is accomplished
with an LDAPv3 connection established between the IMS module within Cisco Unified Communications Manager (CUCM) and a corporate
directory server.
You can make changes to LDAP Directory information and LDAP
Authentication settings only if synchronization from the customer LDAP
directory is enabled in the Cisco Unified Communications Manager
Administration LDAP System.
The following statements describe Cisco Unified Communications Manager (CUCM)'s behavior when authentication is enabled:
- End user passwords are authenticated against the corporate directory.
- Application user passwords are authenticated against the Cisco Unified Communications Manager (CUCM) database.
- End user PINs are authenticated against the Cisco Unified Communications Manager (CUCM) database.
The LDAP filter filters the results of LDAP searches when Cisco DirSync
is in use. LDAP users that match the filter get imported into the Cisco
Unified Communications Manager database, while LDAP users that do not
match the filter do not get imported.
The filter must comply with the regular LDAP search filter standards
specified in RFC 4515. Enclose the filter text within parentheses (). It
is recommended to verify the LDAP search filter against the LDAP
directory-searchbase by using the ldapsearch command.
You apply LDAP filters to LDAP directories. Before you can synchronize
the LDAP directory, you must activate the Cisco DirSync service.
The following LDAP filters are defined:
LDAP Search allows the configuration of LDAP search filters for users and groups.
The single sign on feature allows end users to log into a Windows client
machine on a Windows domain, and to then use certain Cisco Unified
Communications Manager applications without having to sign on again.
No changes.
Cross-Origin Resource Sharing (CORS) is a mechanism to allow code
running in a browser (JavaScript for example) to make requests to a
domain other than the one from where it originated.
The following CORS domains are configured:
Locations are used to implement call admission control in a centralized call-processing
system. Call admission control enables you to regulate audio quality and video
availability by limiting the amount of bandwidth that is available for audio and
video calls over links between the locations.
If you do not use call admission control to limit the audio and video bandwidth on
an IP WAN link, an unlimited number of calls can be active on that link at the
same time. This situation can cause the audio quality of each audio call and the
video quality of each video call to degrade as the link becomes oversubscribed.
In a centralized call-processing system, a single Cisco Unified Communications Manager (CUCM)
cluster provides call processing for all locations on the IP telephony network. The
Cisco Unified Communications Manager (CUCM) cluster usually resides at the main (or central)
location, along with other devices such as phones and gateways. The remote
locations contain additional devices, but no Cisco Unified Communications Manager (CUCM). IP WAN
links connect the remote locations to the main location.
No changes.
The Location Bandwidth Manager Groups set the Location Bandwidth Manager
(LBM) services that each Cisco Callmanager service communicates with.
Each Cisco Callmanager service must communicate with an LBM service to
determine the availability of bandwidth for each call, and to deduct
bandwidth for the duration of each call that is admitted.
The LBM Group Page allows the Cisco Callmanger service to communicate
with selected LBM services, instead of communicating with the local LBM
service.
Location Bandwidth Manager Hub Group configuration enables an LBM
service to participate directly in inter-cluster replication of
configured and dynamic Location Bandwidth data. LBMs assigned an LBM Hub
Group discover each other through their common connections and form a
fully-meshed replication network. Other LBM services in a cluster with
an LBM Hub participate indirectly in inter-cluster replication through
the LBM Hubs in their cluster.
Use the LBM Hub Group Page to configure the LBM Hub service to find a
location in the remote clusters to establish external communication
Physical locations support the Device Mobility feature. Physical
locations provide a means of distinguishing the parameters that relate
to a specific geographical location from other parameters.
For example, a media resources server may serve a specific office or
campus within the enterprise. When a device roams to another office or
campus and reregisters with Cisco Unified Communications Manager, you
want to have the media resources server at the roaming location serve
the device. By defining the physical location according to availability
of media services, you can assure efficient and cost-effective
reassignment of services as devices move from one physical location to
another. Depending upon the network structure and allocation of
services, you may define physical locations based upon a city,
enterprise campus, or building.
A survivable remote site telephony (SRST) reference comprises the
gateway that
can provide limited Cisco Unified Communications Manager (CUCM)
functionality when all other Cisco Unified Communications Manager (CUCM)
servers for a device are unreachable.
Typically assigned to
device pools, SRST references determine the gateways where calling devices
search when they attempt to complete a call if Cisco Unified Communications Manager (CUCM) is
unavailable.
No changes.
An MLPP domain specifies the collection of devices and resources that
are associated with an MLPP subscriber. When an MLPP subscriber that
belongs to a particular domain places a precedence call to another MLPP
subscriber that belongs to the same domain, MLPP service can preempt the
existing call that the called MLPP subscriber is on for a higher
precedence call. MLPP service availability does not go across different
domains.
No changes.
Cisco Unified Communications Manager uses Resource Priority Namespace
Network Domains to support Voice over Secured IP (VoSIP) networks by
using Multilevel Precedence and Preemption (MLPP) for Session Initiation
Protocol (SIP) trunks.
MLPP, with configured Resource Priority domains, prioritizes
SIP-signaled resources and enables indications related to precedence and
preempted calls. End users can establish secure calls when the calls
traverse SIP trunks.
Cisco Unified Communications Manager uses Resource Priority Namespace
Lists to configure a default group of Resource Priority Namespace
Network Domains to add to a SIP profile for validating incoming Resource
Priority Namespace Network Domains.
Enterprise parameters provide default settings that apply to all devices
and services in the same cluster. (A cluster comprises a set of Cisco
Unified Communications Managers that share the same database.) When you
install a new Cisco Unified Communications Manager, it uses the
enterprise parameters to set the initial values of its device defaults.
You cannot add or delete enterprise parameters, but you can update existing enterprise parameters.
Please note that not all parameters are listed as not all parameters can be retrieved.
No changes.
The Enterprise Phone Configuration defines parameters that will apply to all phones that support these parameters.
Parameters that you set in this window may also appear in the Common
Phone profile window and the Device Configuration window for various
devices. If you set these same parameters in these other windows too,
the setting that takes precedence is determined in the following order:
1) Device Configuration window settings, 2) Common Phone Profile window
settings, 3) Enterprise Phone Configuration window settings.
If the "Override Common Settings" box is not checked for a given
setting, the corresponding parameter setting does not take effect.
The following Enterprise Phone Configurations are configured:
No changes.
Service parameters provide default settings that apply to all devices
and
services in the same cluster. A cluster comprises a set of Cisco Unified
Communications Managers (CUCMs) that share the same database. When you
install a new Cisco Unified Communications Manager (CUCM), it uses the
enterprise parameters to set the initial values of its device defaults.
If a subscriber parameter is not equal to the publisher parameter, the subscriber value will appear in red.
If the value cannot be retrieved (for example the subscriber server is
not active but configured in the database, the subscriber value appears
as error.
Please note that not all parameters are listed as not all parameters can be retrieved.
No changes.
A certificate is a message that contains the certificate holder name,
the public key, and the digital signature of the certificate authority
that is issuing the certificate. Certificate fields are read only.
The following certificates are installed on CUCM:
No changes.
Cisco Unified Communications Manager Administration groups
security-related settings for a phone type and protocol into security
profiles to allow you to assign a single security profile to multiple
phones. Security-related settings include device security mode, digest
authentication, and some CAPF settings. You apply the configured
settings to a phone when you choose the security profile in the Phone
Configuration window.
Installing Cisco Unified Communications Manager provides a set of
predefined, nonsecure security profiles for auto-registration. To enable
security features for a phone, you must configure a new security
profile for the device type and protocol and apply it to the phone.
No changes.
The SIP Trunk Security Profile object includes security-related settings
such as transport type, device security mode, digest authentication
settings, and authorization settings for incoming SIP messages. Security
profiles must be applied to all SIP trunks that are configured.
No changes.
Cisco Unified Communications Manager Administration groups
security-related settings to allow you to assign a single security
profile to multiple Cisco Unified Mobile Communicator clients.
Security-related settings include device security mode, incoming
transport type, and X.509 subject name. Configuring a Cisco Unified
Mobility Advantage server security profile in Cisco Unified
Communications Manager Administration automatically applies this profile
to all configured Cisco Unified Mobile Communicator clients on that
Cisco Unified Communications Manager.
The following Cisco application servers are known to the cluster:
Geographical location information, or geolocation, describes a physical
position in the world that may correspond to the past, present, or
future location of a person, event, or device.
Cisco Unified Communications Manager Administration allows you to specify a geolocation for every device.
The Request for Comments (RFC) 4119 standard provides the basis for
geolocations. Geolocations use the civic location format that specifies
the following fields: country, A1, A2, A3, A4, A5, A6, PRD, POD, STS,
HNO, HNS, LMK, LOC, FLR, NAM, and PC.
You assign these geolocations to VoIP phones, VoIP gateways, IP trunks, device pools, and enterprise parameters.
You can define geolocation filters that select a subset of fields from
geolocation and associate with VoIP gateways, IP trunks, device pools,
and enterprise parameters
No changes.
Geolocation filters allow selection of specific fields from the 17
geolocation fields for the purpose of creating an identifier from the
selected fields. Geolocation filters get configured manually and are
assigned to devices.
The following logic determines the geolocation filter value:
- For phone device that is in roaming, read the geolocation filter
value from DP in roaming configuration. For phone device that is not in
roaming, read the geolocation filter value from DP in device
configuration.
- For trunk, intercluster trunk, or MGCP port device, read
geolocation filter value from device window. If no value is configured,
read from DP.
- If DP is not configured with a geolocation filter value, use blank value.
- If available filter is blank, call processing uses the value that the Default Geolocation Filter enterprise parameter specifies.
The E911 Messages Configuration page displays the Agreement, Disclaimer,
and Error messages. Optionally, you can edit the E911 messages to be
displayed on off-premises devices.
No changes.
Automated alternate routing (AAR) provides a mechanism to reroute calls
through the PSTN when a call is blocked due to insufficient location
bandwidth. With automated alternate routing, the caller does not need to
hang up and redial the called party.
Cisco Unified Communications Manager (CUCM) automatically attempts to
reroute calls, due to insufficient bandwidth, through the PSTN or other
network only when the AAREnable enterprise parameter is set to true.
Cisco Unified Communications Manager (CUCM) uses the device-based AAR
calling search space, which is assigned to Cisco IP Phone station
devices and gateway devices, when it attempts to route the call to the
gateway device that connects to the PSTN or other network.
Cisco Unified Communications Manager (CUCM) 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 administrator uses dial rules configuration to add and sort the
priority of dialing rules. Dial rules for applications such as Cisco
Unified Communications Manager Assistant automatically strip numbers
from or add numbers to telephone numbers that a user dials. For example,
the dial rules can automatically add the digit 9 in front of a 7-digit
telephone number to provide access to an outside line.
For example, in Cisco Unified Communications Manager Assistant, the
assistant can perform a directory search from the assistant console. The
assistant can drag and drop the directory entry to the My Calls panel
on the assistant console, which invokes a call to the number that is
listed in the entry. The dial rules apply to the number that is listed
in the entry before the call gets made.
Directory lookup rules transform caller identification numbers into
numbers that can be looked up in the directory. Each rule specifies
which numbers to transform based on the beginning digits and length of
the number. For example, you can create a directory lookup rule that
automatically removes the area code and 2 prefix digits from a 10-digit
telephone, which would transform 4085551212 into 51212. If Cisco Unified
Communications Manager Attendant Console can match the number with a
user in the speed-dial entries of the attendant or in the directory, the
attendant console displays the name in the Call Detail window.
SIP dial rules are used to configure SIP phone dial plans and associate them with SIP phones.
Without SIP dial rules, the user must press the Dial softkey unless the
phone supports KPML. SIP dial rules must get associated with a SIP
phone, so the dial plans get sent to the device.
Pattern recognition is concerned only with automating the collection of
user digit input, to be forwarded automatically to Cisco Unified
Communications Manager (CUCM) without requiring inter-digit timeout or
pressing the Dial key. All enforcement of class of service is handled by
the various calling search spaces chosen from within Cisco Unified
Communications Manager (CUCM).
Route filters, along with route patterns/hunt pilots, use dialed-digit
strings to determine how a call is handled. Route filters only apply
when you configure a pattern that contains the at (@) wildcard. When the
route pattern-hunt pilot contains the @ wildcard, Cisco Unified
Communications Manager routes calls according to the numbering plan that
is specified in the Numbering Plan drop-down list box.
Route filters allow you to determine which route patterns/hunt pilots
your users can dial; for example, whether your users can manually choose
a long-distance carrier (by dialing 101 plus a carrier access code).
A route group allows you to designate the order in which gateways and
trunks are selected. It allows you to prioritize a list of gateways and
ports for outgoing trunk selection. A Route Group can be added to any
number of Route Lists.
A route list associates a set of route groups in a specified priority
order. A route list then associates with one or more route patterns and
determines the order in which those route groups are accessed. The order
controls the progress of the search for available devices for outgoing
calls.
A route list can only contain route groups. Each route list should have
at least one route group. Each route group includes at least one
available device, such as a gateway.
A route group allows you to designate the order in which gateways and
trunks are selected. It allows you to prioritize a list of gateways and
ports for outgoing trunk selection.
For example, if you use two long-distance carriers, you could add a
route group, so that long-distance calls to the less expensive carrier
are given priority. Calls route to the more expensive carrier only if
the first trunk is unavailable.
A route list associates a set of route groups oredered by priority. A
route list then associates with one or more route patterns and
determines the order in which those route groups are accessed. The order
controls the progress of the search for available devices for outgoing
calls.
A route list can contain only route groups. Each route list should have
at least one route group. Each route group includes at least one
available device, such as a gateway. Based on device type, Cisco Unified
Communications Manager can choose some, or all, ports as resources in
each route group. Some devices, such as digital access, only allow you
to choose all ports.
No changes.
A route list associates a set of route groups in order of priority. A
route list then associates with one or more route patterns and
determines the order in which those route groups are accessed. The order
controls the progress of the search for available devices for outgoing
calls.
A route list can contain only route groups. Each route list should have
at least one route group. Each route group includes at least one device,
such as a gateway, that is available. Based on device type, Cisco
Unified Communications Manager can choose some, or all, ports as
resources in each route group. Some devices, such as digital access,
only allow you to choose all ports.
A route pattern comprises a string of digits (an address) and a set of associated
digit manipulations that route calls to a route list or a gateway. Route patterns
provide flexibility in network design. They work in conjunction with route filters
and route lists to direct calls to specific devices and to include, exclude, or modify
specific digit patterns.
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.
No changes.
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.
A hunt pilot comprises a string of digits (an address) and a set of
associated digit manipulations that route calls to a hunt list. They
represent the start of the hunt process. Hunt pilots provide flexibility
in network design. They work in conjunction with route filters and hunt
lists to direct calls to specific devices and to include, exclude, or
modify specific digit patterns. A hunt pilot can specify a partition,
numbering plan, route filter, and hunt forward settings. A hunt pilot
must specify a hunt list.
A line group allows you to designate the order in which directory
numbers are chosen. Cisco Unified Communications Manager distributes a
call to idle or available members of a line group based on a call
distribution algorithm and on the Ring No Answer Reversion (RNAR)
Timeout setting.
A Hunt List lists a set of Line groups in a specific order. A hunt list
then associates with one or more hunt pilots and determines the order in
which those line groups are accessed. The order controls the progress
of the search for available directory numbers for incoming calls.
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.
Cisco Unified Communications Manager uses SIP route patterns to route or block both internal and external calls.
The domain name or IP address provides the basis for routing. The
administrator can add domains, IP addresses, and IP network (subnet)
addresses and associate them to SIP trunks (only). This method allows
requests that are destined for these domains to be routed through
particular SIP trunk interfaces.
An access list, which supports Cisco Unified Mobility, specifies a list
that determines the phone numbers that the system can pass or block from
being passed to remote destinations.
A time schedule comprises a group of time periods. Time schedules get
assigned to partitions. Time schedules determine the partitions where
calling devices search when they are attempting to complete a call
during a particular time of day.
A time period comprises a time range that is defined by a start time and
end time. Time periods also specify a repetition interval either as
days of the week or a specified date on the yearly calendar.
Administrators define time periods and then associate the time periods
with time schedules.
No changes.
A partition comprises a logical grouping of directory numbers (DNs) and route
patterns with similar reachability characteristics. Devices that are typically placed
in partitions include DNs and route patterns. These entities associate with DNs
that users dial.
No changes.
A calling search space (CSS) comprises an ordered list of route partitions that are
typically assigned to devices. Calling search spaces determine the partitions that
calling devices search when they are attempting to complete a call.
When a calling search space is assigned to a device, the list of partitions in the
calling search space determine the partitions that the device is allowed to
reach.
| Calling Search Space |
| Name | Description | Route Partitions for this Calling Search Space |
CSS_2
| Detected Change ID | 2 | | Detected Change | Updated record 'CSS_2' | | Detected Object | Calling Search Space | | Detected Date (UTC) | 2/29/2024 6:53:31 PM | | Detected Date (Local) | 2/29/2024 7:53:31 PM | | Child ID | 3 | | | Directory URI
E911
Global Learned E164 Numbers
Global Learned E164 Patterns
Global Learned Enterprise Numbers
Global Learned Enterprise Patterns
P_1
P_2
P_3
P_4
P_5
P_AutoReg
P_Brisbane
P_Brisbane_1
P_Brisbane_2
P_Brisbane_3
P_LoggedOut
P_Perth
P_Perth_1
P_Perth_2
P_Perth_3
P_Sydney
P_Sydney_1
P_Sydney_2
P_Sydney_3
| Detected Change ID | 3 | | Detected Change | Updated record 'CSS_2' | | Detected Object | Calling Search Space | | Detected Date (UTC) | 2/29/2024 6:53:31 PM | | Detected Date (Local) | 2/29/2024 7:53:31 PM | | Parent ID | 2 | |
CSS_3
| Detected Change ID | 4 | | Detected Change | Updated record 'CSS_3' | | Detected Object | Calling Search Space | | Detected Date (UTC) | 2/29/2024 6:53:18 PM | | Detected Date (Local) | 2/29/2024 7:53:18 PM | | Child ID | 5 | | | Directory URI
Global Learned E164 Numbers
Global Learned Enterprise Numbers
Global Learned Enterprise Patterns
P_2
P_3
P_4
P_5
P_AutoReg
P_Brisbane
P_Brisbane_1
P_Brisbane_2
P_Brisbane_3
P_LoggedOut
P_Perth
P_Perth_1
P_Perth_2
P_Perth_3
P_Sydney
P_Sydney_1
P_Sydney_2
P_Sydney_3
Global Learned E164 Patterns
| Detected Change ID | 5 | | Detected Change | Updated record 'CSS_3' | | Detected Object | Calling Search Space | | Detected Date (UTC) | 2/29/2024 6:53:18 PM | | Detected Date (Local) | 2/29/2024 7:53:18 PM | | Parent ID | 4 | |
An intercom partition contains a list of route patterns [directory
number (DN) and route patterns]. Partitions facilitate call routing by
dividing the route plan into logical subsets that are based on
organization, location, and call type.
The following intercom route partitions are configured:
An intercom calling search space comprises an ordered list of intercom
route partitions that are typically assigned to devices. Intercom
calling search spaces determine the partitions that calling devices
search when they are attempting to complete a call.
The following intercom calling search spaces are configured:
The following table lists all intercom lines, both assigned and not assigned to any phones.
Cisco Unified Communications Manager uses intercom translation patterns
to manipulate dialed digits before it routes a call. In some cases, the
system might not use the actual dialed number. In other cases, a public
switched telephone network (PSTN) might not recognize the dialed number
so it needs translatng.
The following intercom translation patterns are configured:
Client
matter codes (CMC) allow an organization to manage call access and
accounting. CMC assists with call accounting and billing for billable
clients by forcing the user to enter a code to specify that the call
relates to a specific client matter. You can assign client matter codes
to customers, students, or other populations for call accounting and
billing purposes. To use the Client Matter Codes feature, users must
enter a client matter code to reach certain dialed numbers.
CMCs are enabled or disabled through route patterns. Multiple Client
Matter Codes can be configured. When a user dials a number that is
routed through a CMC-enabled route pattern, a tone prompts the user for
the client matter code. When the user enters a valid CMC, the call
occurs. If the user enters an invalid code, reorder occurs. The CMC
writes to the CDR, so you
can collect the information by using Cisco Unified Communications
Manager (CUCM) CDR Analysis
and Reporting (CAR), which generates reports for client accounting and
billing.
You can implement CMCs and Forced Authorization Codes (FACs) separately or together. For example, you may
authorize users to place certain classes of calls, such as long distance calls, and
also assign the class of calls to a specific client. If you implement CMC and FAC
together, the user dials a number, enters the user-specific authorization code when prompted to do so, and then enters the
client matter code at the next prompt. CMC and FAC tones sound the same to the
user, so the feature tells the user to enter the authorization code after the first tone
and enter the CMC after the second tone.
The CMC and FAC features work with all Cisco Unified IP Phone models and
MGCP-controlled analog gateways.
When Forced Authorization Codes (FACs) are enabled through route
patterns, users must enter an authorization code to reach the intended
recipient of the call. When a user dials a number that is routed through
a
FAC-enabled route pattern, the system plays a tone that prompts for the
authorization code.
In Cisco Unified Communications Manager (CUCM) Administration, it is possible to configure various levels
of authorization. If the user authorization code does not meet or exceed the level
of authorization that is specified to route the dialed number, the user receives a
reorder tone. If the authorization is accepted, the call occurs.
Enable Emergency Location (ELIN) Support. Do not enable this feature if
you are already using an external emergency calling solution such as
Cisco Emergency Responder.
Related settings:
- Configure Route Patterns to enable the Emergency Location Services
- Translation Pattern has the Emergency Location Service Enabled
- Emergency Location (ELIN) Groups are configured
- Configure Device Pools to use an Emergency Location (ELIN) Group
- Configure Devices to use an Emergency Location (ELIN) Group
No changes.
Emergency Location (ELIN) Groups contain ELIN numbers. These are a pool
of Direct Inward Dial (DID) numbers registered in the Public Safety
Answering Point (PSAP) database that identify the location of the caller
and can be used for an emergency services operator to call back someone
who contacted emergency services. Please make sure you contact your
local PSAP provider to register the number used and location details for
this ELIN Group.
Emergency Location (ELIN) Groups are configured:
The Cisco Unified Communications Manager (CUCM) uses translation patterns to manipulate dialed
digits before it routes a call. In some cases, the system does not use the dialed
number. In other cases, the public switched telephone network (PSTN) does not
recognize the dialed number.
The following list is the condensed version of translation patterns:
The Call Park feature allows you to place a call on hold, so it can be retrieved from
another phone in the Cisco Unified Communications Manager (CUCM) system (for example, a phone in
another office or in a conference room).
If you are on an active call at your phone, you can park the call to a call park extension by pressing the Park softkey or the
Call Park button. Someone on another phone in your system can then dial the call
park extension to retrieve that call.
Directed Call Park allows a user to transfer a call to a specific
user-selected directed call park number. Configure directed call park
numbers in the Cisco Unified Communications Manager Directed Call Park
Configuration window. Configured directed call park numbers exist
cluster wide. You can configure phones that support the directed call
park Busy Lamp Field (BLF) to monitor the busy/idle status of specific
directed call park numbers. Users can also use the BLF to speed dial a
directed call park number.
A user can retrieve a parked call by dialing a configured retrieval
prefix followed by the directed call park number where the call is
parked
Call Pickup allows you to answer a call that comes in on a directory number other
than your own. When you hear an incoming call ringing on another phone, you
can redirect the call to your phone by using this feature.
Cisco Unified IP Phones provide three types of call pickup:
-
Call pickup allows users to pick up incoming calls within their own call
pickup group. The Cisco Unified Communications Manager (CUCM) automatically dials the
appropriate call pickup group number when a user activates this feature on a
phone.
- Group call pickup allows users to pick up incoming calls in another group.
Users must dial the appropriate call pickup group number when they activate
this feature on a phone.
- Other group call pickup allow users to pick up incoming calls
in a group that
is associated with their own group without having to dial (or even know)
the
call pickup group number. When a phone rings in a group that is
associated
with the user's group and the user activates this feature on a phone,
the Cisco Unified Communications Manager (CUCM) automatically searches
for the incoming call in the
associated groups.
This section lists the members of each Call Pickup Group.
This section lists all Directory numbers configured (associated and unassigned directory numbers).
Directory numbers may be associated with devices such as phones, route points, CTI ports, and H.323 clients.
No changes.
Users can use Meet-Me Conferencing to set up or join conferences. A user
that sets up a conference is called the conference controller. A user
that joins a conference is called a participant. Meet-Me conferences
require an allocation of directory numbers. Cisco Unified Communications
Manager (CUCM) Administration provides the Meet-Me conference directory
number range to users, so they can access the feature.
Cisco Unified Communications Manager (CUCM) supports a maximum of 100 simultaneous meet-me
conferences for each Cisco Unified Communications Manager (CUCM) server.
Conference Now feature allows both external and internal callers to join
a conference by dialing a Conference Now IVR Directory Number which is a
centralized conference assistant number. An IVR application guides the
caller to join the conference by playing announcements.
A conference is established using a Meeting Number, which is the same as
the Self-Service User ID. The meeting number can be configured by the
administrator in the End User's page. The Self-Service User ID is
usually the same as the user's primary extension number.
The host (End User) informs of the Meeting Number, Time slot, and
Attendees Access Code to all the participants. The host requires a PIN
to join the conference, but the participants do not require it. If a
participant dials into the meeting before the host, the participant is
placed on Music on Hold (MOH).
After the host enters both Meeting Number and PIN correctly, a
conference bridge is allocated based on the MRGL(Media Resource Group
List) of the host. Participants who join before the start of the meeting
are redirected to the same conference bridge.
The host can set the Attendees Access Code for a secure conference call.
No changes.
The parameters in the Calling Party Transformation Patterns provide
appropriate caller information using the Calling Party Transformation
calling search space on the destination device. Be aware that calls
through transformation patterns are not routable. When this pattern is
matched, the call does not route to any device.
You use calling party transformation patterns with the calling party
normalization feature. 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.
The parameters in the Called Party Transformation Patterns provide
appropriate caller information by using the Called Party Transformation
calling search space on the destination device. Be aware that calls
through transformation patterns are not routable. When this pattern is
matched, the call does not route to any device.
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.
Transformation profiles allow the system to convert the calling and
called party numbers for outgoing calls to a fully qualified +E.164
number format. The system includes the transformed numbers in the voice
call records (VCRs) that Cisco Intercompany Media Engine (Cisco IME)
uses to validate PSTN calls. The number transformation takes place after
normal call routing processing. Cisco Unified Communications Manager
does not use transformation profiles for call routing.
The Mobility Enterprise Feature Configuration defines mobility
enterprise feature access (EFA) numbers. These numbers can then be
associated with mobility profiles for use.
The DID number defines enterprise feature access and supports transfer,
conference, resume, and two-stage dialing from smartphones. Each DID
number must be unique.
The Handoff Mobility Configuration defines a handoff number and/or
partition for dual-mode phones between the Wi-Fi and Global System for
Mobile communication (GSM) or Code Division Multiple Access (CDMA)
networks. The handoff feature requires this number.
Mobility profiles specify profiles that configure Dial-via-Office
Forward (DVO-F) or Dial-via-Office Reverse (DVO-R) settings for a mobile
client. A mobility profile is then assigned to a user or to a group of
users, such as the users in a region or location.
Mobility profiles can associate with a standalone Cisco Unified Mobile
Communicator mobile identity or with a Cisco Unified Mobile
Communicator-enabled dual-mode mobile identity. Standard, single-mode
remote destinations cannot associate with a mobility profile.
Mobility profiles settings can only be changed by administrators: users cannot change the settings in a mobility profile.
The following mobility profiles are defined:
Logical partitioning specifies a call control feature in Cisco Unified
Communications Manager that provides functionality, so communication
between the following pairs of VoIP entities can be controlled:
- A VoIP phone and a VoIP gateway
- A VoIP gateway and another VoIP gateway
- An intercluster trunk and a VoIP phone
- An intercluster trunk and a VoIP gateway
No logical partitioning policy logic exists on endpoints. Be aware that
logical partitioning is required to control such communication, not only
during basic call establishment but also mid-call as a result of
midcall features.
The Cisco Unified Communications Manager basic routing policy constructs
of calling search spaces and partitions are enough to prevent forbidden
basic calls from being established but are not sufficient to prevent
forbidden calls from being created as a result of midcall features. In
Cisco Unified Communications Manager, such midcall features are often
termed Join and Redirect features, because these primitives often get
used internally to affect these features.
Logical partitioning enhances Cisco Unified Communications Manager to
handle such midcall scenarios. Configuration for logical partitioning
remains independent of supplementary features, where the policy checking
gets performed based on devices being joined or redirected to a
supplementary feature.
Cisco Unified Communications Manager supports the external call control
feature, which enables an adjunct route server to make call-routing
decisions for Cisco Unified Communications Manager by using the Cisco
Unified Routing Rules Interface. When you configure external call
control, CUCM issues a route request that contains the calling party and
called party information to the adjunct route server. The adjunct route
server receives the request, applies appropriate business logic, and
returns a route response that instructs Cisco Unified Communications
Manager on how the call should get routed, along with any additional
call treatment that should get applied.
The adjunct route server can instruct Cisco Unified Communications
Manager to allow, divert, or deny the call, modify calling and called
party information, play announcements to callers, reset call history so
adjunct voicemail and IVR servers can properly interpret calling/called
party information, and log reason codes that indicate why calls were
diverted or denied.
Each hosted DN group covers one geophysical location advertising DN
range. Each hosted DN pattern must be unique. Each hosted DN pattern can
only exist in one hosted DN group.
The following hosted DN groups are configured:
Hosted DN patterns are directory number patterns that belong to the local call-control entity.
Hosted DN patterns are directory number pattern ranges for the local
Cisco Unified Communications Manager cluster that you want to advertise
to remote call-control entities. It is published by the CCD advertising
service to the SAF forwarder.
The following Hosted DN patterns are configured:
The Call Control Discovery (CCD) advertising service resides in Cisco
Unified Communications Manager and advertises the PSTN failover
configuration and hosted DN patterns along with the SAF trunk access
information for the local Cisco Unified Communications Manager cluster
to the remote call-control entities that use the SAF network.
You must enable SAF on the trunk in Cisco Unified Communications Manager
Administration and assign SAF-enabled trunks to the CCD advertising and
requesting services. You can configure as many CCD advertising services
as you want. Only one hosted DN group can be associated with one CCD
advertising service.
The Call Control Discovery feature relies on a route partition,
configured in this section. This route partition gets used exclusively
by Call Control Discovery to ensure that all learned patterns get placed
in digit analysis under the route partition. You assign this partition
to the CCD requesting service.
If you want a user to make outbound calls to learned patterns that are
advertised by remote call-control entities, ensure that the calling
search space that you assign to the device contains the route partition
that is assigned to the CCD requesting service.
Call control discovery (CCD) requesting service resides in Cisco Unified
Communications Manager and allows the local Cisco Unified
Communications Manager to listen for advertisements from remote
call-control entities that use the SAF network.
Learned patterns (hosted DN patterns from remote call-control entities)
get inserted into digit analysis on the local Cisco Unified
Communications Manager. It performs load balancing for calls to learned
patterns and handles withdrawals for Cisco Unified Communications
Manager from the SAF network .
Blocked patterns that remote call-control entities send to the local Cisco Unified Communications Manager:
The following table contains all Call Control Discovery feature parameters:
No changes.
Advertised patterns create summarized routing instructions for a range
of enterprise alternate numbers or +E.164 alternate numbers and
replicate that pattern throughout an ILS network such that all clusters
within the ILS network know the pattern. Advertised patterns save you
from having to configure routing information for each alternate number
on an individual basis. Advertised patterns are never used by the local
cluster on which they are configured. They are only used by remote
clusters that learn the pattern through ILS.
The Blocked Learned Pattern Configuration window supports the call
control discovery feature by allowing you to purge and block learned
patterns, for example, learned patterns that you no longer want to use.
Any subsequent notifications with this information gets blocked and
ignored.
To block or purge a pattern, the learned pattern must match all data that is configured.
Learned numbers and learned patterns must be assigned to a partition
which cannot be the NULL partition. Define your own partitions or use
the predefined default partitions. Cisco Unified Communications Manager
comes installed with the following predefined partitions for learned
alternate numbers and number patterns:
- Global Learned Enterprise Numbers
- Global Learned E.164 Numbers
- Global Learned Enterprise Patterns
- Global Learned E.164 Patterns
The following partitions are defined:
No changes.
Global dial plan data that Cisco Unified Communications Manager learns
via ILS is stored in the local database. In addition to replicating
locally configured data, ILS also replicates learned global dial plan
data to the rest of the ILS network so that all data learned by one
cluster is learned by all clusters in the ILS network.
The following numbers have been learned:
Global dial plan data that Cisco Unified Communications Manager learns
via ILS is stored in the local database. In addition to replicating
locally configured data, ILS also replicates learned global dial plan
data to the rest of the ILS network so that all data learned by one
cluster is learned by all clusters in the ILS network.
The following patterns have been learned:
Global dial plan data that Cisco Unified Communications Manager learns
via ILS is stored in the local database. In addition to replicating
locally configured data, ILS also replicates learned global dial plan
data to the rest of the ILS network so that all data learned by one
cluster is learned by all clusters in the ILS network.
The following Directory URIs have been learned:
Cisco Unified Communications Manager allows you to import global dial
plan data from a CSV file into any hub cluster in an ILS network. ILS
replicates the imported global dial plan data throughout the ILS network
allowing you to interoperate Cisco Unified Communications Manager with a
Cisco TelePresence Video Communications Server or a third-party call
control system.
Imported data includes only global dial plan data that is imported
manually into Cisco Unified Communications Manager. Imported global dial
plan data does not include data that was learned through ILS.
The following global dial plan data has been imported:
Cisco Unified Communications Manager allows you to import Directory URIs
from a CSV file into any hub cluster in an ILS network and ILS
replicates the imported data throughout the ILS network allowing you to
interoperate Cisco Unified Communications Manager with a Cisco
TelePresence Video Communications Server or a third-party call control
system.
Imported data includes only data that is imported manually into Cisco
Unified Communications Manager. Imported data does not include data that
was learned through ILS.
The following Directory URIs have been imported:
Cisco Unified Communications Manager allows you to import patterns from a
CSV file into any hub cluster in an ILS network and ILS replicates the
imported data throughout the ILS network allowing you to interoperate
Cisco Unified Communications Manager with a Cisco TelePresence Video
Communications Server or a third-party call control system.
Imported data includes only data that is imported manually into Cisco
Unified Communications Manager. Imported data does not include data that
was learned through ILS.
The following patterns have been imported:
An annunciator, an SCCP device that uses the Cisco Media Streaming
Application service, enables Cisco Unified Communications Manager to
play prerecorded announcements (.wav files) and tones to Cisco Unified
IP Phones and gateways. The annunciator, which works with Cisco
Multilevel Precedence and Preemption (MLPP), enables Cisco Unified
Communications Manager to alert callers as to why the call fails.
Annunciator can also play tones for some transferred calls and some
conferences.
No changes.
The Interactive Voice Response (IVR) device enables Cisco Unified
Communications Manager to play prerecorded feature announcements (.wav
files) to devices such as Cisco Unified IP Phones and Gateways. These
announcements play on devices that use features which require IVR
announcements like Conference Now.
When you add a node, an IVR device is automatically added to that node.
The IVR device remains inactive until the Cisco IP Voice Media Streaming
Application service is activated on that node.
An IVR supports 48 simultaneous callers by default. You can change the
number of IVR callers using the Cisco IP Voice Media Streaming
Application service parameter; however, we recommend that you do not
exceed 48 IVR callers on a node. You can configure the number of callers
for IVR based on expected simultaneous calls to IVR for joining
Conference Now.
No changes.
A conference bridge is a resource that joins multiple participants into a single call. It can accept any
number of connections for a given conference, up to the maximum number of streams allowed for a
single conference on that device. There is a one-to-one correspondence between media streams
connected to a conference and participants connected to the conference. The conference bridge mixes
the streams together and creates a unique output stream for each connected party. The output stream for
a given party is the composite of the streams from all connected parties minus their own input stream.
Some conference bridges mix only the three loudest talkers on the conference and distribute that
composite stream to each participant (minus their own input stream if they are one of the talkers).
Software conference bridges automatically get added when a Cisco Unified
Communications Manager server gets added. You can update software
conference bridges, but you cannot delete them.
A hardware conference bridge has all the capabilities of a software conference bridge. In addition, some
hardware conference bridges can support multiple low bit-rate (LBR) stream types such as G.729, GSM,
or G.723. This capability enables some hardware conference bridges to handle mixed-mode conferences.
In a mixed-mode conference, the hardware conference bridge transcodes G.729, GSM, and G.723
streams into G.711 streams, mixes them, and then encodes the resulting stream into the appropriate
stream type for transmission back to the user. Some hardware conference bridges support only G.711
conferences.
All conference bridges that are under the control of Cisco Unified
Communications Manager
(CUCM) use Skinny Client Control Protocol (SCCP) to communicate with
CUCM.
Cisco Unified Communications Manager allocates a conference bridge from
a conferencing resource that is registered with the (CUCM) cluster.
Both hardware and software conferencing resources can register with
Cisco Unified Communications Manager at the same time, and CUCM can
allocate and use conference bridges from either resource.
Cisco Unified Communications Manager does not distinguish between these
types of conference bridges when it processes a conference allocation
request.
No changes.
A Media Termination Point software device allows Cisco Unified
Communications Manager to relay calls that are routed through SIP or
H.323 endpoints or gateways. You can allocate a media termination point
device because of DTMF or RSVP requirements. When a media termination
point is allocated for RSVP, you can insert it between any type of
endpoint device, including SIP or H.323 devices.
Media termination point, a Cisco software application, is installed on a
server during the software installation process. You must activate and
start the Cisco IP Voice Media Streaming App service on the server on
which you configure the media termination point device.
No changes.
The integrated Music On Hold (MOH) feature allows users to place on-net
and off-net users on hold with music that is streamed from a streaming
source. The Music On Hold feature allows two types of hold:
- End-user hold
- Network hold, which includes transfer hold, conference hold, and call park hold
Music On Hold also supports other scenarios where recorded or live audio is needed.
No changes.
The music on hold server uses the Station Stimulus (Skinny Client)
messaging protocol for communication with Cisco Unified Communications
Manager. A music on hold server registers with the Cisco Unified
Communications Manager as a single device and reports the number of
simplex, unicast audio streams that it can support. The music on hold
server advertises its media type capabilities to the Cisco Unified
Communications Manager as G.711 mu-law and a-law, G.729a, and wideband.
Cisco Unified Communications Manager starts and stops Music On Hold
unicast streams by sending skinny client messages to the music on hold
server.
A music on hold server handles up to 500 simplex, unicast audio streams.
A media resource group includes one or more music on hold servers. A
music on hold server supports 51 audio sources, with one audio source
that is sourced from a fixed device that uses the local computer audio
driver, and the rest sourced from files on the local music on hold
server.
No changes.
The Video on Hold feature is for video contact centres where customers
calling into the video contact centre are able to watch a specific video
after initial consultation with the agent at the contact centre. In
this case, the agent selects the video stream that gets played to the
customer while the customer is on hold.
The media content server is an external device that can store and stream
audio and video content under Unified Communications Manager control
using SIP as the signal protocol.
The Cisco Unified Communications Manager invokes a transcoder on behalf
of endpoint devices when the two devices are using different codecs and
would normally not be able to communicate. When inserted into a call,
the transcoder converts the data streams between the two disparate
codecs to enable communications between them.
The Media Resource Manager (MRM) is responsible for resource
registration and resource reservation of transcoders within a Cisco
Unified Communications Manager cluster. Cisco Unified Communications
Manager simultaneously supports registration of both the Media
Termination Point (MTP) and transcoder and concurrent MTP and transcoder
functionality within a single call.
Media resource group lists specify a list of prioritized media resource groups. An
application can select required media resources from among the available
resources according to the priority order that is defined in the media resource
group list. Media resource group lists, associated with devices, provide
media resource group redundancy.
Media resource groups define logical groupings of media servers. You can
associate a media resource group with a geographical location or a site as desired.
You can also form media resource groups to control the usage of servers or the
type of service (unicast or multicast) that is desired.
Mobile Connect allows users to manage business calls using a single
phone number and pick up in-progress calls on the desktop phone and
cellular phone. Mobile Voice Access is the associated integrated voice
response (IVR) system, which allows users to turn Mobile Connect on or
off and to initiate calls from a cellular phone or other remote phone as
if the call were initiated from the desktop phone.
The Mobile Voice Access window contains settings for localized user IVR prompts.
When you install Cisco Unified Communications Manager, Cisco-provided
announcements and tones are included. The Find and List Announcements
window in Cisco Unified Communications Manager Administration displays
these announcements and tones, used for basic calls, external call
control, or MLPP, depending on the announcement. Cisco Unified
Communications Manager allows you to use the Cisco-provided
announcements as is, insert customized announcement .wav files, assign a
locale for the announcement, change the description for the
announcement, or change the message or tone that you want an
announcement to play.
The following announcements and tones are installed:
No changes.
The optional Cisco Unity (Connection) software, available as part of
Cisco Unified Communications Solutions, provides voice-messaging
capability for users when they are unavailable to answer calls.
This section contains the Cisco Unity voice-mail ports which are setup
as virtual phones for the Cisco for the Cisco Unity (Connection) server.
The Message Waiting Configuration defines a "message waiting on" or
"message waiting off" directory number that a directory-connected based
voice-messaging system uses to determine whether to set or clear a
message waiting indication for a particular Cisco Unified IP Phone.
Voicemail profiles contain the Pilot extension and MWI settings for any
voicemail system and are assigned to phone extensions. The pilot
extension is used to forward a call to the voicemail system and can be
an individual extension or the pilot point of a hunt-list which contains
voicemail extensions.
No changes.
In the SAF Security Profile Configuration window, you configure a SAF
security profile so that a secure connection occurs between the SAF
forwarder and the Cisco Unified Communications Manager. When you
configure a SAF forwarder in the SAF Forwarder Configuration window, you
must choose a SAF security profile to apply to the SAF forwarder.
Cisco Unified Communications Manager uses digest authentication (SHA1) to communicate with the SAF forwarder.
The call control discovery feature leverages the Service Advertisement
Framework (SAF) network service, a proprietary Cisco service, to
facilitate dynamic provisioning of inter-call agent information.
A SAF forwarder, a Cisco router that you configure for Call Control
Discovery/SAF, handles the publishing requests from Cisco Unified
Communications Manager for the call control discovery feature. In
addition, the SAF forwarder handles advertising requests from remote
call-control entities for the Call Control Discovery feature.
The following table contains all EMCC feature parameters:
No changes.
EMCC intercluster service profile allows activation of the Cisco
Extension Mobility Cross Cluster feature, activation of PSTN access and
assigned SIP trunk, and activation of the RSVP agent and assigned SIP
trunk.
No changes.
This section defines the EMCC Remote Clusters. EMCC Remote Clusters are
used to allow users from this home cluster to roam to the remote cluster
as visitors and login with Extension Mobility.
Cluster ID: Ensure that this cluster ID matches the enterprise parameter value of the cluster ID of the other clusters.
Fully Qualified Name: Use the IP address of the remote cluster or a
domain name that can resolve to any node on the remote cluster.
Use the Intercompany Media Engine Server Connection Configuration window
to specify information about the Cisco Intercompany Media Engine (Cisco
IME) server to which Cisco Unified Communications Manager connects.
This information enables Cisco Unified Communications Manager to connect
to the Cisco IME server to initiate VAP messaging. The interface
between servers allows Cisco Unified Communications Manager to publish
its configured direct inward dialing (DID) patterns and to learn new
routes.
After Cisco Unified Communications Manager establishes a connection,
CUCM sends a VAP Register message to the Cisco IME server. This message
contains the username that associates with the application user that the
Application User field specifies. The Cisco IME server checks the
credentials against the configured VAP username and password.
The numbers selected to participate in Cisco Intercompany Media Engine
(Cisco IME) are set by creating enrolled groups and patterns. Enrolled
groups are a collection of enrolled patterns. These patterns define the
set of +E.164 numbers that make and receive Cisco IME calls. Cisco IME
publishes these numbers to the IME distributed cache. By doing so, Cisco
IME makes these numbers available for other enterprises to learn
through Cisco IME. Numbers within your enterprise must also match a
pattern in an enrolled group in order to make Cisco IME calls. You can
create an enrolled group for each of your campuses or sites to
facilitate incremental deployment of Cisco IME, starting with certain
sites or campuses and extending the deployment as usage grows.
After creating the enrolled group, create the enrolled patterns, assign
the patterns to a group, and associate the group with a Cisco IME
service. If you want to disable Cisco IME for certain phones in the
enterprise, you can unassign the enrolled group for those phones from
the Cisco IME service.
Cisco Intercompany Media Engine (Cisco IME) enrolled patterns define the
set of +E.164 numbers that make and receive Cisco IME calls. Cisco IME
publishes these numbers to the IME distributed cache. By doing so, Cisco
IME makes these numbers available for other enterprises to learn
through Cisco IME. The patterns must specify valid direct inward dialing
numbers (DIDs) that the enterprise owns. Numbers within your enterprise
must match a pattern that is found in an enrolled group in order to
make Cisco IME calls.
To eliminate the need for day-to-day provisioning of specific numbers,
as individual phones are added to and removed from the system, you can
add a pattern that represents a large group of numbers for a given site.
The enrolled pattern can include numbers that you have not assigned to a
phone. Numbers that are not associated to a phone cannot be validated.
After you create enrolled patterns, you associate them to an enrolled
group and assign the enrolled group to a Cisco Intercompany Media Engine
service. You can disable or enable Cisco IME from calling certain
phones in the enterprise by disassociating or associating the enrolled
group to the Cisco IME service.
Exclusion groups contain a list of numbers that you want to prevent from
using Cisco Intercompany Media Engine (Cisco IME), including numbers of
analog devices and fax machines. First the exclusion group is created,
then exclusion numbers are created that are then associated with a
particular exclusion group. Finally, you associate the exclusion group
to the Cisco IME service.
Use the Intercompany Media Services Exclusion Number Configuration
window to define numbers, sets of numbers, prefixes, or sets of prefixes
that you do not want to use Cisco Intercompany Media Engine (Cisco
IME), even if these numbers occur within a list of numbers that are
included in the Cisco IME enrolled pattern.
Cisco Intercompany Media Engine (Cisco IME) trust groups contain a list
of domains and prefixes that are trusted (or not trusted) by the Cisco
IME service that associates with the trust group. Cisco Unified
Communications Manager can only place Cisco IME calls to domains or
prefixes that are trusted.
Configuration of trust groups is optional. If you do not create trust groups, Cisco IME trusts all calls by default.
Cisco Intercompany Media Engine (Cisco IME) trust elements specify
prefixes or domains that you want to trust or not trust. You include the
trust elements in a trust group. Cisco Unified Communications Manager
can only place Cisco IME calls to domains or prefixes that are trusted.
You cannot receive Cisco IME calls from a number whose prefix or domain
is specified in an untrusted element.
Use the Intercompany Media Service Configuration window to configure and
activate the Cisco Intercompany Media Engine (Cisco IME) service. To
configure the Cisco IME service in Cisco Unified Communications Manager
Administration, you associate various components that you have already
configured, including trusted groups, enrolled groups, and exclusion
groups. You indicate the Cisco IME server with which you want Cisco
Unified Communications Manager to communicate. Communications between
the Cisco Unified Communications Manager and the Cisco IME servers begin
after you configure and activate the Cisco IME service.
To begin load balancing so that the system work spreads across multiple
Cisco Intercompany Media Engine servers, create more than one Cisco
Intercompany Media Engine service with different Cisco Intercompany
Media Engine servers and move some of the enrolled groups from the old
Cisco Intercompany Media Engine service to the new service.
Cisco Intercompany Media Engine (Cisco IME) E.164 transformations
convert calling numbers and called numbers on both the originating and
terminating (incoming and outgoing) sides to +E.164 format after a PSTN
call terminates. Cisco IME E.164 transformations do not impact call
routing or digit analysis in Cisco Unified Communications Manager. The
transformations allow the following actions to occur:
- Send UploadVCRs to the Cisco Intercompany Media Engine server for unlearned direct inward dialing numbers (DIDs).
- Reroute calls to the Cisco IME trunk if the DID exists in the learned table.
You associate Cisco IME E.164 transformations with a PSTN access trunk.
If the transformation does not yield valid calling and called numbers on
the incoming and outgoing sides of the call, no VCR upload takes place,
and Cisco IME processing stops for that call.
Learned routes specify lists of all +E.164 numbers that the system has
learned through Cisco Intercompany Media Engine (Cisco IME). You can
enable or disable a particular route. You can disable if you are having
problems with a particular route and you need to disable to
troubleshoot.
The following is a list of the Intercompany Media Services learned routes:
Use the Intercompany Media Services Firewall Configuration window to
configure the IP address and port of the ASA mapping service. You need
to configure this information if you have implemented an off-path
deployment model in which normal Internet-facing traffic does not flow
through the same adaptive security appliance (ASA) as the Cisco
Intercompany Media Engine (Cisco IME) traffic.
During an outbound call attempt, the SIP invite message must be routed
to the offpath Cisco IME enabled ASA. Cisco Unified Communications
Manager sends a request to the ASA for a mapping of the global IP/port
of the remote enterprise (found in the Cisco IME learned route) to an
internal IP/port on the Cisco IME enabled ASA. Cisco Unified
Communications Manager then initiates a SIP Invite that routes to this
internal IP/port. The Cisco IME enabled ASA performs NAT, mapping to the
global IP/port of the remote enterprise from the IME learned route. The
offpath Cisco IME enabled ASA proxies this signaling session and
initiates a TLS session to this global IP/port (the Cisco IME enabled
ASA of the remote enterprise).
The following values are configured for the Intercompany Media Services feature parameters.
No changes.
The fallback profile defines several values that the Cisco Unified
Communications Manager uses to fallback Cisco IME calls to the PSTN. The
fallback profile defines the level of quality of service at which Cisco
Unified Communications Manager attempts a mid-call fallback as well as
the fallback number that the Cisco Unified Communications Manager uses
to invoke the PSTN call.
When a user makes a call to a number that is linked to a fallback
profile, the Cisco Unified Communications Manager of the calling party
receives a fallback directory number that is configured on the Cisco
Unified Communications Manager of the called party. The Cisco Unified
Communications Manager uses the fallback number for the PSTN call when
the ASA triggers a fallback to the PSTN.
The following Fallback feature parameters apply to mid-call fallback of Cisco Intercompany Media Engine:
No changes.
The VPN Profile settings are assigned to the Cisco Unified IP Phone by
using the Common Phone Profile Configuration window. This is the list of
configured VPN profiles.
A VPN Group contains VPN gateways which are used to create the VPN connection.
You can add up to a maximum of three VPN gateways to a VPN group. The
total number of certificates in the VPN group cannot exceed 10.
The following VPN gateways (Cisco Adaptive Security Appliance (ASA)) are configured on CUCM.
The VPN Gateway URL is the URL for the main VPN concentrator in the
gateway. Note : You must configure the VPN concentrator with a group-URL
and use this URL as the gateway URL.
You can assign up to 10 certificates to a VPN Gateway, and you must
assign at least one certificate to each gateway. Only certificates that
are associated with the Phone-VPN-trust role display in the available
VPN certificates list. To configure a VPN gateway, you must first upload
the VPN concentrator certificates and then configure the VPN gateway.
VPN Feature Configuration contains default settings for the VPN feature,
used when a VPN Profile is not associated a Common Phone Profile. If a
VPN Profile is associated with a Common Phone Profile, the VPN Feature
Configuration settings will not be used.
No changes.
Called Party Tracing allows you to configure a directory number or list
of directory numbers that you want to trace. You can request on-demand
tracing of calls using the Session Trace Tool.
When the Intercluster Lookup Service (ILS) is configured on multiple
Unified CM clusters, ILS updates Cisco Unified Communications Manager
with the current status of remote clusters in the ILS network. The ILS
cluster discovery service allows Cisco Unified Communications Manager to
learn about remote clusters without the need for an administrator to
manually configure connections between each cluster.
The ILS URI Replication feature enables ILS to exchange directory URI
catalogs with the other clusters in an ILS network. URI Replication
provides support for intercluster URI dialing.
Although ILS is activated and runs on individual cluster nodes, the
configuration settings are applied on a cluster-wide basis. After ILS is
configured on a cluster node, those settings are propagated out to the
other cluster nodes. The length of time that it takes for ILS settings
to be propagated to other cluster nodes depends on the synchronization
value that you enter.
No changes.
When you associate a Call Control Agent (CCA) profile to a directory
number and if ESN and E164 masks are configured on that directory
number, then the directory number will be synchronized to the
corresponding fields in the external LDAP server that you have
configured.
The Directory Number Alias Lookup and Sync setup enables you to route
the commercial calls to an alternate number. Routing the commercial
calls to an alternate number reduces the commercial cost of calling an
external number. You must configure the LDAP server for Directory Number
Alias Sync (sync server) if you need to synchronize users from Cisco
Unified Communications Manager database to the sync server. You must
configure the LDAP server for Directory Number Alias Lookup (lookup
server) if you need to route the commercial calls to an alternate
number.
The Switches and Access Points section shows a list of tracked switches
and wireless access points in your network and their settings.
Wireless Access Point Controllers section shows the configuration of wireless access point controllers in your network.
A CTI route point virtual device can receive multiple, simultaneous calls for
application-controlled redirection. You can configure one or more lines on a CTI
route point that users can call to access the application. Applications can answer
calls at a route point and can also be redirected to a CTI port or IP phone.
An endpoint gatekeeper is configured to manage all RAS procedures for
calls to, from, and between
H.323 clients, MCUs, and H.320 video gateways. The endpoint gatekeeper
directs all such calls to
the appropriate Cisco Unified Communications Manager (CUCM) cluster so
that Cisco Unified Communications Manager (CUCM) can perform
all of the H.225 call routing and H.245 media negotiations.
An infrastructure gatekeeper is configured to manage all dial plan
resolution and bandwidth
restrictions (call admission control) between CUCM clusters, between a
CUCM cluster and a network of H.323 VoIP gateways, or between a CUCM
cluster and a service provider's H.323 VoIP transport network.
< No records found >| Gatekeeper |
| Host Name/IP Address | Description | Registration Request Time to Live | Registration Retry Timeout | Enabled |
Gatekeeper1.lab.test
| Detected Change ID | 6 | | Detected Change | Added record 'Gatekeeper1.lab.test' | | Detected Object | Gatekeeper | | Detected Date (UTC) | 2/29/2024 6:54:16 PM | | Detected Date (Local) | 2/29/2024 7:54:16 PM | | Desc Gatekeeper1.lab.test | 60 | 300 | Y |
Cisco Unified Communications Manager (CUCM) supports several types of voice gateways.
The following gateway devices are present:
No changes.
Cisco IP telephony gateways enable Cisco Unified Communications Manager
(CUCM) to communicate with non-IP telecommunications devices.
MGCP gateways provide full support for the hold, transfer, and conference features through the
MGCP protocol. Because MGCP is a master/slave protocol with CUCM controlling
all session intelligence, CUCM can easily manipulate MGCP gateway voice
connections.
No changes.
MGCP Gateway Endpoints are the line interfaces of the MGCP gateways.
This section is linked to the previous section MGCP gateway. The gateway, module and slot configurations are documented there.
Cisco IP telephony gateways enable Cisco Unified Communications Manager
(CUCM) to communicate with non-IP telecommunications devices.
Cisco IOS H.323 gateways must be configured by using the Cisco IOS
command-line interface (CLI). Compared to MGCP gateways, H.323 gateways
maintain the dial plan and route pattern and can perform number translations autonomously.
Cisco IP telephony gateways enable Cisco Unified Communications Manager
(CUCM) to communicate with non-IP telecommunications devices.
The Cisco Analog Phone Gateways allow on-premise analog telephones, fax machines, modems,
voice-messaging systems, and speakerphones to register with one Cisco Unified Communications Manager (CUCM) cluster.
No changes.
This report has been generated with the following filter applied.If
there is a filter configured, not all objects may be be listed.
No changes.
The following table lists the subscribed IP services and parameters for each phone:
The following Speed Dials are configured per phone:
The following Busy Lamp Field Speed Dials are configured per phone:
The following Busy Lamp Field Directed Call Parks are configured per phone:
The following is an overview of the configured trunks on this system.
Click on the name (leftmost column in the overview) for detailed information.
A trunk device configures a logical route to a gatekeeper (that is, the
wholesale network or an intercluster trunk with gatekeeper control), to an
intercluster trunk without a gatekeeper, or to a SIP network. The
following trunk types are available:
- H.225 trunk (gatekeeper controlled)
- Inter-Cluster trunk (gatekeeper controlled)
- Inter-Cluster trunk (non-gatekeeper controlled)
- SIP trunk
Remote destinations represent the cellular (or other phones) that are
able to accept transfers from the user's desktop phone and can be used
to initiate calls using Mobile Voice Access.
Device defaults set the default characteristics of each type of device that
registers with a Cisco Unified Communications Manager (CUCM). The device defaults for a device type
apply to all auto-registered devices of that type within a CUCM cluster.
When a device auto-registers with a Cisco Unified Communications Manager, it acquires the
device default settings for its device type. After a device registers, you can update
its configuration individually to change the device settings.
No changes.
The Firmware Load Information in Cisco Unified Communications Manager
locates devices that are not using the default firmware load for their
device type.
Each device can have an individually assigned firmware load that overrides the default.
No changes.
Use the default device profile for whenever a user logs on to a phone
model for which no user device profile exists. To create a default
device profile for each phone model that supports Cisco Extension
Mobility, use the Default Device Profile Configuration window. The
maximum number of default device profiles cannot exceed the number of
phone models that support Cisco Extension Mobility.
For example, a user logs on to a Cisco Unified IP Phone 7960, for which
there is a user device profile. The user device profile for the user
gets downloaded to the phone to which the user logged on. Later, the
same user logs on to a Cisco Unified IP Phone 7940, for which he does
not have a user device profile. In this case, the default device profile
for the 7940 gets downloaded to the phone.
A default device profile comprises the set of attributes (services
and/or features) that are associated with a particular device. Device
profiles include device type, user locale, phone button template,
softkey template, multilevel precedence and preemption (MLPP)
information, and IP phone services.
This report has been generated with the following filter applied.If
there is a filter configured, not all objects may be be listed.
No changes.
No changes.
The following table lists the subscribed IP services and parameters for each Device Profile:
No changes.
The following Speed Dials are configured per Device Profile:
The following Busy Lamp Field Speed Dials are configured per Device Profile:
The following Busy Lamp Field Directed Call Parks are configured per Device Profile:
Cisco Unified Communications Manager (CUCM) includes several default phone button templates.
When adding phones, you can assign one of these templates to the phones or
create a new template.
Creating and using templates provides a fast way to assign a common button
configuration to a large number of phones. For example, if users in your company
do not use the conference feature, you can create a template that reassigns this
button to a different feature, such as speed dial.
No changes.
Softkey templates include softkey settings that are associated with applications
such as Cisco Unified Communications Manager Assistant or call-processing features such as
Cisco Call Back on the Cisco Unified IP Phones.
Cisco Unified Communications Manager (CUCM) supports two types of softkey templates: standard and
nonstandard. Standard softkey templates in the Cisco Unified Communications Manager (CUCM)
database contain the recommended selection and positioning of the softkeys for
an application.
No changes.
Cisco Unified IP Phone Services comprise XML applications that enable
the display of interactive content with text and graphics on Cisco
Unified IP Phones.
IP Phone Services are either statically assigned by the administrator to
phones or device profiles or users can subscribe to IP Phone Services
on the CCM user pages.
No changes.
A SIP profile comprises the set of SIP attributes that are associated
with SIP trunks and SIP endpoints. SIP profiles include information such
as name, description, timing, retry, call pickup URI, and so on. The
profiles contain some standard entries that cannot be deleted or
changed.
No changes.
A common device configuration comprises user-specific service and
feature attributes. Ensure that each device is associated with a common
device configuration for user-oriented information.
Note: The Device Pool window now contains only location-related
information. The Common Device Configuration window records all the
user-oriented information.
Cisco Unified Communications Manager uses common phone profiles to
define phone attributes that are associated with Cisco Unified IP
Phones. Having these attributes in a profile instead of adding them
individually to every phone decreases the amount of time that
administrators spend configuring phones and allows the administrator to
change the values for a group of phones.
No changes.
Remote destination profiles (RDPs) are associated with directory numbers (for example, the DN of a
user's IP phone) and with remote destinations (for example, the mobile phone number of a user). The
RDP controls the interaction between the IP phone and the external numbers (for example, a mobile
phone) configured as remote destinations.
Note: Remote destinations cannot be configured with on-cluster DNs as destination numbers.
Feature Control Policies allows you to enable or disable a particular
feature and thereby control the appearance of certain features and
softkeys that display on the phone. You can configure multiple policies
on Cisco Unified Communications Manager Administration. After you
configure a Feature Control Policy, you must associate that policy to an
individual phone, a group of phones, or to all phones in the system.
The appearance of softkeys on Cisco Unified IP Phones is customized by
using softkey templates. When you disable a feature by using Feature
Control Policies, the softkeys for the disabled feature do not appear in
any call state.
Cisco Unified Communications Manager uses the following order of
precedence (Device Configuration has the highest precedence) for Feature
Control Policies settings: Device Configuration, Common Phone Profile,
Enterprise Parameter Configuration.
To provision line appearances of agents for call recording,
administrators create one or more call recording profiles. The
administrator then selects a recording profile for a line appearance.
This section defines SIP normalization and transparency scripts.
SIP trunks can connect to a variety of endpoints, including PBXs,
gateways, and service providers. Each of these endpoints implements the
SIP protocol a bit differently, causing a unique set of interoperability
issues. To normalize messages per trunk, Cisco Unified Communications
Manager allows you to add or update scripts to the system and then
associate them with one or more SIP trunks. The normalization scripts
that you create allow you to preserve, remove, or change the contents of
any SIP headers or content bodies, known or unknown.
Transparency refers to the ability to pass information from one call leg
to the other. REFER transparency allows Cisco Unified Communications
Manager to pass on REFER requests to another endpoint rather than acting
on them. REFER transparency is key in call center applications, where
the agent sending the REFER (initiating the transfer) resides in a
geographic area remote from both of the other call parties.
After you configure a script in Cisco Unified Communications Manager,
you associate the script with a SIP trunk by configuring the
Normalization Script fields in the Trunk Configuration window. You can
only associate one script per trunk, but you can associate the same
script to multiple trunks.
No changes.
The Session Description Protocol Transparency for Declarative Parameters
allows the administrator to specify declarative SDP attributes that are
not natively supported by Cisco Unified Communications Manager to be
passed from the ingress call leg to the egress call leg.
If the Unified Communications Manager receives attributes that are not
explicitly identified by the administrator to send to the egress leg,
Unified Communications Manager drops the attribute from the outgoing SDP
similar to previous versions of Unified Communications Manager.
No changes.
A Network Access Profile contains information about VPN connectivity and
HTTP proxy settings. It is assigned to a Wireless LAN Profile.
The Wireless LAN Profile feature removes the need for users to configure
Wi-Fi parameters on their phones by allowing the administrator to
configure Wi-Fi profiles for them. The user devices can automatically
download the Wi-Fi configuration from the Cisco Unified Communications
Manager TFTP server, and the configuration is then applied to these
devices.
The following Wireless LAN Profiles are configured:
After you create one or more Wireless LAN Profiles, you can add them to a Wireless LAN Profile Group.
A Wireless LAN Profile Group can be added to a device pool or device-level configuration.
The Wi-Fi Hotspot Profile feature allows users to use their desk phones
to provide a Wi-Fi Hotspot, so that they can connect a Wi-Fi device such
as a tablet or a mobile phone to the network through the desk phone.
The desk phones can automatically download the Wi-Fi Hotspot
configuration from the Cisco Unified Communications Manager, and the
configuration is then applied to these devices.
The following Wi-Fi Hotspot Profiles are configured:
Application users are all users associated with other Cisco IP
Communications features or
applications, such as Cisco Attendant Console, Cisco IP Contact Center
Express, or Cisco Unified Communications Manager Assistant. These
applications need to authenticate with Cisco Unified Communications
Manager (CUCM), but
these internal "users" do not have an interactive login and serve purely
for internal communications
between applications.
No changes.
End users are all users associated with a physical person and an
interactive login. This category
includes all IP Telephony users as well as Cisco Unified Communications
Manager (CUCM) administrators when using the User Groups
and Roles configuration (equivalent to the Cisco Multilevel
Administration feature in prior
Cisco Unified Communications Manager (CUCM) versions). The following is a
condensed table with the most important end user settings.
The SIP Realm provides the trunk-side credentials when Cisco Unified Communications Manager gets challenged by a trunk peer.
When you configure digest authentication for SIP trunks, Cisco Unified
Communications Manager challenges the identity of the SIP user agent
that connects to the trunk every time the trunk sends a SIP request to
Cisco Unified Communications Manager; the SIP user agent, in turn, can
challenge the identity of Cisco Unified Communications Manager. For CUCM
to respond to a challenge from the SIP user agent, you must configure
the SIP realm for Cisco Unified Communications Manager.
The Credential Policy Default window provides options to change the
default credential policy assignment for a user and credential type (for
example, end user PINs).
At installation, Cisco Unified Communications Manager assigns the system
Default Credential Policy to end user passwords, end user PINS, and
application user passwords. The system applies the application password
that you configured at installation to all application users. You can
assign a new default credential policy and configure new default
credentials after installation.
No changes.
A Credential Policy comprises a set of rules that controls access to a
system or network resource. A credential policy defines password
requirements and account lockouts for user accounts.
Credential policies that are assigned to user accounts control the
authentication process in Cisco Unified Communications Manager.
After you add a credential policy, you can assign the new policy as the
default policy for a credential type or to an individual application or
end user.
No changes.
Roles allow to configure end users and application users with different
levels of privilege. Administrators with full administration privilege
configure roles and user groups. In general, full-access administration
users configure the privilege of other administration users and end
users to Cisco Unified Communications Manager Administration and to
other applications.
Roles comprise groups of resources for an application. At installation,
default standard roles get created for various administrative functions.
You may, however, create custom roles that comprise custom groupings of
resources for an application.
Different levels of privilege exist for each application. For the Cisco
Unified Communications Manager Administration application, two levels of
privilege exist: read privilege and update privilege.
No changes.
User groups comprise lists of application users and end users. A user
may belong to multiple user groups. After you add a user group, you then
add users to a user group. Afterward, you may proceed to assign roles
to a user group. If a user belongs to multiple user groups, the MLA
permission enterprise parameter determines the effective privilege of
the user.
Users with full access configure roles, user groups, and access
privileges for roles. In general, full-access users configure the access
of other users to Cisco Unified Communications Manager Administration.
User groups comprise lists of application users and end users. A user
may belong to multiple user groups. After you add a user group, you then
add users to a user group. Afterward, you may proceed to assign roles
to a user group. If a user belongs to multiple user groups, the MLA
permission enterprise parameter determines the effective privilege of
the user.
No changes.
The End User CAPF Profile Configuration window in Cisco Unified
Communications Manager Administration allows you to issue locally
significant certificates to CTI clients. After you issue the certificate
and perform other security-related tasks, the CTI client communicates
with the CTIManager service via a TLS connection.
Unified Communications (UC) services contain settings for voicemail,
conferencing, CTI, and IM and Presence which are grouped into service
profiles that are associated with end users. UC service settings are
then downloaded by devices of users for seamless integration with the
configured UC services.
The following Unified Communications (UC) services are configured:
Service Profiles that are associated with end users and are deployed to
user devices. Each Service Profiles contains several Unified
Communications (UC) services which defines settings for voicemail,
conferencing, CTI, and IM and Presence. UC service settings are
downloaded by devices of users for seamless integration with the
configured UC services.
The following Service Profiles are configured:
The Self-Provisioning feature allows an end user or administrator to add
an unprovisioned phone to a Cisco Unified Communications Manager system
with minimal administrative effort. A phone can be added by plugging it
into the network and following a few prompts to identify the user.
With appropriately configured User Profiles, end users can provision
their own devices. These User Profiles may be shared by a group of users
that share the same characteristics. The User Profile contains the
following settings:
- Universal Device Templates
- Universal Line Template
- End user Self-Provisioning settings
No changes.
When the Enterprise Groups feature is configured in the LDAP Directory
Synchronization configuration, CUCM includes user groups when it
synchronizes with an external LDAP directory. In CUCM Administration,
you can view synced groups in the menu User Management > User
Settings > User Group.
Cisco Jabber users can search for enterprise groups and security groups
in Microsoft Active Directory and add them to their contact lists. If a
group that is already added to the contact list is updated, the contact
list is automatically updated. Cisco CUCM synchronizes its database with
Microsoft Active Directory groups at specified intervals determined by
the LDAP Directory Synchronization Schedule configuration.
Currently, the Enterprise Groups feature is supported only on Microsoft
Active Directory server. It is not supported on other corporate
directories.
If a Cisco Jabber user wants to add a group to the contact list while
the Enterprise Groups feature is enabled, the Cisco Jabber client sends a
group request to the IM and Presence Service node. The IM and Presence
Service node provides the following information for each group member:
- Display Name
- User ID
- Title/LI>
- Phone number
- Mail ID
Only the group members that are assigned to the IM and Presence Service
nodes can be added to the contact list. Other group members are
discarded.
User Ranks can be assign to end users, application users and access
control groups. You can configure up to 10 different ranks. The highest
rank is 1, the lowest is 10. To be permitted to join an access control
group, a user must meet the minimum user rank threshold set by the
access control group. The highest rank is 1, the lowest is 10.
No changes.
The Self-Provisioning feature allows an end user or administrator to add
an unprovisioned phone to a Cisco Unified Communications Manager system
with minimal administrative effort. A phone can be added by plugging it
into the network and following a few prompts to identify the user.
This feature enhances the out-of-box experience for end users by
allowing them to directly add their desk phone or soft client without
contacting the administrator. It simplifies administrator deployments by
allowing them to add desk phones on behalf of an end user. The feature
lets administrators and users deploy a large number of devices without
interacting directly with the Cisco Unified Communications Manager
Administration GUI, but from the device itself. The feature relies on
the administrator preconfiguring a number of templates and profiles, so
that when the phone attempts to self-provision, the necessary
information is available in the system for it to create a new device.
