rfc3265.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,440 行 · 第 1/5 页

3.1. Description of SUBSCRIBE Behavior

   The SUBSCRIBE method is used to request current state and state
   updates from a remote node.

3.1.1. Subscription Duration

   SUBSCRIBE requests SHOULD contain an "Expires" header (defined in SIP
   [1]).  This expires value indicates the duration of the subscription.
   In order to keep subscriptions effective beyond the duration
   communicated in the "Expires" header, subscribers need to refresh
   subscriptions on a periodic basis using a new SUBSCRIBE message on
   the same dialog as defined in SIP [1].

   If no "Expires" header is present in a SUBSCRIBE request, the implied
   default is defined by the event package being used.

   200-class responses to SUBSCRIBE requests also MUST contain an
   "Expires" header.  The period of time in the response MAY be shorter
   but MUST NOT be longer than specified in the request.  The period of
   time in the response is the one which defines the duration of the
   subscription.

   An "expires" parameter on the "Contact" header has no semantics for
   SUBSCRIBE and is explicitly not equivalent to an "Expires" header in
   a SUBSCRIBE request or response.

   A natural consequence of this scheme is that a SUBSCRIBE with an
   "Expires" of 0 constitutes a request to unsubscribe from an event.

      In addition to being a request to unsubscribe, a SUBSCRIBE message
      with "Expires" of 0 also causes a fetch of state; see section
      3.3.6.

   Notifiers may also wish to cancel subscriptions to events; this is
   useful, for example, when the resource to which a subscription refers
   is no longer available.  Further details on this mechanism are
   discussed in section 3.2.2.

3.1.2. Identification of Subscribed Events and Event Classes

   Identification of events is provided by three pieces of information:
   Request URI, Event Type, and (optionally) message body.






Roach                       Standards Track                     [Page 6]

RFC 3265            SIP-Specific Event Notification            June 2002


   The Request URI of a SUBSCRIBE request, most importantly, contains
   enough information to route the request to the appropriate entity per
   the request routing procedures outlined in SIP [1].  It also contains
   enough information to identify the resource for which event
   notification is desired, but not necessarily enough information to
   uniquely identify the nature of the event (e.g.,
   "sip:[e-mail]" would be an appropriate URI to subscribe
   to for my presence state; it would also be an appropriate URI to
   subscribe to the state of my voice mailbox).

   Subscribers MUST include exactly one "Event" header in SUBSCRIBE
   requests, indicating to which event or class of events they are
   subscribing.  The "Event" header will contain a token which indicates
   the type of state for which a subscription is being requested.  This
   token will be registered with the IANA and will correspond to an
   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 token which
   identifies the specific subscription within a dialog.  An "id"
   parameter is only valid within the scope of a single dialog.

   If the event package to which the event token corresponds defines
   behavior associated with the body of its SUBSCRIBE requests, those
   semantics apply.

   Event packages may also define parameters for the Event header; if
   they do so, they must define the semantics for such parameters.

3.1.3. Additional SUBSCRIBE Header Values

   Because SUBSCRIBE requests create a dialog as defined in SIP [1],
   they MAY contain an "Accept" header.  This header, if present,
   indicates the body formats allowed in subsequent NOTIFY requests.
   Event packages MUST define the behavior for SUBSCRIBE requests
   without "Accept" headers; usually, this will connote a single,
   default body type.

   Header values not described in this document are to be interpreted as
   described in SIP [1].

3.1.4. Subscriber SUBSCRIBE Behavior

3.1.4.1. Requesting a Subscription

   SUBSCRIBE is a dialog-creating method, as described in SIP [1].

   When a subscriber wishes to subscribe to a particular state for a
   resource, it forms a SUBSCRIBE message.  If the initial SUBSCRIBE



Roach                       Standards Track                     [Page 7]

RFC 3265            SIP-Specific Event Notification            June 2002


   represents a request outside of a dialog (as it typically will), its
   construction follows the procedures outlined in SIP [1] for UAC
   request generation outside of a dialog.

   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
   authorized to subscribe to the requested resource.  A 202 response
   merely indicates that the subscription has been understood, and that
   authorization may or may not have been granted.

   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
   non-200 class responses (with the exception of "489", described
   herein) have the same meanings and handling as described in SIP [1].

   A SUBSCRIBE request MAY include an "id" parameter in its "Event"
   header to allow differentiation between multiple subscriptions in the
   same dialog.

3.1.4.2. Refreshing of Subscriptions

   At any time before a subscription expires, the subscriber may refresh
   the timer on such a subscription by sending another SUBSCRIBE request
   on the same dialog as the existing subscription, and with the same
   "Event" header "id" parameter (if one was present in the initial
   subscription).  The handling for such a request is the same as for
   the initial creation of a subscription except as described below.

      If the initial SUBSCRIBE message contained an "id" parameter on
      the "Event" header, then refreshes of the subscription must also
      contain an identical "id" parameter; they will otherwise be
      considered new subscriptions in an existing dialog.

   If a SUBSCRIBE request to refresh a subscription receives a "481"
   response, this indicates that the subscription has been terminated
   and that the subscriber did not receive notification of this fact.
   In this case, the subscriber should consider the subscription
   invalid.  If the subscriber wishes to re-subscribe to the state, he
   does so by composing an unrelated initial SUBSCRIBE request with a
   freshly-generated Call-ID and a new, unique "From" tag (see section
   3.1.4.1.)




