RFC 3265 (rfc3265) - Page 3 of 38
Session Initiation Protocol (SIP)-Specific Event Notification
Alternative Format: Original Text Document
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
