SIP Presence (二)

SIP 消息流程，模糊了RLS 和PS 这些节点。 原来想和 （一）合在一起。还是单独写出来吧。 后面在继续一点XCAP部分，描述下RLS,PS 与XDMS 之间的业务和消息流程。

也就贴了下RFC 里的消息流程。

PUA                     PA                      WATCHER
         (EPA)                   (ESC)
           |                       |                         |
           |                       | <---- M1: SUBSCRIBE --- |
           |                       |                         |
           |                       | ----- M2: 200 OK -----> |
           |                       |                         |
           |                       | ----- M3: NOTIFY -----> |
           |                       |                         |
           |                       | <---- M4: 200 OK ------ |
           |                       |                         |
           |                       |                         |
           | ---- M5: PUBLISH ---> |                         |
           |                       |                         |
           | <--- M6: 200 OK ----  |                         |
           |                       |                         |
           |                       | ----- M7: NOTIFY -----> |
           |                       |                         |
           |                       | <---- M8: 200 OK ------ |
           |                       |                         |
           | ---- M9: PUBLISH ---> |                         |
           |                       |                         |
           | <--- M10: 200 OK ---  |                         |
           |                       |                         |
           |                       |                         |
           | --- M11: PUBLISH ---> |                         |
           |                       |                         |
           | <-- M12: 200 OK ----  |                         |
           |                       |                         |
           |                       | ----- M13: NOTIFY ----> |
           |                       |                         |
           |                       | <---- M14: 200 OK ----- |
           |                       |                         |

   Event State: State information for a resource, associated with an event package and an address-of-record.

   Event Publication Agent (EPA): The User Agent Client (UAC) that issues PUBLISH requests to publish event state.

   Event State Compositor (ESC): The User Agent Server (UAS) that processes PUBLISH requests, and is responsible for compositing event state into a complete, composite event state of a resource.

     A User Agent Client (UAC) that publishes event state is labeled an Event Publication Agent (EPA).  For presence, this is the familiar Presence User Agent

   (PUA) role. The entity that processes the PUBLISH request is known as an Event State Compositor

  

