TOC 
SIPPING WGM. Vakil
Internet-DraftS. Parameswar
Intended status: Standards TrackMicrosoft Corporation
Expires: September 13, 2008March 12, 2008


An Extension to Session Initiation Protocol (SIP) Events for Pausing and Resuming Notifications
draft-vakil-sipping-notify-pause-02.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 13, 2008.

Abstract

The Session Initiation Protocol (SIP) events framework enables a subscriber to receive asynchronous notification of various events from other SIP user agents. It defines mechanisms to create, refresh, terminate subscriptions. This framework also defines mechanism to fetch (poll) an event state of a resource without creating persistent subscriptions. There is no mechanism to temporarily pause the notifications, while still maintaining a subscription on the server. This lack of functionality sometime results in a lot of superfluous notification traffic, and put unnecessary load on the server. This draft defines an extension to SIP events that allows the subscriber to pause, un-pause notifications, and be able to perform fetch (poll) subscriptions within an established (created) subscription dialog.



Table of Contents

1.  Requirements notation
2.  Introduction
3.  Motivation
    3.1.  Overview
        3.1.1.  Why Not Terminate and Re-create Subscription?
        3.1.2.  Fetch During Paused Stream
    3.2.  Problem Statement
    3.3.  Requirements
    3.4.  Overview of Operation
    3.5.  Subscriber And Notifier Behaviors
        3.5.1.  Subscriber Behavior
        3.5.2.  Notifier Behavior
        3.5.3.  Subscriber Behavior when "notify" Not Supported
    3.6.  Syntax
        3.6.1.  The "notify" event parameter
        3.6.2.  New Option Tag for Notify Pause and Resume functionality
    3.7.  IANA Considerations
        3.7.1.  New Header Parameter
        3.7.2.  New Option Tag
    3.8.  Security Considerations
    3.9.  Acknowledgments
4.  References
    4.1.  Normative References
    4.2.  Informational References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

2.  Introduction

The Session Initiation Protocol (SIP) events framework enables a subscriber to receive asynchronous notification of various events from other SIP user agents. It defines mechanisms to create, refresh, terminate subscriptions. This framework also defines mechanism to fetch (poll) an event state of a resource without creating persistent subscriptions. There is no mechanism to temporarily pause the notifications, while still maintaining a subscription on the server.

There are many event packages defined, e.g. presence RFC3856 (Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” August 2004.) [5] , reg event RFC3680 (Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Registrations,” March 2004.) [6], resource list RFC4662 (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.) [4], on top of SIP event framework RFC3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [3]. There is no mechanism to temporarily pause the notifications, while still maintaining a subscription on the server. According to RFC 3265 RFC3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [3], once a subscription dialog is established, notifications are sent whenever there's any change in resource state. There're instances, as described below, where user agents are not required to receive notifications. But at the same time they cannot simply terminate the subscription, because there are huge costs associated with installing the new subscriptions at the notifier.

This lack of functionality sometime results in a lot of superfluous notification traffic, and put unnecessary load on the server. This draft defines an extension to SIP events that allows the subscriber to pause, un-pause notifications, and be able to perform fetch (poll) subscriptions within an established (created) subscription dialog.



 TOC 

3.  Motivation



 TOC 

3.1.  Overview

A SUBSCRIBE request (with Expires !=0 ) for a given event package creates a subscrption with a finite lifetime. In that duration, whenever an event state change occurs for a given resource, notification is sent to the subscriber. This duration depends upon event packages and could range upto hours.

There is a processing cost on the notifier side to generate notifies, incur network traffic, and have user agent (subscriber) receive the NOTIFY, parse the event state, and perform all the update functions with no benefit.

In the following scenarios, it is not necessary to keep on receiving on going notifications, when that event state is not beneficial.

In the above scenarios, it would be prudent to simply pause the notifications traffic, while still maintaining subscriptions, and when user becomes active, or when the event state is required to be known instantaneously, at that point, it MUST be able to un-pause notification stream or perform a one off fetch subscription to retrieve an updated state within an established dialog.



 TOC 

3.1.1.  Why Not Terminate and Re-create Subscription?

In big deployments, it's not prudent to simply terminate the subscriptions tempoararily, because creation of subscription take a huge toll on the system. The cost of creating a new subscription on the server is far more than simply pausing the notification traffic temporarily. Typically, the following steps are required to install a new subscription:

Therefore, it is much less costly to simply turn off notification stream if receipt of the notifications are not required by the subscriber.



 TOC 

3.1.2.  Fetch During Paused Stream

It would be a significant performance improvement to be able to perform a fetch subscription within a paused dialog. Because, fetch subscription creates an equal amount of processing on the server as described in the section above. This improvement will be useful for wireless handset to be able to do a quick fetch when event state needs to be shown to end user.



 TOC 

3.2.  Problem Statement

