By Alan Johnston, Consulting Member of Technical Staff, Avaya
And Christian Stegh, IP Telephony Practice Leader, Avaya, North America

Some 75% of companies use instant messaging, according to Nemertes Research. IM’s popularity is understandable: presence-enabled real-time communication with associates and friends is efficient and easy to use. As its popularity exploded in the consumer market, workers began bringing the technology to the office on a multitude of IM clients. IM’s wide use within enterprises comes in spite of the lack of a unifying standard and cross-client interoperability. New approaches to standards and federations between enterprises and outside domains seek to solve these challenges, and are the focus of this column.

The Case for Controlled Connectivity:

IM in the enterprise is typically supplied using one of two models:

The first approach typically means that the IT department either doesn’t mind or doesn’t control user access, and that there is more or less wide open access. This approach has its pitfalls; security risks and lack of IT control are at the forefront. Client vulnerabilities, an alternate conduit for spam, viruses, identity theft and loss of privacy are most common concerns. And with good reason, considering that December 2005’s instant message exploits jumped 826 percent over December, 2004 according to IMlogic’s Threat Center. As such, enterprises are getting more serious about banning the use of public IM services. Yet attempts to lock down IM are difficult, since many common IM platforms use open ports (like port 80) if their default ports are blocked at the firewall.

The second approach, in which IT has control of an internal IM system, has its benefits:

Reduced virus risks

But it’s isolated – each enterprise is an island unto itself with limited or no external IM connections to partners, clients, and the rest of the outside world, isolating a company and its employees.

The Best of Both Worlds

Enterprises can leverage the best of both worlds — controlled connectivity — by systematically interconnecting their internal IM system with other enterprises and public IM services. While bilateral peering (one company to another) is possible, it is not scalable. If a health care insurance company wanted to peer with all of its providers, for instance, a team of engineers would be needed to manage the policy and technology. So, what’s the happy medium? Something to efficiently interconnect the domains is needed.

Enter “federated services,” a way for enterprises that need to work closely with partners, hosted suppliers, and customers, to interconnect their enterprise VoIP networks, federate enterprise IM systems, and interoperate with the public IM networks. This is an emerging business segment in the convergence landscape. A service provider works with the enterprise to develop a peering policy, then handles the complex policy implementation, process work, and protocol exchange. The result is a collaborative, yet secure environment, since enterprises can still control with whom they want to federate. Of course, to federate, service providers must handle multiple IM protocols. A brief explanation of the common protocols used by public and enterprise IM systems is provided next.

Instant Messaging Standards

There are two primary approaches to Instant Messaging. One is based on a client-server model, the second based on SIP. While both strive to meet the requirements of IETF Request For Comment 2779 (an informational IETF document on IM/Presence Protocol requirements), they’re different in philosophy and practice and are not natively compatible. Most public IM services use older proprietary protocols.

XMPP (Extensible Messaging and Presence Protocol), the first standard IM protocol to become popular, was born out of the instant messaging world. After being formed as the Jabber protocol in 1999, the base Jabber/XMPP protocols have since been approved by the Internet Engineering Task Force (IETF). XMPP is an XML streaming technology using client/server architecture. Like email, XMPP clients connect to servers and servers can connect to each other. Unlike email, though, XMPP doesn’t have multiple hops between servers and has native security mechanisms, such as channel encryption and authentication. IM systems from Apple (in its Tiger OS), GAIM, Google, and Sun, to name a few, use XMPP.

SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) is the IETF working group responsible for one of the first major extensions to the core SIP standard. Since SIP inherently supports multiple media types, IM is simply another form of communication supported by the protocol, along with voice, video, gaming, and others. SIMPLE’s base protocols have been approved by the IETF. Since SIP is inherently a peer-to-peer protocol, IM can be P2P, not passing through servers. Being a part of the SIP stack enables presence across other devices, like SIP phones, so a buddy list can include on-hook/off-hook status in addition to basic IM/desktop status. SIMPLE’s inherent scalability and modularity within the broader SIP stack made it the choice of enterprise players like Avaya, IBM, and Microsoft.

Current State of the Standards

Both the core XMPP and SIP specifications are complete and published in the IETF as RFCs. However, significant work is being done on extensions to the base standards.

