idnits 2.17.1 draft-ietf-sip-rfc3312-update-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 412. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- 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 (September 29, 2004) is 7141 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-08 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIP Working Group G. Camarillo 2 Internet-Draft Ericsson 3 Expires: March 30, 2005 P. Kyzivat 4 Cisco Systems 5 September 29, 2004 7 Update to the Session Initiation Protocol (SIP) Preconditions 8 Framework 9 draft-ietf-sip-rfc3312-update-03.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 30, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document updates the framework for preconditions in SIP. We 45 provide guidelines for authors of new precondition types and describe 46 how to use SIP preconditions in situations that involve session 47 mobility. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Defining New Precondition Types . . . . . . . . . . . . . . . 3 54 3.1 Precondition Type Tag . . . . . . . . . . . . . . . . . . 3 55 3.2 Status Type . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.3 Precondition Strength . . . . . . . . . . . . . . . . . . 4 57 3.4 Suspending and Resuming Session Establishment . . . . . . 4 58 4. Issues Related to Session Mobility . . . . . . . . . . . . . . 5 59 4.1 Update to RFC 3312 . . . . . . . . . . . . . . . . . . . . 6 60 4.2 Desired Status . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 66 8.2 Informational References . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 68 Intellectual Property and Copyright Statements . . . . . . . . 10 70 1. Introduction 72 RFC 3312 [3] defines the framework for SIP [2] preconditions, which 73 is a generic framework that allows SIP UAs (User Agents) to suspend 74 the establishment of a session until a set of preconditions are met. 75 Although only Quality of Service (QoS) preconditions have been 76 defined so far, this framework supports different preconditions 77 types. (QoS preconditions are defined by RFC 3312 [3] as well.) 79 This document updates RFC 3312 [3]. We provide guidelines for 80 authors of new precondition types and explain which topics they need 81 to discuss when defining them. In addition, we update some of the 82 procedures in RFC 3312 to be able to use SIP preconditions in 83 situations that involve session mobility, as described below. 85 RFC 3312 [3] focuses on media sessions that do not move around. That 86 is, media is sent between the same end-points throughout the duration 87 of the session. Nevertheless, media sessions established by SIP are 88 not always static. 90 SIP offers mechanisms to provide session mobility, namely re-INVITEs 91 and UPDATEs [5]. While existing implementations of RFC 3312 [3] can 92 probably handle session mobility, there is a need to explicitly point 93 out the issues involved and make a slight update to some of the 94 procedures defined there. With the updated procedures defined in 95 this document, messages carrying precondition information become more 96 explicit about the current status of the preconditions. 98 2. Terminology 100 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 101 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 102 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 103 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 104 compliant implementations. 106 3. Defining New Precondition Types 108 Specifications defining new precondition types need to discuss the 109 topics described in this section. Having clear definitions of new 110 precondition types is essential to ensure interoperability among 111 different implementations. 113 3.1 Precondition Type Tag 115 New precondition types MUST have an associated precondition type tag 116 (e.g., "qos" is the tag for QoS preconditions). The IANA registry 117 for precondition types can be found at: 119 http://www.iana.org/assignments/sip-precond-types 121 Authors of new preconditions MUST register new precondition types, 122 and their tags, with the IANA following the instructions in Section 123 15 of RFC 3312 [3]. 125 3.2 Status Type 127 RFC 3312 [3] defines two status types: end-to-end and segmented. 128 Specifications defining new precondition types MUST indicate which of 129 these status applies to the new precondition. New preconditions can 130 use only one status type or both. For example, the QoS preconditions 131 defined in RFC 3312 can use both [3]. 133 3.3 Precondition Strength 135 RFC 3312 [3] defines optional and mandatory preconditions. 136 Specifications defining new precondition types MUST describe whether 137 or not optional preconditions are applicable, and in case they are, 138 what is the expected behavior of a UA on reception of optional 139 preconditions. 141 3.4 Suspending and Resuming Session Establishment 143 Section 6 of RFC 3312 [3] describes the behavior of UAs from the 144 moment session establishment is suspended due to a set of 145 preconditions until is resumed when these preconditions are met. In 146 general, the called user is not alterted until the preconditions are 147 met. 149 Still, in addition to not alerting the user, each precondition type 150 MUST define any extra actions UAs should perform or refrain from 151 performing when session establishment is suspended. The behavior of 152 media streams during session suspension is therefore part of the 153 definition of a particular precondition type. Some precondition 154 types may allow media streams to send and receive packets during 155 session suspension; others may not. Consequently, the following 156 paragraph from RFC 3312 only appplies to QoS preconditions: 158 While session establishment is suspended, user agents SHOULD not 159 send any data over any media stream. In the case of RTP, neither 160 RTP nor RTCP packets are sent. 162 As a clarification to the previous paragraph, the control messages 163 used to establish connections in connection-oriented transport 164 protocols (e.g., TCP SYNs) are not affected by the previous rule. 165 So, user agents follow standard rules (e.g., the SDP a:setup 166 attribute [7]) to decide when to establish the connection, regardless 167 of the presence of QoS preconditions. 169 New precondition types MUST also describe the behaviour of UAs on 170 reception of a re-INVITE or an UPDATE with preconditions for an 171 ongoing session. 173 4. Issues Related to Session Mobility 175 Section 5 oft RFC 3312 [3] describes how to use SIP [2] preconditions 176 with the offer/answer model [4]. RFC 3312 gives a set of rules that 177 allow a user agent to communicate changes in the current status of 178 the preconditions to the remote user agent. 180 The idea is that a given user agent knows about the current status of 181 some part of the preconditions (e.g., send direction of the QoS 182 precondition) through local information (e.g., an RSVP RESV is 183 received indicating that resource reservation was successful). The 184 UAC (User Agent Client) informs the UAS (User Agent Server) about 185 changes in the current status by sending an offer to the UAS. The 186 UAS, in turn, could (if needed) send an offer to the UAC informing it 187 about the status of the part of the preconditions the UAS has local 188 information about. 190 Note, however, that UASs do not usually send updates about the 191 current status to the UAC because UASs are the ones resuming 192 session establishment when all the preconditions are met. 193 Therefore, rather than performing an offer/answer exchange to 194 inform the UAC that all the preconditions are met, they simply 195 send a 180 (Ringing) response indicating that session 196 establishment has been resumed. 198 While RFC 3312 [3] allows to update current status information using 199 offers as described above, it does not allow to downgrade current 200 status values in answers, as shown in the third row of Table 3 of RFC 201 3312. However, such downgrades are sometimes needed. Figure 1 shows 202 an example where performing such a downgrade in an answer would be 203 needed. 205 3pcc 206 A Controller B C 208 | | | | 209 |<-dialog 1->|<-dialog 2->| | 210 | | | | 211 | *********************** | | 212 |* MEDIA *| | 213 | *********************** | | 214 | | | | 215 | | | | 216 |<-dialog 1->|<------dialog 3----->| 217 | | | | 218 | ******************************** | 219 |* MEDIA *| 220 | ******************************** | 221 | | | | 222 | | | | 224 Figure 1: Session mobility using 3pcc 226 The 3pcc (Third Party Call Control) [6] controller in Figure 1 has 227 established a session between A and B using dialog 1 towards A and 228 dialog 2 towards B. At that point, the controller wants A to have a 229 session with C instead of B. To transfer A to C (configuration shown 230 at the bottom of Figure 1, the controller sends an empty (no offer) 231 re-INVITE to A. Since A does not know that the session will be 232 moved, its offer in the 200 OK states that the current status of the 233 media stream in the send direction is "Yes". The controller, after 234 contacting C establishing dialog 3, sends back an answer to A. This 235 answer contains a new destination for the media (C) and should have 236 downgraded the current status of the media stream to "No", since 237 there is no reservation of resources between A and C. 239 4.1 Update to RFC 3312 241 Below there are a set of new rules that update RFC 3312 [3] to 242 address the issues above. 244 The rule below applies to offerers that are moving a media stream to 245 a new address: 247 When a stream is being moved to a new transport address, the offerer 248 MUST set all the current status values it does not have local 249 information about to "No". 251 Note that for streams using segmented status (as opposed to 252 end-to-end status), the fact that the address for the media stream at 253 the local segment changes may or may not affect the status of the 254 preconditions at the remote segment. However, moving an existing 255 stream to a new location, from the preconditions point of view, is 256 like establishing a new stream. Therefore, it is appropriate to set 257 all the current status values to "No" and start a new precondition 258 negotiation from scratch. 260 The updated table and the rules below applies to an answerer that is 261 moving a media stream. That is, the offerer was not aware of the 262 move when it generated the offer. 264 Table 3 of RFC 3312 [3] needs to be updated to allow answers to 265 downgrade current status values. The following table shows the 266 result. 268 Transac. status table Local status table New values transac./local 269 ____________________________________________________________________ 270 no no no/no 271 yes yes yes/yes 272 yes no depends on local info 273 no yes depends on local info 275 An answerer MUST downgrade the current status values that received in 276 the offer if it has local information about them or if the media 277 stream is being moved to a new transport address. 279 Note that for streams using segmented status the address change at 280 the answerer may or may not affect the status of the preconditions at 281 the offerer's segment. However, as stated above, moving an existing 282 stream to a new location, from the preconditions point of view, is 283 like establishing a new stream. Therefore, it is appropriate to set 284 all the current status values to "No" and start a new precondition 285 negotiation from scratch. 287 The new table below applies to an offerer that receives an answer 288 that updates or downgrades its local status tables. 290 Offerers should update their local status tables when they receive an 291 answer as shown in the following table. 293 Transac. status table Local status table New value Local Status 294 _________________________________________________________________ 295 no no no 296 yes yes yes 297 yes no yes 298 no yes no 300 4.2 Desired Status 302 The desired status that a UA wants for a media stream after the 303 stream is moved to a new transport address may be different than the 304 desired status negotiated for the stream originally. A UA, for 305 instance, may require mandatory QoS over a low-bandwidth link but be 306 satisfied with optional QoS when the stream is moved to a 307 high-bandwidth link. 309 If the new desired status is higher than the previous one (e.g., 310 optional to mandatory), the UA, following RFC 3312 procedures, may 311 upgrade its desired status in an offer or in an answer. If the new 312 desired status is lower that the previous one (e.g., mandatory to 313 optional), the UA, following RFC 3312 procedures as well, may 314 downgrade its desired status only in an offer (i.e., not in an 315 answer.) 317 5. Security Considerations 319 An attacker adding preconditions to a session description or 320 modifying existing preconditions could keep sessions from being 321 established. An attacker removing preconditions from a session 322 description could force sessions to be established without meeting 323 mandatory preconditions. 325 It is thus strongly RECOMMENDED that integrity protection be applied 326 to the SDP session descriptions. S/MIME is the natural choice to 327 provide such end-to-end integrity protection, as described in RFC 328 3261 [2]. 330 6. IANA Considerations 332 This document has no IANA considerations. 334 7. Acknowledges 336 Dave Oran and Allison Mankin provided useful comments on this 337 document. 339 8. References 341 8.1 Normative References 343 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 344 Levels", BCP 14, RFC 2119, March 1997. 346 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 347 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 349 Session Initiation Protocol", RFC 3261, June 2002. 351 [3] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of 352 Resource Management and Session Initiation Protocol (SIP)", RFC 353 3312, October 2002. 355 8.2 Informational References 357 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 358 Session Description Protocol (SDP)", RFC 3264, June 2002. 360 [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 361 Method", RFC 3311, October 2002. 363 [6] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, 364 "Best Current Practices for Third Party Call Control (3pcc) in 365 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 366 2004. 368 [7] Yon, D., "Connection-Oriented Media Transport in the Session 369 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-08 370 (work in progress), July 2004. 372 Authors' Addresses 374 Gonzalo Camarillo 375 Ericsson 376 Hirsalantie 11 377 Jorvas 02420 378 Finland 380 EMail: Gonzalo.Camarillo@ericsson.com 382 Paul Kyzivat 383 Cisco Systems 384 1414 Massachusetts Avenue, BXB500 C2-2 385 Boxborough, MA 01719 386 USA 388 EMail: pkyzivat@cisco.com 390 Intellectual Property Statement 392 The IETF takes no position regarding the validity or scope of any 393 Intellectual Property Rights or other rights that might be claimed to 394 pertain to the implementation or use of the technology described in 395 this document or the extent to which any license under such rights 396 might or might not be available; nor does it represent that it has 397 made any independent effort to identify any such rights. Information 398 on the procedures with respect to rights in RFC documents can be 399 found in BCP 78 and BCP 79. 401 Copies of IPR disclosures made to the IETF Secretariat and any 402 assurances of licenses to be made available, or the result of an 403 attempt made to obtain a general license or permission for the use of 404 such proprietary rights by implementers or users of this 405 specification can be obtained from the IETF on-line IPR repository at 406 http://www.ietf.org/ipr. 408 The IETF invites any interested party to bring to its attention any 409 copyrights, patents or patent applications, or other proprietary 410 rights that may cover technology that may be required to implement 411 this standard. Please address the information to the IETF at 412 ietf-ipr@ietf.org. 414 Disclaimer of Validity 416 This document and the information contained herein are provided on an 417 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 418 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 419 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 420 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 421 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 422 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 424 Copyright Statement 426 Copyright (C) The Internet Society (2004). This document is subject 427 to the rights, licenses and restrictions contained in BCP 78, and 428 except as set forth therein, the authors retain all their rights. 430 Acknowledgment 432 Funding for the RFC Editor function is currently provided by the 433 Internet Society.