Cisco Unified Presence

Last revised on: September 30, 2008

Cisco Unified Presence consists of many components that enhance the value of a Cisco Unified Communications system. The main presence component is the Cisco Unified Presence server, which collects information regarding a user's availability status and communications capabilities. The user's availability status indicates whether or not the user is actively using a particular communications device such as a phone. The user's communications capabilities indicate the types of communications that user is capable of using, such as video conferencing, web collaboration, or basic audio.

The aggregated user information captured by the Cisco Unified Presence server enables Cisco Unified Personal Communicator and Cisco Unified Communications Manager applications to increase user productivity. These applications help connect colleagues more efficiently by determining the most effective form of communication.

This chapter explains the basic concepts of Presence within the Cisco Unified Communications System and provides guidelines for how best to deploy the various presence components. This chapter covers the following topics:

Presence

Presence refers to the ability and willingness of a user to communicate across a set of devices. It involves the following phases or activities:

•Publish user status

User status changes can be published automatically by recognizing user keyboard activity, phone use, or device connectivity to the network.

•Collect this status

The published information is gathered from all the available sources, privacy policies are applied, and then current status is aggregated, synchronized, and stored for consumption.

•Consume the information

Desktop applications, calendar applications, and devices can use the user status information to provide real-time updates for the end users to make better communication decisions.

Status combines the capabilities of what the device or user can do (voice, video, web collaboration, and so forth) and the attributes showing the state of the device or user (available, busy, on a call, and so forth). Presence status can be derived from automatic events such as computer login and telephone off-hook, or it can be derived from explicit notification events for changing status such as the user selecting Do Not Disturb from a change-status pick list.

Terminology surrounding presence refers to a watcher, presence entity (presentity), and presence server. The presence entity publishes its current status via a PUBLISH or REGISTER message to the presence server, and it can be a directory number (DN) or a SIP uniform resource identifier (URI) that resides within or outside the communications cluster. A watcher (device or user) requests presence status about a presence entity by sending a SUBSCRIBE message to the presence server. The presence server responds to the watcher with a NOTIFY message containing the current status of the presence entity.

The reason for using SIP with presence is that it unifies all major communications services such as voice, video, web, email, presence, and instant messaging on a single infrastructure. SIP is an extensible protocol and allows for additional packages, such as presence events, to be utilized on an existing SIP network that already routes specified requests and responses to the appropriate locations. By aligning these services, SIP allows for tighter integration and reduces management complexity in delivering these combined communication services.

Cisco Unified Presence User

For presence, typically a user is described in terms of the user's presence status, the number of users on the system, or the user's presence capabilities.

As defined by Cisco Unified Presence, a user is specified in Cisco Unified CM 5.x as an end user and must be configured with a primary extension. (The Primary Extension End User configuration was introduced in Unified CM 5.0.) The user is effectively tied to a directory number, and the presence status is reflected for the user's primary extension rather than for the device to which the user is associated. (See Figure 23-2.)

A user is specified in Unified CM 6.x as an end user and can be configured with a primary extension or associated with a line appearance. (The Line Appearance End User configuration is new with Unified CM 6.0.) With the line appearance, the user is effectively tied to a line appearance (directory number associated with a particular device), which allows for a more detailed level of granularity for aggregation of presence information. The user can be mapped to multiple line appearances, and each line appearance can have multiple users (up to 5). Cisco recommends associating the end user with a line appearance when using Cisco Unified CM 6.x. (See Figure 23-2.)

Figure 23-2 Associating an End User with a Primary Extension or Line Appearance

The concept of a presence user appears throughout this chapter; therefore, keep in mind the meaning of a user as defined for Cisco Unified Presence.

Unified CM Presence

All presence requests for users, whether inside or outside the cluster, are processed and handled by Cisco Unified CM Release 5.0(4) or higher.

A Unified CM watcher that sends a presence request will receive a direct response, including the presence status, if the watcher and presence entity are co-located within the Unified CM cluster.

If the presence entity exists outside the cluster, Unified CM will query the external presence entity through the SIP trunk. If the watcher has permission to monitor the external presence entity based on the SUBSCRIBE calling search space and presence group (both described in the section on Unified CM Presence Policy), the SIP trunk will forward the presence request to the external presence entity, await the presence response from the external presence entity, and return the current presence status to the watcher.

A watcher that is not in a Unified CM cluster can send a presence request to a SIP trunk. If Unified CM supports the presence entity, it will respond with the current presence status. If Unified CM does not support the presence entity, it will reject the presence request with a SIP error response.

Unified CM Presence with SIP

Unified CM uses the term SIP line to represent endpoints supporting SIP that are directly connected and registered to Unified CM and the term SIP trunk to represent trunks supporting SIP. SIP line-side endpoints acting as presence watchers can send a SIP SUBSCRIBE message to Unified CM requesting the presence status of the indicated presence entity.

If the presence entity resides within the Unified CM cluster, Unified CM responds to a SIP line-side presence request by sending a SIP NOTIFY message to the presence watcher, indicating the current status of the presence entity. (See Figure 23-3.)

Figure 23-3 SIP Line SUBSCRIBE/NOTIFY Exchange

If the presence entity resides outside the Unified CM cluster, Unified CM routes a SUBSCRIBE request out the appropriate SIP trunk, based on the SUBSCRIBE calling search space, presence group, and SIP route pattern. When Unified CM receives a SIP NOTIFY response on the trunk, indicating the presence entity status, it responds to the SIP line-side presence request by sending a SIP NOTIFY message to the presence watcher, indicating the current status of the presence entity. (See Figure 23-4.)

Figure 23-4 SIP Trunk SUBSCRIBE/NOTIFY Exchange

SUBSCRIBE messages for any directory number or SIP URI residing outside the Unified CM cluster are sent or received on a SIP trunk in Unified CM. The SIP trunk could be an interface to another Unified CM or it could be an interface to the Cisco Unified Presence server.

If the presence entity resides within the Unified CM cluster, Unified CM responds to the SCCP line-side presence request by sending SCCP messages to the presence watcher, indicating the current status of the presence entity.

