Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 7.x
Cisco Unified Presence
Downloads: This chapterpdf (PDF - 1.18MB) The complete bookPDF (PDF - 16.32MB) | Feedback

Cisco Unified Presence

Table Of Contents

Cisco Unified Presence

What's New in This Chapter

Presence

Cisco Unified Presence Components

Cisco Unified Presence User

Unified CM Presence

Unified CM Presence with SIP

Unified CM Presence with SCCP

Unified CM Speed Dial Presence

Unified CM Call History Presence

Unified CM Presence Policy

Unified CM Subscribe Calling Search Space

Unified CM Presence Groups

Unified CM Presence Guidelines

Cisco Unified Presence Server

Cisco Unified Presence Server Cluster

Cisco Unified Presence Server Redundancy

Cisco Unified Presence Deployment Models

Cisco Unified Presence Deployment Examples

Cisco Unified Presence Server Performance

Cisco Unified Presence Licensing

Cisco Unified Presence Deployment

Single-Cluster Deployment

Multi-Cluster Deployment

Clustering Over the WAN

Federated Deployment

Cisco Unified Presence Server Policy

Cisco Unified Presence Calendar Integration

Cisco Unified Presence Mobility Integration

Cisco Unified Presence Third-Party Open API

Guidelines for Deploying Cisco Unified Presence

Cisco IP Phone Messenger Application

Cisco IP Phone Messenger Bandwidth Considerations

Cisco Unified Personal Communicator

Cisco Unified Personal Communicator Deployment

Design Considerations for Cisco Unified Personal Communicator

Third-Party Presence Server Integration

Microsoft Communications Server

IBM Sametime 7.5


Cisco Unified Presence


Last revised on: January 12, 2012

 

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, instant messaging, 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 components of the presence solution. Cisco Unified Presence must be deployed with Cisco Unified Communications Manager (Unified CM) 5.x or later releases; Cisco Unified CM 4.x and earlier releases do not support Cisco Unified Presence.

This chapter covers the following topics:

Presence

Unified CM Presence

Cisco Unified Presence Server

Cisco IP Phone Messenger Application

Cisco Unified Personal Communicator

Third-Party Presence Server Integration

What's New in This Chapter

Table 22-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

 

Table 22-1 New or Changed Information Since the Previous Release of This Document 

New or Revised Topic
Described in:

Minor corrections to a few illustrations

Figure 22-6, Figure 22-7, Figure 22-8, Figure 22-10

Cisco Unified Communications Manager Business Edition

Guidelines for Deploying Cisco Unified Presence

Cisco Unified Personal Communicator

Cisco Unified Personal Communicator

Cisco WebEx

Design Considerations for Cisco Unified Personal Communicator

Clustering over the WAN and geographic redundancy

Clustering Over the WAN

Clusters

Cisco Unified Presence Server Cluster

Deployment models

Cisco Unified Presence Deployment Models

Federated deployment

Federated Deployment

IBM Sametime

Guidelines for Integrating Cisco Unified Presence with IBM Sametime Server 7.5.1

LDAP Search Context

Design Considerations for Cisco Unified Personal Communicator

Microsoft Exchange Server

Cisco Unified Presence Calendar Integration

Mobility integration

Cisco Unified Presence Mobility Integration

Multi-cluster deployment

Multi-Cluster Deployment

Multi-language support for calendars

Multi-Language Calendar Support

Performance

Cisco Unified Presence Server Performance

Reverse look-up of directory numbers

Guidelines for Integrating Cisco Unified Presence with Microsoft Live Communications Server 2005 or Office Communications Server 2007

Third-Party Open API

Cisco Unified Presence Third-Party Open API


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 Components

Cisco Unified Presence encompasses the following components, illustrated in Figure 22-1:

Cisco Unified Presence server

Cisco Unified Communications Manager (Unified CM)

Cisco Unified Personal Communicator

Cisco Unified MeetingPlace or MeetingPlace Express

Cisco Unity or Unity Connection

Cisco Unified Videoconferencing or Cisco Unified MeetingPlace Express VT

Lightweight Directory Access Protocol (LDAP) Server v3.0

Cisco Unified IP Phones

Third-party presence server

Figure 22-1 Cisco Unified Presence Components

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 by default as an end user and must be configured with a primary extension. 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 22-2.)

A user, specified in Unified CM as an end user, can be configured with a primary extension or associated with a line appearance. When using the CUP PUBLISH Trunk service parameter, you must associate the user with a line appearance rather than just a primary extension. 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. (See Figure 22-2.)

Figure 22-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.

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 22-3.)

Figure 22-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 22-4.)

Figure 22-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.

Unified CM Presence with SCCP

Unified CM supports Skinny Client Control Protocol (SCCP) line-side endpoints acting as presence watchers. There are no SCCP trunks. SCCP endpoints can request presence status of the indicated presence entity by sending SCCP messages to Unified CM.

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 by means of 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

Cisco Unified IP Phone Expansion Modules 7915 and 7916

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

Cisco Unified IP Phone Expansion Modules 7915 and 7916

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

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

Figure 22-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 22-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 through 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 phone state 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 phone state 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.


Note Cisco Unified Communications Manager Business Edition (Unified CMBE) can be used in ways similar to Unified CM to configure and control user presence capabilities. For more information, see Cisco Unified Communications Manager Business Edition.


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. Cisco Unified Presence also provides an HTTP interface that has a configuration interface via Simple Object Access Protocol (SOAP) as well as a presence interface via Representational State Transfer (REST). The Cisco Unified Presence server collects, aggregates, and distributes user capabilities and attributes using these standards-based SIP, SIMPLE, and HTTP interfaces.

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

