class
Click on the red underlined text to get to the source
... 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 ...
... framework may define arbitrarily elaborate rules which govern the
subscription and notification for the events or classes of events
they describe.
...
... event packages"). In object-oriented design terminology, it may
be thought of as an abstract base class which must be derived into an
instantiatable class by further extensions. Guidelines for creating
...
... be thought of as an abstract base class which must be derived into an
instantiatable class by further extensions. Guidelines for creating
these extensions are described in section 4.
...
... event package being used.
200-class responses to SUBSCRIBE requests also MUST contain an
"Expires" header ...
... Identification of Subscribed Events and Event Classes ...
... header in SUBSCRIBE
requests, indicating to which event or class of events they are
subscribing. The "Event" header ...
... event package which further describes the semantics of the event or
event class. The "Event" header MAY also contain an "id" parameter.
This "id" parameter, if present, contains an opaque ...
... This SUBSCRIBE request will be confirmed with a final response.
200-class responses indicate that the subscription has been accepted,
and that a NOTIFY will be sent immediately. A 200 response indicates
that the subscription has been accepted and that the user is
...
...
The "Expires" header in a 200-class response to SUBSCRIBE indicates
the actual duration for which the subscription will remain active ...
... (unless refreshed).
Non-200 class final responses indicate that no subscription or dialog
has been created, and no subsequent NOTIFY message will be sent. All
...
... has been created, and no subsequent NOTIFY message will be sent. All
non-200 class responses (with the exception of "489", described
herein) have the same meanings and handling as described in SIP [1 ...
... header is understood. If not, the notifier SHOULD return a
"489 Bad Event" response to indicate that the specified event/event
class is not understood.
The notifier SHOULD also perform any necessary authentication ...
...
The "Expires" values present in SUBSCRIBE 200-class responses behave
in the same way as they do in REGISTER responses: the server MAY
...
... described earlier in this section.
200-class responses to SUBSCRIBE requests will not generally contain
any useful information beyond subscription duration; their primary
...
...
Note that a NOTIFY message is always sent immediately after any 200-
class response to a SUBSCRIBE request, regardless of whether the
subscription has already been authorized.
...
... node. The latter behavior is invalid, and
MUST receive a "481 Subscription does not exist" response (unless
some other 400- or 500-class error code is more applicable), as
described in section 3.2.4. In other words, knowledge of a
...
... Identification of Reported Events, Event Classes, and Current State ...
...
When a SUBSCRIBE request is answered with a 200-class response, the
notifier MUST immediately construct and send a NOTIFY request to the
subscriber ...
...
A NOTIFY request is considered failed if the response times out, or a
non-200 class response code is received which has no "Retry-After"
...
... matches at least one of its outstanding subscriptions; if not, it
MUST return a "481 Subscription does not exist" response unless
another 400- or 500-class response is more appropriate. The rules
for matching NOTIFY requests with subscriptions that create a new
...
... 1], successful SUBSCRIBE requests will receive only
one 200-class response; however, due to forking, the subscription may
have been accepted by multiple nodes. The subscriber ...
... from the "To:" tag received in the SUBSCRIBE 200-class response.
If multiple NOTIFY messages are received in different dialogs in
...
... If an initial SUBSCRIBE is sent on a pre-existing dialog, a matching
200-class response or successful NOTIFY request merely creates a new
subscription associated with that dialog.
...
... In some circumstances, conveying the current state alone may be
insufficient for a particular class of events. In these cases, the
event packages should include complete state ...
... filter, throttle, and/or set thresholds for
the class of events being requested. Designers of event packages are
strongly encouraged to re-use existing MIME types ...
... and "Event" header "id" parameter) but which do not match the dialog
would be rejected with a 481 response. Note that the 200-class
response to the SUBSCRIBE can arrive after a matching NOTIFY has been
...
... SUBSCRIBE is allowed, the subscriber establishes a new dialog towards
each notifier by returning a 200-class response to each NOTIFY. Each
dialog is then handled as its own entity, and is refreshed
...