In the globalized economy of today, where business decisions must be made almost instantaneously,

bringing the involved parties together at the same table is almost an impossible mission, unless the
table is virtual. Thanks to the Cisco Collaboration Solution, it's now possible for all parties to
collaborate with each other anytime and anywhere, while saving time and reducing expenses.

The Cisco Collaboration Solution comprises four main elements-- network and unified computing,
collaboration infrastructure, collaboration endpoints, and collaboration management. In the network
and unified computing component, routing and switching technologies are the basis for a successful
collaboration solution. Adding Quality of Service or QoS mechanisms along with medianet services
will provide an infrastructure that is capable of recognizing various services and prioritizing traffic
according to its needs.
Cisco Collaboration System release 10 includes completely virtualized deployment models that are
based on VMware vSphere ESXi Hypervisor, where application nodes run as virtual machines, or
VMs, on servers. Infrastructure doesn't end with virtualization. The network and unified computing
also includes security mechanisms that protect every component at each level and a wide variety of
tools, applications, and products to monitor and manage the system.
Let's look at collaboration infrastructure. It provides very important services such as collaboration
applications, call control, Collaboration Edge, and conferencing. Call control component is in the
center of everything. The handling and processing of voice and video calls is a critical function
provided by IP telephony systems. This functionality is handled by some type of call processing
entity or agent. These entities include Cisco Unified Communications Manager, Cisco Unified
Communications Manager Business Edition, Cisco Unified Communications Manager Express, and
Cisco TelePresence Video Communication Server.
Once the network call routing and call control infrastructure has been put in place for your Cisco
Unified Communications and Collaboration System, additional applications and services can be
added or layered on top of that infrastructure. There are numerous applications and services that
can be deployed on an existing Cisco Unified Communications and Collaboration infrastructure. And
the following applications and services are typically deployed-- voice messaging, instant messaging
and presence services, mobility services, contact center, and call recording and monitoring.
Enterprises with collaboration systems may have widely deployed voice and video services such as
point to point calls within the enterprise, as well as calls to external networks. The compression
function is an essential component of any collaborations system, especially those that serve remote
users and/or a large user base.
Cisco Rich Media Conferencing improves on traditional conferencing by offering features, such as ad
hoc audio and video conferencing, rendezvous audio and video conferencing, and scheduled
conferencing, as well as application sharing.
The Collaboration Edge includes a series of servers and gateways defining access to services at the
perimeter of a collaboration network. The Collaboration Edge provides access to public networks,
including the Internet and PSTN.
A variety of endpoints can be used in a Cisco Collaboration Deployment. These endpoints range from
gateways that support ordinary analog phones in an IP environment to an extensive set of native IP
phones offering a wide range of capabilities. These endpoints include Cisco Unified IP phones and
desktop endpoints, Cisco TelePresence room and immersive systems, Cisco mobile endpoints, and
Cisco TelePresence integrated solutions. We are focused on making our collaboration technology
easy, convenient, and beneficial to use with particular emphasis on the user experience.
Network management is a service consisting of a wide variety of tools, applications, and products to
assist network system administrators in provisioning, operating, monitoring, and maintaining new
and existing network deployments.
With the convergence of rich media and data, the need for unified management is greater than ever.
The Cisco Prime Collaboration offers a set of integrated tools that help to test, deploy, and monitor
Cisco Unified communications and TelePresence systems.
Prime Collaboration implements the various management phases to strategically manage the
performance and availability of Cisco Unified Communications applications, including voice, video,
contact center, and rich-media applications.
As unified communications has become more commonplace, the deployment options for Cisco
Unified Communications and collaboration have increased to address the demand for collaboration
as a service, as well as traditional on-premises unified communications and collaboration
deployment.
The choice of using an on-premises, cloud-based, or hybrid solution may be determined by
manufacturers. For example, cloud-based solutions require less on-site expertise, but might lag the
deployment flexibility that many enterprises need.
Hybrid designs can also be deployed where some unified communications functions, such as call
control, are deployed on premises. And others are provided as a cloud-based service.
Cisco Unified Communications Manager extends enterprise telephony features and functions to
packet telephony network devices. These packet telephony network devices include Cisco IP phones,
media processing devices, web gateways, and multimedia applications. Additional data, voice, and
video services such as converged messaging, multimedia conferencing, collaborative contact
centers, and interactive multimedia response systems interact with the IP telephony solution
through the Cisco Unified Communications Manager Application Programming Interface or API. Cisco
Unified Communications Manager provides these functions:

Call processing refers to the complete process of routing, originating, and terminating calls,
including any billing and statistical collection processes. Cisco Unified Communications Manager sets
up all of the signaling connections between call endpoints and directs devices such as
phones, gateways, and conference bridges to establish and tear down streaming connections. The
dial plan is a set of configurable lists that Cisco Unified Communications Manager uses to
determine call routing.
Cisco Unified Communications Manager provides the ability to create scaleable dial plans for users.
Cisco Unified Communications Manager extends services such as hold, transfer, forward, conference,
speed dial, last number redial, call park, and other features to IP phones and gateways. Cisco Unified
Communications Manager uses its own database to store user information.
You can authenticate users either locally or against an external directory. You can provision users by
directory synchronization. With directory synchronization, you can automatically add users from the
directory to the local database. Cisco Unified Communications Manager provides a programing
interface to external applications such as Cisco IP Communicator, Cisco Unified IP IVR, Cisco Personal
Assistant, and Cisco Unified Communications Manager Attendant Console.
Cisco Unified Communications Manager uses different signaling protocols to communicate with the
Cisco IP phones for call setup and maintenance tasks, including SIP, SCCP, or even H323. After the
call setup is finished, media exchange normally occurs directly between Cisco IP phones using RTP to
carry the audio and potentially video stream.
Let's look at example. In the figure, user A on IP phone A wants to make a call to IP phone B. User A
enters the number of user B.

In this scenario, dialed digits are sent to Cisco Unified Communications Manager, which performs its
main function of call processing. Cisco Unified Communications Manager finds the IP address of the
destination and determines where to route the call. Using SCCP, SIP, or H323, Cisco Unified
Communications Manager checks the status of the called party. If the Cisco Unified Communications
Manager is ready to accept the call, it sends the called party details and signals via ring back to the
calling party to indicate that the destination is ringing.
When user B accepts the call, the RTP media path opens between the two devices. User A and user B
may now begin a conversation. Note that Cisco IP phones require no further communication with
Cisco Unified Communications Manager until either user A or user B invokes a feature such as call
transfer, call conferencing, or call termination.
Cisco Unified Communications Manager depends on some additional network elements. In particular,
the Cisco Unified Communications Manager cluster uses external NTP and DNS servers, plus DHCP
and TFTP services that the endpoints use.

Cisco Unified Communications Manager uses NTP to obtain time information from a time server. Only
the publisher sends NTP requests to the external NTP server or servers. Subscribers synchronize
their time with the publisher.

NTP is a protocol for synchronizing computer system clocks over IP networks. It has a hierarchical
organization that is based on clock stratum. Stratum 0 is an extremely precise clock source, such as
an atomic clock or radio clock. A stratum 1 server is directly connected to stratum 0 clock, and can
provide time information to other stratum 2 devices, which in turn, serves stratum 3 devices. Cisco
Unified Communications Manager typically uses stratum 1.
NTP must be enabled and configured during installation of Cisco Unified Communications Manager.
At least one external NTP server must be reachable and functioning when installing the Cisco Unified
Communications Manager Publisher to complete the installation. We recommend you to use a
minimum of three external NTP servers in a production environment. It is extremely important that
all network devices have accurate time information because the system time of Cisco Unified
Communications Manager is relevant in many situations.
For example, Cisco IP phones display date and time information. This information is obtained from
Cisco Unified Communications Manager. Call detail records, or CDRs, and call management records,
or CMRs, which are used for call reporting, analysis and billing, include date and time information.
Alarms and events and log files, as well as trace information in trace files, include time information.
Troubleshooting a problem requires correlation of information that is created by different system
components, such as Cisco Unified Communications Manager, Cisco IOS Gateway, and so on. This
problem solving is only possible if all devices in the network have the same correct time information.
In addition some Cisco Unified Communications Manager features are date or time based, and
therefore rely on correct date and time. These features include time of day routing and certificate-
based security features.