http://www.cisco.com/en/US/products/ps6837/prod_maintenance_guides_list.html

Cisco Unified Presence consists of up to six servers, including one designated as a publisher, which utilize the same architectural concepts as the Unified CM publisher and subscriber. Within a Cisco Unified Presence cluster, individual servers can be grouped to form a subcluster. A subcluster can have at most two servers associated with it, and a single Cisco Unified Presence cluster can have up to three subclusters deployed as a basic topology, as shown in Figure 22-6, or as a highly available topology, as shown in Figure 22-7. The Cisco Unified Presence cluster can also have mixed subclusters, where one subcluster is configured for high availability with two servers while other subclusters contain a single server, as shown in Figure 22-8. The Cisco Unified Presence servers form their own cluster and are not formally integrated as part of the Unified CM cluster.

Figure 22-6 Basic Deployment of Cisco Unified Presence

Figure 22-7 Highly Available Deployment of Cisco Unified Presence

Figure 22-8 Mixed Deployment of Cisco Unified Presence

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 cluster supports only a single Unified CM cluster; therefore, all users of Cisco Unified Presence must be defined within the same Unified CM cluster.

Intracluster traffic participates at a very low level between Cisco Unified Presence and Unified CM and between the Cisco Unified Presence publisher and subscriber servers. 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 server interface with external systems sends SIP traffic over UDP, TCP, or TLS. TLS mutual authentication requires the import and export of certificates between Cisco Unified Presence server and the external system. TLS server authentication (Cisco Unified Presence server presenting its TLS certificate to the client device for verification) validates the end user via HTTP digest authentication.

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 22-2 as guidelines when executing the initial database synchronization with Unified CM using a single Cisco Unified Presence publisher.

 

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

Server Platform
Number of Users
Synchronization Time

Cisco MCS 7816

500

5 minutes

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 22-3 as guidelines when executing the initial database synchronization with Unified CM using a Cisco Unified Presence publisher and subscriber servers:

 

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

Server Platform
Number of Users
Synchronization Time

Cisco MCS 7816

500

5 minutes

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.

For more information on Unified CM redundancy, see the chapter on Call Processing.

The Cisco Unified Presence cluster consists of up to six servers, which can be configured into multiple subclusters (maximum of three subclusters) for high availability. A subcluster contains a maximum of two servers and allows for users associated with one server of the subcluster to use the other server in the subcluster automatically when a failover event occurs. Cisco Unified Presence does not provide failover between subclusters.

When deploying a Cisco Unified Presence cluster for high availability, you must take into consideration the maximum number of users per server to avoid oversubscribing any one server within the subcluster in the event of a failover. When deploying a Cisco Unified Presence cluster, use equivalent hardware for all servers within the cluster.

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 all the Unified CM deployment models. However, Cisco recommends co-locating the Cisco Unified Presence publisher with the Unified CM publisher due to the initial user database synchronization. All Cisco Unified Presence servers should be co-located within the Cisco Unified Presence cluster with the following exceptions:

Geographic datacenter redundancy and clustering over the WAN

For details, see Clustering Over the WAN.

Cisco Unified Customer Voice Portal (Unified CVP)

A Cisco Unified Presence cluster can be deployed with a maximum of two servers forming a single subcluster between two sites (one server in each site) for SIP Proxy functionality only (no presence functionality), as required by the Cisco Unified Customer Voice Portal deployment. This deployment must have a minimum bandwidth of 5 Mbps (primarily for installation and configuration) and a maximum latency of 80 ms round-trip time (RTT). For more information on Unified CVP, refer to the Cisco Unified Customer Voice Portal SRND, available at http://www.cisco.com/go/ucsrnd.

For more information on Unified CM deployment models, see the chapter on Unified Communications Deployment Models.

Cisco Unified Presence deployment depends on high-availability requirements, the total number of users, and the server hardware being used. Cisco recommends using similar hardware for each server in the Cisco Unified Presence cluster. Detailed configuration and deployment steps can be found in the Cisco Unified Presence Deployment Guide, available at

http://www.cisco.com/en/US/products/ps6837/products_installation_and_configuration_guides_list.html

A highly available Cisco Unified Presence cluster requires two servers per subcluster. This allows for users to fail-over between the servers within the subcluster; however, the total number of users supported and the time to failover vary based on which features are enabled, the average size of contact lists, and the rate of traffic placed on the servers. Once a Cisco Unified Presence subcluster is configured for two servers, it always operates as highly available. High availability can be deployed using an Active/Standby model or an Active/Active model, and these modes are controlled by the Sync Agent service parameter User Assignment Mode.

Cisco Unified Presence Active/Standby mode (setting User Assignment Mode to None) is attained by manually assigning users to the first server in the subcluster, leaving the second server with no users assigned but all processes synchronized and ready for a failover if the first server in the subcluster fails. For example, in Figure 22-7 the first user would be assigned to server 1A, the second user to server 2A, the third user to server 3A, the fourth user to server 1A, the fifth user to server 2A, the sixth user to server 3A, and so forth. The users should be assigned equally across all the 'A' servers in the cluster.

