rfc3262.txt

RFC 的详细文档！


RFC 3262      Reliability of Provisional Responses in SIP      June 2002


            Header field              where      PRACK
            __________________________________________
            Priority                    R          -
            Proxy-Authenticate         407         m
            Proxy-Authenticate         401         o
            Proxy-Authorization         R          o
            Proxy-Require               R          o
            Record-Route                R          o
            Record-Route             2xx,18x       o
            Reply-To                               -
            Require                                c
            Retry-After          404,413,480,486   o
                                     500,503       o
                                     600,603       o
            Route                       R          c
            Server                      r          o
            Subject                     R          -
            Supported                   R          o
            Supported                  2xx         o
            Timestamp                              o
            To                          c          m
            Unsupported                420         m
            User-Agent                             o
            Via                         c          m
            Warning                     r          o
            WWW-Authenticate           401         m

            Table 2: Summary of header fields, P--Z

   If the UAC does not wish to insist on usage of reliable provisional
   responses, but merely indicate that it supports them if the UAS needs
   to send one, a Supported header MUST be included in the request with
   the option tag 100rel.  The UAC SHOULD include this in all INVITE
   requests.

   If a provisional response is received for an initial request, and
   that response contains a Require header field containing the option
   tag 100rel, the response is to be sent reliably.  If the response is
   a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be
   ignored, and the procedures below MUST NOT be used.











Rosenberg & Schulzrinne     Standards Track                     [Page 8]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


   The provisional response MUST establish a dialog if one is not yet
   created.

   Assuming the response is to be transmitted reliably, the UAC MUST
   create a new request with method PRACK.  This request is sent within
   the dialog associated with the provisional response (indeed, the
   provisional response may have created the dialog).  PRACK requests
   MAY contain bodies, which are interpreted according to their type and
   disposition.

   Note that the PRACK is like any other non-INVITE request within a
   dialog.  In particular, a UAC SHOULD NOT retransmit the PRACK request
   when it receives a retransmission of the provisional response being
   acknowledged, although doing so does not create a protocol error.

   Once a reliable provisional response is received, retransmissions of
   that response MUST be discarded.  A response is a retransmission when
   its dialog ID, CSeq, and RSeq match the original response.  The UAC
   MUST maintain a sequence number that indicates the most recently
   received in-order reliable provisional response for the initial
   request.  This sequence number MUST be maintained until a final
   response is received for the initial request.  Its value MUST be
   initialized to the RSeq header field in the first reliable
   provisional response received for the initial request.

   Handling of subsequent reliable provisional responses for the same
   initial request follows the same rules as above, with the following
   difference: reliable provisional responses are guaranteed to be in
   order.  As a result, if the UAC receives another reliable provisional
   response to the same request, and its RSeq value is not one higher
   than the value of the sequence number, that response MUST NOT be
   acknowledged with a PRACK, and MUST NOT be processed further by the
   UAC.  An implementation MAY discard the response, or MAY cache the
   response in the hopes of receiving the missing responses.

   The UAC MAY acknowledge reliable provisional responses received after
   the final response or MAY discard them.

5 The Offer/Answer Model and PRACK

   RFC 3261 describes guidelines for the sets of messages in which
   offers and answers [3] can appear.  Based on those guidelines, this
   extension provides additional opportunities for offer/answer
   exchanges.

   If the INVITE contained an offer, the UAS MAY generate an answer in a
   reliable provisional response (assuming these are supported by the
   UAC).  That results in the establishment of the session before



Rosenberg & Schulzrinne     Standards Track                     [Page 9]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


   completion of the call.  Similarly, if a reliable provisional
   response is the first reliable message sent back to the UAC, and the
   INVITE did not contain an offer, one MUST appear in that reliable
   provisional response.

   If the UAC receives a reliable provisional response with an offer
   (this would occur if the UAC sent an INVITE without an offer, in
   which case the first reliable provisional response will contain the
   offer), it MUST generate an answer in the PRACK.  If the UAC receives
   a reliable provisional response with an answer, it MAY generate an
   additional offer in the PRACK.  If the UAS receives a PRACK with an
   offer, it MUST place the answer in the 2xx to the PRACK.

   Once an answer has been sent or received, the UA SHOULD establish the
   session based on the parameters of the offer and answer, even if the
   original INVITE itself has not been responded to.

   If the UAS had placed a session description in any reliable
   provisional response that is unacknowledged when the INVITE is
   accepted, the UAS MUST delay sending the 2xx until the provisional
   response is acknowledged.  Otherwise, the reliability of the 1xx
   cannot be guaranteed, and reliability is needed for proper operation
   of the offer/answer exchange.

   All user agents that support this extension MUST support all
   offer/answer exchanges that are possible based on the rules in
   Section 13.2 of RFC 3261, based on the existence of INVITE and PRACK
   as requests, and 2xx and reliable 1xx as non-failure reliable
   responses.

