SIP
Click on the red underlined text to get to the source
... asynchronous notification of events proves
useful in many types of SIP services for which cooperation between
end-nodes ...
... notification is far too complex for a
single protocol. Our goal is to provide a SIP-specific framework for
event notification ...
... SUBSCRIBE requests SHOULD contain an "Expires" header (defined in SIP
[1]). This expires value indicates the duration of the subscription.
...
... subscriptions on a periodic basis using a new SUBSCRIBE message on
the same dialog as defined in SIP [1].
...
... entity per
the request routing procedures outlined in SIP [1]. It also contains
enough information to identify the resource for which event
notification ...
... Because SUBSCRIBE requests create a dialog as defined in SIP [1],
they MAY contain an "Accept" header ...
...
represents a request outside of a dialog (as it typically will), its
construction follows the procedures outlined in SIP [1] for UAC
...
... non-200 class responses (with the exception of "489", described
herein) have the same meanings and handling as described in SIP [1].
...
... cannot rely on being able to access any information that is not
explicitly required to be proxy-readable by SIP [1].
...
... SIP authentication mechanisms are discussed in SIP [1]. Note that,
even if the notifier node ...
... network. Because such transmissions will be sent multiple
times, per the retransmission algorithm defined in SIP [1]
(instead of the typical single transmission for functioning
...
...
Proxies need no additional behavior beyond that described in SIP [1]
to support NOTIFY. If a proxy ...
... cannot rely on being able to access any information that is not
explicitly required to be proxy-readable by SIP [1].
...
... spoofing of events, NOTIFY requests SHOULD be
authenticated, using any defined SIP authentication mechanism.
...
... header.
Other responses defined in SIP [1] may also be returned, as
appropriate. In no case should a NOTIFY transaction ...
... In accordance with the rules for proxying non-INVITE requests as
defined in SIP [1], successful SUBSCRIBE requests will receive only
...
... comparison of these headers are described in
SIP [1]. If a 200-class response matches such a SUBSCRIBE ...
... methods described in this
document for event notification, it is important to consider: is SIP
an appropriate mechanism for the problem set? Is SIP being selected
...
... event notification, it is important to consider: is SIP
an appropriate mechanism for the problem set? Is SIP being selected
because of some unique feature provided by the protocol (e.g., user
mobility), or merely because "it can be done?" If you find yourself
...
... Those interested in extending the mechanism defined in this
document are urged to follow the development of "Guidelines for
Authors of SIP Extensions" [7] for further guidance regarding
appropriate uses of SIP ...
... SIP Extensions" [7] for further guidance regarding
appropriate uses of SIP.
Further, it is expected that this 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). A SIP network is
generally going to be provisioned for a reasonable signalling volume;
sending a notification ...
...
In addition to the normal sections expected in standards-track
RFCs and SIP extension documents, authors of event packages need
to address ...
... event packages may define state information which is
potentially too large to reasonably send in a SIP message. To
alleviate this problem, event packages may include the ability to
...
... identity (based on access control lists),
using standard SIP authentication mechanisms. The methods for
...
... The table below lists the event packages and template-packages
defined in "SIP-Specific Event Notification" [RFC3265prop]. Each name is
...
...
This section describes the syntax extensions required for event
notification in SIP. Semantics are described in section 3. Note
that the formal syntax ...
... formal syntax definitions described in this document are
expressed in the ABNF format used in SIP [1], and contain references
to elements ...
...
The NOTIFY method is used to notify a SIP node that an event which
has been requested by an earlier SUBSCRIBE ...
...
This table expands on tables 2 and 3 in SIP [1], as amended by the
changes described in section 7.1.
...
... element "message-header" in
the SIP message grammar.
For the purposes of matching responses and NOTIFY messages with
...
... element "general-
header" in the SIP message grammar. Its usage is described in
section 3.3.7.
...
... element
"request-header" in the SIP message grammar. Its usage is described
in section 3.2.4.
...
... Augmented BNF definitions for the various new and modified syntax
elements follows. The notation is as used in SIP [1], and any
elements ...
... 1], and any
elements not defined in this section are as defined in SIP and the
documents to which it refers.
...
... Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261prop, June 2002. ...
... Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of SIP Extensions", Work in Progress. ...
... Schulzrinne, H. and J. Rosenberg, "SIP Caller Preferences and Callee Capabilities", Work in Progress. ...
... IETF meeting
in Pittsburgh, as well as those who gave ideas and suggestions on the
SIP Events mailing list. In particular, I wish to thank Henning
Schulzrinne of Columbia University for coming up with the final
...
... event identification scheme, Sean Olson for
miscellaneous guidance, Jonathan Rosenberg for a thorough scrubbing
of the -00 draft, and the authors of the "SIP Extensions for
Presence" document for their input to SUBSCRIBE and NOTIFY request
...