-
Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 6.x
-
Preface
-
Introduction
-
Unified Communications Deployment Models
-
Network Infrastructure
-
Gateways
-
Cisco Unified CM Trunks
-
Media Resources
-
Music on Hold
-
Call Processing
-
Call Admission Control
-
Dial Plan
-
Emergency Services
-
Third-Party Voicemail Design
-
Cisco Unity
-
Cisco Unity Express
-
Cisco Unified MeetingPlace Integration
-
Cisco Unified MeetingPlace Express
-
IP Video Telephony
-
LDAP Directory Integration
-
Migrating to a Unified Communications System
-
Voice Security
-
Unified Communications Endpoints
-
Device Mobility
-
Cisco Unified Presence
-
Cisco Unified CM Applications
-
Cisco Mobility Applications
-
Network Management
-
Cisco Unified Communications Manager Business Edition
-
Recommended Hardware and Software Combinations
-
Glossary
-
Index
-
Table Of Contents
IP Phone Services Phone Support
Unified CM Services and IP Phone Service Enterprise Service Parameters
Unified CM Services for IP Phone Services
IP Phone Service Enterprise Service Parameters
IP Phone Services Architecture
Guidelines and Restrictions for IP Phone Services
Unified CM Services and EM Service Parameters
Guidelines and Restrictions for EM
EM Interactions: Unified CM Assistant, AC, and WebDialer
Unified CM Assistant Phone Support
Unified CM Services and Unified CM Assistant Service Parameters
Unified CM Services for Unified CM Assistant
Unified CM Assistant Service Parameters
Unified CM Assistant Functionality and Architecture
Unified CM Assistant Proxy Line Mode
Unified CM Assistant Share Lined Mode
Unified CM Assistant Architecture
Unified CM Assistant Dial Plan Considerations
Unified CM Assistant Console Installation
Unified CM Assistant Desktop Console QoS
Unified CM Assistant Console Directory Window
Unified CM Assistant Phone Console QoS
Unified CM Assistant Redundancy
Service and Component Redundancy
Device and Reachability Redundancy
Guidelines and Restrictions for Unified CM Assistant
Unified CM Assistant Performance and Capacity
Unified CM Assistant Interactions with EM
Unified CM Services and AC Service Parameters
AC and AC Device Authentication Application Users
AC Functionality and Architecture
Attendant Console Desktop Application
Attendant Console Installation
Attendant Console Directory Window
Service and Component Redundancy
Device and Reachability Redundancy
Guidelines and Restrictions for AC
Unified CM Services and WebDialer Service Parameters
Unified CM Services for WebDialer
WebDialer Functionality and Architecture
Service and Component Redundancy
Device and Reachability Redundancy
Guidelines and Restrictions for WebDialer
WebDialer Performance and Scalability
WebDialer Interactions with EM
Cisco Unified CM Applications
Last revised on: September 30, 2008
Cisco Unified Communications Manager (Unified CM) applications provide numerous operational and functional enhancements to basic IP telephony. External eXtensible Markup Language (XML) productivity applications or IP Phone Services can be run on the web server and/or client on most Cisco Unified IP Phones. For example, the IP phone on a user's desk can be used to get stock quotes, weather information, flight information, and other types of web-based information. In addition, custom IP phone service applications can be written that allow users to track inventory, bill customers for time, or control conference room environments (lights, video screen, temperature, and so forth). Unified CM also has a number of integrated applications that provide additional functionality, including:
•
Cisco Extension Mobility (EM)
The Extension Mobility feature enables mobile users to configure a Cisco Unified IP Phone as their own, on a temporary basis, by logging in to that phone.
•
Unified CM Assistant is a Unified CM integrated application that enables assistants to handle one or more managers' incoming phone calls.
•
The Attendant Console enables one or more receptionists to answer and transfer (or dispatch) calls within an organization.
•
WebDialer is a click-to-dial application for Unified CM that enables users to place calls easily from their PCs using any supported phone device.
In some cases these integrated applications also invoke IP Phone Services to provide additional functionality.
This chapter examines the following Unified CM applications:
What's New in This Chapter
Table 24-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.
IP Phone Services
Cisco Unified IP Phone Services are applications that utilize the web client and/or server and XML capabilities of the Cisco Unified IP Phone. The Cisco Unified IP Phone firmware contains a micro-browser that enables limited web browsing capability. These phone service applications provide the potential for value-added services and productivity enhancement by running directly on the user's desktop phone. For purposes of this chapter, the term phone service refers to an application that transmits and receives content to and from the Cisco Unified IP Phone.
IP Phone Services Phone Support
The following phones support IP Phone Services:
•
•
•
•
IP Phone Services can also run on the following IP phones, however these phone models support only text-based XML applications:
•
•
•
•
•
All of the IP Phones listed above can process a limited set of Cisco-defined XML objects for enabling the user interface (UI) between the phone and the web server that contains the running phone service.
Note that the phones listed above support phone services for both the Skinny Client Control Protocol (SCCP) and Session Initiation Protocol (SIP).
Unified CM Services and IP Phone Service Enterprise Service Parameters
To enable IP Phone Services, the system administrator must ensure that the Cisco Unified IP Phone Service network service is enabled under the Cisco Unified Serviceability interface. In addition, the administrator can use service parameters within Unified CM to customize and configure certain aspects of Unified CM and application behavior. There are a number of enterprise service parameters that provide configuration and customization options for IP Phone Services, as described in the following sections.
Unified CM Services for IP Phone Services
IP Phone Services rely on the Cisco CallManager Cisco IP Phone Services network service on Unified CM in order to function. This feature is installed and activated by default when Unified CM is installed on a server.
IP Phone Service Enterprise Service Parameters
There are a number of pertinent Enterprise Service Parameters that relate to IP Phone Services. The following items represent a partial list of configuration parameters under the Phone URL Parameters section of the Unified CM Enterprise Service Parameters configuration page that relate to IP Phone Services and XML operation of IP Phones:
•
This URL points to the authenticate.jsp service on Unified CM, which provides an authentication proxy service between Cisco Unified IP Phones and Unified CM. The URL is used to validate "push" requests made directly to the phone by the phone services. It is automatically configured at installation time. If no value is specified for this parameter, phone services will not be able to push content to the phone.
•
This URL points to the xmldirectory.jsp service on Unified CM, which generates and returns the directory menu presented when the user pushes the Directories (or book icon) button on the phone. The URL is automatically configured at installation time. If no value is specified for this parameter, the directory menu will not be available when the user pushes the Directories button.
•
This URL, if specified, points to a service that provides text or images to be displayed on the phone screen when the phone is idle. This parameter is closely coupled with the URL Idle Time parameter, which indicates how long the phone must be idle before initiating the service. By default this parameter is left blank (not configured) at installation time.
•
This parameter setting indicates the time in seconds that a phone will wait before initiating the URL Idle service. By default the parameter is set to 0 (zero) at installation time, indicating that the phone will never become idle.
•
This URL points to the GetTelecasterHelpText.jsp service on Unified CM, which generates and returns on-screen phone help for the phone keys and call statistics when the user presses the Help ("i" or "?") button (located to the right of the keypad). The URL is automatically configured at installation time. If no value is specified for this parameter, no help information will be displayed when the user pushes the Help button.
•
This URL points to the getservicesmenu.jsp service on Unified CM, which provides a list of user-subscribed phone services for the phone when the user presses the Services (or globe icon) button. It is automatically configured at installation time. If no value is specified for this parameter, a list of subscribed services will not be provided when the user pushes the Services button.
IP Phone Services Architecture
An IP Phone service can be initiated in several ways:
•
An IP Phone user presses the Services button, which sends an HTTP GET message to Unified CM for displaying a list of user-subscribed phone services. Figure 24-1 illustrates this functionality.
•
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 specified by the URL Idle parameter.
•
A phone service application can push content to the IP Phone by sending an HTTP POST message to the phone.
Note
Figure 24-1 shows a detailed illustration of the user-initiated IP Phone service operation. When a user presses the Services button, an HTTP GET message is sent from the IP Phone to the Unified CM getservicesmenu.jsp script by default (step 1). You can specify a different script by changing the URL Services parameter (see IP Phone Service Enterprise Service Parameters). The getservicesmenu.jsp script returns the list of phone service URL locations to which the individual user has subscribed (step 2). The HTTP response returns this list to the IP Phone (step 3). Any further phone service menu options chosen by the user continues the HTTP messaging between the user and the web server containing the selected phone service application (step 4).
Figure 24-1 User-Initiated IP Phone Service Architecture
Figure 24-2 shows examples of both phone-initiated and phone service-initiated push functionality. In the phone-initiated example, the phone automatically sends an HTTP GET to the location specified under the URL Idle parameter (see IP Phone Service Enterprise Service Parameters) when the URL Idle Time is reached. The HTTP GET is forwarded via Unified CM to the external web server. The web server sends back an HTTP Response, which is relayed by Unified CM back to the phone, and the phone displays the text and/or image on the screen.
In the phone service-initiated push example, the phone service on the external web server sends an HTTP POST with a Common Gateway Interface (CGI) or Execute call to the phone's web server. Before performing the CGI or Execute call, the phone authenticates the request using the proxy authentication service specified by the URL Authentication parameter (see IP Phone Service Enterprise Service Parameters). This proxy authentication service provides an interface between the phone and the Unified CM directory in order to validate requests made directly to the phone. If the request is authenticated, Unified CM forwards an HTTP Response to the phone. The phone's web server then performs the requested action, and the phone returns an HTTP response back to the external web server. If authentication fails, Unified CM forwards a negative HTTP Response, and the phone does not perform the requested CGI or Execute action but in turn forwards a negative HTTP Response to the external web server.
Figure 24-2 Phone-Initiated and Phone Service-Initiated IP Phone Service Architecture
IP Phone Services Redundancy
To ensure reliable services for phone users, you must maintain a high level of system availability, with a seamless transition to redundant systems during a system failure. While most of the back-end processing of a phone service occurs on a web server, the phones still depend upon Unified CM to redirect them to the phone service. And in the case of Extension Mobility and Unified CM Assistant phone services, the service actually runs on the Unified CM server(s).
Given the architecture of IP phone service functionality and the message flows shown in Figure 24-1 and Figure 24-2, there are two main failure scenarios to be considered:
Failure Scenario 1: Server with Cisco CallManager Cisco IP Phone Services Fails
Redundancy in this case depends upon some type of server load balancing (SLB), as illustrated in Figure 24-3 where a virtual IP address is used to point to one or more Unified CM servers. This virtual IP address is used when configuring the URL Services parameter. Thus a Unified CM server failure does not prevent the IP Phone Services subscription list from being returned to the phone when the phone's Services button is pushed. In addition, phone services such as Extension Mobility and Unified CM Assistant that run on a Unified CM server are also potentially made redundant via this method.
Figure 24-3 Method for Providing Redundancy for Phone Services
Failure Scenario 2: External Web Server Hosting a Particular IP Phone Service Fails
In this scenario, the connection to the Unified CM server is preserved, but the link fails to the web server hosting the user-subscribed phone service. This is an easier scenario to provision for redundancy because the IP Phone is still able to access the Unified CM server when the Services button is pressed. In this case, the IP Phone is similar to any other HTTP client accessing a web server. As a result, you can again use some type of SLB functionality (similar to the one indicated in Figure 24-3) to redirect the HTTP request from the phone to one or more redundant web servers hosting the user-subscribe phone service.
IP Phone Services Scalability
Cisco Unified IP Phone Services act, for the most part, as an HTTP client. In most cases it uses Unified CM only as a redirect server to the location of the subscribed service. Because Unified CM acts as a redirect server to the phone service, there is minimal performance impact on Unified CM when a user initiates a phone service request by pressing the Services key.
Note
Because the IP Phone is either an HTTP client or server, estimating the required bandwidth used by an IP Phone service is similar to estimating the bandwidth of an HTTP browser accessing the same text as HTTP content residing on a web hosting server.
Guidelines and Restrictions for IP Phone Services
With the exception of the integrated Extension Mobility and Unified CM Assistant applications' Phone Services, IP Phone services must reside on a separate web server. Running phone services other than Extension Mobility and Unified CM Assistant on the Unified CM server is not supported.
Extension Mobility (EM)
The Cisco Extension Mobility (EM) feature enables users to configure a Cisco Unified IP Phone as their own, on a temporary basis, by logging in to that phone. After a user logs in, the phone adopts the user's individual device profile information, including line numbers, speed dials, services links, and other user-specific properties of a phone. For example, when user X occupies a desk and logs in to the phone, that user's directory number(s), speed dials, and other properties appear on that phone; but when user Y uses the same desk at a different time, user Y's information appears. The EM feature dynamically configures a phone according to the authenticated user's device profile. The benefit of this application is that it allows users to be reached at their own extension on any phone within the Unified CM cluster, regardless of physical location, provided the phone supports EM.
EM Phone Support
The following Skinny Client Control Protocol (SCCP) phones support EM:
•
•
•
•
•
•
•
•
•
The following Session Initiation Protocol (SIP) phones support EM:
•
•
•
•
•
Note
Unified CM Services and EM Service Parameters
To enable the EM application, the system administrator must activate and start a number of Unified CM services from the Cisco Unified Serviceability interface. In addition, EM service parameters provide configuration and customization options for determining how the EM application behaves.
Unified CM Services for EM
The EM application relies on the Cisco Extension Mobility feature service, which you must activate manually from the Serviceability page.
EM also relies on the following network services, which are activated automatically on all Unified CM nodes during installation:
•
•
The Cisco Extension Mobility Application service provides an interface between the EM user phone and the Cisco Extension Mobility service. In addition, the Cisco Extension Mobility Application service subscribes to the change notification indications within the cluster and maintains a list of nodes in the cluster that have an active Cisco Extension Mobility service. By subscribing to change notification within the cluster, the Cisco Tomcat network service and the Cisco Extension Mobility feature service do not have to be restarted after changes are made to the EM service parameters.
The Cisco CallManager Cisco IP Phone Services service is needed to provide access to the EM phone service. The URL used to define the EM phone service is:
http://<Unified-CM_Server_IP-Address>/emapp/EMAppServlet?device=#DEVICENAME#
For example:
http://10.1.1.1/emapp/EMAppServlet?device=#DEVICENAME#
EM Service Parameters
The following items represent a partial list of Cisco EM Service Parameters related to Extension Mobility functionality:
•
This parameter indicates whether EM users will be logged out automatically when the Maximum Login Time is reached. By default the value is set to False, meaning EM users are not automatically logged out.
•
This parameter indicates the number of hours and/or minutes (hh:mm) an EM user can stay logged in before being logged out automatically. Automatic logout at the time specified occurs only if the Enforce Maximum Login Time parameter is set to True.
•
This parameter indicates whether an EM user is allowed to log in to more than one device at one time. By default multiple logins by a single user are not allowed, and attempts by a user to log in to another device while logged on to one device results in the following message:
Login Unsuccessful
[25]User logged in elsewhere.•
This parameter indicates whether the last userID used to log in to a device will be remembered during subsequent attempts to log in to that same device. If this value is set to True, the last logged-in userID information is stored in a table in the Unified CM database for efficient retrieval. Upon a subsequent login attempt, the UserID field in the login screen on phone is pre-populated with the stored userID value.
•
This parameter indicates whether the call logs specified for the Directories button menu are cleared at EM login and logout. This parameter affects the following logs: Missed Calls, Received Calls, and Placed Calls. If the value is set to True, then these logs are cleared during login and manual logout.
One exception is that these logs are not cleared when the user is logged out automatically. Therefore, logs are not cleared when the Maximum Login Time is reached (assuming Enforce Maximum Login Time is set to True) and the user is automatically logged out of the phone. Likewise, if a Unified CM Administrator clicks on the Log Out button under the Extension section of the phone/device configuration screen, the logs are not cleared.
•
This parameter indicates whether EM login and logout restrictions are enabled. If the value is set to false, login and logout restrictions do not take effect. If the value is set to true, the login and logout restrictions do take effect and EM will attempt to validate the IP address sending the login or the logout request.
•
This parameter takes effect only when Validate IP Address is set to true. This parameter is a text field of size 1024 characters that takes a string of IP addresses and host names separated by semicolons. EM will attempt to use this list as a source for EM login and logout IP Address validation checks.
•
This parameter takes effect only when Validate IP Address is set to true. This parameter indicates whether login and logout requests are allowed via proxy servers. If the value is set to false, EM will reject all login and logout requests coming via proxy servers. If the value is set to true, EM will attempt to validate the IP Address of proxy servers proxying EM login and logout requests.
•
This parameter takes effect only when Validate IP Address is set to true. This parameter is a text field to configure the size of the device cache that is maintained by EM. Setting this parameter to a higher value will increase the number of entries that can be stored in the EM device cache. Setting this parameter to a lower value will decrease the number of entries that can be stored.
For a complete list of Extension Mobility service parameters, consult the Cisco Extension Mobility chapter of the Cisco Unified Communications Manager Features and Services Guide, available at
http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html
EM Architecture
Figure 24-4 depicts the message flows and architecture of the EM application. When a phone user wants to access the EM application, the following sequence of events occurs:
1.
2.
Note
3.
4.
5.
6.
7.
8.
9.
Figure 24-4 EM Application Architecture and Message Flow
EM Redundancy
According to the EM architecture illustrated in Figure 24-4, reads and writes to the Unified CM database are required. Beginning with Unified CM 6.0, EM functionality is no longer dependent upon the publisher server because the required database writes can be done on subscriber nodes. If the publisher is unavailable, EM logins and logouts are still possible.
From a redundancy perspective, the following three component levels of redundancy must be considered for full EM resiliency:
•
As previously discussed, the Cisco CallManager Cisco IP Phone Services is required for providing the IP phone services menu to the phone. The menu of subscribed phone services is displayed when the user presses the services button on the phone. This is necessary so that the user can select the EM phone service. The node to which a phone points for the Cisco IP Phone service is determined by the URL Services parameter. Only a single service URL can be configured per phone. By default this parameter points to the publisher node.
•
The EM IP phone service is the service that is selected by the user from the IP phone services menu (or, alternatively, from a services line button) in order to log in or log out of a phone. This phone service points to the Cisco Extension Mobility Application service running on a particular Unified CM node. As indicated previously, the Cisco EM Application service provides the interface between the user (or phone) and the Cisco Extension Mobility service. The EM IP phone service can point to only a single IP address or host name.
•
The Cisco Extension Mobility service is required for EM login and logout. This service takes user credentials from the Cisco EM Application service and then writes to and reads from the local Unified CM database.
In order to provide redundancy for the Cisco CallManager Cisco IP Phone Services (or URL Services) and the EM phone service components, Cisco recommends using the Server Load Balancing (SLB) feature available in Cisco IOS to front-end multiple Unified CM nodes. The Cisco IOS SLB feature provides a virtual-IP-to-real-IP address mapping, as depicted in Figure 24-3, that front-ends the real IP addresses of the Unified CM nodes. The SLB feature can be configured to monitor the status of multiple nodes, automatically redirecting requests during failure events. By using the SLB virtual IP address (or DNS hostname) for the URL Services and EM IP phone service, you can ensure that both components are still available during any node failure and, therefore, EM login and logouts will continue.
As an alternative to Cisco IOS SLB, DNS can be used to provide redundancy for these components. To use DNS as a redundancy mechanism, a DNS A record should be configured for each Unified CM subscriber node with the same fully qualified domain name (FQDN) or host name so that a DNS query for the FQDN or host name will return IP addresses for multiple Unified CM subscriber nodes. Thus, a phone querying the DNS server for the FQDN or host name will receive multiple IP addresses. Given a node failure, these IP addresses can be contacted one at a time in turn until a responding node is found. The drawback to using DNS for EM redundancy is that a phone must wait for a timeout if a node has failed before attempting to contact the next IP address or node. This timeout can take anywhere from 30 to 45 seconds and will be repeated for each attempt to contact a failed node, therefore significant delay can occur during node failures before a response is received from a Unified CM node.
Finally, because the Cisco Extension Mobility Application service subscribes to cluster change notification, it maintains a list of all nodes in the cluster with the Cisco Extension Mobility service activated. Therefore, to provide redundancy for the Cisco Extension Mobility service component, this service should be run on multiple nodes within the cluster, and the Cisco Extension Mobility Application service will provide automatic failover to any nodes running the Cisco Extension Mobility service.
EM Security
Beginning with Cisco Unified CM release 6.1(2), the EM feature provides an optional level of security for EM login and logout requests by validating the source IP Address of the request. By default, EM will not perform this request validation; therefore, to enable EM security, the administrator must set the cluster-wide service parameter Validate IP Address to true. Once enabled, the EM service uses the following three sources (in the order listed) to validate the EM login and logout requests:
1.
During initialization, the EM service first queries the Unified CM database for all EM-enabled devices. It then queries the RIS Data Collector service to obtain an IP Address mapping for those devices that have registered with Unified CM. The number of device-to-IP-Address mappings contained in the cache is limited by the size of the cache specified in the EM Device Cache Size service parameter.
2.
This service parameter allows the administrator to provide a semicolon-separated list of trusted IP Addresses. This allows organizations to validate separate applications or proxy servers that perform login and logout requests on behalf of users.
3.
If no matches are present in the cache of trusted devices or in the trusted list of IPs service parameter, a specific query for the requesting device is made to the RIS DC service. This allows login and logout requests to be validated if the device registered after cache creation or if the cache is full.
Note
Whenever a login or a logout request is received by an EM service enabled for Validate IP Address, it will perform the IP Address validation by first attempting to locate the device-to-IP mapping in the cache of trusted devices. If the mapped IP address for that device matches the source IP address of the login or logout request, the request is performed. If the device is not found in the cache or if the IP Address does not match, the EM service checks the Trusted List of IPs service parameter. If the IP address of the source requesting the login or logout is located in this list, the request is performed. If the IP address is not validated here, the EM service then creates a new RIS DC query for the device making the request. If the response to this query contains the IP address of the source requesting the login or logout, EM performs the login and adds this device-to-IP mapping to the cache of trusted devices if the EM device cache size has not been exceeded. If the IP address is not validated during this step, an error will be displayed on the requesting device.
For organizations that implement a web proxy to handle EM login and logout HTTP requests, the Allow Proxy service parameter must be set to true. A proxy server, while forwarding the HTTP request, will set the via-field of the HTTP header with its hostname. If there are multiple proxy servers between the device and Unified CM, and if the request is forwarded by all the servers, then the via field in the HTTP header will have a comma-separated list of hostnames for each of the proxy servers in the forwarding path. The Allow Proxy service parameter, if set to true, allows EM logins and logouts received via a web proxy. In addition, if the proxied EM requests use the source IP address of the proxy server, this IP address must also be configured in the Trusted list of IPs service parameter.
Guidelines and Restrictions for EM
The following guidelines and restrictions apply with regard to the deployment and operation of EM within the Unified CM telephony environment:
•
EM is not currently supported between clusters. EM users of one Unified CM cluster can not log on to a phone in a second cluster unless a separate device profile and userID for that user has been created in the second cluster.
•
EM functionality relies on the use of the IP network for routing calls. Call routing via the PSTN is more problematic because E.164 PSTN numbers are static and the PSTN is unable to account for movement of EM user directory numbers (DNs) from their home sites. AAR relies on the PSTN for call routing, as does the VoPSTN deployment model. In both cases, EM user movement between locations and sites is supported only if all sites the user is traversing are in the same AAR group. For additional information, see Extension Mobility, page 10-34.
•
If Cisco Extension Mobility is stopped or restarted, the system does not auto-logout users who are already logged in after the expiration of the maximum login interval. These phones have to be logged out manually.
EM Performance and Capacity
The Cisco EM application supports the following cluster-wide login and logout capacities:
•
•
•
Note
Note
Cisco Extension Mobility login and logout functionality can be distributed across a pair of subscriber nodes to increase login/logout cluster capacity. To distribute the EM load evenly between the two subscriber nodes, the phones should be divided into two groups, with one group of phones subscribed to an EM phone service pointing to one of the subscriber nodes and the other group of phones subscribed to a second EM phone service that is pointing to a second subscriber node. When the EM load is distributed in this way, evenly between two MCS-7845 servers, the maximum cluster-wide capacity is 375 sequential logins and/or logouts per minute.
EM Interactions: Unified CM Assistant, AC, and WebDialer
EM can be used by both Unified CM Assistant Managers and Attendant Console users to log into their phones. For the details and guidelines governing the use EM with these other applications, see Unified CM Assistant Interactions with EM and AC Interactions with EM.
WebDialer users can also use EM to log on to their phones. See WebDialer Interactions with EM, for more information.
Unified CM Assistant
Cisco Unified Communications Manager Assistant (Unified CM Assistant) is a Unified CM integrated application that enables assistants to handle incoming calls on behalf of one or more managers. With the use of the Unified CM Assistant Console desktop application or the Unified CM Assistant Console phone service on the assistant phone, assistants can quickly determine a manager's status and determine what to do with a call. Assistants can manipulate calls using their phone's softkeys and service menus or via the PC interface with either keyboard shortcuts, drop-down menus, or by dragging and dropping calls to the managers' proxy lines.
Unified CM Assistant Phone Support
The following SCCP phones support Unified CM Assistant:
•
•
•
The following SIP phones support Unified CM Assistant:
•
•
•
Note
Unified CM Services and Unified CM Assistant Service Parameters
To enable the Unified CM Assistant application, the system administrator must activate and start several Unified CM feature services from the Cisco Unified Serviceability interface. In addition, Unified CM Assistant service parameters provide configuration and customization options for determining how the Unified CM Assistant application and services behave.
Unified CM Services for Unified CM Assistant
The Unified CM Assistant application relies on the following feature services, which must to be activated manually from the Serviceability page:
•
•
The Unified CM Assistant application also relies on the Cisco CallManager Cisco IP Phone Services network service, which is automatically activated on Unified CM during installation.
The Cisco IP Manager Assistant service provides an interface for the Unified CM Assistant Console and Manager Configuration applications as well as interacting with the Cisco CTIManager service and Unified CM database. The Cisco CTIManager service interfaces and interacts with the Cisco CallManager service and the Cisco IP Manager Assistant service for phone and call control.
The Cisco Unified IP Phone Services are needed to provide access to the Unified CM Assistant phone service from the manager and assistant phones. The URL used to define the Unified CM Assistant phone service is:
http://<Server_IP-Address>:8080/ma/servlet/MAService?cmd=doPhoneService&Name=#DEVICENAME#
(where <Server_IP-Address> is the IP address of any node in the cluster)
Note
Unified CM Assistant Service Parameters
The following items represent a partial list of Cisco IP Manager Assistant service parameters related to Unified CM Assistant functionality:
•
This parameter determines whether a secure Transport Layer Security (TLS) connection is used between the Cisco IP Manager Assistant service and the CTIManager. If enabled, a secure connection is configured using the Certificate Authority Proxy Function (CAPF) profile configured for the instance ID of the application user IPMASecureSysUser. The instance ID must be specified under the service parameter CAPF Profile Instance ID for Secure Connection to CTIManager.
Note
•
The CAPF Profile Instance ID is a unique string of numbers and/or letters used to identify the TLS connection or instance that is made between the Unified CM Assistant server and CTIManager for the IPMASecureSysUser application user. If the CTI Manager Connection Security Flag parameter is set to True, then this parameter must be configured with a value.
•
This parameter specifies the IP address of the primary CTIManager that the Cisco Unified CM Assistant server uses to process calls. A primary CTIManager can be configured on each Unified CM Assistant server.
•
This parameter specifies the IP address of the backup CTIManager that this Cisco Unified CM Assistant server uses to process calls when the primary CTIManager is down. A backup CTIManager can be configured on each Unified CM Assistant server.
•
This parameter specifies the IP address of the primary Cisco Unified CM Assistant server. This is a cluster-wide parameter and only two Unified CM Assistant servers, a primary and a backup, may be configured.
•
This parameter specifies the IP address of the backup Cisco Unified CM Assistant server. The backup server provides Unified CM Assistant functionality when the primary Unified CM Assistant server fails. This is a cluster-wide parameter.
•
This parameter specifies how often, in seconds, the IPMA server will send keep-alive messages (commonly referred to as heartbeats) to each Unified CM Assistant Console desktop application. The Unified CM Assistant Console desktop applications will initiate a failover to the backup IPMA server when they fail to receive a keep-alive message from the primary server before the specified time expires.
•
This parameter specifies the time, in seconds, that Unified CM Assistant Console desktop applications will wait to receive a response from the active or primary IPMA server.
•
When set to True, this parameter enables calls to an assistant's phone to be ring-no-answer (RNA) forwarded to the manager's next available assistant when the RNA value specified by the Cisco IPMA RNA Timeout parameter expires. If this parameter is set to False, then the call will ring the first assistant indefinitely or, if a voicemail profile is configured, the call will be forwarded to voicemail.
•
This parameter specifies the time, in seconds, that the Cisco Unified CM Assistant server waits before RNA forwarding an unanswered call to the next available assistant. RNA forwarding will occur only if the Cisco IPMA RNA Forward Calls parameter is set to True. If a voicemail profile is configured on the line and no other assistant is available, the call will be forwarded to voicemail when the timeout expires.
Advanced Service Parameters
The following service parameters are hidden by default and are available only when you click the Advanced button or icon:
•
When set to True, this parameter enables more than one Unified CM Assistant pair to be configured for increased Unified CM Assistant capacity.
•
This parameter specifies the IP address of the primary Cisco Unified CM Assistant server in Pool 2. This is a cluster-wide parameter and only two Unified CM Assistant servers, a primary and a backup, may be configured in this pool.
•
This parameter specifies the IP address of the backup Cisco Unified CM Assistant server in Pool 2. The backup server provides Unified CM Assistant service when the primary Unified CM Assistant server in Pool 2 fails. This is a cluster-wide parameter.
•
This parameter specifies the IP address of the primary Cisco Unified CM Assistant server in Pool 3. This is a cluster-wide parameter and only two Unified CM Assistant servers, a primary and a backup, may be configured in this pool.
•
This parameter specifies the IP address of the backup Cisco Unified CM Assistant server in Pool 3. The backup server provides Unified CM Assistant service when the primary Unified CM Assistant server in Pool 3 fails. This is a cluster-wide parameter.
For a complete list of Unified CM Assistant service parameters, refer to the Unified CM Assistant information in the Cisco Unified Communications Manager Features and Services Guide, available at
http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html
Unified CM Assistant Functionality and Architecture
The Unified CM Assistant application can operate in two modes: proxy line mode and shared line mode. The operation and functionality of each mode is different, and each has specific advantages and disadvantages. Both modes can be configured within a single cluster. However, mixing modes on the same assistant is not allowed. A single assistant providing support for one or more managers can support those managers in either shared line mode or proxy line mode.
Unified CM Assistant Proxy Line Mode
Figure 24-5 illustrates a simple call flow with Unified CM Assistant in proxy line mode. In this example, Phone A calls the Manager phone with directory number (DN) 60001 (step 1). The CTI/Unified CM Assistant Route Point (RP) intercepts this call based on a configured DN of 6XXXX. Next, based on the Manager DN, the call is redirected by the route point to the Manager's proxy line (DN: 39001) on the Assistant's phone (step 2). The Assistant can then answer or handle the call and, if appropriate, redirect the call to the Manager's phone (step 3). In the event of Unified CM Assistant application failure or if the Unified CM Assistant RP fails, a fall-through mechanism exists via the Call Forward No Answer (CFNA) 6XXXX configuration of the RP, so that calls to the Manager's DN will fall-through directly to the Manager's phone (step 4).
Figure 24-5 Unified CM Assistant Proxy Line Mode
Note
Unified CM Assistant Share Lined Mode
Figure 24-6 illustrates a simple call flow with Unified CM Assistant in shared line mode. In this example, Phone A calls the Manager phone with directory number (DN) 60001, which is a shared line on the Assistant phone (step 1). The call will ring at both the Assistant and Manager phones unless the Manager has invoked the Do Not Disturb (DND) feature, in which case the Assistant's phone will be the only phone that rings audibly (step 2).
Figure 24-6 Unified CM Assistant Shared Line Mode
In Unified CM Assistant shared line mode, the Unified CM Assistant RP is not needed or required for intercepting calls to the Manager phone. However, the Do Not Disturb (DND) feature on the Manager phone and the Unified CM Assistant Console desktop application still depend on the Cisco IP Manager Assistant and Cisco CTIManager services. Furthermore, in Unified CM Assistant shared line mode, features such as call filtering, call intercept, assistant selection, and Assistant Watch are not available.
Unified CM Assistant Architecture
The architecture of the Unified CM Assistant application is as important to understand as its functionality. Figure 24-7 depicts the message flows and architecture of Unified CM Assistant. When Unified CM Assistant has been configured for Unified CM Assistant Manager and Assistant users, the following sequence of interactions and events can occur:
1.
2.
3.
4.
5.
6.
The Unified CM Assistant phone service is controlled by the Cisco IP Manager Assistant service, and configuration changes made by the Manager using the phone are handled and propagated via the Cisco IP Manager Assistant service.
Note
Figure 24-7 Unified CM Assistant Architecture
Note
Unified CM Assistant Dial Plan Considerations
Dial plan configuration is extremely important for Unified CM Assistant configured in proxy line mode. To ensure that calls to Manager DNs are intercepted by the Unified CM Assistant RP and redirected to the Assistant phone, calling search spaces and partitions must be configured in such a way that Manager DNs are unreachable from all devices except the Unified CM Assistant RP and the Manager's proxy line on the Assistant phone.
Figure 24-8 shows an example of a proxy line mode Unified CM Assistant dial plan with the minimum requirements for calling search spaces, partitions, and the configuration of various types of devices within these dial plan components. Three partitions are required for proxy line mode, and for the example in Figure 24-8 they are as follows:
•
•
•
In addition, two calling search spaces are required, and for the example in Figure 24-8 they are as follows:
•
•
That is the extent of the dial plan for this example. However, it is also important to properly configure the various phone and Unified CM Assistant RP DNs or lines with the appropriate calling search spaces so that call routing works as required. In this case all user, Assistant primary (or personal), and Manager phone lines would be configured with the ASSISTANT_EVERYONE_CSS calling search space so that all of these lines can reach all the DNs in the Assistant_Everyone and Assistant_Route_Point partitions. Intercom lines and any other lines configured on devices within the telephony network would be configured with this same calling search space. All Manager proxy lines and all Assistant_RP lines are configured with the MANAGER_EVERYONE_CSS calling search space so that all of these lines can reach the Manager DNs in the Assistant_Manager partition as well as all the DNs belonging to the Assistant_Everyone partition. In this way, the dial plan ensures that only the Assistant_RP lines and the Manager proxy lines on the Assistant phones are capable of reaching the Manager phone DNs directly.
Figure 24-8 Unified CM Assistant Proxy Line Mode Dial Plan Example
The example in Figure 24-8 shows the minimum dial plan requirements for Unified CM Assistant in proxy line mode. However, most real-world telephony networks will have additional or existing dial plan requirements that must be integrated with the Unified CM Assistant calling search spaces and partitions. Figure 24-9 illustrates such an integration dial plan. In this example, the previously discussed dial plan must now handle two additional partitions and an additional calling search space. The On Cluster partition has been added in Figure 24-9, and it contains some additional phone DNs. The On Cluster partition has been added to both of the existing Unified CM Assistant calling search spaces (ASSISTANT_EVERYONE_CSS and MANAGER_EVERYONE_CSS) so that existing devices can reach these added DNs. The UNRESTRICTED_CSS calling search space has also been added to the existing dial plan. This calling search space is configured with the Assistant_Route_Point, Assistant_Everyone, and the recently added On Cluster partitions. In addition, a second new partition called PSTN has been added, and it contains a set of route patterns used for routing calls to the PSTN via the common route list (RL), route group (RG), and voice gateway mechanism. This PSTN partition is configured as part of the UNRESTRICTED_CSS calling search space.
Phone and device line calling search space configurations may be adjusted to incorporate the newly added partitions and calling search spaces, provided the Assistant_RP and Assistant phone Manager proxy lines remain assigned to the MANAGER_EVERYONE_CSS calling search space. In this example, the Manager phone line has been moved from the originally configured ASSISTANT_EVERYONE_CSS calling search space to the new UNRESTRICTED_CSS because it is likely that a Manager would be given unrestricted access to the PSTN.
Figure 24-9 Unified CM Assistant Proxy Line Mode Dial Plan Integration Example
As Figure 24-9 illustrates, integrating additional partitions and calling search spaces into a new or existing Unified CM Assistant dial plan is feasible, but care must be taken to ensure that the underlying proxy line mode mechanism remains intact.
For Unified CM Assistant shared line mode, no special dial plan provisioning is required. Manager and Assistant phones can be configured with calling search spaces and partitions like any other phones in the network because there are no Unified CM Assistant RPs or proxy lines to be concerned about. The only requirement with regard to shared line mode is that the Manager and Assistant DNs must be in the same partition so that shared line functionality is possible.
Unified CM Assistant Console
The Unified CM Assistant Console desktop application or the Unified CM Assistant Console phone service is required in order for assistants to handle calls on a manager's behalf. The desktop application provides assistants with a graphical interface for handling calls, while the phone service provides a menu-driven interface for handling calls. Both the desktop application and the IP phone service allow the assistant to configure the Manager phone and environment and monitor line status and availability. In addition, the desktop application provides other functions such as click-to-dial speed dialing and directory entries, which can also be performed on the assistant phone using the traditional softkey and menu approach.
Unified CM Assistant Console Installation
The Unified CM Assistant Console desktop application can be installed from the following URL:
https://<Server_IP-Address>:8443/ma/Install/IPMAConsoleInstall.jsp
(where <Server_IP-Address> is the IP address of any node in the cluster)
The Unified CM Assistant Console phone service does not require any installation. To enable the Assistant's phone as a console, subscribe the phone to the Unified CM Assistant phone service. (This is the same service to which Manager phones must also be subscribed.)
Unified CM Assistant Desktop Console QoS
After installation, and in order to handle calls on a Manager's behalf, the Assistant must log on to the application by providing userID and password (as configured in the End-user directory on Unified CM) and will have to toggle status to "online" by clicking the Go Online icon or menu item. Once the user is logged in and online, the desktop application communicates with the Unified CM Assistant server at TCP port 2912. The application chooses an ephemeral TCP port when sourcing traffic. Because the Unified CM Assistant server on Unified CM interfaces with the desktop application for call control (generation and handling of call flows), traffic sourced from Unified CM on TCP port 2912 is QoS-marked by Unified CM as Differentiated Services Code Point (DSCP) of 24 or Per Hop Behavior (PHB) of CS3. In this way, Unified CM Assistant phone control traffic can be queued throughout the network like all other call signaling traffic.
In order to ensure symmetrical marking and queuing, the Unified CM Assistant Console application traffic destined for Unified CM TCP port 2912 should also be marked as DSCP 24 (PHB CS3) to ensure this traffic is placed in the appropriate call signaling queues along the network path toward Unified CM and the Unified CM Assistant server. The Unified CM Assistant Console application marks all traffic as best-effort. This means that you will have to apply an access control list (ACL) at the switch port level (or somewhere along the network path, preferably as close to the console PC as possible) to remark traffic sent by the application PC destined for Unified CM on TCP port 2912 from DSCP 0 (PHB Best Effort) to DSCP 24 (PHB CS3).
Unified CM Assistant Console Directory Window
The directory window within the Assistant Console desktop application enables an assistant to search for end-users in the Unified CM Directory. Search strings entered into the Name field of the directory window are sent to the Unified CM Assistant server, and searches are generated directly against the Unified CM database. Responses to search queries are then sent back to the desktop application by the Unified CM Assistant server.
While the additional traffic generated by directory searches within the desktop application is nominal, this traffic can be problematic in centralized call processing deployments when one or more Unified CM Assistant console applications are running at remote sites. A directory search resulting in a single entry generates approximately one (1) kilobit of traffic from the Unified CM Assistant server to the desktop application. Fortunately, a maximum of 25 entries can be retrieved per search, meaning that a maximum of approximately 25 kilobits of traffic can be generated for each search made by the desktop application. However, if directory searches are made by multiple Unified CM Assistant Console desktop applications across low-speed WAN links from the Unified CM Assistant server, the potential for congestion, delay, and queuing is increased. In addition, directory retrieval traffic is sourced from Unified CM on TCP port 2912, like all other Unified CM Assistant traffic to the desktop. This means that directory retrieval traffic is also marked with DSCP 24 (PHB CS3) and therefore is queued like call signaling traffic. As a result, directory retrieval could potentially congest, overrun, or delay call control traffic.
Note
Given the potential for network congestion, Cisco recommends that administrators encourage Unified CM Assistant Console users to do the following:
•
•
These recommendations are especially important if either of the following conditions is true:
•
•
Unified CM Assistant Phone Console QoS
In order to handle calls on a Manager's behalf using the Unified CM Assistant Phone Console phone service, the Assistant must log on to the service by providing a userID and PIN (as configured in the End-user directory on Unified CM). Once the user is logged in, the phone console service communicates with Unified CM using HTTPS and SCCP. Call control traffic for Unified CM Assistant call generation and call handling is sent between the phone and Unified CM using SCCP. By default this traffic is marked as Differentiated Services Code Point (DSCP) of 24 or Per Hop Behavior (PHB) of CS3, thus ensuring it is queued throughout the network as call signaling traffic, therefore no additional QoS configuration or marking is required.
Unified CM Assistant Redundancy
Unified CM Assistant application redundancy can be provided at two levels:
•
At this level, redundancy must be considered with regard to Unified CM Assistant service or server redundancy and CTIManager service redundancy. Likewise, the lack of publisher redundancy and the impact of this component failing should also be considered.
•
At this level, redundancy should be considered as it relates to Assistant and Manager phones, the Unified CM Assistant route point, and the Unified CM Assistant Console desktop application and phone service, as well as redundancy in terms of Assistant and Manager reachability.
Service and Component Redundancy
As shown in Figure 24-7, Unified CM Assistant functionality is primarily dependent on the Cisco IP Manager Assistant service and the Cisco CTIManager service. In both cases, redundancy is automatically built-in using a primary and backup mechanism. Up to three pairs of active and backup Unified CM Assistant servers (nodes running the Cisco IP Manager service) can be defined, for a total of six Unified CM Assistant servers within a single cluster. Active and backup Unified CM Assistant server pairs are configured using the Cisco IPMA Server IP Address, Pool 2 Cisco IPMA Server IP Address, and Pool 3 Cisco IPMA Server IP Address service parameters (see Unified CM Assistant Service Parameters). With the configuration of these parameters, the required Cisco IP Manager service is made redundant. Given a failure of any of the primary Unified CM Assistant servers, the backup or standby Unified CM Assistant servers are able to handle Unified CM Assistant service requests. For each pair of Unified CM Assistant servers, only one Unified CM Assistant server can be active and handling request at a given time, while the other Unified CM Assistant server will be in a standby state and will not handle requests unless the active server fails.
In addition, two CTIManager servers or services can be defined for each Unified CM Assistant server using the CTIManager (Primary) IP Address and CTIManager (Backup) IP Address service parameters (see Unified CM Assistant Service Parameters). By configuring these parameters, you can make the CTIManager service redundant. Thus, given a failure of a primary CTIManager, CTIManager services can still be provided by the backup CTIManager. If all Cisco IP Manager Assistant and CTIManager services on cluster nodes fail, the Unified CM Assistant route point, Unified CM Assistant Console desktop application and phone service, and in turn the Unified CM Assistant application as a whole will fail. However as noted previously, given a failure of the Unified CM Assistant application, the CFNA fall-through mechanism will continue to work, allowing calls to a Manager to be routed directly to the Manager's phone.
Note
Figure 24-10 shows an example redundancy configuration for Unified CM Assistant and CTIManager primary and backup servers in a two-site deployment with clustering over the WAN. In order to provide maximum redundancy, a node at Site 1 is configured as the primary Unified CM Assistant server and a node at Site 2 is configured as the backup Unified CM Assistant server. In the event of a WAN failure, the backup Unified CM Assistant server at Site 2 will become a primary Unified CM Assistant server because the existing primary Unified CM Assistant server will be unreachable from Site
