SIP Working Group M. Garcia-Martin
Internet-Draft Nokia Siemens Networks
Intended status: Informational H. Schulzrinne
Expires: November 12, 2007 Columbia University
May 11, 2007
Notification of General Events Using the Session Initiation Protocol
(SIP) Event Notification Framework
draft-garcia-sipping-general-events-00
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 November 12, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The SIP event notification framework is specified in RFC 3265. The
framework restricts usage to notifications of events related to the
SIP state. However, there is growing interest in the community for
relaxing that constraint and using the SIP event notification
framework for reporting changes in state that is not directly related
to SIP. For example, it has been suggested a usage of the framework
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 1]
Internet-Draft SIP General Events May 2007
for reporting events related to a vehicle state, files stored in a
device, calendar events, and Sieve notifications. This memo
discusses the benefits of a mechanism for general event notifications
using SIP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General requirements . . . . . . . . . . . . . . . . . . . . . 4
3. Benefits of Using SIP . . . . . . . . . . . . . . . . . . . . 4
3.1. Operations with the SIP Event Notification Framework . . . 5
3.2. Soft State . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Separation of Transport and Events . . . . . . . . . . . . 5
3.4. Subscriber List Discovery . . . . . . . . . . . . . . . . 5
3.5. Aggregation, Rate Limit, and Filtering Event
Notifications . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Owner Control of Offered Information . . . . . . . . . . . 6
3.7. Availability of Protocol Stack . . . . . . . . . . . . . . 6
3.8. Service Integration . . . . . . . . . . . . . . . . . . . 6
3.9. Maturity of protocols . . . . . . . . . . . . . . . . . . 6
3.10. Infrastructure Re-usability . . . . . . . . . . . . . . . 7
3.11. Security Properties . . . . . . . . . . . . . . . . . . . 7
3.11.1. Authentication . . . . . . . . . . . . . . . . . . . 7
3.11.2. Authorization . . . . . . . . . . . . . . . . . . . . 7
3.11.3. Integrity Protection and Confidentiality . . . . . . 7
3.11.4. Identity Management . . . . . . . . . . . . . . . . . 8
3.12. Discovery of IP Address . . . . . . . . . . . . . . . . . 8
3.13. Support for Multiple Endpoints . . . . . . . . . . . . . . 8
3.14. Independence of Data Source and Notifiers . . . . . . . . 8
3.15. NAT traversal . . . . . . . . . . . . . . . . . . . . . . 8
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informational References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 2]
Internet-Draft SIP General Events May 2007
1. Introduction
The Session Initiation Protocol (SIP) (RFC 3261 [1]) provides a
mechanism for creating, modifying, and terminating sessions between
users. The SIP event notification framework (RFC 3265 [2]) extends
SIP with a mechanism for subscribing to, and receiving notifications
of, SIP-related events within SIP networks.
The SIP event notification framework introduces the notion of a
package, which is a specific "instantiation" of the events framework
for a well-defined set of events. However, the SIP-specific event
notification framework restricts its usage to SIP-related events.
Specifically, the framework indicates that it is not intended to be a
general-purpose infrastructure for all classes of event subscription
and notification. Rather, the framework is restricted to provide
notifications related to SIP state.
Following the guidelines in RFC 3265, a number of event packages for
reporting SIP-related notifications have been developed. To cite a
few of them:
o The conference event package (RFC 4575 [14]) provides
notifications of conference participants and associated data.
o The dialog event package (RFC 4235 [11]) provides notifications
related to a given SIP dialog.
o The Key Press Stimulus event package (RFC 4730 [16]) provides
notifications of key presses in SIP User Agents (UAs).
o The Message-Summary event package (RFC 3842 [6]) provides
notifications of message waiting status and message summaries
stored in voicemail servers.
o The presence event package (RFC 3856 [8]) provides notifications
of the user's presence information.
o The 'reg' event package (RFC 3680 [5]) provides notifications of
the SIP registration state associated with a user.
All of the above mentioned event packages provide notifications of
events related, in some manner, to SIP.
However, during the last years, there is a growing interest in the
community to use the SIP notification framework for providing
notifications of events that are somehow related to real-time
communications, but not necessarily to SIP. A few examples of those
event packages specifications are:
o The vehicle information event package [18] provides status of
vehicles and diagnostic information distributed by vehicle
telematics systems.
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 3]
Internet-Draft SIP General Events May 2007
o The calendar event package [25] provides notifications of calendar
events.
o Sieve notifications using SIP [26] proposes an event package to
provide notifications of Sieve filter rules.
o The resource sharing framework [23] and the companion resource
event package [24] propose a mechanism for getting a list of
remotely available files and notifications of changes in those
files.
It must be noted that none of the mentioned proposed usages require
an extension to the core SIP protocol or the SIP event notification
framework. The definition of the event package is the only required
extension.
2. General requirements
We have a analyzed the proposed usages of the SIP event notification
framework for reporting non-SIP state, and we have drafted a set of
requirements to be met by a suitable protocol. These requirements
are:
REQ-1: The protocol must provide subscribe, notification, and
publication operations.
REQ-2: The protocol must provide subscriptions to soft state with
configurable time-out.
REQ-3: The protocol must provide a separation of transport and event
description, to allow adding new event types.
REQ-4: The protocol must have the ability to discover who is
currently subscribed to an event.
REQ-5: The protocol must have the ability to aggregate, rate-limit
and filter event notifications.
REQ-6: The protocol must have the ability of the event "owner" to
restrict access to event notifications.
REQ-7: The protocol must have the ability to control who can
subscribe to what and when.
3. Benefits of Using SIP
According to RFC 3265, implementations of event packages need to
consider whether SIP is a correct protocol for delivering the needed
notifications. This sections analyzes the benefits of using SIP and
its compliance with the above-mentioned requirements for delivering
non-SIP related notifications.
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 4]
Internet-Draft SIP General Events May 2007
3.1. Operations with the SIP Event Notification Framework
The SIP Event Notification Framework [2] provides for two basic
operations: subscriptions to event state and notifications of changes
in the event state. These are modeled through the SUBSCRIBE and
NOTIFY SIP methods. In addition, SIP also provides a publication
operation in the format of the SIP PUBLISH method [10].
3.2. Soft State
The SIP event notification framework allows subscribers of event
state data to get subscribed by utilizing soft-state subscriptions,
i.e., subscriptions that eventually expire (if not renewed). This
contrasts hard state subscriptions, which only expire upon the
reception of an explicit message. The mechanism allows a negotiation
of the time-out of the soft state between the subscriber and
notifier.
3.3. Separation of Transport and Events
SIP publications, subscriptions and notifications are handled by the
SIP PUBLISH, SUBSCRIBE, and NOTIFY methods, respectively. None of
the methods define which events are to be reported, not even the data
format that describes such event. Events are specified separately,
so they are the data formats. These provides a separation of two
separate issues: the transport and the events. As a consequence, it
is possible to add new events with no changes to the transport
protocol.
3.4. Subscriber List Discovery
There are scenarios where it is needed to discover the list of
subscribers to a certain event. This might be the case, for example,
to provide authorization for subscriptions or to be able to adapt
certain authorization rules to a group of subscribers. SIP provides
a watcher information template event package [9] that meets the
requirements. A user can subscribe to the watcher information of an
event package of a given resource, and get notifications that contain
the list of subscribers to that event package at that resource.
3.5. Aggregation, Rate Limit, and Filtering Event Notifications
SIP provides a number of mechanisms that help to provide aggregation,
rate limit, and filtering of event notifications. On one side, event
packages can be designed to provide aggregated events, where a single
notification provides the new event state for a number of atomic
changes. Event packages need to defined the minimum notification
rate and be able to hand aggregated notifications.
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 5]
Internet-Draft SIP General Events May 2007
On the other hand, work is on progress for providing SIP with a
mechanism that allows a subscriber to limit the rate of notifications
[21]. SIP also provides a filtering mechanism [15] by which a
subscriber can indicate the pieces of information within the event
for which notifications should be sent.
3.6. Owner Control of Offered Information
Owners of event state information (or other duly authorized users)
can determine the level of privacy of the state information by, e.g.,
setting the rules that govern the level of details of the state
information that is to be delivered to each subscriber. This makes
that two different subscribers receive different level of details
pertaining to the same state, according to the rules that an
authorized person has set.
Common Policy [17] offers a framework for expressing privacy
preferences. The framework allows a user to create authorization
policies for access application-specific data. This framework has
been tailored to different applications. For example, the presence
service instantiates Common Policy [17] with Presence Authorization
Rules [22]. These rules determine the type of information supplied
to each subscriber to a presence event package.
3.7. Availability of Protocol Stack
Most modern communications applications already implement SIP and the
SIP event notification framework due to requirements of a number of
applications. Assuming SIP and the SIP event notification framework
is already implemented, adding a new event package is simpler, from
the implementation point of view, than adding a completely new
protocol. In many occasions, the SIP event notification framework
has been already implemented to support the presence service.
3.8. Service Integration
Most communications services today integrate a number of services,
such as voice, video, instant messaging, presence, web, email, and
file transfer, where some of these services are based on SIP. When a
new service or function should be integrated in the existing set of
services, the integration is greatly simplified if a single protocol
is used for the new and existing services.
3.9. Maturity of protocols
SIP is a mature protocol which is widely deployed in the Internet,
enterprise, and other networks. Interoperability of SIP has been a
key aspect of it over the years. This can be verified through the
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 6]
Internet-Draft SIP General Events May 2007
logs of the multiple SIP and SIMPLE interoperability tests that have
been taking place during the last years. Because of this, SIP offers
an enviable record that attracts new services.
3.10. Infrastructure Re-usability
There are cases when the new service or function requires to deploy
some sort of network support, for example, to route SIP signaling,
authenticate users, aggregate state, or handle subscriptions. If an
existing SIP network of proxies, registrars, or notifiers is already
available and can be re-utilized by the service or function, then the
deployment and operation of the service is greatly simplified.
3.11. Security Properties
SIP provides a number of security properties that are very
interesting for the deployment of services. Among others, the
following security properties are of interest for most services.
3.11.1. Authentication
SIP provides means to do client to server or mutual authentication.
Authentication can be done on a request by request basis, or at
registration time and then extended to all the SIP requests that take
place while the registration is active.
Several authentication mechanisms have been developed or adapted for
SIP. The HTTP Digest Authentication scheme (RFC 2617 [3]) offers the
common minimum denominator. Other mechanisms include TLS [12] with
certificates, etc. These mechanisms are further complemented with
mechanisms for delivering a cryptographic identity [13], network
asserted identity [4], or trait-based authorization using the
Security Assertion Markup Language (SAML) [20].
3.11.2. Authorization
The SIP event notification framework provides several levels of
authorizations. On one side, an event state compositor can authorize
state suppliers to publish state related to some data. On the other
hand, an event state compositor can authorize subscriptions of
subscribers of state information.
3.11.3. Integrity Protection and Confidentiality
Integrity protection and confidentiality of the supplied state can be
achieved by applying S/MIME [7] to the bodies of the SIP requests
(e.g., NOTIFY, PUBLISH).
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 7]
Internet-Draft SIP General Events May 2007
3.11.4. Identity Management
A user of SIP services is usually provided with an identity,
typically in the format of a SIP URI, for his disposal. When a new
service is introduced, the new service can reuse existing SIP
identities, if deemed necessary. So, the new service does not need
to deploy new identities (and perhaps also new associated
credentials) for delivering the new service.
3.12. Discovery of IP Address
A problem that often arises is the discovery of the IP address and
port number of the endpoint that eventually wants to receive
notifications of event state. In SIP, User Agents (UAs) typically
register with a SIP service provider. The registration process binds
a SIP Address-Of-Record identity with a URI that resolves to the IP
address of the user. Any other SIP User Agent or proxy can route
towards a proxy that can get the IP address and port number of the UA
where the user is logged in.
3.13. Support for Multiple Endpoints
SIP contains built-in support for a user that is running a service in
different devices. For example, the user can be subscribed to event
state information from different endpoints, and receive notifications
in several endpoints. On the other hand, a supplier of event state
information can publish the state information from different sources;
an event state compositor will merge the various inputs into
congruent state data.
3.14. Independence of Data Source and Notifiers
An advantage of SIP consists of the ability to separate sources of
event state data and the notifier that handles subscriptions to such
data. So, the source or sources of state need not be located in the
same host where notifications are managed. For example, state agents
publishes state information acquired from sources of state.
3.15. NAT traversal
SIP provides an outbound mechanism [19] for easing the burden of
firewall and NAT traversal of SIP messages. However, many NATs and
firewalls requires a keep alive mechanism that keeps the state in
those nodes alive. Sometimes the keepalive timer might be as short
as 30 seconds. In this respect, having SIP as a single protocol for
various usages allows to have a single keep alive mechanism shared by
those different usages, as opposed to using two separated keep alive
mechanisms for two different protocols. This becomes a benefit for
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 8]
Internet-Draft SIP General Events May 2007
extending the battery life of battery-operated devices.
4. Discussion
Several key aspects for providing new services have been evaluated in
the previous sections. While in some cases it might be possible to
deliver a service using alternative protocols, the SIP event
notification framework provides in most cases a great deal of
simplification by reusing many of the existing functions: security
mechanism, authorization rules, composition rules, privacy
mechanisms, and state agents. If the service has to be integrated
with an existing SIP application, then SIP is usually superior in the
evaluation of alternatives.
RFC 3265 [2] indicates that the mechanism is not intended to be a
general-purpose infrastructure for all classes of event subscription
and notification. But it must be noted that the RFC provides no
technical reasons for such restriction. However, on the other hand,
we are not advocating for a general purpose event notification
mechanism either, since we believe there are no compelling reasons
for implementing the SIP event notification framework in every case
(for example, we believe there are no reasons for implementing the
framework in an Ethernet switch or a router). Instead, we advocate
for a relaxation of the said constraint so that the SIP event
notification framework can also be applied to more general events,
such as those to be integrated in communication services, where the
state to be reported is not directly related to SIP. That is the
case for the proposals listed in Section 1.
RFC 3265 [2] provides a discussion about the rate of notifications,
indicating that the mechanism is not to be used in applications where
the frequency of reportable events is excessively rapid (e.g., more
than about once per second). It is believed that the proposals under
discussion meet this criterion.
Additionally, none of the proposed usages of the SIP event
notification framework require any extension to the core SIP protocol
or the SIP event notification framework.
5. Conclusion
This document identifies a number of benefits when the SIP event
notification framework is used to report non-SIP state related to
communication services. We advocate for relaxing the restriction
existing in RFC 3265 [2] that limits the usage of the SIP event
notification framework to report SIP-related event state.
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 9]
Internet-Draft SIP General Events May 2007
6. IANA Considerations
This document has no actions for IANA.
7. Security considerations
This document discusses the usage of the SIP event notification
framework for reporting non-SIP state. The document itself does not
define a protocol. However, certain security features of SIP are
discussed throughout it.
8. References
8.1. Normative References
[1] 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.
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
8.2. Informational References
[3] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[5] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[6] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)",
RFC 3842, August 2004.
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
[8] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 10]
Internet-Draft SIP General Events May 2007
[9] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", RFC 3857,
August 2004.
[10] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[11] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[13] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[14] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[15] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "Functional Description of Event Notification
Filtering", RFC 4660, September 2006.
[16] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)", RFC 4730,
November 2006.
[17] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
J., and J. Rosenberg, "Common Policy: A Document Format for
Expressing Privacy Preferences", RFC 4745, February 2007.
[18] Singh, V., "Vehicle Info Event Package",
draft-singh-simple-vehicle-info-00 (work in progress),
February 2007.
[19] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-08 (work in progress), March 2007.
[20] Tschofenig, H., "SIP SAML Profile and Binding",
draft-ietf-sip-saml-01 (work in progress), October 2006.
[21] Niemi, A., "Session Initiation Protocol (SIP) Event
Notification Extension for Notification Throttling",
draft-niemi-sipping-event-throttle-05 (work in progress),
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 11]
Internet-Draft SIP General Events May 2007
March 2007.
[22] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-09 (work in progress),
March 2007.
[23] Garcia-Martin, M., "A Framework for Sharing Resources with the
Session Initiation Protocol (SIP)",
draft-garcia-sipping-resource-sharing-framework-01 (work in
progress), December 2006.
[24] Garcia-Martin, M. and M. Matuszewski, "A Session Initiation
Protocol (SIP) Event Package and Data Format for Describing
Generic Resources",
draft-garcia-sipping-resource-event-package-01 (work in
progress), December 2006.
[25] Niemi, A., "Session Initiation Protocol Event Packages for
Calendaring", draft-niemi-sipping-cal-events-01 (work in
progress), March 2006.
[26] Mahy, R., "Sieve Notification Using the Session Initiation
Protocol (SIP) Message Summary and Message Waiting Indication
Event Package", draft-mahy-sieve-notify-sip-00 (work in
progress), January 2007.
Authors' Addresses
Miguel A. Garcia-Martin
Nokia Siemens Networks
P.O.Box 6
Nokia Siemens Networks, FIN 02022
Finland
Email: miguel.garcia@nsn.com
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 12]
Internet-Draft SIP General Events May 2007
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York 10027
USA
Phone: +1 212 939 7042
Email: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 13]
Internet-Draft SIP General Events May 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).
Garcia-Martin & Schulzrinne Expires November 12, 2007 [Page 14]