SIPPING WG M. Vakil
Internet-Draft Microsoft Corporation
Intended status: Standards Track April 27, 2007
Expires: October 29, 2007
An Extension to Session Initiation Protocol (SIP) Events for Pausing and
Resuming Notifications
draft-vakil-sipping-Notify-pause-01.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 October 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Vakil Expires October 29, 2007 [Page 1]
Internet-Draft Pausing Notifications Temporarily April 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, un-pause
notifications, and be able to perform fetch (poll) subscriptions
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.1.2. Fetch During Paused Stream . . . . . . . . . . . . . . 6
3.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 6
3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Overview of Operation . . . . . . . . . . . . . . . . . . 7
3.5. Subscriber And Notifier Behaviors . . . . . . . . . . . . 9
3.5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . 9
3.5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . 9
3.5.3. Subscriber Behavior when "notify" Not Supported . . . 10
3.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
3.8. Security Considerations . . . . . . . . . . . . . . . . . 11
3.9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Normative References . . . . . . . . . . . . . . . . . . . 12
4.2. Informational References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Vakil Expires October 29, 2007 [Page 2]
Internet-Draft Pausing Notifications Temporarily April 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 October 29, 2007 [Page 3]
Internet-Draft Pausing Notifications Temporarily April 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.
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 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.
Vakil Expires October 29, 2007 [Page 4]
Internet-Draft Pausing Notifications Temporarily April 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 (e.g. PC is locked), 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. 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:
Vakil Expires October 29, 2007 [Page 5]
Internet-Draft Pausing Notifications Temporarily April 2007
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.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,
regular fetch subscription outside any dialog (expires=0) creates an
equal amount of processing on the server as described (creation of
new subscription) 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.
Vakil Expires October 29, 2007 [Page 6]
Internet-Draft Pausing Notifications Temporarily April 2007
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 | |
Vakil Expires October 29, 2007 [Page 7]
Internet-Draft Pausing Notifications Temporarily April 2007
|------------------------------>| |
| | 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 |
| |<-----------------------------|
Vakil Expires October 29, 2007 [Page 8]
Internet-Draft Pausing Notifications Temporarily April 2007
| 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.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 receive a one off updated notification
Vakil Expires October 29, 2007 [Page 9]
Internet-Draft Pausing Notifications Temporarily April 2007
(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
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"|"once")
3.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]
"once"
Vakil Expires October 29, 2007 [Page 10]
Internet-Draft Pausing Notifications Temporarily April 2007
(Note to the RFC Editor: Replace "xxxx" with the RFC number of this
specification, when assigned.)
3.8. Security Considerations
The security considerations listed in SIP events RFC3265 [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.
Vakil Expires October 29, 2007 [Page 11]
Internet-Draft Pausing Notifications Temporarily April 2007
4. References
4.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.
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.
[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 October 29, 2007 [Page 12]
Internet-Draft Pausing Notifications Temporarily April 2007
Author's Address
Mohammad Vakil
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: mvakil@microsoft.com
Vakil Expires October 29, 2007 [Page 13]
Internet-Draft Pausing Notifications Temporarily April 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 October 29, 2007 [Page 14]