Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Several CUCM features require user accounts for authentication purposes. These features include an
administrative web page, user web pages, and the following applications:
■ Cisco Unified Attendant Console
■ Cisco Unified Extension Mobility
■ Cisco Unified Manager Assistant (CUMA)
Cisco IP Phones can browse corporate and personal directories to find the directory number of a user.
CUCM is provisioned with a user’s first and last name to provide this directory-browsing
functionality.
114 Chapter 6: Managing User Accounts
CUCM IP phone services can be configured to require a user login before providing access
to the service. Users can authenticate with their username and password (alphanumeric) or
PIN (numeric), depending on the needs of the application. CUCM sends authentication
requests to an internal library called the Identity Management System (IMS) library, which
is responsible for authenticating the user login credentials against the user database.
User Account Types
There are two types of user accounts in CUCM:
■ End users: End users are associated with an individual and have an interactive login.
End users can have administrative roles based on the user group role configuration.
■ Application users: Application users are associated with applications such as Cisco
Unified Attendant Console, Cisco Unified Contact Center Express (UCCX), or
Cisco Unified Manager Assistant. The mentioned applications need to authenticate
with CUCM, but application users do not have the ability to interactively log
in. Application users are leveraged for internal process-level communications between
applications.
Table 6-1 summarizes the differences between end users and application users.
The attributes associated with end users are separated into three categories, as follows:
■ Personal and organizational settings:
—User ID, first, middle, and last name
—Manager user ID, department
—Phone number, mail ID
Table 6-1 User Account Types in CUCM
End Users Application Users
Associated with an individual Associated with an application
Provide interactive logins Provide noninteractive logins
User feature and system administration
authorization
Application authorization
Included in phone directory Not included in phone directory
Can be provisioned and authenticated using an
external LDAPv3 directory server
Cannot use LDAPv3
CUCM User Accounts 115
■ Password
■ CUCM administration settings:
—PIN, SIP digest credentials
—User privileges (user groups and roles)
—Associated PCs, controlled devices, and directory numbers
—Application and feature parameters
User Privileges
CUCM allows for the assignment of user privileges to application users and end users.
Privileges that can be assigned to users include the following:
■ Access to administration and user web pages
■ Access to specific administrative functions
■ Access to application interfaces such as Computer Telephony Integration (CTI) and
Simple Object Access Protocol (SOAP)
User privileges are configured using two configuration entities:
■ User groups: A collection of application users and end users with similar privilege
levels
■ Roles: Resources for an application
Each role refers to exactly one application, and each application has one or more
resources. Access privileges are configured per application resource in the role
configuration. Roles are assigned to user groups.
Figure 6-1 illustrates the access that four users have to two different applications. The needs
of the four users are achieved through the assignment of two user groups.
User1 and User2 are assigned to Group1, which has two roles assigned to it for Application1.
The privilege levels of Role1 and Role2 refer to the same application but provide different
levels of access (privileges) to the resource. The overlapping configuration can be configured
to give the highest or lowest overlapping privilege level.
116 Chapter 6: Managing User Accounts
User3 is assigned to both Group1 and Group2. Group1 and Group2 have role assignments
of 1, 2, and 3. Role1 and Role2 both control different privilege levels to Application1 and
Application2. It is best to avoid overlapping role privileges (Role1 and Role2) when
possible.
User4 is assigned to Group2, which has privilege levels to Application1 and Application2,
controlled through Role2 and Role3. User4 does not have overlapping privilege challenges.
Figure 6-1 User Privilege Component Interaction
The goal of the configuration illustrated in Figure 6-2 is to create administrative groups that
have read, write, and update access to the Communications Manager configuration web
pages (CCMAdmin), and junior-level administrators who have read-only privileges to the
CCMAdmin configuration web pages. The following text relates to the example illustrated
in Figure 6-2.
Users
Application1
Resource1
Resource2
Resource3
Application1
Resource1
Resource2
Resource3
Application2
Resource1
Resource2
Resource3
Resource4
Role2
Role1
Role3
Group1
Group2
User1
User2
User3
User4
Users Groups Roles 1 : 1 Applications 1 : 1 Privileges
Read
(None)
Read, Update
Read
Read
(None)
Read, Update
Read
(None)
Read, Update
n : n n : n
CUCM User Accounts 117
CUCM has various Administration web pages associated with functions, such as the Call
Park web pages (used to the configure call park feature), the AAR Group web pages (used
to configure automated alternate routing), the CallManager group web pages (for CUCM
configuration), and the DRF Show Status page (used to check the status of Disaster
Recovery System backup or restore jobs).
CUCM has many default roles, called standard roles. Some of the standard roles are
associated with CUCM Administration applications (CCMAdmin). There are many
predefined roles in CUCM by default, but we explore two in this example. Two standard roles
for CUCM Administration exist: Standard CCMAdmin Administration and Standard
CCMAdmin Read-Only. Standard CCMAdmin Administration has all privileges of the
CCMAdmin application set to Update, whereas Standard CCMAdmin Read-Only has
CCMAdmin privileges set to Read-Only Access. Standard roles can be copied, renamed,
and reconfigured to achieve the needs of the organization deploying CUCM.
CUCM has many default user groups, called standard user groups. Two examples of standard
user groups are Standard CCM Super Users and Standard CCM Read-Only. User group
Standard CCM Super Users is associated with role Standard CCMAdmin Administration,
and user group Standard CCM Read-Only is associated with role Standard CCMAdmin
Read-Only. This is illustrated in Figure 6-2.
To assign an end user full access to all configuration pages of CUCM Administration, you have
to assign the end user just to the Standard CCM Super Users group. End users who should
have read-only access to all configuration pages of CUCM Administration just have to be
assigned to the Standard CCMAdmin Read-Only user group. The appropriate application
privileges are configured in the default roles, and the default roles are assigned to the
corresponding user groups.
The final step required to achieve the objective of Figure 6-2 is to assign the users John and
Jane to the Standard CCM Super Users group and to assign Kim and Tom to the Standard
CCM Read-Only user group.
Figure 6-2 Roles and User Groups
User Group
Standard CCM Super
Users
• User “John Doe”
• User “Jane Smith”
Standard
CCMADMIN
Administration
Standard
CCMADMIN
Read-Only
Standard CCM Read-
Only
• User “Kim Lu”
• User “Tom Adams”
Role
Cisco
CallManager
Administration
• Call Park Web
Pages
• AAR Group
Web Pages
• CallManager
Group Web
Pages
• DRF Show
Status Page
• ...
Cisco
CallManager
Administration
Application Resource Privilege
Update
Read-Only
118 Chapter 6: Managing User Accounts
User Management
User management options in CUCM include the following:
■ CUCM Administration: Suitable for configuring a small number of users or doing
single updates to the configuration of a user. CUCM administration of users is not
scalable for large deployments of CUCM.
■ Bulk Administration tool (BAT): BAT is a tool that allows large insertions, updates,
and deletions of users when LDAPv3 synchronization is not leveraged. Many learning
institutions have frequent changes to the user database. BAT is an excellent tool for
initial deployment or large updates to many configuration options, including the user
database.
■ LDAPv3 integration: LDAPv3 integration allows end users to be synchronized from
a centralized database to CUCM. This option proves useful when all the end users
already exist in an LDAPv3 database. LDAPv3 user synchronization is available only
to end users. LDAPv3 authentication is another LDAPv3 feature that can be leveraged.
LDAPv3 authentication passes any authentication requests through the CUCM server
to the LDAPv3 server where the user login is authenticated. LDAPv3 authentication
has the benefit of maintaining one central password database. CUCM does not replicate
the passwords that are configured in the central LDAPv3 database.
LDAPv3 synchronization replicates data to the CUCM database. User data cannot be
modified from CUCM administration tools when LDAPv3 synchronization is enabled.
User data is modified on the LDAPv3 server by the LDAPv3 administrator, and
NOTE CUCM has numerous default user groups that cover the needs of most
requirements. Examples of default user groups include the following:
■ CCM Super Users
■ Standard CCMAdmin Read-Only
■ Standard CAR Admin Users
■ Standard CCM Server Maintenance
■ Standard CCM Server Monitoring
■ Standard CCM Phone Administration
■ Standard CCM End User
■ Standard CCM Gateway Administration
CUCM User Accounts 119
resynchronization will occur at the next resynchronization interval. Depending on the
resynchronization schedule, the resynchronization event might not occur for days or weeks.
Manual synchronization can be performed at any time.
Passwords are not replicated to the CUCM database when LDAPv3 authentication is turned
on. User passwords may exist in both CUCM and the LDAPv3 server if the user exists in
both servers. It is recommended to combine LDAPv3 authentication with LDAPv3
synchronization to avoid inconsistencies in usernames and to eliminate the need for
maintaining multiple usernames.
Table 6-2 summarizes the differences between the local CUCM database, LDAPv3
synchronization, and LDAPv3 authentication.
Managing User Accounts
CUCM user management is performed from the Cisco Unified Communications Manager
Administration User Management menu. The administrator must use an account with user
management privileges. Any end-user account that has the user management privilege
assigned can modify user accounts (including the CCMAdministrator).
The User Management menu includes options to configure application users, end users,
roles, and user groups, as shown in Figure 6-3.
Table 6-2 End-User Data Location
No LDAPv3
Integration
LDAPv3
Synchronization
LDAPv3
Authentication
User ID, First Name, Middle Name,
Last Name, Manager User ID,
Department, Phone Number,
Mail ID
Local database LDAPv3
(replicated to
local database)
LDAPv3
(replicated to
local database)
Password Local database Local database LDAPv3
PIN, Digest Credentials, Groups,
Roles, Associated PCs, Controlled
Devices, Extension Mobility
Profile, CAPF Presence Group,
Mobility
Local database Local database Local database
120 Chapter 6: Managing User Accounts
Figure 6-3 User Management Menu
Figure 6-4 shows the Application User Configuration page. The most important settings are
the user ID and the password. The user ID and password must match on the application
server if the application user is configured for integration with another server. The application
user could be associated with multiple devices (phones, CTI route points, and pilot points).
Navigate to User Management > Application User from the CUCMAdministration to add
an application user. Click the Add New button.
Figure 6-4 Application User Configuration
CUCM User Accounts 121
At the bottom of the Application User Configuration page, the application user can be
added to user groups, as shown in Figure 6-5. The roles that are assigned to the user groups
are listed in the Roles field under the Groups field.
Figure 6-5 Application User Group Configuration
The End User Configuration page is similar to the Application User Configuration page.
User ID, password, and group membership are the most important settings. Figure 6-6
displays the End User Configuration page in CUCM. Navigate to User Management > End
User to add an end user in CUCM Administration. Click the Add New button.
Standard roles cannot be deleted or modified. Custom roles, however, can be created from
scratch or by copying and then modifying a standard role. Figure 6-7 shows an abbreviated
listing of CUCM roles. Navigate to User Management > Role to find an existing role
configuration. Click the Find button to display all existing roles. Click Find.
Add Application User to User Groups
View Roles of Application User
122 Chapter 6: Managing User Accounts
Figure 6-6 End User Configuration
Figure 6-7 Default Role Configuration
Figure 6-8 displays the Role Configuration page. When configuring a new role, you have to
select an application on the configuration web page. The application resources will be
displayed and read, or update privilege can be assigned to each. The Role Configuration
pages are accessible via User Management > Role in CUCM Administration.
CUCM User Accounts 123
Figure 6-8 Role Configuration Page
Standard user groups cannot be deleted or modified. Custom user groups can be created
from scratch or by copying an existing user group. Figure 6-9 displays an abbreviated list
of the default user groups. Navigate to User Management > User Group and click the Find
button to display existing user groups. Click Find. Click a user group.
Figure 6-9 Default User Groups
Selected Application
Configured Privilege per Application Resource
124 Chapter 6: Managing User Accounts
Figure 6-10 displays the User Group Configuration page in which users can be added to a
user group. In this example, the Standard CCM Super Users Group was selected.
Figure 6-10 User Group Configuration
Figure 6-11 displays the end-user addition to a user group. Click the Add End Users to
Group button of Figure 6-10 to display the user search page displayed in Figure 6-12. Enter
a search string and click Find. Select the user by checking the box next to the user, and then
click Add Selected.
Figure 6-11 User Group Configuration
Assign roles to a user group by selecting the Assign Role to User Group item from the
Related Links list box in the upper right of the User Group Configuration page. A new
window will display where you can assign or delete roles, as shown in Figure 6-12.
Lightweight Directory Access Protocol 125
Figure 6-12 User Group Role Assignment
Click the Add Role to Group button. Select the roles that you would like to add, as shown
in Figure 6-13, and then click the Add Selected button.
Wednesday, December 15, 2010
Global Server Settings Best Cisco CCIE Training Institute in Delhi Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Two types of settings parameters can be changed in CUCM globally across a server or
globally across the cluster: enterprise parameters and service parameters.
Enterprise Parameters
Enterprise parameters are used to define cluster-wide system settings, and they 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 will specify initial values of device defaults.
CAUTION Only change enterprise parameters if you are fully aware of the impact of
your modifications or if instructed to do so by Cisco Technical Assistance Center (TAC).
Network and Feature Services 101
Figure 5-10 Control Center
You can modify many enterprise parameters. Table 5-3 displays some frequently modified
enterprise parameters.
Table 5-3 Enterprise Parameters
Parameter Description Default Value
Auto Registration Phone
Protocol
Specifies the protocol that autoregistered
phones should boot
with during initialization
SCCP
Enable Dependency Records Determines whether to display
dependency records
False
continues
Activation status
Current status Service start time and up time
Start, stop, restart, refresh
selected service
Select service to
start, stop, or restart
102 Chapter 5: Initial Configuration Settings
Dependency records are a feature of CUCM that enable an administrator to view
configuration database records that reference the currently displayed record. Dependency
record reports can be run by using the Related Links drop-down menu in most configuration
pages throughout CUCM Administration. Dependency record reports search the database
and return links to all configuration items that include the configuration detail in question.
Dependency record reports are useful when CUCM will not allow a configuration element
to be deleted because it is in use somewhere in the system but should no longer be in use.
Because dependency records could cause a CPU spike in the server platform, it is not
recommended that they be run during high-usage periods.
To modify enterprise parameters, follow these steps in the CUCM Administration web
interface:
Step 1 Navigate to System > Enterprise Parameters.
Step 2 Change the enterprise parameter values as desired and save the changes.
Figure 5-11 shows the procedure to hide configuration elements from the CCMUser
configuration pages. A business might not want end users to be able to change the Call
CCMUser Parameters Display or hide certain userconfigurable
settings from the
CCMUser web page
Not applicable
Phone URL Parameters URLs for IP phone
authentication, Directory
button, Services button, and
so on
Hostnames rather than IP
addresses
User Search Limit Specifies the maximum number
of users to be retrieved from a
search in the Corporate
Directory feature on the phone
64
NOTE To obtain additional information about specific enterprise parameters, click the
? symbol in the upper-right corner of the screen. The same help system is available by
clicking the hyperlink of the enterprise parameter name.
Table 5-3 Enterprise Parameters (Continued)
Parameter Description Default Value
Network and Feature Services 103
Forward All options of their phone in the CCMUser configuration pages, but the option
exists in the page by default. Using the enterprise parameter options shown in Figure 5-11,
the administrator can choose to remove the hyperlink to Call Forward All in the CCMUser
section of the Enterprise Parameters Configuration page. All default settings appear on the
right side of the Enterprise Parameter Configurations page.
Figure 5-11 Enterprise Parameter Configuration
When you are removing DNS reliance, all hostnames within enterprise URL parameters
have to be changed to IP addresses. Phone URL parameters change the website that the
phone launches when the settings, services, or directories buttons are clicked on the Cisco
IP Phone. The phone URL parameters are part of the enterprise parameters. Figure 5-12
shows the configuration of the phone URL parameters.
1. Select the new setting Default setting
2. Save the changes
104 Chapter 5: Initial Configuration Settings
Figure 5-12 Phone URL Parameters
Service Parameters
Service parameters are used to define settings for a specific service (for example, the callprocessing
CallManager service). They can be configured separately 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. The most
important service parameters for the CallManager service are as follows:
■ T302 timer: The T.303 interdigit timeout specifies the interdigit timeout value used to
route calls when there are multiple possible matches in the database. Multiple possible
matches is a condition that will exist when variable-length numbers (international) or
overlapping dial plans are being analyzed by CUCM. Reducing the default T.302 value
will accelerate the call-routing decision of CUCM when users dial international phone
numbers or a phone number that overlaps with another. The default T.302 timer is
15,000-ms (15 seconds). A value of 15 seconds is too long for most environments. Best
practice is to reconfigure this timer to a value of 5000 ms (5 seconds). An example of
an overlapping dial plan is extension 1500 and extension 15001. CUCM would not
know whether it was done receiving digits if the digits of 1500 were received. The user
might dial another 1, which would direct the call to a different extension. In this situation,
CUCM waits for the T.302 timer to expire and then extends the call to extension 1500.
Network and Feature Services 105
■ CDR and CMR: CDRs are the basis for call reporting, accounting, and billing. The
service parameters are used to enable CDRs and CMRs. CMRs report QoS information
related to the phone call (lost packets, average jitter, maximum jitter, and so forth).
■ Cisco Unified Extension Mobility maximum login time: After expiration of this
timer, a user is logged out of Cisco Unified Extension Mobility.
■ Cisco Unified Attendant Console username: Specifies the application username that
is used by the Cisco Unified Attendant Console application when logging in to the
CUCM Computer Telephony Integration (CTI) interface.
By default, not all service parameters display. To see the complete list of service parameters,
click the Advanced button. The Change B-Channel Maintenance Status service parameter
is an example of a CallManager service parameter that does not show by default. Table 5-4
includes some frequently modified service parameters. Hundreds of service parameters are
available to CUCM, many of which you will never encounter. The best way to find one of
the parameters listed in Table 5-4 is to use the Find function of your web browser to locate
the option on the page.
Table 5-4 Service Parameter Examples
Parameter Description Default Value
CDR Enabled Flag This parameter determines whether CDRs are
generated.
False
Station Keepalive Interval This parameter designates the interval between
keepalive messages sent from Cisco IP Phones to the
primary CUCM.
30 seconds
T302 Timer This parameter specifies an interdigit timer for
sending the setup acknowledgment message. When
this timer expires, CUCM routes the dialed digits.
15 seconds
Automated Alternate
Routing Enable
This parameter determines whether to use automated
alternate routing when the system does not have
enough bandwidth.
False
Change B-Channel
Maintenance Status (click
Advanced button first)
This parameter allows CUCM to change individual B
channel maintenance status for PRI and CAS
interfaces in real time for troubleshooting.
No default
106 Chapter 5: Initial Configuration Settings
To modify service parameters, follow these steps in the CUCM Administration web
interface:
Step 1 Navigate to System > Service Parameters.
Step 2 Select the server and the service for which you want to change service
parameters.
Step 3 Change the service parameter values as desired and save the changes.
Step 4 Click Save.
Steps 2 through 4 are illustrated in Figures 5-13 and 5-14.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Two types of settings parameters can be changed in CUCM globally across a server or
globally across the cluster: enterprise parameters and service parameters.
Enterprise Parameters
Enterprise parameters are used to define cluster-wide system settings, and they 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 will specify initial values of device defaults.
CAUTION Only change enterprise parameters if you are fully aware of the impact of
your modifications or if instructed to do so by Cisco Technical Assistance Center (TAC).
Network and Feature Services 101
Figure 5-10 Control Center
You can modify many enterprise parameters. Table 5-3 displays some frequently modified
enterprise parameters.
Table 5-3 Enterprise Parameters
Parameter Description Default Value
Auto Registration Phone
Protocol
Specifies the protocol that autoregistered
phones should boot
with during initialization
SCCP
Enable Dependency Records Determines whether to display
dependency records
False
continues
Activation status
Current status Service start time and up time
Start, stop, restart, refresh
selected service
Select service to
start, stop, or restart
102 Chapter 5: Initial Configuration Settings
Dependency records are a feature of CUCM that enable an administrator to view
configuration database records that reference the currently displayed record. Dependency
record reports can be run by using the Related Links drop-down menu in most configuration
pages throughout CUCM Administration. Dependency record reports search the database
and return links to all configuration items that include the configuration detail in question.
Dependency record reports are useful when CUCM will not allow a configuration element
to be deleted because it is in use somewhere in the system but should no longer be in use.
Because dependency records could cause a CPU spike in the server platform, it is not
recommended that they be run during high-usage periods.
To modify enterprise parameters, follow these steps in the CUCM Administration web
interface:
Step 1 Navigate to System > Enterprise Parameters.
Step 2 Change the enterprise parameter values as desired and save the changes.
Figure 5-11 shows the procedure to hide configuration elements from the CCMUser
configuration pages. A business might not want end users to be able to change the Call
CCMUser Parameters Display or hide certain userconfigurable
settings from the
CCMUser web page
Not applicable
Phone URL Parameters URLs for IP phone
authentication, Directory
button, Services button, and
so on
Hostnames rather than IP
addresses
User Search Limit Specifies the maximum number
of users to be retrieved from a
search in the Corporate
Directory feature on the phone
64
NOTE To obtain additional information about specific enterprise parameters, click the
? symbol in the upper-right corner of the screen. The same help system is available by
clicking the hyperlink of the enterprise parameter name.
Table 5-3 Enterprise Parameters (Continued)
Parameter Description Default Value
Network and Feature Services 103
Forward All options of their phone in the CCMUser configuration pages, but the option
exists in the page by default. Using the enterprise parameter options shown in Figure 5-11,
the administrator can choose to remove the hyperlink to Call Forward All in the CCMUser
section of the Enterprise Parameters Configuration page. All default settings appear on the
right side of the Enterprise Parameter Configurations page.
Figure 5-11 Enterprise Parameter Configuration
When you are removing DNS reliance, all hostnames within enterprise URL parameters
have to be changed to IP addresses. Phone URL parameters change the website that the
phone launches when the settings, services, or directories buttons are clicked on the Cisco
IP Phone. The phone URL parameters are part of the enterprise parameters. Figure 5-12
shows the configuration of the phone URL parameters.
1. Select the new setting Default setting
2. Save the changes
104 Chapter 5: Initial Configuration Settings
Figure 5-12 Phone URL Parameters
Service Parameters
Service parameters are used to define settings for a specific service (for example, the callprocessing
CallManager service). They can be configured separately 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. The most
important service parameters for the CallManager service are as follows:
■ T302 timer: The T.303 interdigit timeout specifies the interdigit timeout value used to
route calls when there are multiple possible matches in the database. Multiple possible
matches is a condition that will exist when variable-length numbers (international) or
overlapping dial plans are being analyzed by CUCM. Reducing the default T.302 value
will accelerate the call-routing decision of CUCM when users dial international phone
numbers or a phone number that overlaps with another. The default T.302 timer is
15,000-ms (15 seconds). A value of 15 seconds is too long for most environments. Best
practice is to reconfigure this timer to a value of 5000 ms (5 seconds). An example of
an overlapping dial plan is extension 1500 and extension 15001. CUCM would not
know whether it was done receiving digits if the digits of 1500 were received. The user
might dial another 1, which would direct the call to a different extension. In this situation,
CUCM waits for the T.302 timer to expire and then extends the call to extension 1500.
Network and Feature Services 105
■ CDR and CMR: CDRs are the basis for call reporting, accounting, and billing. The
service parameters are used to enable CDRs and CMRs. CMRs report QoS information
related to the phone call (lost packets, average jitter, maximum jitter, and so forth).
■ Cisco Unified Extension Mobility maximum login time: After expiration of this
timer, a user is logged out of Cisco Unified Extension Mobility.
■ Cisco Unified Attendant Console username: Specifies the application username that
is used by the Cisco Unified Attendant Console application when logging in to the
CUCM Computer Telephony Integration (CTI) interface.
By default, not all service parameters display. To see the complete list of service parameters,
click the Advanced button. The Change B-Channel Maintenance Status service parameter
is an example of a CallManager service parameter that does not show by default. Table 5-4
includes some frequently modified service parameters. Hundreds of service parameters are
available to CUCM, many of which you will never encounter. The best way to find one of
the parameters listed in Table 5-4 is to use the Find function of your web browser to locate
the option on the page.
Table 5-4 Service Parameter Examples
Parameter Description Default Value
CDR Enabled Flag This parameter determines whether CDRs are
generated.
False
Station Keepalive Interval This parameter designates the interval between
keepalive messages sent from Cisco IP Phones to the
primary CUCM.
30 seconds
T302 Timer This parameter specifies an interdigit timer for
sending the setup acknowledgment message. When
this timer expires, CUCM routes the dialed digits.
15 seconds
Automated Alternate
Routing Enable
This parameter determines whether to use automated
alternate routing when the system does not have
enough bandwidth.
False
Change B-Channel
Maintenance Status (click
Advanced button first)
This parameter allows CUCM to change individual B
channel maintenance status for PRI and CAS
interfaces in real time for troubleshooting.
No default
106 Chapter 5: Initial Configuration Settings
To modify service parameters, follow these steps in the CUCM Administration web
interface:
Step 1 Navigate to System > Service Parameters.
Step 2 Select the server and the service for which you want to change service
parameters.
Step 3 Change the service parameter values as desired and save the changes.
Step 4 Click Save.
Steps 2 through 4 are illustrated in Figures 5-13 and 5-14.
Network and Feature Services Best Cisco CCSP Coaching Institute in Delhi Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
A CUCM cluster can consist of up to 20 servers. Each server 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 a server, different services have to be activated on the system.
There are two types of services on CUCM servers:
■ Network services: Network services are automatically activated and are required for
the operation of the server. Network services cannot be activated or deactivated by the
administrator, but they can be stopped, started, or restarted from the Cisco Unified
Serviceability web interface. Just choose Control Center > Network Services.
NOTE Repeat Steps 2 and 3 for each server in the cluster.
98 Chapter 5: Initial Configuration Settings
■ Feature services: Feature services can be selectively activated or deactivated per
server to assign specific tasks or functions (call processing, TFTP, and so on) to a
certain server. Feature services can be activated and deactivated by the administrator
from the Cisco Unified Serviceability web interface (Tools > Service Activation).
Feature services can be started, stopped, or restarted from the Cisco Unified
Serviceability web interface (Control Center > Feature Services).
Network Services
Network services are the operating system services that CUCM relies on. Network services
are summarized as follows:
■ Performance and monitoring services: Cisco CallManager Serviceability RTMT,
Cisco RTMT Reporter
■ Backup and restore services: Cisco DRF Master, Cisco DRF Local System Services:
Cisco CallManager Serviceability, Cisco CDP, Cisco Trace Collection Service
■ Platform services: Cisco Database, Cisco Tomcat, SNMP Master Agent
■ DB services: Cisco Database Layer Monitor
■ SOAP services: SOAP Real Time Service APIs and so on
■ CM services: Cisco CallManager Personal Directory, Cisco Extension Mobility
Application, Cisco CallManager Cisco IP Phone Services
■ CDR services: Cisco CDR Repository Manager, CDR Agent
■ Admin services: Cisco CallManager Admin
Feature Services
Feature services are the CUCM-related services that run on top of the operating system and
database. Feature services are summarized as follows:
■ Database and admin services: Cisco AXL Web Service, Cisco Bulk Provisioning
Service, Cisco TAPS Service
Network and Feature Services 99
■ Performance and monitoring services: Cisco Serviceability Reporter, Cisco
CallManager SNMP Service
■ CM services: Cisco CallManager, Cisco TFTP, Cisco CTIManager, Cisco Extension
Mobility
■ CTI services: Cisco CallManager Attendant Console Server, Cisco IP Manager
Assistant, Cisco WebDialer Web Service
■ CDR services: Cisco SOAP, including CDRonDemand Service, Cisco CAR Scheduler,
Cisco CAR Web Service
■ Security services: Cisco CTL Provider, Cisco Certificate Proxy Function
■ Directory Services: Cisco DirSync
■ Voice Quality Reporter Services: Cisco Extended Functions
Service Activation
To activate or deactivate feature services for a server, follow these steps in the Cisco Unified
Serviceability web interface:
Step 1 Go to Tools > Service Activation.
Step 2 Select the server where you want to activate or deactivate a service.
Step 3 Check or uncheck the check box for each service you want to modify, and
save the changes.
Step 4 Use the Control Center to verify that the service has been started (Tools >
Control Center – Feature Services).
Figure 5-9 illustrates the Service Activation configuration page in CUCM. The Related
Links drop-down menus in the upper-right portion of the CUCM web pages hyperlink to
different areas of CUCM configuration. Learning how to leverage the related links can
increase the speed in which you can provision services in CUCM.
Control Center
The Control Center for feature services is used to start, stop, or restart services. It is also
used to verify the current status and the activation status of feature services per server in the
cluster.
100 Chapter 5: Initial Configuration Settings
Figure 5-9 Service Activation
Figure 5-10 illustrates the process of viewing a service status and runtime. The figure also
shows the process of selecting the radio button related to a particular service so that the
service can be started, stopped, restarted, or refreshed.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
A CUCM cluster can consist of up to 20 servers. Each server 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 a server, different services have to be activated on the system.
There are two types of services on CUCM servers:
■ Network services: Network services are automatically activated and are required for
the operation of the server. Network services cannot be activated or deactivated by the
administrator, but they can be stopped, started, or restarted from the Cisco Unified
Serviceability web interface. Just choose Control Center > Network Services.
NOTE Repeat Steps 2 and 3 for each server in the cluster.
98 Chapter 5: Initial Configuration Settings
■ Feature services: Feature services can be selectively activated or deactivated per
server to assign specific tasks or functions (call processing, TFTP, and so on) to a
certain server. Feature services can be activated and deactivated by the administrator
from the Cisco Unified Serviceability web interface (Tools > Service Activation).
Feature services can be started, stopped, or restarted from the Cisco Unified
Serviceability web interface (Control Center > Feature Services).
Network Services
Network services are the operating system services that CUCM relies on. Network services
are summarized as follows:
■ Performance and monitoring services: Cisco CallManager Serviceability RTMT,
Cisco RTMT Reporter
■ Backup and restore services: Cisco DRF Master, Cisco DRF Local System Services:
Cisco CallManager Serviceability, Cisco CDP, Cisco Trace Collection Service
■ Platform services: Cisco Database, Cisco Tomcat, SNMP Master Agent
■ DB services: Cisco Database Layer Monitor
■ SOAP services: SOAP Real Time Service APIs and so on
■ CM services: Cisco CallManager Personal Directory, Cisco Extension Mobility
Application, Cisco CallManager Cisco IP Phone Services
■ CDR services: Cisco CDR Repository Manager, CDR Agent
■ Admin services: Cisco CallManager Admin
Feature Services
Feature services are the CUCM-related services that run on top of the operating system and
database. Feature services are summarized as follows:
■ Database and admin services: Cisco AXL Web Service, Cisco Bulk Provisioning
Service, Cisco TAPS Service
Network and Feature Services 99
■ Performance and monitoring services: Cisco Serviceability Reporter, Cisco
CallManager SNMP Service
■ CM services: Cisco CallManager, Cisco TFTP, Cisco CTIManager, Cisco Extension
Mobility
■ CTI services: Cisco CallManager Attendant Console Server, Cisco IP Manager
Assistant, Cisco WebDialer Web Service
■ CDR services: Cisco SOAP, including CDRonDemand Service, Cisco CAR Scheduler,
Cisco CAR Web Service
■ Security services: Cisco CTL Provider, Cisco Certificate Proxy Function
■ Directory Services: Cisco DirSync
■ Voice Quality Reporter Services: Cisco Extended Functions
Service Activation
To activate or deactivate feature services for a server, follow these steps in the Cisco Unified
Serviceability web interface:
Step 1 Go to Tools > Service Activation.
Step 2 Select the server where you want to activate or deactivate a service.
Step 3 Check or uncheck the check box for each service you want to modify, and
save the changes.
Step 4 Use the Control Center to verify that the service has been started (Tools >
Control Center – Feature Services).
Figure 5-9 illustrates the Service Activation configuration page in CUCM. The Related
Links drop-down menus in the upper-right portion of the CUCM web pages hyperlink to
different areas of CUCM configuration. Learning how to leverage the related links can
increase the speed in which you can provision services in CUCM.
Control Center
The Control Center for feature services is used to start, stop, or restart services. It is also
used to verify the current status and the activation status of feature services per server in the
cluster.
100 Chapter 5: Initial Configuration Settings
Figure 5-9 Service Activation
Figure 5-10 illustrates the process of viewing a service status and runtime. The figure also
shows the process of selecting the radio button related to a particular service so that the
service can be started, stopped, restarted, or refreshed.
DHCP Best Cisco CCNP Coaching Institutein Delhi Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The CUCM DHCP server is designed to serve IP phones in small deployments (maximum
of 1000 devices). It provides a subset of the functionality that was provided by the Windows
2000 Server in CUCM versions earlier than CallManager 5.0.
Only one DHCP server can be configured per CUCM cluster; no backup configuration is
possible. The CUCM DHCP server can be configured with multiple subnets. DHCP relay
must be enabled in remote subnets to allow the DHCP broadcast request packets to be
forwarded to the DHCP server. Routers drop all broadcast packets by default, but the
packets can be configured with DHCP relay by using the ip helper-address command.
To configure DHCP support on CUCM, follow these steps:
Step 1 Activate the DHCP Monitor Service.
Step 2 Add and configure the DHCP server.
Step 3 Configure the DHCP subnets.
Navigate to the Cisco Unified Serviceability web pages. From the Tools menu, choose
Service Activation. Activate the DHCP Monitor Service by clicking the DHCP Monitor
Service check box and then clicking the Save icon. Figure 5-3 is a screen capture of the
DHCP Monitor Service activation.
The DHCP server then needs to be configured. Configure the DHCP server from the CUCM
Administration page. Navigate to System > DHCP > DHCP Server. The Find and List
DHCP Servers page will display. Click the Add New button. Choose the CUCM server that
will be acting as the DHCP server from the Host Server drop-down menu. Configure the
Primary TFTP Server IP Address field and the Secondary TFTP Server IP Address field. It
is advisable to have two CUCM servers running the TFTP service for fault-tolerance
purposes. Figure 5-4 shows the DHCP server configuration page options.
NOTE Due to the CPU load impact, CUCM DHCP server must not be used in deployments
larger than 1000 registered devices. The CPU load of the server can be monitored
using the Real-Time Monitoring Tool (RTMT). If high CPU load is experienced, the
DHCP service should be provided by other devices (DHCP server, switch, or router).
RTMT is covered in Cisco Unified Communications IP Telephony, Part 2.
CUCM Initial Configuration 93
Figure 5-3 Service Activation: DHCP Monitor Service
Figure 5-4 DHCP Server Configuration
94 Chapter 5: Initial Configuration Settings
The DHCP subnet(s) needs to be configured from the CUCM Administration page.
Navigate to System > DHCP > DHCP Subnet. The Find and List DHCP Subnets page will
display. Click the Add New button. Choose the DHCP server from the DHCP Server dropdown
menu. This is a required field. All fields in the configuration pages that have an
asterisk (*) to the upper right of the configuration option are required fields. Specify the
subnet IP address, IP address range, primary router IP address, subnet mask, and TFTP
servers. Figure 5-5 displays the DHCP subnet configuration page options.
Figure 5-5 DHCP Subnet Configuration
In CUCM releases earlier than 5.0, DHCP services could be provided by the Windowsbased
operating system of CUCM. If the Windows DHCP server was used and CUCM is
upgraded to a CUCM release running the Linux operating system, all DHCP configuration
is lost. The Data Migration Assistant (DMA) does not migrate Windows DHCP configuration.
DHCP can configured on CUCM servers beginning with Release 5.0.
DNS
CUCM can use either 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.
CUCM Initial Configuration 95
Both methods have some advantages:
■ Using IP addresses: The system does not depend on a DNS server. This prevents loss
of service when the DNS server cannot be reached. Clients, using DNS, query the
server with a name lookup request and receive a reply in which the DNS server resolves
the hostname record of the query to an IP address. Eliminating the requirement of a DNS
server reduces the danger of DNS configuration errors, DNS outages, and the latency
issues involved in sending a query and receiving a response using the DNS model.
Troubleshooting is simplified when using IP addresses rather than DNS names because
there is no need to perform name resolution.
■ Using DNS: Management is simplified because logical names are easier to remember
than IP addresses. If IP addresses change, there is no need to modify any of the application
settings that rely on the existing IP address. When DNS is used, the applications point
to a DNS name that does not change; the underlying IP address might change at any
time with no consequence to the IP addresses that rely on the server. CUCM server
addressing is sent to Cisco IP Phones in the CUCM group in the phone’s XML
configuration file. The addressing sent down to the IP phone can be based on IP
addresses or names.
Because of the additional point of failure introduced using DNS, the Cisco best
practices recommendation is to not use DNS with CUCM.
Table 5-2 summarizes the advantages and disadvantage of using DNS with CUCM.
Before the IP phone can communicate with CUCM, it has to resolve the name of the server.
Signaling messages are then exchanged between the Cisco IP Phone and CUCM, as
illustrated in Figure 5-6.
Table 5-2 IP Addressing and DNS Comparison
IP Addressing Advantages DNS Advantages
Does not require a DNS server Simplifies management because of the use of
names rather than numbers
Prevents the IP telephony network from failing if
the IP phones lose connection to the DNS server
Enables easier IP address changes because of
name-based IP paths
Decreases the amount of time required when a
device attempts to contact the Unified CM server
Allows server to IP phone NAT
Simplifies troubleshooting
96 Chapter 5: Initial Configuration Settings
Figure 5-6 Call Flow with DNS
When DNS naming is not used in the CUCM cluster, there is no need to resolve the name
of the CUCM to an IP address. The signaling between the IP phone and CUCM can be set
up faster, and calls can be processed even if the DNS service is not available. CUCM will
have higher availability and faster response times by removing any DNS reliance. Call flow
without the use of DNS is illustrated in Figure 5-7.
Figure 5-7 Call Flow Without DNS
IP Phone A IP Phone B
2) Signaling Protocol
3) RTP Media Path
2) Signaling Protocol
1) DNS Query/Response 1) DNS Query/Response
DNS Server
IP Phone A IP Phone B
1) Signaling Protocol
2) RTP Media Path
1) Signaling Protocol
Network and Feature Services 97
To change the system to operate without a DNS server, follow these steps:
Step 1 In CUCM Administration, go to System > Server.
Step 2 Click the Find button and select the first (next) available server from the
list of CUCM servers.
Step 3 Change the server name to the IP address of the server and save the
changes, as shown in Figure 5-8.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The CUCM DHCP server is designed to serve IP phones in small deployments (maximum
of 1000 devices). It provides a subset of the functionality that was provided by the Windows
2000 Server in CUCM versions earlier than CallManager 5.0.
Only one DHCP server can be configured per CUCM cluster; no backup configuration is
possible. The CUCM DHCP server can be configured with multiple subnets. DHCP relay
must be enabled in remote subnets to allow the DHCP broadcast request packets to be
forwarded to the DHCP server. Routers drop all broadcast packets by default, but the
packets can be configured with DHCP relay by using the ip helper-address command.
To configure DHCP support on CUCM, follow these steps:
Step 1 Activate the DHCP Monitor Service.
Step 2 Add and configure the DHCP server.
Step 3 Configure the DHCP subnets.
Navigate to the Cisco Unified Serviceability web pages. From the Tools menu, choose
Service Activation. Activate the DHCP Monitor Service by clicking the DHCP Monitor
Service check box and then clicking the Save icon. Figure 5-3 is a screen capture of the
DHCP Monitor Service activation.
The DHCP server then needs to be configured. Configure the DHCP server from the CUCM
Administration page. Navigate to System > DHCP > DHCP Server. The Find and List
DHCP Servers page will display. Click the Add New button. Choose the CUCM server that
will be acting as the DHCP server from the Host Server drop-down menu. Configure the
Primary TFTP Server IP Address field and the Secondary TFTP Server IP Address field. It
is advisable to have two CUCM servers running the TFTP service for fault-tolerance
purposes. Figure 5-4 shows the DHCP server configuration page options.
NOTE Due to the CPU load impact, CUCM DHCP server must not be used in deployments
larger than 1000 registered devices. The CPU load of the server can be monitored
using the Real-Time Monitoring Tool (RTMT). If high CPU load is experienced, the
DHCP service should be provided by other devices (DHCP server, switch, or router).
RTMT is covered in Cisco Unified Communications IP Telephony, Part 2.
CUCM Initial Configuration 93
Figure 5-3 Service Activation: DHCP Monitor Service
Figure 5-4 DHCP Server Configuration
94 Chapter 5: Initial Configuration Settings
The DHCP subnet(s) needs to be configured from the CUCM Administration page.
Navigate to System > DHCP > DHCP Subnet. The Find and List DHCP Subnets page will
display. Click the Add New button. Choose the DHCP server from the DHCP Server dropdown
menu. This is a required field. All fields in the configuration pages that have an
asterisk (*) to the upper right of the configuration option are required fields. Specify the
subnet IP address, IP address range, primary router IP address, subnet mask, and TFTP
servers. Figure 5-5 displays the DHCP subnet configuration page options.
Figure 5-5 DHCP Subnet Configuration
In CUCM releases earlier than 5.0, DHCP services could be provided by the Windowsbased
operating system of CUCM. If the Windows DHCP server was used and CUCM is
upgraded to a CUCM release running the Linux operating system, all DHCP configuration
is lost. The Data Migration Assistant (DMA) does not migrate Windows DHCP configuration.
DHCP can configured on CUCM servers beginning with Release 5.0.
DNS
CUCM can use either 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.
CUCM Initial Configuration 95
Both methods have some advantages:
■ Using IP addresses: The system does not depend on a DNS server. This prevents loss
of service when the DNS server cannot be reached. Clients, using DNS, query the
server with a name lookup request and receive a reply in which the DNS server resolves
the hostname record of the query to an IP address. Eliminating the requirement of a DNS
server reduces the danger of DNS configuration errors, DNS outages, and the latency
issues involved in sending a query and receiving a response using the DNS model.
Troubleshooting is simplified when using IP addresses rather than DNS names because
there is no need to perform name resolution.
■ Using DNS: Management is simplified because logical names are easier to remember
than IP addresses. If IP addresses change, there is no need to modify any of the application
settings that rely on the existing IP address. When DNS is used, the applications point
to a DNS name that does not change; the underlying IP address might change at any
time with no consequence to the IP addresses that rely on the server. CUCM server
addressing is sent to Cisco IP Phones in the CUCM group in the phone’s XML
configuration file. The addressing sent down to the IP phone can be based on IP
addresses or names.
Because of the additional point of failure introduced using DNS, the Cisco best
practices recommendation is to not use DNS with CUCM.
Table 5-2 summarizes the advantages and disadvantage of using DNS with CUCM.
Before the IP phone can communicate with CUCM, it has to resolve the name of the server.
Signaling messages are then exchanged between the Cisco IP Phone and CUCM, as
illustrated in Figure 5-6.
Table 5-2 IP Addressing and DNS Comparison
IP Addressing Advantages DNS Advantages
Does not require a DNS server Simplifies management because of the use of
names rather than numbers
Prevents the IP telephony network from failing if
the IP phones lose connection to the DNS server
Enables easier IP address changes because of
name-based IP paths
Decreases the amount of time required when a
device attempts to contact the Unified CM server
Allows server to IP phone NAT
Simplifies troubleshooting
96 Chapter 5: Initial Configuration Settings
Figure 5-6 Call Flow with DNS
When DNS naming is not used in the CUCM cluster, there is no need to resolve the name
of the CUCM to an IP address. The signaling between the IP phone and CUCM can be set
up faster, and calls can be processed even if the DNS service is not available. CUCM will
have higher availability and faster response times by removing any DNS reliance. Call flow
without the use of DNS is illustrated in Figure 5-7.
Figure 5-7 Call Flow Without DNS
IP Phone A IP Phone B
2) Signaling Protocol
3) RTP Media Path
2) Signaling Protocol
1) DNS Query/Response 1) DNS Query/Response
DNS Server
IP Phone A IP Phone B
1) Signaling Protocol
2) RTP Media Path
1) Signaling Protocol
Network and Feature Services 97
To change the system to operate without a DNS server, follow these steps:
Step 1 In CUCM Administration, go to System > Server.
Step 2 Click the Find button and select the first (next) available server from the
list of CUCM servers.
Step 3 Change the server name to the IP address of the server and save the
changes, as shown in Figure 5-8.
CUCM Initial Configuration Best Cisco CCNA Coaching Institute in Delhi Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
After you install CUCM, some initial configuration has to be done before starting to deploy
endpoints. This initial configuration includes the items in Table 5-1.
Network Components
CUCM leverages various IP networking protocols and systems.
Network Time Protocol
Network Time Protocol (NTP) is a protocol for synchronizing the clocks of computer
systems over IP networks through use of a hierarchical clock strata organization. A stratum
level 1 timing source device is an extremely precise clock source using the rare earth element
cesium. Cesium clocks used to be very expensive, but most service providers with large
central offices now have local stratum level 1 clocks. Global positioning system (GPS)
satellites provide a stratum level 1 clocking source that provides a cost-effective synchronization
system.
Stratum level 1 clocks are distributed over networks to provide timing information to a large
number of devices. A linear relationship exists between the number of nodes passed and the
degradation of the timing quality.
Stratum level 2 timing sources are based on the rare earth element rubidium. Distribution
of stratum 2 time information becomes inaccurate more quickly than stratum 1 information.
Table 5-1 Publisher Server Required Services
Configuration Item Description
Network settings Basic network settings have already been configured during installation,
but some of them should be revisited (use of external NTP and DNS
servers), and network settings that are not configurable during
installation (for example, enabling DHCP services on CUCM) have
to be addressed before endpoint deployment.
Network and feature services CUCM servers run network services (automatically activated) and
feature services (activated by the administrator). After installation,
network services should be checked, and desired feature services
have to be activated.
Enterprise parameters CUCM has cluster-wide configuration settings called enterprise
parameters. After installation, enterprise parameter default values
should be verified and modified if required.
Service parameters CUCM services have configurable parameters that can usually be set
per CUCM server. After installation and service activation, service
parameter default values should be verified and modified if required.
CUCM Initial Configuration 89
Stratum level 2 timing is not as accurate as stratum level 1, but the timing is accurate enough
to time a large SONET node. SONET nodes are very high-speed networks that are used
by service providers to transport time-division multiplexing (TDM) voice calls through
networks operating at up to OC-192 speeds (almost 10 Gbp/s). T1 and T3 voice interfaces
are provisioned from SONET nodes, such as the Cisco ONS 15454.
Stratum level 3 timing sources are based on the rare earth element quartz, which has become
affordable enough that it is built in to most off-the-shelf wristwatches. Stratum level 3 is
accurate enough to time a SONET node, but it quickly loses accuracy when distributed to
other nodes. Most T3 (44.736 Mb/s) controllers have built-in oscillators with a stratum
level 3 timing source. T3 interfaces multiplex (28) individual T1 interfaces for a total of
672 voice channels.
CUCM has an option to use NTP to obtain time information from a time server. Only
the CUCM publisher will communicate with one or more NTP servers. The timing that the
publisher receives is synchronized to the subscriber servers. If an external NTP server is not
used, CUCM can be manually configured with the date and time. The system time in most
servers is a stratum level 4 timing source and should not be relied on to time a production
network.
Dynamic Host Configuration Protocol
Dynamic Host Configuration Protocol (DHCP) is a protocol that allows IP endpoints to
obtain their IP settings dynamically from a server. The most important settings include the
IP address, subnet mask, default gateway, TFTP server (option 150), and DNS server.
CUCM features a DHCP server that was designed to serve Cisco IP Phones only.
Trivial File Transfer Protocol
Trivial File Transfer Protocol (TFTP) is a simple file transfer protocol used by Cisco IP Phones
to obtain configuration files and their software (binary image load). A CUCM server has to
run the TFTP service on at least one server to be able to support Cisco IP Phones.
Domain Name System
Domain Name System (DNS) is a name-resolution protocol that allows IP applications to
refer to other systems by logical names rather than IP addresses. A CUCM cluster can be
configured to use either DNS or IP addresses.
NOTE More information on SONET, optical networking, and the ONS 15454 is
available in Cisco Self-Study: Building Cisco Metro Optical Networks (METRO), by
Dave Warren and Dennis Hartmann (Cisco Press, 2003).
90 Chapter 5: Initial Configuration Settings
NTP and DHCP Considerations
NTP can be configured during installation of the CUCM product. NTP can also be
configured after the installation procedure using the CUCM Administration web pages.
It is extremely important that all network devices have accurate time information because
the system time of CUCM is relevant in the following situations:
■ Cisco IP Phones display date and time information; this information is obtained from
CUCM unless an NTP reference is assigned to the phone. NTP references can be
configured in date/time groups in CUCM versions 5.x and later. The date/time group is
then added to Cisco IP Phone devices.
■ Call details records (CDR) provide time-stamped call reporting, analysis, and billing
information. Call management records (CMR) contain quality of service (QoS)
information regarding the quality of phone calls, including the number of lost packets
(per direction), average jitter (delay variation), and maximum jitter. CMRs are mapped
to CDRs.
■ Alarms, log files, and trace files include time stamps with millisecond-level accuracy.
One second of processing in a CUCM server can have hundreds of lines of trace output.
Troubleshooting calls that involve multiple servers frequently require the correlation of
alarm, event, and trace information available in different systems. Correlation of these
records is possible only if all devices in the network have the same date and time
information.
■ CUCM includes features that rely on date and time. These features include time-of-day
routing, certificate-based security features, and remote support.
Figure 5-1 displays a master reference clock from which the publisher server is synchronizing
time. The publisher server redistributes the timing information to the subscriber servers.
NOTE Cisco Unified Communications IP Telephony, Part 2 (Cisco Press, 2007)
explains the operation of X.509v3 certificates, certificate trust lists, IPsec, transport layer
security, and Secure Skinny Client Control Protocol (SCCPS).
CUCM Initial Configuration 91
Figure 5-1 Network Time Protocol
CUCM and all network devices should synchronize their time from a stratum level 1 NTP
server. To modify NTP configurations in CUCM, navigate to System > NTP Servers from
the CUCM Administration web pages, as shown in Figure 5-2. NTP servers can be added,
deleted, or modified.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
After you install CUCM, some initial configuration has to be done before starting to deploy
endpoints. This initial configuration includes the items in Table 5-1.
Network Components
CUCM leverages various IP networking protocols and systems.
Network Time Protocol
Network Time Protocol (NTP) is a protocol for synchronizing the clocks of computer
systems over IP networks through use of a hierarchical clock strata organization. A stratum
level 1 timing source device is an extremely precise clock source using the rare earth element
cesium. Cesium clocks used to be very expensive, but most service providers with large
central offices now have local stratum level 1 clocks. Global positioning system (GPS)
satellites provide a stratum level 1 clocking source that provides a cost-effective synchronization
system.
Stratum level 1 clocks are distributed over networks to provide timing information to a large
number of devices. A linear relationship exists between the number of nodes passed and the
degradation of the timing quality.
Stratum level 2 timing sources are based on the rare earth element rubidium. Distribution
of stratum 2 time information becomes inaccurate more quickly than stratum 1 information.
Table 5-1 Publisher Server Required Services
Configuration Item Description
Network settings Basic network settings have already been configured during installation,
but some of them should be revisited (use of external NTP and DNS
servers), and network settings that are not configurable during
installation (for example, enabling DHCP services on CUCM) have
to be addressed before endpoint deployment.
Network and feature services CUCM servers run network services (automatically activated) and
feature services (activated by the administrator). After installation,
network services should be checked, and desired feature services
have to be activated.
Enterprise parameters CUCM has cluster-wide configuration settings called enterprise
parameters. After installation, enterprise parameter default values
should be verified and modified if required.
Service parameters CUCM services have configurable parameters that can usually be set
per CUCM server. After installation and service activation, service
parameter default values should be verified and modified if required.
CUCM Initial Configuration 89
Stratum level 2 timing is not as accurate as stratum level 1, but the timing is accurate enough
to time a large SONET node. SONET nodes are very high-speed networks that are used
by service providers to transport time-division multiplexing (TDM) voice calls through
networks operating at up to OC-192 speeds (almost 10 Gbp/s). T1 and T3 voice interfaces
are provisioned from SONET nodes, such as the Cisco ONS 15454.
Stratum level 3 timing sources are based on the rare earth element quartz, which has become
affordable enough that it is built in to most off-the-shelf wristwatches. Stratum level 3 is
accurate enough to time a SONET node, but it quickly loses accuracy when distributed to
other nodes. Most T3 (44.736 Mb/s) controllers have built-in oscillators with a stratum
level 3 timing source. T3 interfaces multiplex (28) individual T1 interfaces for a total of
672 voice channels.
CUCM has an option to use NTP to obtain time information from a time server. Only
the CUCM publisher will communicate with one or more NTP servers. The timing that the
publisher receives is synchronized to the subscriber servers. If an external NTP server is not
used, CUCM can be manually configured with the date and time. The system time in most
servers is a stratum level 4 timing source and should not be relied on to time a production
network.
Dynamic Host Configuration Protocol
Dynamic Host Configuration Protocol (DHCP) is a protocol that allows IP endpoints to
obtain their IP settings dynamically from a server. The most important settings include the
IP address, subnet mask, default gateway, TFTP server (option 150), and DNS server.
CUCM features a DHCP server that was designed to serve Cisco IP Phones only.
Trivial File Transfer Protocol
Trivial File Transfer Protocol (TFTP) is a simple file transfer protocol used by Cisco IP Phones
to obtain configuration files and their software (binary image load). A CUCM server has to
run the TFTP service on at least one server to be able to support Cisco IP Phones.
Domain Name System
Domain Name System (DNS) is a name-resolution protocol that allows IP applications to
refer to other systems by logical names rather than IP addresses. A CUCM cluster can be
configured to use either DNS or IP addresses.
NOTE More information on SONET, optical networking, and the ONS 15454 is
available in Cisco Self-Study: Building Cisco Metro Optical Networks (METRO), by
Dave Warren and Dennis Hartmann (Cisco Press, 2003).
90 Chapter 5: Initial Configuration Settings
NTP and DHCP Considerations
NTP can be configured during installation of the CUCM product. NTP can also be
configured after the installation procedure using the CUCM Administration web pages.
It is extremely important that all network devices have accurate time information because
the system time of CUCM is relevant in the following situations:
■ Cisco IP Phones display date and time information; this information is obtained from
CUCM unless an NTP reference is assigned to the phone. NTP references can be
configured in date/time groups in CUCM versions 5.x and later. The date/time group is
then added to Cisco IP Phone devices.
■ Call details records (CDR) provide time-stamped call reporting, analysis, and billing
information. Call management records (CMR) contain quality of service (QoS)
information regarding the quality of phone calls, including the number of lost packets
(per direction), average jitter (delay variation), and maximum jitter. CMRs are mapped
to CDRs.
■ Alarms, log files, and trace files include time stamps with millisecond-level accuracy.
One second of processing in a CUCM server can have hundreds of lines of trace output.
Troubleshooting calls that involve multiple servers frequently require the correlation of
alarm, event, and trace information available in different systems. Correlation of these
records is possible only if all devices in the network have the same date and time
information.
■ CUCM includes features that rely on date and time. These features include time-of-day
routing, certificate-based security features, and remote support.
Figure 5-1 displays a master reference clock from which the publisher server is synchronizing
time. The publisher server redistributes the timing information to the subscriber servers.
NOTE Cisco Unified Communications IP Telephony, Part 2 (Cisco Press, 2007)
explains the operation of X.509v3 certificates, certificate trust lists, IPsec, transport layer
security, and Secure Skinny Client Control Protocol (SCCPS).
CUCM Initial Configuration 91
Figure 5-1 Network Time Protocol
CUCM and all network devices should synchronize their time from a stratum level 1 NTP
server. To modify NTP configurations in CUCM, navigate to System > NTP Servers from
the CUCM Administration web pages, as shown in Figure 5-2. NTP servers can be added,
deleted, or modified.
Operating System Administration Best Cisco CCIE Institute in Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The CUCM Operating System Administration web interface allows platform
administrators to configure and manage the CUCM operating system. Examples of
operating system administration tasks include the following:
■ Check software and hardware status
■ Upgrade system software and install or upgrade options
■ View or update IP addresses
■ Manage Network Time Protocol (NTP) servers
80 Chapter 4: Administration
■ Manage server security, including IPsec configuration and certificates
■ Ping other network devices
■ Manage remote support (Technical Assistance Center, TAC) accounts
The Operating System Administration web page is accessible via the Navigation drop-down
menu or directly at https://<ip-address>/cmplatform. Figure 4-11 shows the Operating
System Administration web page.
Figure 4-11 Operating System Login Page
The platform administrator username is required for access to the Operating System
Administration page. Figure 4-12 shows the Operating System Administration page
menu options.
Figure 4-12 Operating System Menu Page
CUCM User Interface Options 81
Command-Line Interface
The CUCM CLI provides similar features to platform administrators that they can find in
the CUCM OS and CUCM DRS GUI and includes some additional functions:
■ Display platform information, such as product version, CPU, memory, disk usage,
platform hardware, serial number, and so on
■ Display network, process, and load information
■ Configure additional platform administrator accounts
■ Change platform administrator account password and security passwords
■ Perform disaster recovery tasks
■ Use tools such as ping, traceroute, and packet capture
■ Change network configuration settings
■ Start, stop, and restart services
■ Perform system restarts, shutdowns, and switch versions
When accessing the CUCM CLI, the platform administrator has to log in with a username
and password. The CLI is accessible via the physical Media Convergence Server (MCS)
platform or over the network via a Secure Shell (SSH) client. Telnet is not supported on
CUCM because Telnet does not provide transport security.
When using the CUCM CLI, you can use ? to see the available commands or command
options. In the first example shown in Figure 4-13, the ? was used at the root access level;
therefore, all top-level commands displayed. In the second example, the command show ?
was entered; therefore, all available show commands displayed. Finally, all utility
commands (utils) displayed because the utils ? command was entered.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The CUCM Operating System Administration web interface allows platform
administrators to configure and manage the CUCM operating system. Examples of
operating system administration tasks include the following:
■ Check software and hardware status
■ Upgrade system software and install or upgrade options
■ View or update IP addresses
■ Manage Network Time Protocol (NTP) servers
80 Chapter 4: Administration
■ Manage server security, including IPsec configuration and certificates
■ Ping other network devices
■ Manage remote support (Technical Assistance Center, TAC) accounts
The Operating System Administration web page is accessible via the Navigation drop-down
menu or directly at https://<ip-address>/cmplatform. Figure 4-11 shows the Operating
System Administration web page.
Figure 4-11 Operating System Login Page
The platform administrator username is required for access to the Operating System
Administration page. Figure 4-12 shows the Operating System Administration page
menu options.
Figure 4-12 Operating System Menu Page
CUCM User Interface Options 81
Command-Line Interface
The CUCM CLI provides similar features to platform administrators that they can find in
the CUCM OS and CUCM DRS GUI and includes some additional functions:
■ Display platform information, such as product version, CPU, memory, disk usage,
platform hardware, serial number, and so on
■ Display network, process, and load information
■ Configure additional platform administrator accounts
■ Change platform administrator account password and security passwords
■ Perform disaster recovery tasks
■ Use tools such as ping, traceroute, and packet capture
■ Change network configuration settings
■ Start, stop, and restart services
■ Perform system restarts, shutdowns, and switch versions
When accessing the CUCM CLI, the platform administrator has to log in with a username
and password. The CLI is accessible via the physical Media Convergence Server (MCS)
platform or over the network via a Secure Shell (SSH) client. Telnet is not supported on
CUCM because Telnet does not provide transport security.
When using the CUCM CLI, you can use ? to see the available commands or command
options. In the first example shown in Figure 4-13, the ? was used at the root access level;
therefore, all top-level commands displayed. In the second example, the command show ?
was entered; therefore, all available show commands displayed. Finally, all utility
commands (utils) displayed because the utils ? command was entered.
CUCM Administration Interface Best Cisco CCSP Institute in Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The CUCM Administration web interface provides the following functions:
■ System configuration, including CUCM groups, presence groups, device mobility
groups, device pools, regions, locations, phone security profile, and so on
■ Call-routing configuration, including dial rules, route patterns, call hunting, time-ofday
routing, partitioning and CSS, intercom, call park, call pickup, and so on
■ Media resource configuration, including conference bridges, transcoders, music on
hold (MOH), media termination points (MTP), and so on
■ Voice-mail configuration
■ Device configuration, including gateways, gatekeepers, trunks, IP phones, and so on
■ Application configuration, including manager - assistant, attendant console, and so on
■ User management, including end users, application users, groups, and role
configuration
When accessing the CUCM Administration web interface, shown in Figure 4-4, the CUCM
administrator must log in with the CCMAdministrator username and password. The initial
Communications Manager administrator account is created during installation. Additional
CM administrator accounts can be created from the CUCM Administration web interface
by assigning the appropriate user group to the user. This is covered in a later chapter with
multilevel administration (MLA). The CUCM Administration page is available at https://
<ip-address>/ccmadmin.
Figure 4-4 Administrator Web Interface
76 Chapter 4: Administration
Figure 4-5 illustrates the main configuration menu options that are available from the
CUCM Administration configuration page.
Figure 4-5 Administrator Configuration Menus
Cisco Unified Serviceability Interface
The Cisco Unified Serviceability web interface provides the following functions:
■ Configure alarms, logs, and traces (for monitoring and troubleshooting CUCM).
■ Configure call details records (CDR) disk storage and external billing servers. CUCM
can create CDRs and call management records (CMR), providing detailed information
about call activities and voice quality. Using CUCM Serviceability, an administrator
can limit the disk space used for these records and configure CUCM to copy or move
these files containing CDRs and CMRs to external billing servers using the Secure File
Transfer Protocol (SFTP).
■ Activate, deactivate, start, stop, and restart network and feature services.
■ Configure Simple Network Management Protocol (SNMP) settings.
■ Configure serviceability reports. Serviceability reports are automatically created every
night and allow system analysis based on monitored objects. CUCM administrators
can obtain the generated reports from the CUCM Serviceability web pages.
The CUCM Serviceability web interface is accessible via the Navigation drop-down menu
on any of the GUI web interfaces except the user web interface. Figure 4-6 shows the
Navigation menu.
CUCM User Interface Options 77
Figure 4-6 Navigation Menu
The CUCM Serviceability menu is also accessible directly via the following URL: https://
<ip-address>/ccmservice. Figure 4-7 shows the CUCM Serviceability login page. The
CUCM Administrator user has access to the Serviceability menu.
Figure 4-7 Cisco Unified Serviceability Login
Figure 4-8 shows the CUCM Serviceability menu options.
78 Chapter 4: Administration
Disaster Recovery System
The CUCM Disaster Recovery System web interface provides the following functions:
■ Write backups to a physical tape drive or remote SFTP server
■ Support full cluster backups
■ Support ad hoc backup and restore jobs
■ Support scheduled backups
Figure 4-8 Cisco Unified Serviceability Menu Options
The CUCM Disaster Recovery System web interface can be accessed only by a platform
administrator. The initial platform administrator account is created during installation of
the CUCM product. During the installation of CUCM, the installer must configure a username
and password for both the CallManager administration and the operating system
administration. Security best practices mandate these accounts use a different username,
but the username of the platform and operating system administrators can be the same.
Additional platform administrator accounts can be created only from the CUCM CLI using
the set account command.
The CUCM Disaster Recovery System web page is accessible via the Navigation dropdown
menu shown in Figure 4-6 or via https://<ip-address>/drf. Figure 4-9 shows the
Disaster Recovery System login page.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The CUCM Administration web interface provides the following functions:
■ System configuration, including CUCM groups, presence groups, device mobility
groups, device pools, regions, locations, phone security profile, and so on
■ Call-routing configuration, including dial rules, route patterns, call hunting, time-ofday
routing, partitioning and CSS, intercom, call park, call pickup, and so on
■ Media resource configuration, including conference bridges, transcoders, music on
hold (MOH), media termination points (MTP), and so on
■ Voice-mail configuration
■ Device configuration, including gateways, gatekeepers, trunks, IP phones, and so on
■ Application configuration, including manager - assistant, attendant console, and so on
■ User management, including end users, application users, groups, and role
configuration
When accessing the CUCM Administration web interface, shown in Figure 4-4, the CUCM
administrator must log in with the CCMAdministrator username and password. The initial
Communications Manager administrator account is created during installation. Additional
CM administrator accounts can be created from the CUCM Administration web interface
by assigning the appropriate user group to the user. This is covered in a later chapter with
multilevel administration (MLA). The CUCM Administration page is available at https://
<ip-address>/ccmadmin.
Figure 4-4 Administrator Web Interface
76 Chapter 4: Administration
Figure 4-5 illustrates the main configuration menu options that are available from the
CUCM Administration configuration page.
Figure 4-5 Administrator Configuration Menus
Cisco Unified Serviceability Interface
The Cisco Unified Serviceability web interface provides the following functions:
■ Configure alarms, logs, and traces (for monitoring and troubleshooting CUCM).
■ Configure call details records (CDR) disk storage and external billing servers. CUCM
can create CDRs and call management records (CMR), providing detailed information
about call activities and voice quality. Using CUCM Serviceability, an administrator
can limit the disk space used for these records and configure CUCM to copy or move
these files containing CDRs and CMRs to external billing servers using the Secure File
Transfer Protocol (SFTP).
■ Activate, deactivate, start, stop, and restart network and feature services.
■ Configure Simple Network Management Protocol (SNMP) settings.
■ Configure serviceability reports. Serviceability reports are automatically created every
night and allow system analysis based on monitored objects. CUCM administrators
can obtain the generated reports from the CUCM Serviceability web pages.
The CUCM Serviceability web interface is accessible via the Navigation drop-down menu
on any of the GUI web interfaces except the user web interface. Figure 4-6 shows the
Navigation menu.
CUCM User Interface Options 77
Figure 4-6 Navigation Menu
The CUCM Serviceability menu is also accessible directly via the following URL: https://
<ip-address>/ccmservice. Figure 4-7 shows the CUCM Serviceability login page. The
CUCM Administrator user has access to the Serviceability menu.
Figure 4-7 Cisco Unified Serviceability Login
Figure 4-8 shows the CUCM Serviceability menu options.
78 Chapter 4: Administration
Disaster Recovery System
The CUCM Disaster Recovery System web interface provides the following functions:
■ Write backups to a physical tape drive or remote SFTP server
■ Support full cluster backups
■ Support ad hoc backup and restore jobs
■ Support scheduled backups
Figure 4-8 Cisco Unified Serviceability Menu Options
The CUCM Disaster Recovery System web interface can be accessed only by a platform
administrator. The initial platform administrator account is created during installation of
the CUCM product. During the installation of CUCM, the installer must configure a username
and password for both the CallManager administration and the operating system
administration. Security best practices mandate these accounts use a different username,
but the username of the platform and operating system administrators can be the same.
Additional platform administrator accounts can be created only from the CUCM CLI using
the set account command.
The CUCM Disaster Recovery System web page is accessible via the Navigation dropdown
menu shown in Figure 4-6 or via https://<ip-address>/drf. Figure 4-9 shows the
Disaster Recovery System login page.
CUCM User Interface Options Best Cisco CCNP Institute in Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Serviceability
System version: 6.0.1.2000-3
Disaster Recovery System
System version: 6.0.1.2000-3
Cisco Unified Operating System Administration
System version: 6.0.1.2000-3
CUCM 6.0.1.2000-3
CUCM1-1 login: admin
Password:
Last login: Fri Sep 21 15:35:37 on tty1
Welcome to the Platform Command Line Interface
(version 1.1)
admin:_
CUCM Administration and User Interface Options
CUCM User Options
For Cisco Unified Communications Solutions
CUCM Administration
For Cisco Unified Communications Solutions
Disaster Recovery System
For Cisco Unified Communications Solutions
Cisco Unified Serviceability
For Cisco Unified Communications Solutions
Cisco Unified Operating System Administration
For Cisco Unified Communications Solutions
CUCM User Interface Options 73
CUCM User Options Interface
CUCM has functionality that allows end-user accounts to be configured and associated with
one or more IP phones, and enables end users to configure personal features for their IP
phones. The configurable features include the following:
■ Call Forwarding.
■ Speed Dial Numbers.
■ End users can configure speed dial buttons on each IP phone. Speed dial buttons
configured via the phone button template on the IP phone are limited by the number
of buttons on the IP phone. The User Options web interface also allows the end user
to configure up to 99 abbreviated dialing soft keys.
■ Subscribe to IP Phone Services.
■ Most Cisco IP Phone models can be used to access Extensible Markup Language
(XML)-based web applications end users can freely subscribe to.
■ Configure Personal Address Book and Fast Dials.
■ Change Message Waiting Lamp Policy.
■ Change User Locale (Phone Language), Password, and PIN.
Users with permission to access the web interface may do so via the following URL:
https://<ip-address>/ccmuser. Users must use the username and password that has been
provided by the CUCM administrator. Figure 4-2 shows the CCMUser login page.
Cisco Unified
Serviceability
Allows CUCM administrators to control feature and network services,
configure alarms and trace information, and so on
Disaster Recovery
System
Allows platform administrators to perform CUCM backup and restore tasks
Cisco Unified
Operating System -
Administration
Allows platform administrators to manage the CUCM operating system
Administration CLI Allows platform administrators to manage the CUCM operating system via
a CLI
Table 4-1 Publisher Server Required Services (Continued)
Interface Option Description
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Serviceability
System version: 6.0.1.2000-3
Disaster Recovery System
System version: 6.0.1.2000-3
Cisco Unified Operating System Administration
System version: 6.0.1.2000-3
CUCM 6.0.1.2000-3
CUCM1-1 login: admin
Password:
Last login: Fri Sep 21 15:35:37 on tty1
Welcome to the Platform Command Line Interface
(version 1.1)
admin:_
CUCM Administration and User Interface Options
CUCM User Options
For Cisco Unified Communications Solutions
CUCM Administration
For Cisco Unified Communications Solutions
Disaster Recovery System
For Cisco Unified Communications Solutions
Cisco Unified Serviceability
For Cisco Unified Communications Solutions
Cisco Unified Operating System Administration
For Cisco Unified Communications Solutions
CUCM User Interface Options 73
CUCM User Options Interface
CUCM has functionality that allows end-user accounts to be configured and associated with
one or more IP phones, and enables end users to configure personal features for their IP
phones. The configurable features include the following:
■ Call Forwarding.
■ Speed Dial Numbers.
■ End users can configure speed dial buttons on each IP phone. Speed dial buttons
configured via the phone button template on the IP phone are limited by the number
of buttons on the IP phone. The User Options web interface also allows the end user
to configure up to 99 abbreviated dialing soft keys.
■ Subscribe to IP Phone Services.
■ Most Cisco IP Phone models can be used to access Extensible Markup Language
(XML)-based web applications end users can freely subscribe to.
■ Configure Personal Address Book and Fast Dials.
■ Change Message Waiting Lamp Policy.
■ Change User Locale (Phone Language), Password, and PIN.
Users with permission to access the web interface may do so via the following URL:
https://<ip-address>/ccmuser. Users must use the username and password that has been
provided by the CUCM administrator. Figure 4-2 shows the CCMUser login page.
Cisco Unified
Serviceability
Allows CUCM administrators to control feature and network services,
configure alarms and trace information, and so on
Disaster Recovery
System
Allows platform administrators to perform CUCM backup and restore tasks
Cisco Unified
Operating System -
Administration
Allows platform administrators to manage the CUCM operating system
Administration CLI Allows platform administrators to manage the CUCM operating system via
a CLI
Table 4-1 Publisher Server Required Services (Continued)
Interface Option Description
CUCM Installation and Upgrade Overview Windows Upgrade Best Cisco CCNA Institute in Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
When upgrading from Windows-based CUCM (Version 4.x) to the appliance-based CUCM
Version 5.x or 6.x, all the configuration and runtime data has to be exported from the
Microsoft SQL database and transformed to the new format of the Informix database. These
tasks are performed by the Cisco DMA tool.
To perform the Windows upgrade installation, click Yes in the Import Windows Data
window. After the installation of CUCM 6, the configuration data will be retrieved from
tape or an FTP/SFTP source. This installation option requires that you run DMA on the
Windows-based CUCM 4.x version before the upgrade installation.
The Cisco DMA needs to be installed and run on the CUCM 4.x publisher server. The
backup file created by DMA must be saved to a tape drive or to a network location.
The CUCM 6.0(1) publisher installation procedure then retrieves the DMA backup file via
SFTP/FTP or from the tape and migrates CUCM 4.x data into CUCM Version 6.0(1).
Installation of CUCM subscribers follows the publisher installation. Subscribers pull data
from the publisher database; therefore, no DMA files are loaded during the installation of
a subscriber.
Figure 3-6 DMA Overview
Caveats to keep in mind when using the DMA include the following:
■ Customized music on hold (MOH) files have to be backed up manually to be
reinstalled on all CUCM servers after upgrade to 6.0(1).
■ Special phone load files and background images stored on the TFTP server will also be
lost; these files have to be backed up and can be uploaded to the newly installed TFTP
server after upgrade.
Cisco Unified
CallManager
4.2(3) Publisher
Unified CM
6.0(1) Publisher
Network Share
Server
S/FTP
Appliance
Unified CM
6.0(1)
Installation
Imports File
DMA
Exports TAR
File or Tape
DMA
CUCM Installation and Upgrade Overview 67
■ Files on CUCM subscriber servers will not be backed up, because the DMA only runs
on the publisher server.
■ The default user ID for the CUCM administrator needs to be set during the CUCM
6.0(1) installation; a default user ID of CCMAdministrator is no longer mandatory.
■ All usernames are migrated, but the passwords and PINs are reset to a default defined
during installation. After the upgrade, users can change their passwords and PINs on
the CCMUser web pages.
CUCM 5.x and 6.x Upgrades
Updates from appliance-based CUCM versions (5.x) are performed from the CUCM
Operating System Administration web page.
The system does not have to be rebooted, because the current operating system and application
are not overwritten by the new version. Instead, they are installed to a second (inactive)
partition.
The upgrade procedure includes the following steps:
Step 1 Back up the existing CUCM 5.x or 6.x system using the CUCM Disaster
Recovery System (DRS).
Step 2 Ensure that the SFTP/FTP server is available to perform the upgrade
remotely or that the upgrade image is available on the DVD to perform
the upgrade locally.
Step 3 Log in to the Cisco Unified Operating System Administration page and
start the upgrade.
Step 4 CUCM upgrades can be done without affecting call processing, and the
server can be rebooted later during a service window after the upgrade.
Step 5 Install the updated license file (required when upgrading from 5.x to 6.0).
NOTE CUCM Version 5.0 requires an upgrade to CUCM Version 5.1(1) before it can
be upgraded to CUCM Version 6.
68 Chapter 3: Installation and Upgrade
Dual Partitions
Since Release 5.x, CUCM supports dual partitions, which simplify software updates:
■ Each partition keeps one version of the CUCM software and databases.
■ Operation continues during upgrades.
■ Upgrade installs to the inactive partition.
■ During reboot, versions (active and inactive partitions) can be swapped. The previously
active partition becomes inactive and retains “old” software and databases until the
next upgrade. Any changes made to the active partition are not replicated to the inactive
partition. All changes made since the upgrade are lost when reverting.
■ If versions are switched again before the next upgrade, you revert to the previous
version (downgrade).
An upgraded system always maintains two versions of software (does not apply to upgrade
from 4.x).
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
When upgrading from Windows-based CUCM (Version 4.x) to the appliance-based CUCM
Version 5.x or 6.x, all the configuration and runtime data has to be exported from the
Microsoft SQL database and transformed to the new format of the Informix database. These
tasks are performed by the Cisco DMA tool.
To perform the Windows upgrade installation, click Yes in the Import Windows Data
window. After the installation of CUCM 6, the configuration data will be retrieved from
tape or an FTP/SFTP source. This installation option requires that you run DMA on the
Windows-based CUCM 4.x version before the upgrade installation.
The Cisco DMA needs to be installed and run on the CUCM 4.x publisher server. The
backup file created by DMA must be saved to a tape drive or to a network location.
The CUCM 6.0(1) publisher installation procedure then retrieves the DMA backup file via
SFTP/FTP or from the tape and migrates CUCM 4.x data into CUCM Version 6.0(1).
Installation of CUCM subscribers follows the publisher installation. Subscribers pull data
from the publisher database; therefore, no DMA files are loaded during the installation of
a subscriber.
Figure 3-6 DMA Overview
Caveats to keep in mind when using the DMA include the following:
■ Customized music on hold (MOH) files have to be backed up manually to be
reinstalled on all CUCM servers after upgrade to 6.0(1).
■ Special phone load files and background images stored on the TFTP server will also be
lost; these files have to be backed up and can be uploaded to the newly installed TFTP
server after upgrade.
Cisco Unified
CallManager
4.2(3) Publisher
Unified CM
6.0(1) Publisher
Network Share
Server
S/FTP
Appliance
Unified CM
6.0(1)
Installation
Imports File
DMA
Exports TAR
File or Tape
DMA
CUCM Installation and Upgrade Overview 67
■ Files on CUCM subscriber servers will not be backed up, because the DMA only runs
on the publisher server.
■ The default user ID for the CUCM administrator needs to be set during the CUCM
6.0(1) installation; a default user ID of CCMAdministrator is no longer mandatory.
■ All usernames are migrated, but the passwords and PINs are reset to a default defined
during installation. After the upgrade, users can change their passwords and PINs on
the CCMUser web pages.
CUCM 5.x and 6.x Upgrades
Updates from appliance-based CUCM versions (5.x) are performed from the CUCM
Operating System Administration web page.
The system does not have to be rebooted, because the current operating system and application
are not overwritten by the new version. Instead, they are installed to a second (inactive)
partition.
The upgrade procedure includes the following steps:
Step 1 Back up the existing CUCM 5.x or 6.x system using the CUCM Disaster
Recovery System (DRS).
Step 2 Ensure that the SFTP/FTP server is available to perform the upgrade
remotely or that the upgrade image is available on the DVD to perform
the upgrade locally.
Step 3 Log in to the Cisco Unified Operating System Administration page and
start the upgrade.
Step 4 CUCM upgrades can be done without affecting call processing, and the
server can be rebooted later during a service window after the upgrade.
Step 5 Install the updated license file (required when upgrading from 5.x to 6.0).
NOTE CUCM Version 5.0 requires an upgrade to CUCM Version 5.1(1) before it can
be upgraded to CUCM Version 6.
68 Chapter 3: Installation and Upgrade
Dual Partitions
Since Release 5.x, CUCM supports dual partitions, which simplify software updates:
■ Each partition keeps one version of the CUCM software and databases.
■ Operation continues during upgrades.
■ Upgrade installs to the inactive partition.
■ During reboot, versions (active and inactive partitions) can be swapped. The previously
active partition becomes inactive and retains “old” software and databases until the
next upgrade. Any changes made to the active partition are not replicated to the inactive
partition. All changes made since the upgrade are lost when reverting.
■ If versions are switched again before the next upgrade, you revert to the previous
version (downgrade).
An upgraded system always maintains two versions of software (does not apply to upgrade
from 4.x).
CUCM Installation and Upgrade Overview Best Cisco CCIE Coaching in New Delhi
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
CUCM can be upgraded from the various previous releases of Windows Server-based CUCM or
appliance-based CUCM.
Cisco CallManager Releases 3.x and earlier for Windows Server have to be upgraded to Release 4.1(3)
or later before upgrade to 6.0(1) is possible.
Appliance-based CUCM releases earlier than 5.1(1) have to be upgraded to Release 5.1(1) before
upgrade to 6.0(1) is possible.
54 Chapter 3: Installation and Upgrade
Figure 3-1 displays the various upgrade path options available for CUCM 6.0(1).
Figure 3-1 CUCM Upgrade Paths
CUCM Installation and Upgrade Options
Of the four installation options, only the first three options are available when booting from
the DVD. These options are available when CUCM has been chosen in the Product
Deployment Selection screen.
Upgrade from 5.1 does not require booting from the installation DVD, but it is presented
here as one of the upgrade options.
CUCM 6.0(x) uses an installation framework similar to CUCM Release 5.x. The
installation process allows performing a basic installation, upgrading to a newer
service release during the installation, and upgrading from CUCM 4.1(3) or later
to CUCM 6.0(1).
The sections that follow describe how the installation and upgrade options work.
Basic Install
This option represents the basic installation and does not use imported data. This type of
installation generally starts by booting a system from an installation DVD or powering up
a new system from the factory (with preinstalled software).
Windows Server 2000 Windows Server 2003
Release 4.x 4.0(2a) 4.1(3) 4.2(1) 4.2(3) 4.3(1)
Appliance
Release 6.x
Appliance
Release 5.x
Windows Server 2000
Release 3.x 3.3(5)
Appliance-Based Windows-Based CM Upgrade Path
6.0(1)
5.0(4) 5.1(1)
CUCM Installation and Upgrade Overview 55
Upgrade During Install
This option performs a basic installation on a system and allows the system to be upgraded
to a specific service release patch level before the completion of the basic installation. This
option performs a basic installation before prompting the installer for additional upgrade
information.
Windows Upgrade
This option upgrades a Windows-based CUCM system to an appliance-based system and
migrates data from an existing Windows Server-based CUCM system. This installation
method can be done on the same machine or a different machine from the Windows Serverbased
CUCM machine. The Windows migration file can be saved to a variety of locations,
including a remote hard drive or tape system. The CUCM then uploads the file from one of
these locations during the upgrade process.
5.x or Later Upgrade
If you are upgrading from CUCM Release 5.x, the upgrade filename has the following
format:
cisco-ipt-k9-patchX.X.X.X-X.tar.gz.sgn
Where X.X.X.X-X represents the release and build number. An upgrade from 5.x or later is
performed from the Cisco Unified Operating System Administration.
Upgrade Methods
The first method is a full installation from scratch where the customer inserts a DVD and
loads the operating system and CUCM Release 6.0 application. This method is primarily
for customers who have an existing Media Convergence Server (MCS) or when users
purchase servers from a Cisco-approved third-party vendor.
NOTE Ensure that the patches are available on DVD or SFTP/FTP during this
installation option.
NOTE During upgrade from a Windows-based release, new software licenses and
configuration files generated with the Data Migration Assistant tool (DMA) are required.
CAUTION Installation on an existing server formats the hard drive. All existing data on
the drive is lost.
56 Chapter 3: Installation and Upgrade
The second method is a factory preinstallation in which the customer orders an MCS
platform, and the operating system and CUCM Release 6.0 application are preloaded to the
server at the factory and then shipped to the customer. This method is primarily for
customers who order a new MCS platform. A preinstallation without configuration can also
be done from the installation DVD by selecting Skip during the Platform Installation wizard
prompt. In this case, only the software is installed, but no configuration is applied. When
the server is booted the next time, the Configuration wizard starts automatically (like on a
factory preinstalled system).
Installation Disc
The installation disc enables you to install the operating system and CUCM from the same
DVD. The installation disc performs a hardware check to verify hardware requirements for
the release. If any unsupported component is found, an applicable error message displays,
and the installation halts.
The disc can be used for full installation or for recovery if you have a backup of the data.
A separate recovery disc is available for use for system recovery if you want to recover the
operating system and application files without a backup of the data.
Cisco Unity Connection and Cisco Unified Communications Manager Business Edition
(CMBE) can also be installed from the same DVD; select the product that you want to
install. This lesson describes only the installation and upgrade of CUCM.
Hardware Configuration
Hardware configuration is integrated with the Cisco Unified Communications (UC)
installation process. The hardware configuration includes the following:
■ A check for correct hardware configuration, supported platforms, and minimum
hardware requirements
■ Configuration of the correct BIOS and RAID settings on the supported platforms
Basic Installation (Installation DVD)
This topic describes the process for performing a basic installation of the operating system
and CUCM Release 6.0 application on the publisher. CUCM Release 6.0 has to be installed
on the publisher before installing it on any subscriber nodes.
NOTE Only the products that are supported on your server appear in the list.
CUCM Installation and Upgrade Overview 57
To select the Basic installation option, choose No in both the Apply Additional Release
window and the Import Windows Data window.
Important Configuration Information
During the installation process, the installation prompts for various required information
based on the installation engineer’s answers to the installation prompts. Table 3-1 lists
important configuration information requested during CUCM setup.
Table 3-1 Installation Configuration Information
Field Description Usage
Administrator ID This field specifies the name
that you want to assign to this
account.
Ensure that the name is unique; it can contain
lowercase, alphanumeric characters, hyphens,
and underscores. It must start with a lowercase
alphanumeric character.
For this mandatory field, you should record it
for use when logging in to the CLI or into
Cisco Unified Communications Operating
System Administration.
Administrator
Password
This field specifies the
password that you use for
logging in to the CLI on the
platform and for logging in to
Cisco Unified Communications
Operating System
Administration.
Ensure that the password is at least six
characters long; it can contain alphanumeric
characters, hyphens, and underscores.
For this mandatory field, you should record it
for use when logging in to the CLI or into
Cisco Unified Communications Operating
System Administration.
DHCP Dynamic Host Configuration
Protocol.
Choose Yes if you want to use DHCP to
automatically configure the network settings
on your server.
If you choose No, you must enter a hostname,
IP address, IP mask, and gateway.
DNS Enabled A DNS server represents a
device that resolves a hostname
into an IP address or an IP
address into a hostname.
If you do not have a DNS server, choose No.
When DNS is not enabled, you should enter
only IP addresses (not hostnames) for all
network devices in your Cisco UC network.
If you have a DNS server, Cisco recommends
that you choose Yes to enable DNS.
Disabling DNS limits the system ability to
resolve some domain names.
continues
58 Chapter 3: Installation and Upgrade
DNS Primary The server contacts this DNS
server first when it attempts to
resolve hostnames.
Enter the IP address of the DNS server that
you want to specify as the primary DNS
server. Enter the IP address in dotted-decimal
format as ddd.ddd.ddd.ddd, where ddd can
have a value between 0 and 255 (except
0.0.0.0).
Consider this field mandatory if DNS is set
to Yes.
DNS Secondary When a primary DNS server
fails, the server attempts to
connect to the secondary DNS
server.
In this optional field, enter the IP address of
the secondary DNS. Enter the IP address in
dotted-decimal format as ddd.ddd.ddd.ddd,
where ddd can have a value between 0 and
255 (except 0.0.0.0).
Domain This field represents the name
of the domain in which this
machine is located.
Consider this field mandatory if DNS is set
to Yes.
First Cisco
Unified
Communications
Manager Node
This field specifies the first
CUCM node that contains the
database.
Subsequent nodes connect to
the first node to access database
content.
The first node also synchronizes
with an external Network Time
Protocol server and provides
time to the other nodes.
Choose Yes if you are configuring the first
CUCM node in the cluster.
Hostname A hostname represents an alias
that is assigned to an IP address
to identify it.
Enter a hostname that is unique to your
network.
The hostname can consist of up to 64
characters and can contain alphanumeric
characters and hyphens.
If DHCP is set to No, consider this field
mandatory.
Table 3-1 Installation Configuration Information (Continued)
Field Description Usage
CUCM Installation and Upgrade Overview 59
IP Address This field specifies the IP
address of this machine. It
uniquely identifies the server on
this network. Ensure that
another machine in this network
does not use this IP address.
Enter the IP address in the form
ddd.ddd.ddd.ddd, where ddd can have a
value between 0 and 255 (except 0.0.0.0).
If DHCP is set to No, consider this field
mandatory.
IP Mask This field specifies the IP
subnet mask of this machine.
The subnet mask, together with
the IP address, defines the
network address and the host
address.
Enter the IP mask in the form
ddd.ddd.ddd.ddd, where ddd can have a
value between 0 and 255 (except 0.0.0.0).
A valid mask should have contiguous 1 bits
on the left side and contiguous 0 bits on the
right.
For example, a valid mask follows:
255.255.240.0
(11111111.11111111.11110000.00000000)
An invalid mask follows: 255.255.240.240
(11111111.11111111.11110000.11110000)
NIC Speed This field specifies the speed of
the server network interface
card in megabits per second.
The possible speeds include 10 or 100.
NIC Duplex This field specifies the duplex
setting of the server network
interface card.
The possible settings include Half and Full.
NTP Server This field identifies the NTP
servers with which you want to
synchronize.
Enter the hostname or IP address of one or
more NTP servers.
Note that you can add additional NTP
servers or make changes to the NTP server
list at a later time.
NTP Server
Enable
When enabled, this server acts
as an NTP server and provides
time updates to the subsequent
nodes in the cluster.
Choose Yes if you want to enable this
machine to be an NTP server.
This option is available only on the first node
in a cluster.
continues
Table 3-1 Installation Configuration Information (Continued)
Field Description Usage
60 Chapter 3: Installation and Upgrade
Security
Password
Servers in the cluster use the
security password to
communicate with one another.
You are asked to enter the same
security password for each
subsequent node in the cluster.
Enter the security password.
Enter the same password in the Confirm
Password field.
The password must contain at least six
alphanumeric characters. It can contain
hyphens and underscores, but it must start
with an alphanumeric character.
All nodes in the cluster must have the same
password.
Set Hardware
Clock
This field specifies the date and
local time for the machine.
Note that if you set the
hardware clock manually, the
node does not use an external
NTP server for time
synchronization.
Choose Yes if you want to set the date and
local time for the time zone that you choose.
Enter the hours based on a 24-hour format.
Note that if you configure an external NTP
server, the hardware clock gets set
automatically.
SMTP This field specifies the name of
the SMTP host that is used for
outbound e-mail.
Enter the hostname or dotted-decimal IP
address for the SMTP server. For a host,
it can contain alphanumeric characters,
hyphens, or periods. For a hostname, it must
start with an alphanumeric character.
You must fill in this field if you plan to use
electronic notification. If not, you can leave it
blank.
Subnet IP
Address
By entering a subnet address,
you can specify a range of IP
addresses that will be granted
access to query this NTP server.
Enter an IP subnet that will be granted access
to the NTP server
During installation, you can enter only two
subnets.
Subnet Mask This field specifies the subnet
mask for the subnet address.
Enter the subnet mask for the IP subnet.
Time Zone This field specifies the local
time zone and offset from
Greenwich mean time.
Choose Yes if you want to change the time
zone.
Choose the time zone that most closely
matches the location of your machine.
Table 3-1 Installation Configuration Information (Continued)
Field Description Usage
CUCM Installation and Upgrade Overview 61
Installation Procedures for Basic Install
Installation starts the same way for all three installation options: Insert the installation disc
in the DVD drive and reboot the server. The DVD Found window displays after the server
completes the boot sequence.
Figure 3-2 provides a flowchart displaying the various steps involved in installing CUCM
from a DVD.
Figure 3-2 Basic Installation Flow (DVD Installation)
The DVD prompts the installer to perform a media check. To perform the media check,
choose Yes. To skip the media check, choose No. If Yes was chosen, the installation process
performs a media check of the image on the DVD to ensure that the image is error free
before installation. If the disk is okay, the installation continues.
A hardware check is then performed to determine whether the correct hardware is installed,
and then the RAID and BIOS settings are configured.
Boots from DVD
at Product
Deployment
Selection –
Select Unified CM
Platform
Configuration
Completed OS and
Application
Installation Scripts
Starts
Proceed
with
Install
Platform
Installation
Wizard
Apply
Additional
Releases
Basic
Install –
Continue
No
No
No No
Yes
Yes
Yes
Proceed
No
Yes
No
No
Yes
Yes
TimeZone
Configuration
Import
Windows
Data
Auto
Negotiation
Config
Configure
SMTP Host
Address
Application
User
Config
Platform
Config
Confirmation
NTP Client
Config
Database
Access
Security
Config
SMTP
Host
Config
Publisher
Address and
Security
Password
Configure
DNS and
Domain
Administrator
Login
Config
Certificate
Information
Publisher
Config
NIC Speed
and Duplex
Configuration
Use
DHCP
Static
Network
Configuration
DNS
Client
Config
62 Chapter 3: Installation and Upgrade
After the hardware checks are complete, the Product Deployment Selection window displays.
In the Product Deployment Selection window, you can choose from the following options:
■ Cisco Unified Communications Manager
■ Cisco Unity Connection
■ Cisco Unified Communications Manager Business Edition (includes CUCM and Cisco
Unity Connection)
Select the first option (Cisco Unified Communication Manager) to install only CUCM.
The Overwrite Hard Drive window then indicates the current software version on your
hard drive and the version on the DVD. Choose No to halt the installation. Choose Yes to
overwrite the hard drive.
Next, choose the desired type of installation by performing the following steps.
In both the Apply Additional Release window and the Import Windows Data window,
choose No to select the Basic installation option. When you click Continue, the Platform
Installation wizard guides you through the installation process and gathers the required
information. Review this window to familiarize yourself with navigating within the
Platform Installation wizard, and follow these guidelines:
If you click Proceed, the Product Installation Configuration window displays immediately
before any software is copied or installed.
If you click Skip, the software is first transferred to the hard drive, and the system shuts
down. At the next boot, the system displays the Installation Configuration window. This is
the same state as on a factory-installed system, in which the software is preloaded but no
configuration has been done.
When the preloaded system boots, the Configuration dialog is completely skipped if a
Universal Serial Bus (USB) drive with a configuration file that includes all configuration
parameters is found. Such a configuration file can be prepared using the Answer File
Generator, as covered in the following section.
Basic Installation (Preinstalled)
After you boot the system, the Preexisting Installation Configuration window displays. If
preexisting configuration information generated by the Answer File Generator and stored
on a floppy disc or a USB key exists, you must insert the disc or the USB key and then click
Continue. In this case, the Installation wizard reads the configuration information from the
CUCM Installation and Upgrade Overview 63
USB key. If no configuration file on a USB key is provided, the Installation wizard prompts
for configuration data. Figure 3-3 shows this install process.
Figure 3-3 Basic Installation Flow (Preinstalled)
The only difference to a basic installation executed from the installation DVD is the ability
to skip over the configuration portion by providing a configuration file on a USB key.
The Answer File Generator is a web-based tool available at Cisco.com that provides the
answer file based on the form entries that the user has filled out. The Answer File Generator
was located at http://www.cisco.com/web/cuc_afg/index.html at the time of this writing.
A Cisco.com search for “Answer File Generator” will provide a link to the current version
of the tool.
Upgrade During Install
Service releases, engineering special updates, and security updates may be installed during
Basic installation. To install, make sure the additional release is downloaded and prepared
on a DVD or FTP/SFTP server before starting the installation. Click Yes in the Apply
Additional Release window.
Boots from
Hard Disk
Platform
Configuration
Completed
Configuration
Script Starts
Existing
USB
or Disk with
Pre-Existing
Config
File
Platform
Installation
Wizard
Apply
Additional
Releases
Basic
Install –
Continue
No
No
No
No
Yes
Yes
Yes
Yes
Proceed
No
No
No
No
Yes
Yes
TimeZone
Config
Import
Windows
Data
Auto
Negotiation
Config
Configure
SMTP Host
Address
Application
User
Config
Platform
Config
Confirmation
NTP Client
Config
Database
Access
Security
Config
SMTP
Host
Config
Subscriber
Address and
Security
Password
Configure
DNS and
Domain
Administrator
Login
Config
Certificate
Information
Publisher
Config
NIC Speed
and Duplex
Config
Use
DHCP
Static
Network
Config
DNS
Client
Config
64 Chapter 3: Installation and Upgrade
The installation starts when the server is booted from the installation DVD. Verify the
checksum for the DVD, and click Overwrite Hard Disk.
In the Platform Installation wizard, click Yes in the Apply Additional Releases window.
Then the installation of the operating system and application will start; when finished, the
system reboots.
After reboot, choose the upgrade retrieval mechanism:
■ Local: Specify path and filename on the local DVD.
■ FTP/SFTP: Configure network settings and enter the location and login information
for the remote file server.
The upgrade will start, and the appliance server will reboot when the upgrade is complete.
Figure 3-4 and Figure 3-5 show the entire process.
Figure 3-4 Upgrade During Installation Flowchart (1 of 2)
Boots from DVD
and at Product
Deployment
Selection –
Select Unified CM
Proceed
with
Install
Platform
Installation
Wizard
Apply
Additional
Releases
Install OS,
Application
and Reboots
No
No
No
Yes
Yes
Yes
Yes
Proceed
Yes Local
Remote
Retrieve
Upgrade
from CD
or DVD
Upgrade
Retrieval
Mechanism
Auto
Negotiation
Configuration
Configure
DNS and
Domain
Remote
Patch
Configuration
Install
Upgrade
Patch and
Reboots
NIC Speed
and Duplex
Configuration
Use
DHCP
Static
Network
Configuration
DNS
Client
Configuration
CUCM Installation and Upgrade Overview 65
Figure 3-5 Upgrade During Installation Flowchart (2 of 2)
Table 3-2 outlines the information required to configure the remote path, which includes
the location and login information necessary for CUCM to access patches to the product
via the file transfer mechanism specified.
Table 3-2 Remote Path Information Description
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
CUCM can be upgraded from the various previous releases of Windows Server-based CUCM or
appliance-based CUCM.
Cisco CallManager Releases 3.x and earlier for Windows Server have to be upgraded to Release 4.1(3)
or later before upgrade to 6.0(1) is possible.
Appliance-based CUCM releases earlier than 5.1(1) have to be upgraded to Release 5.1(1) before
upgrade to 6.0(1) is possible.
54 Chapter 3: Installation and Upgrade
Figure 3-1 displays the various upgrade path options available for CUCM 6.0(1).
Figure 3-1 CUCM Upgrade Paths
CUCM Installation and Upgrade Options
Of the four installation options, only the first three options are available when booting from
the DVD. These options are available when CUCM has been chosen in the Product
Deployment Selection screen.
Upgrade from 5.1 does not require booting from the installation DVD, but it is presented
here as one of the upgrade options.
CUCM 6.0(x) uses an installation framework similar to CUCM Release 5.x. The
installation process allows performing a basic installation, upgrading to a newer
service release during the installation, and upgrading from CUCM 4.1(3) or later
to CUCM 6.0(1).
The sections that follow describe how the installation and upgrade options work.
Basic Install
This option represents the basic installation and does not use imported data. This type of
installation generally starts by booting a system from an installation DVD or powering up
a new system from the factory (with preinstalled software).
Windows Server 2000 Windows Server 2003
Release 4.x 4.0(2a) 4.1(3) 4.2(1) 4.2(3) 4.3(1)
Appliance
Release 6.x
Appliance
Release 5.x
Windows Server 2000
Release 3.x 3.3(5)
Appliance-Based Windows-Based CM Upgrade Path
6.0(1)
5.0(4) 5.1(1)
CUCM Installation and Upgrade Overview 55
Upgrade During Install
This option performs a basic installation on a system and allows the system to be upgraded
to a specific service release patch level before the completion of the basic installation. This
option performs a basic installation before prompting the installer for additional upgrade
information.
Windows Upgrade
This option upgrades a Windows-based CUCM system to an appliance-based system and
migrates data from an existing Windows Server-based CUCM system. This installation
method can be done on the same machine or a different machine from the Windows Serverbased
CUCM machine. The Windows migration file can be saved to a variety of locations,
including a remote hard drive or tape system. The CUCM then uploads the file from one of
these locations during the upgrade process.
5.x or Later Upgrade
If you are upgrading from CUCM Release 5.x, the upgrade filename has the following
format:
cisco-ipt-k9-patchX.X.X.X-X.tar.gz.sgn
Where X.X.X.X-X represents the release and build number. An upgrade from 5.x or later is
performed from the Cisco Unified Operating System Administration.
Upgrade Methods
The first method is a full installation from scratch where the customer inserts a DVD and
loads the operating system and CUCM Release 6.0 application. This method is primarily
for customers who have an existing Media Convergence Server (MCS) or when users
purchase servers from a Cisco-approved third-party vendor.
NOTE Ensure that the patches are available on DVD or SFTP/FTP during this
installation option.
NOTE During upgrade from a Windows-based release, new software licenses and
configuration files generated with the Data Migration Assistant tool (DMA) are required.
CAUTION Installation on an existing server formats the hard drive. All existing data on
the drive is lost.
56 Chapter 3: Installation and Upgrade
The second method is a factory preinstallation in which the customer orders an MCS
platform, and the operating system and CUCM Release 6.0 application are preloaded to the
server at the factory and then shipped to the customer. This method is primarily for
customers who order a new MCS platform. A preinstallation without configuration can also
be done from the installation DVD by selecting Skip during the Platform Installation wizard
prompt. In this case, only the software is installed, but no configuration is applied. When
the server is booted the next time, the Configuration wizard starts automatically (like on a
factory preinstalled system).
Installation Disc
The installation disc enables you to install the operating system and CUCM from the same
DVD. The installation disc performs a hardware check to verify hardware requirements for
the release. If any unsupported component is found, an applicable error message displays,
and the installation halts.
The disc can be used for full installation or for recovery if you have a backup of the data.
A separate recovery disc is available for use for system recovery if you want to recover the
operating system and application files without a backup of the data.
Cisco Unity Connection and Cisco Unified Communications Manager Business Edition
(CMBE) can also be installed from the same DVD; select the product that you want to
install. This lesson describes only the installation and upgrade of CUCM.
Hardware Configuration
Hardware configuration is integrated with the Cisco Unified Communications (UC)
installation process. The hardware configuration includes the following:
■ A check for correct hardware configuration, supported platforms, and minimum
hardware requirements
■ Configuration of the correct BIOS and RAID settings on the supported platforms
Basic Installation (Installation DVD)
This topic describes the process for performing a basic installation of the operating system
and CUCM Release 6.0 application on the publisher. CUCM Release 6.0 has to be installed
on the publisher before installing it on any subscriber nodes.
NOTE Only the products that are supported on your server appear in the list.
CUCM Installation and Upgrade Overview 57
To select the Basic installation option, choose No in both the Apply Additional Release
window and the Import Windows Data window.
Important Configuration Information
During the installation process, the installation prompts for various required information
based on the installation engineer’s answers to the installation prompts. Table 3-1 lists
important configuration information requested during CUCM setup.
Table 3-1 Installation Configuration Information
Field Description Usage
Administrator ID This field specifies the name
that you want to assign to this
account.
Ensure that the name is unique; it can contain
lowercase, alphanumeric characters, hyphens,
and underscores. It must start with a lowercase
alphanumeric character.
For this mandatory field, you should record it
for use when logging in to the CLI or into
Cisco Unified Communications Operating
System Administration.
Administrator
Password
This field specifies the
password that you use for
logging in to the CLI on the
platform and for logging in to
Cisco Unified Communications
Operating System
Administration.
Ensure that the password is at least six
characters long; it can contain alphanumeric
characters, hyphens, and underscores.
For this mandatory field, you should record it
for use when logging in to the CLI or into
Cisco Unified Communications Operating
System Administration.
DHCP Dynamic Host Configuration
Protocol.
Choose Yes if you want to use DHCP to
automatically configure the network settings
on your server.
If you choose No, you must enter a hostname,
IP address, IP mask, and gateway.
DNS Enabled A DNS server represents a
device that resolves a hostname
into an IP address or an IP
address into a hostname.
If you do not have a DNS server, choose No.
When DNS is not enabled, you should enter
only IP addresses (not hostnames) for all
network devices in your Cisco UC network.
If you have a DNS server, Cisco recommends
that you choose Yes to enable DNS.
Disabling DNS limits the system ability to
resolve some domain names.
continues
58 Chapter 3: Installation and Upgrade
DNS Primary The server contacts this DNS
server first when it attempts to
resolve hostnames.
Enter the IP address of the DNS server that
you want to specify as the primary DNS
server. Enter the IP address in dotted-decimal
format as ddd.ddd.ddd.ddd, where ddd can
have a value between 0 and 255 (except
0.0.0.0).
Consider this field mandatory if DNS is set
to Yes.
DNS Secondary When a primary DNS server
fails, the server attempts to
connect to the secondary DNS
server.
In this optional field, enter the IP address of
the secondary DNS. Enter the IP address in
dotted-decimal format as ddd.ddd.ddd.ddd,
where ddd can have a value between 0 and
255 (except 0.0.0.0).
Domain This field represents the name
of the domain in which this
machine is located.
Consider this field mandatory if DNS is set
to Yes.
First Cisco
Unified
Communications
Manager Node
This field specifies the first
CUCM node that contains the
database.
Subsequent nodes connect to
the first node to access database
content.
The first node also synchronizes
with an external Network Time
Protocol server and provides
time to the other nodes.
Choose Yes if you are configuring the first
CUCM node in the cluster.
Hostname A hostname represents an alias
that is assigned to an IP address
to identify it.
Enter a hostname that is unique to your
network.
The hostname can consist of up to 64
characters and can contain alphanumeric
characters and hyphens.
If DHCP is set to No, consider this field
mandatory.
Table 3-1 Installation Configuration Information (Continued)
Field Description Usage
CUCM Installation and Upgrade Overview 59
IP Address This field specifies the IP
address of this machine. It
uniquely identifies the server on
this network. Ensure that
another machine in this network
does not use this IP address.
Enter the IP address in the form
ddd.ddd.ddd.ddd, where ddd can have a
value between 0 and 255 (except 0.0.0.0).
If DHCP is set to No, consider this field
mandatory.
IP Mask This field specifies the IP
subnet mask of this machine.
The subnet mask, together with
the IP address, defines the
network address and the host
address.
Enter the IP mask in the form
ddd.ddd.ddd.ddd, where ddd can have a
value between 0 and 255 (except 0.0.0.0).
A valid mask should have contiguous 1 bits
on the left side and contiguous 0 bits on the
right.
For example, a valid mask follows:
255.255.240.0
(11111111.11111111.11110000.00000000)
An invalid mask follows: 255.255.240.240
(11111111.11111111.11110000.11110000)
NIC Speed This field specifies the speed of
the server network interface
card in megabits per second.
The possible speeds include 10 or 100.
NIC Duplex This field specifies the duplex
setting of the server network
interface card.
The possible settings include Half and Full.
NTP Server This field identifies the NTP
servers with which you want to
synchronize.
Enter the hostname or IP address of one or
more NTP servers.
Note that you can add additional NTP
servers or make changes to the NTP server
list at a later time.
NTP Server
Enable
When enabled, this server acts
as an NTP server and provides
time updates to the subsequent
nodes in the cluster.
Choose Yes if you want to enable this
machine to be an NTP server.
This option is available only on the first node
in a cluster.
continues
Table 3-1 Installation Configuration Information (Continued)
Field Description Usage
60 Chapter 3: Installation and Upgrade
Security
Password
Servers in the cluster use the
security password to
communicate with one another.
You are asked to enter the same
security password for each
subsequent node in the cluster.
Enter the security password.
Enter the same password in the Confirm
Password field.
The password must contain at least six
alphanumeric characters. It can contain
hyphens and underscores, but it must start
with an alphanumeric character.
All nodes in the cluster must have the same
password.
Set Hardware
Clock
This field specifies the date and
local time for the machine.
Note that if you set the
hardware clock manually, the
node does not use an external
NTP server for time
synchronization.
Choose Yes if you want to set the date and
local time for the time zone that you choose.
Enter the hours based on a 24-hour format.
Note that if you configure an external NTP
server, the hardware clock gets set
automatically.
SMTP This field specifies the name of
the SMTP host that is used for
outbound e-mail.
Enter the hostname or dotted-decimal IP
address for the SMTP server. For a host,
it can contain alphanumeric characters,
hyphens, or periods. For a hostname, it must
start with an alphanumeric character.
You must fill in this field if you plan to use
electronic notification. If not, you can leave it
blank.
Subnet IP
Address
By entering a subnet address,
you can specify a range of IP
addresses that will be granted
access to query this NTP server.
Enter an IP subnet that will be granted access
to the NTP server
During installation, you can enter only two
subnets.
Subnet Mask This field specifies the subnet
mask for the subnet address.
Enter the subnet mask for the IP subnet.
Time Zone This field specifies the local
time zone and offset from
Greenwich mean time.
Choose Yes if you want to change the time
zone.
Choose the time zone that most closely
matches the location of your machine.
Table 3-1 Installation Configuration Information (Continued)
Field Description Usage
CUCM Installation and Upgrade Overview 61
Installation Procedures for Basic Install
Installation starts the same way for all three installation options: Insert the installation disc
in the DVD drive and reboot the server. The DVD Found window displays after the server
completes the boot sequence.
Figure 3-2 provides a flowchart displaying the various steps involved in installing CUCM
from a DVD.
Figure 3-2 Basic Installation Flow (DVD Installation)
The DVD prompts the installer to perform a media check. To perform the media check,
choose Yes. To skip the media check, choose No. If Yes was chosen, the installation process
performs a media check of the image on the DVD to ensure that the image is error free
before installation. If the disk is okay, the installation continues.
A hardware check is then performed to determine whether the correct hardware is installed,
and then the RAID and BIOS settings are configured.
Boots from DVD
at Product
Deployment
Selection –
Select Unified CM
Platform
Configuration
Completed OS and
Application
Installation Scripts
Starts
Proceed
with
Install
Platform
Installation
Wizard
Apply
Additional
Releases
Basic
Install –
Continue
No
No
No No
Yes
Yes
Yes
Proceed
No
Yes
No
No
Yes
Yes
TimeZone
Configuration
Import
Windows
Data
Auto
Negotiation
Config
Configure
SMTP Host
Address
Application
User
Config
Platform
Config
Confirmation
NTP Client
Config
Database
Access
Security
Config
SMTP
Host
Config
Publisher
Address and
Security
Password
Configure
DNS and
Domain
Administrator
Login
Config
Certificate
Information
Publisher
Config
NIC Speed
and Duplex
Configuration
Use
DHCP
Static
Network
Configuration
DNS
Client
Config
62 Chapter 3: Installation and Upgrade
After the hardware checks are complete, the Product Deployment Selection window displays.
In the Product Deployment Selection window, you can choose from the following options:
■ Cisco Unified Communications Manager
■ Cisco Unity Connection
■ Cisco Unified Communications Manager Business Edition (includes CUCM and Cisco
Unity Connection)
Select the first option (Cisco Unified Communication Manager) to install only CUCM.
The Overwrite Hard Drive window then indicates the current software version on your
hard drive and the version on the DVD. Choose No to halt the installation. Choose Yes to
overwrite the hard drive.
Next, choose the desired type of installation by performing the following steps.
In both the Apply Additional Release window and the Import Windows Data window,
choose No to select the Basic installation option. When you click Continue, the Platform
Installation wizard guides you through the installation process and gathers the required
information. Review this window to familiarize yourself with navigating within the
Platform Installation wizard, and follow these guidelines:
If you click Proceed, the Product Installation Configuration window displays immediately
before any software is copied or installed.
If you click Skip, the software is first transferred to the hard drive, and the system shuts
down. At the next boot, the system displays the Installation Configuration window. This is
the same state as on a factory-installed system, in which the software is preloaded but no
configuration has been done.
When the preloaded system boots, the Configuration dialog is completely skipped if a
Universal Serial Bus (USB) drive with a configuration file that includes all configuration
parameters is found. Such a configuration file can be prepared using the Answer File
Generator, as covered in the following section.
Basic Installation (Preinstalled)
After you boot the system, the Preexisting Installation Configuration window displays. If
preexisting configuration information generated by the Answer File Generator and stored
on a floppy disc or a USB key exists, you must insert the disc or the USB key and then click
Continue. In this case, the Installation wizard reads the configuration information from the
CUCM Installation and Upgrade Overview 63
USB key. If no configuration file on a USB key is provided, the Installation wizard prompts
for configuration data. Figure 3-3 shows this install process.
Figure 3-3 Basic Installation Flow (Preinstalled)
The only difference to a basic installation executed from the installation DVD is the ability
to skip over the configuration portion by providing a configuration file on a USB key.
The Answer File Generator is a web-based tool available at Cisco.com that provides the
answer file based on the form entries that the user has filled out. The Answer File Generator
was located at http://www.cisco.com/web/cuc_afg/index.html at the time of this writing.
A Cisco.com search for “Answer File Generator” will provide a link to the current version
of the tool.
Upgrade During Install
Service releases, engineering special updates, and security updates may be installed during
Basic installation. To install, make sure the additional release is downloaded and prepared
on a DVD or FTP/SFTP server before starting the installation. Click Yes in the Apply
Additional Release window.
Boots from
Hard Disk
Platform
Configuration
Completed
Configuration
Script Starts
Existing
USB
or Disk with
Pre-Existing
Config
File
Platform
Installation
Wizard
Apply
Additional
Releases
Basic
Install –
Continue
No
No
No
No
Yes
Yes
Yes
Yes
Proceed
No
No
No
No
Yes
Yes
TimeZone
Config
Import
Windows
Data
Auto
Negotiation
Config
Configure
SMTP Host
Address
Application
User
Config
Platform
Config
Confirmation
NTP Client
Config
Database
Access
Security
Config
SMTP
Host
Config
Subscriber
Address and
Security
Password
Configure
DNS and
Domain
Administrator
Login
Config
Certificate
Information
Publisher
Config
NIC Speed
and Duplex
Config
Use
DHCP
Static
Network
Config
DNS
Client
Config
64 Chapter 3: Installation and Upgrade
The installation starts when the server is booted from the installation DVD. Verify the
checksum for the DVD, and click Overwrite Hard Disk.
In the Platform Installation wizard, click Yes in the Apply Additional Releases window.
Then the installation of the operating system and application will start; when finished, the
system reboots.
After reboot, choose the upgrade retrieval mechanism:
■ Local: Specify path and filename on the local DVD.
■ FTP/SFTP: Configure network settings and enter the location and login information
for the remote file server.
The upgrade will start, and the appliance server will reboot when the upgrade is complete.
Figure 3-4 and Figure 3-5 show the entire process.
Figure 3-4 Upgrade During Installation Flowchart (1 of 2)
Boots from DVD
and at Product
Deployment
Selection –
Select Unified CM
Proceed
with
Install
Platform
Installation
Wizard
Apply
Additional
Releases
Install OS,
Application
and Reboots
No
No
No
Yes
Yes
Yes
Yes
Proceed
Yes Local
Remote
Retrieve
Upgrade
from CD
or DVD
Upgrade
Retrieval
Mechanism
Auto
Negotiation
Configuration
Configure
DNS and
Domain
Remote
Patch
Configuration
Install
Upgrade
Patch and
Reboots
NIC Speed
and Duplex
Configuration
Use
DHCP
Static
Network
Configuration
DNS
Client
Configuration
CUCM Installation and Upgrade Overview 65
Figure 3-5 Upgrade During Installation Flowchart (2 of 2)
Table 3-2 outlines the information required to configure the remote path, which includes
the location and login information necessary for CUCM to access patches to the product
via the file transfer mechanism specified.
Table 3-2 Remote Path Information Description
CUCM Call-Processing Redundancy Best CIsco CCSP Coaching in Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
A CUCM cluster is a group of physical servers working as a single IP PBX system. With
CUCM 6.0, a cluster may contain up to 20 servers, of which a maximum of 8 servers may
run the Cisco CallManager service performing call processing in a cluster. Other servers
can be used as TFTP servers or provide media resources such as software conference
bridges or music on hold (MOH).
CUCM call-processing redundancy is implemented by grouping servers running the Cisco
CallManager service into CUCM groups. A CM group is a prioritized list of one or more
call-processing servers. Figure 2-5 shows this 1:1 redundancy design.
The following rules apply for the CM groups:
■ Multiple CM groups can exist in the same cluster.
■ Each call-processing server can be assigned to more than one CM group.
■ Each device has to have a CM group assigned that will determine the primary and
backup servers to which it can register.
46 Chapter 2: Deployment Models
Figure 2-5 1:1 Redundancy Design
Cisco IP Phones register with their primary server. When idle, the Cisco IP Phones and
CUCM exchange signaling application keepalives. In addition, Cisco IP Phones establish
a TCP session with their secondary server and exchange TCP keepalives. When the
connection to the primary server is lost (no keepalives received), the Cisco IP Phone
registers to the secondary server. The Cisco IP Phone will continuously try to reestablish
a connection with the primary server; if successful, the Cisco IP Phone will reregister with
the primary server.
A 1:1 CUCM call-processing redundancy deployment design guarantees that Cisco IP
Phone registrations will never overwhelm the backup servers. Multiple primary servers can
fail concurrently, and the cluster would still be fully operational. The 1:1 design has an
increased server count compared to other redundancy design models. This design is not the
most cost-effective, but it offers the highest level of fault tolerance.
Each cluster must also provide a TFTP service. The TFTP service is responsible for
delivering IP phone configuration and firmware files to telephones, along with streamed
media files, such as MOH and ring files; therefore, the server running the TFTP service can
Cisco MCS 7845
Publisher and
TFTP Server
Scenario Three:
30,000 IP Phones
1 to 7500
7501 to
15,000
15,001 to
22,500
22,501 to
30,000
Backups
Cisco MCS 7845
Publisher and
TFTP Server
Scenario Two:
15,000 IP Phones
1 to 7500
7501 to
15,000
Backups Backups
Cisco MCS 7845
Publisher and
TFTP Server
(Not Req. < 1000)
Scenario One:
7500 IP Phones
Primary
1 to 7500
Backup
Primary
Secondary/Backup
IP
CUCM Call-Processing Redundancy 47
experience a considerable network and processor load. Depending on the number of
devices that a server is supporting, you can run the TFTP service on a dedicated server,
on the database publisher server, or on any other server in the cluster.
In this example, a Cisco 7845 Media Convergence Server (MCS) is used as the dedicated
database publisher and TFTP server. In addition, there are two call-processing servers
supporting a maximum of 7500 Cisco IP Phones (on the Cisco 7845 MCS platform). One
of these two servers is the primary server, and the other is a dedicated backup server. The
function of the database publisher and the TFTP server can be provided by the primary or
secondary call-processing server in a smaller IP telephony deployment (fewer than 1250 IP
phones with the MCS 7845). In this case, only two servers are needed in total.
When you increase the number of IP phones, you must increase the number of CUCM
servers that are required to support the telephones. Some network engineers may consider
the 1:1 redundancy design excessive, because a well-designed network is unlikely to lose
more than one primary server at a time. With the low possibility of server loss and the
increased server cost, many network engineers choose to use a 2:1 redundancy design,
as shown in Figure 2-6.
Figure 2-6 2:1 Redundancy Design
Cisco MCS 7845
Publisher and
TFTP Server
Scenario Three:
30,000 IP Phones
1 to 7500
7501 to
15,000
15,001 to
22,500
22,501 to
30,000
Backup
Cisco MCS 7845
Publisher and
TFTP Server
Scenario Two:
15,000 IP Phones
1 to 7500
7501 to
15,000
Backup Backup
Cisco MCS 7845
Publisher and
TFTP Server
(Not Req. < 1000)
Scenario One:
7500 IP Phones
Primary
1 to 7500
Backup
Primary
Secondary/Backup
IP
48 Chapter 2: Deployment Models
Although the 2:1 redundancy design offers some redundancy, there is the risk of overwhelming
the backup server if multiple primary servers fail. In addition, upgrading the
CUCM servers can cause a temporary loss of service because rebooting the CUCM servers
is required 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 Cisco MCS 7845 is used (shown in the figure), that
server is equipped with redundant, hot-swappable power supplies and hard drives. It is
unlikely that multiple primary servers will fail at the same time, which makes the 2:1
redundancy model an attractive option for most businesses.
Cisco recommends dedicating a TFTP server in any cluster that exceeds 1250 phones. In a
large cluster, Cisco recommends dedicating two servers to TFTP functionality.
As shown in the first scenario, when using no more than 7500 IP phones, there is no saving
in the 2:1 redundancy design compared to the 1:1 redundancy design (simply because there
is only a single primary server).
In the second scenario of Figure 2-6 with up to 15,000 IP phones, there are 2 primary
servers (each serving 7500 IP phones) and 1 secondary server. As long as only one primary
server fails, the backup server can take over. If both primary servers fail, the backup server
could serve only half of the IP phones.
The third scenario in Figure 2-6 illustrates a deployment with 30,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 take over, and all IP phones will operate normally.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
A CUCM cluster is a group of physical servers working as a single IP PBX system. With
CUCM 6.0, a cluster may contain up to 20 servers, of which a maximum of 8 servers may
run the Cisco CallManager service performing call processing in a cluster. Other servers
can be used as TFTP servers or provide media resources such as software conference
bridges or music on hold (MOH).
CUCM call-processing redundancy is implemented by grouping servers running the Cisco
CallManager service into CUCM groups. A CM group is a prioritized list of one or more
call-processing servers. Figure 2-5 shows this 1:1 redundancy design.
The following rules apply for the CM groups:
■ Multiple CM groups can exist in the same cluster.
■ Each call-processing server can be assigned to more than one CM group.
■ Each device has to have a CM group assigned that will determine the primary and
backup servers to which it can register.
46 Chapter 2: Deployment Models
Figure 2-5 1:1 Redundancy Design
Cisco IP Phones register with their primary server. When idle, the Cisco IP Phones and
CUCM exchange signaling application keepalives. In addition, Cisco IP Phones establish
a TCP session with their secondary server and exchange TCP keepalives. When the
connection to the primary server is lost (no keepalives received), the Cisco IP Phone
registers to the secondary server. The Cisco IP Phone will continuously try to reestablish
a connection with the primary server; if successful, the Cisco IP Phone will reregister with
the primary server.
A 1:1 CUCM call-processing redundancy deployment design guarantees that Cisco IP
Phone registrations will never overwhelm the backup servers. Multiple primary servers can
fail concurrently, and the cluster would still be fully operational. The 1:1 design has an
increased server count compared to other redundancy design models. This design is not the
most cost-effective, but it offers the highest level of fault tolerance.
Each cluster must also provide a TFTP service. The TFTP service is responsible for
delivering IP phone configuration and firmware files to telephones, along with streamed
media files, such as MOH and ring files; therefore, the server running the TFTP service can
Cisco MCS 7845
Publisher and
TFTP Server
Scenario Three:
30,000 IP Phones
1 to 7500
7501 to
15,000
15,001 to
22,500
22,501 to
30,000
Backups
Cisco MCS 7845
Publisher and
TFTP Server
Scenario Two:
15,000 IP Phones
1 to 7500
7501 to
15,000
Backups Backups
Cisco MCS 7845
Publisher and
TFTP Server
(Not Req. < 1000)
Scenario One:
7500 IP Phones
Primary
1 to 7500
Backup
Primary
Secondary/Backup
IP
CUCM Call-Processing Redundancy 47
experience a considerable network and processor load. Depending on the number of
devices that a server is supporting, you can run the TFTP service on a dedicated server,
on the database publisher server, or on any other server in the cluster.
In this example, a Cisco 7845 Media Convergence Server (MCS) is used as the dedicated
database publisher and TFTP server. In addition, there are two call-processing servers
supporting a maximum of 7500 Cisco IP Phones (on the Cisco 7845 MCS platform). One
of these two servers is the primary server, and the other is a dedicated backup server. The
function of the database publisher and the TFTP server can be provided by the primary or
secondary call-processing server in a smaller IP telephony deployment (fewer than 1250 IP
phones with the MCS 7845). In this case, only two servers are needed in total.
When you increase the number of IP phones, you must increase the number of CUCM
servers that are required to support the telephones. Some network engineers may consider
the 1:1 redundancy design excessive, because a well-designed network is unlikely to lose
more than one primary server at a time. With the low possibility of server loss and the
increased server cost, many network engineers choose to use a 2:1 redundancy design,
as shown in Figure 2-6.
Figure 2-6 2:1 Redundancy Design
Cisco MCS 7845
Publisher and
TFTP Server
Scenario Three:
30,000 IP Phones
1 to 7500
7501 to
15,000
15,001 to
22,500
22,501 to
30,000
Backup
Cisco MCS 7845
Publisher and
TFTP Server
Scenario Two:
15,000 IP Phones
1 to 7500
7501 to
15,000
Backup Backup
Cisco MCS 7845
Publisher and
TFTP Server
(Not Req. < 1000)
Scenario One:
7500 IP Phones
Primary
1 to 7500
Backup
Primary
Secondary/Backup
IP
48 Chapter 2: Deployment Models
Although the 2:1 redundancy design offers some redundancy, there is the risk of overwhelming
the backup server if multiple primary servers fail. In addition, upgrading the
CUCM servers can cause a temporary loss of service because rebooting the CUCM servers
is required 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 Cisco MCS 7845 is used (shown in the figure), that
server is equipped with redundant, hot-swappable power supplies and hard drives. It is
unlikely that multiple primary servers will fail at the same time, which makes the 2:1
redundancy model an attractive option for most businesses.
Cisco recommends dedicating a TFTP server in any cluster that exceeds 1250 phones. In a
large cluster, Cisco recommends dedicating two servers to TFTP functionality.
As shown in the first scenario, when using no more than 7500 IP phones, there is no saving
in the 2:1 redundancy design compared to the 1:1 redundancy design (simply because there
is only a single primary server).
In the second scenario of Figure 2-6 with up to 15,000 IP phones, there are 2 primary
servers (each serving 7500 IP phones) and 1 secondary server. As long as only one primary
server fails, the backup server can take over. If both primary servers fail, the backup server
could serve only half of the IP phones.
The third scenario in Figure 2-6 illustrates a deployment with 30,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 take over, and all IP phones will operate normally.
Multisite Deployment with Distributed Call Processing Best Cisco CCNP Coaching in Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
As illustrated in Figure 2-3, the model for a multisite WAN deployment with distributed
call processing consists of multiple independent sites, each with its own CUCM cluster,
connected to an IP WAN that carries voice traffic between the distributed sites.
CUCM, applications, and DSP resources may be located at each site. The IP WAN carries
signaling traffic only for intersite calls; signaling traffic for calls within a site remains local
to the site. This way, the amount of signaling traffic between sites is reduced compared to
a Centralized Call Processing model.
With the use of gatekeepers, a Distributed Call Processing model can scale to hundreds
of sites. It also provides transparent use of the PSTN in the event that the IP WAN is
unavailable.
40 Chapter 2: Deployment Models
Figure 2-3 Multisite WAN with Distributed Call Processing
The Multisite with Distributed Call Processing model has the following design characteristics:
■ Maximum of 30,000 SCCP or SIP IP phones or SCCP video endpoints per cluster.
■ Maximum of 1100 MGCP gateways or H.323 devices (gateways, MCUs, trunks, and
clients) per CUCM cluster.
IP
SIP/SCCP
IP
SIP/SCCP
Unified CM
Cluster
Unified CM
Cluster
V V
IP
Unified CM
Cluster
SIP/SCCP
PSTN
V
IP WAN
GK
Gatekeeper
Multisite Deployment with Distributed Call Processing 41
■ PSTN for all external calls.
■ DSP resources for conferencing, transcoding, and MTP.
■ Voice mail, unified messaging, and Cisco Unified Presence components.
■ Capability to integrate with legacy PBX and voice-mail systems.
■ H.323 clients, MCUs, and H.323/H.320 gateways that require a gatekeeper to place
calls must register with a Cisco IOS Gatekeeper (Cisco IOS Release 12.3(8)T or later).
CUCM then uses an H.323 trunk to integrate with the gatekeeper and provide callrouting
and bandwidth management services for the H.323 devices registered to it.
Multiple Cisco IOS Gatekeepers may be used to provide redundancy. Cisco IOS
Gatekeepers may also be used to provide call-routing and bandwidth management
between the distributed CUCM clusters. In most situations, Cisco recommends that
each CUCM cluster have its own set of endpoint gatekeepers and that a separate set of
gatekeepers be used to manage the intercluster calls. It is possible in some
circumstances to use the same set of gatekeepers for both functions, depending on the
size of the network, the complexity of the dial plan, and so forth.
■ MCU resources are required in each cluster for multipoint videoconferencing.
Depending on conferencing requirements, these resources may be either SCCP or
H.323 or both, and they may all be located at the regional sites or may be distributed
to the remote sites of each cluster if local conferencing resources are required.
■ H.323/H.320 video gateways are needed to communicate with H.320 videoconferencing
devices on the public ISDN network. All these gateways may be located at the
regional sites, or they may be distributed to the remote sites of each cluster if local
ISDN access is required.
■ High-bandwidth audio (for example, G.711, G.722, or Cisco Wideband Audio)
between devices in the same site, but low-bandwidth audio (for example, G.729
or G.728) between devices in different sites.
■ High-bandwidth video (for example, 384 kb/s or greater) between devices in the same
site, but low-bandwidth video (for example, 128 kb/s) between devices at different
sites. The Cisco Unified Video Advantage wideband codec, operating at 7 Mb/s, is
recommended only for calls between devices at the same site. Note that the Cisco
VT Camera wideband video codec is not supported over intercluster trunks.
42 Chapter 2: Deployment Models
Benefits
The Multisite WAN with Distributed Call Processing model provides the following
benefits:
■ PSTN call cost savings when using the IP WAN for calls between sites.
■ Use of the IP WAN to bypass toll charges by routing calls through remote-site
gateways, closer to the PSTN number dialed (TEHO).
■ Maximum utilization of available bandwidth by allowing voice traffic to share the
IP WAN with other types of traffic.
■ No loss of functionality during IP WAN failure because there is a call-processing
agent at each site.
■ Scalability to hundreds of sites.
■ Gatekeeper networks can scale to hundreds of sites, and the design is limited only by
the WAN topology.
Best Practices
A multisite WAN deployment with distributed call processing has many of the same requirements
as a single-site or a multisite WAN deployment with centralized call processing.
Follow the best practices from these other models in addition to the ones listed here for the
Distributed Call Processing model.
Among the key elements of this Multisite WAN model are the SIP or gatekeeper proxy
servers. They each provide dial plan resolution, with the gatekeeper also providing CAC.
A gatekeeper is an H.323 device that provides CAC and E.164 dial plan resolution.
The following best practices apply to the use of a gatekeeper:
■ Use a Cisco IOS Gatekeeper to provide CAC into and out of each site.
■ To provide high availability of the gatekeeper, use Hot Standby Router Protocol
(HSRP) gatekeeper pairs, gatekeeper clustering, and alternate gatekeeper support.
In addition, use multiple gatekeepers to provide redundancy within the network.
■ Size the platforms appropriately to ensure that performance and capacity requirements
can be met.
Clustering over the IP WAN 43
■ Use only one type of audio codec on the WAN, because the H.323 specification does
not allow for Layer 2, IP, User Data Protocol (UDP), or Real-Time Transport Protocol
(RTP) header overhead in the bandwidth request. Using one type of codec on the WAN
simplifies capacity planning by eliminating the need to overprovision the IP WAN to
allow for the worst-case scenario.
Clustering over the IP WAN
Cisco supports CUCM clusters over a WAN. Characteristics include the following:
■ Applications and CUCM of the same cluster distributed over the IP WAN.
■ IP WAN carries intracluster server communication and signaling.
■ Limited number of sites:
—Two to four sites for local failover (two CUCM servers per site)
—Up to eight sites for remote failover across the IP WAN (one CUCM
server per site)
The cluster design, as illustrated in Figure 2-4, is useful for customers who require more
functionality than the limited feature set offered by SRST. This network design also allows
remote offices to support more IP phones than SRST in the event that the connection to the
primary CUCM is lost.
Figure 2-4 Clustering over the IP WAN
IP
IP
SIP/SCCP
Publisher/TFTP Subscribers
IP WAN
V V
<40 ms Round-Trip Delay
QoS Enabled BW
IP
IP
SIP/SCCP
44 Chapter 2: Deployment Models
The design guidelines for clustering over the IP WAN are as follows:
■ Two CUCM servers in a cluster must have a maximum round-trip time (RTT) delay of
40 ms between them. Because of the strict 40-ms database replication requirement, this
design can be used only between high-speed locations. The sites cannot be located on
separate coasts of the United States, for example, because the speed of light is not
capable of communicating between New York and California (propagation delay). In
comparison to this strict RTT database requirement, high-quality voice guidelines
dictate that one-way end-to-end delay should not exceed 150 ms.
■ For every 10,000 busy hour call attempts (BHCA) within the cluster, an additional
900 kb/s of WAN bandwidth for intracluster runtime communication must be supported.
The BHCA represents the number of call attempts made during the busiest hour of
the day.
■ Up to eight small sites are supported using the Remote Failover deployment model.
Remote failover allows one server per location with a maximum of eight call-processing
servers supported in a cluster. In the event of CUCM failure, IP phones register to
another server over the WAN. SRST is not required in this deployment model. The
remote failover design may require significant additional bandwidth, depending on the
number of telephones at each location.
NOTE In earlier versions of CUCM, subscriber servers in the cluster used the publisher’s
database for read/write access, and they used their local database for read access only when
the publisher’s database could not be reached.
With CUCM 6.x, subscriber servers in the cluster read their local database. Database
modifications can occur in the local database (for special applications such as user-facing
features). IBM Informix Dynamic Server (IDS) database replication is used to synchronize
the databases on the various servers in the cluster. Therefore, when recovering from failure
conditions such as the loss of WAN connectivity for an extended period of time, the CUCM
databases must be synchronized with any changes that might have been made during the
outage. This process happens automatically when database connectivity is restored and can
take longer over low-bandwidth links.
In rare scenarios, manual reset or repair of the database replication between servers in the
cluster might be required. This reset/repair is performed by using commands such as utils
dbreplication repair all and utils dbreplication reset all at the command-line interface
(CLI). Repair or reset of database replication using the CLI on remote subscribers over the
WAN causes all CUCM databases in the cluster to be resynchronized, in which case
additional bandwidth above 1.544 Mb/s might be required. Lower bandwidths can take
longer for database replication repair or reset to complete.
CUCM Call-Processing Redundancy 45
Although there are stringent requirements, clustering over the IP WAN design offers these
advantages:
■ Single point of administration for users for all sites within the cluster
■ Feature transparency
■ Shared line appearances
■ Extension mobility within the cluster
■ Unified dial plan
The clustering over IP WAN design is useful for customers who want to combine the
resiliency advantages of this model with the benefits provided by a local call-processing
agent at each site. Intrasite signaling is kept local, and WAN failures will not result in loss
of functionality. 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 across 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 sites.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
As illustrated in Figure 2-3, the model for a multisite WAN deployment with distributed
call processing consists of multiple independent sites, each with its own CUCM cluster,
connected to an IP WAN that carries voice traffic between the distributed sites.
CUCM, applications, and DSP resources may be located at each site. The IP WAN carries
signaling traffic only for intersite calls; signaling traffic for calls within a site remains local
to the site. This way, the amount of signaling traffic between sites is reduced compared to
a Centralized Call Processing model.
With the use of gatekeepers, a Distributed Call Processing model can scale to hundreds
of sites. It also provides transparent use of the PSTN in the event that the IP WAN is
unavailable.
40 Chapter 2: Deployment Models
Figure 2-3 Multisite WAN with Distributed Call Processing
The Multisite with Distributed Call Processing model has the following design characteristics:
■ Maximum of 30,000 SCCP or SIP IP phones or SCCP video endpoints per cluster.
■ Maximum of 1100 MGCP gateways or H.323 devices (gateways, MCUs, trunks, and
clients) per CUCM cluster.
IP
SIP/SCCP
IP
SIP/SCCP
Unified CM
Cluster
Unified CM
Cluster
V V
IP
Unified CM
Cluster
SIP/SCCP
PSTN
V
IP WAN
GK
Gatekeeper
Multisite Deployment with Distributed Call Processing 41
■ PSTN for all external calls.
■ DSP resources for conferencing, transcoding, and MTP.
■ Voice mail, unified messaging, and Cisco Unified Presence components.
■ Capability to integrate with legacy PBX and voice-mail systems.
■ H.323 clients, MCUs, and H.323/H.320 gateways that require a gatekeeper to place
calls must register with a Cisco IOS Gatekeeper (Cisco IOS Release 12.3(8)T or later).
CUCM then uses an H.323 trunk to integrate with the gatekeeper and provide callrouting
and bandwidth management services for the H.323 devices registered to it.
Multiple Cisco IOS Gatekeepers may be used to provide redundancy. Cisco IOS
Gatekeepers may also be used to provide call-routing and bandwidth management
between the distributed CUCM clusters. In most situations, Cisco recommends that
each CUCM cluster have its own set of endpoint gatekeepers and that a separate set of
gatekeepers be used to manage the intercluster calls. It is possible in some
circumstances to use the same set of gatekeepers for both functions, depending on the
size of the network, the complexity of the dial plan, and so forth.
■ MCU resources are required in each cluster for multipoint videoconferencing.
Depending on conferencing requirements, these resources may be either SCCP or
H.323 or both, and they may all be located at the regional sites or may be distributed
to the remote sites of each cluster if local conferencing resources are required.
■ H.323/H.320 video gateways are needed to communicate with H.320 videoconferencing
devices on the public ISDN network. All these gateways may be located at the
regional sites, or they may be distributed to the remote sites of each cluster if local
ISDN access is required.
■ High-bandwidth audio (for example, G.711, G.722, or Cisco Wideband Audio)
between devices in the same site, but low-bandwidth audio (for example, G.729
or G.728) between devices in different sites.
■ High-bandwidth video (for example, 384 kb/s or greater) between devices in the same
site, but low-bandwidth video (for example, 128 kb/s) between devices at different
sites. The Cisco Unified Video Advantage wideband codec, operating at 7 Mb/s, is
recommended only for calls between devices at the same site. Note that the Cisco
VT Camera wideband video codec is not supported over intercluster trunks.
42 Chapter 2: Deployment Models
Benefits
The Multisite WAN with Distributed Call Processing model provides the following
benefits:
■ PSTN call cost savings when using the IP WAN for calls between sites.
■ Use of the IP WAN to bypass toll charges by routing calls through remote-site
gateways, closer to the PSTN number dialed (TEHO).
■ Maximum utilization of available bandwidth by allowing voice traffic to share the
IP WAN with other types of traffic.
■ No loss of functionality during IP WAN failure because there is a call-processing
agent at each site.
■ Scalability to hundreds of sites.
■ Gatekeeper networks can scale to hundreds of sites, and the design is limited only by
the WAN topology.
Best Practices
A multisite WAN deployment with distributed call processing has many of the same requirements
as a single-site or a multisite WAN deployment with centralized call processing.
Follow the best practices from these other models in addition to the ones listed here for the
Distributed Call Processing model.
Among the key elements of this Multisite WAN model are the SIP or gatekeeper proxy
servers. They each provide dial plan resolution, with the gatekeeper also providing CAC.
A gatekeeper is an H.323 device that provides CAC and E.164 dial plan resolution.
The following best practices apply to the use of a gatekeeper:
■ Use a Cisco IOS Gatekeeper to provide CAC into and out of each site.
■ To provide high availability of the gatekeeper, use Hot Standby Router Protocol
(HSRP) gatekeeper pairs, gatekeeper clustering, and alternate gatekeeper support.
In addition, use multiple gatekeepers to provide redundancy within the network.
■ Size the platforms appropriately to ensure that performance and capacity requirements
can be met.
Clustering over the IP WAN 43
■ Use only one type of audio codec on the WAN, because the H.323 specification does
not allow for Layer 2, IP, User Data Protocol (UDP), or Real-Time Transport Protocol
(RTP) header overhead in the bandwidth request. Using one type of codec on the WAN
simplifies capacity planning by eliminating the need to overprovision the IP WAN to
allow for the worst-case scenario.
Clustering over the IP WAN
Cisco supports CUCM clusters over a WAN. Characteristics include the following:
■ Applications and CUCM of the same cluster distributed over the IP WAN.
■ IP WAN carries intracluster server communication and signaling.
■ Limited number of sites:
—Two to four sites for local failover (two CUCM servers per site)
—Up to eight sites for remote failover across the IP WAN (one CUCM
server per site)
The cluster design, as illustrated in Figure 2-4, is useful for customers who require more
functionality than the limited feature set offered by SRST. This network design also allows
remote offices to support more IP phones than SRST in the event that the connection to the
primary CUCM is lost.
Figure 2-4 Clustering over the IP WAN
IP
IP
SIP/SCCP
Publisher/TFTP Subscribers
IP WAN
V V
<40 ms Round-Trip Delay
QoS Enabled BW
IP
IP
SIP/SCCP
44 Chapter 2: Deployment Models
The design guidelines for clustering over the IP WAN are as follows:
■ Two CUCM servers in a cluster must have a maximum round-trip time (RTT) delay of
40 ms between them. Because of the strict 40-ms database replication requirement, this
design can be used only between high-speed locations. The sites cannot be located on
separate coasts of the United States, for example, because the speed of light is not
capable of communicating between New York and California (propagation delay). In
comparison to this strict RTT database requirement, high-quality voice guidelines
dictate that one-way end-to-end delay should not exceed 150 ms.
■ For every 10,000 busy hour call attempts (BHCA) within the cluster, an additional
900 kb/s of WAN bandwidth for intracluster runtime communication must be supported.
The BHCA represents the number of call attempts made during the busiest hour of
the day.
■ Up to eight small sites are supported using the Remote Failover deployment model.
Remote failover allows one server per location with a maximum of eight call-processing
servers supported in a cluster. In the event of CUCM failure, IP phones register to
another server over the WAN. SRST is not required in this deployment model. The
remote failover design may require significant additional bandwidth, depending on the
number of telephones at each location.
NOTE In earlier versions of CUCM, subscriber servers in the cluster used the publisher’s
database for read/write access, and they used their local database for read access only when
the publisher’s database could not be reached.
With CUCM 6.x, subscriber servers in the cluster read their local database. Database
modifications can occur in the local database (for special applications such as user-facing
features). IBM Informix Dynamic Server (IDS) database replication is used to synchronize
the databases on the various servers in the cluster. Therefore, when recovering from failure
conditions such as the loss of WAN connectivity for an extended period of time, the CUCM
databases must be synchronized with any changes that might have been made during the
outage. This process happens automatically when database connectivity is restored and can
take longer over low-bandwidth links.
In rare scenarios, manual reset or repair of the database replication between servers in the
cluster might be required. This reset/repair is performed by using commands such as utils
dbreplication repair all and utils dbreplication reset all at the command-line interface
(CLI). Repair or reset of database replication using the CLI on remote subscribers over the
WAN causes all CUCM databases in the cluster to be resynchronized, in which case
additional bandwidth above 1.544 Mb/s might be required. Lower bandwidths can take
longer for database replication repair or reset to complete.
CUCM Call-Processing Redundancy 45
Although there are stringent requirements, clustering over the IP WAN design offers these
advantages:
■ Single point of administration for users for all sites within the cluster
■ Feature transparency
■ Shared line appearances
■ Extension mobility within the cluster
■ Unified dial plan
The clustering over IP WAN design is useful for customers who want to combine the
resiliency advantages of this model with the benefits provided by a local call-processing
agent at each site. Intrasite signaling is kept local, and WAN failures will not result in loss
of functionality. 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 across 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 sites.
Subscribe to:
Comments (Atom)