CCNA Collaboration CICD 210-060 Official Cert Guide: Managing Endpoints and End Users in CUCM

This chapter is from the book 

Foundation Topics

Implementing IP Phones in CUCM

The implementation of IP phones is remarkably simple, considering the myriad of services, protocols, and processes going on in the background to make the system work well. This section reviews these “hidden” processes and details some of the administrative tasks required to easily and reliably run IP phones in CUCM.

Special Functions and Services Used by IP Phones

A variety of standards-based and proprietary protocols and services support IP phones in CUCM. In no particular order, they include the following:

• Network Time Protocol (NTP)
• Cisco Discovery Protocol (CDP)
• Dynamic Host Configuration Protocol (DHCP)
• Power over Ethernet (PoE)
• Trivial File Transfer Protocol (TFTP)
• Domain Name System (DNS)

The next section describes each of these services, how IP phones use them, and how to configure them in CUCM (or other systems as appropriate).

NTP

NTP is an IP standard that provides network-based time synchronization. There are many good reasons to use NTP beyond the convenience and consistency of having the same time on all devices. Call detail records (CDRs) and call management records (CMRs) are time stamped, as are log files. Comparing sequential events across multiple platforms is much simpler and easier to understand if the relative time is exactly the same on all those devices. Some functions and features can also be time (calendar) based, so time synchronization is important for those functions to operate properly.

In a typical NTP implementation, a corporate router synchronizes its clock with an Internet time server (such as an atomic clock or a GPS clock). Other devices in the corporate network then sync to the router.

The CUCM Publisher is one such device; during installation, CUCM asks for the IP address of an NTP server. (Alternatively, it can use its internal clock, which is not recommended because of its inaccuracy compared to NTP.) The Subscriber servers then sync their clocks to the Publisher, and the IP phones get their time from their subscribers via Skinny Client Control Protocol (SCCP) messages. Session Initiation Protocol (SIP) phones need an NTP reference (detailed later), but in the absence of one, they can get the time from the time stamp in the SIP OK response from the Subscriber server.

CDP

CDP is a Cisco proprietary Layer 2 protocol that provides network mapping information to directly connected Cisco devices. (You learned about CDP in your CCNA studies, so we do not detail it here.) Cisco IP phones generate CDP messages and use CDP to learn the voice VLAN ID from the Cisco switch to which they are connected. The IP phone then tags the voice frames it is transmitting with that VLAN ID in the 802.1Q/P frame header.

DHCP

DHCP is a widely used IP standard that can provide the following information to IP phones:

• IP address
• Subnet mask
• Default gateway
• DNS servers
• TFTP servers

Although it is possible to statically configure IP phones with all that information, it would be time-consuming and error-prone. DHCP is faster, easier, more scalable, and a widely accepted practice. DHCP can be provided by an existing DHCP server (because most deployments already have one), a local router, or even by CUCM itself (although this is not generally recommended for large deployments). Later sections review the configuration of DHCP services in CUCM and router IOS.

PoE

PoE is a standards-based feature that delivers DC power supply over Ethernet cabling. IP phones can use this feature, and doing so means less cabling to clutter the desk, no power supplies to buy for the phones, and potential cost savings. PoE is generally assumed to be provided by the switch that the phones connect to, but it may also be provided by a powered patch panel or inline power injector.

TFTP

TFTP is a critical service for IP phones. The phones use TFTP to download their config files, firmware, and other data. Without TFTP, the phones simply do not function properly. When you make a configuration change to a device, CUCM creates or modifies a config file for the device and uploads it to the TFTP servers. TFTP services must therefore be provided by one (or more in large deployments) of the CUCM servers in the cluster; a generic TFTP server will not have the integrated capability that a CUCM TFTP server does and will not correctly fulfill the role.

DNS

DNS provides hostname-to-IP address resolution. DNS services are not critical to IP phones. (In fact, in most deployments, it is recommended to eliminate DNS reliance from the IP phones [see Chapter 10, “Understanding CUCM Dial Plan Elements and Interactions”].) But in some circumstances, it is desirable. A DNS server must be external to the CUCM cluster; DNS is not a service that CUCM can offer.

IP Phone Registration Process

The steps that each phone goes through as it registers and becomes operational are more complex than you might think. The following section reviews these steps:

• Step 1. The phone obtains power (PoE or AC adapter).
• Step 2. The phone loads its locally stored firmware image.
• Step 3. The phone learns the voice VLAN ID via CDP from the switch.
• Step 4. The phone uses DHCP to learn its IP address, subnet mask, default gateway, and TFTP server address. (Other items may be learned also.)
• Step 5. The phone contacts the TFTP server and requests its configuration file. (Each phone has a customized configuration file named SEP<mac_address>.cnf.xml created by CUCM and uploaded to TFTP when the administrator creates or modifies the phone.)
• Step 6. The phone registers with the primary CUCM server listed in its configuration file. CUCM then sends the softkey template to the phone using SCCP messages.

SIP Phone Registration Process

SIP phones use a different set of steps to achieve the same goal. Steps 1 to 4 are the same as SCCP phones. The following are the rest of the steps:

• Step 1. The phone contacts the TFTP server and requests the Certificate Trust List file (only if the cluster is secured).
• Step 2. The phone contacts the TFTP server and requests its SEP<mac_address>.cnf.xml configuration file.
• Step 3. The phone downloads the SIP Dial Rules (if any) configured for that phone.
• Step 4. The phone registers with the primary CUCM server listed in its configuration file.
• Step 5. The phone downloads the appropriate localization files from TFTP.
• Step 6. The phone downloads softkey configurations from TFTP.
• Step 7. The phone downloads custom ringtones (if any) from TFTP.

