doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc3311.txt b/doc/rfc/rfc3311.txt
new file mode 100644
index 0000000..d478aca
--- /dev/null
+++ b/doc/rfc/rfc3311.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                       J. Rosenberg
+Request for Comments: 3311                                   dynamicsoft
+Category: Standards Track                                 September 2002
+
+
+          The Session Initiation Protocol (SIP) UPDATE Method
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This specification defines the new UPDATE method for the Session
+   Initiation Protocol (SIP).  UPDATE allows a client to update
+   parameters of a session (such as the set of media streams and their
+   codecs) but has no impact on the state of a dialog.  In that sense,
+   it is like a re-INVITE, but unlike re-INVITE, it can be sent before
+   the initial INVITE has been completed.  This makes it very useful for
+   updating session parameters within early dialogs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg                   Standards Track                     [Page 1]
+
+RFC 3311                   SIP UPDATE Method              September 2002
+
+
+Table of Contents
+
+   1    Introduction ..............................................    2
+   2    Terminology ...............................................    3
+   3    Overview of Operation .....................................    3
+   4    Determining Support for this Extension ....................    3
+   5    UPDATE Handling ...........................................    4
+   5.1  Sending an UPDATE .........................................    4
+   5.2  Receiving an UPDATE .......................................    5
+   5.3  Processing the UPDATE Response ............................    6
+   6    Proxy Behavior ............................................    7
+   7    Definition of the UPDATE method ...........................    7
+   8    Example Call Flow .........................................    7
+   9    Security Considerations ...................................   11
+   10   IANA Considerations .......................................   11
+   11   Notice Regarding Intellectual Property Rights .............   11
+   12   Normative References ......................................   11
+   13   Acknowledgements ..........................................   12
+   14   Author's Address ..........................................   12
+   15   Full Copyright Statement ..................................   13
+
+1 Introduction
+
+   The Session Initiation Protocol (SIP) [1] defines the INVITE method
+   for the initiation and modification of sessions.  However, this
+   method actually affects two important pieces of state.  It impacts
+   the session (the media streams SIP sets up) and also the dialog (the
+   state that SIP itself defines).  While this is reasonable in many
+   cases, there are important scenarios in which this coupling causes
+   complications.
+
+   The primary difficulty is when aspects of the session need to be
+   modified before the initial INVITE has been answered.  An example of
+   this situation is "early media", a condition where the session is
+   established, for the purpose of conveying progress of the call, but
+   before the INVITE itself is accepted.  It is important that either
+   caller or callee be able to modify the characteristics of that
+   session (putting the early media on hold, for example), before the
+   call is answered.  However, a re-INVITE cannot be used for this
+   purpose, because the re-INVITE has an impact on the state of the
+   dialog, in addition to the session.
+
+   As a result, a solution is needed that allows the caller or callee to
+   provide updated session information before a final response to the
+   initial INVITE request is generated.  The UPDATE method, defined
+   here, fulfills that need.  It can be sent by a UA within a dialog
+   (early or confirmed) to update session parameters without impacting
+   the dialog state itself.
+
+
+
+Rosenberg                   Standards Track                     [Page 2]
+
+RFC 3311                   SIP UPDATE Method              September 2002
+
+
+2 Terminology
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
+   [2] and indicate requirement levels for compliant SIP
+   implementations.
+
+3 Overview of Operation
+
+   Operation of this extension is straightforward.  The caller begins
+   with an INVITE transaction, which proceeds normally.  Once a dialog
+   is established, either early or confirmed, the caller can generate an
+   UPDATE method that contains an SDP offer [3] for the purposes of
+   updating the session.  The response to the UPDATE method contains the
+   answer.  Similarly, once a dialog is established, the callee can send
+   an UPDATE with an offer, and the caller places its answer in the 2xx
+   to the UPDATE.  The Allow header field is used to indicate support
+   for the UPDATE method.  There are additional constraints on when
+   UPDATE can be used, based on the restrictions of the offer/answer
+   model.
+
+4 Determining Support for this Extension
+
+   The initiation of a session operates as specified in RFC 3261 [1].
+   However, a UAC compliant to this specification SHOULD also include an
+   Allow header field in the INVITE request, listing the method UPDATE,
+   to indicate its ability to receive an UPDATE request.
+
+   When a UAS compliant to this specification receives an INVITE request
+   for a new dialog, and generates a reliable provisional response
+   containing SDP, that response SHOULD contain an Allow header field
+   that lists the UPDATE method.  This informs the caller that the
+   callee is capable of receiving an UPDATE request at any time.  An
+   unreliable provisional response MAY contain an Allow header field
+   listing the UPDATE method, and a 2xx response SHOULD contain an Allow
+   header field listing the UPDATE method.
+
+   Responses are processed normally as per RFC 3261 [1], and in the case
+   of reliable provisional responses, according to [4].  It is important
+   to note that a reliable provisional response will always create an
+   early dialog at the UAC.  Creation of this dialog is necessary in
+   order to receive UPDATE requests from the callee.
+
+   If the response contains an Allow header field containing the value
+   "UPDATE", the UAC knows that the callee supports UPDATE, and the UAC
+   is allowed to follow the procedures of Section 5.1.
+
+
+
+
+Rosenberg                   Standards Track                     [Page 3]
+
+RFC 3311                   SIP UPDATE Method              September 2002
+
+
+5 UPDATE Handling
+
+5.1 Sending an UPDATE
+
+   The UPDATE request is constructed as would any other request within
+   an existing dialog, as described in Section 12.2.1 of RFC 3261.  It
+   MAY be sent for both early and confirmed dialogs, and MAY be sent by
+   either caller or callee.  Although UPDATE can be used on confirmed
+   dialogs, it is RECOMMENDED that a re-INVITE be used instead.  This is
+   because an UPDATE needs to be answered immediately, ruling out the
+   possibility of user approval.  Such approval will frequently be
+   needed, and is possible with a re-INVITE.
+
+   The UAC MAY add optional headers for the UPDATE request, as defined
+   in Tables 1 and 2.
+
+   UPDATE is a target refresh request. As specified in RFC 3261 [1],
+   this means that it can update the remote target of a dialog. If a UA
+   uses an UPDATE request or response to modify the remote target while
+   an INVITE transaction is in progress, and it is a UAS for that INVITE
+   transaction, it MUST place the same value into the Contact header
+   field of the 2xx to the INVITE that it placed into the UPDATE request
+   or response.
+
+   The rules for inclusion of offers and answers in SIP messages as
+   defined in Section 13.2.1 of RFC 3261 still apply.  These rules exist
+   to guarantee a consistent view of the session state.  This means
+   that, for the caller:
+
+      o  If the UPDATE is being sent before completion of the initial
+         INVITE transaction, and the initial INVITE contained an offer,
+         the UPDATE can contain an offer if the callee generated an
+         answer in a reliable provisional response, and the caller has
+         received answers to any other offers it sent in either PRACK or
+         UPDATE, and has generated answers for any offers it received in
+         an UPDATE from the callee.
+
+      o  If the UPDATE is being sent before completion of the initial
+         INVITE transaction, and the initial INVITE did not contain an
+         offer, the UPDATE can contain an offer if the callee generated
+         an offer in a reliable provisional response, and the UAC
+         generated an answer in the corresponding PRACK.  Of course, it
+         can't send an UPDATE if it has not received answers to any
+         other offers it sent in either PRACK or UPDATE, or has not
+         generated answers for any other offers it received in an UPDATE
+         from the callee.
+
+
+
+
+
+Rosenberg                   Standards Track                     [Page 4]
+
+RFC 3311                   SIP UPDATE Method              September 2002
+
+
+      o  If the UPDATE is being sent after the completion of the initial
+         INVITE transaction, it cannot contain an offer if the caller
+         has generated or received offers in a re-INVITE or UPDATE which
+         have not been answered.
+
+   and for the callee:
+
+      o  If the UPDATE is being sent before the completion of the INVITE
+         transaction, and the initial INVITE contained an offer, the
+         UPDATE cannot be sent with an offer unless the callee has
+         generated an answer in a reliable provisional response, has
+         received a PRACK for that reliable provisional response, has
+         not received any requests (PRACK or UPDATE) with offers that it
+         has not answered, and has not sent any UPDATE requests
+         containing offers that have not been answered.
+
+      o  If the UPDATE is being sent before completion of the INVITE
+         transaction, and the initial INVITE did not contain an offer,
+         the UPDATE cannot be sent with an offer unless the callee has
+         sent an offer in a reliable provisional response, received an
+         answer in a PRACK, and has not received any UPDATE requests
+         with offers that it has not answered, and has not sent any
+         UPDATE requests containing offers that have not been answered.
+
+      o  If the UPDATE is being sent after the completion of the initial
+         INVITE transaction, it cannot be sent with an offer if the
+         callee has generated or received offers in a re-INVITE or
+         UPDATE which have not been answered.
+
+5.2 Receiving an UPDATE
+
+   The UPDATE is processed as any other mid-dialog target refresh
+   request, as described in Section 12.2.2 of RFC 3261 [1].  If the
+   request is generally acceptable, processing continues as described
+   below.  This processing is nearly identical to that of Section 14.2
+   of RFC 3261 [1], but generalized for the case of UPDATE.
+
+   A UAS that receives an UPDATE before it has generated a final
+   response to a previous UPDATE on the same dialog MUST return a 500
+   response to the new UPDATE, and MUST include a Retry-After header
+   field with a randomly chosen value between 0 and 10 seconds.
+
+   If an UPDATE is received that contains an offer, and the UAS has
+   generated an offer (in an UPDATE, PRACK or INVITE) to which it has
+   not yet received an answer, the UAS MUST reject the UPDATE with a 491
+   response.  Similarly, if an UPDATE is received that contains an
+   offer, and the UAS has received an offer (in an UPDATE, PRACK, or
+   INVITE) to which it has not yet generated an answer, the UAS MUST
+
+
+
+Rosenberg                   Standards Track                     [Page 5]
+
+RFC 3311                   SIP UPDATE Method              September 2002
+
+
+   reject the UPDATE with a 500 response, and MUST include a Retry-After
+   header field with a randomly chosen value between 0 and 10 seconds.
+
+   If a UA receives an UPDATE for an existing dialog, it MUST check any
+   version identifiers in the session description or, if there are no
+   version identifiers, the content of the session description to see if
+   it has changed.  If the session description has changed, the UAS MUST
+   adjust the session parameters accordingly and generate an answer in
+   the 2xx response.  However, unlike a re-INVITE, the UPDATE MUST be
+   responded to promptly, and therefore the user cannot generally be
+   prompted to approve the session changes.  If the UAS cannot change
+   the session parameters without prompting the user, it SHOULD reject
+   the request with a 504 response.  If the new session description is
+   not acceptable, the UAS can reject it by returning a 488 (Not
+   Acceptable Here) response for the UPDATE.  This response SHOULD
+   include a Warning header field.
+
+5.3 Processing the UPDATE Response
+
+   Processing of the UPDATE response at the UAC follows the rules in
+   Section 12.2.1.2 of RFC 3261 [1] for a target refresh request.  Once
+   that processing is complete, it continues as specified below.  This
+   processing is nearly identical to the processing of Section 14.1 of
+   RFC 3261 [1], but generalized for UPDATE.
+
+   If a UA receives a non-2xx final response to a UPDATE, the session
+   parameters MUST remain unchanged, as if no UPDATE had been issued.
+   Note that, as stated in Section 12.2.1 of RFC 3261 [1], if the non-
+   2xx final response is a 481 (Call/Transaction Does Not Exist), or a
+   408 (Request Timeout), or no response at all is received for the
+   UPDATE (that is, a timeout is returned by the UPDATE client
+   transaction), the UAC will terminate the dialog.
+
+   If a UAC receives a 491 response to a UPDATE, it SHOULD start a timer
+   with a value T chosen as follows:
+
+      1. If the UAC is the owner of the Call-ID of the dialog ID
+         (meaning it generated the value), T has a randomly chosen value
+         between 2.1 and 4 seconds in units of 10 ms.
+
+      2. If the UAC is not the owner of the Call-ID of the dialog ID, T
+         has a randomly chosen value between 0 and 2 seconds in units of
+         10 ms.
+
+   When the timer fires, the UAC SHOULD attempt the UPDATE once more, if
+   it still desires for that session modification to take place.  For
+   example, if the call was already hung up with a BYE, the UPDATE would
+   not take place.
+
+
+
+Rosenberg                   Standards Track                     [Page 6]
+
+RFC 3311                   SIP UPDATE Method              September 2002
+
+
+6 Proxy Behavior
+
+   Proxy processing of the UPDATE request is identical to any other
+   non-INVITE request.
+
+7 Definition of the UPDATE method
+
+   The semantics of the UPDATE method are described in detail above.
+   This extension adds another value to the Method BNF described in RFC
+   3261:
+
+         UPDATEm  =  %x55.50.44.41.54.45 ; UPDATE in caps
+         Method   =  INVITEm / ACKm / OPTIONSm / BYEm
+                     / CANCELm / REGISTERm / UPDATEm
+                     / extension-method
+
+   Table 1 extends Table 2 of RFC 3261 for the UPDATE method.
+
+   Table 2 updates Table 3 of RFC 3261 for the UPDATE method.
+
+8 Example Call Flow
+
+   This section presents an example call flow using the UPDATE method.
+   The flow is shown in Figure 1.  The caller sends an initial INVITE
+   (1) which contains an offer.  The callee generates a 180 response (2)
+   with an answer to that offer.  With the completion of an offer/answer
+   exchange, the session is established, although the dialog is still in
+   the early state.  The caller generates a PRACK (3) to acknowledge the
+   180, and the PRACK is answered with a 200 OK (4).  The caller decides
+   to update some aspect of the session - to put it on hold, for
+   example.  So, they generate an UPDATE request (5) with a new offer.
+   This offer is answered in the 200 response to the UPDATE (6).
+   Shortly thereafter, the callee decides to update some aspect of the
+   session, so it generates an UPDATE request (7) with an offer, and the
+   answer is sent in the 200 response (8).  Finally, the callee answers
+   the call, resulting in a 200 OK response to the INVITE (9), and then
+   an ACK (10).  Neither the 200 OK to the INVITE, nor the ACK, will
+   contain SDP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg                   Standards Track                     [Page 7]
+
+RFC 3311                   SIP UPDATE Method              September 2002
+
+
+               Header field          where   proxy  UPDATE
+               ____________________________________________
+               Accept                  R              o
+               Accept                 2xx             o
+               Accept                 415             c
+               Accept-Encoding         R              o
+               Accept-Encoding        2xx             o
+               Accept-Encoding        415             c
+               Accept-Language         R              o
+               Accept-Language        2xx             o
+               Accept-Language        415             c
+               Alert-Info                             -
+               Allow                   R              o
+               Allow                  2xx             o
+               Allow                   r              o
+               Allow                  405             m
+               Allow-Events           (1)             -
+               Authentication-Info    2xx             o
+               Authorization           R              o
+               Call-ID                 c       r      m
+               Call-Info                      ar      o
+               Contact                 R              m
+               Contact                1xx             o
+               Contact                2xx             m
+               Contact                3xx      d      o
+               Contact                485             o
+               Content-Disposition                    o
+               Content-Encoding                       o
+               Content-Language                       o
+               Content-Length                 ar      t
+               Content-Type                           *
+               CSeq                    c       r      m
+               Date                            a      o
+               Error-Info           300-699    a      o
+               Event                  (1)             -
+               Expires                                -
+               From                    c       r      m
+               In-Reply-To                            -
+               Max-Forwards            R      amr     m
+               Min-Expires                            -
+               MIME-Version                           o
+               Organization                   ar      o
+
+   Table 1: Summary of header fields, A--O ; (1) defined in [5].
+
+
+
+
+
+
+
+Rosenberg                   Standards Track                     [Page 8]
+
+RFC 3311                   SIP UPDATE Method              September 2002
+
+
+           Header field              where       proxy  UPDATE
+           ____________________________________________________
+           Priority                                       -
+           Proxy-Authenticate         407         ar      m
+           Proxy-Authenticate         401         ar      o
+           Proxy-Authorization         R          dr      o
+           Proxy-Require               R          ar      o
+           RAck                        R                  -
+           Record-Route                R          ar      o
+           Record-Route             2xx,18x       mr      o
+           Reply-To                                       -
+           Require                                ar      c
+           Retry-After          404,413,480,486           o
+                                    500,503               o
+                                    600,603               o
+           Route                       R          adr     c
+           RSeq                        -                  -
+           Server                      r                  o
+           Subject                     -                  -
+           Subscription-State         (1)                 -
+           Supported                   R                  o
+           Supported                  2xx                 o
+           Timestamp                                      o
+           To                          c           r      m
+           Unsupported                420                 m
+           User-Agent                                     o
+           Via                         R          amr     m
+           Via                        rc          dr      m
+           Warning                     r                  o
+           WWW-Authenticate           401         ar      m
+           WWW-Authenticate           407         ar      o
+
+
+   Table 2: Summary of header fields, P--Z.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg                   Standards Track                     [Page 9]
+
+RFC 3311                   SIP UPDATE Method              September 2002
+
+
+                Caller                        Callee
+                   |                             |
+                   |                             |
+                   |(1) INVITE with offer 1      |
+                   |---------------------------->|
+                   |                             |
+                   |                             |
+                   |(2) 180 with answer 1        |
+                   |<----------------------------|
+                   |                             |
+                   |                             |
+                   |(3) PRACK                    |
+                   |---------------------------->|
+                   |                             |
+                   |                             |
+                   |(4) 200 PRACK                |
+                   |<----------------------------|
+                   |                             |
+                   |                             |
+                   |(5) UPDATE with offer 2      |
+                   |---------------------------->|
+                   |                             |
+                   |                             |
+                   |(6) 200 UPDATE with answer 2 |
+                   |<----------------------------|
+                   |                             |
+                   |                             |
+                   |(7) UPDATE with offer 3      |
+                   |<----------------------------|
+                   |                             |
+                   |                             |
+                   |(8) 200 UPDATE with answer 3 |
+                   |---------------------------->|
+                   |                             |
+                   |                             |
+                   |(9) 200 INVITE               |
+                   |<----------------------------|
+                   |                             |
+                   |                             |
+                   |(10) ACK                     |
+                   |---------------------------->|
+                   |                             |
+                   |                             |
+                   |                             |
+                   |                             |
+
+                     Figure 1: UPDATE Call Flow
+
+
+
+
+Rosenberg                   Standards Track                    [Page 10]
+
+RFC 3311                   SIP UPDATE Method              September 2002
+
+
+9 Security Considerations
+
+   The security considerations for UPDATE are identical to those for
+   re-INVITE.  It is important that the UPDATE be integrity protected
+   and authenticated as coming from the same source as the entity on the
+   other end of the dialog.  RFC 3261 [1] discusses security mechanisms
+   for achieving these functions.
+
+10 IANA Considerations
+
+   As per Section 27.4 of RFC 3261 [1], this specification serves as a
+   registration for the SIP UPDATE request method.  The information to
+   be added to the registry is:
+
+      RFC 3311: This specification serves as the RFC for registering
+                the UPDATE request method.
+
+      Method Name: UPDATE
+
+      Reason Phrase: Not applicable.
+
+11 Notice Regarding Intellectual Property Rights
+
+      The IETF has been notified of intellectual property rights claimed
+      in regard to some or all of the specification contained in this
+      document.  For more information consult the online list of claimed
+      rights.
+
+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 the
+       Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+   [4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
+       Responses in the Session Initiation Protocol (SIP)", RFC 3262,
+       June 2002.
+
+   [5] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
+       Notification", RFC 3265, June 2002.
+
+
+
+
+
+Rosenberg                   Standards Track                    [Page 11]
+
+RFC 3311                   SIP UPDATE Method              September 2002
+
+
+13 Acknowledgements
+
+   The author would like to thank Jo Hornsby, Markus Isomaki, Rohan
+   Mahy, and Bob Penfield for their comments.
+
+14 Author's Address
+
+   Jonathan Rosenberg
+   dynamicsoft
+   72 Eagle Rock Avenue
+   First Floor
+   East Hanover, NJ 07936
+
+   EMail: jdrosen@dynamicsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg                   Standards Track                    [Page 12]
+
+RFC 3311                   SIP UPDATE Method              September 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                   Standards Track                    [Page 13]
+