Modern instant messaging started with networks like ICQ and AIM which were cut off from each other - users of one network could not send messages to users of another or add them to their buddy lists. Enterprise IM systems are very similar: out of the box, an enterprise IM system only allows messaging and presence information to be sent to other users within that enterprise.

This makes its usefulness rather limited, like internal phone systems which aren't connected to the outside. (You could argue that the fact that enterprise IM systems are closed is a strength rather than a weakness because if they are closed then viruses and spam can't come, making them more secure and less intrusive. But it's a strange kind of communication system that makes a virtue of its lack of connectivity.)

In most cases, then, it's desirable to enable enterprise IM users to exchange messages and presence information with people outside the organization - either to a closed set of users such as those at a partner company, or to one or all of the big public IM networks.

One way this can be done is by domain federation. "SIP/SIMPLE (define) uses an e-mail address type of identifier, and that's crucial as the domain of the SIP address identifies the IM service," says Nick Shelness, a senior analyst at Ferris Research. "The end point uses the DNS and looks for the ID of the SIP server for that domain. With e-mail, you can send an e-mail to "fred" and it will go to that username at the same domain. When two SIP/SIMPLE domains federate with each other, it's as if they are the same domain, and presence is tracked totally and instant messages flow totally within them," he says. "In effect there are two domains but a single service running across them."

So what happens when federation takes place? "The way that presence works in instant messaging systems is either that a client polls for changes in a user's status, or it subscribes to changes," says Shelness. "Federated IM domains are those domains that accept subscriptions from each other and accept results. Of course an assumption is made that you can't subscribe unless an agreement is explicit between domains," he says.

Using LCS 2005, for example, direct federation with up to 300 other partners is supported, but to simplify matters it's also possible to use a clearing house topology to communicate with a community of partner companies or an industry group of suppliers, manufacturers, distributors and so on. A proxy can also be used to connect to branch offices that are not within the organization's internal SIP domain.

With the public networks the situation is a bit different. AOL's Enterprise Federation Program, for example, involves a proprietary federation gateway which routes messages and translates between AOL's proprietary protocol and the SIP/SIMPLE or XMPP used by various enterprise IM systems including LCS 2005, SameTime and systems from Jabber Inc. And whereas two partner organizations can federate their IM systems for free (ignoring the cost of carrying out the behind-the-scenes work), companies usually have to pay additional license fees if they want to federate with the big public networks.

Servers based on XMPP (frequently referred to as the "Jabber Protocol") (define) don't need formal federation agreements with other XMPP servers (including IM networks like GoogleTalk which run on XMPP) since XMPP is by its nature open in the way that e-mail is. Some XMPP systems like the latest release of Jabber Inc.'s Jabber XCP can federate with SIP/SIMPLE based enterprise systems like SameTime and LCS.

To connect to closed public networks like AIM or MSN the alternative to formal federation agreements for Jabber users is to utilize public IM network gateways or transports running on a Jabber server. When a user registers with a transport to a network on a particular Jabber server, they supply a username and password for the network they want to access. In effect, they are logged on to that network, and the presence information and buddy lists are translated (if the protocol is different) and sent back to the Jabber client. Messages between the two networks go through the gateway and on to their destinations. Open source Jabber transports exist for AIM (and ICQ,) MSN, and Yahoo! networks.

There are some disadvantages with this approach: a user has to find the transport they need on a Jabber server somewhere - though they don't have to change their "home server" which their account is registered on if the transports they need aren't available on it. And since these transports are unofficial, they will only work as long as the protocols used by the public networks aren't changed. Each time this happens, the transports need to be modified - though this hasn't been too common in recent years. And of course, it's necessary to have an account on each of these networks in order to use them. On the plus side though, transports are free.

Federation or transports - one thing is clear: enterprise and public networks have become more interoperable than ever, and this trend looks certain to continue. After all, what use is a messaging system if its communications abilities are severely limited?

Source:  http://www.instantmessagingplanet.com/enterprise/article.php/3662351