Cisco Unified Presence Active/Active mode (setting User Assignment Mode to balanced) will automatically assign users equally across all servers in the subclusters. Each server is synchronized and ready for a failover if the other server in the subcluster fails. For example, in Figure 22-7 the first user would be assigned to server 1A, the second user to server 2A, the third user to server 3A, the fourth user to server 1B, the fifth user to server 2B, the sixth user to server 3B, and so forth. The users are assigned equally across all the servers in the cluster.

Cisco Unified Presence Active/Active deployments with a balanced User Assignment Mode allows for redundancy flexibility based on the features being used, the size of user contact lists, and the traffic (user data profiles) being generated. A Cisco Unified Presence Active/Active deployment with a fully redundant mode, regardless of features, requires the total number of supported users to be reduced in half (for example, Cisco MCS 7845 servers in a balanced high-availability redundant deployment support up to 5000 users per subcluster). A Cisco Unified Presence Active/Active deployment with a non-redundant mode requires a more detailed look at the Cisco Unified Presence features being utilized, the average size of the users contact lists, as well as the traffic being generated. For example, for a deployment with presence and instant messaging enabled and calendaring and mobility integration disabled, with an average contact list of 30 users and a user data profile of a few presence and instant message updates, it is possible to support more than 5000 users per subcluster (if using Cisco MCS 7845 servers).

A Cisco Unified Presence cluster deployment that is not highly available allows for each server in the subcluster to support up to the maximum number of users. Cisco recommends deploying subclusters with single servers and creating up to three subclusters prior to adding a second server to any subscluter. Once a second server is added in a subcluster, the subcluster will still act as if in a high-available deployment; however, if a server failure occurs, an attempt to fail-over might not result in success if the online server reaches its capacity limit based on Cisco Unified Presence features enabled, the average user contact list size, and the traffic being generated by the users.

Cisco Unified Presence Deployment Examples

Example 22-1 Single Unified CM Cluster without Cisco Unified Presence

Deployment requirements:

4,000 users that could scale to 13,000 users

Single Cisco Unified Communications Manager cluster

High availability is not needed

Hardware:

Cisco MCS 7845 servers

Deployment:

Three single-server subclusters using User Assignment Mode = balanced

Example 22-2 Two Unified CM Clusters without Cisco Unified Presence

Deployment requirements:

11,000 users that could scale to 24,000 users

Two Cisco Unified Communications Manager clusters

High availability is not needed

Hardware:

Cisco MCS 7845 servers

Deployment:

Two Cisco Unified Presence clusters (one per Cisco Unified Communications Manager cluster), each with three subclusters with one server each using User Assignment Mode = balanced

Example 22-3 Single Unified CM Cluster with Cisco Unified Presence

Deployment requirements:

500 users that could scale to 2500 users

Single Cisco Unified Communications Manager cluster

High availability is required

Hardware:

Cisco MCS 7835 servers

Deployment:

One 2-server subcluster using User Assignment Mode = balanced

Example 22-4 Single Unified CMBE Cluster with Cisco Unified Presence

Deployment requirements:

100 users that could scale to 500 users

Single Cisco Unified Communications Manager Business Edition (Unified CMBE)

High availability is required

Hardware:

Cisco MCS 7825 servers

Deployment:

One 2-server subcluster using User Assignment Mode = balanced

Example 22-5 Multiple Unified CM Clusters with Cisco Unified Presence

Deployment requirements:

5,000 users that could scale to 40,000 users

Multiple Cisco Unified Communications Manager clusters

High availability is required

Hardware:

Cisco MCS 7845 servers

Deployment:

Multiple Cisco Unified Presence clusters will have to be set up with intercluster peers between each. Start with a single two-server subcluster, with up to 5000 users, for each Cisco Unified Presence cluster prior to adding additional subclusters within existing Cisco Unified Presence clusters. With a large number of users within a single Cisco Unified Presence cluster, the User Assignment Mode service parameter to use will most likely be dictated by the system administrator. If the desire is to monitor a single server per subcluster, Active/Standby mode might be preferred; whereas if equal user distribution is desired, then Active/Active mode might be preferred.

Cisco Unified Presence Server Performance

Cisco Unified Presence server clusters support single-server as well as multi-server configurations. However, if multiple servers are used, each server must be on the same type of server platform as the publisher server.

Table 22-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 cluster is deployed with three Cisco MCS 7845 servers, each forming their own subcluster, a total of 15,000 users would be supported.)

 

Table 22-4 Cisco Unified Presence Server Platforms and Number of Users Supported  

Server Platform
Users Supported Per Platform

Cisco MCS 7816

500

Cisco MCS 7825

1000

Cisco MCS 7835

2500

Cisco MCS 7845

5000


For additional hardware specifications, refer to the Media Convergence Server documentation available at

http://www.cisco.com/en/US/products/hw/voiceapp/ps378/prod_models_home.html

Cisco Unified Presence Licensing

User presence capabilities are assigned from Unified CM Administration under the licensing capabilities assignment. Users are licensed for presence capabilities from Unified CM, therefore Cisco Unified Presence requires integration with Cisco Unified CM.

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

http://www.cisco.com

Unified CM 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 any of the following configurations:

Single-Cluster Deployment

Multi-Cluster Deployment

Clustering Over the WAN

Federated Deployment

Single-Cluster Deployment

Figure 22-9 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

http://www.cisco.com/en/US/products/ps6837/tsd_products_support_series_home.html

