Chapter 5. Deploying IP Phone Services in Cisco Unified Communications Manager

It used to be that a phone was a phone and a PC was a PC, and each was used for a different purpose. In today’s world, those distinctions have blurred and mostly gone away. Your PC can make calls using a softphone application, such as IP Communicator or Cisco Jabber, while some desktop phones can run interactive applications on the phone display. Other endpoints, such as the DX series, are based on the Android operating system to further enhance endpoint functionality.

This chapter discusses the implementation of IP phone services in the Cisco Unified Communications Manager (CUCM) environment.

Chapter Objectives

Upon completing this chapter, you will be able to meet the following objectives:

Describe general uses of IP phone services.

Describe IP phone service configuration.

Describe the IP phone service initiation process.

Describe how IP phone services are secured.

Describe IP phone services deployment options.

Overview of Cisco IP Phone Services

Using CUCM Administration, you define and maintain the list of IP phone services that can display on supported models of Cisco Unified IP Phones. IP phone services comprise XML applications or Cisco-signed Java MIDlets that enable the display of interactive content with text and graphics on some Cisco Unified IP Phone models. The Cisco Unified IP phone firmware contains a microbrowser that enables limited web-browsing capability. By running directly on the desktop phone of users, these phone-service applications provide the potential for value-added services and productivity enhancement.

The list of Cisco endpoints that support IP phone services is extensive and includes both Cisco Unified IP Phones and a variety of Cisco Telepresence endpoints. You can view a list of endpoints that support this feature by navigating to Cisco Unified Reporting and running the CUCM Phone Feature List report with the parameters of Product set to All and Feature set to IP Phone Services.

With the exception of the integrated CUCM Extension Mobility and CUCM Assistant application phone services, IP phone services must reside on a separate, off-cluster web server that is not a CUCM web server. Running phone services other than Extension Mobility and CUCM Assistant on the CUCM server node is not supported.

Cisco IP Phone Services Configuration

In Cisco Unified Communications Manager Administration, use the Device > Device Settings > Phone Services menu path to configure IP phone services.

Table 5-1 describes the IP phone service settings that display in the IP Phone Services Configuration window in Cisco Unified Communications Manager Administration.

After you configure the services, you can add services to the phones in the database by subscribing them to each appropriate service if the service is not classified as an enterprise subscription. You can assign the services to the Services, Directory, or Messages buttons/options, if the phone model supports these buttons/options.

Users can log in to Cisco Unified Communications Self Care Portal and subscribe to these services for their Cisco Unified IP Phones if these IP phone services are not classified as enterprise subscriptions.

Cisco IP Phone Services Functions

An IP phone service can be initiated by the end user or by the phone in several ways, as described in the following sections.

User-initiated (pull)

Phone-initiated (pull)

Phone service–initiated (push)

Cisco IP Phone Services Functions: User-Initiated

A user-initiated service occurs when an IP phone user presses the Services or Applications button, which sends a HTTP GET message to CUCM to display a list of user-subscribed phone services.

Figure 5-1 describes the steps between a user initiating a service and CUCM processing the request and fulfilling the delivery of the service application.

The steps in Figure 5-1 are as follows:

Step 1. When a user presses the Services or Applications button, an HTTP GET message is sent from the IP phone to the CUCM getservicesmenu.jsp script, if the Services Provisioning enterprise parameter is set to External URL or Both. You can specify a different script by changing the URL Services enterprise parameter.

Step 2. The getservicesmenu.jsp script returns the list of phone service URL locations to which the individual user has subscribed.

Step 3. The HTTP response returns this list to the IP phone.

Step 4. Any further phone service menu options chosen by the user continue the HTTP messaging between the user and the web server that contains the selected phone service application.

By default, the Services Provisioning enterprise parameter is set to Internal. With this setting, the IP phone obtains the list of phone services from its configuration file instead of sending an HTTP GET message to CUCM (IP Phone Services begins with Step 4). Some phones, like the Cisco Unified IP Phone 7960, do not have the ability to parse the list of phone services from their configuration file. IP phones that do not have this ability send an HTTP GET message to CUCM to get that list, even if the Service Provisioning enterprise parameter is set to Internal.

