Presence Functionality
Presence Functionality by Don Van Doren
The concept of presence is one of the foundation elements of Unified Communications. Every aspect of collaboration requires, or at least is enhanced by, an understanding of whether and how a colleague is available for a communication, and how that availability varies based on specific circumstances such as who is trying to contact whom and for what purpose.
Presence has to be much much more than what we currently get with IM. A powerful presence server will be needed to collect, store, and pass along presence information about users to selected audiences, depending on the business needs – where, how, and under what conditions a specific user can be contacted. Most of the suppliers have announced plans for a presence server that will make this information available, with varying degrees of functionality.
But for presence to be effective, it will have to work in a multivendor environment. This will generally be true if users are just trying to get presence information within their own company. It will certainly be required if we are going to extend presence awareness across company boundaries.
To accommodate this requirement, vendors have made vague references to largely undefined “federation” capabilities that will allow sharing of information between different presence devices. A key challenge is how open the federation schemes really are.
Beyond those issues, here are a few desirable presence requirements, built around my needs:
1. I must be able to set some broad parameters in the system for who can interrupt what sort of activities I might be engaged in. Also, what devices do I have access to in which circumstances. This should be a setup step with only occasional modification. But, when it needs to be modified, this must be intuitively easy for me to do. The suppliers can help by providing some common templates representing typical job types, that can readily be customized.
2. Current status information has to be as automatic as possible, without requiring me to go in and set my status manually whenever I change tasks or locations. This means communicating and integrating information from a variety of devices – telephone systems indicate that I’m talking on the phone or cell; my desktop applications notify the server that I’m actively working on a document; and maybe my car or GPS-capable cell phone tells the server that I’m driving 75mph on I-80.
3. My information, stored on a presence server, has to be available across applications and across devices from different suppliers.
4. The presence server has to collect and track all this status data for each user, then figure out how to display different information to different people in real time. There will be different information communicated based on the inquiry – someone known or unknown in my company? Someone external I have identified? Or someone unknown, from a known or unknown location? That is, my boss will see different availability and access information for me than a co-worker or a business partner in another company.
5. Finally, overlaying all this, are security and privacy issues. What are appropriate safeguards in what circumstances? And, does this open up new cans of worms for regulatory provisions (e.g., HIPAA) or legal discovery proceedings?
In the near term, we are likely to see multiple presence servers linked in some way with some federation capabilities emerging. But it’s pretty clear that the five requirements listed above aren’t likely to be fully functional coming out of the gates. We need much better presence capabilities than have generally been talked about through all these initial announcements.
Achieving what’s really needed in presence is going to make the CTI challenges of a decade or two ago seem like child’s play. To help overcome these hurdles, there needs to be some common industry thinking and standards about how best to promote a uniform way to collect, describe, and transmit needed presence information. Perhaps, as the Internet Engineering Task Force (www.ietf.org) polishes off SIP standards, they can consider this even thornier problem!
In any case, the industry needs to put in place a way for dialog to develop among the vendors to solve these issues. Certainly, www.UCStragegies.com will be a resource for the discussion. VOIPLoop, VoiceCon and BCR will also continue as focal points for the dialog. And, as an enterprise communications consultancy, Vanguard Communications (www.vanguard.net) will bring customer requirements to the conversation. All of this will be aimed at ways that we can get the vendors together to begin this process.
Meanwhile, we’ll continue to highlight the successful uses of the Presence functionality that exists today, since the payoff from those applications will provide justification for increased investment and improved functionality.