Chapter 19 - The Presence Service on the Internet pdf

Chapter 19

The Presence Service on the

Internet

Presence is one of those basic services that, day by day, is becoming omnipresent. On the one

hand, the presence service is able to provide an extensive customized amount of information

about a given user to a set of users. On the other hand, third-party services are able to read

and understand presence information, so that the service provided to the user is modified

(actually, we should say customized) according to the user’s needs and preferences expressed

in the presence information.

19.1 Overview of the Presence Service

Presence is the service that allows a user to be informed about the reachability, availability,

and willingness of communication with another user. The presence service is able to indicate

whether other users are online or not, and if they are online, whether they are idle or busy

(e.g., attending a meeting or engaged in a phone call). In addition, the presence service allows

users to give details of their communication means and capabilities (e.g., whether they have

audio, video, instant messaging, etc., capabilities and in which terminal those capabilities are

present).

The presence framework defines various roles, as shown in Figure 19.1. The person who

is providing presence information to the presence service is called a presence entity, or for

short, a presentity. In Figure 19.1 Alice plays the role of a presentity. The presentity is

supplying presence information (i.e., the set of attributes that characterize the properties of a

presentity, such as status, capabilities, communication address, etc.). A given presentity has

several devices known as Presence User Agents (PUAs) which provide information about her

presence.

Figure 19.1 shows three PUAs: an IMS terminal, a laptop, and a desktop computer. Each

has a piece of information about Alice, the presentity. The laptop knows whether Alice is

logged on or not, as does the desktop computer. The IMS terminal knows Alice’s registration

status and whether she is engaged in any type of communication. They can have even richer

presence information, such as what time Alice will be back from lunch, whether Alice is

available for videoconferences, or whether she only wants to receive voice calls right now.

All of the PUAs send their pieces of information to a Presence Agent (PA). The PA gathers

all of the information received and obtains a complete picture of Alice’s presence.

ıa- ´ Martın´

The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition

Gonzalo Camarillo and Miguel A. Garc

© 2008 John Wiley & Sons, Ltd. ISBN: 978- 0- 470- 51662- 1

406 CHAPTER 19. THE PRESENCE SERVICE ON THE INTERNET

Figure 19.1: SIP presence architecture

A Presence Agent can be an integral part of a Presence Server (PS). A PS is a functional

entity that acts as either a PA or as a proxy server for SUBSCRIBE requests. The term

Presence Server is often used to refer to a PA. While both are quite similar in functionality,

PSs also act as proxy servers for SUBSCRIBE request, while PAs do not.

Figure 19.1 also shows two watchers: Bob and Cynthia. A watcher is an entity that

requests (from the PA) presence information about a presentity. There are several types of

watchers. A fetcher is a watcher that retrieves the current presentity’s presence information

from the PA. A subscribed watcher asks to be notified about future changes in the presentity’s

presence information, so that the subscribed watcher has an accurate updated view of the

presentity’s presence information.

Typically, applications combine the watcher and presentity functionalities in a single

piece of software, thus hiding the functional distinction of presence publication from presence

information acquisition by the end-user. However, since both functions are different and

governed by different procedures we treat them separately.

The presence service is a particular application built on top of the SIP event notification

framework (we described the SIP event notification framework in Section 4.15). The

framework allows a watcher to subscribe to or fetch (using a SIP SUBSCRIBE transaction)

the presentity’s presence information. The subscription state is kept in the presentity’s PA,

which acts as a notifier (according to the SIP event notification framework). The PA notifies

(using SIP NOTIFY transactions) all of the subscribed watchers when a change has occurred

in the presentity’s presence information.

All SUBSCRIBE/NOTIFY transactions contain a SIP Event header field that identifies

the actual event the subscription or notification is related to. RFC 3856 [268] defines the

“presence” event package identified by the value presence in the Event header field of

SUBSCRIBE and NOTIFY requests.

NOTIFY requests usually contain a MIME body that indicates the presentity’s presence

information. This body is an XML document formatted according to certain rules. Since the

presentity’s presence information is carried in an XML document, which is highly extensible,

then it is easy to extend the presence information with all sorts of imaginable bells and

19.2. THE PRESENCE LIFE CYCLE 407

whistles. The fact that presence information is not carried directly in SIP, but in XML

documents that are transported in SIP, provides a clear separation between the transport

protocol layer (SIP) and the application protocol layer (XML documents containing presence

information).

19.1.1 The pres URI

Traditionally, Internet technologies have used URIs to identify resources that can be accessed

with a protocol (e.g., sip, http, and ftp URIs) or are associated to functionality (e.g., tel and

mailto URIs). Presence defines (in RFC 3859 [248]) a pres URI for identifying a presentity

or a watcher. It must be noted that the pres URI is protocol-agnostic: therefore, there is no

information indicated in the URI on how to access the resource. However, when SIP is used

to access presence resources it is recommended to use sip or sips URIs as they are protocol￾specific.

The syntax of the pres URI is

PRES-URI = "pres:" [ to ] [ headers ]

to = mailbox

headers = "?" header *( "&" header )

header = hname "=" hvalue

hname = *uric

hvalue = *uric

An example of a pres URI is

pres:[email protected]

A pres URI can replace a sip URI in any header field where a sip URI can be present,

such as From, To, Route, Record-Route header fields and the Request-URI. It might be

used in exceptional cases when a gateway from SIP to another protocol is involved. In typical

scenarios only sip and sips URIs are used.

19.2 The Presence Life Cycle

As if it were a product, the presentity’s supplied presence information has a life cycle.

During its life cycle the presence information suffers a number of transformations, from its

creation phase to its shipping and handling, storage, and the final delivery phase to consumers

(watchers, in the case of presence).

Figure 19.2 shows a schematic representation of the first part of the life cycle of the

presence information A presentity (on the left-hand side of the figure), has some presence

information to publish. The actual presence information varies slightly depending on which

PUA the presentity is using. There can be several PUAs supplying different presence

information, such as a computer, a mobile phone, and a fixed phone. For example, the

presentity might be away from the keyboard of the computer, but engaged in a call on her

mobile phone, so these details are reflected in their presence information.

At some point in time each of these PUAs will send a SIP PUBLISH request containing

their view of the presentity’s presence information in a presence document. This is the

presence publication process, which is described in Section 19.4. The presence document,

received at the PA, is fed into the merging process. The merging process, governed by