rfc4662 a session initiation protocol (sip) event notification extension.txt

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

Roach, et al.               Standards Track                    [Page 18]

RFC 4662                    SIP Event Lists                  August 2006


   Terminal   pres.vancouver.example.com   pres.stockholm.example.org
     |                |        pres.dallas.example.net  |
   1 |---SUBSCRIBE--->|                |                |
   2 |<-----200-------|                |                |
   3 |<----NOTIFY-----|                |                |
   4 |------200------>|                |                |
   5 |                |---SUBSCRIBE--->|                |
   6 |                |<-----200-------|                |
   7 |                |<----NOTIFY-----|                |
   8 |                |------200------>|                |
   9 |                |------------SUBSCRIBE----------->|
   10|                |<--------------200---------------|
   11|                |<-------------NOTIFY-------------|
   12|                |---------------200-------------->|
   13|<----NOTIFY-----|                |                |
   14|------200------>|                |                |

   1.   We initiate the subscription by sending a SUBSCRIBE message to
        our local RLS.  (There is no reason that the RLS we contact has
        to be in our domain, of course).  Note that we must advertise
        support for application/rlmi+xml and multipart/related because
        we support the eventlist extension, and that we must advertise
        application/pidf+xml because we are requesting a subscription to
        presence.

   Terminal -> Local RLS

   SUBSCRIBE sip:[e-mail] SIP/2.0
   Via: SIP/2.0/TCP terminal.vancouver.example.com;
     branch=z9hG4bKwYb6QREiCL
   Max-Forwards: 70
   To: <sip:[e-mail]>
   From: <sip:[e-mail]>;tag=ie4hbb8t
   Call-ID: [e-mail]
   CSeq: 322723822 SUBSCRIBE
   Contact: <sip:terminal.vancouver.example.com>
   Event: presence
   Expires: 7200
   Supported: eventlist
   Accept: application/pidf+xml
   Accept: application/rlmi+xml
   Accept: multipart/related
   Accept: multipart/signed
   Accept: application/pkcs7-mime
   Content-Length: 0






Roach, et al.               Standards Track                    [Page 19]

RFC 4662                    SIP Event Lists                  August 2006


   2.   The Local RLS completes the SUBSCRIBE transaction.  Note that
        authentication and authorization would normally take place at
        this point in the call flow.  Those steps are omitted for
        brevity.

   Local RLS -> Terminal

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP terminal.vancouver.example.com;
     branch=z9hG4bKwYb6QREiCL
   To: <sip:[e-mail]>;tag=zpNctbZq
   From: <sip:[e-mail]>;tag=ie4hbb8t
   Call-ID: [e-mail]
   CSeq: 322723822 SUBSCRIBE
   Contact: <sip:pres.vancouver.example.com>
   Expires: 7200
   Require: eventlist
   Content-Length: 0

   3.   As is required by RFC 3265 [2], the RLS sends a NOTIFY
        immediately upon accepting the subscription.  In this example,
        we are assuming that the local RLS is also an authority for
        presence information for the users in the
        "vancouver.example.com" domain.  The NOTIFY contains an RLMI
        document describing the entire buddy list (initial notifies
        require full state), as well as presence information for the
        users about which it already knows.  Note that, since the RLS
        has not yet retrieved information for some of the entries on the
        list, those <resource> elements contain no <instance> elements.

   Local RLS -> Terminal

   NOTIFY sip:terminal.vancouver.example.com SIP/2.0
   Via: SIP/2.0/TCP pres.vancouver.example.com;
     branch=z9hG4bKMgRenTETmm
   Max-Forwards: 70
   From: <sip:[e-mail]>;tag=zpNctbZq
   To: <sip:[e-mail]>;tag=ie4hbb8t
   Call-ID: [e-mail]
   CSeq: 997935768 NOTIFY
   Contact: <sip:pres.vancouver.example.com>
   Event: presence
   Subscription-State: active;expires=7200
   Require: eventlist
   Content-Type: multipart/related;type="application/rlmi+xml";
       start="<[e-mail]>";
       boundary="50UBfW7LSCVLtggUPe5z"
   Content-Length: 1560



Roach, et al.               Standards Track                    [Page 20]

RFC 4662                    SIP Event Lists                  August 2006


   --50UBfW7LSCVLtggUPe5z
   Content-Transfer-Encoding: binary
   Content-ID: <[e-mail]>
   Content-Type: application/rlmi+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8"?>
   <list xmlns="urn:ietf:params:xml:ns:rlmi"
         uri="sip:[e-mail]"
         version="1" fullState="true">
     <name xml:lang="en">Buddy List at COM</name>
     <name xml:lang="de">Liste der Freunde an COM</name>
     <resource uri="sip:[e-mail]"">
       <name>Bob Smith</name>
       <instance id="juwigmtboe" state="active"
                 cid="[e-mail]"/>
     </resource>
     <resource uri="sip:[e-mail]">
       <name>Dave Jones</name>
       <instance id="hqzsuxtfyq" state="active"
                 cid="[e-mail]"/>
     </resource>
     <resource uri="sip:[e-mail]">
       <name>Ed at NET</name>
     </resource>
     <resource uri="sip:[e-mail]">
       <name xml:lang="en">My Friends at ORG</name>
       <name xml:lang="de">Meine Freunde an ORG</name>
     </resource>
   </list>

   --50UBfW7LSCVLtggUPe5z
   Content-Transfer-Encoding: binary
   Content-ID: <[e-mail]>
   Content-Type: application/pidf+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
       entity="sip:[e-mail]">
     <tuple id="sg89ae">
       <status>
         <basic>open</basic>
       </status>
       <contact priority="1.0">sip:[e-mail]</contact>
     </tuple>
   </presence>

   --50UBfW7LSCVLtggUPe5z
   Content-Transfer-Encoding: binary