Figure 22-9 Interactions Between Cisco Unified Presence Components

Figure 22-9 depicts the following interactions between Cisco Unified Presence components:

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

a. Unified CM configuration requires the Cisco Unified Presence servers 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 servers, or it could simply be an IP address of an individual Cisco Unified Presence server. Cisco Unified Presence 7.0(3) and later releases handle the configuration of the Cisco Unified Communications Manager application server entry automatically through AXL/SOAP once the administrator adds a node in the system topology page through Cisco Unified Presence administration.

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 Unified CM subscribers because it points to a single subscriber.

Unified CM provides the ability to further streamline communications and reduce bandwidth utilization by means of the 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. Once the CUP PUBLISH Trunk service parameter has been enabled, the users must be associated with a line appearance and not just a primary extension.

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.

3. The AXL/SOAP interface handles the database synchronization from Unified CM to populate the Cisco Unified Presence database.

a. No additional configuration is required on Unified CM.

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

The Sync Agent Service Parameter, User Assignment, set to balanced by default, will load-balance all users equally across all servers within the Cisco Unified Presence cluster. The administrator can also manually assign users to a particular server in the Cisco Unified Presence cluster by changing the User Assignment service parameter to None.

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.

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.

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 22-10 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 22-10 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 servers, or it could also simply be the IP address of the Cisco Unified Presence cluster servers.

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.

To assist with Cisco Unified Presence multi-cluster deployment performance, Cisco recommends sizing each Cisco Unified Presence cluster so that all users within the Cisco Unified Presence cluster are configured on a single subcluster. Also, Cisco recommends enabling the service parameter for decomposed lists to avoid additional server backend subscription traffic on the Cisco Unified Presence cluster.

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.

Clustering Over the WAN

A Cisco Unified Presence cluster can be deployed with one of the nodes of a subcluster deployed across the Wide Area Network (WAN). This allows for geographic redundancy of a subcluster and high availability for the users between the nodes across the sites. The following guidelines must be used when planning for a Cisco Unified Presence deployment with clustering over the WAN.

Geographic datacenter redundancy and remote failover

A Cisco Unified Presence cluster can be deployed between two sites with a single subcluster topology, where one server of the subcluster is in one geographic site and the other server of the subcluster is in another site. Any remaining subclusters (nodes within those subclusters) must remain co-located with the Cisco Unified Presence publisher. This deployment must have a minimum bandwidth of 5 Mbps, a maximum latency of 80 ms round-trip time (RTT), and TCP method event routing.

High availability and scale

Cisco Unified Presence high availability allows for users on one node within a subcluster to automatically fail-over to the other node within the subcluster. With a Cisco Unified Presence subcluster containing a maximum of two nodes, remote failover is essentially between two sites, one site for each node. A scalable highly available capacity for a Cisco Unified Presence cluster is up to three subclusters; therefore, a scalable highly available remote failover topology would consist of the following two sites:

Site A: Subcluster 1 node A, subcluster 2 node A, and subcluster 3 node A

Site B: Subcluster 1 node B, subcluster 2 node B, and subcluster 3 node B

This deployment must have a minimum bandwidth of 5 Mbps per subcluster, a maximum latency of 80 ms round-trip time (RTT), and TCP method event routing. Each new subcluster added to the deployment requires an additional 5 Mbps of dedicated bandwidth to handle the database and state replication.

Local Failover

A Cisco Unified Presence cluster deployment between two sites may also contain a subcluster topology per site (single node or dual node for high availability), where one subcluster is in one geographic site and the other subcluster is in another geographic site. This topology allows for the users to remain at their local site (highly available or not) without the requirement or need to fail-over to a different site or location. This deployment must have a minimum bandwidth of 5 Mbps dedicated bandwidth between each subcluster in the respective sites, a maximum latency of 80 ms round-trip time (RTT), and TCP method event routing.

Bandwidth and latency considerations

With a Cisco Unified Presence cluster that has a topology of nodes split across a WAN, the number of contacts within a user's client can impact the bandwidth needs and criteria for the deployment. The traffic generated within and between Cisco Unified Presence clusters is directly proportional to the characteristics of the presence user profile, and thus the amount of bandwidth required for deployment. Cisco recommends 25% or fewer remote contacts for a client in environments where the bandwidth is low (10 Mbps or less), and at all times the maximum round-trip latency must be 80 ms or less.

Federated Deployment

Cisco Unified Presence allows for business-to-business communications by enabling inter-domain federation, which provides the ability to share presence and instant messaging communications between different domains. Inter-domain federation requires two explicit DNS domains to be configured, as well as a security appliance (Cisco Adaptive Security Appliance) in the DMZ to terminate federated connections with the enterprise.

Figure 22-11 shows the basic inter-domain federation deployment between two different domains, indicated by Domain A and Domain B. The Adaptive Security Appliance (ASA) in the DMZ is used to terminate the TLS connections via the TLS Proxy and SIP Inspect functionality introduced in ASA version 8.0.4. All inbound federated traffic coming from the ASA is routed through a single Cisco Unified Presence cluster, and the inter-cluster peering propagates the traffic to the appropriate home cluster within the domain. All outbound traffic is sent from any Cisco Unified Presence cluster through the ASA to be propagated across the federated link.

Figure 22-11 Inter-Domain Federation

