RFC 3265 (rfc3265) - Page 3 of 38

Session Initiation Protocol (SIP)-Specific Event Notification

RFC 3265            SIP-Specific Event Notification            June 2002


   7.1.     New Methods............................................ 32
   7.1.1.   SUBSCRIBE method....................................... 34
   7.1.2.   NOTIFY method.......................................... 34
   7.2.     New Headers............................................ 34
   7.2.1.   "Event" header......................................... 34
   7.2.2.   "Allow-Events" Header.................................. 35
   7.2.3.   "Subscription-State" Header............................ 35
   7.3.     New Response Codes..................................... 35
   7.3.1.   "202 Accepted" Response Code........................... 35
   7.3.2.   "489 Bad Event" Response Code.......................... 35
   7.4.     Augmented BNF Definitions.............................. 35
   8.       Normative References................................... 36
   9.       Informative References................................. 37
   10.      Acknowledgements....................................... 37
   11.      Notice Regarding Intellectual Property Rights.......... 37
   12.      Author's Address....................................... 37
   13.      Full Copyright Statement............................... 38

1. Introduction

   The ability to request asynchronous notification of events proves
   useful in many types of SIP services for which cooperation between
   end-nodes is required.  Examples of such services include automatic
   callback services (based on terminal state events), buddy lists
   (based on user presence events), message waiting indications (based
   on mailbox state change events), and PSTN and Internet
   Internetworking (PINT) [2] status (based on call state events).

   The methods described in this document provide a framework by which
   notification of these events can be ordered.

   The event notification mechanisms defined herein are NOT intended to
   be a general-purpose infrastructure for all classes of event
   subscription and notification.  Meeting requirements for the general
   problem set of subscription and notification is far too complex for a
   single protocol.  Our goal is to provide a SIP-specific framework for
   event notification which is not so complex as to be unusable for
   simple features, but which is still flexible enough to provide
   powerful services.  Note, however, that event packages based on this
   framework may define arbitrarily elaborate rules which govern the
   subscription and notification for the events or classes of events
   they describe.

   This document does not describe an extension which may be used
   directly; it must be extended by other documents (herein referred to
   as "event packages").  In object-oriented design terminology, it may





Roach                       Standards Track