rfc 3856 a presence event package for the session initiation protocol (sip).htm

有关IMS SIP及Presence应用的RFC文档包

   response is returned.  In both cases, the PA sends an immediate
   NOTIFY message containing the state of the presentity and of the
   subscription.  The presentity state may be bogus in the case of a
   pending subscription, indicating offline no matter what the actual
   state of the presentity, for example.  This is to protect the privacy
   of the presentity, who may not want to reveal that they have not
   provided authorization for the subscriber.  As the state of the
   presentity changes, the PA generates NOTIFYs containing those state
   changes to all subscribers with authorized subscriptions.  Changes in
   the state of the subscription itself can also trigger NOTIFY
   requests; that state is carried in the Subscription-State header
   field of the NOTIFY, and would typically indicate whether the
   subscription is active or pending.

   The SUBSCRIBE message establishes a "dialog" with the presence agent.
   A dialog is defined in <A href="http://tools.ietf.org/html/rfc3261">RFC 3261</A> [<A title='"SIP: Session Initiation Protocol"' href="http://tools.ietf.org/html/rfc3856#ref-1">1</A>], and it represents the SIP state
   between a pair of entities to facilitate peer-to-peer message
   exchanges.  This state includes the sequence numbers for messages in
   both directions (SUBSCRIBE from the subscriber, NOTIFY from the
   presence agent), in addition to a route set and remote target URI.
   The route set is a list of SIP (or SIPS) URIs which identify SIP
   proxy servers that are to be visited along the path of SUBSCRIBE
   refreshes or NOTIFY requests.  The remote target URI is the SIP or
   SIPS URI that identifies the target of the message - the subscriber,
   in the case of NOTIFY, or the presence agent, in the case of a
   SUBSCRIBE refresh.

   SIP provides a procedure called record-routing that allows for proxy
   servers to request to be on the path of NOTIFY messages and SUBSCRIBE
   refreshes.  This is accomplished by inserting a URI into the
   Record-Route header field in the initial SUBSCRIBE request.

   The subscription persists for a duration that is negotiated as part
   of the initial SUBSCRIBE.  The subscriber will need to refresh the
   subscription before its expiration, if they wish to retain the
   subscription.  This is accomplished by sending a SUBSCRIBE refresh
   within the same dialog established by the initial SUBSCRIBE.  This
   SUBSCRIBE is nearly identical to the initial one, but contains a tag
   in the To header field, a higher CSeq header field value, and
   possibly a set of Route header field values that identify the path of
   proxies the request is to take.




<SPAN class=grey>Rosenberg                   Standards Track                     [Page 5]</SPAN>
<A id=page-6 href="http://tools.ietf.org/html/rfc3856#page-6" name=page-6><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3856">RFC 3856</A>                      SIP Presence                   August 2004</SPAN>


   The subscriber can terminate the subscription by sending a SUBSCRIBE,
   within the dialog, with an Expires header field (which indicates
   duration of the subscription) value of zero.  This causes an
   immediate termination of the subscription.  A NOTIFY request is then
   generated by the presence agent with the most recent state.  In fact,
   behavior of the presence agent for handling a SUBSCRIBE request with
   Expires of zero is no different than for any other expiration value;
   pending or authorized SUBSCRIBE requests result in a triggered NOTIFY
   with the current presentity and subscription state.

   The presence agent can terminate the subscription at any time.  To do
   so, it sends a NOTIFY request with a Subscription-State header field
   indicating that the subscription has been terminated.  A reason
   parameter can be supplied which provides the reason.

   It is also possible to fetch the current presence state, resulting in
   a one-time notification containing the current state.  This is
   accomplished by sending a SUBSCRIBE request with an immediate
   expiration.

<SPAN class=h2><A name=section-5>5</A>.  Usage of Presence URIs</SPAN>

   A presentity is identified in the most general way through a presence
   URI [<A title='"Common Profile for Presence (CPP)"' href="http://tools.ietf.org/html/rfc3856#ref-3">3</A>], which is of the form pres:user@domain.  These URIs are
   resolved to protocol specific URIs, such as the SIP or SIPS URI,
   through domain-specific mapping policies maintained on a server.

   It is very possible that a user will have both a SIP (and/or SIPS)
   URI and a pres URI to identify both themself and other users.  This
   leads to questions about how these URI relate and which are to be
   used.

   In some instances, a user starts with one URI format, such as the
   pres URI, and learns a URI in a different format through some
   protocol means.  As an example, a SUBSCRIBE request sent to a pres
   URI will result in learning a SIP or SIPS URI for the presentity from
   the Contact header field of the 200 OK to the SUBSCRIBE request.  As
   another example, a DNS mechanism might be defined that would allow
   lookup of a pres URI to obtain a SIP or SIPS URI.  In cases where one
   URI is learned from another through protocol means, those means will
   often provide some kind of scoping that limit the lifetime of the
   learned URI.  DNS, for example, provides a TTL which would limit the
   scope of the URI.  These scopes are very useful to avoid stale or
   conflicting URIs for identifying the same resource.  To ensure that a
   user can always determine whether a learned URI is still valid, it is
   RECOMMENDED that systems which provide lookup services for presence
   URIs have some kind of scoping mechanism.




