Peering Outside: Federating Presence

By J.D Rosenberg, COLUMNS: Speaking SIP

Presence. When I say that word to folks outside our industry, they think I’m talking about the stuff you get during the holiday season that’s wrapped in shiny paper and bows. Just a few years ago, even folks within the VoIP or telecom industries hadn’t heard of presence. Now, it’s a common part of the lingo of modern telecommunications. In case you haven’t heard of it, presence refers to someone’s ability, willingness and desire to communicate across different devices, modalities and services. The simplest manifestation of presence is the traditional “buddy list,” such as the ones provided by Yahoo, AOL and MSN. In those applications, presence shows up as those icons and status messages that say something about your ability and desire to receive instant messages.

Instant messaging is just the beginning, though. I can also be reached on my desk phone, my home phone, my cell phone, through email (at multiple addresses), through pushto- talk services, through the postal service and, of course, face to face. With so many modalities, it becomes hard for someone to figure out when I should be contacted, and how. That’s where presence comes in. Presence tells other people about all of the ways I can be reached and gives them clues about how and when I can best be reached. Presence helps bring order to the mess of modern communications. It makes the experience richer and facilitates more frequent and more effective communications. That has value to end users and the service providers that offer it.

Unfortunately, presence exists in islands. Subscribers of one provider cannot see the presence of subscribers of other providers, unless they obtain identities and clients for each of those providers. Worse still, enterprises that deploy presence systems see only the presence of other users within the same enterprise. Presence is particularly valuable in the enterprise. At work, communicating effectively is important. Everyone is busy, and getting the most out of your day means quickly connecting with the people you need to connect with and moving on. For example, when I have a question that can be quickly answered by any one of a number of people, I quickly scan my buddy list, see who is online, and shoot that person an instant message. I get a response, and I’m done. Presence helped me choose whom to contact. Without it, I would have had to call people randomly or email them randomly, and most of those attempts would have been wasted.

My business contacts don’t end at the front door of my office building. I, like many others, have colleagues and customers at other enterprises with whom I interact. Communications with those contacts is even more valuable. They have less time for me than for their own internal colleagues, and the information they provide is also usually more valuable. For this reason, being able to see their presence would be even more useful than seeing the presence of people within my own enterprise.

So why doesn’t it work? What makes it difficult to extend presence outside the boundaries of an enterprise? Why can’t we federate?

There are many challenges. One of the biggest ones is scale. Presence generates a LOT of traffic. Consider two large enterprises, each with 100,000 employees. Each of those employees has a buddy list of 50 people, 10 of whom are in the other enterprise. Each user changes his or her presence state 10 times a day. This results in 1 million subscriptions reaching between the two enterprises, generating 10 million notifications a day, or 347 notifications per second. These numbers are one to two orders of magnitude larger than the typical call volume between enterprises of this size. The problem gets even worse for extremely large service providers whose subscribers number in the millions; internetwork notification rates there can be measured in the tens of thousands per second.

Security is another challenge. How do enterprises make sure that only authorized recipients can get and see the presence data? How do they make sure that their presence systems don’t get used for launching denial-of-service attacks? Those kinds of problems are not specific to presence systems, but the scale of these systems makes them more attractive targets.

The final challenge is making the value proposition clear. Many enterprises still don’t utilize presence and IM systems at all, many actively block it, and even more have users who make use of consumer systems without the approval or support of IT departments. Presence and IM have yet to catch up to voice and email as recognized essential tools for today’s information worker. However, it’s just a matter of time. Once they have caught up, unfederated presence will look as antiquated as email or voice systems that don’t work outside the enterprise. I look forward to that day.

Jonathan Rosenberg is co-author of the original SIP specification (RFC 3261). He is currently a Cisco (quote - news - alert) Fellow and Director of VoIP Service Provider Architecture for the Broadband Subscriber Applications Business Unit in the Voice Technology Group at Cisco Systems.