rfc3857 a watcher information event template-package for.txt

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

RFC 3857                  Watcher Information                August 2004


   Of course, policy may never be specified for the subscription.  As a
   result, the server can generate a giveup event to move the waiting
   subscription to the terminated state.  The amount of time to wait
   before issuing a giveup event is system dependent.

   The giveup event is generated in either the waiting or pending states
   to destroy resources associated with unauthorized subscriptions.
   This event is generated when a giveup timer fires. This timer is set
   to a timeout value when entering either the pending or waiting
   states.  Servers need to exercise care in selecting this value.  It
   needs to be large in order to provide a useful user experience; a
   user should be able to log in days later and see that someone tried
   to subscribe to them.  However, allocating state to unauthorized
   subscriptions can be used as a source of DoS attacks.  Therefore, it
   is RECOMMENDED that servers that retain state for unauthorized
   subscriptions add policies which prohibit a particular subscriber
   from having more than some number of pending or waiting
   subscriptions.

   At any time, the server can deactivate a subscription.  Deactivation
   implies that the subscription is discarded without a change in
   authorization policy.  This may be done in order to trigger refreshes
   of subscriptions for a graceful shutdown or subscription migration
   operation.  A related event is probation, where a subscription is
   terminated, and the subscriber is requested to wait some amount of
   time before trying again.  The meaning of these events is described
   in more detail in Section 3.2.4 of RFC 3265 [1].

   A subscription can be terminated at any time because the resource
   associated with that subscription no longer exists.  This corresponds
   to the noresource event.

4.7.2.  Applying the State Machine

   The server MAY generate a notification to watcherinfo subscribers on
   a transition of the state machine.  Whether it does or not is policy
   dependent.  However, several guidelines are defined.

   Consider some event package foo.  A subscribes to B for events within
   that package.  A also subscribes to foo.winfo for B.  In this
   scenario (where the subscriber to foo.winfo is also a subscriber to
   foo for the same resource), it is RECOMMENDED that A receive
   watcherinfo notifications only about the changes in its own
   subscription.  Normally, A will receive notifications about changes
   in its subscription to foo through the Subscription-State header
   field.  This will frequently obviate the need for a separate
   subscription to foo.winfo.  However, if such a subscription is
   performed by A, the foo.winfo notifications SHOULD NOT report any



Rosenberg                   Standards Track                    [Page 11]

RFC 3857                  Watcher Information                August 2004


   state changes which would not be reported (because of authorization
   policy) in the Subscription-State header field in notifications on
   foo.

   As a general rule, when a watcherinfo subscriber is authorized to
   receive watcherinfo notifications about more than one watcher, it is
   RECOMMENDED that watcherinfo notifications contain information about
   those watchers which have changed state (and thus triggered a
   notification), instead of delivering the current state of every
   watcher in every watcherinfo notification.  However, watcherinfo
   notifications triggered as a result of a fetch operation (a SUBSCRIBE
   with Expires of 0) SHOULD result in the full state of all watchers
   (of course, only those watchers that have been authorized to be
   divulged to the watcherinfo subscriber) to be present in the NOTIFY.

   Frequently, states in the subscription state machine will be
   transient.  For example, if an authorized watcher performs a fetch
   operation, this will cause the state machine to be created,
   transition from init to active, and then from active to terminated,
   followed by a destruction of the FSM.  In such cases, watcherinfo
   notifications SHOULD NOT be sent for any transient states.  In the
   prior example, the server wouldn't send any notifications, since all
   of the states are transient.

4.8.  Subscriber Processing of NOTIFY Requests

   RFC 3265 [1] expects packages to specify how a subscriber processes
   NOTIFY requests in any package specific ways, and in particular, how
   it uses the NOTIFY requests to construct a coherent view of the state
   of the subscribed resource.  Typically, the watcherinfo NOTIFY will
   only contain information about those watchers whose state has
   changed.  To construct a coherent view of the total state of all
   watchers, a watcherinfo subscriber will need to combine NOTIFYs
   received over time.  This details of this process depend on the
   document format.  See [3] for details on the
   application/watcherinfo+xml format.