If the presence entity resides outside the Unified CM cluster, Unified CM routes a SUBSCRIBE request out the appropriate SIP trunk, based on the SUBSCRIBE calling search space, presence group, and SIP route pattern. When Unified CM receives a SIP NOTIFY response on the trunk, indicating the presence entity status, it responds to the SCCP line-side presence request by sending SCCP messages to the presence watcher, indicating the current status of the presence entity.

Unified CM Speed Dial Presence

Unified CM supports the ability for a speed dial to have presence capabilities via a busy lamp field (BLF) speed dial. BLF speed dials work as both a speed dial and a presence indicator. However, only the system administrator can configure a BLF speed dial; a system user is not allowed to configure a BLF speed dial.

The administrator must configure the BLF speed dial with a target directory number that is resolvable to a directory number within the Unified CM cluster or a SIP trunk destination. BLF SIP line-side endpoints can also be configured with a SIP URI for the BLF speed dial, but SCCP line-side endpoints cannot be configured with a SIP URI for BLF speed dial. The BLF speed dial indication is a line-level indication and not a device-level indication.

The following Cisco Unified IP Phones support BLF speed dial for SCCP:

•Cisco Unified IP Phone 7914G

•Cisco Unified IP Phone 7921G

•Cisco Unified IP Phone 7940G

•Cisco Unified IP Phone 7960G

•Cisco Unified IP Phones 7941G, 7941G-GE, 7942G, and 7945G

•Cisco Unified IP Phones 7961G, 7961G-GE, 7962G, and 7965G

•Cisco Unified IP Phones 7970G, 7971G-GE, and 7975G

The following Cisco Unified IP Phones support BLF speed dial for SIP:

•Cisco Unified IP Phones 7941G, 7941G-GE, 7942G, and 7945G

•Cisco Unified IP Phones 7961G, 7961G-GE, 7962G, and 7965G

•Cisco Unified IP Phones 7970G, 7971G-GE, and 7975G

The Cisco Unified IP Phones 7905, 7906, 7911, and 7912 do not support BLF speed dial.

Figure 23-5 lists the various types of BLF speed dial indications from the phones.

Figure 23-5 Indicators for Speed Dial Presence

Unified CM Call History Presence

Unified CM supports presence capabilities for call history lists (the Directories button on the phone). Call history list presence capabilities are controlled via the BLF for Call Lists Enterprise Parameter within Unified CM Administration. The BLF for Call Lists Enterprise Parameter impacts all pages using the phone Directories button (Missed, Received, and Placed Calls, Personal Directory, or Corporate Directory), and it is set on a global basis.

Presence capabilities for call history lists are supported for both SCCP and SIP on the following Cisco Unified IP Phones:

•Cisco Unified IP Phones 7941G, 7941G-GE, 7942G, and 7945G

•Cisco Unified IP Phones 7961G, 7961G-GE, 7962G, and 7965G

•Cisco Unified IP Phones 7970G, 7971G-GE, and 7975G

The Cisco Unified IP Phones 7905G, 7906G, 7911G, 7912G, 7940G, and 7960G do not support presence capabilities for call history lists.

The presence indicators for call history lists are the same as those listed in the Icon column in Figure 23-5; however, no LED indications are available.

Unified CM Presence Policy

Unified CM provides the capability to set policy for users who request presence status. You can set this policy by configuring a calling search space specifically to route SIP SUBSCRIBE messages for presence status and by configuring presence groups with which users can be associated to specify rules for viewing the presence status of users associated with another group.

Unified CM Subscribe Calling Search Space

The first aspect of presence policy for Unified CM is the SUBSCRIBE calling search space. Unified CM uses the SUBSCRIBE calling search space to determine how to route presence requests (SUBSCRIBE messages with the Event field set to Presence) that come from the watcher, which could be a phone or a trunk. The SUBSCRIBE calling search space is associated with the watcher and lists the partitions that the watcher is allowed to "see." This mechanism provides an additional level of granularity for the presence SUBSCRIBE requests to be routed independently from the normal call-processing calling search space.

The SUBSCRIBE calling search space can be assigned on a device basis or on a user basis. The user setting applies for originating subscriptions when the user is logged in to the device via Extension Mobility or when the user is administratively assigned to the device.

With the SUBSCRIBE calling search space set to <None>, BLF speed dial and call history list presence status does not work and the subscription messages is rejected as "user unknown." When a valid SUBSCRIBE calling search space is specified, the indicators work and the SUBSCRIBE messages are accepted and routed properly.

Note Cisco strongly recommends that you do not leave any calling search space defined as <None>. Leaving a calling search space set to <None> can introduce presence status or dialing plan behavior that is difficult to predict.

Unified CM Presence Groups

The second aspect of the presence policy for Unified CM is presence groups. Devices, directory numbers, and users can be assigned to a presence group, and by default all users are assigned to the Standard Presence Group. A presence group controls the destinations that a watcher can monitor, based on the user's association with their defined presence group (for example, Contractors watching Executives is disallowed, but Executives watching Contractors is allowed). The presence group user setting applies for originating subscriptions when the user is logged in to the device via Extension Mobility or when the user is administratively assigned to the device.

When multiple presence groups are defined, the Inter-Presence Group Subscribe Policy service parameter is used. If one group has a relationship to another group via the Use System Default setting rather than being allowed or disallowed, this service parameter's value will take effect. If the Inter-Presence Group Subscribe Policy service parameter is set to Disallowed, Unified CM will block the request even if the SUBSCRIBE calling search space allows it. The Inter-Presence Group Subscribe Policy service parameter applies only for presence status with call history lists and is not used for BLF speed dials.

Presence groups can list all associated directory numbers, users, and devices if you enable dependency records. Dependency records allow the administrator to find specific information about group-level settings. However, use caution when enabling the Dependency Record Enterprise parameter because it could lead to high CPU usage.

Unified CM Presence Guidelines

Unified CM enables the system administrator to configure and control user presence capabilities from within Unified CM Administration. Observe the following guidelines when configuring presence within Unified CM:

•Select the appropriate model of Cisco Unified IP Phones that have the ability to display user presence status.

•Define a presence policy for presence users.