Preparing CUCM to Support Phones

Before we add phones, a certain amount of work should be done on the CUCM servers. Doing this setup work makes adding phones easier, more consistent, and more scalable, assuming that we follow our design plan.

The tasks we review in this section are as follows:

• Configure and Verify Network Services: Set up NTP, DHCP, and TFTP.
• Configure Enterprise Parameters: Modify and verify cluster-wide default settings.
• Configure Service Parameters: Tune application settings and behavior.

Service Activation

Many required services are deactivated by default on CUCM. Using the Unified Serviceability admin page, you must activate the one you need. For our purposes, we activate the Cisco CallManager, Cisco TFTP, and Cisco DHCP Monitor services. Figure 9-1 shows the Unified Serviceability Service Activation page with those services activated.

DHCP Server Configuration

CUCM includes a basic DHCP server capability. It is intended to support only IP phones, and not very many of them: only up to 1000 phones. (This is the maximum recommended due to heavy CPU load.) There is no native capability for DHCP server redundancy and only one DHCP server is supported per cluster. Multiple subnets (scopes) can be configured on the server.

If you decide that you want to use CUCM for DHCP, setting up the DHCP service is straightforward. We already activated the DHCP Monitor Service, so now we follow these basic steps:

• Step 1. Navigate to System > DHCP > DHCP Server.
• Step 2. Click Add New.
• Step 3. Select the server running the DHCP Monitor Service from the pull-down.
• Step 4. Configure the desired settings.

The settings that can be configured on the Server page include the following (among others):

• Primary DNS Server IPv4 Address
• Primary TFTP Server IPv4 Address
• IP Address Lease Time

Any settings you configure on the server page are inherited by the subnet configuration (shown next); however, any setting you change on the subnet page overrides the Server setting. Figure 9-2 shows the DHCP Server Configuration page.

Configuring DHCP subnets requires some understanding of IP subnetting and assumes that you have an IP addressing plan in place. Because these topics are covered in the CCNA prerequisite, we assume you have a grasp of these fundamentals. To configure DHCP subnets, navigate to System > DHCP > DHCP Subnet. Click Add New to create subnets; you can create multiple subnets as needed for your environment design. On the Subnet Configuration page, select the server from the DHCP Server drop-down list. You can then configure the following (some other settings are not listed):

• Subnet address
• Primary range start IP
• Primary range end IP
• Primary router IP address (default gateway)
• Subnet mask
• Primary DNS server IP address
• TFTP server IP address

Remember that settings in the subnet configuration override the same settings in the server configuration. Figure 9-3 shows the DHCP Subnet Configuration page.

Configuring DHCP in Router IOS

Cisco routers support basic DHCP server functionality, and this capability is commonly used in small office environments where a dedicated DHCP server is not needed or available. Example 9-1 shows a typical DHCP configuration, with commands annotated for reference:

Example 9-1 DHCP Configuration

service dhcp
! Enables the DHCP service
!
ip dhcp excluded-address 10.1.1.1 10.1.1.10
! Specifies a start / end range of addresses that DHCP will NOT assign
ip dhcp pool name IP_PH0NES
! Creates a pool of addresses (case-sensitive name) and enters DHCP configuration mode
!
network 10.1.1.0 255.255.255.0
! Defines the subnet address for the pool
default-router address 10.1.1.1
! Defines the default gateway
dns-server address 192.168.1.10 192.168.1.11
! Identifies the DNS server IP address(es) - up to 8 IPs
!
option 150 ip 192.168.1.2
! Identifies the TFTP server IP. Multiple IPs may be included, separated by spaces.

Multiple DHCP pools can be created, so DHCP services can be provided for PCs in a small office by the same router. For some third-party SIP phones, it may be necessary to specify Option 66 (the TFTP server DNS name).

IP Phone Configuration Requirements in CUCM

CUCM has several configuration elements for IP phones. We briefly look at the following basic required elements:

• Device pool
• Cisco Unified CM group
• Region
• Location
• Date/time group
• Phone NTP reference
• Device defaults
• Softkey template
• Phone button template
• SIP profile
• Phone security profile
• Common phone profile

Device Pool

Device pools provide a set of common configurations to a group of devices; think of a device pool as a template to apply several different settings all at once, quickly and accurately. You can create as many device pools as you need, typically one per location, but they can also be applied per function. (For example, all the phones in the call center may use a different device pool from the rest of the phones in the administration offices, although they are all at the same location.) There are several settings within the device pool; some of the ones relevant to us are as follows:

• Cisco Unified CM group: A CM group defines a top-down ordered list of redundant call-processing servers to which the phones can register. The list can include a maximum of three servers (plus an optional Survivable Remote Site Telephony [SRST] reference). The first server in the list is the primary subscriber, the second is the backup, and the third is the tertiary. In normal operation, phones send primary registration messages to the primary, backup registration messages to the backup, and nothing to the tertiary. If the primary server fails or otherwise becomes unavailable, the phone sends a primary registration message to the backup server (and registers with it) and begins sending backup registration messages to the tertiary.

  The number of CM groups created depends on the number of subscribers in the cluster; the goal is to provide server redundancy to the phones while distributing phone registrations evenly as planned in the system design. A server may be listed in more than one CM group to provide an overlapping depth of coverage, as long as its performance capacity will not be exceeded in any foreseeable failure circumstance. This is simply another requirement of a good design.

