Guest

Cisco Unified Communications Manager IM & Presence Service

Interdomain Federation - Enable Business-to-Business Exchange of Cisco and Microsoft Presence and IM

  • Viewing Options

  • PDF (499.1 KB)
  • Feedback

What You Will Learn

This paper discusses the user capabilities and experience when interdomain federation is established between Cisco ® Unified Presence and Microsoft Office Communications Server or Live Communications Server deployed in separate enterprises. It highlights areas where the user capabilities and experience might differ when compared to the exchange of rich presence and instant messaging (IM) among Cisco Unified Personal Communicator users within the same enterprise.
The information provided here is based on interoperability testing that Cisco conducted between Microsoft Office Communications Server 2007 and Cisco Unified Presence 7.0. This testing took place in both Cisco test labs and customer trial deployments. The paper also summarizes the inter-enterprise deployment setup, provides examples of commonly used features, and highlights deployment considerations.

Introduction

Enabling real-time collaboration and communication between an increasingly virtual and mobile workforce is critical to making businesses more responsive and agile in today's global workspace. A study conducted by Chadwick Martin Bailey (July 2008) found that on a daily basis 40 percent of employees are unable to reach co-workers on the first try, resulting in more than 20 percent of their employers experiencing a missed deadline or project delay on a weekly basis. As a result, businesses of all sizes are either deploying or evaluating unified communications applications - voice, video, presence, instant messaging, conferencing, messaging, mobile, telepresence, and contact center - to facilitate real-time collaboration between employees and business partners.
Presence and instant messaging constitute one of the foundational components of the unified communications experience that allows you to connect with colleagues on the first try by knowing their availability in advance and sharing instant messages with them in real time. As businesses go beyond corporate boundaries in search for new business partners, many see the value in the ability to exchange presence information and IM between businesses.
Interdomain federation is the secure, policy-controlled interconnection between different domains, enabling exchange of IM and presence information between users of these domains. This federation is established between groups of users that reside in separate domains to enable exchange of IM and presence information between them using open, standards-based protocols. These domains typically represent two different organizations, but they could also represent two subdomains inside the same corporation. This paper focuses on interdomain federation between two enterprises in separate Domain Name System (DNS) domains.
Interenterprise interdomain federation extends business benefits of presence and IM beyond the enterprise, with the security and performance that enterprises expect (Figure 1). When users are able to instantly view presence status and exchange IM with business partners or suppliers, they can remove the real-time communications bottleneck that often inhibits business-to-business communications.
When using this solution in a single corporation with subdomains, you need to analyze the effect of subdomains on your corporation's existing domain infrastructure; in some cases enabling interdomain federation between subdomains may not be a viable alternative. In addition, enabling interdomain federation between subdomains results in similar constraints to those experienced by users with interdomain federation enabled between enterprises. For example, users may need to know what subdomain their peer resides in if they wish to exchange presence and instant messages with them. It is also important to note that subdomaining prevents the ability to have a single federation point when federating with another enterprise.

Figure 1. Interenterprise Interdomain Presence and Instant Messaging Federation

With the introduction of Cisco Unified Presence 7.0, Cisco introduced interdomain federation between organizations that are both running Cisco Unified Presence 7.0 as well as when one organization is using Cisco Unified Presence 7.0 and the other is using Microsoft Office Communications Server 2007 and Live Communications Server 2005 Service Pack 1. Although there is no specific standard for interdomain federation, the Microsoft and Cisco interfaces for federation are based on Session Initiation Protocol/Session Initiation Protocol for Instant Messaging and Presence Leverage Extensions (SIP/SIMPLE) standards.

Interdomain Federation Deployment

This section briefly outlines how to establish interdomain federation between Cisco Unified Presence 7.0 and Microsoft Office Communications Server 2007. (For more-detailed deployment information, please refer to the " Integration Guide for Configuring Cisco Unified Presence Release 7.0 for Inter Domain Federation." Cisco Unified Presence also supports interdomain federation between Cisco Unified Presence 7.0 and Microsoft Live Communications Server 2005 Service Pack 1; however, in the interest of avoiding duplication of information, only Microsoft Office Communications Server 2007 is discussed here.
Configuration prerequisites for the federating enterprises include:

• One enterprise has a fully functional IM and presence Cisco Unified Presence 7.0 deployment with all required infrastructure components.

• The other enterprise has a fully functional IM and presence Microsoft Office Communications Server 2007 deployment with all required infrastructure components and associated Microsoft Office Communicator users enabled for federation.

• Each enterprise has a fully functional Internet connection with appropriate security features, components, and configurations. For example, firewalls need to be configured to allow SIP-over-Transport Layer Security (TLS) connections to be successfully established between the two enterprise domains.

The primary deployment task involves facilitating SIP-over-TLS communication between the enterprises. In order to enable this communication, both enterprises need to add a security mechanism to their existing unified communications setup, thereby securely exposing their environments to the Internet. In a Cisco enterprise this mechanism is in the form of a Cisco Adaptive Security Appliance (ASA), and in the Microsoft enterprise it is in the form of a Microsoft Office Communications Server in an Access Edge Server role.
Subsequently there are some configuration steps, including general configuration, security certificate deployment, and development of a trust relationship and DNS SRV publication so that one enterprise can find the other.
The typical solution architecture is illustrated in Figure 2.

Figure 2. Interdomain Federation Architecture

Interdomain Federation User Capabilities and Experience

This section summarizes key features supported by interdomain federation between Cisco Unified Presence and Microsoft Office Communications Server 2007.

Federated Presence Exchange

As mentioned in the introduction, it is possible to exchange presence information between federating organizations. This information exchanged between Cisco Unified Presence and Microsoft Office Communications Server 2007 is a subset of full presence states available to users on each system. The interdomain presence solution is intended to address a broad ecosystem of IM and presence providers that may or may not support all states and capabilities on their unique services.
Tables 1 and 2 show the presence mapping between a user's actual presence and the presence a federated buddy or watcher would see for that user. (A watcher is someone who has a view of a user's presence.) For example, if a Microsoft Office Communicator presence displays "Inactive" (Idle), then a federated Cisco Unified Personal Communicator user will see a presence of "Away" for that user. Similarly, if a Cisco Unified Personal Communicator user's presence state is "Inactive" (Idle), then a federated Microsoft Office Communicator user will see a presence of "Away" for that user.