–Use SUBSCRIBE calling search spaces to control the routing of a watcher presence-based SIP SUBSCRIBE message to the correct destinations.

–Use presence groups to define sets of similar users and to define whether presence status updates of other user groups are allowed or disallowed.

•Call history list presence capabilities are enabled on a global basis; however, user status can be secured by using a presence policy.

•BLF speed dials are administratively controlled and are not impacted by the presence policy configuration.

Cisco Unified Presence Server

The Cisco Unified Presence server uses standards-based SIP and SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) to provide a common demarcation point for integrating all SIP or SIMPLE applications into the Cisco Unified Communications System. The Cisco Unified Presence server collects, aggregates, and distributes user capabilities and attributes using this standards-based SIP and SIMPLE interface.

The core components of the Cisco Unified Presence server consist of the SIP Presence Engine, which collects information regarding a user's availability status and communications capabilities, and the SIP Proxy/Registrar for the routing of presence-related and general SIP messaging. Applications (either Cisco or third-party) can integrate presence and provide services that improve the end user experience and efficiency. By default, the Cisco Unified Presence server contains the IP Phone Messenger application to allow for instant messaging and presence status using Cisco Unified IP Phones. In addition, Cisco Unified Personal Communicator is a supported client of the Cisco Unified Presence server that also integrates instant messaging and presence status.

The Cisco Unified Presence server also contains support for interoperability with Microsoft Live Communications Server 2005 or Office Communications Server 2007 and the Microsoft Office Communicator client for any Cisco Unified IP Phone connected to a Unified CM. The Microsoft Office Communicator client interoperability includes click-to-dial functionality, phone control capability, and presence status of Cisco Unified IP Phones.

Cisco Unified Presence Server Cluster

The Cisco Unified Presence server uses the same underlying appliance model and hardware as used by Unified CM, including a similar administration interface. For details on the supported platforms, refer to the Cisco Unified Presence Server Administration Guide, available at

Cisco Unified Presence consists of two servers, a publisher and a subscriber, based on the same architecture as the Unified CM publisher and subscriber. However, the Cisco Unified Presence publisher server and subscriber server form their own cluster and are not formally integrated as part of the Unified CM cluster. The Cisco Unified Presence publisher utilizes and builds upon the database used by the Unified CM publisher by sharing the user and device information. A Cisco Unified Presence server cluster supports only a single Unified CM cluster; therefore, all users of Cisco Unified Presence must be defined within the same Unified CM cluster with Release 5.0(4) or higher.

Intracluster traffic participates at a very low level between Cisco Unified Presence and Unified CM and between the Cisco Unified Presence publisher and subscriber. Both clusters share a common hosts file and have a strong trust relationship using IPTables. At the level of the database and services, the clusters are separate and distinct, and each Cisco Unified Presence server and Unified CM cluster requires separate administration. There is currently no Transport Layer Security (TLS) or IPSec utilization for intracluster traffic.

The Cisco Unified Presence publisher communicates directly with the Unified CM publisher via the AVVID XML Layer Application Program Interface (AXL API) using the Simple Object Access Protocol (SOAP) interface. When first configured, the Cisco Unified Presence publisher performs an initial synchronization of the entire Unified CM user and device database. All Cisco Unified Presence users are configured in the Unified CM End User configuration. During the synchronization, Cisco Unified Presence populates these users in its database from the Unified CM database and does not provide end-user configuration from its administration interface.

The initial Cisco Unified Presence database synchronization from Unified CM might take a while, depending on the amount of information in the database as well as the load that is currently on the system. Subsequent database synchronizations from Unified CM to Cisco Unified Presence are performed in real time when any new user or device information is added to Unified CM. For planning purposes, use the values in Table 23-2 as guidelines when executing the initial database synchronization with Unified CM using a single Cisco Unified Presence publisher.

Table 23-2 Synchronization Times for a Cisco Unified Presence Publisher

Server Platform

Number of Users

Synchronization Time

Cisco MCS 7825

1,000

5 minutes

Cisco MCS 7835

1,000

5 minutes

10,000

25 minutes

Cisco MCS 7845

1,000

5 minutes

10,000

20 minutes

30,000

70 minutes

For planning purposes, use the values in Table 23-3 as guidelines when executing the initial database synchronization with Unified CM using a Cisco Unified Presence publisher and subscriber:

Table 23-3 Synchronization Times for a Cisco Unified Presence Publisher and Subscriber

Server Platform

Number of Users

Synchronization Time

Cisco MCS 7825

1,000

10 minutes

Cisco MCS 7835

1,000

10 minutes

10,000

50 minutes

Cisco MCS 7845

1,000

10 minutes

10,000

40 minutes

30,000

140 minutes

Note When the Cisco Unified Presence server is performing the initial database synchronization from Unified CM, do not perform any administrative activities on Unified CM while the synchronization agent is active.

If the database entries are not updating, you can check for broken connections with the synchronization agent by using the Real-Time Monitoring Tool (RTMT) to monitor the Critical Alarm Cisco Unified Presence ServerSyncAgentAXLConnectionFailed.

Cisco Unified Presence Server Redundancy

Unified CM provides a choice of the following optional redundancy configurations:

•Two to one (2:1) — For every two primary subscribers, there is one shared backup subscriber.

•One to one (1:1) — For every primary subscriber, there is a backup subscriber.

The Cisco Unified Presence cluster consists of the Cisco Unified Presence publisher and subscriber only, with no redundancy for either server. What this means is that, if one Cisco Unified Presence server fails, the users associated with that failed server will not automatically fail-over to the other Cisco Unified Presence server.

A Cisco Unified Presence server cluster has two servers primarily for load balancing, which allows for the processing power to be scaled beyond the capacity of a single server to support a larger number of users. A Cisco Unified Presence server cluster can initially be viewed as each server containing the same user information and services, but it currently does not allow for true redundancy.

Cisco Unified Presence Deployment Models

Unified CM provides a choice of the following deployment models:

•Single site

•Multisite WAN with centralized call processing

•Multisite WAN with distributed call processing

•Clustering over the WAN