• Region: A region is a virtual assignment that allows the system designer to control the bit rate for calls. For example, if we define two regions, called Vancouver_HQ_REG and Ottawa_BR_REG, we can set the bit rate for calls within the Vancouver region to 256 kbps, within the Ottawa region to 64 kbps, and between the two regions to 16 kbps.

  We are in effect selecting (or at least influencing) the codec to be used for these calls; the codec in turn generates a known bit rate, which in turn uses a predictable amount of bandwidth and provides a predictable voice quality. In general, it is assumed that WAN bandwidth is limited; selecting a lower bit rate reduces the amount of bandwidth per call at the expense of call quality.

• Location: As you just saw, we can select the appropriate bit rate for calls and, therefore, the bandwidth used by each call. Given that WAN bandwidth is assumed to be limited, we need to be able to limit the amount of bandwidth used by calls to a particular location. Location defines a maximum amount of bandwidth used by calls to a particular location; each call is tracked, and the bandwidth it uses is deducted from the total for that location. When the bandwidth remaining is not enough to support another call at a given bit rate, that call is dropped by default (but may be rerouted over the PSTN if AAR is correctly configured). This is one mechanism for Call Admission Control (CAC), which is described later in this book.
• Date/time group: As discussed earlier, it is recommended to use NTP for time synchronization of all devices. The problem is that NTP references Greenwich mean time, which makes the time displayed on devices “wrong” if they are not in the GMT time zone. Date/time groups allow us to offset the correct time learned via NTP to match the local time zone of the device. Date/Time Groups also allow us to display the time and date in the desired format, which can vary from place to place.
• Phone NTP reference: SIP phones need an NTP server address from which they can obtain the time using NTP. (This is not required for SCCP phones, which are configured to the correct time using SCCP signaling.) It is preferred that the NTP reference be local to the phones that need it.

It is common to have groups of phones with similar configurations. Using a device pool for each group simplifies and speeds up administrative tasks, while making them less error-prone in the bargain. Figure 9-4 shows part of a Device Pool Configuration page.

Device Defaults

The Device Defaults page lists all the supported endpoints (with separate entries for SCCP and SIP as necessary), and the firmware load, device pool, and phone button template each endpoint uses by default. This allows an administrator to set useful system-wide defaults for any newly registered device of each type.

Softkey Template and Phone Button Template

The softkey template controls what softkey button functions are available to the user; these are typically used for feature access (conference, transfer, park, Extension Mobility, and so on). Seven softkey templates are available by default, and you can create as many more as your design requires.

The Phone Button template defines the behavior of the buttons to the right of the phone screen (for most models). Eighty (or more) are defined by default because there are unique templates for each supported phone type—and for most phones, a separate template for SCCP and SIP. The default templates typically provide two lines and as many speed dials as there are remaining buttons on a particular phone model; you can add and customize the templates to assign each button one of many different functions.

Profiles

Profiles allow for a one-time configuration of repetitive tasks; several types of profiles exist, and you can create many versions of each type to be applied to phones as needed.

Phone Security Profile

A default phone security profile exists for each type of phone/protocol. These default profiles have security disabled; you can choose to configure the device as secured, set encrypted TFTP configuration files, and modify Certificate Authority Proxy settings.

Common Phone Profile

The common phone profile includes settings that control the behavior of the phone, including the following:

• DND settings
• Phone personalization capabilities
• VPN settings
• USB port behavior
• Video capabilities
• Power-save options

Adding Phones in CUCM

Phones can be added to CUCM in several ways:

• Manual configuration: The administrator creates a new phone, configuring all settings in real time on the Phone Configuration page.
• Auto-registration: The administrator configures CUCM to dynamically configure and add to the database any new IP phone that connects to the network.
• Bulk Administration Tool (BAT): Using templates configured for the purpose by the administrator in CUCM, the administrator creates CSV files that contain all the required information to create multiple phones in one operation.
• Auto Register Phone Tool (TAPS): An Interactive Voice Response (IVR) server enhances the auto-register and BAT functionality, providing an automated method of adding potentially thousands of phones at a time.
• Self-provisioning: Operating in a manner similar to TAPS, self-provisioning is a new capability for CUCM 10.x. The IVR and CTI capabilities are now integral to the CUCM application, and no external server is required; the required administrative steps are detailed later in this section.

The following sections provide more detail on each of these operations.

Manual Configuration of IP Phones

The basic steps for manually adding an IP phone are as follows:

• Step 1. Navigate to Device > Phone, and then click Add New.
• Step 2. Choose the IP phone model from the drop-down list.
• Step 3. Choose the device protocol (either SCCP or SIP; some phones will support only one protocol, and this step will be skipped).

• Step 4. Select, or enter, the required specific information for the phone. The five required settings that do not have default values (must be manually configured) include the following:

  • MAC Address: The MAC address is the unique identifier that links the IP phone hardware to the software configuration in CUCM. If you are building a phone for Bob, you must obtain the MAC address of the phone that will end up on Bob’s desk; otherwise, Bob will not see the correct settings, DN, and so forth.
  • Device Pool: The device pool (as described earlier in this chapter) applies many common settings to the phone that are relevant to its physical location and desired behavior.
  • Phone Button Template: The Phone Button template (also detailed earlier in this chapter) defines what functions are assigned to the buttons on the phone (DNs, speed dials, services, and so on).
  • Owner User ID: Associates or assigns the phone to a user account for license calculation purposes. This setting should not be confused with the user configuration page setting for device association, which is used for features such as the Self-Care Portal and Extension Mobility.
  • Device Security Profile: Applies a set of security-related configurations, as described previously in this chapter.