M1: The watcher initiates a new subscription to the
      presentity@example.com's presence agent.

      SUBSCRIBE sip:presentity@example.com SIP/2.0
      Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
      To: <sip:presentity@example.com>
      From: <sip:watcher@example.com>;tag=12341234
      Call-ID: 12345678@host.example.com
      CSeq: 1 SUBSCRIBE
      Max-Forwards: 70
      Expires: 3600
      Event: presence            ( 如果是Watcher information 的SUBSCRIBER，Event: present.winfo)
      Contact: sip:user@host.example.com
      Content-Length: 0

   M2: The presence agent for presentity@example.com processes the
      subscription request and creates a new subscription.  A 200 (OK)
      response is sent to confirm the subscription.

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
       ;received=192.0.2.1
      To: <sip:presentity@example.com>;tag=abcd1234
      From: <sip:watcher@example.com>;tag=12341234
      Call-ID: 12345678@host.example.com
      CSeq: 1 SUBSCRIBE
      Contact: sip:pa.example.com
      Expires: 3600

 

   M3: In order to complete the process, the presence agent sends the
      watcher a NOTIFY with the current presence state of the
      presentity.

     NOTIFY sip:user@host.example.com SIP/2.0
      Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2
      To: <sip:watcher@example.com>;tag=12341234
      From: <sip:presentity@example.com>;tag=abcd1234
      Call-ID: 12345678@host.example.com
      CSeq: 1 NOTIFY
      Max-Forwards: 70
      Event: presence
      Subscription-State: active; expires=3599
      Contact: sip:pa.example.com
      Content-Type: application/pidf+xml
      Content-Length: ...

      <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
                entity="pres:presentity@example.com">
         <tuple id="mobile-phone">
            <status>
               <basic>open</basic>
            </status>
            <timestamp>2003-02-01T16:49:29Z</timestamp>
         </tuple>
         <tuple id="gwewg991">
            <status>
               <basic>open</basic>
            </status>
            <timestamp>2003-02-01T12:21:29Z</timestamp>
         </tuple>
      </presence>

   M4: The watcher confirms receipt of the NOTIFY request.

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2
       ;received=192.0.2.2
      To: <sip:watcher@example.com>;tag=12341234
      From: <sip:presentity@example.com>;tag=abcd1234
      Call-ID: 12345678@host.example.com
      CSeq: 1 NOTIFY

   M5: A presence user agent for the presentity initiates a PUBLISH to
      the presentity's presence agent in order to update it with new
      presence information.  The Expires header indicates the desired
      duration of this soft state.

      PUBLISH sip:presentity@example.com SIP/2.0
      Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
      To: <sip:presentity@example.com>
      From: <sip:presentity@example.com>;tag=1234wxyz
      Call-ID: 81818181@pua.example.com
      CSeq: 1 PUBLISH
      Max-Forwards: 70
      Expires: 3600
      Event: presence
      Content-Type: application/pidf+xml
      Content-Length: ...

      <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
                entity="pres:presentity@example.com">
         <tuple id="efeef223">
            <status>
               <basic>closed</basic>
            </status>
            <timestamp>2003-02-01T17:00:19Z</timestamp>
         </tuple>
      </presence>

   M6: The presence agent receives, and accepts the presence
      information.  The published data is incorporated into the
      presentity's presence document.  A 200 (OK) response is sent to
      confirm the publication.  The 200 (OK) response contains an
      SIP-ETag header field with an entity-tag.  This is used to
      identify the published event state in subsequent PUBLISH requests.

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
       ;received=192.0.2.3
      To: <sip:presentity@example.com>;tag=1a2b3c4d
      From: <sip:presentity@example.com>;tag=1234wxyz
      Call-ID: 81818181@pua.example.com
      CSeq: 1 PUBLISH
      SIP-ETag: dx200xyz
      Expires: 1800

   M7: The presence agent determines that a reportable change has been
      made to the presentity's presence document, and sends another
      notification to those watching the presentity to update their
      information regarding the presentity's current presence status.
      
      NOTIFY sip:user@host.example.com SIP/2.0
      Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a
      To: <sip:watcher@example.com>;tag=12341234
      From: <sip:presentity@example.com>;tag=abcd1234
      Call-ID: 12345678@host.example.com
      CSeq: 2 NOTIFY
      Max-Forwards: 70
      Event: presence
      Subscription-State: active; expires=3400
      Contact: sip:pa.example.com
      Content-Type: application/pidf+xml
      Content-Length: ...

      <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
                entity="pres:presentity@example.com">
         <tuple id="efeef223">
            <status>
               <basic>closed</basic>
            </status>
            <timestamp>2003-02-01T17:00:19Z</timestamp>
         </tuple>
         <tuple id="gwewg991">
            <status>
               <basic>open</basic>
            </status>
            <timestamp>2003-02-01T12:21:29Z</timestamp>
         </tuple>
      </presence>

   M8: The watcher confirms receipt of the NOTIFY request.

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a
       ;received=192.0.2.2
      To: <sip:watcher@example.com>;tag=12341234
      From: <sip:presentity@example.com>;tag=abcd1234
      Call-ID: 12345678@host.example.com
      CSeq: 2 NOTIFY
      Content-Length: 0

   M9: The PUA determines that the event state it previously published
      is about to expire, and refreshes that event state.

      PUBLISH sip:presentity@example.com SIP/2.0
      Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
      To: <sip:presentity@example.com>
      From: <sip:presentity@example.com>;tag=1234kljk
      Call-ID: 98798798@pua.example.com
      CSeq: 1 PUBLISH
      Max-Forwards: 70
      SIP-If-Match: dx200xyz
      Expires: 3600
      Event: presence
      Content-Length: 0

   M10: The presence agent receives, and accepts the publication
      refresh.  The timers regarding the expiration of the specific
      event state identified by the entity-tag are updated.  As always,
      the ESC returns an entity-tag in the response to a successful
      PUBLISH.  Note that no actual state change has occured, so the
      watchers will receive no NOTIFYs.

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
       ;received=192.0.2.3
      To: <sip:presentity@example.com>;tag=2affde434
      From: <sip:presentity@example.com>;tag=1234kljk
      Call-ID: 98798798@pua.example.com
      CSeq: 1 PUBLISH
      SIP-ETag: kwj449x
      Expires: 1800

   M11: The PUA of the presentity detects a change in the user's
      presence state.  It initiates a PUBLISH request to the presence
      agent to modify the published presence information with the recent
      change.
      
      PUBLISH sip:presentity@example.com SIP/2.0
      Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2
      To: <sip:presentity@example.com>
      From: <sip:presentity@example.com>;tag=54321mm
      Call-ID: 5566778@pua.example.com
      CSeq: 1 PUBLISH
      Max-Forwards: 70
      SIP-If-Match: kwj449x
      Expires: 3600
      Event: presence
      Content-Type: application/pidf+xml
      Content-Length: ...

      <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
                entity="pres:presentity@example.com">
         <tuple id="efeef223">
            <status>
               <basic>open</basic>
            </status>
            <timestamp>2003-02-01T19:15:15Z</timestamp>
         </tuple>
      </presence>

   M12: The presence agent receives, and accepts the publication
      modification.  The timers regarding the expiration of the specific
      event state identified by the entity-tag are updated, and the
      published data is incorporated into the presentity's presence
      document.  Note that the document delivered in this modification
      will replace the previous document.

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2
       ;received=192.0.2.3
      To: <sip:presentity@example.com>;tag=effe22aa
      From: <sip:presentity@example.com>;tag=54321mm
      Call-ID: 5566778@pua.example.com
      CSeq: 1 PUBLISH
      SIP-ETag: qwi982ks
      Expires: 3600

   M13: The presence agent determines that a reportable change has been
      made to the presentity's presence document, and sends another
      notification to those watching the presentity to update their
      information regarding the presentity's current presence status.

  NOTIFY sip:user@host.example.com SIP/2.0
      Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3
      To: <sip:watcher@example.com>;tag=12341234
      From: <sip:presentity@example.com>;tag=abcd1234
      Call-ID: 12345678@host.example.com
      CSeq: 2 NOTIFY
      Max-Forwards: 70
      Event: presence
      Subscription-State: active; expires=3400
      Contact: sip:pa.example.com
      Content-Type: application/pidf+xml
      Content-Length: ...

      <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
                entity="pres:presentity@example.com">
         <tuple id="efeef223">
            <status>
               <basic>open</basic>
            </status>
            <timestamp>2003-02-01T19:15:15Z</timestamp>
         </tuple>
         <tuple id="gwewg991">
            <status>
               <basic>open</basic>
            </status>
            <timestamp>2003-02-01T12:21:29Z</timestamp>
         </tuple>
      </presence>

   M14: The watcher confirms receipt of the NOTIFY request.

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3
       ;received=192.0.2.3
      To: <sip:watcher@example.com>;tag=12341234
      From: <sip:presentity@example.com>;tag=abcd1234
      Call-ID: 12345678@host.example.com
      CSeq: 2 NOTIFY
      Content-Length: 0