Roach, et al.               Standards Track                    [Page 21]

RFC 4662                    SIP Event Lists                  August 2006


   Content-ID: <[e-mail]>
   Content-Type: application/pidf+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
       entity="sip:[e-mail]">
     <tuple id="slie74">
       <status>
         <basic>closed</basic>
       </status>
     </tuple>
   </presence>

   --50UBfW7LSCVLtggUPe5z--

   4.   The terminal completes the transaction.

   Terminal -> Local RLS

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP pres.vancouver.example.com;
     branch=z9hG4bKMgRenTETmm
   From: <sip:[e-mail]>;tag=zpNctbZq
   To: <sip:[e-mail]>;tag=ie4hbb8t
   Call-ID: [e-mail]
   CSeq: 997935768 NOTIFY
   Contact: <sip:terminal.vancouver.example.com>
   Content-Length: 0

   5.   In order to service the subscription, the local RLS subscribes
        to the state of the resources.  In this step, the RLS attempts
        to subscribe to the presence state of the resource
        "sip:[e-mail]".  Since the local RLS knows how to
        receive notifications for list subscriptions, it includes the
        "Supported: eventlist" header field in its request.  Although
        the linkage between this subscription and the one sent by the
        terminal is left up to the application, this message
        demonstrates some reasonable behavior by including "Accept"
        header fields for all the body types it knows the subscriber
        (Terminal) supports.  This is safe to do, since the local RLS
        will only pass these formats through to the subscriber and does
        not need to actually understand them.

   Local RLS -> Presence Server in dallas.example.net

   SUBSCRIBE sip:[e-mail] SIP/2.0
   Via: SIP/2.0/TCP pres.vancouver.example.com;
     branch=z9hG4bKMEyGjdG1LH



Roach, et al.               Standards Track                    [Page 22]

RFC 4662                    SIP Event Lists                  August 2006


   Max-Forwards: 70
   To: <sip:[e-mail]>
   From: <sip:[e-mail]>;tag=aM5icQu9
   Call-ID: [e-mail]
   CSeq: 870936068 SUBSCRIBE
   Contact: <sip:pres.vancouver.example.com>
   Identity: Tm8sIHRoaXMgaXNuJ3QgYSByZWFsIGNlcnQuIFlvdSBvn
             Zpb3VzbHkgaGF2ZSB0aW1lIHRvIGtpbGwuIEkKc3VnZ2V
             zdCBodHRwOi8vd3d3LmhvbWVzdGFycnVubmVyLmNvbS8K
   Identity-Info: https://vancouver.example.com/cert
   Event: presence
   Expires: 3600
   Supported: eventlist
   Accept: application/pidf+xml
   Accept: application/rlmi+xml
   Accept: multipart/related
   Accept: multipart/signed
   Accept: application/pkcs7-mime
   Content-Length: 0

   6.   The Presence Server in dallas.example.net completes the
        SUBSCRIBE transaction.  Note that authentication would normally
        take place at this point in the call flow.  This step is omitted
        for brevity.

   Presence Server in dallas.example.net -> Local RLS

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP pres.vancouver.example.com;
     branch=z9hG4bKMEyGjdG1LH
   To: <sip:[e-mail]>;tag=e45TmHTh
   From: <sip:[e-mail]>;tag=aM5icQu9
   Call-ID: [e-mail]
   CSeq: 870936068 SUBSCRIBE
   Contact: <sip:dallas.example.net>
   Expires: 3600
   Content-Length: 0

   7.   In this example, we assume that the server at dallas.example.net
        doesn't have enough authorization information to reject or
        accept our subscription.  The initial notify, therefore,
        contains a "Subscription-State" of "pending".  Presumably, the
        party responsible for accepting or denying authorization for the
        resource is notified of this change; however, those steps are
        not included in this call flow for brevity.






Roach, et al.               Standards Track                    [Page 23]

RFC 4662                    SIP Event Lists                  August 2006


   Presence Server in dallas.example.net -> Local RLS

   NOTIFY sip:pres.vancouver.example.com SIP/2.0
   Via: SIP/2.0/TCP pres.dallas.example.net;
     branch=z9hG4bKfwpklPxmrW
   Max-Forwards: 70
   From: <sip:[e-mail]>;tag=e45TmHTh
   To: <sip:[e-mail]>;tag=aM5icQu9
   Call-ID: [e-mail]
   CSeq: 1002640632 NOTIFY
   Contact: <sip:dallas.example.net>
   Subscription-State: pending;expires=3600
   Event: presence
   Require: eventlist
   Content-Length: 0

   8.   The local RLS completes the NOTIFY transaction.  Note that, at
        this point, the Local RLS has new information to report to the
        subscriber.  Whether it chooses to report the information