Roach                       Standards Track                     [Page 8]

RFC 3265            SIP-Specific Event Notification            June 2002


   If a SUBSCRIBE request to refresh a subscription fails with a non-481
   response, the original subscription is still considered valid for the
   duration of the most recently known "Expires" value as negotiated by
   SUBSCRIBE and its response, or as communicated by NOTIFY in the
   "Subscription-State" header "expires" parameter.

      Note that many such errors indicate that there may be a problem
      with the network or the notifier such that no further NOTIFY
      messages will be received.

3.1.4.3. Unsubscribing

   Unsubscribing is handled in the same way as refreshing of a
   subscription, with the "Expires" header set to "0".  Note that a
   successful unsubscription will also trigger a final NOTIFY message.

3.1.4.4. Confirmation of Subscription Creation

   The subscriber can expect to receive a NOTIFY message from each node
   which has processed a successful subscription or subscription
   refresh.  Until the first NOTIFY message arrives, the subscriber
   should consider the state of the subscribed resource to be in a
   neutral state.  Documents which define new event packages MUST define
   this "neutral state" in such a way that makes sense for their
   application (see section 4.4.7.).

   Due to the potential for both out-of-order messages and forking, the
   subscriber MUST be prepared to receive NOTIFY messages before the
   SUBSCRIBE transaction has completed.

   Except as noted above, processing of this NOTIFY is the same as in
   section 3.2.4.

3.1.5. Proxy SUBSCRIBE Behavior

   Proxies need no additional behavior beyond that described in SIP [1]
   to support SUBSCRIBE.  If a proxy wishes to see all of the SUBSCRIBE
   and NOTIFY requests for a given dialog, it MUST record-route the
   initial SUBSCRIBE and any dialog-establishing NOTIFY requests.  Such
   proxies SHOULD also record-route all other SUBSCRIBE and NOTIFY
   requests.

      Note that subscribers and notifiers may elect to use S/MIME
      encryption of SUBSCRIBE and NOTIFY requests; consequently, proxies
      cannot rely on being able to access any information that is not
      explicitly required to be proxy-readable by SIP [1].





Roach                       Standards Track                     [Page 9]

RFC 3265            SIP-Specific Event Notification            June 2002


3.1.6. Notifier SUBSCRIBE Behavior

3.1.6.1. Initial SUBSCRIBE Transaction Processing

   In no case should a SUBSCRIBE transaction extend for any longer than
   the time necessary for automated processing.  In particular,
   notifiers MUST NOT wait for a user response before returning a final
   response to a SUBSCRIBE request.

      This requirement is imposed primarily to prevent the non-INVITE
      transaction timeout timer F (see [1]) from firing during the
      SUBSCRIBE transaction, since interaction with a user would often
      exceed 64*T1 seconds.

   The notifier SHOULD check that the event package specified in the
   "Event" 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 and
   authorization per its local policy.  See section 3.1.6.3.

   The notifier MAY also check that the duration in the "Expires" header
   is not too small.  If and only if the expiration interval is greater
   than zero AND smaller than one hour AND less than a notifier-
   configured minimum, the notifier MAY return a "423 Interval too
   small" error which contains a "Min-Expires" header field.  The "Min-
   Expires" header field is described in SIP [1].

   If the notifier is able to immediately determine that it understands
   the event package, that the authenticated subscriber is authorized to
   subscribe, and that there are no other barriers to creating the
   subscription, it creates the subscription and a dialog (if
   necessary), and returns a "200 OK" response (unless doing so would
   reveal authorization policy in an undesirable fashion; see section
   5.2.).

   If the notifier cannot immediately create the subscription (e.g., it
   needs to wait for user input for authorization, or is acting for
   another node which is not currently reachable), or wishes to mask
   authorization policy, it will return a "202 Accepted" response.  This
   response indicates that the request has been received and understood,
   but does not necessarily imply that the subscription has been
   authorized yet.

   When a subscription is created in the notifier, it stores the event
   package name and the "Event" header "id" parameter (if present) as
   part of the subscription information.



Roach                       Standards Track                    [Page 10]

RFC 3265            SIP-Specific Event Notification            June 2002


   The "Expires" values present in SUBSCRIBE 200-class responses behave
   in the same way as they do in REGISTER responses: the server MAY
   shorten the interval, but MUST NOT lengthen it.

      If the duration specified in a SUBSCRIBE message is unacceptably
      short, the notifier may be able to send a 423 response, as
      described earlier in this section.

   200-class responses to SUBSCRIBE requests will not generally contain
   any useful information beyond subscription duration; their primary