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.