<SPAN class=grey>Rosenberg                   Standards Track                     [Page 6]</SPAN>
<A id=page-7 href="http://tools.ietf.org/html/rfc3856#page-7" name=page-7><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3856">RFC 3856</A>                      SIP Presence                   August 2004</SPAN>


   If a subscriber is only aware of the protocol-independent pres URI
   for a presentity, it follows the procedures defined in [<A title='"Address Resolution for Instant Messaging and Presence"' href="http://tools.ietf.org/html/rfc3856#ref-5">5</A>].  These
   procedures will result in the placement of the pres URI in the
   Request-URI of the SIP request, followed by the usage of the DNS
   procedures defined in [<A title='"Address Resolution for Instant Messaging and Presence"' href="http://tools.ietf.org/html/rfc3856#ref-5">5</A>] to determine the host to send the SIP
   request to.  Of course, a local outbound proxy may alternatively be
   used, as specified in <A href="http://tools.ietf.org/html/rfc3261">RFC 3261</A> [<A title='"SIP: Session Initiation Protocol"' href="http://tools.ietf.org/html/rfc3856#ref-1">1</A>].  If the subscriber is aware of
   both the protocol-independent pres URI and the SIP or SIPS URI for
   the same presentity, and both are valid (as discussed above) it
   SHOULD use the pres URI format.  Of course, if the subscriber only
   knows the SIP URI for the presentity, that URI is used, and standard
   <A href="http://tools.ietf.org/html/rfc3261">RFC 3261</A> processing will occur. When the pres URI is used, any
   proxies along the path of the SUBSCRIBE request which do not
   understand the URI scheme will reject the request.  As such, it is
   expected that many systems will be initially deployed that only
   provide users with a SIP URI.

   SUBSCRIBE messages also contain logical identifiers that define the
   originator and recipient of the subscription (the To and From header
   fields).  These headers can take either a pres or SIP URI.  When the
   subscriber is aware of both a pres and SIP URI for its own identity,
   it SHOULD use the pres URI in the From header field.  Similarly, when
   the subscriber is aware of both a pres and a SIP URI for the desired
   presentity, it SHOULD use the pres URI in the To header field.

   The usage of the pres URI instead of the SIP URI within the SIP
   message supports interoperability through gateways to other
   CPP-compliant systems.  It provides a protocol-independent form of
   identification which can be passed between systems.  Without such an
   identity, gateways would be forced to map SIP URIs into the
   addressing format of other protocols.  Generally, this is done by
   converting the SIP URI to the form &lt;foreign-protocol-scheme&gt;:&lt;encoded
   SIP URI&gt;@&lt;gateway&gt;.  This is commonly done in email systems, and has
   many known problems.  The usage of the pres URI is a SHOULD, and not
   a MUST, to allow for cases where it is known that there are no
   gateways present, or where the usage of the pres URI will cause
   interoperability problems with SIP components that do not support the
   pres URI.

   The Contact, Record-Route and Route fields do not identify logical
   entities, but rather concrete ones used for SIP messaging.  SIP [<A title='"SIP: Session Initiation Protocol"' href="http://tools.ietf.org/html/rfc3856#ref-1">1</A>]
   specifies rules for their construction.

<SPAN class=h2><A name=section-6>6</A>.  Presence Event Package</SPAN>

   The SIP event framework [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>] defines a SIP extension for subscribing
   to, and receiving notifications of, events.  It leaves the definition
   of many aspects of these events to concrete extensions, known as



<SPAN class=grey>Rosenberg                   Standards Track                     [Page 7]</SPAN>
<A id=page-8 href="http://tools.ietf.org/html/rfc3856#page-8" name=page-8><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3856">RFC 3856</A>                      SIP Presence                   August 2004</SPAN>


   event packages.  This document qualifies as an event package.  This
   section fills in the information required for all event packages by
   <A href="http://tools.ietf.org/html/rfc3265">RFC 3265</A> [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>].

<SPAN class=h3><A name=section-6.1>6.1</A>.  Package Name</SPAN>

   The name of this package is "presence".  As specified in <A href="http://tools.ietf.org/html/rfc3265">RFC 3265</A>
   [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>], this value appears in the Event header field present in
   SUBSCRIBE and NOTIFY requests.

   Example:

   Event: presence

<SPAN class=h3><A name=section-6.2>6.2</A>.  Event Package Parameters</SPAN>

   The SIP event framework allows event packages to define additional
   parameters carried in the Event header field.  This package,
   presence, does not define any additional parameters.

<SPAN class=h3><A name=section-6.3>6.3</A>.  SUBSCRIBE Bodies</SPAN>

   A SUBSCRIBE request MAY contain a body.  The purpose of the body
   depends on its type.  Subscriptions will normally not contain bodies.

   The Request-URI, which identifies the presentity, combined with the
   event package name, is sufficient for presence.

   One type of body that can be included in a SUBSCRIBE request is a
   filter document.  These filters request that only certain presence
   events generate notifications, or would ask for a restriction on the
   set of data returned in NOTIFY requests.  For example, a presence
   filter might specify that the notifications should only be generated
   when the status of the user's instant inbox [<A title='"A Model for Presence and Instant Messaging"' href="http://tools.ietf.org/html/rfc3856#ref-10">10</A>] changes.  It might
   also say that the content of these notifications should only contain
   the status of the instant inbox.  Filter documents are not specified
   in this document, and at the time of writing, are expected to be the
   subject of future standardization activity.

   Honoring of these filters is at the policy discretion of the PA.

   If the SUBSCRIBE request does not contain a filter, this tells the PA
   that no filter is to be applied.  The PA SHOULD send NOTIFY requests
   at the discretion of its own policy.







<SPAN class=grey>Rosenberg                   Standards Track                     [Page 8]</SPAN>