Cisco Unified Presence is supported with the following Unified CM deployment models: single-site centralized call processing, multisite centralized call processing, and multisite distributed call processing. However, both the Cisco Unified Presence publisher and subscriber must be co-located with the Unified CM publisher. The Cisco Unified Presence cluster is not supported in Unified CM deployments with clustering over the WAN.

Cisco Unified Presence Server Performance

Cisco Unified Presence server clusters support publisher-only or publisher-and-subscriber configurations. However, if a subscriber is used, it must be on the same type of server platform as the publisher.

Table 23-4 lists the hardware platform requirements for the Cisco Unified Presence server as well as the maximum number of users supported per platform. (For example, if a Cisco Unified Presence publisher and subscriber are deployed on MCS 7845 platforms, a total of 10,000 users would be supported.)

There are two checkboxes, one for Unified Presence and one for Unified Personal Communicator. To enable the user to send and receive presence SIP messaging updates, the Unified Presence checkbox must be enabled for that user. If the user is not enabled for Unified Presence, no presence messaging or status updates will be allowed for that user. To enable the use of Cisco Unified Personal Communicator, the Unified Personal Communicator checkbox must be enabled for the user.

Each checkbox (Enable CUP and Enable CUPC) for the user will consume a Device License Unit. You can use the License Unit Calculator on Unified CM to view a report of the number of Device License Units consumed (that is, the number of users enabled for presence). For complete information regarding licensing on Unified CM, refer to the Cisco Unified Communications Manager Administration Guide, available at

Unified CM 6.x provides the ability to use adjunct licensing for a presence user who is using multiple devices. This feature allows the presence user, who is already using a Cisco Unified IP Phone, to require only a single Device License Unit (instead of three) when also using Cisco Unified Personal Communicator. The adjunct licensing is enabled via configuration on Unified CM, under the Primary Phone option for Cisco Unified Personal Communicator. When a primary phone is associated with Cisco Unified Personal Communicator, then the adjunct licensing is enabled and reflected in the License Unit Calculator.

Cisco Unified Presence Deployment

Cisco Unified Presence can be deployed in either of the following configurations:

Single-Cluster Deployment

Figure 23-6 represents the interfaces between Cisco Unified Presence components and the interactions between those components for basic functionality. For complete information on Cisco Unified Presence administration and configuration, refer to the Cisco Unified Presence installation, administration, and configuration guides, available at

1. The SIP connection between the Cisco Unified Presence server and Unified CM handles all the presence information exchange.

a. Unified CM configuration requires the Cisco Unified Presence publisher and subscriber to be added as application servers on Unified CM and also requires a SIP trunk pointing to the Cisco Unified Presence server. The address configured on the SIP trunk could be a Domain Name System (DNS) server (SRV) fully qualified domain name (FQDN) that resolves to the Cisco Unified Presence publisher and subscriber, or it could simply be an IP address of the Cisco Unified Presence publisher or subscriber.

b. Configuration of Cisco Unified Presence occurs through the Unified CM Presence Gateway for presence information exchange with Unified CM. The following information is configured:

Presence Gateway: server_fqdn:5070

Note The server_fqdn could be the FQDN of the Unified CM publisher, a DNS SRV FQDN that resolves to the Unified CM subscriber servers, or an IP address.

If DNS is highly available within your network and DNS SRV is an option, configure the SIP trunk on Unified CM with a DNS SRV FQDN of the Cisco Unified Presence publisher and subscriber. Also configure the Presence Gateway on the Cisco Unified Presence server with a DNS SRV FQDN of the Unified CM subscribers, equally weighted. This configuration will allow for presence messaging to be shared equally among all the servers used for presence information exchange.

If DNS is not highly available or not a viable option within your network, use IP addressing. When using an IP address, presence messaging traffic cannot be equally shared across multiple subscribers because it points to a single subscriber.

Unified CM 6.x provides the ability to further streamline communications and reduce bandwidth utilization by means of a new service parameter, CUP PUBLISH Trunk, which allows for the PUBLISH method (rather than SUBSCRIBE/NOTIFY) to be configured and used on the SIP trunk interface to Cisco Unified Presence.

2. The Computer Telephony Integration Quick Buffer Encoding (CTI-QBE) connection between Cisco Unified Presence and Unified CM handles all the CTI communication for users on the Cisco Unified Presence server to control phones on Unified CM. This CTI communication occurs when Cisco Unified Personal Communicator is using Desk Phone mode to do Click to Call or when Microsoft Office Communicator is doing Click to Call through Microsoft Live Communications Server 2005 or Office Communications Server 2007.

a. Unified CM configuration requires the user to be associated with a CTI Enabled Group, and the primary extension assigned to that user must be enabled for CTI control (checkbox on the Directory Number page). The CTI Manager Service must also be activated on each of the Unified CM subscribers used for communication with the Cisco Unified Presence publisher and subscriber. Integration with Microsoft Live Communications Server 2005 or Office Communications Server 2007 requires that you configure an Application User, with CTI Enabled Group and Role, on Unified CM.

b. Cisco Unified Presence CTI configuration (CTI Server and Profile) for use with Cisco Unified Personal Communicator is automatically created during the database synchronization with Unified CM. All Cisco Unified Personal Communicator CTI communication occurs directly with Unified CM and not through the Cisco Unified Presence server.

Cisco Unified Presence CTI configuration (CTI Gateway) for use with Microsoft Live Communications Server 2005 or Office Communications Server 2007 requires you to set the CTI Gateway address (Cisco Unified Communications Manager Address) and a provider, which is the application user configured previously in Unified CM. Up to eight Cisco Unified Communications Manager Addresses can be provisioned for increased scalability. Only IP addresses can be used for CTI gateway configuration in the Cisco Unified Presence server.

b. Cisco Unified Presence security configuration requires you to set a user and password for the Unified CM AXL account in the AXL configuration.

4. The LDAP interface is used for LDAP authentication of Cisco Unified Personal Communicator users during login. For more information regarding LDAP synchronization and authentication, see the chapter on LDAP Directory Integration, page 18-1.

