doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc4032.txt b/doc/rfc/rfc4032.txt
new file mode 100644
index 0000000..936b443
--- /dev/null
+++ b/doc/rfc/rfc4032.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                       G. Camarillo
+Request for Comments: 4032                                      Ericsson
+Updates: 3312                                                 P. Kyzivat
+Category: Standards Track                                  Cisco Systems
+                                                              March 2005
+
+
+            Update to the Session Initiation Protocol (SIP)
+                        Preconditions Framework
+
+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 (2005).
+
+Abstract
+
+   This document updates RFC 3312, which defines the framework for
+   preconditions in SIP.  We provide guidelines for authors of new
+   precondition types and describe how to use SIP preconditions in
+   situations that involve session mobility.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   3.  Defining New Precondition Types  . . . . . . . . . . . . . . .  3
+       3.1.  Precondition Type Tag  . . . . . . . . . . . . . . . . .  3
+       3.2.  Status Type  . . . . . . . . . . . . . . . . . . . . . .  3
+       3.3.  Precondition Strength  . . . . . . . . . . . . . . . . .  3
+       3.4.  Suspending and Resuming Session Establishment  . . . . .  3
+   4.  Issues Related to Session Mobility . . . . . . . . . . . . . .  4
+       4.1.  Update to RFC 3312 . . . . . . . . . . . . . . . . . . .  5
+       4.2.  Desired Status . . . . . . . . . . . . . . . . . . . . .  7
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+       8.1.  Normative References . . . . . . . . . . . . . . . . . .  8
+
+
+
+
+
+Camarillo & Kyzivat         Standards Track                     [Page 1]
+
+RFC 4032              SIP Preconditions Framework             March 2005
+
+
+       8.2.  Informational References . . . . . . . . . . . . . . . .  8
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10
+
+1.  Introduction
+
+   RFC 3312 [3] defines the framework for SIP [2] preconditions, which
+   is a generic framework that allows SIP UAs (User Agents) to suspend
+   the establishment of a session until a set of preconditions are met.
+   Although only Quality of Service (QoS) preconditions have been
+   defined so far, this framework supports different types of
+   preconditions.  (QoS preconditions are defined by RFC 3312 as well).
+
+   This document updates RFC 3312,  provides guidelines for authors of
+   new precondition types and explains which topics they need to discuss
+   when defining them.  In addition, it updates some of the procedures
+   in RFC 3312 for using SIP preconditions in situations that involve
+   session mobility as described below.
+
+   RFC 3312 focuses on media sessions that do not move around.  That is,
+   media is sent between the same end-points throughout the duration of
+   the session.  Nevertheless, media sessions established by SIP are not
+   always static.
+
+   SIP offers mechanisms to provide session mobility, namely re-INVITEs
+   and UPDATEs [5].  While existing implementations of RFC 3312 can
+   probably handle session mobility, there is a need to explicitly point
+   out the issues involved and make a slight update on some of the
+   procedures defined there in.  With the updated procedures defined in
+   this document, messages carrying precondition information become more
+   explicit about the current status of the preconditions.
+
+   Specifically, we now allow answers to downgrade current status values
+   (this was disallowed by RFC 3312).  We consider moving an existing
+   stream to a new location as equivalent to establishing a new stream.
+   Therefore, answers moving streams to new locations set all the
+   current status values in their answers to "No" and start a new
+   precondition negotiation from scratch.
+
+2.  Terminology
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
+   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
+   described in BCP 14, RFC 2119 [1] and indicate requirement levels for
+   compliant implementations.
+
+
+
+
+
+Camarillo & Kyzivat         Standards Track                     [Page 2]
+
+RFC 4032              SIP Preconditions Framework             March 2005
+
+
+3.  Defining New Precondition Types
+
+   Specifications defining new precondition types need to discuss the
+   topics described in this section.  Having clear definitions of new
+   precondition types is essential to ensure interoperability among
+   different implementations.
+
+3.1.  Precondition Type Tag
+
+   New precondition types MUST have an associated precondition type tag
+   (e.g., "qos" is the tag for QoS preconditions).  Authors of new
+   preconditions MUST register new precondition types and their tags
+   with the IANA by following the instructions in Section 15 of RFC
+   3312.
+
+3.2.  Status Type
+
+   RFC 3312 defines two status types: end-to-end and segmented.
+   Specifications defining new precondition types MUST indicate which
+   status applies to the new precondition.  New preconditions can use
+   only one status type or both.  For example, the QoS preconditions
+   defined in RFC 3312 can use both.
+
+3.3.  Precondition Strength
+
+   RFC 3312 defines optional and mandatory preconditions.
+   Specifications defining new precondition types MUST describe whether
+   or not optional preconditions are applicable, and in case they are,
+   what is the expected behavior of a UA on reception of optional
+   preconditions.
+
+3.4.  Suspending and Resuming Session Establishment
+
+   Section 6 of RFC 3312 describes the behavior of UAs from the moment
+   session establishment is suspended, due to a set of preconditions,
+   until it is resumed when these preconditions are met.  In general,
+   the called user is not alerted until the preconditions are met.
+
+   In addition to not alerting the user, each precondition type MUST
+   define any extra actions UAs should perform or refrain from
+   performing when session establishment is suspended.  The behavior of
+   media streams during session suspension is therefore part of the
+   definition of a particular precondition type.  Some precondition
+
+
+
+
+
+
+
+
+Camarillo & Kyzivat         Standards Track                     [Page 3]
+
+RFC 4032              SIP Preconditions Framework             March 2005
+
+
+   types may allow media streams to send and receive packets during
+   session suspension; others may not.  Consequently, the following
+   paragraph from RFC 3312 only applies to QoS preconditions:
+
+      While session establishment is suspended, user agents SHOULD not
+      send any data over any media stream.  In the case of RTP, neither
+      RTP nor RTCP packets are sent.
+
+   To clarify the previous paragraph, the control messages used to
+   establish connections in connection-oriented transport protocols
+   (e.g., TCP SYNs) are not affected by the previous rule.  So, user
+   agents follow standard rules (e.g., the SDP 'setup' attribute [7]) to
+   decide when to establish the connection, regardless of QoS
+   preconditions.
+
+   New precondition types MUST also describe the behaviour of UAs on
+   reception of a re-INVITE or an UPDATE with preconditions for an
+   ongoing session.
+
+4.  Issues Related to Session Mobility
+
+   Section 5 of RFC 3312 describes how to use SIP [2] preconditions with
+   the offer/answer model [4].  RFC 3312 gives a set of rules that allow
+   a user agent to communicate changes in the current status of the
+   preconditions to the remote user agent.
+
+   The idea is that a given user agent knows about the current status of
+   some part of the preconditions (e.g., send direction of the QoS
+   precondition) through local information (e.g., an RSVP RESV is
+   received indicating that resource reservation was successful).  The
+   UAC (User Agent Client) informs the UAS (User Agent Server) about
+   changes in the current status by sending an offer to the UAS.  The
+   UAS, in turn, could (if needed) send an offer to the UAC informing it
+   about the status of the part of the preconditions the UAS has local
+   information about.
+
+      Note, however, that UASs do not usually send updates about the
+      current status to the UAC because UASs are the ones resuming
+      session establishment when all the preconditions are met.
+      Therefore, rather than performing an offer/answer exchange to
+      inform the UAC that all the preconditions are met, they simply
+      send a 180 (Ringing) response indicating that session
+      establishment has been resumed.
+
+
+
+
+
+
+
+
+Camarillo & Kyzivat         Standards Track                     [Page 4]
+
+RFC 4032              SIP Preconditions Framework             March 2005
+
+
+   While RFC 3312 allows updating current status information using the
+   methods described above, it does not allow downgrading current status
+   values in answers, as shown in the third row of Table 3 of RFC 3312.
+   Figure 1 shows how performing such a downgrade in an answer would
+   sometimes be needed.
+
+                            3pcc
+                 A       Controller        B        C
+
+                 |            |            |        |
+                 |<-dialog 1->|<-dialog 2->|        |
+                 |            |            |        |
+                 | *********************** |        |
+                 |*         MEDIA         *|        |
+                 | *********************** |        |
+                 |            |            |        |
+                 |            |            |        |
+                 |<-dialog 1->|<------dialog 3----->|
+                 |            |            |        |
+                 | ******************************** |
+                 |*             MEDIA              *|
+                 | ******************************** |
+                 |            |            |        |
+                 |            |            |        |
+
+                 Figure 1: Session mobility using 3pcc
+
+   The 3pcc (Third Party Call Control) [6] controller in Figure 1 has
+   established a session between A and B using dialog 1 towards A and
+   dialog 2 towards B.  At that point, the controller wants A to have a
+   session with C instead of B.  To transfer A to C (configuration shown
+   at the bottom of Figure 1), the controller sends an empty (no offer)
+   re-INVITE to A.  Since A does not know that the session will be
+   moved, its offer in the 200 OK states that the current status of the
+   media stream in the send direction is "Yes".  After contacting C
+   establishing dialog 3, the controller sends back an answer to A.
+   This answer contains a new destination for the media (C) and should
+   have downgraded the current status of the media stream to "No", since
+   there is no reservation of resources between A and C.
+
+4.1.  Update to RFC 3312
+
+   Below is a set of new rules that update RFC 3312 to address the
+   issues above.
+
+
+
+
+
+
+
+Camarillo & Kyzivat         Standards Track                     [Page 5]
+
+RFC 4032              SIP Preconditions Framework             March 2005
+
+
+   The rule below applies to offerers moving a media stream to a new
+   address:
+
+   When a stream is being moved to a new transport address, the offerer
+   MUST set all current status values about which it does not have local
+   information about to "No".
+
+   Note that for streams using segmented status (as opposed to end-to-
+   end status), the fact that the address for the media stream at the
+   local segment changes may or may not affect the status of
+   preconditions at the remote segment.  However, moving an existing
+   stream to a new location, from the preconditions point of view, is
+   like establishing a new stream.  Therefore, it is appropriate to set
+   all the current status values to "No" and start a new precondition
+   negotiation from scratch.
+
+   The updated table and rules below apply to an answerer that is moving
+   a media stream.  The offerer was not aware of the move when it
+   generated the offer.
+
+   Table 3 of RFC 3312 needs to be updated to allow answerers to
+   downgrade current status values.  The following table shows the
+   result.
+
+
+   Transac status table  Local status table  New values transac./local
+   ____________________________________________________________________
+            no                    no                    no/no
+           yes                   yes                   yes/yes
+           yes                    no            depends on local info
+            no                   yes            depends on local info
+
+   An answerer MUST downgrade the current status values received in the
+   offer if it has local information about them or if the media stream
+   is being moved to a new transport address.
+
+   Note that for streams using segmented status, the address change at
+   the answerer may or may not affect the status of the preconditions at
+   the offerer's segment.  However, as stated above, moving an existing
+   stream to a new location, from the preconditions point of view, is
+   like establishing a new stream.  Therefore, it is appropriate to set
+   all the current status values to "No" and start a new precondition
+   negotiation from scratch.
+
+   The new table below applies to an offerer that receives an answer
+   that updates or downgrades its local status tables.
+
+
+
+
+
+Camarillo & Kyzivat         Standards Track                     [Page 6]
+
+RFC 4032              SIP Preconditions Framework             March 2005
+
+
+   Offerers should update their local status tables when they receive an
+   answer as shown in the following table.
+
+
+   Transac. status table  Local status table  New value Local Status
+   _________________________________________________________________
+            no                    no                    no
+           yes                   yes                   yes
+           yes                    no                   yes
+            no                   yes                    no
+
+4.2.  Desired Status
+
+   The desired status that a UA wants for a media stream after the
+   stream is moved to a new transport address may be different than the
+   desired status negotiated for the stream originally.  A UA, for
+   instance, may require mandatory QoS over a low bandwidth link but be
+   satisfied with optional QoS when the stream is moved to a high
+   bandwidth link.
+
+   If the new desired status is higher than the previous one (e.g.,
+   optional to mandatory), the UA, following RFC 3312 procedures, may
+   upgrade its desired status in an offer or in an answer.  If the new
+   desired status is lower that the previous one (i.e., mandatory to
+   optional), the UA, following RFC 3312 procedures as well, may
+   downgrade its desired status only in an offer (i.e., not in an
+   answer.)
+
+5.  Security Considerations
+
+   An attacker adding preconditions to a session description or
+   modifying existing preconditions could prevent establishment of
+   sessions.  An attacker removing preconditions from a session
+   description could force sessions to be established without meeting
+   mandatory preconditions.
+
+   Thus, it is strongly RECOMMENDED that integrity protection be applied
+   to the SDP session descriptions.  S/MIME is the natural choice to
+   provide such end-to-end integrity protection, as described in RFC
+   3261 [2].
+
+6.  IANA Considerations
+
+   The IANA registration requirements for the preconditions framework
+   are defined in RFC 3312.  Any new preconditions are governed by the
+   IANA Considerations there.
+
+
+
+
+
+Camarillo & Kyzivat         Standards Track                     [Page 7]
+
+RFC 4032              SIP Preconditions Framework             March 2005
+
+
+7.  Acknowledgement
+
+   Dave Oran and Allison Mankin provided useful comments on this
+   document.
+
+8.  References
+
+8.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  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.
+
+   [3]  Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
+        Resource Management and Session Initiation Protocol (SIP)", RFC
+        3312, October 2002.
+
+8.2.  Informational References
+
+   [4]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+        Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+   [5]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
+        Method", RFC 3311, October 2002.
+
+   [6]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
+        "Best Current Practices for Third Party Call Control (3pcc) in
+        the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
+        2004.
+
+   [7]  Yon, D. and Camarillo, G., "TCP-Based Media Transport in the
+        Session Description Protocol (SDP)", Work In Progress, November
+        2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo & Kyzivat         Standards Track                     [Page 8]
+
+RFC 4032              SIP Preconditions Framework             March 2005
+
+
+Authors' Addresses
+
+   Gonzalo Camarillo
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   EMail: Gonzalo.Camarillo@ericsson.com
+
+
+   Paul Kyzivat
+   Cisco Systems
+   1414 Massachusetts Avenue, BXB500 C2-2
+   Boxborough, MA  01719
+   USA
+
+   EMail: pkyzivat@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo & Kyzivat         Standards Track                     [Page 9]
+
+RFC 4032              SIP Preconditions Framework             March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Camarillo & Kyzivat         Standards Track                    [Page 10]
+