The inter-domain federation configuration also allows for a specific federation between Cisco Unified Presence and Microsoft Office Communications Server (OCS), as depicted in Figure 22-12. Cisco Unified Presence provides inter-domain federation with Microsoft Office Communications Server (OCS) or Live Communications Server (LCS) to provide basic presence (available, away, busy, offline) and point-to-point instant messaging. Rich presence capability (On the Phone, In a Meeting, On Vacation, and so forth), as well as advanced instant messaging features, are not supported.

Figure 22-12 Federation with Microsoft Office Communications Server

Table 22-5 lists the state mappings between Cisco Unified Presence and Microsoft Office Communications Server.

 

Table 22-5 Mapping of Presence States 

Cisco Status
Cisco Color
Status to Microsoft Office Communications Server

Out of office

RED

Away

Do not disturb

RED

Busy

Busy

RED

Busy

On the phone

YELLOW

Busy

In a meeting

YELLOW

Busy

Idle on all clients

YELLOW

Away

Available

GREEN

Available

Unavailable/offline

GREY

Offline



Note Cisco Unified Presence must publish a DNS SRV record for the domain to allow for other domains to discover the Cisco Unified Presence servers through DNS SRV. With a Microsoft Office Communications Server or Live Communications Server deployment, this is required because Cisco Unified Presence is configured as a Public IM Provider on the Access Edge server. If the Cisco Unified Presence server cannot discover the Microsoft domain using DNS SRV, you must configure a static route on Cisco Unified Presence for the external domain.


The Cisco Unified Presence federation deployment can be configured with redundancy using a load balancer between the Adaptive Security Appliance and the Cisco Unified Presence server, or redundancy can also be achieved with a redundant Adaptive Security Appliance configuration.

Additional configuration and deployment considerations regarding a federated deployment can be found in the Integration Guide for Configuring Cisco Unified Presence Release 7.0 for Inter-Domain Federation, available at

http://www.cisco.com/en/US/products/ps6837/products_installation_and_configuration_guides_list.html

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.

Reachability Rules

Based on precedence rules (first match) for determining reachability (away, available, busy, unavailable, do not disturb, unknown)

Based on device type, media type, and calendar (For example, if my cell phone is busy or my calendar is busy, mark me as busy. If any IM device is do-not-disturb, mark me as do-not-disturb.)

Filtering Rules

Exclude presence status for specific device types, media types, or calendar

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 integration is supported with Microsoft Active Directory 2003 and Active Directory 2008 as well as Windows Server 2003 and Windows Server 2008. 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 22-6).

 

Table 22-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 22-13 depicts this communication.

Figure 22-13 Communication Between Cisco Unified Presence and Microsoft Exchange

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.


Note Cisco Unified Presence can be deployed with a single Microsoft Exchange Server or with multiple Microsoft Exchange Servers. Microsoft Exchange deployment allows for clustering of multiple Exchange servers; therefore, Cisco Unified Presence will honor the REDIRECT message to the exchange server that is hosting the user for which Cisco Unified Presence is requesting status.


Multi-Language Calendar Support

In cases where the requirements for a calendar integration deployment specify more than one language, use the following design guidelines:

Cisco Unified Presence, as well as Cisco Unified Communications Manager, must have the appropriate locales installed for the users to select their locale.

Cisco Unified Presence supports all the standard Unified Communications locales for calendar integration.

Users must be configured for the locale that is desired, either through the end user pages or administratively through the Bulk Administration Tool.

A Presence Gateway of type Outlook must be configured to Microsoft Exchange. Cisco Unified Presence sends the appropriate locale folder with the initial query. Queries are redirected, if required, through the response of the initial Front-End or Client Access Microsoft Exchange server.

When using IP Phone Messenger and the Meeting Notification functionality, the user's locale must be configured to be the same as the locale where the phone's IP Phone Messenger service is being used.

Cisco Unified Presence Mobility Integration

Cisco Unified Presence has the ability to integrate contact lists and presence state with Cisco Unified Mobility Advantage and Cisco Unified Mobile Communicator. Cisco Unified Mobile Communicator continues to communicate directly with Cisco Unified Mobility Advantage, while Cisco Unified Mobility Advantage communicates with Cisco Unified Presence via AXL/SOAP and SIP.

An application user must be configured on Cisco Unified Presence and Cisco Unified Mobility Advantage before Cisco Unified Mobility Advantage can establish an administrative session with Cisco Unified Presence. Cisco Unified Mobile Communicator end-user logins will generate a Cisco Unified Mobility Advantage SOAP request to Cisco Unified Presence for system configuration, user configuration, contact list, presence rules, and application dial rules, followed by Unified Communicator Change Notifier (UCCN) configuration and Presence SIP subscriptions. Figure 22-14 highlights the Cisco Unified Mobility Advantage interaction with Cisco Unified Presence.

Figure 22-14 Cisco Unified Mobile Communicator Call Flow

The call flow in Figure 22-14 illustrates the following sequence of events:

1. Cisco Unified Mobility Advantage initiates a SOAP login request to Cisco Unified Presence via the super-user application user (CCMAdministrator), and Cisco Unified Presence returns a session key. This application user must be created on both Cisco Unified Presence and Cisco Unified Mobility Advantage.

2. A Cisco Unified Mobile Communicator end-user logs in, and Cisco Unified Presence returns a session key.

3. Cisco Unified Mobility Advantage initiates a get-all-config SOAP request (with session key) on behalf of the user to retrieve the system configuration, user configuration, contact list, presence rules, and application dial rules.