Extensions to XMPP are not being done in the IETF. Instead, they are being handled in the Jabber Software Foundation’s JEP process and will never be published as RFCs. There are well over 100 JEPs listed at http://www.jabber.org/jeps/jeplist.shtml. XMPP extensions include the initial documentation for a set of multimedia extensions, called Jingle, released in late 2005.

The extensions to SIP for IM and Presence are not yet complete either; they are being developed in the IETF’s SIMPLE Working Group. Many have been published as RFCs with others in various stages as Internet Drafts. The SIMPLE WG charter page lists about 20 Internet Drafts that will eventually be published as RFCs.

Interworking Between SIMPLE and XMPP

SIMPLE and XMPP systems have been deployed in enterprises and both will continue to be deployed in the near future. Gateway products have emerged out of the need to interwork between different IM systems. Gateways mainly transpose IM and desktop presence protocols, so that users with one client can see buddies from other IM systems. Behind the scenes, gateways manage protocol conversion, security, policy rules, and privileges, usually all on the same platform. When connected to SIP-enabled IP PBXs, some gateways can transpose the on-hook/off-hook presence of phones as well. In most cases, gateways are custom developed, often involving APIs, to interwork with each IM system.

Fortunately, basic interworking between the protocols is possible in a standardized way, by directly mapping addresses and presence subscriptions/ notifications from one protocol to another for use in such gateways.

However, the different security models used by the two protocols have proven more difficult to merge. For example, Secure SIP requires the use of TLS transport end to end — the session must fail if this cannot be provided. It is unclear how to interwork a Secure SIP IM session with XMPP, which has no equivalent security mode. As a result, it is likely that federation services providing both protocol interworking and security and policy enforcement will be a viable service.

Advanced Features Call for Advanced Services

While the challenge of the base protocols working together might be solved by standards in the short term, more advanced features, security, and management will be value-added services of the federated model for the longer term.

For instance, the more complicated mapping of text chat rooms and conferencing has not yet been described in published documents. Privacy and manageability policies across borders will take significant care and feeding. While enterprise IM systems have some policy control built into them, in their current versions, they lack robust features to handle complex cross-company requests. While enterprise systems may be able to allow/deny based on general characteristics, it would be a coarse, rather than granular, set of options. For instance, Company A could peer with Company B, but, if A’s recruiting department shouldn’t be able to see the presence of B’s coveted IT staff, today’s enterprise systems might not block their view. Another example: two companies that are merging might want to allow IM only from executives and merger analysts, but not between line workers.

What about a Standard for Federation Itself?

Currently, no discussion is underway about standardizing how enterprises peer with their federated IM service providers, but there is good reason to begin them. Like SIP itself, there are options within SIMPLE that network engineers may employ differently, such as the duration of the subscription before a watcher marks a user “away” or “offline.” Even mapping of graphical “emoticons” between IM systems needs to be defined. The SIP Forum’s IP PBX / Service Provider Interop Task Group provides a precedent for creating such recommendations, since early deployments of SIP VoIP to service providers experienced implementation complexities. That said, the IM federation model is less complicated and should take less time, since there are fewer players in the enterprise IM space than in the VoIP space, and the interconnection requirements are more straightforward. Nonetheless, standards outlining authentication requirements, TLS rules, and so forth would speed adoption.

Moreover, agreements between federation providers would make a large-scale federated IM model more feasible. If Company A federates with Provider 1, Company B federates with Provider 2, and the two companies want to share IM and presence, then both would benefit if Providers 1 and 2 were federated. Otherwise, enterprises may end up peering with one another as the standards mature and their security and management tools improve.

Summary

Enterprises should consider the risks versus rewards of using public IM services and move towards a standards-based enterprise IM system as required by security and corporate policy. Using a system based on SIMPLE provides other integration benefits, like being able to view the on-hook/off-hook phone status presence of buddies using the enterprise IP PBX and making an informed decision on whether to call or IM.

While IM and its underlying standards are mature, the options for controlling connectivity between enterprises and the outside world are new. Federated service providers are leveraging standards to provide enterprises with options to securely interconnect with other enterprises, partners, and public IM networks. Instead of peering with one another, enterprises peer with the service provider, who handles any protocol conversion, implements the enterprise’s desired policy, and manages security rules. This model should speed the time to IM federation; soon enterprises will benefit from exposing their IM systems to the outside world for customer contact center, supply chain, and other creative communication applications.