The Cisco Unified Communications Manager DHCP server is designed to serve IP phones in small
deployments with a maximum of 1,000 devices. It provides a subset of Windows, Linux, or Cisco IOS
DHCP server functionality that is sufficient for IP phones, but it should not be used for other network
devices, such as PCs. Note that the DHCP server of Cisco Unified Communications Manager must not
be used with deployments of more than 1,000 registered devices. Even if there are fewer devices,
the CPU log of the services must be watched closely. If high CPU load is experienced, the DHCP
service should be provided by other devices. For example, a dedicated DHCP server, switch, router,
and so on.
Multiple DHCP services can be configured per Cisco Unified Communications Manager cluster. Each
Cisco Unified Communications Manager DHCP server can be configured with multiple subnets. In
non-attached subnets, DHCP relay must be enabled so that they DHCP request that the clients send
out are forwarded to the DHCP server.

Cisco Unified Communications Manager can use IP addresses or names to refer to other IP devices in
application settings. When names are used, they need to be resolved to IP addresses by DNS. Both
methods have some advantages. When using IP addresses, the system doesn't depend on a DNS
server, which prevents loss of service when a DNS server cannot be reached. When a device initiates
a connection for the first time, the time that is required to establish the connection is shorter
because no name resolution is required. By eliminating the need for DNS, there is no danger of
errors that DNS misconfiguration causes. Troubleshooting is simplified because there is no need to
verify a proper name resolution.

When using DNS, management is simplified because logical names are simpler to manage than 32
bit IP addresses. If IP addresses change, there is no need to modify the application settings because
they can still use the same names. Only the DNS server configuration has to be modified in this
case. IP addresses of Cisco Unified Communications Manager servers can be translated toward IP
phones because the IP phone configuration files include server names, not the original server IP
address, which should appear differently to the IP phone. As long as these names are resolved to the
correct translated address when IP phones send out DNS requests, the net is no problem.
In general, due to additional point of failure that is disclosed by configuration errors or because of
unavailability of the service, the recommendation is not to use DNS with Cisco Unified
Communications Manager. By default, Cisco Unified Communications Manager propagates the
machine name and not the IP addresses of it's active Cisco Call Manager services. To remove DNS
reliance, choose System, Server in Cisco Unified Communications Manager Administration, choose
each available server from the list, and change the server name to the IP address.

Cisco IP Telephony supports these deployment models, single-site or campus, multisite WAN with
centralized call processing, and multisite WAN with distributed call processing. In addition, a fourth
model clustered over the IP WAN is often referenced in the documentation. Selection of the
deployment model is based on several factors, such as size, that is number of IP phones, Cisco
Unified Communications Manager servers, and other resources, such as gateways or media
resources, geographical distribution, there is number and location of sites and network
characteristics, there is bandwidth and delay of network links, and type of traffic.
Let's describe all these deployment models in details. The single-site or campus deployment model
for Cisco Unified Communications Manager comprises a Cisco Unified Communications Manager
Cluster that is located at a single-site or campus, with no telephony services that are provided over
an IP WAN. All Cisco Unified Communications Manager servers, applications, and DSP resources, are
located in the same physical location. An enterprise would typically deploy the single-site model
over a LAN or MAN, which carries the voice traffic within the site.
In this model, calls beyond the LAN or MAN use the PSTN. Each cluster supports a maximum of
40,000 IP phones. If there is a need to deploy more than 40,000 IP phones in a single-site
configuration, multiple clusters that are inside a LAN or within a MAN can be implemented and
interconnected through inter-cluster trunks. Gateway trunks that connect directly to the PSTN
manage external calls. Even IP WAN exists between sites, it is used to carry data traffic only. No
delivery services are provided over the WAN.
Single-site deployment allows each side to be completely self-contained. Calls between sites will be
routed over the PSTN. Extra provisioning of WAN bandwidth is not needed. Dial plans are also easier
to provision. There are no service issues in the event of an IP WAN failure or insufficient bandwidth,
and there is no loss of call processing service or functionality.
The multi-site WAN with centralized call processing model consists of a centralized Cisco Unified
Communications Manager Cluster that provides services for many sites and uses the IP WAN to
transport IP telephony traffic between the sites.
The IP WAN also carried call control signaling between the Cisco Unified Communications Manager
Cluster at the central site, and the IP phones at the remote site. The figure illustrates a typical
centralized call processing deployment with a Cisco Unified Communications Manager Cluster at the
central site, and the IP WAN with QoS that is enabled to connect all the sites. The remote sites rely
on the centralized Cisco Unified Communications Manager Cluster to manage their call processing.
Applications, such as voice mail, and interactive voice response systems, are typical centralized as
well to reduce the overall costs of administration and maintenance. This Cisco Unified Survivable
Remote Site Telephony, or SRST feature that is available in Cisco IOS gateways, provides call
processing services to remote IP phones during a WAN outage.