Table 1. Cisco Unified Personal Communicator to Microsoft Office Communicator Presence Mapping

Table 2. Microsoft Office Communicator to Cisco Unified Personal Communicator Presence Mapping

* This indication is expected with polite blocking. Polite blocking does not indicate to the blocked watcher that they have been blocked from viewing a user's presence state. To the blocked watcher you simply appear offline at all times.

For instance, Figure 3 depicts a simple example where a Cisco Unified Personal Communicator user, "Harry Whit", is federating with a Microsoft Office Communicator user, "Rodney Fratt". Harry's presence is "Available"; this information is represented in both Harry's Cisco Unified Personal Communicator client and on the contact list of Rodney's Microsoft Office Communicator client. In Rodney's case, his presence is set to "Away", and this information is again reflected in both clients.

Figure 3. Federated Presence Exchange

Point-to-Point Federated Instant Messaging Exchange

The interdomain federation features enable IM communication between users in two separate domains. Keyboard or typing activity is also exchanged. The media type of the text content is plaintext. Exchange of rich text formatting such as font styling and coloring is not supported.
Figure 4 shows an example of business-to-business federated instant message exchange between Rodney Fratt's Cisco Unified Personal Communicator and Harry White's Microsoft Office Communicator clients.

Figure 4. IM Exchange

Enterprise User-to-User Access Policy and Polite Blocking

Both Cisco and Microsoft give users the ability to control which contacts from outside the enterprise can exchange presence and instant messages with them. This feature is a very important privacy feature in the context of exchanging presence information with entities outside of the user's local enterprise. Using a polite blocking mechanism, either Cisco Unified Personal Communicator or Microsoft Office Communicator users can prevent or block others from viewing their presence state. When a contact is blocked, the user appears offline to the blocked party and no separate indication is made to them that they have been blocked from viewing someone's presence state. In addition, the Microsoft Office Communicator and Cisco Unified Personal Communicator users who have blocked a contact are also unable to view blocked party's presence state.

User Access Policy Example

User access policy involves notifying users that someone wishes to view their presence information and allowing them to manage who can or cannot see that information. Figure 5 shows both the Cisco Unified Personal Communicator and Microsoft Office Communicator notifications when a federated user tries to view a user's presence for the first time.

Figure 5. Federated Watcher Notifications

The user can then choose to authorize or prevent (politely block) the federated user from viewing presence information at this juncture. If the user chooses to allow presence viewing, the federated user will see the user's presence, as discussed in the "Federated Presence Exchange" section. Polite blocking is demonstrated in Figure 6.

Figure 6. Polite Blocking

The user can unblock or block a watcher at any time.

Federated Contact Resolution

Users must know the SIP address of the contact in the enterprise they wish to federate with. The same paradigm applies to communication by email. A SIP address can be thought of as the user's IM and presence address. It is syntactically the same as an email address userid@domain (for example, bob@cisco.com). Users' SIP address may or may not be the same as their email address; it depends on how their enterprise is configured. Figure 7 shows how to add a contact.

Figure 7. Adding a Federated Contact

Deployment Considerations

This section describes aspects of interdomain federation between Microsoft Office Communications Server 2007 or Live Communications Server 2005 Service Pack 1 and Cisco Unified Presence to consider when deployment planning.

• Federated presence exchange: There is greater granularity of presence state sharing among Cisco Unified Personal Communicator users within the enterprise than is available with interdomain federation between Cisco Unified Personal Communicator and Microsoft Office Communicator users in different domains.

• Media escalation: Currently IM is the only supported media across the open, standards-based federated link. Escalation from IM to other communication mechanisms such as voice and video or features such as file transfer are not supported.

• Multiparty IM exchange: Group chat or multiparty IM in any form is unavailable across the open, standards-based federated link.

Conclusion

Interdomain federation of presence and IM breaks down communication barriers and allows users of Cisco Unified Presence and Microsoft Office Communications Server 2007 or Live Communications Server 2005 Service Pack 1 to communicate more efficiently. With the ability to see when business partners and customers are available, users can more effectively manage their communications, connect on the first try, and be more productive. Organizations with Cisco Unified Presence that need to communicate with organizations with Microsoft Office Communications Server or Live Communications Server can realize the benefits of presence and IM federation today.

For More Information

• Cisco Unified Presence: http://www.cisco.com/go/presenceserver

• Cisco Unified Personal Communicator: http://www.cisco.com/go/unifiedpersonalcomm

• Cisco Unified Communications: http://www.cisco.com/go/unifiedcommunications

• Microsoft Office Communications Server: http://www.microsoft.com/communicationsserver/en/us/default.aspx

• Microsoft Office Communicator:
http://office.microsoft.com/en-us/communicator/FX101729051033.aspx

• Microsoft Unified Communications: http://www.microsoft.com/uc