The SIP events framework (RFC 3265) does not include protocol methods to pause and un-pause notifications, once a subscription is established with a non-zero expiration value. Every, state change triggers a notification towards subscriber, which may not be needed. These notifications cause processing power on the notifier and subscriber side, and the bandwidth in the network. It's not always prudent to terminate the subscription in those cases, as subsequent creation of new subscription requires much more processing on the notifier. There's also no mechanism to do a light weight fetch subscription as and when event state is needed, within a paused subscription.



 TOC 

3.3.  Requirements

REQ1: It MUST be possible to pause the notification stream for established SIP dialog of a subscription for any event package.

REQ2: It MUST be possible to resume the notification stream for an earlier paused notification stream on an established subscription and MUST be able to receive a full state notification to sync up with event state.

REQ3: It MUST be possible to perform a one off retrieval of updated event state within a paused notification stream.



 TOC 

3.4.  Overview of Operation

The SIP events framework specifies creation, refresh, and deletion of subscriptions. Once a subscription is created on the server, it keeps on sending notifies on event state changes. In order to pause the subscription on a temporary basis, subscriber issues a SUBSCRIBE request, similar to a refresh subscription, with an event header parameter of "notify=off". At this point, notifier stops sending the notifications, while still keeping the subscription alive. The subscription remains inactive until it expires or subscriber sends a request to resume notifications. In this state, subscriber may perform a light weight fetch subscription to trigger only one notify with an updated state, whenever needed. This can be performed by "notify=once". The resumption of notification is performed by the subscriber sending another refresh subscription, with an event header parameter "notify=on".

In all three cases, expires value is non-zero. Since, these are similar to refresh subscription, they may generate notifies. In the first case of pausing the notifications (notify=off), notifier SHOULD not send a notify. In the resumption case (notify=on) and (notify=once), notifier MUST send a full state subscription.