• Step 5. Click Save.

  When the page reloads, a new pane labeled Association Information appears on the left, in which you can configure the phone buttons functions. The base functionality (line, speed dial, intercom, service, and so on) is defined by the Phone Button template specified previously; here is where you specify what the DN number on the lines will be, what service is accessed, or which Intercom DN is dialed. Figure 9-5 shows the Phone Configuration page, including the Association Information pane.

  

  Figure 9-5 The Phone Configuration Page

  In the Association Information pane, continue the basic phone configuration steps, as follows:

• Step 6. Click Line [1] - Add New DN. The Directory Number Information page opens, in which you must enter a directory number, and optionally set the partition and other optional configurations. The following points highlight a few of the settings found on the Directory Number Configuration page:

  • Route Partition: As discussed in Chapter 10, the partition is part of the calling privileges system or class of control.
  • Alerting Name: This is the name to display on the caller’s phone when this phone is ringing. Some public switched telephone network (PSTN) connections might not support this functionality.
  • Call Forward and Call Pickup Settings: This is where the administrator can determine how to forward a call if the DN is busy or does not answer, or for Call Forward All. The user can set Call Forward All at the phone itself using the CallFwdAll softkey or on their user web page; other call forward settings (such as Busy and No Answer) are available to the user only on the user’s user web page and not on the phone.
  • Display: The text entered in the Display field serves as an internal caller ID. When this DN calls another IP phone, the display text replaces the calling DN number. In other words, if Bob’s DN is 5309 and the Display field is blank, when Bob calls Ethan, Ethan’s phone shows that 5309 is calling. If the Display field on Bob’s phone has Bob Loblaw as the entry, Ethan’s phone displays the caller as Bob Loblaw.
  • Line Text Label: This is the text that displays on the phone to describe the line; for example, if the second button on the phone is the shared DN for the Parts Desk, the line text label for line 2 might read “Parts Line.”
  • External Phone Number Mask: If this phone makes an off-net call (typically to the PSTN), this field can change the calling line ID (CLID) to present a full PSTN number instead of the internal DN.

• Step 7. Click Save twice.

  TIP

  The “Save twice” instruction is a recent one, and one that will trouble a lot of admins who are familiar with versions of CUCM prior to 9.x. Watch for the message at the top of the DN Configuration page when you click Save the first time: “Directory Number Configuration has refreshed due to a directory number change. Please click Save button to save the configuration.” If you do not Save again, your changes are not preserved (but this should only happen if you change the DN).

• Step 8. In the Related Links drop-down, select Configure Device (<Phone>), and then click Go.
• Step 9. You are now back at the Phone Configuration page for the new phone. At this point, if you need to continue making config changes you can do so, or you can click Save again to commit the changes so far. The page prompts you to “Click on the Apply Config button to have the changes take effect.” This happens because in order for the phone to adopt the changes, it has to reload with its new config. This requires either a restart or a reset, depending on what was changed.

It is common, especially if advanced features such as Extension Mobility or Cisco Unified Personal Communicator are in use, to associate a user with a particular device (IP phone). It is required to associate the user with the device if you want users to be able to use the user web pages to customize their phones. The end user is associated with the device (IP phone), and the device is associated with one or more DNs. This allows the user not only to access the user web pages to configure this phone, but for other applications and processes to interact with the user through the phone system.

So, what happens if you delete an end user who is associated with a device that is associated with a DN? Nothing. Although the association exists and is important and useful, the three database entities of user, device, and DN are independent of each other. The device and the DN do not go away if the user is deleted, and the same result applies if the device or DN are deleted (although a phone without a DN, or a DN without a phone, cannot make calls).

Auto-Registration of IP Phones

CUCM includes the auto-registration feature, which dynamically adds new phones to the database and allows them to register, including issuing each new phone a DN so that it can place and receive calls. Auto-registration is supported by all Cisco IP phones.

To enable auto-registration, perform the following steps:

• Step 1. Verify your auto-registration phone protocol. Access this setting under System > Enterprise Parameters; choose either SCCP (default) or SIP. Phones that do not support the chosen protocol will still auto-register using their native protocol.
• Step 2. Verify that at least one CM Group has auto-registration enabled (by selecting the check box for Auto-Registration Cisco Unified Communications Manager Group).

• Step 3. Enable and configure auto-registration on one or more CUCM servers within the CM group enabled for auto-registration:

  • Enable auto-registration by deselecting the Auto-Registration Disabled on this Cisco Unified Communications Manager check box; it is disabled by default, so unchecking the box enables it.
  • Configure the range of DNs that will be dynamically and sequentially issued to auto-registering phones. The default starting directory number is 1000; if you change the ending directory number to anything higher than 1000, Auto-registration is automatically enabled. If you set the starting and ending DNs to the same value, auto-registration is automatically disabled. (Auto-registration is disabled by default because both the starting and ending directory numbers are set to 1000.) You want to choose a range of DNs that fits in well with your dial plan to avoid overlap and confusion.
  • Select a (previously configured) universal device template (UDT) and universal line template (ULT). UDTs and ULTs are introduced and explained in the following note.
  • Set the Partition that will be assigned to the auto-registered DNs. This is optional, but it is one good way to limit and control auto-registered phones.
  • Verify that the Auto-Registration Disabled on this Cisco Unified Communications Manager check box is unchecked, and then click Save.

A simple way to test auto-registration is to plug in a new phone; if it receives a DN in the range you specified (or a DN in the range of 1000 to 1999 if you left it at the defaults), auto-registration is working.

Some administrators see auto-registration as a security weakness because any IP phone will be dynamically added to the database and potentially begin making calls, perhaps even to the PSTN if it is not restricted. It is common to enable auto-registration only when it is needed to prevent the registration of “rogue phones.”