CUCM provides the ability to configure a secure IP phone Services URL using HTTPS. This ability was introduced in Release 8.0(1), in addition to a nonsecure URL. Phones that support HTTPS automatically use the secure URL. The following features support HTTPS:

Cisco Extension Mobility

Cisco Extension Mobility Cross Cluster (EMCC)

Cisco Unified Communications Manager Assistant

Cisco Unified IP Phone Services

Personal Directory

Change Credentials

Cisco IP Phone Services Functions: Phone-Initiated and Phone Service–Initiated

An idle time value can be set within the IP phone firmware, as indicated by the URL Idle Time parameter. When this timeout value is exceeded, the IP phone firmware itself initiates an HTTP GET to the idle URL location that is specified by the URL Idle parameter. This would be an example of a phone-initiated service. Additionally, a phone service application can push content to the IP phone by sending an HTTP POST message to the phone. An example of this would be a service that updates the stock value of the company’s shares, which might be of interest to staff members who hold company shares or are compensated in part through a stock option program.

Figure 5-2 details the process of phone or phone service–initiated phone services.

The upper half of Figure 5-2 shows the communication for phone-initiated service, which proceeds with the following steps:

Step 1. The phone automatically sends an HTTP GET message to the location that is specified in the URL Idle enterprise parameter when the URL Idle Time enterprise parameter is reached.

Step 2. The HTTP GET message is forwarded via CUCM to the external web server.

Step 3. The web server sends back an HTTP response containing the content to display.

Step 4. CUCM relays this content to the phone, and the phone displays the text or image on the screen.

The bottom half of Figure 5-2 shows the communications for phone service–initiated applications using the following steps:

Step 1. The phone service on the external web server sends an HTTP POST message with a CGI or Execute call to the phone’s web server.

Step 2. Before performing the CGI or Execute call, the phone authenticates the request using the proxy authentication service that is specified by the URL Authentication enterprise parameter. This proxy authentication service provides an interface between the phone and the CUCM directory to validate requests that are made directly to the phone.

Step 3. If the request is authenticated, CUCM forwards an HTTP response to the phone. The phone’s web server then performs the requested action.

Step 4. The phone returns an HTTP response back to the external web server.

Step 5. If authentication fails, CUCM forwards a negative HTTP response, and the phone does not perform the requested CGI or Execute action but instead forwards a negative HTTP response to the external web server.

Securing Cisco IP Phone Services

This section explains the Security by Default (SBD) feature and how it applies to secure Cisco IP phone services.

SBD provides these three functions for supported IP phones:

Default authentication of TFTP downloaded files (configuration, locale, ring list) that use a signing key

Optional encryption of TFTP configuration files that use a signing key

Certificate verification for phone-initiated Secure HTTP (HTTPS) connections that use a remote certificate trust store on CUCM called the Trust Verification Service (TVS)

The first two bullets refer to the process of securing the communication between the Cisco IP phone and the TFTP server containing the configuration files. The third bullet applies to any communication between the phone and an HTTPS server where the phone does not have the server’s certificate in the Identity Trust List (ITL) file.

The ITL file contains a record for each certificate, and is generated automatically and downloaded by phones at boot or reset. An ITL file is comparable to Certificate Trust List (CTL) file and is downloaded when a Cisco Unified IP Phone first registers with the cluster. In other words, an ITL is a leaner CTL file that is available for Cisco Unified IP Phones to offer initial level of trust with the cluster and consequent protection of signaling and media traffic with CUCM and other IP phones respectively.

If the IP phone service is defined as an HTTPS link, the phone must validate the certificate of the external server. Since the phone’s resources are limited, it does not store all possible certificates locally. Instead it uses the ITL certificate of the TVS server to create a secure connection to the TVS service and forward the certificate query to TVS.

TVS is a service that runs on all call processing CUCM servers and acts as a central certificate repository. TVS has access to a broader range of server certificates and can process authentication requests that are received from IP phones when the IP phones don’t have the certificate locally.

Figure 5-3 shows the authentication procedure for an IP phone that is connecting to a secure application server.

These steps take place whenever an SBD-enabled IP phone connects to a secure application server:

Step 1. The IP phone connects to the secure application server and requests secure communication.

Step 2. To encrypt the communication, the application server sends its certificate to the IP phone.