Subscriber			Notifier		  Event State
							   Generator
   |				   |				  |
   |SUBSCRIBE (expires!=0 , no notify param)	 		  |
   |------------------------------>|				  |
   |	200 OK			   |---Subscription created	  |
   |<------------------------------|				  |
   |	NOTIFY (first full state notify)			  |
   |<------------------------------|				  |
   |    200 OK			   |				  |
   |------------------------------>|				  |
   |				   |	Event state update	  |
   |				   |<-----------------------------|
   |	NOTIFY (partial or full)   |---Notify sent		  |
   |<------------------------------|				  |
   |    200 OK			   |				  |
   |------------------------------>|				  |
   |				   |				  |
   |				   |				  |
   |				   |				  |
   |SUBSCRIBE (expires!=0 , notify=off)		 		  |
   |------------------------------>|				  |
   |	200 OK			   |---Subscription paused	  |
   |<------------------------------|				  |
   |				   |				  |
   |				   |	Event state update	  |
   |				   |<-----------------------------|
   |				   |---No notify sent (paused)	  |
   |				   |				  |
   |SUBSCRIBE (expires!=0 , notify=once)	 		  |
   |------------------------------>|				  |
   |	200 OK			   |---Subscription paused but one|
   |<------------------------------|	full state notify (fetch  |
   |				   |	requested		  |
   |	NOTIFY (full state notify) |				  |
   |<------------------------------|				  |
   |    200 OK			   |				  |
   |------------------------------>|				  |
   |				   |				  |
   |				   |	Event state update	  |
   |				   |<-----------------------------|
   |				   |---No notify sent (paused)	  |
   |				   |				  |
   |				   |				  |
   |				   |				  |
   |				   |				  |
   |SUBSCRIBE (expires!=0 , notify=on)	 			  |
   |------------------------------>|				  |
   |	200 OK			   |---Subscription unpaused 	  |
   |<------------------------------|				  |
   |				   |				  |
   |	NOTIFY (full state notify) |				  |
   |<------------------------------|				  |
   |    200 OK			   |				  |
   |------------------------------>|				  |
   |				   |				  |
   |				   |	Event state update	  |
   |				   |<-----------------------------|
   |	NOTIFY (partial or full)   |---Notify sent		  |
   |<------------------------------|				  |
   |    200 OK			   |				  |
   |------------------------------>|				  |
   |				   |				  |



 TOC 

3.5.  Subscriber And Notifier Behaviors



 TOC 

3.5.1.  Subscriber Behavior

Whenever a subscriber is not interested in receiving on-going notifications for event state changes, it creates a refresh subscription with a non-zero expires value, and adds a new event header parameter "notify=off" to pause notifies on an existing established subscription dialog. This pause notification request in the form of a refresh subscription is sent to the notifier.

At this point, subscriber MUST NOT drop or reject the incoming notifies, if sent from the notifier. A subscriber is just recommending to halt notifies on a temporary basis.

In this halted state, subscriber may send another subscribe request with a non-zero expires value, but with a "notify=once" event header parameter to retrieve an updated event state with only one notification. This would allow subscriber to achieve fetch function within an established dialog.

When a subscriber discovers the need to receive on-going notifications again, it sends another refresh subscription. This time it uses a different value of "notify" event header parameter, with "notify=on". At this point, subscriber expects to receive a full state notification, similar to very first notification, when a subscription is created, continued updates in the event state on an on-going basis until subscription is terminated or another subscription with "notify=off" is sent.



 TOC 

3.5.1.1.  Initial Subscriptons and option tags

The subscriber SHOULD NOT use the "notify=off" parameter in the initial subscription. In case the subscriber invokes this functionality with the initial subscription,it MUST be prepared to receive the immediate notification as specified in RFC3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [3].

It is expected that the subscriber that is sending the initial subscription will place the "notifyoff" option tag in the Supported header. The subscriber SHOULD invoke this feature only if it receives confirmation of support from the notifier. The subscriber MAY invoke this functionality even if it does not receive confirmation, but must then be prepared to receive notifies.



 TOC 

3.5.2.  Notifier Behavior

When a notifier receives a request to pause the subscription, it treats that request very similar to a refresh subscription request. It does update the expiration of the subscription. But it pays attention to "notify" parameter, and if it's found to be "off". It SHOULD NOT send any notification, not even the immediate notifcation, until either subscription expires or a request to resume notification arrives. It is a feature of this specification that the notifier SHOULD suppresses the notification for the subscription refresh with "notify=off", though this is notification is required by section 3.1.6.2 of RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [3]. The notifier MUST send notifications in the event that the subscription is terminated for any reason.

Upon receiving a request to receive a one off updated notification (refresh subscription with notify="once"), notifier MUST treat that as a refresh subscription request. It MUST update the expiration time of the subscription and pays attention to "notify" parameter. If it's found to be "once", notifier MUST send a full state notification, and MUST NOT turn on the notification stream, upon every event state changes.

Upon receiving a request to resume notifications (refresh subscription with notify="on"), notifier MUST treat that as a refresh subscription request. It MUST update the expiration time of the subscription and pays attention to "notify" parameter. If it's found to be "on", notifier MUST send a full state notification, and then turns on the notification stream, where by sending notifies for every event state changes.



 TOC 

3.5.3.  Subscriber Behavior when "notify" Not Supported

In the case of a notifier not supporting the mechanism identified in this proposed extension, notifier will ignore "notify=" parameter, and would continue to send notifications. That's why, subscriber must be prepared to receive notifications and must keep on acknowleding it with 200 OK.



 TOC 

3.6.  Syntax



 TOC 

3.6.1.  The "notify" event parameter

This section describes the Augmented BNF [RFC 2234] definitions for the new syntax elements. It's based on ruleset present in both SIP Events RFC3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [3] and SIP RFC3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [2], adding additional alternatives to the alternative sets of "event-param" defined therein.

event-param =/ notify-param

notify-param = "notify" "=" ("on"|"off"|"once")



 TOC 

3.6.2.  New Option Tag for Notify Pause and Resume functionality

This specification defines a new option tag "notifyoff" that is be used to signal the state of support for the feature documented here.

UAs that support this feature MUST include the "notifyoff" option tag in a Supported header field. The "notifyoff" option tag SHOULD NOT be used in conjuction with the Required header, as the functionality described within this specification is an optimization, and UAs can continue to work in its absence, albeit with some deleterious effects.



 TOC 

3.7.  IANA Considerations



 TOC 

3.7.1.  New Header Parameter

This mechanism registers a new SIP header field parameter for the event header defined in SIP events RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [3], defined by the following information which is to be added to the Header Field Parameters and Parameter Values sub-registry under.

Header Field 	Parameter Name	Predefined	References
				 Values
------------	--------------	----------	-----------
Event		  notify	"on", "off",	 RFC[xxxx]
				  "once"

(Note to the RFC Editor: Replace "xxxx" with the RFC number of this specification, when assigned.)



 TOC 

3.7.2.  New Option Tag

This section defines a new option tag as per the guidelines of section 27.1 of RFC3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [2]

Name: notifyoff

Description: This option tag identifies the Notify Pause and Resume functionality. When present in the Supported header it indicates the user agents support for this functionality.



 TOC 

3.8.  Security Considerations

The security considerations listed in SIP events RFC3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [3], which the specified mechanism extends, apply in entirety.



 TOC 

3.9.  Acknowledgments

I would like to thank everyone who provided feedback on the sipping mailing list for their ideas and input, especially to Paul Kyzivat, Sean Olson, Sriram Parameswar, and Srivatsa Srinivasan.



 TOC 

4.  References



 TOC 

4.1. Normative References

[1] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002 (TXT).
[3] Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” RFC 3265, June 2002 (TXT).


 TOC 

4.2. Informational References

[4] Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” RFC 4662, August 2006 (TXT).
[5] Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” RFC 3856, August 2004 (TXT).
[6] Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Registrations,” RFC 3680, March 2004 (TXT).


 TOC 

Authors' Addresses

  Mohammad Vakil
  Microsoft Corporation
  One Microsoft Way
  Redmond, WA 98052
  USA
Email:  mvakil@microsoft.com
  
  Sriram Parameswar
  Microsoft Corporation
  One Microsoft Way
  Redmond, WA 98052
  USA
Email:  srirampa@microsoft.com


 TOC 

Full Copyright Statement

Intellectual Property