In the last blog about Standards, I provided a simple overview of what SIMPLE is. Here I dive more into the presence aspect of the SIMPLE standards.
A Simplified View of the Presence Model.
The requirements for a presence infrastructure are defined in Instant Messaging / Presence Protocol Requirements (RFC 2779). The presence model was originally introduced by A Model for Presence and Instant Messaging (RFC 2778) and later refined by a set of RFCs in the SIMPLE charter. The model and terminologies I used here are simplified from these RFCs to make them easier to understand.
Presence, as known as Presence Information, conveys the the capability, availability, and willingness of a user to communicate with others over the network.
Presentity is an entity that provides Presence. In a simplified view, the user that provides the Presence is the Presentity.
Watcher is an entity that requests Presence about a Presentity. In a simplified view, the user that requests the Presence is the Watcher.
Presence Server is a service that accepts the Presence from Presentity, stores the Presence, and distributes the Presence to Watchers.
In the RFCs in SIMPLE charter, the above model is actually broken into more finer grain entities. Although the fundamental idea of a presence model is illustrated above, don’t be surprised to see a lot more terminologies used in those RFCs.
Presence Trilogy – SUBSCRIBE, PUBLISH, and NOTIFY
In SIMPLE, the mechanism for a Presence Server to collect and distribute the Presence is based on SIP Event Notification (RFC 3265), SIP Event Publication (RFC 3903), and A Presence Event Package for SIP (RFC 3856).
A Watcher requests the Presence about a Presentity by sending SIP SUBSCRIBE requests to the Presence Server. For example,
SUBSCRIBE sip:presentity@voxeo.com SIP/2.0
To: <sip:presentity@voxeo.com>
From: <sip:watcher@voxeo.com>;tag=xfg9
Event: presence
Accept: application/pidf+xml
Expires: 3600
Content-Length: 0
A Presentity provides its Presence by sending SIP PUBLISH requests to the Presence Server. For example,
PUBLISH sip:presentity@voxeo.com SIP/2.0
To: <sip:presentity@voxeo.com>
From: <sip:presentity@voxeo.com>;tag=1234wxyz
Expires: 3600
Event: presence
Content-Type: application/pidf+xml
... the presence information ...
The Presence Server distributes the Presence by sending SIP NOTIFY requests to Watchers. For example,
NOTIFY sip:watcher@voxeo.com SIP/2.0
From: <sip:presentity@voxeo.com>;tag=ffd2
To: <sip:watcher@voxeo.com>;tag=xfg9
Event: presence
Subscription-State: active;expires=3599
Content-Type: application/pidf+xml
... the presence information ...
Please note the above sample messages omit some common headers such as Call-ID, CSeq, etc. A couple of new headers are worth further discussion here.
- Event: RFC 3265 defines this header to indicate the name of the event package (i.e. the even type). All SUBSCRIBE, PUBLISH and NOTIFY requests must include this header. For presence, the value is always “presence”, as defined in RFC 3856.
- Subscription-State: RFC 3265 defines this header to indicate the status of the subscription associated with the NOTIFY request.
Also note the “application/pidf+xml” value in both Accept and Content-Type header. This value is the MIME type of a data format for describing the presence information in the requests, as discussed in the next section.
The Data Format for Presence
Now we know how the Presence is collected and distributed. But how do we describe the capability, availability, and willingness to communicate?
Presence Information Data Format (RFC 3863) and its extensions are used to describe the Presence in SIMPLE.
PIDF is an XML format (hence the “application/pidf+xml” MIME type name) that defines the framework and a minimal but extensible set of elements to express the Presence. Here is a very simple PIDF XML.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:presentity@voxeo.com">
<tuple id="sg89ae">
<status><basic>open</basic></status>
</tuple>
</presence>
The basic PIDF is quite simple. The root element is <presence> with a required entity attribute. The value of the entity attribute is the URI of the Presentity to which the Presence belongs.
Under the root element, there are one or more <tuple> elements, called Presence Tuple. Presence Tuple is a way to segment the Presence. For example, a user might have multiple devices, such as laptop and cellphone. Each Presence Tuple can describe the capability, availability, and willingness to communicate on each device respectively. The required id attribute is an XML ID to distinguish the <tuple> elements within the XML.
Each <tuple> element must have a <status> element to describe the Presentity’s availability or willingness to communicate. RFC 3863 only defines two basic statuses – open and closed.
Although the PIDF defined in RFC 3863 is quite simple, it is a very extensible and flexible framework to aggregate different presence information. Here are some of the PIDF extensions.
Watch the Watchers
Now we know how a Watcher can track the Presence of a Presentity. Can a Presentity know what Watchers are watching its Presence?
A Presentity can watch the Watchers using the same SIP Event Notification (RFC 3265) mechanism with A Watcher Information Event Package (RFC 3857).
A Presentity requests to be notified about “presence” subscription by sending SIP SUBSCRIBE requests to the Presence Server. For example,
SUBSCRIBE sip:presentity@voxeo.com SIP/2.0
From: <sip:presentity@voxeo.com>;tag=123s8a
To: <sip:presentity@voxeo.com>
Event: presence.winfo
When a Watcher subscribes to the Presence of this Presentity, the Presence Server will notify the Presentity by sending SIP NOTIFY requests to the Presentity. For example,
NOTIFY sip:presentity@voxeo.com SIP/2.0
From: <sip:presentity@voxeo.com>;tag=xyzygg
To: <sip:presentity@voxeo.com>;tag=123aa9
Event: presence.winfo
Subscription-State: active
Content-Type: application/watcherinfo+xml
... the watcher information ...
Please note the event type is “presence.winfo”, defined by RFC 3857. And the Content-Type is “application/watcherinfo+xml”.
Similar to the “application/pidf+xm”, the “application/watcherinfo+xml” is the MIME type for an XML format to describe the Watcher information, defined in XML Based Format for Watcher Information (RFC 3858). Here is a sample Watcher information.
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="0" state="full">
<watcher-list resource="sip:presentity@voxoe.com" package="presence">
<watcher id="77ajsyy76" event="subscribe" status="pending">sip:watcher@voxeo.com</watcher>
</watcher-list>
</watcherinfo>
This Watcher information basically tells the Presentity that a Watcher “sip:watcher@voxeo.com” wants to subscribe to its Presence and the subscription is pending for approval.
How can a Presentity approve or reject the subscription? In SIMPLE, this is done via XML Configuration Access Protocol (XCAP), which I will talk about in future blogs.
What does Presence do for VoIP, or MoIP?
The Internet has made the communication and collaboration easier than ever. With IP communication moves beyond just voice into multimedia (MoIP), rich presence information becomes essential for people to indicate when, how, and if they want to be contacted.
Here is an example how a cartoon can show the Presentity’s audio, video, IM capability and its current time, location, availability and willingness to communicate through these capabilities.
This kind of rich presence information helps people to easily identify when and how they should communicate, especially in a multi-party and multi-device collaboration environment.
This week I am up in Minneapolis, Minnesota, at 
RSS Feed