4. Cisco Unified Mobility Advantage submits a Unified Communicator Change Notifier (UCCN) subscription with the profileconfig event package for the user.

5. Cisco Unified Mobility Advantage submits a Presence subscription with the presence event package for the user.

Observe the following requirements when integrating Cisco Unified Mobility Advantage with Cisco Unified Presence:

Cisco Unified Mobility Advantage must be deployed in a single Cisco Unified Communications Manager cluster and a single Cisco Unified Presence cluster.

No more than 1000 Cisco Unified Mobile Communicator users can be integrated per Cisco Unified Mobility Advantage deployment.

A Cisco Unified Presence cluster can have no more than 2 nodes.

Cisco Unified Presence Third-Party Open API

Cisco Unified Presence has the ability to integrate with third-party applications via HTTP in addition to SIP/SIMPLE. The HTTP interface has a configuration interface as well as a presence interface via Representational State Transfer (REST). The Third-Party Open API provides two mechanisms to access presence: a real-time eventing model and a polling model.

Real-Time Eventing Model

The real-time eventing model uses an application user on Cisco Unified Presence to establish an administrative session, which allows for end users to log in with that session key. Once the end user has logged in, the user registers and subscribes for presence updates using Representational State Transfer (REST). Figure 22-15 highlights the Third-Party Open API real-time eventing model interaction with Cisco Unified Presence.

Figure 22-15 Third-Party Open API Real-Time Eventing Model

The call flow in Figure 22-15 illustrates the following sequence of events:

1. The application initiates a SOAP login request to Cisco Unified Presence via the super-user application user (APIUser), and Cisco Unified Presence returns a session key. The application can then log in the end-user with this session key (essentially, the end-user logs in via the application).

2. The end user registers the endpoint using the application-user session key.

3. The application initiates a subscribe request (using the session key) on behalf of the end user to retrieve user information, contact list, and presence rules.

4. Cisco Unified Presence sends a notification - unsecured.

5. The application requests the user's presence status.

Polling Model

The polling model uses an application user on Cisco Unified Presence to establish an administrative session, which allows for end users to log in with that session key. Once the end user has logged in, the application requests presence updates periodically, also using Representational State Transfer (REST). Figure 22-16 highlights the Third-Party Open API polling model interaction with Cisco Unified Presence.

Figure 22-16 Third-Party Open API Polling Model

The call flow in Figure 22-16 illustrates the following sequence of events:

1. The application initiates a SOAP login request to Cisco Unified Presence via the super-user application user (APIUser), and Cisco Unified Presence returns a session key. The application can then log in the end-user with this session key (essentially, the end-user logs in via the application).

2. The application requests presence state and bypasses the eventing model.

3. The application requests presence state and bypasses the eventing model.


Note Both Basic presence and Rich presence can be retrieved; however, the polling model puts an additional load on the presence server.


Observe the following requirements when integrating either model of the Third-Party Open API with Cisco Unified Presence:

Certificates are required for the presence interface (sipproxy.der) and the configuration interface (tomcat_cert.der).

No more than 1000 Third-Party Open API users can be integrated per Cisco Unified Presence deployment.

To improve performance, balance the Third-Party Open API users across all servers in the Cisco Unified Presence cluster.

You can obtain additional information and support for use of the Cisco Unified Presence Third-Party Open API through Cisco Developer Services, available at:

http://www.cisco.com/web/developer/

Information and assistance for developers is also available from the Cisco Developer Community, which is accessible through valid Cisco login authentication at:

http://developer.cisco.com/

Guidelines for Deploying Cisco Unified Presence

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.

Cisco Unified Presence marks Layer 3 IP packets via Differentiated Services Code Point (DSCP). Cisco Unified Presence marks all call signaling traffic based on the Differential Service Value service parameter under SIP Proxy, which defaults to a value of DSCP 24 (PHB CS3).

Presence Policy for Cisco Unified Presence is controlled strictly by a defined set of rules created by the user.

The Cisco Unified Presence publisher and subscriber must be co-located with the Unified CM publisher.

Use the service parameter CUP PUBLISH Trunk to streamline SIP communication traffic with the Cisco Unified Presence server.

Associate presence users in Unified CM with a line appearance, rather than just 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.

A Presence User Profile (the user activity and contact list contacts and size) must be taken into consideration for determining the server hardware and cluster topology characteristics.

Use the User Assignment Mode sync agent parameter default of balanced for best overall cluster performance.

Cisco Unified Presence 7.x is compatible with Unified CM 5.x, 6.x, and 7.x.

Cisco Unified Communications Manager Business Edition (Unified CMBE) 7.x supports LDAP synchronization, which should be enabled when integrating Unified CMBE with Cisco Unified Presence.

For a complete listing of ports used by Cisco Unified Presence, refer to Port Usage Information for Cisco Unified Presence, available at

http://www.cisco.com/en/US/products/ps6837/products_device_support_tables_list.html

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.

The IPPM application provides the following presence functionality (see Figure 22-17):

Shows aggregated presence status of a buddy.

Supports overriding the presence status manually (Available, Busy, Do Not Disturb).

Upon phone login, SUBSCRIBE to all phone buddies' presence statuses. Upon phone logout, SUBSCRIBE with Expires=0 (terminate subscription).

Update buddy presence status in the IPPM application upon receipt of a NOTIFY message from the presence engine.

