SIPPING WG M. Vakil Internet-Draft Microsoft Corporation Intended status: Informational February 23, 2007 Expires: August 27, 2007 An Extension to Session Initiation Protocol (SIP) Events for Pausing and Resuming Notifications draft-vakil-sipping-notify-pause-00.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 August 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Vakil Expires August 27, 2007 [Page 1] Internet-Draft Pausing Notifications Temporarily February 2007 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 and un-pause notifications within an established (created) subscription dialog. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Why Not Terminate and Re-create Subscription? . . . . 5 3.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 5. Subscriber And Notifier Behaviors . . . . . . . . . . . . . . 8 5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 8 5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 8 5.3. Subscriber Behavior when "notify" Not Supported . . . . . 8 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informational References . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Vakil Expires August 27, 2007 [Page 2] Internet-Draft Pausing Notifications Temporarily February 2007 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]. Vakil Expires August 27, 2007 [Page 3] Internet-Draft Pausing Notifications Temporarily February 2007 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. 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 and un-pause notifications within an established (created) subscription dialog. There are many event packages defined, e.g. presence RFC3856 [5] , reg event RFC3680 [6], resource list RFC4662 [4], on top of SIP event framework RFC3265 [3]. There is no mechanism to temporarily pause the notifications, while still maintaining a subscription on the server. According to RFC 3265 RFC3265 [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 tends to results in a lot of superfluous notification traffic, and puts unnecessary load on the servers and client. This draft defines an extension to SIP events that allows the subscriber to pause and un-pause notifications stream within the same subscription dialog. Vakil Expires August 27, 2007 [Page 4] Internet-Draft Pausing Notifications Temporarily February 2007 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. o An endpoint, used by the subscriber for presence event may not be active at that endpoint, but still logged into the system. This idle endpoint keeps on receiving unnecessary notifications o 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 o This problem gets worse for subscriptions to list resources. It tends to create high notification traffic related to the members of the list. This rate increases as the size of the list increases. This puts an undue burden on the notifier, to send notification for each list element's event state udpate. Therefore, it's preferred to simply pause the notifications on the event list subscription 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. 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 Vakil Expires August 27, 2007 [Page 5] Internet-Draft Pausing Notifications Temporarily February 2007 temporarily. Typically, the following steps are required to install a new subscription: o New dialog state creation o Execution of authorization policies o Installing composition policies o Creating watcher/presentity based filters o 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 o Each new subscription requires processing of watcher info notifcations, if applicable o 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.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. 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. Vakil Expires August 27, 2007 [Page 6] Internet-Draft Pausing Notifications Temporarily February 2007 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. The resumption of notification is performed by the subscriber sending another refresh subscription, with an event header parameter "notify=on". In both the cases, expires value is non-zero. Since, these are similar to refresh subscription, they may generate notifies. In the first case of pausing the subscription, notifier SHOULD not send a notify. In the resumption case, notifier MUST send a full state subscription. Vakil Expires August 27, 2007 [Page 7] Internet-Draft Pausing Notifications Temporarily February 2007 5. Subscriber And Notifier Behaviors 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. When a subscriber discovers the need to receive 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. 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. 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. 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. Vakil Expires August 27, 2007 [Page 8] Internet-Draft Pausing Notifications Temporarily February 2007 6. Syntax 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 [3] and SIP RFC3261 [2], adding additional alternatives to the alternative sets of "event-param" defined therein. event-param =/ notify-param notify-param = "notify" "=" ("on"|"off") Vakil Expires August 27, 2007 [Page 9] Internet-Draft Pausing Notifications Temporarily February 2007 7. IANA Considerations This mechanism registers a new SIP header field parameter for the event header defined in SIP events RFC 3265 [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] (Note to the RFC Editor: Replace "xxxx" with the RFC number of this specification, when assigned.) Vakil Expires August 27, 2007 [Page 10] Internet-Draft Pausing Notifications Temporarily February 2007 8. Security Considerations The security considerations listed in SIP events RFC3265 [3], which the specified mechanism extends, apply in entirety. Vakil Expires August 27, 2007 [Page 11] Internet-Draft Pausing Notifications Temporarily February 2007 9. Acknowledgments I would like to thank Sean Olson, Sriram Parameswar, and Srivatsa Srinivasan for their ideas and input. Vakil Expires August 27, 2007 [Page 12] Internet-Draft Pausing Notifications Temporarily February 2007 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. 10.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. [5] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [6] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. Vakil Expires August 27, 2007 [Page 13] Internet-Draft Pausing Notifications Temporarily February 2007 Author's Address Mohammad Vakil Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Email: mvakil@microsoft.com Vakil Expires August 27, 2007 [Page 14] Internet-Draft Pausing Notifications Temporarily February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Vakil Expires August 27, 2007 [Page 15]