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