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

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.).

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.

3.  Motivation

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.

• An endpoint, used by the subscriber for presence event may not be active at that endpoint (e.g. PC is locked), but still logged into the system. This idle endpoint keeps on receiving unnecessary notifications
• A wireless handset receiving notifications for events, not paid attention to, while wasting over the air bandwidth. The same wireless endpoint may also consume processing and battery power, which might be needed for other voice applications, to process these unwanted notifications. A wireless handset, may trigger a fetch subscription within an established dialog whenever end user wants to receive an updated event state (mostly in presence buddy list applications)

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.

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:

• New dialog state creation
• Execution of authorization policies
• Installing composition policies
• Creating watcher/presentity based filters
• Creation of back end subscriptions to intra and inter domains for distributed resources. That in turn creates extra processing on the back-end servers to install the subscriptions
• Each new subscription requires processing of watcher info notifcations, if applicable
• To meet high availability requirements, subscription state replication occurs on other nodes

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

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.

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.

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.

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			   |				  |
   |------------------------------>|				  |
   |				   |				  |

3.5.  Subscriber And Notifier Behaviors

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.

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.

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.

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.

3.6.  Syntax

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")

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.

3.7.  IANA Considerations

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.)

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.

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.

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.

4.  References

4.1. Normative References

4.2. Informational References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.