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 IETF’s SIPCORE
working group is currently refining an update to the
SIP Events
specification. The full scope of the changes in this update are called out

in the draft. These changes are based on operational experience and implementer feedback based on the original RFC 3265.

The most widely implemented event package is currently the
“refer” package, which is used to implement
call transfer. The person transferring the call sends a REFER request to the person being transferred. That request contains a SIP URI that will reach the transfer target.

In the above figure, Bob has to come up with a useful URI to send to Alice that will reach Carol. Alice needs to reach the particular phone that Carol used to talk with Bob above (remember that Carol might have many phones that ring when her primary SIP URI is used). Alice needs to be able to reach Carol through NATs and firewalls (maybe different NATs and firewalls than are between Bob and Carol). Quite a bit of machinery has been defined to allow Bob’s phone to provide a useful URI, including the
Replaces extension and the
Global Routable User Agent URI, or GRUU. The details of using these mechanisms are called out in
RFC5589.

The flow above described a fairly boring use of the refer event package. The utility of having a subscription reporting on the status of the REFER-triggered request is more obvious when the transfer attempt fails for some reason.

Through SIP Events, Bob learns that Alice can’t contact Carol with the URI he provided. He’s able to recover his call with Alice and can move on to try something else.

The vast majority of current call-transfer implementations send the REFER inside a dialog created by an INVITE (in the example above, Bob’s REFER request was sent inside the dialog created by Alice’s initial INVITE). As detailed in
RFC 5057, sharing the dialog information between the session usage established with the INVITE and the subscription usage established with the REFER request introduces perils, not the least of which is additional complexity when things start to fail. The original specification of REFER was completed well before the issues documented in RFC 5057 were understood, and reusing the dialog solved an important problem – when should a phone accept a request that will make it call another phone? For the original REFER specification, the answer was roughly “It’s ok to accept this request since it came from someone I’m currently in a call with”. This avoided having the phone accept a command to call some expensive service in the middle of the night, and avoided having additional user-interface elements put onto the phone in order to get the user’s permission in real-time. Since then, additional mechanisms (notably the
Target-Dialog extension) have been defined to allow this same admission criteria to be used when the REFER is sent on its own dialog.

With these extra mechanics, the ability to recover when some step of the transfer process fails is simplified and the probability of running into an interoperability failure due to the ambiguities detailed in RFC 5057 is reduced. The resulting flow looks like this:

There are no other known deployed SIP Event implementations that reuse existing dialogs. New implementations of call-transfer have been encouraged to use the mechanics that avoid dialog reuse for some time. The update to the SIP Event specification is raising the bar from encouraging the use of these mechanics to requiring them when the necessary extensions are supported by the endpoints involved. These new implementations will be more robust, and networks using them will be easier to diagnose and maintain.

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.