My last several posts have discussed various standard optimizations to the SIP Events mechanism. Another such optimization is the “Partial Notification” mechanism described in RFC 5263.

Unlike some of the previous optimizations that I have written about, partial notification is not designed for SIP Events in general. Instead, partial notification only works with the Presence event package. The reason for that should become apparent shortly.

In a SIP Presence system that doesn’t support partial notification, each time a presentity changes state, the presence server must send the full presence document to every watcher for that presentity. Given that presence documents can get large and complex, and that a presentity could have a large number of watchers, this can consume a fair amount of bandwidth. This could be particularly troublesome in mobile data networks, where bandwidth is relatively scarce–and potentially expensive to the end user.

With partial notification, rather than sending the entire presence document to each watcher, the presence agent only sends the parts of the presence document that actually changed. RFC 5262 describes a data format for expressing a “patch” or “diff” between two different versions of a presence document. This patch mechanism is specific to PIDF, the data format used to express presence information. (This is the reason that partial notify is specific to the presence event package.)

A user agent advertises support of partial notify by putting the diff format (“application/pidf-diff+xml”) in the Accept header field of a SUBSCRIBE request. Assuming the presence server also supports the partial notify, it can initially invoke the extension by using the pidf-diff format to send the entire presence document, along with a version number. When changes occur to the presence state, the presence server sends just those changes in a new pidf-diff document, along with an incremented version number. The pidf-diff format allows the presence server to include elements to be added to or removed from the presence state, as well as elements to replace existing ones.

When the user agent receives a partial notification, it compares the version number in the notification to the last version number it received. If the new version number is less than or equal to the old number, the user agent assumes an error, and ignores the change. If the new version skips a number since the last version, the user agent assumes it missed an update, and requests a full-state refresh. If the new version is exactly one more than old version, then the user agent applies the changes to its cached version of the presence document.

Like with any optimization, the designers of the partial notification extension made some assumptions. One is that changes to a presence document are usually smaller than the document itself. This a pretty safe assumption in presence systems that generate any but the most trivial presence documents.

They also assumed that the cost of the saved bandwidth between the presence server and the watchers’ user agents would be large compared to the cost of the added complexity at the presence server. This may not always be true, given that determining the difference between two large presence documents is anything but trivial. And if the presence server supports presence rules that can result in sending different presence state to one watcher than to another, for the same presentity, then the effort required to calculate the difference between documents may be multiplied by the number of watchers. This assumption is more likely to be true in mobile data networks (and in all fairness, partial notification was designed for mobile networks), where the cost of bandwidth is usually high compared to wireline services–although this might change with the deployment of 4G mobile data networks. 

The SIP Event Framework, defined in RFC 3265 , provides a way for SIP elements to learn when “something interesting” has happened somewhere else in the network.

A SIP element that wants to hear about these things SUBSCRIBEs to an event. That SUBSCRIBE will be routed to an appropriate SIP Events Server which will then send NOTIFY messages back to the subscriber whenever the “something interesting” being subscribed to happens.

This subscription model is an alternative to having elements periodically poll: asking repeatedly “did my interesting thing change yet?” For many applications, the subscription model has better traffic scaling characteristics than a polling model.

The SIP Events Framework requires that the meaning of “something interesting” be standardized in advance. Event Packages define what can be subscribed to, and what information will appear in the notifications. One of the first applications that drove the creation of the framework was Presence and there is a “presence” event package that allows watchers to subscribe to presence entities and receive new presence documents any time that presence changes.

There are around a dozen other event packages defined, including:

• the “refer” package used primarily to learn whether a transfer attempt has succeeded or not
• the “message-summary” package which allows someone to learn they have new messages at a service like a voice-mail server
• the “dialog” package which lets applications learn when endpoints initiate, accept, and terminate sessions. This package is used to realize features like automated-callback and directed call pickup.
• the “kpml” or Key Pad Markup Language package which lets an application learn when keys on an endpoint are pressed and released

The current set of standardized packages can be found at the sip-events namespace registry page at IANA.

Subscriptions are soft-state. They have to be periodically refreshed or they expire. Either the subscriber or the notifier can end the subscription at any time. The framework requires that the subscriber be authorized before actual event information will be sent (allowing you to control who sees your presence for example).

The framework allows the notifier to be any element in the network. The “presence” package, for example, supports both the model of a concentrated, centralized Presence Server that services all the subscriptions for a service, and a more peer-to-peer model where each endpoint accepts subscriptions and sends notifications on its own.

An initial SUBSCRIBE request might be forked to several event servers, and the framework allows all of them to accept the subscription. Individual packages are required to define how to combine the information received from multiple notifiers if the package allows this to happen.

The framework has proven to be a powerful tool for realizing new applications and providing new services. In future FAQs, we’ll look more deeply into some of these packages, the way the framework works, and how the challenges authentication presents are managed.