When the IP WAN is down, the IP phones at the remote branch office can register through the Cisco
Unified SRST router.
The Cisco Unified SRST router can process calls between the registered IP phones and can send calls
to other sites through the PSTN. To avoid oversubscribing the WAN links with the voice traffic,
causing deterioration of the quality of the established calls, call admission control, or CAC, is used to
limit the number of calls between the sites. Centralized call processing models can take advantage
of Automatic Alternate Routing, or AAR features. AAR allows Cisco Unified Communications Manager
to dynamically reroute a call over the PSTN if the call is denied because of call admission control.
The model for a multisite WAN deployment with distributed call processing comprises multiple
independent sites each with its own Cisco Unified Communications Manager Cluster that is
connected to an IP WAN that carries voice traffic between the distributed sites. A Cisco Unified
Communications Manager Session Manager Edition, or SME cluster, or SIP proxy servers can be used
to provide intercluster call routing and dial plan aggregation in the multisite distributed call-
processing deployments.
Cisco Unified Communications Manager SME may also be used to connect to the PSTN and third-
party unified communications systems such as PBXs and centralized unified communications
applications. The multisite WAN with distributed call-processing deployment model is a superset of
both single-site and multi-site WAN with centralized call processing. The extent call cost savings are
possible when using the IP WAN for calls between sites. In this model, you can use the IP WAN to
bypass toll charges by routing calls to remote site gateways closer to the PSTN number that is
dialed.
This approach is called Tail End Hop Off, or TEHO. Maximum utilization of available bandwidth is
possible by allowing voice traffic to share the IP WAN with other types of traffic.
Cisco supports Cisco Unified Communications Manager Clusters over a WAN. Some of the
characteristics of this model include the following, applications and Cisco Unified Communications
Manager of the same cluster can be distributed over the IP WAN. The IP WAN carries intracluster
server communication and signaling.
We have a limited number of sites, two to four size for local failover that is 2 CUCM servers per site
and up to 8 sites for remote failover occurs the IP WAN that is one CUCM server per site. Although
the distributed single-site call processing model offers some significant advantages, it must adhere
to the following design guidelines, two Cisco Unified Communication Manager servers in a cluster
must have a maximum round-trip delay of 80 milliseconds between them. In comparison, high
quality voice guidelines dictate that one-way end-to-end delay should not exceed 150 milliseconds.

Because of this strict guideline, this design can be used only between closely connected high-speed
locations. For every 10,000 busy hour call attempts within the cluster, an extra 900 kilobits per
second of WAN bandwidth for intracluster runtime communication must be supported. The busy hour
call attempt represents the number of call attempts that are made during the busiest hour of the
day. Clustering over the IP WAN provides a combination of the benefits of the two multi-site
deployment models to satisfy specific site requirements.
The clustering over IP WAN design is useful for customers who want to combine such advantages
with the benefits that the local call-processing agent provides at each site, where intrasite signaling
is kept local independent of WAN failures, and requires more functionality at the remote site that
what Cisco Unified SRST provides. This network design also allows remote offices to support more
Cisco IP phones than SRST in the event of WAN failure. These features make clustering over the IP
WAN ideal as a disaster recovery plan for business continuance sites, or as a single solution for up to
eight small or medium size.
A cluster is a set of networking servers that work together to provide Cisco Unified CallManager
service in addition to dedicated servers providing database, application, TFTP and media services,
such as conferencing and Music on Hold. The subscribers and the publisher can provide these
services, and all servers can share them.
Clustering provides several benefits. It allows the network to scale to several thousand endpoints,
provides redundancy in case of network or server failures, and provides a central point of
administration. Cisco Unified Communications Manager also supports clusters for redundancy and
load sharing. Sharing a common database provides database redundancy, whereas Cisco Unified
Communications Manager groups provide call-processing redundancy.
A cluster comprises one publisher and a total maximum of 20 servers providing various services
including TFTP, media resources, conferencing, and call-processing. But you can have a maximum of
eight nodes for call-processing that are runing the Cisco CallManager Service. To process calls
correctly, Cisco Unified Communications Manager needs to retrieve configuration settings for all
devices. The settings are stored in a database using an IBM Informix Dynamic Server, or IDS.

