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

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

        immediately or spool it up for later delivery is completely up
        to the application.  For this example, we assume that the RLS
        will wait for a short period of time before doing so, in order
        to allow the subscriptions it sent out sufficient time to
        provide useful data.

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

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

   9.   The Local RLS subscribes to the state of the other non-local
        resource.

   Local RLS -> RLS in stockholm.example.org

   SUBSCRIBE sip:[e-mail] SIP/2.0
   Via: SIP/2.0/TCP pres.vancouver.example.com;
     branch=z9hG4bKFSrAF8CZFL
   Max-Forwards: 70
   To: <sip:[e-mail]>
   From: <sip:[e-mail]>;tag=a12eztNf



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


   Call-ID: [e-mail]
   CSeq: 980774491 SUBSCRIBE
   Contact: <sip:pres.vancouver.example.com>
   Identity: Tm90IGEgcmVhbCBzaWduYXR1cmUsIGVpdGhlci4gQ2VydGFp
             bmx5IHlvdSBoYXZlIGJldHRlcgp0aGluZ3MgdG8gYmUgZG9p
             bmcuIEhhdmUgeW91IGZpbmlzaGVkIHlvdXIgUkxTIHlldD8K
   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

   10.  The RLS in stockholm.example.org completes the SUBSCRIBE
        transaction.  Note that authentication would normally take place
        at this point in the call flow.  This step is omitted for
        brevity.

   RLS in stockholm.example.org -> Local RLS

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP pres.vancouver.example.com;
     branch=z9hG4bKFSrAF8CZFL
   To: <sip:[e-mail]>;tag=JenZ40P3
   From: <sip:[e-mail]>;tag=a12eztNf
   Call-ID: [e-mail]
   CSeq: 980774491 SUBSCRIBE
   Contact: <sip:stockholm.example.org>
   Expires: 3600
   Content-Length: 0

   11.  In this example, we assume that the RLS in stockholm.example.org
        is also an authority for presence information for the users in
        the "stockholm.example.org" domain.  The NOTIFY contains an RLMI
        document describing the contained buddy list, as well as
        presence information for those users.  In this particular case,
        the RLS in stockholm.example.org has chosen to sign [14] the
        body of the NOTIFY message.  As described in RFC 3851, signing
        is performed by creating a multipart/signed document that has
        two parts.  The first part is the document to be signed (in this
        example, the multipart/related document that describes the list
        resource states), while the second part is the actual signature.





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


   RLS in stockholm.example.org -> Local RLS

   NOTIFY sip:pres.vancouver.example.com SIP/2.0
   Via: SIP/2.0/TCP pres.stockholm.example.org;
     branch=z9hG4bKmGL1nyZfQI
   Max-Forwards: 70
   From: <sip:[e-mail]>;tag=JenZ40P3
   To: <sip:[e-mail]>;tag=a12eztNf
   Call-ID: [e-mail]
   CSeq: 294444656 NOTIFY
   Contact: <sip:stockholm.example.org>
   Event: presence
   Subscription-State: active;expires=3600
   Require: eventlist
   Content-Type: multipart/signed;
       protocol="application/pkcs7-signature";
       micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
   Content-Length: 2038

   --l3WMZaaL8NpQWGnQ4mlU
   Content-Transfer-Encoding: binary
   Content-ID: <[e-mail]>
   Content-Type: multipart/related;type="application/rlmi+xml";
       start="<[e-mail]>";
       boundary="tuLLl3lDyPZX0GMr2YOo"

   --tuLLl3lDyPZX0GMr2YOo
   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>Joe Thomas</name>
       <instance id="1" state="active"
                 cid="[e-mail]"/>
     </resource>
     <resource uri="sip:[e-mail]">
       <name>Mark Edwards</name>
       <instance id="1" state="active"
                 cid="[e-mail]"/>
     </resource>
   </list>



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


   --tuLLl3lDyPZX0GMr2YOo
   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="x823a4">
       <status>
         <basic>open</basic>
       </status>
       <contact priority="1.0">sip:[e-mail]</contact>
     </tuple>
   </presence>

   --tuLLl3lDyPZX0GMr2YOo
   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="z98075">
       <status>
         <basic>closed</basic>
       </status>
     </tuple>
   </presence>

   --tuLLl3lDyPZX0GMr2YOo--

   --l3WMZaaL8NpQWGnQ4mlU
   Content-Transfer-Encoding: binary
   Content-ID: <[e-mail]>
   Content-Type: application/pkcs7-signature

   [PKCS #7 signature here]

   --l3WMZaaL8NpQWGnQ4mlU--










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


   12.  The Local RLS completes the NOTIFY transaction.

   Local RLS -> RLS in stockholm.example.org

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP pres.stockholm.example.org;
     branch=z9hG4bKmGL1nyZfQI
   From: <sip:[e-mail]>;tag=JenZ40P3
   To: <sip:[e-mail]>;tag=a12eztNf
   Call-ID: [e-mail]
   CSeq: 294444656 NOTIFY
   Contact: <sip:pres.vancouver.example.com>
   Content-Length: 0

   13.  At this point, the Local RLS decides it has collected enough
        additional information to warrant sending a new notification to
        the user.  Although sending a full notification would be
        perfectly acceptable, the RLS decides to send a partial
        notification instead.  The RLMI document contains only
        information for the updated resources, as indicated by setting
        the "fullState" parameter to "false".  To avoid corrupting the
        S/MIME signature on the data received from the RLS in
        stockholm.example.org, the local RLS copies the entire
        multipart/signed body as-is into the notification that it sends.

   Local RLS -> Terminal

   NOTIFY sip:terminal.vancouver.example.com SIP/2.0
   Via: SIP/2.0/TCP pres.vancouver.example.com;
     branch=z9hG4bK4EPlfSFQK1
   Max-Forwards: 70
   From: <sip:[e-mail]>;tag=zpNctbZq
   To: <sip:[e-mail]>;tag=ie4hbb8t
   Call-ID: [e-mail]
   CSeq: 997935769 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="TfZxoxgAvLqgj4wRWPDL"
   Content-Length: 2862

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



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


   <?xml version="1.0" encoding="UTF-8"?>
   <list xmlns="urn:ietf:params:xml:ns:rlmi"
         uri="sip:[e-mail]" version="2"
         fullState="false">
     <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>Ed at NET</name>
       <instance id="sdlkmeopdf" state="pending"/>
     </resource>
     <resource uri="sip:[e-mail]">
       <name xml:lang="en">My Friends at ORG</name>
       <name xml:lang="de">Meine Freunde an ORG</name>
       <instance id="cmpqweitlp" state="active"
                 cid="[e-mail]"/>
     </resource>
   </list>

   --TfZxoxgAvLqgj4wRWPDL
   Content-Transfer-Encoding: binary
   Content-ID: <[e-mail]>
   Content-Type: multipart/signed;
       protocol="application/pkcs7-signature";
       micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"

   --l3WMZaaL8NpQWGnQ4mlU
   Content-Transfer-Encoding: binary
   Content-ID: <[e-mail]>
   Content-Type: multipart/related;type="application/rlmi+xml";
       start="<[e-mail]>";
       boundary="tuLLl3lDyPZX0GMr2YOo"

   --tuLLl3lDyPZX0GMr2YOo
   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 ORG</name>
     <name xml:lang="de">Liste der Freunde an ORG</name>
     <resource uri="sip:[e-mail]">
       <name>Joe Thomas</name>
       <instance id="1" state="active"
                 cid="[e-mail]"/>
     </resource>
     <resource uri="sip:[e-mail]">



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


       <name>Mark Edwards</name>
       <instance id="1" state="active"
                 cid="[e-mail]"/>
     </resource>
   </list>

   --t