Figure 9-6 shows the Auto-Registration Information section of the Unified CM Configuration page.

Bulk Administration Tool

The Bulk Administration Tool (BAT) enables administrators to perform database inserts, modifications, or deletions in bulk. This makes it feasible to add a great many phones, users, or other elements more quickly and with fewer errors; it also allows the administrator to schedule the operation to happen automatically and unattended.

The BAT Export feature enables the administrator to pull selected records from the database and export them. The administrator can then modify the records and re-import them into the database, making bulk changes faster and more accurate.

BAT can be used to add, modify, or delete almost any component in CUCM, including phones, users, forced authorization codes and client matter codes, user device profiles, the region matrix, gateway devices, and many others.

The components of BAT include an Excel template that provides the required fields and formatting for the new unique data server-side templates that configure the common data and a set of web page interfaces for preparing and executing the many operations that BAT supports.

The Excel template is downloaded from the CUCM server. The administrator then customizes the templates for the needs of this BAT operation, populates the required fields with the correct data, and uploads the resulting CSV file to the server.

Using the BAT interface appropriate for the operation (insert phones, insert users, create call routing components, and so on), the administrator may need to create a server-side BAT Template for adding new devices, or in some cases simply select the uploaded CSV file for processing. If templates are required (as they would be if adding phones, for example), the template specifies all the settings that all the phones have in common, whereas the CSV file specifies all of the unique settings for each phone, such as DN, line text label, and so forth.

The only trick to adding phones with the BAT tool is that the MAC address of each phone must be specified. Using a barcode scanner to scan the MAC barcode label on the phone into the CSV file makes things faster and more accurate, but there is another challenge waiting for you: You create a detailed config for the phone, including DNs and other user-specific settings, and you specify the MAC address of the new phone. Now you must make sure that the physical phone with that MAC gets to the user it was built for; this is no easy task if several hundred phones are being deployed at once.

A couple of alternative strategies are available to make BAT deployments easier. One is to use auto-registration to get all the phones working and then use the BAT tool to modify the phones’ configurations after the fact. This approach still has some weaknesses, notably that you must still be positive of the MAC address of the physical phone that sits on the desk and match it to the database entry that BAT changes.

Auto Register Phone Tool

A more sophisticated (but much more complex) strategy involves the use of the Auto Register Phone Tool (formerly known as the Tool for Auto Registered Phone Support, but which is still known as TAPS because it is a better acronym than ARPT). TAPS goes one step further in the automation of new IP phone deployments, as summarized in the following steps:

• Step 1. An IP-IVR server is built and configured to support TAPS, and the CUCM server is integrated with the IP-IVR server. The IP-IVR functionality is supported by several Cisco applications, including Unified Contact Center Express.
• Step 2. The administrator prepares a BAT job, specifying a device template for all the common phone settings and a detailed CSV file with all the unique phone settings. The administrator runs the BAT job, substituting fake “dummy” MAC addresses for the as-yet-unknown real ones. (A simple check box in the BAT interface does this substitution automatically.)
• Step 3. The new phones are auto-registered and receive a DN. They can now place calls.
• Step 4. Using Bob’s phone as an example: Bob (or perhaps an administrator if Bob feels uncomfortable doing so) picks up his new auto-registered phone that currently has DN 1024 (from the default auto-registration range) and dials the specially configured IP-IVR pilot number.
• Step 5. The IP-IVR may prompt Bob to authenticate. (This is an optional but more secure approach.) When Bob has authenticated successfully, the IP-IVR prompts Bob to enter the extension his phone should have; in a new deployment, this may be provided to Bob on an information sheet, or it may simply be the same extension (let’s assume 5309 in this case) that he had on the old phone system that is being migrated to CUCM.
• Step 6. When Bob enters the extension, the IP-IVR records his input of 5309 and captures the MAC address of the phone Bob is using. The IP-IVR sends all this information to CUCM.
• Step 7. CUCM looks up the extension of 5309 in the database and finds it in the record for one of the newly added BAT job phones; the one that will become Bob’s phone. CUCM replaces the dummy MAC address in the BAT record with the real MAC captured and forwarded by the IP-IVR. The database record is now complete and accurate, including the real MAC address of the phone that sits on Bob’s desk.
• Step 8. CUCM restarts Bob’s phone, and when it comes back online, it is fully configured with all the specific details from the BAT record for Bob’s phone.

This is a powerful way to deploy thousands of IP phones. With some minor tweaks and some training of the users, it requires minimal administrator involvement in the phone deployment. The downside is that it requires the IP-IVR hardware and software and a capable administrator to configure it and still involves either training users to set up their own phones or using administrators to perform repetitive simple tasks, which are not cost-effective uses of their time.

Self-Provisioning

Self-provisioning is conceptually almost exactly the same as TAPS, with the very significant difference being that all of the IVR capability has been integrated into the CUCM application. This means that we no longer need to go to the trouble and expense of building and configuring an external IVR; we just configure CM to do it for us. Self-provisioning utilizes UDTs and ULTs, giving us even better customization with much less effort because we can leverage the variables definitions in the UDT and ULT.

Describe End Users in CUCM

It is technically true that a phone system does not need end users. If a person sits in front of a phone and starts using it, it does not really matter who the person is as long as the phone does what that person needs it to do. But a Unified Communications system provides much more than just phone functionality; it has a massive array of features that can be provided to and customized by individual users. Converged networks are increasingly complex, and end users expect an increasing simplicity of use. The configuration of end users is an integral part of a full-featured system, or as one of my friends put it: “All the fun stuff needs user accounts.”

End Users Versus Application Users

