Figure 8.2 Presence architecture.

8.3 SIMPLE

In 2001, the IETF chartered a new working group to develop SIP standards and extensions for instant messaging and presence. Over the years, a set of specifications and protocols have been developed, with a few still under development. The standards for presence are summarized in Table 8.3. An overview specification is known as “SIMPLE made simple” [3], which describes how all these protocols work together.

8.4 Presence with SIMPLE

This section will cover presence with SIMPLE. The specifications are summarized in Tables 8.3 and 8.4.

8.4.1SIP Events Framework

The SIP events framework was defined in RFC 3265 which defined the SUBSCRIBE and NOTIFY methods, as described in Sections 4.1.7 and 4.1.8. SUBSCRIBE is used to establish a dialog and ongoing association between two UAs. In the presence architecture of Figure 8.2, the watcher sends the SUBSCRIBE request to the presentity. If the subscription is authorized, the presentity will send NOTIFYs whenever the state of the presentity changes, and at regular intervals. The basic call flow was shown in Figure 4.5.

<?xml version=”1.0” encoding=”UTF-8”?> <presence xmlns=”urn:ietf:params:xml:ns:pidf”

entity=”pres:Sophie.Germain@mathematica.org”> <tuple id=”34g45sfde”>

<status>

<basic>open</basic>

</status>

<contact>sip:sophie@78.34.32.1:51234</contact>

</tuple>

</presence>

The XML document begins with the XML declaration, then the presentity information is contained in the <presence> element. The presence information is that of the entity listed in the entity attribute. Presence documents consist of <tuple> elements, which contain the <status> of the presentity and can be either open (available) or closed (unavailable). In addition, this example shows <contact> information. Presence information is conveyed in a SIP message us-

ing the Content-Type: application/pidf+xml. Note that this Content-Type is

also sometimes incorrectly written as application/cpim-pidf+xml.

The next example shows the inclusion of both contact information (Contact Information Presence Information Data or CIPID) [11], UA capabilities [19] , and the presence data model [12]:

<?xml version=”1.0” encoding=”UTF-8”?> <presence xmlns=”urn:ietf:params:xml:ns:pidf”

xmlns:dm=”urn:ietf:params:xml:ns:pidf:data-model” xmlns:cipid=”urn:ietf:params:xml:ns:pidf:cipid” xmlns:caps=”urn:ietf:params:xml:ns:pidf:caps” entity=”pres:m.c.thomas@brynmawr.edu”>

<tuple id=”54234g45sfde”> <status> <basic>open</basic> </status>

<contact>sip:mc@dean.brynmawr.edu</contact>

<caps:servcaps>

<caps:audio>true</caps:audio>

<caps:video>true</caps:video>

</caps:servcaps>

</tuple>

<dm:person id=”1”> <cipid:card>http://brynmawr.edu/~m.c.thomas/card.vcd</c:card> <cipid:display-name>M. C. Thomas</c:card>

</dm:person>

</presence>

This document defines a default namespace plus three other extension namespaces, dm, cipid, and caps. This example shows that the capabilities of the UA identified by the <contact> element include both audio and video, as indicated by the <audio> and <video> subelements of <servcaps>. The data model element <person> is used to provide personal information about the contact entity, and includes the contact information including a vcard, display name, homepage, icon, and map. The next example shows Rich Presence Information Data (RIPD) [10]:

<?xml version=”1.0” encoding=”UTF-8”?> <presence xmlns=”urn:ietf:params:xml:ns:pidf”

xmlns:rpid=”urn:ietf:params:xml:ns:pidf:rpid”

entity=”sip:skovalevsky@su.se”> <tuple id=”4sdf432sd”>

<status>

<basic>closed</basic>

</status>

<rpid:class>IM</rpid:class>

<contact>im:skovalesky@su.se</contact>

</tuple>

<tuple id=”832thr76jk”> <status>

<basic>open</basic>

</status>

<rpid:class>voice</rpid:class>

<contact>tel:+465551212</contact>

</tuple>

</presence>

8.4.3Resource Lists

Resource lists allow a UA to combine multiple individual subscriptions into a single subscription and receive notifications about multiple individual subscriptions in a single notification message. Resource lists are defined in RFC 4662 [13] and are an extension to the SIP events framework [4]. As such, resource lists can be used with any event package. However, the most common use is for subscriptions to a “buddy list” in presence applications. In this application, a contact list or “buddy list” is represented by a SIP URI and stored in a server

known as a resource list server or RLS. For example, if a user’s contact list contained 10 SIP URIs, this would normally require 10 separate subscriptions to be maintained, one for each URI in the list. Each of these subscriptions would need to be created, managed, and refreshed, resulting in a lot of overhead traffic messages. With the resource list extension, the list is stored in the RLS, and the presence client creates a single subscription to the RLS over which notifications of the presence of all 10 URIs would be sent. The RLS may need to initiate 10 separate subscriptions, but not the presence UA. An example event list subscription is shown here:

SUBSCRIBE sip:beatrix-321223@lakesdistrict.co.uk SIP/2.0 Via: SIP/2.0/TCP cottage43.lakesdistrict.co.uk:5060 ;branch=z9hG4bKwYb6QREiCL

Max-Forwards: 70

To: <sip:beatrix-321223@lakesdistrict.co.uk>

From: Beatrix Potter <sip:beatrix@lakesdistrict.co.uk> ;tag=6733

Call-ID: dkfj39890wssdfj2938d7 CSeq: 23822 SUBSCRIBE

Contact: <sip:beatrix@cottage.lakesdistrict.co.uk; transport=tcp>

Ev ent: presence Expires: 7200 Supported: eventlist

Accept: application/pidf+xml Accept: application/rlmi+xml Accept: multipart/related Content-Length: 0

