summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4032.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4032.txt')
-rw-r--r--doc/rfc/rfc4032.txt563
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]
+