Clarifying UC Terms

During a VoiceCon webinar Nancy Jamison and I presented along with Jim Krauetler of Genesys, I was asked to clarify a couple terms I had used. The following is intended to do a better job of explaining what these terms mean, both by definition and based on the impact they have on customers.

Tagging

“Tagging” allows UC users to “tag” contacts so they will receive a notification whenever the tagged contact becomes available for communication (IM, phone call, etc.). By “tagging” someone, you let the system know that you want to be notified when that person’s presence status changes to indicate the person is available for a phone call or IM. So, when the person’s status changes, the system will notify you so that you can make contact. Essentially, tagging reduces phone tag, voice mail or e-mail just to request a contact and makes it easier for people to connect, minimizing the communication overhead in managing tasks. Of course, many UC solutions also offer the ability to find alternate resources with equivalent knowledge, skills or authority, so that the transaction or task does not even have to wait for future availability, so Tagging should be seen as only one option for “optimizing business processes.”

Federation

In the UC world, federation is the term used for exchanging presence information among and between systems and devices, or the sharing of presence information across multiple presence systems. Federation makes it easier for UC users to connect with their colleagues, business partners, suppliers, and customers who are either outside of the company or using other UC systems, servers, or IM services. Without presence federation, a user can only see the presence information of other users who are on the same system and/or within their company. This is great for internal communications, but if you want to interact with people outside of your organization, especially with customers, partners, and suppliers, then federation is needed. With federation, rather than having separate islands of proprietary and private presence and IM systems, users on different environments can share presence information and IM with each other regardless of the system or service they’re using.

An alternate to federation, of course, is to ask all of your contacts to enroll in the same publicly-available presence service as you are using. The IM services of AOL, Google, MSN, Yahoo! and others are examples of this. Similar examples exist within the social networking services such as Facebook. However, it is not hard to realize the limitations of that approach and the effort required to manage many IM interfaces. In addition, these public services are often not sufficient for enterprise needs, such as security and compliance requirements.

There are many ways that federation will have to work: Between servers in different companies; between servers within the same company; within a network of servers; between enterprise servers and public IM services (e.g., MSN, AOL, Yahoo!); and between servers and other systems that are a source or user of presence data. SIP/SIMPLE standards are one way that presence clients and devices to share presence information with a presence server.

There are two ways of looking at federation or federated presence – 1) sharing presence information with users on the same vendor’s platform but in different companies, and 2) sharing presence information with people on different vendors’ platforms.

In the first case, the single vendor can often provide the federation, but may use some proprietary methods to do so, limiting the reach and participation in the federation approach. For example, using federation on Microsoft Office Communications Server 2007 (OCS), Jim at Genesys can see the presence status of Eric at Microsoft, and they can do click-to-call/click-to-communicate, collaborate and share documents, etc.

In the second case, a person (or company) using one vendor’s presence server would be able to connect with and see the presence of a colleague or partner using a presence server from another vendor. This requires conformity with industry standards, specifically the SIP/SIMPLE standards. This might occur within the same company, say if one division is using Microsoft OCS while another division is using Jabber IM. And, of course, it could occur between enterprises.

Of course, there is an alternative to just use a trusted network service so that each enterprise only need federate once with that service, rather than separately federating with each and every partner or customer. This has been used for years in telephony, e-mail and encryption services, so why not in IM and presence? We will have to watch and wait for this.

Think about email – it doesn’t matter what email system you’re using, you can send and receive email from anyone regardless of what email system they’re using. Enterprise-class IM and presence don’t yet work the same way – today, there is little or no federation between different enterprise IM and presence systems, although some of these systems offer federation with a few public IM systems, such as AIM and Yahoo.

For UC to be used successfully outside of the enterprise walls to customers, partners, suppliers, and others, federation is required across different types of IM services, and across different presence/IM servers and systems from different vendors (whether Microsoft, IBM, Cisco, Avaya, Alcatel-Lucent, etc.). For presence to be effective, it needs to work in a multivendor environment, especially when being used across company boundaries. This can happen either by system-to-system communications or by linkages to a central clearing house, and either way will require adoption of standards

The primary challenge making federation difficult to achieve is that different vendors have different ideas about what presence should be and how it should be used. Each supplier believes that it can “own” the presence engine, making interoperability more difficult. In addition, licensing for IM and presence systems may limit federation.

Many UC vendors are working on federation capabilities and standards. For example, both Microsoft OCS and IBM Sametime offer some federation capabilities – Microsoft Office Communications Server 2007 supports federation between organizations using OCS 2007, with partner presence systems, and with public IM systems (AOL, Yahoo and Windows Live). In addition, a specification has been published to allow any presence server to federate with Office Communications Server. IBM Lotus Sametime federates with any SIP & XMPP user, as well as with Public IM networks such as AIM, Yahoo!, and GoogleTalk. While this is a start, much more work is needed in the area of federation, and to make it easier to share IM and presence information between systems and services from different vendors.

Leave a Reply