CUCM makes a clear distinction between end users and application users. The distinction is simple: End Users are typically people who type a username and password into a login screen (usually a web page) to access features or controls. An application user is typically an application that sends authentication information inline with a request to read or write information to a system (perhaps a third-party billing application accessing the CDR/CAR database, for example). Table 9-2 lists some of the characteristics and limitations of end users versus application users.

Table 9-2 End Users Versus Application Users

End Users	Application Users
Associated with an actual person	Associated with an application
For individual use in interactive logins	For noninteractive logins
Used to assign user features and administrative rights	Used for application authorization
Included in the user directory	Not included in the user directory
Can be provisioned and authenticated using Lightweight Directory Access Protocol (LDAP)	Must be provisioned locally (no LDAP)

Credential Policy

The credential policy defines preset passwords, end-user PINs, and application-user passwords. The default credential policy applies the application password specified at install to all application users.

Administrators can define additional policies that can specify the allowed number of failed login attempts, minimum password length, minimum time between password changes, number of previous passwords stored, and the lifetime of the password. The policy can also check for weak passwords. A strong password

• Contains three of the four characteristics: uppercase, lowercase, numbers, and symbols
• Cannot use the same number or character more than three times consecutively
• Cannot include the alias, username, or extension
• Cannot include consecutive numbers or characters

Similar rules exist for phone PINs:

• Cannot use any number more than two times consecutively
• Cannot include the user mailbox or extension, nor the reverse of them
• Must contain at least three different numbers (for example, 121212 is invalid)
• Cannot be the dial-by-name version of the user name (such as Mike = 6453)
• Cannot contain repeated digit patterns, nor any patterns that are dialed in a straight line on the phone keypad (for example, 2580 or 357)

Features Interacting with User Accounts

The following features use the end-user account login process, with either the username/password or PIN as the authentication:

• Unified CM Administration web pages
• User web pages (Self-Care Portal)
• Serviceability
• OS administration
• Disaster recovery system
• Cisco Extension Mobility
• Cisco Unified Communications Manager Assistant
• Directories
• IP phone services
• Data associated with user accounts

User account information is divided into three categories, with fields for specific data in each category:

1. Personal and Organizational Settings:

   • UserID
   • First, Middle, Last Name
   • Manager UserID
   • Department
   • Phone Number, Mail ID
2. Password Information: Password

3. CUCM Configuration Settings:

   • PIN
   • SIP Digest Credentials
   • User Groups and Roles
   • Associated PCs, controlled devices, and DNs
   • Application and feature parameters (Extension Mobility, Presence Group, CAPF)

Application user accounts use a subset of the previous attributes.

User Locale

User locales allow different languages to be displayed on the IP phone and the user web pages. Additional locales are installed on the CUCM server; then specific locale files are downloaded to the phone via TFTP. This allows for the customization of the primary interfaces for users in a wide range of available locales/languages.

Device Association

For users to be able to control their own devices (using the Self-Care Portal to up their own speed dials, services, and ring preferences, for example), the end-user account must be associated with the device. In CUCM, end users can be associated with IP phones, Cisco IP Communicator (CIPC), and Cisco Extension Mobility profiles.

Because the end-user account must have a unique user attribute name in the CUCM database, it is possible to dial a user by name. Cisco Unified Presence Server (CUPS) tracks the availability status of a user and his communication capabilities (such as voice, video, and chat).

Implementing End Users in CUCM

End users can be added to the CUCM database via three main methods:

• Manual, one-at-a-time entry
• Bulk import using the Bulk Administration Tool
• LDAP synchronization (and optional authentication)

This section reviews each of these methods.

Manual Entry

The CUCM database includes fields for comprehensive user information. Only some of these fields are required, including the following:

• User ID
• Last Name
• Presence Group (defaults to Shared Presence Group)
• Remote Destination Limit (defaults to 4)

Given that the last two required fields are populated by default, it is clear that CUCM does not require much information to create a new user. The user ID must be unique, which implies that you should have a naming convention that accommodates many users with similar names.

There are many optional fields on the End User Configuration page, including Password, PIN, First Name, Telephone Number, and Device Association. The more users you have, the more likely it is that these optional fields will be populated to implement features, improve searching and reporting, or improve security. Figure 9-8 shows part of the End User Configuration page.

Bulk Import Using BAT

Instead of adding potentially hundreds or thousands of users one at a time, the administrator can add users in bulk using the Bulk Administration Tool. BAT allows the administrator to create and upload a CSV file with all the users’ information populated and insert the data into the database in an automated way. BAT is a fast way to add, remove, or modify database entries for many fields in the CUCM database.

LDAP Integration

CUCM supports integration with Lightweight Directory Access Protocol (LDAP). LDAP is a standards-based system that allows an organization to create a single, centralized directory information store. LDAP holds information about user accounts, passwords, and user privileges. The information centralized in LDAP is available to other applications, so that separate directories do not need to be maintained for each application. Using LDAP simplifies user administration, and makes using systems slightly easier for users because they only need to maintain their information and passwords in one place.

CUCM supports LDAP integration with several widely used LDAP systems, including the following:

• Microsoft Active Directory 2000, 2003 and 2008 (support for AD 2012 only in CUCM 10.x and later)
• Microsoft Active Directory Application Mode 2003
• Microsoft Lightweight Directory Services 2008
• iPlanet Directory Server 5.1
• Sun ONE Directory Server (5.2, 6.x)
• Open LDAP (2.3.39, 2.4)