Manage the contact list from both the phone (Phone Messenger Service) and the web user interface (http://<cup_server_address>/ccmuser).

Figure 22-17 IPPM Protocol Translation Presence

The IPPM application provides the following instant messaging (IM) functionality (see Figure 22-18):

Translates HTTP instant messages from the phone to outbound SIP MESSAGE messages.

Translates inbound SIP MESSAGE messages to HTTP instant messages to the phone.

Provides the ability to dial-back a buddy from either the buddy information screen or the IM screen.

Manages the message history from the phone (Phone Messenger Service).

Gives you the ability to configure canned system-wide and personal IM responses as well as the ability to compose messages.

Figure 22-18 IPPM Protocol Translation Instant Message

The IPPM application provides the following meeting notification functionality (see Figure 22-19):

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 22-19 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).

Advantage — The administrator load-balances the IP Phone Messenger users via configuration.

Disadvantage — If the Cisco Unified Presence server 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 running the phone service fails, the user can try using the IP Phone Messenger service running on the second server.

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 being selected more than the other, thus resulting in a disproportionate number of users on one particular Cisco Unified Presence server.

With IP Phone Services redundancy (see IP Phone Services Redundancy), 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:

Lightweight Directory Access Protocol (LDAP) for directory lookup and contact information

Cisco Unified Communications Manager (Unified CM) for IP telephony

Cisco Unity or Unity Connection for voice messaging

Cisco Unified MeetingPlace, MeetingPlace Express, or WebEx for web conferencing

Cisco Unified Videoconferencing for multipoint video

Cisco Unified MeetingPlace Express VT for multipoint voice, web, and video switching

Cisco Unified Presence for configuration, authentication, services, instant messaging, and presence information

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 signaling 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.

Cisco Unified Personal Communicator Deployment

Figure 22-20 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 port usage, refer to the Release Notes for Cisco Unified Personal Communicator, available at

http://www.cisco.com/en/US/products/ps6844/prod_release_notes_list.html

Figure 22-20 Cisco Unified Personal Communicator Components

Figure 22-20 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.

5. Cisco Unified Personal Communicator sends a SIP REGISTER to Unified CM to allow for media exchanges (voice and video), and it receives a SIP NOTIFY for Message Waiting Indication (MWI) status.

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.

All users in the Cisco Unified Presence cluster must be assigned to a server prior to any exchange of information. Cisco Unified Presence, by default, allows for automatic user assignment that is equally balanced across all servers in the cluster. The administrator can control where users are assigned by setting the User Assignment Mode Sync Agent service parameter to None instead of the default balanced. When setting this parameter to None, user assignment is done from the System > Topology menu.

Cisco Unified Personal Communicator deployment provides for basic deployment and a highly available deployment for automatic redundancy. In a Cisco Unified Presence two-server subcluster, users associated with one server are known by the other server in the subcluster, thus allowing for automatic failover when communication with the configured server is interrupted. (See Figure 22-21.)

Figure 22-21 Failover in a Cisco Unified Presence Two-Server Subcluster

As illustrated in Figure 22-21, failure of Cisco Unified Presence server 1A initiates the following sequence of events:

1. Cisco Unified Presence server 1B sends a NOTIFY message to Cisco Unified Personal Communicator, terminating its Presence and Unified Client Change Notifier (UCCN) Subscription-State on server 1A.

2. Cisco Unified Personal Communicator send a SUBSCRIBE message to Cisco Unified Presence server 1B to reactivate its Presence and UCCN Subscription-State.

Cisco Unified Personal Communicator also allows for federated contacts to be added once Cisco Unified Presence has been configure for a federated deployment. This allows for the user to input and control contacts within their existing domain as well as users of other domains. With this additional contact functionality there is also the ability for users to control privacy settings such as blocked lists and domains that are available for communication.

For more information on federation, refer to the Integration Guide for Configuring Cisco Unified Presence Release 7.0 for Inter-Domain Federation, available at

http://www.cisco.com/en/US/products/ps6837/products_installation_and_configuration_guides_list.html

Design Considerations for Cisco Unified Personal Communicator

The required interfaces for Cisco Unified Personal Communicator are Cisco Unified Presence, Cisco Unified Communications Manager (Unified CM), and an LDAP v3 compliant server. Cisco Unified Personal Communicator optional interfaces include Cisco Unity, Cisco Unity Connection, Cisco Unified MeetingPlace, Cisco Unified MeetingPlace Express, Cisco Unified Videoconferencing, Cisco Unified MeetingPlace Express VT. When designing and sizing a solution, you must consider the following scalability impacts for all the components:

Client scalability

The Cisco Unified Presence server hardware deployment determines the number of users a cluster can support. The Cisco Unified Personal Communicator deployment must balance all users equally across all servers in the cluster. This can be done automatically by setting the User Assignment Mode Sync Agent service parameter to balanced.

The maximum number of contacts in the contact list is 200.

LDAP Search Context

The ability to specify an LDAP filter to search an object class, which allows for the retrieval of only users and not computers from the directory, is done by appending &(objectclass=user) to the search context. For example:

cn=user,dc=example,dc=com;&(objectclass=user)

The ability to specify more than a single LDAP search context is done using a # as a delimiter in the LDAP Search Context field on Cisco Unified Presence Administration. An example of the supported format is:

ou=test,dc=example,dc=com#ou=testing,dc=example,dc=com