6 Definition of the PRACK Method

   This specification defines a new SIP method, PRACK.  The semantics of
   this method are described above.  Tables 1 and 2 extend Tables 2 and
   3 from RFC 3261 for this new method.

7 Header Field Definitions

   This specification defines two new header fields, RAck and RSeq.
   Table 3 extends Tables 2 and 3 from RFC 3261 for these headers.

7.1 RSeq

   The RSeq header is used in provisional responses in order to transmit
   them reliably.  It contains a single numeric value from 1 to 2**32 -
   1.  For details on its usage, see Section 3.





Rosenberg & Schulzrinne     Standards Track                    [Page 10]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


   Example:

   RSeq: 988789

      Header field  where  proxy ACK BYE CAN INV OPT REG PRA
      ______________________________________________________
      RAck            R           -   -   -   -   -   -   m
      RSeq           1xx          -   -   -   o   -   -   -


      Table 3: RAck and RSeq Header Fields

7.2 RAck

   The RAck header is sent in a PRACK request to support reliability of
   provisional responses.  It contains two numbers and a method tag.
   The first number is the value from the RSeq header in the provisional
   response that is being acknowledged.  The next number, and the
   method, are copied from the CSeq in the response that is being
   acknowledged.  The method name in the RAck header is case sensitive.

   Example:

      RAck: 776656 1 INVITE

8 IANA Considerations

   This document registers a new option tag and two new headers, based
   on the IANA registration process of RFC 3261.

8.1 IANA Registration of the 100rel Option Tag

   This specification registers a single option tag, 100rel.  The
   required information for this registration, as specified in RFC 3261,
   is:

      Name: 100rel

      Description: This option tag is for reliability of provisional
         responses.  When present in a Supported header, it indicates
         that the UA can send or receive reliable provisional responses.
         When present in a Require header in a request, it indicates
         that the UAS MUST send all provisional responses reliably.
         When present in a Require header in a reliable provisional
         response, it indicates that the response is to be sent
         reliably.





Rosenberg & Schulzrinne     Standards Track                    [Page 11]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


8.2 IANA Registration of RSeq and RAck Headers

   The following is the registration for the RSeq header:

      RFC Number: RFC3262

      Header Name: RSeq

      Compact Form: none

   The following is the registration for the RAck header:

      RFC Number: RFC3262

      Header Name: RAck

      Compact Form: none

9 Security Considerations

   The PRACK request can be injected by attackers to force
   retransmissions of reliable provisional responses to cease.  As these
   responses can convey important information, PRACK messages SHOULD be
   authenticated as any other request.  Authentication procedures are
   specified in RFC 3261.

10 Collected BNF

   The BNF for the RAck and RSeq headers and the PRACK method are
   defined here.

   PRACKm        =  %x50.52.41.43.4B ; PRACK in caps
   Method        =  INVITEm / ACKm / OPTIONSm / BYEm
                    / CANCELm / REGISTERm / PRACKm
                    / extension-method
   RAck          =  "RAck" HCOLON response-num LWS CSeq-num LWS Method
   response-num  =  1*DIGIT
   CSeq-num      =  1*DIGIT
   RSeq          =  "RSeq" HCOLON response-num

11 Acknowledgements

   The authors would like to thank Jo Hornsby, Jonathan Lennox, Rohan
   Mahy, Allison Mankin, Adam Roach, and Tim Schroeder for the comments
   on this document.






Rosenberg & Schulzrinne     Standards Track                    [Page 12]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


12 Normative References

   [1]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [2]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         SDP", RFC 3264, June 2002.

13 Informative References

   [4]   Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
         "SIP: Session Initiation Protocol", RFC 2543, March 1999.

14 Authors' Addresses

   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936

   EMail: [e-mail]


   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003

   EMail: [e-mail]
















Rosenberg & Schulzrinne     Standards Track                    [Page 13]

RFC 3262      Reliability of Provisional Responses in SIP      June 2002


15.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Rosenberg & Schulzrinne     Standards Track                    [Page 14]