Unified CM is responsible for all user entries via manual configuration or synchronization directly from LDAP, and Cisco Unified Presence then synchronizes all the user information from Unified CM. If a Cisco Unified Personal Communicator user logs into the Cisco Unified Presence server and LDAP authentication is enabled on Unified CM, Cisco Unified Presence will go directly to LDAP for the Cisco Unified Personal Communicator user authentication using the Bind operation. Once Cisco Unified Personal Communicator is authenticated, Cisco Unified Presence forwards the information to Cisco Unified Personal Communicator to continue login.

When using Microsoft Active Directory, consider the choice of parameters carefully. Performance of Cisco Unified Presence might be unacceptable when a large Active Directory implementation exists and the configuration uses a Domain Controller. To improve the response time of Active Directory, it might be necessary to promote the Domain Controller to a Global Catalog and configure the LDAP port as 3268.

Table 23-5 lists the ports used by the various protocol interfaces for Cisco Unified Presence.

Table 23-5 Cisco Unified Presence Port Usage

Protocol Interface

Port

CTI-QBE

2748

DB Change Notification

8001

DNS

53

DRF Master Agent Server

4040

HTTP

80

HTTPS

443 or 8443

ICMP

7

IPPM HTTP Listener

8081

LDAP

389 or 3268

LDAPS

636

NTP

123

Presence Engine Exchange Notification

50020

Presence Engine Livebus Messaging

50000

Presence Engine Management (oamagent)

60020

RISDC Client

2556

RISDC Server

2555

RISDC System Access (ServM)

8888 and 8889

SIMPLE

5070

SIP

5060

SNMP Agent

161, 6161, 7161, 7999, or 8161

SNMP Trap

162

SSH/SFTP

22

TLS (Peer Authentication)

5062

TLS (Server Authentication)

5061

Multi-Cluster Deployment

The deployment topology in previous sections is for a single Cisco Unified Presence cluster communicating with a single Unified CM cluster. Presence and instant messaging functionality is limited by having communications within a single cluster only. Therefore, to extend presence and instant messaging capability and functionality, these standalone clusters can be configured for peer relationships for communication between clusters within the same domain. Figure 23-7 represents the peer relationship between Cisco Unified Presence clusters when interconnecting multiple clusters or sites. This functionality provides the ability for users in one cluster to communicate and subscribe to the presence of users in a different cluster within the same domain.

Figure 23-7 Multi-Cluster Deployment of Cisco Unified Presence

To create a fully meshed presence topology, each Cisco Unified Presence cluster requires a separate peer relationship for each of the other Cisco Unified Presence clusters within the same domain. The address configured in this intercluster peer could be a DNS SRV FQDN that resolves to the remote Cisco Unified Presence cluster publisher and subscriber, or it could also simply be the IP address of the Cisco Unified Presence cluster publisher or subscriber.

The interface between each Cisco Unified Presence cluster is two-fold, an AXL/SOAP interface and a SIP interface. The AXL/SOAP interface handles the synchronization of user information for home cluster association, but it is not a full user synchronization. The SIP interface handles the subscription and notification traffic, and it rewrites the host portion of the SIP URI before forwarding, if the user is detected to be on a remote Cisco Unified Presence cluster within the same domain.

Presence and instant-messaging communication between different domains (often referred to as inter-domain federation) is not a supported deployment.

When Cisco Unified Presence is deployed in a multi-cluster environment, a presence user profile should be determined. The presence user profile helps determine the scale and performance of a multi-cluster presence deployment and the number of users that can be supported. The presence user profile helps establish the number of contacts (or buddies) a typical user has, as well as whether those contacts are mostly local cluster users or users of remote clusters.

The traffic generated between Cisco Unified Presence clusters is directly proportional to the characteristics of the presence user profile. For example, assume presence user profile A has 30 contacts with 20% of the users on a local Cisco Unified Presence cluster and 80% of the users on a remote Cisco Unified Presence cluster, while presence user profile B has 30 contacts with 50% of the users on a local Cisco Unified Presence cluster and 50% of the users on a remote Cisco Unified Presence cluster. In this case, presence user profile B will provide for slightly better network performance and less bandwidth utilization due to a smaller amount of remote cluster traffic.

Cisco Unified Presence Server Policy

Cisco Unified Presence server policy is set by the user and not the administrator. A default set of rules, with everything open and available, applies if the user does not make any modifications to the policy rules. All policy configuration control is provided in the User Options area of the Cisco Unified Presence user pages at https://<cup_server_address>/ccmuser/.

The user can configure rule sets that contain access control lists (ACLs) of watchers for which these rules apply. There are three types of rules in each rule set:

•Visibility Rules

–Polite Blocking — Watchers always see an unavailable presence status, with no device status for this user.

–Reachability Only — Watchers see only the overall reachability of the user, with no device detail information.

–All State (default) — Watchers see all unfiltered device state information in addition to the overall reachability.

The filtering rules are applied prior to determining reachability; therefore, a device's filtered status does not affect the reachability status of the user. The user may also define device types (for example, mobile phone, office phone, and so forth) for use with the reachability and filtering rules.

Cisco Unified Presence Calendar Integration

Cisco Unified Presence has the ability to retrieve calendar state and aggregate it into a presence status via the calendar module interface with Microsoft Exchange 2003 or 2007. Microsoft Exchange makes the calendar data available from the server via Outlook Web Access (OWA), which is built upon extensions to the WebDAV protocol (RFC 2518). The integration with Microsoft Exchange is done through a separate Presence Gateway configuration for calendar applications. Once the administrator configures a Presence Gateway for Outlook, the user has the ability to enable or disable the aggregation of calendar information into their presence status (see Table 23-6).

Table 23-6 Aggregated Presence State Based on Calendar State

Cisco Unified Presence State

Calendar State

Available

Free / Tentative

Idle/Busy

Busy

Away

Out of Office

The exchange ID that is used to retrieve calendar information is taken from the email ID of the LDAP structure for that user. If the email ID does not exist or if LDAP is not being used, then the Cisco Unified Presence user ID is mapped as the exchange ID.

Information is gathered via a subscription for calendar state from the Cisco Unified Presence server to the Microsoft Exchange server. Figure 23-8 depicts this communication.