Step 3. The IP phone establishes a Transport Layer Security (TLS) encrypted connection to its configured TVS server. The TVS server sends its certificate to the IP phone the IP phone authenticates the TVS server certificate based on the ITL file of the IP phone.

Step 4. The IP phone forwards the certificate that was received by the secure application server to the TVS over the encrypted connection that was established in step 3.

Step 5. The TVS validates the received certificate based on existing certificates that are stored in the TVS certificate repository.

Step 6. The TVS returns the validation result to the IP phone. If the validation was successful, the IP phone can establish a secure connection with the application server.

Cisco IP Phone Services Deployment Options

This section describes the deployment options that are available for the Cisco IP phone services feature.

In high-availability deployments of Cisco IP phone services, two options are available to provide redundancy:

Cisco server load balancing (SLB): HTTP requests from IP phones are directed to a virtual IP address that is configured on a Cisco server load balancer. The requests are then forwarded to the real IP addresses of the web servers that host the Cisco IP phone Services.

Using Domain Name System (DNS) as a redundancy mechanism: The URLs for Cisco IP phone services that are configured on Cisco Unified Communications Manager use hostnames instead of IP addresses. The DNS server that is responsible for hostname resolution is configured to return multiple IP addresses for a given hostname. This redundancy method requires DNS support on the IP phones.

Figure 5-4 illustrates using SLB to provide redundancy.

Cisco does not recommend a redundancy design using DNS A or SRV records with multiple IP listings. With multiple IP addresses returned to a DNS request, the phones must wait for a timeout period before trying the next IP address in the list, and in most cases this results in unacceptable delays to the end user.

Chapter Summary

The following list summarizes the key points that were discussed in this chapter:

IP phone services can be configured in CUCM and be made available to display on IP phones.

IP phone services list can be acquired by a phone from its configuration file or by sending an HTTP Get request to CUCM.

IP phone services can be user initiated, phone initiated or phone service–initiated.

IP phone service access can be secured and can use SBD to verify server certificates.

SLB (server load balancing) should be used when deploying high-availability IP phone services.

Review Questions

Use the questions here to review what you learned in this chapter. The correct answers are found in Appendix A, “Answers to the Review Questions.”

1. Which statement best describes IP phone services?

a. Services that are automatically activated but can be stopped, started, and restarted through Control Center—IP phone services.

b. Applications that provide interactive or non-interactive display of text and/or graphics on a Cisco Unified IP Phone.

c. Services that enable video, pc port, and web services on a Cisco Unified IP Phone.

d. Applications that deliver feature services such as call park and call pickup.

2. In which three ways can IP phone services be initiated? (Choose three.)

a. User-initiated

b. Serviceability -> control center—IP Phone Services

c. Phone-initiated

d. Phone service–initiated

e. TFTP push initiated

f. TFTP pull initiated

3. IP phone services support which two of the following protocols? (Choose two.)

a. HTTPS

b. ICMP

c. DCOM

d. HTTP

e. RSVP

4. Which IP phone service method sends an HTTP Post message?

a. User-initiated

b. Phone-initiated

c. Phone service–initiated

d. TFTP pull initiated

5. Phones acquire the list of services to display to the user through which two mechanisms? (Choose two.)

a. From its configuration file

b. From the softkey template

c. From the Service List template

d. From the CUCM via an HTTP Get request

e. From the User Subscription List assigned to the phone’s device pool

6. Which three features are provided by deploying Security By Default? (Choose three.)

a. Secure Realtime Transport Protocol (SRTP)

b. Encrypted TFTP configuration files

c. Encrypted video streams

d. Authenticated TFTP configuration files

e. Secure DHCP

f. Certificate verification for HTTPS-based IP phone services

7. What is ITL?

a. Internal Trust List

b. Internal Trust Location

c. Identity Template Location

d. Identity Trust List

8. What does the ITL contain?

a. Cluster server certificates

b. Default gateway certificate

c. CTL files

d. IP phone services certificates

9. How often does the IP phone receive an ITL file?

a. When it autoregisters.

b. When a user selects an IP phone service.

c. When it goes through the boot process.

d. When it upgrades to new firmware version.

10. What is the recommended option for IP phone service redundancy?

a. TFTP Service Load Balancing

b. Server Load Balancing

c. DNS SRV records

d. Dual mode service provisioning