Presence - Where are you now?

Depending on who you ask, 'Presence' is either the 'The Fact or Condition of Being Present' or the seventh studio album by Led Zeppelin.

A more useful definition in our industry is 'A Status Indicator that Conveys Ability and Willingness of a Potential Communication'

The introduction of 'Presence' as part of our new and exciting communications landscape has presented us with a more deterministic method of communicating, i.e. by having a reasonably good idea about the availability of the intended parties.

With such widespread use of Skype (for instance), instant messaging and presence have become a comfortable addition to email, video and audio communication. Mainstream vendors of PBX's have also been quick to appreciate the attractiveness of such a feature, particularly as part of a more unified communications approach.

What makes the topic of interest from a convergence technology perspective is the emergence of mechanisms that can accommodate Multiple Points of Presence (MPOP) from an individual and/or the ability to join different presence domains together.

Sounds exciting, though note that widespread use of instant messaging and presence are still more likely to be using non-enterprise solutions such as skype.

Is there are ROI Justification?

Ignoring for the moment any security considerations, the use of free services from the likes of Skype, AIM, Yahoo MSN and Gmail have proliferated both at home and in the enterprise (until the IT Manager steps in); so in essence, people clearly derive some obvious benefit from these services when translated into the workplace. With Presence and Instant Messaging working hand-in-hand the reduction in mobile calls and text soon mount up, but more significantly does the time that would otherwise be wasted calling people that aren't available.

And Multiples of Presence (MPOP)

A logical extension to the notion of presence is to consider the amalgamation of a number of devices that can report on a single individuals 'status'. For instance, rather than just the PC, the communication channels can consider additional devices such as Desk or mobile phones and even individual applications on the desktop.

The presence server will then aggregate all these presence indicators as 'Multiple Point of Presence' and decide a logical status in terms of availability for the individual. In practice this can take the form of having oncoming messages delivered to the device most likely to respond; for example, by having incoming email routed to mobile text when encountering an 'out-of-office' message. This situation also lends itself to circumstances where the individual can log-in to multiple devices over an extended period of time; the presence server then judging the true availability status by noting event changes across these devices – I.e logged in/out, period of activity/inactivity etc.

The extended logic would define a series of priorities for each of these communication modes such that incoming messages get routed to the 'most available' and 'highest priority' channel first.

A good example of MPOP in action is Microsoft's OCS2007 which combines status information (they use the term sensors) from the user state, the machine state, calender information and the persons phone – all put together by an ‘aggregation script’ resulting in a single unified view of the user’s state.

The enterprise market has quickly followed suite with a range of solutions, a representative cross section being:

• IBM - WebSphere Presence Server/Lotus Sametime 7.5
• Mitel - IP Communications Platform
• Nortel - Applications Server 5200
• Open source - SIPFoundry/Asterisk etc
• Avaya -Intelligent Presence Sever (multi-party)
• Siemens - OpenScape UC server
• Cisco - Cisco Unified Presence
• Microsoft - OCS 2007

However, for presence servers to thrive, they need also to consider operating in a multi vendor environment, especially when being used across company boundaries; hence the need for formalized protocols

The Development of Protocols

In 1999 a group called the Instant message and Presence Protocol (IMPP) working group was formed within the Internet Engineering Task Force (IETF) to develop some formats and protocols for the emerging Instant Messaging and Presence services. Whilst not able to define a single protocol, the group were able to provide a common profile which could be adopted by ‘presence services’ in order to cooperate; known as CPP – the common profile for presence and instant messaging. We look at presence…today.

SIMPLE

Two years later, the IETF had another go, this time via what we now know as the ubiquitous Session Initiation Protocol (SIP). Problem was, despite having the acronym SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions), it was anything but… the working group describes its focus as
“…. the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Profile for Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard”

In essence, the SIMPLE presence specifications can be broken up into:

• The core protocol machinery, which provides the actual SIP extensions for subscriptions, notifications and publications
• Presence documents, which are XML documents that provide for rich presence and are carried by the core protocol machinery

Core Protocol:

The SUBSCRIBE and NOTIFY methods within SIP are used as Event Notifications, Presence is defined as an Event Package in the same way that other Event Packages exist, such message waiting etc. Through these packages, a SIP user agent can be asked to be notified of the state of another entity. The terminology used to describe the contents of the response messages are described as ‘presence documents’. The specifications also deal with the notion of a user agent subscribing to multiple resources lists, in effect creating ‘buddy lists’ without having to subscribe to each individually. The user agent can then publish its own status via a presence event package and have the service send a notification to all parties.

Presence Documents

The content of these event notification on documents (SIP Notify) is where we convey the status of the entity, created using the Extendible Markup Language (XML); the contents have evolved from the most basic communications status (open/closed), to adding the difference between device and person and then to defining moods, places and even future presence information so that availability cab be predicted. These documents can also advertise the type of communications method supported.

Privacy and Policy

The need for a user’s privacy to be maintained is accomplished through the use of an individual policy document that gets uploaded on to the presence server. In it, the user gets to define what type if information the ‘watcher’ is allowed to see. It includes the notion of conditions, action and transformations regarding sensitive data. The existence of a watcher event package allows the user to be notified if a watcher is attempting to subscribe to their presence and to allow or deny the request.

Provisioning

The presence server requires the user to manage both their buddy lists and privacy documents in order to run correctly. This is achieved using XML Configuration Access Protocol, (XCAP); a use of HTTP by which user can manipulate their policy documents on the server, (i.e. modify buddy lists etc). An extension to the SIP user agent configuration profiles allows a user to earn about to changes to their own docs, for instance if someone else make a modification to a buddy list.

And XMPP

An alternative to SIMPLE is the Extensible Messaging and Presence Protocol (XMPP) which is really a formalization of the core XML streaming protocols; developed by the Jabber open source community and current used by the commercial version of Google Talk.

Mechanisms to cooperate between such implementations can exist through the use of gateways employing the Common Profile for Presence (CPP) specifications to define the common formats into which the protocols are translated. Proponents of XMPP rather than SIMPLE contend that an XML-based data-transport technology is better suited than a signalling technology to handle IM and presence.

Presence clearly has a big future and any Unified Communication solutions that ignored that simple fact would do so at it's peril.