The feature requires a new service parameter that is the port address for the UDP HTTP (HTTPu) listen port. This port is where Microsoft Exchange sends any notifications (indicated by the NOTIFY message) indicating a change to a particular subscription identifier for calendar events.

The SEARCH transaction is used to search a user's calendar relevant to a given interval, and is invoked when the user has set a preference to include the calendar information in the presence status. The results of the search are converted into a list of free/busy state transitions. The SUBSCRIBE message indicates the subscription for notifications to changes in the free/busy state of the user in the folder /exchange/userX/Calendar. The POLL method is used to acknowledge that the client has either received or responded to a particular event, while the UNSUBSCRIBE message is used to terminate a previous subscription or subscriptions.

Cisco Unified Presence Guidelines

•If LDAP integration is possible, LDAP synchronization with Unified CM should be used to pull all user information (number, ID, and so forth) from a single source. However, if the deployment includes both an LDAP server and Unified CM that does not have LDAP synchronization enabled, then the administrator should ensure consistent configuration across Unified CM and LDAP when configuring user directory number associations.

•Associate presence users in Unified CM with a line appearance, rather than a primary extension, to allow for increased granularity of device and user presence status. When using the service parameter CUP PUBLISH Trunk, you must associate presence users in Unified CM with a line appearance.

•If you are using Cisco Unified Communications Manager Business Edition (Unified CMBE) 6.x with Cisco Unified Presence 6.x, all users must be entered manually due to the lack of support for LDAP synchronization or authentication.

Cisco IP Phone Messenger Application

Cisco IP Phone Messenger is a Cisco Unified IP Phone Service that provides users with the ability to create a buddy list, watch their buddies' aggregated presence information, and exchange instant messages with their buddies' Cisco Unified IP Phone or compliant SIP or SIMPLE client or gateway.