The Cisco Unified Personal Communicator will search both Organizational Units in order, 'test' then 'testing'.

Note that the LDAP search context field is limited to 255 characters; thus, the number of supported Organizational Units can vary, depending on the size and number of characters for each individual search context.

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.

Web conferencing

Cisco Unified MeetingPlace or Cisco Unified MeetingPlace Express web licensing determines the number of concurrent web conferencing participants allowed. For specific configuration sizing, refer to the Cisco Unified MeetingPlace or Cisco Unified MeetingPlace Express product documentation available at http://www.cisco.com.

Cisco Unified Personal Communicator supports Cisco WebEx meetings that do not require a password. On the Cisco WebEx Server, the option All meetings must have a password is selected by default. You must deselect that option in order for Cisco Unified Personal Communicator to launch a Cisco WebEx meeting.

Video sizing capability

Video conferencing and switching is determined by Cisco Unified Videoconferencing MCU sizing and configuration, or by Cisco Unified MeetingPlace Express VT for concurrent voice, video, and web participants. For specific configuration sizing, refer to the Cisco Unified Videoconferencing or Cisco Unified MeetingPlace Express VT 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. You must include these CTI devices when sizing Unified CM clusters.

Call admission control

Cisco Unified Personal Communicator applies call admission control for voice and video calls via Unified CM locations or RSVP.

Codec selection

Cisco Unified Personal Communicator voice and video calls utilize codec selection through the Unified CM regions configurations.

Dial rules

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.

For Cisco Unified MeetingPlace voice, video, and web collaboration sessions, see the chapter on Cisco Unified MeetingPlace.

For Cisco Unified MeetingPlace Express web collaboration sessions, see the chapter on Cisco Unified MeetingPlace Express.

For video calls, see the chapter on IP Video Telephony.

For Cisco Unity or Unity Connection, see the section on Managing Bandwidth, in the chapter on Cisco Voice Messaging.

Cisco Unified Personal Communicator marks Layer 3 IP packets via Differentiated Services Code Point (DSCP). Cisco Unified Personal Communicator marks call signaling traffic with a vale of DSCP 24 (PHB CS3), and it marks voice media traffic with a value of DSCP 46 (PHB 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

http://www.cisco.com/go/designzone

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:

http://www.microsoft.com/

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 configuration steps for integrating Cisco Unified Presence with Microsoft Live Communications Server 2005. You can access this application note at:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/pbx/interop/notes/602270nt.pdf

Cisco Systems has also developed application notes to show feature interoperability and configuration steps for integrating Cisco Unified Presence with Microsoft Office Communications Server 2007. You can access the application notes at the following locations:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/pbx/interop/notes/617030nt.pdf

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/712410.pdf

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 LCS/OCS for MOC Call Control is available at:

http://www.cisco.com/en/US/products/ps6837/products_installation_and_configuration_guides_list.html

Guidelines for Integrating Cisco Unified Presence with Microsoft Live Communications Server 2005 or Office Communications Server 2007

The following guidelines apply when integrating the Cisco Unified Presence server and Microsoft Live Communications Server 2005 or Office Communications Server 2007:

Communications between Cisco Unified Presence and Microsoft Live Communications Server 2005 or Office Communications Server 2007 uses the SIP/SIMPLE interface. However, Microsoft Live Communications Server 2005 or Office Communications Server 2007 tunnels Computer-Supported Telecommunications Applications (CSTA) traffic over SIP. Therefore, the CTI gateway on the Cisco Unified Presence server must be configured to handle the CSTA-to-CTI conversion for Click to Call phone control.

Cisco Unified Presence deployment with Microsoft Office Communications Server 2007 or Live Communications Server 2005 for Remote Call Control, should consist of a single subcluster pair of servers that make up the Cisco Unified Presence cluster.

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

 

Cisco Unified Presence 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, 7835, or 7845

MCS 7825

900

3,600

MCS 7825, 7835, or 7845

MCS 7835

1,000

4,000

MCS 7825, 7835, or 7845

MCS 7845

3,375

13,500


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 must configure Microsoft Live Communications Server 2005 or Office Communications Server 2007 Host Authentication to contain the Cisco Unified Presence publisher and subscriber.

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.

To address the issue of a reverse look-up of a directory number that corresponds to a user, use the guidelines documented in the Release Notes for Cisco Unified Presence, available at

http://www.cisco.com/en/US/products/ps6837/prod_release_notes_list.html

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

http://www.ibm.com/

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.

Guidelines for Integrating Cisco Unified Presence with IBM Sametime Server 7.5.1

Click-to-call and click-to-conference functionality integrated within the IBM Sametime 7.5.1 client is handled via a Cisco Call Control plugin resident on IBM Sametime Server 7.5.1. The integration into Cisco Unified Communications for click-to-call and click-to-conference functionality is handled via the SIP trunk interface with Unified CM. The integration into Cisco Unified Communications for presence functionality is handled via the SIP/SIMPLE interface with Cisco Unified Presence.

The Unified CM SIP trunk for click-to-call and click-to-conference functionality must be configured for out-of-dialog REFER processing. Enable the Accept Out-of-Dialog REFER checkbox in the SIP Trunk Security Profile associated with the SIP trunk communicating with IBM Sametime Server 7.5.1.

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 Call Control plugin. Therefore, follow the traffic marking guidelines in the Enterprise QoS Solution Reference Network Design (SRND), available at

http://www.cisco.com/go/designzone