The database is the repository for information such as service parameters, features, device
configurations, and the dial plan. The database replicates nearly all information in a star topology
with one publisher and many subscribers.

However, Cisco Unified Communications Manager Nodes also use a second communication
method to replicate run time data in a meshed topology, where every node updates every
other node. This type of communication is used for dynamic information that changes more
frequently than database changes. The primary use of this replication is to communicate newly
registered phones, gateways, and DSP resources so that optimum routing of calls between members
of the cluster and the associated gateways occurs.
Database replication is fully meshed between all servers within a cluster. All non user-facing feature
data can be written only to the publisher database, and will be replicated from the publisher to all
subscribers.

However, user-facing feature data, for example, Cisco Extension Mobility features, are writable on
the subscriber and replicated from an updated subscriber to all other servers.
The user-facing features that are listed in the figure do not rely on the availability of the publisher.
The dynamic user-facing feature data can be written to the subscribers to reach the device as
registered. The data is then replicated to all other servers within the cluster. By allowing the data to
be written to the subscriber, the user-facing features can continue to function in the event of a
publisher failure. Therefore, most data is still replicated it in hub-and-spoke style, publisher to
subscribers, while user-facing feature data is replicated bidirectionally between all servers.
In this section, we'll talk about how to manage CUCM services from the CUCM serviceability page.
The topics of discussion in this section are what I consider day one configurations, such as CUCM
groups, enterprise parameters, service parameters, and device settings. In this course, we will talk
about CUCM clusters and what they are. What you will find is a CUCM cluster is a collection of
physical servers that work together as a single IP PBX, and are connected to each other via the IDS
database.
Although each server in the cluster is capable of doing any of the tasks that any other server in the
cluster are capable of doing, each server can have its own unique tasks within the cluster. It is very
important to understand what the function of each service is and how to turn them on and off for
each server. That is where we will begin in this section of the course, working on CUCM services.
Next, we will talk about what CUCM groups are, and how they help us provide redundancy to the end
devices. What we will also talk about here is how the CUCM groups are responsible for helping load
balance the registration of the end devices onto the CUCM servers. Enterprise parameters are used
to define cluster-wide system settings, and these parameters apply to all devices and services in the
cluster. The enterprise parameters are set to factory defaults after installation of the CUCM server,
and many of them may need to be adjusted to adhere to the needs of your network.
An in-depth discussion will ensue here that will lead into a hands-on lab to further assist you in
learning how these settings affect the operation of the CUCM server. Moving forward in this section,
we will talk about the service parameters and how they function within the CUCM servers. Service
parameters are configuration settings that are different on each server in the cluster.
And finally in this section, we will discuss device settings. These settings contain default settings,
profiles, templates, and common device configurations that can be assigned to the device or device
pools. Please take the time to fully understand and research the concepts in this section before
moving on, and I will see you again soon to introduce another exciting section of this course. But
until then, enjoy.
Each server in Cisco Unified Communications Manager cluster can fulfill different tasks such as
running a TFTP or DHCP server being the database publisher, processing calls, providing media
resources, and so on.
Depending on the usage of the server, different services must be activated on the system. There are
two types of services on Cisco Unified Communications Manager servers. Network services are
automatically activated and are required for the operation of the server.
You cannot activate or deactivate network services, but they can be stopped, started, or restarted
from the Cisco Unified Serviceability, Control Central - Network Services.
Examples of network services are Cisco Discovery Protocol, Cisco Database Replicator, and Cisco
Unified Communications Manager Administration. Feature services can be selectively activated or
deactivated per server to assign specific tasks or functions such as call processing, TFTP, and so on
to a certain server.
You can activate and deactivate feature services using Cisco Unified Serviceability, Service
Activation. The services can be started or restarted from the Cisco Unified Serviceability Control
Center Feature Services. Example of Feature Services includes Cisco CallManager, Cisco TFTP, or
Cisco DirSync.