CUCM can interact with LDAP in two ways: LDAP Synchronization populates the CUCM database with user attributes from LDAP, and (as an optional additional configuration) LDAP authentication redirects password authentication to the LDAP system. Typically, synchronization and authentication are enabled together. In either case, some information that now comes from LDAP is no longer configurable in CUCM; the fields actually become read-only in CUCM, because the information can only be edited in LDAP. The following sections review LDAP synchronization and authentication in more detail.

LDAP Synchronization

Implementing LDAP synchronization (LDAP sync) means that some user data (but not all) for LDAP-sourced end user accounts is maintained in LDAP and replicated to the CUCM database. When LDAP sync is enabled, LDAP-sourced user accounts must be created and maintained in LDAP and cannot be created or deleted in CUCM; the user attributes that LDAP holds become read-only in CUCM. However, some user attributes are not held in LDAP and are still configured in CUCM because those attributes exist only in the CUCM database. As of CUCM v9.x, local CUCM user accounts can coexist with LDAP-sourced accounts; in this case, CUCM maintains read-write access to all the attributes of local accounts, but LDAP-sourced accounts still have attributes that are read-only in CUCM and which must be managed in the LDAP system.

It is important to understand that when using LDAP sync without LDAP authentication, the user passwords are still managed in the CUCM database. This means that, although a user account in LDAP is replicated to the CUCM database, the user password must be maintained separately in both the LDAP system and in CUCM.

CUCM uses the DirSync service to perform LDAP sync. The synchronization can be configured to run just once, on demand, or on a regular schedule. The choice depends on the system environment and the frequency of changes to LDAP content; the need for up-to-date information must be balanced against the load on the servers and network if the sync is frequent or takes place during busy times.

LDAP Authentication

LDAP authentication redirects password authentication requests from CUCM to the LDAP system. End-user account passwords are maintained in the LDAP system and are not configured, stored, or replicated to CUCM. Because one of the benefits (particularly to the end user) of LDAP is a centralized password system (making single sign-on possible), it is typical and desirable to implement LDAP authentication with LDAP sync.

LDAP Integration Considerations

A common misconception regarding CUCM LDAP integration is that all user data resides in LDAP. This is absolutely false. With LDAP sync, certain LDAP user attributes are held in the LDAP directory and are replicated to the CUCM database as read-only attributes. The balance of the user attributes in the CUCM database (fields such as associated devices, PINs, Extension Mobility profile, and so on) are still held and managed only in the CUCM database.

There is a similar misconception with LDAP authentication: Remember that the LDAP password is not replicated to the CUCM database; rather, the authentication process is redirected to the LDAP system. When an LDAP authentication-enabled user logs in to CUCM, the username and password are sent to the LDAP system (the password in sent as an MD5 hash). The LDAP system compares the submitted hash with its own hash of the correct password, and if they match, then the LDAP system indicates to the CUCM that the user is successfully authenticated (and, obviously, if the hashes do not match, the authentication fails).

The interaction of CUCM with LDAP varies with the type of LDAP implementation. The primary concern is how much data is replicated with each synchronization event. For example, Microsoft Active Directory performs a full sync of all records contained in the configuration every time; this can mean a very large amount of data is being synchronized, potentially causing network congestion and server performance issues. For this reason, sync intervals and scheduling should be carefully considered to minimize the performance impact.

Synchronization with all other supported LDAP systems is incremental (for example, only the new or changed information is replicated), which typically greatly reduces the amount of data being replicated, thereby reducing the impact on the network and servers.

LDAP Attribute Mapping

The user attribute field names that LDAP uses are most likely different from the equivalent attribute field names in the CUCM database. Therefore, the various LDAP attributes must be mapped to the appropriate CUCM database attribute. Creating an LDAP sync agreement involves identifying the one LDAP user attribute that will map to the CUCM user ID attribute. In a Microsoft Active Directory integration, for example, the LDAP attribute that will become the CUCM user ID can be any one of the following:

• sAMAccountName
• uid
• mail
• TelephoneNumber

It does not matter which one is chosen, but for consistency and ease of use, the attribute that the users are already using to log in to other applications should be used.

After the initial user ID mapping is selected, some other LDAP attributes should be manually mapped to CUCM database fields. Table 9-3 lists the fields in the CUCM database that map to the possible equivalent attribute in each type of supported LDAP database.

Table 9-3 LDAP User Attribute Mapping

CUCM	Microsoft AD	Other Supported LDAP
User ID	sAMAccountName	uld
	mail	mail
	employeeNumber	employeeNumber
	telephoneNumber	telephonePhone
	UserPrincipalName
First Name	givenName	Givenname
Middle Name	middleName	initials
	Initials
Last Name	sn	sn
Manager ID	manager	manager
Department	department	department
Phone Number	telephoneNumber	telephonenumber
	ipPhone
Mail ID	mail	mail
	sAMAccountName	uld

LDAP Sync Requirements and Behavior

Keep these points in mind when planning and implementing an LDAP sync:

• The data in the LDAP attribute that is mapped to the CUCM User ID field must be unique in the LDAP (and therefore CUCM) database. Some LDAP fields allow duplicate entries, but the CUCM user ID must be unique, so it is necessary to verify that the LDAP data is unique before the sync agreement is built.
• The sn attribute (surname/last name) in LDAP must be populated with data; otherwise, the record will not be replicated to CUCM.
• If the LDAP attribute that maps to the CUCM user ID attribute contains the same data as an existing application user in CUCM, that entry is skipped and not imported into the CUCM database.

LDAP Sync Agreements

An LDAP sync agreement defines what part of the LDAP directory will be searched for user accounts. Many LDAP systems have a highly organized structure, with different containers for different functions, departments, locations, or privileges. The synchronization agreement specifies at which point in the tree the search for user accounts will begin. CUCM has access to the container specified in the agreement, and all levels below that in the tree; it cannot search higher up the tree than the start point, nor can it search across to other branches in the tree that must be accessed by going higher than the starting point then back down.

