idnits 2.17.1 draft-ietf-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 (November 19, 2003) is 7464 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) == Outdated reference: A later version (-06) exists of draft-ietf-sipping-3pcc-05 Summary: 3 errors (**), 0 flaws (~~), 4 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-ietf-sip-rfc3312-update-00.txt 8 November 19, 2003 9 Expires: May, 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 Desired Status ...................................... 6 48 6 Security Considerations ............................. 6 49 7 Authors' Addresses .................................. 6 50 8 Normative References ................................ 7 51 9 Informative References .............................. 7 53 1 Introduction 55 RFC 3312 [1] defines the framework for SIP [2] preconditions and 56 focuses on media sessions that do not move around. That is, media is 57 sent between the same end-points throughout the duration of the 58 session. 60 However, media sessions established by SIP are not always static. SIP 61 offers mechanisms to provide session mobility, namely re-INVITEs and 62 UPDATEs [5]. While existing implementations of RFC 3312 [1] can 63 probably handle session mobility, there is a need to explicitly point 64 out the issues involved and make a slight update to some of the 65 procedures defined there. With the updated procedures defined in this 66 document, messages carrying precondition information become more 67 explicit about the current status of the preconditions. 69 2 Terminology 71 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 72 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 73 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3]. 75 3 Issues Related to Session Mobility 77 Section 5 of RFC 3312 [1] describes how to use SIP [2] preconditions 78 with the offer/answer model [4]. RFC 3312 gives a set of rules that 79 allow a user agent to communicate changes in the current status of 80 the preconditions to the remote user agent. 82 The idea is that a given user agent knows about the current status of 83 some part of the preconditions (e.g., send direction of the QoS 84 precondition) through local information (e.g., an RSVP RESV is 85 received indicating that resource reservation was successful). The 86 UAC informs the UAS about changes in the current status by sending an 87 offer to the UAS. The UAS, in turn, could (if needed) send an offer 88 to the UAC informing it about the status of the part of the 89 preconditions the UAS has local information about. 91 Note, however, that UASs do not usually send updates about 92 the current status to the UAC because UASs are the ones 93 resuming session establishment when all the preconditions 94 are met. Therefore, rather than performing an offer/answer 95 exchange to inform the UAC that all the preconditions are 96 met, they simply send a 180 (Ringing) response indicating 97 that session establishment has been resumed. 99 While RFC 3312 [1] allows to update current status information using 100 offers as described above, it does not allow to downgrade current 101 status values in answers, as shown in the third row of Table 3 of RFC 102 3312. However, such downgrades are sometimes needed. Figure 1 shows 103 an example where performing such a downgrade in an answer would be 104 needed. 106 3pcc 107 A controller B C 109 | | | | 110 |<-dialog 1->|<-dialog 2->| | 111 | | | | 112 | *********************** | | 113 |* MEDIA *| | 114 | *********************** | | 115 | | | | 116 | | | | 117 |<-dialog 1->|<------dialog 3----->| 118 | | | | 119 | ******************************** | 120 |* MEDIA *| 121 | ******************************** | 122 | | | | 123 | | | | 125 Figure 1: Session Mobility using 3pcc 127 The 3pcc [6] controller in Figure 1 has established a session 128 between A and B using dialog 1 towards A and dialog 2 towards B. At 129 that point, the controller wants A to have a session with C instead 130 of B. To transfer A to C (configuration shown at the bottom of Figure 131 1), the controller sends an empty (no offer) re-INVITE to A. Since A 132 does not know that the session will be moved, its offer in the 200 OK 133 states that the current status of the media stream in the send 134 direction is "Yes". The controller, after contacting C establishing 135 dialog 3, sends back an answer to A. This answer contains a new 136 destination for the media (C) and should have downgraded the current 137 status of the media stream to "No", since there is no reservation of 138 resources between A and C. 140 4 Update to RFC 3312 142 Below there are a set of new rules that update RFC 3312 [1] to 143 address the issues above. 145 The rule below applies to offerers that are moving a media stream to 146 a new address: 148 When a stream is being moved to a new transport address, the offerer 149 MUST set all the current status values it does not have local 150 information about to "No". 152 Note that for streams using segmented status (as opposed to end-to- 153 end status), the fact that the address for the media stream at the 154 local segment changes may or may not affect the status of the 155 preconditions at the remote segment. However, moving an existing 156 stream to a new location, from the preconditions point of view, is 157 like establishing a new stream. Therefore, it is appropriate to set 158 all the current status values to "No" and start a new precondition 159 negotiation from scratch. 161 The updated table and the rules below applies to an answerer that is 162 moving a media stream. That is, the offerer was not aware of the move 163 when it generated the offer. 165 Table 3 of RFC 3312 [1] needs to be updated to allow answers to 166 downgrade current status values. Table 1 below shows the result. 168 Transac. status table Local status table New values transac./local 169 ____________________________________________________________________ 170 no no no/no 171 yes yes yes/yes 172 yes no depends on local info 173 no yes depends on local info 175 Table 1: Possible values for the "Current" fields 177 An answerer MUST downgrade the current status values that received in 178 the offer if it has local information about them or if the media 179 stream is being moved to a new transport address. 181 Note that for streams using segmented status the address change at 182 the answerer may or may not affect the status of the preconditions at 183 the offerer's segment. However, as stated above, moving an existing 184 stream to a new location, from the preconditions point of view, is 185 like establishing a new stream. Therefore, it is appropriate to set 186 all the current status values to "No" and start a new precondition 187 negotiation from scratch. 189 The new table below applies to an offerer that receives an answer 190 that updates or downgrades its local status tables. 192 Offerers should update their local status tables when they receive an 193 answer as shown in Table 2. 195 Transac. status table Local status table New value Local Status 196 _________________________________________________________________ 197 no no no 198 yes yes yes 199 yes no yes 200 no yes no 202 Table 2: Possible values for the "Current" fields after an answer 204 5 Desired Status 206 The desired status that a UA wants for a media stream after the 207 stream is moved to a new transport address may be different than the 208 desired status negotiated for the stream originally. A UA, for 209 instance, may require mandatory QoS over a low-bandwidth link but be 210 satisfied with optional QoS when the stream is moved to a high- 211 bandwidth link. 213 If the new desired status is higher than the previous one (e.g., 214 optional to mandatory), the UA, following RFC 3312 procedures, may 215 upgrade its desired status in an offer or in an answer. If the new 216 desired status is lower that the previous one (e.g., mandatory to 217 optional), the UA, following RFC 3312 procedures as well, may 218 downgrade its desired status only in an offer (i.e., not in an 219 answer.) 221 6 Security Considerations 223 An attacker adding preconditions to a session description or 224 modifying existing preconditions could keep sessions from being 225 established. An attacker removing preconditions from a session 226 description could force sessions to be established without meeting 227 mandatory preconditions. 229 It is thus STRONGLY RECOMMENDED that integrity protection be applied 230 to the SDP session descriptions. S/MIME is the natural choice to 231 provide such end-to-end integrity protection, as described in RFC 232 3261 [2]. 234 7 Authors' Addresses 236 Gonzalo Camarillo 237 Ericsson 238 Advanced Signalling Research Lab. 239 FIN-02420 Jorvas 240 Finland 241 electronic mail: Gonzalo.Camarillo@ericsson.com 243 Paul Kyzivat 244 Cisco Systems 245 1414 Massachusetts Avenue, BXB500 C2-2 246 Boxborough, MA 01719 247 USA 248 electronic mail: pkyzivat@cisco.com 250 8 Normative References 252 [1] "Integration of resource management and session initiation 253 protocol (SIP)," RFC 3312, Internet Engineering Task Force, Oct. 254 2002. 256 [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 257 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 258 initiation protocol," RFC 3261, Internet Engineering Task Force, June 259 2002. 261 [3] S. Bradner, "Key words for use in RFCs to indicate requirement 262 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 264 [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 265 session description protocol (SDP)," RFC 3264, Internet Engineering 266 Task Force, June 2002. 268 9 Informative References 270 [5] J. Rosenberg, "The session initiation protocol (SIP) UPDATE 271 method," RFC 3311, Internet Engineering Task Force, Oct. 2002. 273 [6] J. Rosenberg, J. L. Peterson, H. Schulzrinne, and G. Camarillo, 274 "Best current practices for third party call control in the session 275 initiation protocol," Internet Draft draft-ietf-sipping-3pcc-05, 276 Internet Engineering Task Force, Oct. 2003. Work in progress. 278 The IETF takes no position regarding the validity or scope of any 279 intellectual property or other rights that might be claimed to 280 pertain to the implementation or use of the technology described in 281 this document or the extent to which any license under such rights 282 might or might not be available; neither does it represent that it 283 has made any effort to identify any such rights. Information on the 284 IETF's procedures with respect to rights in standards-track and 285 standards-related documentation can be found in BCP-11. Copies of 286 claims of rights made available for publication and any assurances of 287 licenses to be made available, or the result of an attempt made to 288 obtain a general license or permission for the use of such 289 proprietary rights by implementors or users of this specification can 290 be obtained from the IETF Secretariat. 292 The IETF invites any interested party to bring to its attention any 293 copyrights, patents or patent applications, or other proprietary 294 rights which may cover technology that may be required to practice 295 this standard. Please address the information to the IETF Executive 296 Director. 298 Full Copyright Statement 300 Copyright (c) The Internet Society (2003). All Rights Reserved. 302 This document and translations of it may be copied and furnished to 303 others, and derivative works that comment on or otherwise explain it 304 or assist in its implementation may be prepared, copied, published 305 and distributed, in whole or in part, without restriction of any 306 kind, provided that the above copyright notice and this paragraph are 307 included on all such copies and derivative works. However, this 308 document itself may not be modified in any way, such as by removing 309 the copyright notice or references to the Internet Society or other 310 Internet organizations, except as needed for the purpose of 311 developing Internet standards in which case the procedures for 312 copyrights defined in the Internet Standards process must be 313 followed, or as required to translate it into languages other than 314 English. 316 The limited permissions granted above are perpetual and will not be 317 revoked by the Internet Society or its successors or assigns. 319 This document and the information contained herein is provided on an 320 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 321 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 322 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 323 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 324 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.