The Cisco Unified Communications Manager Cluster is a collection of physical servers that work as a
single IP PBX system. With Cisco Unified Communications Manager version 10.0, a cluster can
contain as many as 20 server nodes, of which a maximum of 8 servers may run the Cisco Call
Manager service to perform call processing in a cluster. Other servers can be used as DFTP servers
or provide media resources such as software conference bridges or Music on Hold.
Cisco Unified Communications Manager groups are used to collect servers that run the Cisco Call
Manager service to provide call processing redundancy. A Cisco Unified Communications Manager
group is a prioritized list of one or more call-processing servers. Multiple Cisco Unified
Communications Manager groups can exist in the same cluster. Each call-processing server can be
assigned to more than one Cisco Unified Communications Manager group.

Each device might have a Cisco Unified Communications Manager group that is assigned, which will
determine the primary and backup servers to which the device can register. Cisco IP phones register
with a primary server. When idle, the IP phones and Cisco Unified Communications Manager
exchange signaling application keepalives. In addition, Cisco IP phones establish a TCP connection
with their secondary server and exchange TCP keepalives. When the connection to the primary
server is lost, the IP phone registers to the secondary server. The IP phone continuously tries to
reestablish a connection with the primary server, and if successful, the IP phone re-registers with the
primary server.

A 1:1 Cisco Unified Communications Manager redundancy deployment design guarantees that the
Cisco IP phone registrations will never overwhelm the backup servers even if multiple primary
servers fail concurrently. However, the 1:1 redundancy design has an increased server count
compared with other redundancy designs and may not be cost effective. The other services such as
dedicated database publisher, dedicated TFTP server, or Music on Hold servers, and media stream
and applications, such as conference breach or AMTP, may also be enabled on a separate server that
registers with a cluster.
In this example, there is an OVA template with a maximum number of user functions as a dedicated
database publisher and TFTP. In addition, there are two call-processing servers supporting a
maximum of 10,000 Cisco IP phones. One of these two servers is the primary server. The other
server is a dedicated backup server. The primary or secondary call processing server can provide the
function of the database publisher and the TFTP in a smaller IP telephony deployment with fewer
than 1,000 IP phones. In this case, only two servers are needed in total.
When you increase the number of IP phones, you must increase the number of Cisco Unified
Communications Manager servers to support the telephones. Some network engineers may consider
the 1:1 redundancy design excessive because a well-designed network is unlikely to use more than
one primary server at a time. With the low possibility of server loss and the increased server cost,
many network engineers choose a 2:1 redundancy design.

Although the 2:1 redundancy design offers some redundancy, there is a risk of overwhelming the
backup server if multiple primary servers fail. In addition, operating the Cisco Unified
Communications Manager servers can cause a temporary loss of some services such as TFTP or
DHCP because a reboot of the Cisco Unified Communications Manager servers is needed after the
upgrade is complete. Network engineers use this 2:1 redundancy model in most IP telephony
deployments because of the reduced server costs.
If a virtual machine with the largest OVA template is used, as shown in the figure, the server is
equipped with redundant hot swappable power supplies and hard drives. When these servers are
properly connected and configured, it is unlikely that multiple primary servers will fail at the same
time, which makes the 2:1 redundancy model a viable option for most businesses. As shown in the
first scenario where no more than 10,000 IP phones are used, there are no savings in the 2:1
redundancy design compared with the 1 by 1 redundancy design, simply because there is only a
single primary server. In the scenario with up to 20,000 IP phones, there are two primary servers,
each serving 10,000 IP phones and one secondary server. As long as only one primary server fails,
the backup server can provide complete support. If both primary servers failed, the backup server
would only be able to serve half of the IP phones.
The third scenario shows a deployment with 40,000 IP phones. Four primary servers are required to
facilitate this number of IP phones. For each pair of primary servers there is one backup server. As
long as no more than two servers fail, the backup servers can provide complete support, and all IP
phones will operate normally.