The agreement can specify the root of the domain, but although this is a simple agreement to create, it causes the entire LDAP structure to be searched, which may return unwanted accounts or simply too many accounts.

CUCM can integrate with only one LDAP system, but within that system version 10.x can support up to 20 synchronization agreements. The total number of LDAP-sourced user accounts should not exceed 160,000. To be more precise

• If the number of users is less than 80,000, up to 20 sync agreements are possible.
• If the number of users is greater than 80,000 (to the maximum recommended 160,000), the number of sync agreements supported is 10.

LDAP Sync Mechanism

The LDAP sync agreement specifies when to begin synchronizing and when to repeat the synchronization (a schedule). It is possible to have a synchronization run only once, although this is somewhat unusual.

LDAP Custom Filters

The default behavior of LDAP sync is to import all user accounts from the start point in the tree on down. This may cause accounts to be imported that are not wanted. Using a custom filter allows an administrator to limit which accounts are imported; for example, a filter could specify that only user accounts in a particular organizational unit (OU) are imported. If the filter is changed, a full LDAP sync must be performed for the change to take effect.

Configure LDAP Sync

Setting up LDAP sync is surprisingly simple. The main difficulty is typically gaining a full understanding of the target LDAP structure, knowing what containers hold the users to be imported, and knowing where to start the LDAP search.

The basics steps to set up LDAP sync are as follows:

• Step 1. Activate the Cisco DirSync service.
• Step 2. Configure the LDAP system.
• Step 3. Configure the LDAP directory.
• Step 4. Configure LDAP custom filters.

For CUCM to be able to access and search LDAP, an account must be created in LDAP for CUCM. Configurations may vary between LDAP systems, but the account must essentially have read permissions on everything in the search base.

Activate DirSync

Using the Unified Serviceability application, navigate to Tools > Service Activation. From the Server drop-down list, choose the Publisher. Find the Cisco DirSync service, check the box next to it, and click Save.

Configure the LDAP System

Follow these steps to enable LDAP sync in CUCM:

• Step 1. Using the Unified CM Administration application, navigate to System > LDAP > LDAP System.
• Step 2. Check the Enable Synchronizing from LDAP Server box.
• Step 3. From the LDAP Server Type drop-down, choose the type of LDAP system with which CUCM will synchronize.
• Step 4. From the LDAP Attribute for User ID drop-down, select which LDAP attribute will map to the CUCM User ID attribute.
• Step 5. Click Save.

Figure 9-9 shows the LDAP System Configuration page.

Configure the LDAP Directory

To configure the LDAP directory, follow these steps:

• Step 1. Using the Unified CM Administration application, navigate to System > LDAP > LDAP Directory.
• Step 2. Specify a name for this LDAP Sync agreement in the LDAP Configuration Name field.
• Step 3. Add the account name and password that CUCM will use to access LDAP.
• Step 4. Define the User Search Base. This will be the full LDAP path syntax (for example, ou=Users,dc=Pod1,dc=com).
• Step 5. Set the synchronization schedule.
• Step 6. Specify the LDAP user fields to be synchronized (mapping CUCM fields to LDAP fields).
• Step 7. Specify at least one (up to three for redundancy) LDAP server IP address. Specify SSL to secure the LDAP sync process (requires similar configuration on the LDAP system).

Figure 9-10 shows the LDAP Directory configuration page.

Verify LDAP Sync

The simplest way to verify that LDAP sync is working is to do a quick search of the end users on the CUCM. In the column under LDAP Sync Status, the LDAP-sourced users’ status will be listed as Active LDAP Synchronized User. Users that are locally maintained in the CUCM database will be listed as Enabled Local User.

When you open the configuration page for an LDAP-synced user, you see that the User ID, Last Name, Middle Name, First Name, Telephone Number, Mail ID, Manager User ID, Department and a few other fields are not editable; this is because they are synced with LDAP and can only be edited in the LDAP system.

Configuring LDAP Authentication

Configuring CUCM to redirect authentication to the LDAP system is normally done as part of an LDAP integration. It is not typical to sync all the users but still make them maintain a separate password in CUCM.

To set up LDAP authentication, follow these steps:

• Step 1. Navigate to System > LDAP > LDAP Authentication.
• Step 2. Check the box next to Use LDAP Authentication for End Users.
• Step 3. Specify the account and password CUCM will use to access the LDAP system.
• Step 4. Specify the LDAP User Search Base.
• Step 5. Specify the LDAP server IP address (up to three for redundancy).
• Step 6. Click Save.

Verify LDAP Authentication

Verifying LDAP authentication can be achieved by opening a user configuration page and observing that the Password field is gone; this is because the password is maintained in LDAP, not locally in the CUCM database. A user can test the LDAP authentication by changing her password in LDAP and observing that CUCM requires the new password to log in.

Note that the user PIN is always locally maintained in the CUCM database, as are all the other CUCM-specific attributes.

Create LDAP Custom Filters

Create LDAP custom filters by navigating to System > LDAP > LDAP Custom Filter. Click Add New. In the Filter Configuration page, specify a name for the filter.

In the Filter field, type the filter statement. The statement must be in parentheses: ( ). Some sample filter statements follow; for more detail, see RFC 4515, LDAP: String Representation of Search Filters:

• (cn=Milton Macpherson)
• (!(cn=Milton Macpherson))
• (&(objectClass=Person)(|(sn=Macpherson)(cn=Milton M*)))
• (sn=M*)