idnits 2.17.1 draft-camarillo-sip-rfc3312-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The abstract seems to indicate that this document updates RFC3312, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 28, 2003) is 7540 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft G. Camarillo 4 Ericsson 5 P. Kyzivat 6 Cisco 7 draft-camarillo-sip-rfc3312-update-00.txt 8 August 28, 2003 9 Expires: February, 2004 11 Interactions of Preconditions with Session 12 Mobility in the Session Initiation Protocol (SIP) 14 STATUS OF THIS MEMO 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 To view the list Internet-Draft Shadow Directories, see 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document describes how to use SIP preconditions in situations 38 that involve session mobility. This document updates RFC3312, which 39 defines the framework for SIP preconditions. 41 Table of Contents 43 1 Introduction ........................................ 3 44 2 Terminology ......................................... 3 45 3 Issues Related to Session Mobility .................. 3 46 4 Update to RFC 3312 .................................. 4 47 5 Security Considerations ............................. 6 48 6 Authors' Addresses .................................. 6 49 7 Normative References ................................ 6 50 8 Informative References .............................. 7 52 1 Introduction 54 RFC 3312 [1] defines the framework for SIP [2] preconditions and 55 focuses on media sessions that do not move around. That is, media is 56 sent between the same end-points throughout the duration of the 57 session. 59 However, media sessions established by SIP are not always static. SIP 60 offers mechanisms to provide session mobility, namely re-INVITEs and 61 UPDATEs [5]. While existing implementations of RFC 3312 [1] can 62 probably handle session mobility, there is a need to explicitly point 63 out the issues involved and make a slight update to some of the 64 procedures defined there. With the updated procedures defined in this 65 document, messages carrying precondition information become more 66 explicit about the current status of the preconditions. 68 2 Terminology 70 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 71 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 72 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3]. 74 3 Issues Related to Session Mobility 76 Section 5 of RFC 3312 [1] describes how to use SIP [2] preconditions 77 with the offer/answer model [4]. RFC 3312 gives a set of rules that 78 allow a user agent to communicate changes in the current status of 79 the preconditions to the remote user agent. 81 The idea is that a given user agent knows about the current status of 82 some part of the preconditions (e.g., send direction of the QoS 83 precondition) through local information (e.g., an RSVP RESV is 84 received indicating that resource reservation was successful). The 85 UAC informs the UAS about changes in the current status by sending an 86 offer to the UAS. The UAS, in turn, could (if needed) send an offer 87 to the UAC informing it about the status of the part of the 88 preconditions the UAS has local information about. 90 Note, however, that UASs do not usually send updates about 91 the current status to the UAC because UASs are the ones 92 resuming session establishment when all the preconditions 93 are met. Therefore, rather than performing an offer/answer 94 exchange to inform the UAC that all the preconditions are 95 met, they simply send a 180 (Ringing) response indicating 96 that session establishment has been resumed. 98 While RFC 3312 [1] allows to update current status information using 99 offers as described above, it does not allow to downgrade current 100 status values in answers, as shown in the third row of Table 3 of RFC 101 3312. However, such downgrades are sometimes needed. Figure 1 shows 102 an example where performing such a downgrade in an answer would be 103 needed. 105 3pcc 106 A controller B C 108 | | | | 109 |<-dialog 1->|<-dialog 2->| | 110 | | | | 111 | *********************** | | 112 |* MEDIA *| | 113 | *********************** | | 114 | | | | 115 | | | | 116 |<-dialog 1->|<------dialog 3----->| 117 | | | | 118 | ******************************** | 119 |* MEDIA *| 120 | ******************************** | 121 | | | | 122 | | | | 124 Figure 1: Session Mobility using 3pcc 126 The 3pcc [6] controller in Figure 1 has established a session 127 between A and B using dialog 1 towards A and dialog 2 towards B. At 128 that point, the controller wants A to have a session with C instead 129 of B. To transfer A to C (configuration shown at the bottom of Figure 130 1), the controller sends an empty (no offer) re-INVITE to A. Since A 131 does not know that the session will be moved, its offer in the 200 OK 132 states that the current status of the media stream in the send 133 direction is "Yes". The controller, after contacting C establishing 134 dialog 3, sends back an answer to A. This answer contains a new 135 destination for the media (C) and should have downgraded the current 136 status of the media stream to "No", since there is no reservation of 137 resources between A and C. 139 4 Update to RFC 3312 141 Below there are a set of new rules that update RFC 3312 [1] to 142 address the issues above. 144 The rule below applies to offerers that are moving a media stream to 145 a new address: 147 When a stream is being moved to a new transport address, the offerer 148 MUST set all the current status values it does not have local 149 information about to "No". 151 Note that for streams using segmented status (as opposed to end-to- 152 end status), the fact that the address for the media stream at the 153 local segment changes may or may not affect the status of the 154 preconditions at the remote segment. However, moving an existing 155 stream to a new location, from the preconditions point of view, is 156 like establishing a new stream. Therefore, it is appropriate to set 157 all the current status values to "No" and start a new precondition 158 negotiation from scratch. 160 The updated table and the rules below applies to an answerer that is 161 moving a media stream. That is, the offerer was not aware of the move 162 when it generated the offer. 164 Table 3 of RFC 3312 [1] needs to be updated to allow answers to 165 downgrade current status values. Table 1 below shows the result. 167 Transac. status table Local status table New values transac./local 168 ____________________________________________________________________ 169 no no no/no 170 yes yes yes/yes 171 yes no depends on local info 172 no yes depends on local info 174 Table 1: Possible values for the "Current" fields 176 An answerer MUST downgrade the current status values that received in 177 the offer if it has local information about them or if the media 178 stream is being moved to a new transport address. 180 Note that for streams using segmented status the address change at 181 the answerer may or may not affect the status of the preconditions at 182 the offerer's segment. However, as stated above, moving an existing 183 stream to a new location, from the preconditions point of view, is 184 like establishing a new stream. Therefore, it is appropriate to set 185 all the current status values to "No" and start a new precondition 186 negotiation from scratch. 188 The new table below applies to an offerer that receives an answer 189 that updates or downgrades its local status tables. 191 Offerers should update their local status tables when they receive an 192 answer as shown in Table 2. 194 Transac. status table Local status table New value Local Status 195 _________________________________________________________________ 196 no no no 197 yes yes yes 198 yes no yes 199 no yes no 201 Table 2: Possible values for the "Current" fields after an answer 203 5 Security Considerations 205 An attacker adding preconditions to a session description or 206 modifying existing preconditions could keep sessions from being 207 established. An attacker removing preconditions from a session 208 description could force sessions to be established without meeting 209 mandatory preconditions. 211 It is thus STRONGLY RECOMMENDED that integrity protection be applied 212 to the SDP session descriptions. S/MIME is the natural choice to 213 provide such end-to-end integrity protection, as described in RFC 214 3261 [2]. 216 6 Authors' Addresses 218 Gonzalo Camarillo 219 Ericsson 220 Advanced Signalling Research Lab. 221 FIN-02420 Jorvas 222 Finland 223 electronic mail: Gonzalo.Camarillo@ericsson.com 225 Paul Kyzivat 226 Cisco Systems 227 1414 Massachusetts Avenue, BXB500 C2-2 228 Boxborough, MA 01719 229 USA 230 electronic mail: pkyzivat@cisco.com 232 7 Normative References 234 [1] "Integration of resource management and session initiation 235 protocol (SIP)," RFC 3312, Internet Engineering Task Force, Oct. 236 2002. 238 [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 239 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 240 initiation protocol," RFC 3261, Internet Engineering Task Force, June 241 2002. 243 [3] S. Bradner, "Key words for use in RFCs to indicate requirement 244 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 246 [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 247 session description protocol (SDP)," RFC 3264, Internet Engineering 248 Task Force, June 2002. 250 8 Informative References 252 [5] J. Rosenberg, "The session initiation protocol (SIP) UPDATE 253 method," RFC 3311, Internet Engineering Task Force, Oct. 2002. 255 [6] J. Rosenberg, J. L. Peterson, H. Schulzrinne, and G. Camarillo, 256 "Best current practices for third party call control in the session 257 initiation protocol," internet draft, Internet Engineering Task 258 Force, July 2003. Work in progress. 260 The IETF takes no position regarding the validity or scope of any 261 intellectual property or other rights that might be claimed to 262 pertain to the implementation or use of the technology described in 263 this document or the extent to which any license under such rights 264 might or might not be available; neither does it represent that it 265 has made any effort to identify any such rights. Information on the 266 IETF's procedures with respect to rights in standards-track and 267 standards-related documentation can be found in BCP-11. Copies of 268 claims of rights made available for publication and any assurances of 269 licenses to be made available, or the result of an attempt made to 270 obtain a general license or permission for the use of such 271 proprietary rights by implementors or users of this specification can 272 be obtained from the IETF Secretariat. 274 The IETF invites any interested party to bring to its attention any 275 copyrights, patents or patent applications, or other proprietary 276 rights which may cover technology that may be required to practice 277 this standard. Please address the information to the IETF Executive 278 Director. 280 Full Copyright Statement 282 Copyright (c) The Internet Society (2003). All Rights Reserved. 284 This document and translations of it may be copied and furnished to 285 others, and derivative works that comment on or otherwise explain it 286 or assist in its implementation may be prepared, copied, published 287 and distributed, in whole or in part, without restriction of any 288 kind, provided that the above copyright notice and this paragraph are 289 included on all such copies and derivative works. However, this 290 document itself may not be modified in any way, such as by removing 291 the copyright notice or references to the Internet Society or other 292 Internet organizations, except as needed for the purpose of 293 developing Internet standards in which case the procedures for 294 copyrights defined in the Internet Standards process must be 295 followed, or as required to translate it into languages other than 296 English. 298 The limited permissions granted above are perpetual and will not be 299 revoked by the Internet Society or its successors or assigns. 301 This document and the information contained herein is provided on an 302 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 303 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 304 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 305 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 306 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.