Enterprise parameters are used to define cluster-wide system settings, and these parameters apply
to all devices and services in the cluster. After installation, enterprise parameter default values
should be verified and modified, if required, before deploying endpoints. Some enterprise
parameters specify initial values of device defaults. We recommend you to change enterprise
parameters only if you are completely aware of the impact of your modifications, or if instructed to
do so by a Cisco TAC.
In this table, you can find some examples of enterprise parameters. Dependency records are the
feature of Cisco Unified Communications Manager that allows an administrator to view configuration
database records that reference the currently displayed record. Dependency records are useful when
you want to delete a configuration entry, for example, a device pool, but the deletion fails because
the record is still referenced, for example, by an IP phone. Without dependency records, you would
have to check each device to determine if it uses the device pool that you tried to delete.
Service parameters are used to define settings for a specific series on an individual server. Service
parameters are defined separated for each server in the cluster. After installation, or activation of
feature services, service parameter default values should be verified and modified, if required,
before deploying endpoints.
In this table, you can find some examples of service parameters for the Cisco CallManager service.
T302 Timer specifies the interdigit timeout for variable length numbers. Reducing the default value
will speed up dialing, thus making post-dial delay shorter. CDR Enabled Flag is used to enable
generation of call detail records. The Change B-Channel Maintenance Status service parameter is
another example of a Cisco CallManager service parameter that is not shown by default. Note that,
by default, not all service parameters are displayed. If you cannot find the service parameter that
you want to change, click Advanced to see the complete list of available service parameters.
While enterprise parameters manage cluster-wide settings, and service parameters manage server,
or service related, settings, device settings include parameters that are tied to individual devices or
device pools. Some of these parameters we will discuss later in this course.
SECTION 3: DEPLOYING ENDPOINTS, USERS, AND IP PHONE SERVICES
Comparison of Endpoints Supported by Cisco Unified Communications Manager

Various endpoints are supported by Cisco Unified Communications Manager, including Cisco
products and third-party products. Endpoints include IP phones, video endpoints, and analytic station
gateways, which allow analog phones to interact with Cisco Unified Communications Manager. Cisco
also offers software clients for mobile endpoints that are based on Android and Apple iOS operating
systems and for personal computers, including Windows and Mac. Cisco Unified Communications
Manager supports three protocols for communication with endpoints-- SIP, SCCP, and H.323. SIP
should be the first choice in collaboration deployments today, followed by SCCP. H.323 should be
used only for endpoints that do not support either SIP or SCCP.
Endpoint Configuration Elements
On this figure you can see the relationship between different phone configuration elements. You can
configure phone NTP references in Cisco Unified Communications Manager Administration to ensure
that a SIP phone gets its date and time from the NTP server. If all NTP servers do not respond the
phone that is running SIP uses the date header in the 200 OK response to the register message for
the date and time. Daytime groups are used to define time zones for the various devices that are
connected to Cisco Unified Communications Manager.
Each device exists as a member or only device pool. And each device pool has only one assigned
date/time group. Device pools define sets of common characteristics for devices, such as regions to
implement codec negotiation and locations to implement call admission control in a centralized call
processing system. The device pool allows IP phones to inherit or acquire settings that have been
defined in the various elements. Security profile configuration includes security related settings.
Softkey template configuration allows you to manage softkeys that the Cisco Unified IP phones
support. Phone button templates are used to assign various features to Cisco IP phone buttons.
Common phone profiles provide data this Cisco TFTP requires, such as do not disturb, or DND, phone
personalisation information, and VPN information. Some of the elements apply only to specific
devices. For example, the SIP profile applies only to SIP phones. It comprises the set of SIP attributes
that are associated with SIP trunks and SIP endpoints.
Elements can be divided into mandatory and optional groups. Even if some elements do not need to
be specified, they can still be mandatory because there was default value that is preconfigured. It is
recommended never to use default mandatory values. Instead of modifying the default values, these
elements should be copied and renamed and finally reconfigured.

Cisco Unified Communications Manager User Accounts

There are two types of user accounts in Cisco Unified Communications Manager. End users are
associated with a physical person and an interactive login. This category includes all IP telephony
users as well as Cisco Unified Communications Manager administrators when using the user group
and roles configurations.
Application users are associated with Cisco Unified Communications features or applications such as
Cisco Unified Connect Center Express or Cisco Unified Communications Manager Assistant.
These applications must authenticate with Cisco Unified Communications Manager, but these
internal users do not have an interactive login and serve purely for internal communications
between applications.

