In my last post, I discussed the Resource List Service optimization to the SIP Events mechanism. The reader will recall that I argued that, while that optimization had value in certain specific circumstances, it does not universally improve scalability. Today I will discuss the Conditional Event Notification extension defined in RFC 5839.

As defined in RFC 3265, a SIP event subscription is soft-state. Soft-state is an extremely important concept in SIP and other IP based protocols, in that it makes networks more resilient to errors. But soft-state requires maintenance. In the case of an event subscription, if it the client does not refresh the subscription in some negotiated period of time, it goes away.

The client refreshes a subscription by sending a new SUBSCRIBE request in the existing dialog, that is, the dialog created by the initial SUBSCRIBE request. Other than being mid-dialog, the resulting transaction is similar to the initial one. The server responds (in the same dialog) with both a SIP response to the SUBSCRIBE request, and a NOTIFY request back towards the client.

That NOTIFY request contains the current state of the event. For the presence event, that state could conceivably be quite large. And for a long lived subscription, you can get a lot of subscription refreshes. For example, if you refresh every 30 minutes, a 24-hour long subscription will get a NOTIFY request for the initial subscription, 47 subscription refreshes, and a termination, for a total of 49 “maintenance” SUBSCRIBE requests. This is in addition to any notifications generated due to bona-fide state changes.

The Conditional Event Notification extension offers a mechanism to suppress some or all of these maintenance NOTIFY transactions. The mechanism uses an entity-tag, or ETag for short. An ETag is a kind of magic cookie that identifies a particular version of the state of an event. When the notifier sends an update to the event state, it can include an ETag. Then when the client needs to refresh a subscription, it can include the ETag in the subscription. The notifier then compares that ETag against the one for the current even state. If they match, it knows that the client’s view of the event-state is still current. The notifier can then avoid sending the NOTIFY request. This is similar to the idea of entity-tags in HTTP. In fact, this usage of ETags, and a similar usage for SIP PUBLISH, were inspired by this idea.

This mechanism does not only work for subscription refreshes. The client can also use it to resume a previous subscription, and suppress the contents of the initial NOTIFY. (It can’t suppress the initial NOTIFY entirely, as that transaction is critical for properly establishing a new subscription dialog.)

Conditional notification can be helpful when network bandwidth is scarce or expensive, such as in mobile wireless networks. It’s less helpful when bandwidth is plentiful, such as in wired broadband networks. While conditional notification reduces the NOTIFY requests that a notifier must send, it also increases the computational complexity of handling SUBSCRIBE requests. So, the server-side value of this optimization depends quite a bit on the software implementation of the notifier.

Even in the case of scarce bandwidth, this optimization has an implied assumption that the number of refresh NOTIFY requests is significant compared to the number of NOTIFY requests sent due to actual event state changes. If the event state changes rapidly, as it might in a subscription to user presence state–or even more so if that state includes location data, then the returns of conditional notification begin to diminish.

Additionally, since conditional notification is attractive to mobile wireless providers, it’s likely to be combined with other wireless-oriented optimizations – such as the RLS optimization I discussed last time. If you recall, a resource list subscription receives notification for state changes of each resource on the list, as well as any changes to the list itself. This greatly amplifies the number of NOTIFY requests sent for real state changes. When you stack both of these optimizations, you get diminishing returns compared to using each separately.

The reader may notice a pattern here. SIP was designed to work well for the general case. Most optimizations to SIP are designed for very specific situations. They tend to be less helpful, and sometimes even harmful, in the general case. When looking for ways to optimize a particular SIP network, one must be careful to make sure the network in question actually fits the implicit assumptions of the optimizations.

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.

SIP is robust in the Internet environment.

SIP still works in predictable ways when packets are lost, when routes fail, and when endpoints fall off the network.

SIP achieves some of this robustness through a design principle to fail to a known-safe condition. The idea is that any change to the system has to be maintained through periodic refreshment. If the authority for a change isn’t available to maintain the change, then it’s not around to correct the change when new conditions cause it to be wrong.

For example, a presence user could post a presence document that says “I’m driving”. Somewhere along that drive, the user goes into a parking garage, losing connection to the network. The user leaves his car and makes it into a movie theater without reconnecting. In a less-robust system, that user’s presence will be wrong for the next hour or so. A SIP based presence system will notice, after some time, that the user is no longer maintaining the presence document and will fall back to a known safe default, probably “I don’t know anything about this user’s presence right now.”

This SIP-based presence user’s published presence is “soft-state”. It is information (state) the user put into the system that will go away if the user doesn’t maintain it. Stated another way, the information will expire unless it is refreshed.

By contrast, the position of a typical simple light-switch is “hard-state”. If you flip it up, it will stay up, possibly forever. It will only change back to down when you (or some other user) explicitly comes back to manipulate it.

The soft-state concept is reused in many parts of the SIP protocol. Registrations expire. Subscriptions expire. Presence documents (or any other published SIP Event documents) expire. The time it takes to expire is negotiated between the element providing the state, usually an endpoint, and the element keeping the state, such as a registrar or presence server. That negotiation goes like this:

Handset: “Would you please send requests for me to this Contact for the next hour?”

Registrar: “Yes, I’ll hold onto this Contact for you, but I’ll only keep it for 5 minutes.”

When making that request, the handset’s user is also saying “If something unexpected happens, I’m willing for the state I’ve handed you to be wrong for up to an hour”. The server is replying “I’m only willing to let things be wrong for 5 minutes”.

This points out why the Registrar above cannot say “Yes, I’ll hold onto this Contact for you, and to save you some trouble, I’ll keep it active for a month”. The handset user is only willing for things to be wrong for an hour. Half a month from now, that handset might not even exist.

Once soft-state is accepted, it must be refreshed or it will be deleted. That means that before the negotiated time passes, the element placing the state into the system must return and say “please hold onto this state a little longer”. In SIP, this refresh also re-negotiates the next expiration time.

In the figure below, Phil subscribes to Robert, asking for an hour. Robert grants the subscription, but limits the expiration of the subscription (the soft-state) to 5 minutes. Four minutes into the subscription, Phil refreshes it, asking for another hour, but again getting another 5 minutes. This time Phil doesn’t refresh the subscription, letting it expire. Note that the total subscription time was 9 minutes, not 10. Phil’s second 5 minutes started at the point of negotiation, not when the first 5 ran out.