FAQ: What is WINFO?
Posted by Robert Sparks on Wed, Jan 06, 2010 @ 05:02 PM
As described in an earlier FAQ, SIP Events uses a notion of a "package" to determine what kind of information is being asked for, what kind of change will cause a notification to be sent, and what the available options are for encoding the information in a NOTIFY request.
The current set of standardized SIP Event packages is maintained at the sip-events namespace registry at IANA. At the beginning of 2010, there are thirteen registered packages, and one special thing called a "template-package": winfo.
Subscribing to this template-package will give you "Watcher INFOrmation": details of each subscription to a particular event. For instance, I could subscribe to "presence.winfo" for sip:RjS@tekelec.com to see who is watching my presence.
Template packages are never used directly - they must be applied to regular packages. In other words, it isn't possible to subscribe to "winfo", only to events like "presence.winfo" or "message-summary.winfo".
The template package concept was introduced to make it easier to build packages that would extend every other existing package the same way. It would have been possible to build the same system without template packages by creating separate "presence-winfo", "message-summary-winfo", etc. packages, but each of those would have to respecify the common behavior. Having this meta-package tool avoids that extra specification work (and makes it less likely that watcher information for package "foo" and for package "bar" would behave in subtly different ways).
The concept has been with us for nearly a decade, and the only event-template package we've found a need for is winfo. It may be the only one that ever exists.
Like many aspects of SIP Events, winfo was driven by presence. When a new person tries to add me to their list, I need a way to find out so that I can give the service permission to hand my presence to that new person. My client needs a nudge so it can ask me whether I would like to allow or deny the subscription. Early attempts at a solution involved having the server send me a QAUTH request before answering the SUBSCRIBE from this new person. That turned out to be a dead-end for two reasons. First, like all SIP non-INVITE requests, QAUTH had to get an answer within 32 seconds (64*T1, where T1's default value is 500ms). If I didn't happen to be sitting in front of my computer, notice the dialog, and answer within that time, the wrong thing happened. Second, if this new person and I never happened to be online at the same time, authorization would never complete.
To solve these problems, we reused SIP Events itself - using the winfo template-event package to subscribe to changes in the set of watchers for any other package, like presence. The initial NOTIFY for a winfo subscription will describe each of the existing subscriptions detailing who the subscriber is, how long the subscription has been in place, when it will expire (if it isn't refreshed), and what the current authorization state for the subscription is. (Remember that subscriptions can enter a "pending" state if a server doesn't have authorization when the SUBSCRIBE arrives). To solve the never-online-at-the-same-time problem, winfo carries one more state, named "waiting", for subscriptions which were attempted recently but for which authorization was not available.
Here's a short example of winfo in action. Assume at the beginning of this flow that I've authorized Ben and Adam to see my presence, but not Theo. Note that in this flow, Theo and I are never online at the same time.
The winfo NOTIFY body format is XML. The initial NOTIFY for a winfo subscription will have a complete list of current watchers. Subsequent NOTIFYs will only contain information for those watchers whose subscription has changed state.
For more details on the format of the winfo NOTIFY bodies, see RFC 3858. The winfo template-package itself is in RFC 3857.