The attributes that are associated with end users are separated into three categories-- personal and
organizational settings, password, and CUCM configuration settings. If you use LDAP integration,
users and their personal and organizational data is replicated from LDAP to Cisco Unified
Communications Manager.
This information is then visible as read only in CUCM Administration. In this case, all personal and
organizational user data is configured in LDAP. Depending on LDAP integration configured, password
can be either configured locally or managed via LDAP. CUCM configuration settings are unknown for
any LDAP directory so they always keep local in CUCM database.

Types of LDAP Integration: Synchronization

Synchronization of Cisco Unified Communications Manager with the Corporate LDAP Directory allows
the administrator to provision users easily by mapping UCM user data fields to directory attributes.
Critical user data maintained in the LDAP store is copied into the appropriate corresponding fields in
this UCM database.

The LDAP synchronization process uses a service that is called Directory Synchronization or DirSync
on Cisco Unified Communications Manager to synchronize a number of users' attributes from the
Corporate LDAP Directory. When this feature is enabled, users are automatically provisioned from the
Corporate Directory in the following ways, periodic synchronization schedule or immediate
synchronization upon request. The Corporate Directory retains its status as the central repository.
Unified CM has an integrated database for storing user data and a web interface within UCM
administration for creating and managing user accounts and data.
Therefore, when LDAP synchronization is enabled, the local database is still used and additional local
end user accounts can be created. Management of end user accounts is then accomplished through
the interface of the LDAP Directory and the Unified CM Administration GUI.

Accounts for the application users can be created and managed only through the Cisco Unified
Communications Manager Administration web interface. It provides ability for all the applications
and features that use these accounts to communicate with this UCM in case of Corporate Directory
failure.

Types of LDAP Integration: Authentication

LDAP authentication is used to authenticate users against the LDAP directory instead of having
passwords that are stored in Cisco Unified Communications Manager database. With LDAP
authentication, CUCM authenticates user credentials against the corporate LDAP directory.
When this feature is enabled, LDAP synchronized end user passwords are not stored in Cisco Unified
Communications Manager database, as they are stored in the LDAP directory. Note that passwords
are never replicated to the CUCM database. Rather, the authentication process is redirected through
the LDAP system.

LDAP synchronization is not mandatory, but it is recommended. Personal user data can be managed
in LDAP and replicated into the Cisco Unified Communications Manager database if LDAP
synchronization is enabled.

If not, you can use the CUCM database to store and manage user data locally.

In such case, an identical user account must be configured in the CUCM database and LDAP. In that
way, you have to add users twice, into CUCM database, and into LDAP directory as well. Therefore,
ideally, authentication is used with LDAP synchronization.
If LDAP authentication is enabled and LDAP fails or is inaccessible, only local and user accounts or
application user accounts will be able to log in to the CUCM. This may cause drastic collaboration
service interruption, depending on how users normally interact with the system. Of course, if LDAP
has failed, it is likely to be a serious issue already, causing many applications to cease functioning.

Cisco Unified Communications Manager user data, such as associated PCs, PINs, or control devices
are always stored in the CUCM database for each individual user. As a consequence, the username
must be known in the CUCM database to assign CUCM user settings to the user. Also, the user name
must be known in the LDAP directory to assign the password to the user. Since application users are
configured only in local database, they do not use LDAP authentication.

LDAP Integration Features: Attribute Mapping

Cisco Unified Communications Manager imports data from standard attributes. So extending the
directory schema is not required. This table lists the attributes that are available for mapping to
Unified CM fields.
The data of the directory attribute that is mapped to this UCM user ID must be unique within all
entries for that cluster. The attribute mapped to the user ID field must be populated in the directory.
And the set attribute must be populated with data. Otherwise, those records are skipped during this
import action.
If the primary attribute used during import of end user accounts matches any application user in this
UCM database, that user is not imported from the LDAP directory.

As shown in the table, the attributes differ between the different types of LDAP servers. As we
mentioned, the SN attribute in the LDAP must be populated with data. Otherwise, that report will not
be imported.
The table shows that the LDAP SN attribute will be mapped to this UCM database Last Name
attribute.