The Cisco IP Phone Messenger (IPPM) application, which is a component of Cisco Unified Presence, serves as a protocol translator between HTTP and SIP messaging. The IPPM application communicates with the Cisco Unified IP Phones using XML over HTTP (http://www.cisco.com/go/apps), and it communicates with the SIP Proxy/Registrar Server using SIP. The IPPM application can distinguish between two devices with the same directory number in different partitions and can also function when the user is logged in via Extension Mobility. However, it does rely on the availability of the Cisco Unified Presence publisher for new user logins.

•Meeting reminders can be sent from Cisco Unified Presence to registered IPPM phones without requiring the user to log in to their desktop calendar clients.

•Provides the ability to join a meeting from the IPPM service (via join, dial, or callback).

•Users can control whether to block the meeting reminder feature via the end-user configuration page.

•Users can browse the meeting roster list inside the meeting detail screen. The IPPM module will then send a SUBSCRIBE message per participant to the Presence Engine for their presence status. Meeting reminders and instant messages can then be sent to the users on the roster list, based on current availability.

Figure 23-11 IPPM Protocol Translation Meeting Notification

The following Cisco Unified IP Phones support Cisco IP Phone Messenger with SCCP:

•Cisco Unified IP Phone 7905G

•Cisco Unified IP Phone 7906G

•Cisco Unified IP Phone 7911G

•Cisco Unified IP Phone 7912G

•Cisco Unified IP Phone 7940G

•Cisco Unified IP Phone 7960G

•Cisco Unified IP Phones 7941G, 7941G-GE, 7942G, and 7945G

•Cisco Unified IP Phones 7961G, 7961G-GE, 7962G, and 7965G

•Cisco Unified IP Phones 7970G, 7971G-GE, and 7975G

•Cisco Unified IP Phone 7985G

•Cisco Unified IP Phone 7920 and 7921G

•Cisco IP Communicator

The following Cisco Unified IP Phones support Cisco IP Phone Messenger with SIP:

•Cisco Unified IP Phone 7906G

•Cisco Unified IP Phone 7911G

•Cisco Unified IP Phones 7941G, 7941G-GE, 7942G, and 7945G

•Cisco Unified IP Phones 7961G, 7961G-GE, 7962G, and 7965G

•Cisco Unified IP Phones 7970G, 7971G-GE, and 7975G

IP Phone Messenger is not supported with SIP on the Cisco IP Phones 7905, 7912, 7940, and 7960.

Current IP Phone Services in the Cisco Unified Communications System are configured with either an IP address or DNS A record entry for the HTTP Service URL, which can result in a single point of failure if no IP Phone Service redundancy is configured.

Without IP Phone Services redundancy, the IP Phone Messenger deployment should be load-balanced via configuration across both the Cisco Unified Presence publisher and subscriber.

On Unified CM, configure two phone services for IP Phone Messenger, one that uses the Cisco Unified Presence publisher and one that uses the Cisco Unified Presence subscriber, as illustrated in the following example:

•PhoneMessenger1:

http://publisher.cups.com:8081/ippm/default?name=#DEVICENAME#

•PhoneMessenger2:

http://subscriber.cups.com:8081/ippm/default?name=#DEVICENAME#

With Cisco IP Phone Messenger, you can deploy the Cisco Unified IP Phones in either of the following ways:

•Single phone service

With the single phone service, you configure half of the Cisco Unified IP Phones to point to the Cisco Unified Presence publisher (PhoneMessenger1 in the example above), while the other half is configured to point to the Cisco Unified Presence subscriber (PhoneMessenger2 in the example above).

Disadvantage — If the Cisco Unified Presence server node running that phone service fails, the IP Phone Messenger service is unavailable to the users.

•Dual phone service

With the dual phone service, you configure all Cisco Unified IP Phones to have two IP Phone Messenger services (both PhoneMessenger1 and PhoneMessenger2 in the above example).

Advantage — If the Cisco Unified Presence server node running the phone service fails, the user can try using the IP Phone Messenger service running on the second node.

Disadvantage — This method relies on the phone user to pick the IP Phone Messenger service to use from the Services menu. This method potentially leads to one Cisco Unified Presence server node being selected more than the other, thus resulting in a disproportionate number of users on one particular Cisco Unified Presence server node.

With IP Phone Services redundancy (see IP Phone Services Redundancy, page 24-6), IP Phone Messenger can be configured on Unified CM as a single phone service using the server load balancer (SLB) IP address, as illustrated in the following example:

•PhoneMessenger:

http://slb_ip_address:8081/ippm/default?name=#DEVICENAME#

Cisco IP Phone Messenger Bandwidth Considerations

The user message history and contact list are both stored in the Cisco Unified Presence database and have the potential to contain a lot of data. Every user login to the IP Phone Messenger application will download the message history and contact list. Therefore, if bandwidth might be a concern, you can limit the message history size and contact list size via Cisco Unified Presence administration by setting the Max Instant Message History Size and Max Contact List Size under the IP Phone Messenger settings.

The user has the ability to set a Session Timer parameter for controlling the amount of time the user is logged into the current session and a Refresh Interval parameter for controlling the rate at which presence status updates occur. The administrator currently has no control over these parameters; therefore, the default settings (Session Timer = 480 minutes and Refresh Interval = 30 seconds) are most likely to be used.

Cisco Unified Personal Communicator

Cisco Unified Personal Communicator integrates the most frequently used communications applications and services into a single desktop software application. Cisco Unified Personal Communicator leverages the following applications:

Cisco Unified Personal Communicator operates in one of two modes, Desk Phone (CTI control of the user's desk phone for Click to Call) and Soft Phone (software client operation), and it is supported on Apple Macintosh and Microsoft Windows platforms. Cisco Unified Personal Communicator call control features are similar to the features on Cisco Unified IP Phones. For a complete list of features supported by Cisco Unified Personal Communicator, see the chapter on Unified Communications Endpoints, page 21-1.

Cisco Unified Personal Communicator Deployment

Figure 23-12 shows the interfaces and various components of Cisco Unified Personal Communicator, and lists the ports used by Cisco Unified Personal Communicator for the protocol exchanges. For more information on Cisco Unified Personal Communicator, refer to the Cisco Unified Personal Communicator installation, operation, and maintenance guides, available at

Figure 23-12 depicts the following interactions between the components of Cisco Unified Personal Communicator:

1. Through the SOAP interface, a Cisco Unified Personal Communicator user logs in using TLS and retrieves the configuration profiles for the various interface components. The Cisco Unified Presence server is not an authenticated server with Cisco Unified Personal Communicator because no certificate validation is performed. However, this TLS connection protects all configuration information exchanged between Cisco Unified Personal Communicator and Cisco Unified Presence. If the Cisco Unified Personal Communicator user is authenticated via LDAP, Cisco Unified Presence does the bind to LDAP for the user during this login period before proceeding.

2. Cisco Unified Personal Communicator binds to the LDAP server for all the user-specific information (telephone number, contact, and so forth).

When using Microsoft Active Directory, consider the choice of parameters carefully. Performance of Cisco Unified Personal Communicator may be unacceptable when a large Active Directory implementation exists and the configuration uses a Domain Controller. To improve the response time of Active Directory, it might be necessary to promote the Domain Controller to a Global Catalog and configure the LDAP port as 3268.

3. Cisco Unified Personal Communicator sends a SIP REGISTER for the user and a SIP SUBSCRIBE for all the users in the contact list, to Cisco Unified Presence. A SIP NOTIFY is received from Cisco Unified Presence when a user status in the contact list needs to be updated. A SIP PUBLISH is sent when the user status is changed either manually or automatically.

4. If Cisco Unified Personal Communicator is configured for Desk Phone mode, a connection is established with the CTI Manager of Unified CM for phone control.

6. Calls between two Cisco Unified Personal Communicator users can be escalated, from within the conversation, to Cisco Unified MeetingPlace or MeetingPlace Express for a share-only web collaboration session using HTTP(S). Each connection will utilize one MeetingPlace User License, and the user initiating the escalation must have a MeetingPlace Express Profile.

7. Calls initiated to voicemail are communicated using IMAP with Cisco Unity or Unity Connection.

All SIP traffic, presence, and call setup between Cisco Unified Personal Communicator and Cisco Unified Presence, as well as Cisco Unified Personal Communicator and Unified CM, is not encrypted and is done via TCP or UDP. Cisco Unified Personal Communicator uses a standard SIMPLE interface for presence information exchange.

The Cisco Unified Personal Communicator deployment should be load-balanced via configuration across both the Cisco Unified Presence publisher and subscriber.

On the Cisco Unified Presence server, configure two Cisco Unified Personal Communicator proxy profiles, one that uses the Cisco Unified Presence publisher as the primary proxy server and the Cisco Unified Presence subscriber as the backup proxy server, while the other uses the Cisco Unified Presence subscriber as the primary proxy server and the Cisco Unified Presence publisher as the backup proxy server, as illustrated in the following example:

•ProxyProfile1:

Primary Proxy Server: Cisco Unified Presence Publisher

Backup Proxy Server: Cisco Unified Presence Subscriber

•ProxyProfile2:

Primary Proxy Server: Cisco Unified Presence Subscriber

Backup Proxy Server: Cisco Unified Presence Publisher

Configure half of the Cisco Unified Personal Communicator users to point to ProxyProfile1 and configure the other half to point to ProxyProfile2.

The Cisco Unified Presence server hardware deployment determines the number of users a cluster can support.

•IMAP scalability

The number of IMAP connections are determined by the platform overlay (Cisco Unity or Cisco Unity Connection) for messaging integration. For specific configuration sizing, refer to the Cisco Unity or Cisco Unity Connection product documentation available at http://www.cisco.com.

Cisco Unified Personal Communicator interfaces with Unified CM. Therefore, the following guidelines for the current functionality of Unified CM apply when Cisco Unified Personal Communicator voice or video calls are initiated:

•CTI scalability

In Desk Phone mode, calls from Cisco Unified Personal Communicator use the CTI interface on Unified CM. Therefore, observe the CTI limits as defined in the chapter on Call Processing, page 8-1. You must include these CTI devices when sizing Unified CM clusters.

Cisco Unified Personal Communicator does not download or store any local dial rules. Therefore, you might have to configure application dial rules on Unified CM to maintain the dial plans. (For example, if a user dials 18005551212 but you need only five digits, Unified CM can apply the Application Dial Rule: "Eleven-digit number beginning with 1 = retain only the last five digits.")

The following bandwidth considerations also apply to Cisco Unified Personal Communicator:

•All Cisco Unified Personal Communicator configuration and contacts are stored in the Cisco Unified Presence database and have the potential to contain large amounts of data. The current communications list is limited to 50 users, while the contact list size has no limit. Therefore, bandwidth utilization for presence data exchange must be taken into consideration.

Cisco Unified Personal Communicator marks Layer 3 IP packets via Differentiated Services Code Point (DSCP). The Cisco Unified Personal Communicator client marks call signaling traffic with a DSCP value of 24 or a per-hop behavior (PHB) value of CS3, and it marks RTP media traffic with a DSCP value of 46 (PHB value of EF). However, personal computer traffic is typically untrusted, and the network will strip DSCP markings made by an application from the PC. Therefore, access routers and switches must be configured to allow these DSCP markings for the port ranges that Cisco Unified Personal Communicator utilizes. For details on traffic marking, refer to the Enterprise QoS Solution Reference Network Design (SRND), available at

Third-Party Presence Server Integration

Cisco Unified Presence provides an interface based on SIP and SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) for integrating SIP and SIMPLE applications into the Cisco Unified Communications solution. You can configure and integrate a third-party presence server or application with this SIP/SIMPLE interface to provide presence aggregation and federation.

Microsoft Communications Server

For all setup, configuration, and deployment of Microsoft Live Communications Server 2005 or Office Communications Server 2007 and Microsoft Office Communicator, refer to the documentation at

Cisco does not provide configuration, deployment, or best practice procedures for Microsoft Communications products, but Cisco does provide the guidelines listed below for integrating Cisco Unified Presence with Microsoft Live Communications Server 2005 or Office Communications Server 2007.

Cisco Systems has developed an application note to show feature interoperability and configurations steps for integrating Cisco Unified Presence with Microsoft Live Communications Server 2005. You can access this application note at

Cisco Systems has developed an application note to show feature interoperability and configurations steps for integrating Cisco Unified Presence with Microsoft Office Communications Server 2007. You can access this application note at

Cisco Systems has also developed a guide for integrating Cisco Unified Presence with Microsoft Office Communications Server 2007. This Integration Note for Configuring Cisco Unified Presence with Microsoft OCS for MOC Call Control is available at

•The following table lists the number of users supported per platform.

Cisco Unified Communications Manager Platform

Number of Microsoft Office Communicator Users Supported Per Server

Number of Microsoft Office Communicator Users Supported Per Cluster

MCS 7825

800

3200

MCS 7835

800

3200

MCS 7845

2500

10000

•You must configure the same end-user ID in LDAP, Unified CM, and Microsoft Live Communications Server 2005 or Office Communications Server 2007. This practice avoids any conflicts between Microsoft Live Communications Server 2005 or Office Communications Server 2007 authentication with Active Directory (AD) and the end-user configuration on Unified CM, as well as conflicts with user phone control on Unified CM.

For Active Directory, Cisco recommends that the user properties of General, Account, and Live Communications all have the same ID. To ensure the Cisco Unified Presence users are consistent, LDAP Synchronization and Authentication should be enabled with Unified CM.

•You can configure routing of the SIP messages to Cisco Unified Presence by means of Static Routes in the Microsoft Live Communications Server 2005 or Office Communications Server 2007 properties.

•You must configure an incoming and outgoing access control list (ACL) on the Cisco Unified Presence server to allow for communications with Microsoft Live Communications Server 2005 or Office Communications Server 2007.

•You must enable each user for use of Microsoft Office Communicator in the Cisco Unified Presence server configuration, in addition to enabling each user for presence in Unified CM.

•Take into account bandwidth considerations for Microsoft Office Communicator login due to the exchange of configuration information between Microsoft Office Communicator and the Microsoft Communications Server, and due to initial communication with the Cisco Unified Presence server CTI gateway.

•The parameters that are required for Microsoft Office Communications Server 2007 have changed names from Live Communications Server 2005. The TEL URI parameter defined in Live Communications Server 2005 is the same as the Line URI parameter in Office Communications Server 2007, and the Remote Call Control SIP URI parameter defined in Live Communications Server 2005 is the same as the Server URI parameter in Office Communications Server 2007.

•When using E.164 numbering plans, Cisco recommends applying the rules for reverse number look-up to allow for conversion of the full directory number to the userid, as described in the Release Notes for Cisco Unified Presence Release 6.x available at

IBM Sametime 7.5

Cisco Systems, Inc. provides the following guidelines around how best to integrate IBM Sametime Server 7.5.1 with Cisco Unified Communications, but does not contend configuration, deployment, or best practice procedures for IBM Communications products.

For all setup, configuration, and deployment of IBM Sametime Server 7.5.1, refer to the documentation at

Cisco does not provide configuration, deployment, or best practice procedures for IBM communications products, but Cisco does provide the guidelines listed below for integrating IBM Sametime Server 7.5.1 with a Cisco Unified Communications system.

•The Cisco Call-Control plugin, resident on IBM Sametime Server 7.5.1, maintains a configured list of Unified CMs utilized in a round-robin manner. This list should be populated with the IP address of Unified CM subscribers that have been configured with the out-of-dialog REFER SIP trunks.

The Unified CM list can also be configured with DNS SRV; however, currently this SRV logic is used for redundancy only and not for load balancing, therefore it is not a recommended setting.

•Deployment topologies using IBM Sametime Server 7.5.1 typically will integrate with multiple Unified CM clusters due to the capacity differences between the two systems. With the Cisco Click-to-Call plugin utilizing a list of Unified CMs in a round-robin fashion, a call initiation can result in a REFER being sent to a cluster different from the user's home cluster. The Unified CM receiving this call setup will process the REFER and generate an INVITE to the appropriate destination to complete the call setup.

•Traffic marking has not been implemented fully with the Cisco Click-to-Call plugin. Therefore, follow the traffic marking guidelines in the Enterprise QoS Solution Reference Network Design (SRND), available at