RFC 3265 - Session Initiation Protocol (SIP)-Specific Event Notification

在NOTIFY 中， 通过Subscription-State header 来决定当前的SUBSCRIBER是否成功。200 OK 只是在transaction 层面上对于SUBSCRIBER的一个response，并不能说明SUBSCRIBER是否成功，需要后续的NOTIFY消息来告知。

   If the "Subscription-State" header value is "active", it means that
   the subscription has been accepted and (in general) has been
   authorized.  If the header also contains an "expires" parameter, the
   subscriber SHOULD take it as the authoritative subscription duration
   and adjust accordingly.  The "retry-after" and "reason" parameters
   have no semantics for "active".

   If the "Subscription-State" value is "pending", the subscription has
   been received by the notifier, but there is insufficient policy
   information to grant or deny the subscription yet.  If the header
   also contains an "expires" parameter, the subscriber SHOULD take it
   as the authoritative subscription duration and adjust accordingly.
   No further action is necessary on the part of the subscriber.  The
   "retry-after" and "reason" parameters have no semantics for
   "pending".

   If the "Subscription-State" value is "terminated", the subscriber
   should consider the subscription terminated.  The "expires" parameter
   has no semantics for "terminated".  If a reason code is present, the
   client should behave as described below.  If no reason code or an
   unknown reason code is present, the client MAY attempt to re-
   subscribe at any time (unless a "retry-after" parameter is present,
   in which case the client SHOULD NOT attempt re-subscription until
   after the number of seconds specified by the "retry-after"
   parameter).  The defined reason codes are:

   deactivated: The subscription has been terminated, but the subscriber
      SHOULD retry immediately with a new subscription.  One primary use
      of such a status code is to allow migration of subscriptions
      between nodes.  The "retry-after" parameter has no semantics for
      "deactivated".

   probation: The subscription has been terminated, but the client
      SHOULD retry at some later time.  If a "retry-after" parameter is
      also present, the client SHOULD wait at least the number of
      seconds specified by that parameter before attempting to re-
      subscribe.

   rejected: The subscription has been terminated due to change in
      authorization policy.  Clients SHOULD NOT attempt to re-subscribe.
      The "retry-after" parameter has no semantics for "rejected".

   timeout: The subscription has been terminated because it was not
      refreshed before it expired.  Clients MAY re-subscribe
      immediately.  The "retry-after" parameter has no semantics for
      "timeout".

   giveup: The subscription has been terminated because the notifier
      could not obtain authorization in a timely fashion.  If a "retry-
      after" parameter is also present, the client SHOULD wait at least
      the number of seconds specified by that parameter before
      attempting to re-subscribe; otherwise, the client MAY retry
      immediately, but will likely get put back into pending state.

   noresource: The subscription has been terminated because the resource
      state which was being monitored no longer exists.  Clients SHOULD
      NOT attempt to re-subscribe.  The "retry-after" parameter has no
      semantics for "noresource".