4.9.  Handling of Forked Requests

   The SIP Events framework mandates that packages indicate whether or
   not forked SUBSCRIBE requests can install multiple subscriptions.

   When a user wishes to obtain watcher information for some resource
   for package foo, the SUBSCRIBE to the watcher information will need
   to reach a collection of servers that have, unioned together,
   complete information about all watchers on that resource for package
   foo.  If there are a multiplicity of servers handling subscriptions
   for that resource for package foo (for load balancing reasons,



Rosenberg                   Standards Track                    [Page 12]

RFC 3857                  Watcher Information                August 2004


   typically), it is very likely that no single server will have the
   complete set of watcher information.  There are several solutions in
   this case.  This specification does not mandate a particular one, nor
   does it rule out others.  It merely ensures that a broad range of
   solutions can be built.

   One solution is to use forking.  The system can be designed so that a
   SUBSCRIBE for watcher information arrives at a special proxy which is
   aware of the requirements for watcher information.  This proxy would
   fork the SUBSCRIBE request to all of the servers which could possibly
   maintain subscriptions for that resource for that package.  Each of
   these servers, whether or not they have any current subscribers for
   that resource, would accept the watcherinfo subscription.  Each needs
   to accept because they may all eventually receive a subscription for
   that resource.  The watcherinfo subscriber would receive some number
   of watcherinfo NOTIFY requests, each of which establishes a separate
   dialog.  By aggregating the information across each dialog, the
   watcherinfo subscriber can compute full watcherinfo state.  In many
   cases, a particular dialog might never generate any watcherinfo
   notifications; this would happen if the servers never receive any
   subscriptions for the resource.

   In order for such a system to be built in an interoperable fashion,
   all watcherinfo subscribers MUST be prepared to install multiple
   subscriptions as a result of a multiplicity of NOTIFY messages in
   response to a single SUBSCRIBE.

   Another approach for handling the server multiplicity problem is to
   use state agents.  See Section 4.11 for details.

4.10.  Rate of Notifications

   RFC 3265 [1] mandates that packages define a maximum rate of
   notifications for their package.

   For reasons of congestion control, it is important that the rate of
   notifications not become excessive.  As a result, it is RECOMMENDED
   that the server not generate watcherinfo notifications for a single
   watcherinfo subscriber at a rate faster than once every 5 seconds.

4.11.  State Agents

   RFC 3265 [1] asks packages to consider the role of state agents in
   their design.

   State agents play an important role in this package.  As discussed in
   Section 4.9, there may be a multiplicity of servers sharing the load
   of subscriptions for a particular package.  A watcherinfo



Rosenberg                   Standards Track                    [Page 13]

RFC 3857                  Watcher Information                August 2004


   subscription might require subscription state spread across all of
   those servers. To handle that, a farm of state agents can be used.
   Each of these state agents would know the entire watcherinfo state
   for some set of resources.  The means by which the state agents would
   determine the full watcherinfo state is outside the scope of this
   specification. When a watcherinfo subscription is received, it would
   be routed to a state agent that has the full watcherinfo state for
   the requested resource.  This server would accept the watcherinfo
   subscription (assuming it was authorized, of course), and generate
   watcherinfo notifications as the watcherinfo state changed.  The
   watcherinfo subscriber would only have a single dialog in this case.

5.  Example Usage

   The following section discusses an example application and call flows
   using the watcherinfo package.

   In this example, a user Joe, sip:[e-mail] provides presence
   through the example.com presence server.  Joe subscribes to his own
   watcher information, in order to learn about people who subscribe to
   his presence, so that he can approve or reject their subscriptions.
   Joe sends the following SUBSCRIBE request:

   SUBSCRIBE sip:[e-mail] SIP/2.0
   Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
   From: sip:[e-mail];tag=123aa9
   To: sip:[e-mail]
   Call-ID: [e-mail]
   CSeq: 9887 SUBSCRIBE
   Contact: sip:[e-mail]
   Event: presence.winfo
   Max-Forwards: 70

   The server responds with a 401 to authenticate, and Joe resubmits the
   SUBSCRIBE with credentials (message not shown).  The server then
   authorizes the subscription, since it allows Joe to subscribe to his
   own watcher information for presence.  It responds with a 200 OK:

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds8
     ;received=192.0.2.8
   From: sip:[e-mail];tag=123aa9
   To: sip:[e-mail];tag=xyzygg
   Call-ID: [e-mail]
   CSeq: 9988 SUBSCRIBE
   Contact: sip:server19.example.com
   Expires: 3600
   Event: presence.winfo



Rosenberg                   Standards Track                    [Page 14]

RFC 3857                  Watcher Information                August 2004


   The server then sends a NOTIFY with the current state of
   presence.winfo for [e-mail]:

   NOTIFY sip:[e-mail] SIP/2.0
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
   From: sip:[e-mail];tag=xyzygg
   To: sip:[e-mail];tag=123aa9
   Call-ID: [e-mail]
   CSeq: 1288 NOTIFY
   Contact: sip:server19.example.com
   Event: presence.winfo
   Subscription-State: active
   Max-Forwards: 70
   Content-Type: application/watcherinfo+xml
   Content-Length: ...

   <?xml version="1.0"?>
   <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
                version="0" state="full">
     <watcher-list resource="sip:[e-mail]" package="presence">
       <watcher id="77ajsyy76" event="subscribe"
                status="pending">sip:[e-mail]</watcher>
     </watcher-list>
   </watcherinfo>

   Joe then responds with a 200 OK to the NOTIFY:

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
     ;received=192.0.2.7
   From: sip:[e-mail];tag=xyzygg
   To: sip:[e-mail];tag=123aa9
   Call-ID: [e-mail]
   CSeq: 1288 NOTIFY

















Rosenberg                   Standards Track                    [Page 15]

RFC 3857                  Watcher Information                August 2004