In this subscription, the presence of the Supported: eventlist header field indicates that the presence UA supports the extension. The Accept: application/ rlmi+xml also indicates that it is willing to accept notifications that use the resource list format described in the next section. The Event: presence and Accept: application/pidf+xml are to indicate that the subscription is for presence information. A NOTIFY sent during this subscription might look like:

NOTIFY sip:beatrix@cottage43.lakesdistrict.co.uk SIP/2.0 Via: SIP/2.0/TCP pres.vancouver.example.com

;branch=z9hG4bKMgRenTETmm Max-Forwards: 70

From: <sip:beatrix-321223@lakesdistrict.co.uk>;tag=dkisksk3 To: Beatrix Potter <sip:beatrix@lakesdistrict.co.uk>

;tag=673

Call-ID: dkfj39890wssdfj2938d7 CSeq: 997935768 NOTIFY

Contact: <sip:rls34.lakesdistrict.co.uk> Event: presence

Subscription-State: active;expires=7200 Require: eventlist

Content-Type: multipart/related;type=”application/rlmi+xml” ;start=”<38dk2nXYxAE@lakesdistrict.co.uk>” ;boundary=”0909e3ksdf893”

Content-Length: 1560

The notification contains Require: eventlist, which indicates that this is an eventlist notification. The

related;type=”application/rlmi+xml” indicates that the message body is mul-

tipart MIME and contains application/rlmi+xml parts, which is the XML format for event lists defined in RFC 4662 [13]. Each part of the multipart MIME is separated by a CRLF and a boundary string, defined to be 0909e3ksdf893 in

this example. The Content-Type: application/pidf+xml;charset=”UTF-8” in

each part indicates that each part is a PIDF.

A resource list stored on an RLS is not a static list—the presence user may add or delete users from this list at any time. One way to do this is to use XCAP to manipulate the resource list. The format for this resource list is defined in RFC 4826 [16]. An example document is shown here:

<?xml version=”1.0” encoding=”UTF-8”?>

<rls-services xmlns=”urn:ietf:params:xml:ns:rls-services” xmlns:rl=”urn:ietf:params:xml:ns:resource-lists” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”> <service uri=”sip:astronomers@lists.org”>

<list name=”astronomers”>

<rl:entry uri=”sip:janet.taylor@observatory.com”/> <rl:entry uri=”sip:Maria.Kirch.Winkelmann@comets.r.us”/>

</list>

<packages>

<package>presence</package>

</packages>

</service> </rls-services>

The list is enclosed in a <rls-services> element where each <service> element defines a resource list. In this example, the event list URI is sip:marketing@ example.com as defined by the URI attribute to the <service> element. The list is included inside the <list> element.

Instead of using XCAP to create the list, the resource list subscribe extension [36] allows a SUBSCRIBE to create an event list. An example SUBSCRIBE is shown here:

SUBSCRIBE sip:beatrix-321223@lakesdistrict.co.uk SIP/2.0 Via: SIP/2.0/TCP cottage43.lakesdistrict.co.uk ;branch=z9hG4bKwYb6QREiCL

Max-Forwards: 70

To: <sip:beatrix-321223@lakesdistrict.co.uk>

From: Beatrix Potter <sip:beatrix@lakesdistrict.co.uk> ;tag=26

Call-ID: dkfj39890wssdfj2938d7 CSeq: 23822 SUBSCRIBE

Contact: <sip:beatrix@cottage43.lakesdistrict.co.uk;transport=tcp> Event: presence

Expires: 7200

Require: recipient-list-subscribe Supported: eventlist

Accept: application/pidf+xml

To: <sips:manya-friends@warszawa.pl>

From: Manya Sklodowska <sips:manya@warszawa.pl>;tag=22222 Call-ID: 7jh5dD3Fkifr2

CSeq: 3 SUBSCRIBE

Max-Forwards: 70 Event: presence Require: adhoclist

Accept: application/pidf+xml Accept: application/rlmi+xml Contact: <sips:manya@rs.warszawa.pl> Content-Type: application/adrl+xml Content-Length: ...

<?xml version=”1.0”?>

<adhoclist uri=”sip:manya-friends@warszawa” name=”Manya’s Friends”>

<add>

<resource

uri=”sips:hypatia@greatlibrary.alexandria.eg”> <resource uri=”sips:m.g.mayer@katowice.pl”> <resource uri=”sips:pan.chao@imperial.org”>

</add>

</adhoclist>

This subscribe adds three URIs in the <resource> element contained

in the <adhoclist> element. The Require: adhoclist and Content-Type:

application/adrl+xml indicate that this SUBSCRIBE is for an RLS that supports adhoc lists. A later refresh SUBSCRIBE could be used to add more URIs and delete others. For example:

SUBSCRIBE sips:manya-friends@warszawa.pl SIP/2.0 Via: SIP/2.0/TLS rs.warszawa.pl

;branch=z9hG4bKwYb6QREiCL

To: <sips:manya-friends@warszawa.pl>;tag=32111df

From: Manya Sklodowska <sips:manya@warszawa.pl>;tag=xz2d Call-ID: 7jh5dD3Fkifr2

CSeq: 34 SUBSCRIBE

Max-Forwards: 70 Event: presence Require: adhoclist

Accept: application/pidf+xml Accept: application/rlmi+xml Contact: <sips:manya@rs.warszawa.pl> Content-Type: application/adrl+xml Content-Length: ...

<?xml version=”1.0”?>

<adhoclist uri=”sip:manya-friends@warszawa” name=”Manya’s Friends”>

<add>

<resource uri=”sips:margaret_cavendish@dutchess.newcastle.gb”>

</add>

<delete>

<resource uri=”sips:m.g.mayer@katowice.pl”> </delete>

</adhoclist>