idnits 2.17.1 draft-ietf-sipping-early-disposition-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 444. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 450. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 466), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** 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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 366 has weird spacing: '...session the ...' == 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 (April 2004) is 7315 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) ** Obsolete normative reference: RFC 3489 (ref. '5') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '7') (Obsoleted by RFC 4566) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: September 30, 2004 April 2004 6 The Early Session Disposition Type for the Session Initiation 7 Protocol (SIP) 8 draft-ietf-sipping-early-disposition-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 30, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document defines a new disposition type (early-session) for the 41 Content-Disposition header field in SIP. The treatment of 42 "early-session" bodies is similar to the treatment of "session" 43 bodies. That is, they follow the offer/answer model. Their only 44 difference is that session descriptions whose disposition type is 45 "early-session" are used to establish early media sessions within 46 early dialogs, as opposed to regular sessions within regular dialogs. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Issues Related to Early Media Session Establishment . . . . 3 53 4. The Early Session Disposition Type . . . . . . . . . . . . . 4 54 5. Preconditions . . . . . . . . . . . . . . . . . . . . . . . 5 55 6. Option tag . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 8. Security Considerations . . . . . . . . . . . . . . . . . . 8 58 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 59 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 60 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 11.1 Normative References . . . . . . . . . . . . . . . . . . . 10 62 11.2 Informational References . . . . . . . . . . . . . . . . . 10 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 64 Intellectual Property and Copyright Statements . . . . . . . 11 66 1. Introduction 68 Early media refers to media (e.g., audio and video) that is exchanged 69 before a particular session is accepted by the called user. Within a 70 dialog, early media occurs from the moment the initial INVITE is sent 71 until the UAS generates a final response. It may be unidirectional or 72 bidirectional, and can be generated by the caller, the callee, or 73 both. Typical examples of early media generated by the callee are 74 ringing tone and announcements (e.g., queuing status). Early media 75 generated by the caller typically consists of voice commands or DTMF 76 tones to drive IVRs. 78 The basic SIP specification (RFC 3261 [2]) only supports very simple 79 early media mechanisms. These simple mechanisms have a number of 80 problems which relate to forking and security, and do not satisfy the 81 requirements of most applications. RFC xxxx [8] goes beyond the 82 mechanisms defined in RFC 3261 [2] and describes two models to 83 implement early media using SIP: the gateway model and the 84 application server model. 86 Although both early media models described in RFC xxxx [8] are 87 superior to the one specified in RFC 3261 [2], the gateway model 88 still presents a set of issues. In particular, the gateway model does 89 not work well with forking. Nevertheless, the gateway model is needed 90 because some SIP entities (in particular, some gateways) cannot 91 implement the application server model. 93 The application server model addresses some of the issues present in 94 the gateway model. This model uses the early-session disposition 95 type, which is specified in this document. 97 2. Terminology 99 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 100 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 101 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 102 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 103 compliant implementations. 105 3. Issues Related to Early Media Session Establishment 107 Traditionally, early media sessions have been established in the same 108 way as regular sessions. That is, using an offer/answer exchange 109 where the disposition type of the session descriptions is "session". 110 Application servers perform an offer/answer exchange with the UAC to 111 exchange early media exclusively, while UASs use the same offer/ 112 answer exchange, first to exchange early media, and once the regular 113 dialog is established, to exchange regular media. This way of 114 establishing early media sessions is known as the gateway model [8], 115 which presents some issues which relate to forking and security. 116 These issues exist when this model is used by either an application 117 server or by a UAS. 119 Application servers may not be able to generate an answer for an 120 offer received in the INVITE. The UAC created the offer for the UAS, 121 and so, it may have applied end-to-end encryption or have included 122 information (e.g., related to key management) that the application 123 server is not supposed to use. Therefore, application servers need a 124 means to perform an offer/answer exchange with the UAC which is 125 independent from the offer/answer exchange between both UAs. 127 UASs using the offer/answer exchange that will carry regular media to 128 send and receive early media can cause media clipping, as described 129 in Section 2.1.1 of [8]. Some UACs cannot receive early media from 130 different UASs at the same time. So, when an INVITE forks and several 131 UASs start sending early media, the UAC mutes all the UASs but one 132 (which is usually randomly chosen). If the UAS that accepts the 133 INVITE (i.e., sends a 200 OK) was muted, a new offer/answer exchange 134 is needed to unmute it. This usually causes media clipping. 135 Therefore, UASs need a means to perform an offer/answer exchange with 136 the UAC to exchange early media which is independent from the offer/ 137 answer exchanged used to exchange regular media. 139 A potential solution to this need would be to establish a different 140 dialog using a globally routable URI to perform an independent offer/ 141 answer exchange. This dialog would be labelled as a dialog for early 142 media and would be related to the original dialog somehow at the UAC. 143 However, performing all the offer/answer exchanges within the 144 original dialog has many advantages: 146 o It is simpler. 147 o It does not have synchronization problems, because all the early 148 dialogs are terminated when the session is accepted. 149 o It does not require globally routable URIs. 150 o It does not introduce service interaction issues related to 151 services that may be wrongly applied to the new dialog. 152 o It makes firewall management easier. 154 This way of performing offer/answer exchanges for early media is 155 referred to as the application server model [8]. This model uses the 156 early-session disposition type, which we define in the following 157 section. 159 4. The Early Session Disposition Type 161 We define a new disposition type for the Content-Disposition header 162 field: early-session. User agents MUST use early-session bodies to 163 establish early media sessions in the same way as they use session 164 bodies to establish regular sessions, as described in RFC 3261 [2] 165 and in RFC 3264 [3]. Particularly, early-session bodies MUST follow 166 the offer/answer model and MAY appear in the same messages as session 167 bodies do with the exceptions of 2xx responses for an INVITE and 168 ACKs. Nevertheless, it is NOT RECOMMENDED to include early offers in 169 INVITEs because they can fork, and the UAC could receive multiple 170 early answers establishing early media streams at roughly the same 171 time. It is also NOT RECOMMENDED to use the same transport address 172 (IP address plus port) in a session body and in an early-session 173 body. Using different transport addresses (e.g., different ports) to 174 receive early and regular media makes it easy to detect the start of 175 the regular media. 177 If a UA needs to refuse an early-session offer, it MUST to so by 178 refusing all the media streams in it. When SDP [7] is used, this is 179 done by setting the port number of all the media streams to zero. 181 This is the same mechanism that UACs use to refuse regular offers 182 that arrive in a response to an empty INVITE. 184 An early media session established using early-session bodies MUST be 185 terminated when its corresponding early dialog is terminated or it 186 transitions to a regular dialog. 188 It is RECOMMENDED that UAs generating regular and early session 189 descriptions use, as long as it is possible, the same codecs in both. 190 This way, the remote UA does not need to change codecs when the early 191 session transitions to a regular session. 193 5. Preconditions 195 RFC 3312 [4] defines a framework for preconditions for SDP. 196 Early-sessions MAY contain preconditions, which are treated in the 197 same way as preconditions in regular sessions. That is, the UAs do 198 not exchange media and the called user is not alerted until the 199 preconditions are met. 201 6. Option tag 203 We define an option tag to be used in Require and Supported header 204 fields. Its name is early-session. A UA adding the early-session 205 option tag to a message indicates that it understands the 206 early-session disposition type. 208 7. Example 210 Figure 1 shows the message flow between two UAs. INVITE (1) has an 211 early-session option tag in its Supported header field and the body 212 shown in Figure 2. The UAS sends back a response with two body parts, 213 as shown in Figure 3; one of disposition type session and the other 214 early-session. The session body part is the answer to the offer in 215 the INVITE. The early-session body part is an offer to establish an 216 early media session. When the UAC receives the 183 (Session Progress) 217 response, it sends the answer to the early-session offer in a PRACK, 218 as shown in Figure 4. This early media session is terminated when the 219 early dialog transitions to a regular dialog. That is, when the UAS 220 sends the (5) 200 (OK) response for the INVITE. 222 A B 223 | | 224 |--------(1) INVITE-------->| 225 | offer | 226 | | 227 |<--(2) Session Progress----| 228 | early-offer | 229 | answer | 230 | | 231 |---------(3) PRACK-------->| 232 | early-answer | 233 | | 234 |<--------(4) 200 OK--------| 235 | | 236 | * * | 237 | ************************* | 238 |* Early Media *| 239 | ************************* | 240 | * * | 241 | | 242 |<--------(5) 200 OK--------| 243 | | 244 |----------(6) ACK--------->| 245 | | 247 Figure 1: Message flow 249 Content-Type: application/sdp 250 Content-Disposition: session 252 v=0 253 o=alice 2890844730 2890844731 IN IP4 host.example.com 254 s= 255 c=IN IP4 192.0.0.1 256 t=0 0 257 m=audio 20000 RTP/AVP 0 259 Figure 2: Offer 261 Content-Type: multipart/mixed; boundary="boundary1" 262 Content-Length: 401 264 --boundary1 265 Content-Type: application/sdp 266 Content-Disposition: session 268 v=0 269 o=Bob 2890844725 2890844725 IN IP4 host.example2.com 270 s= 271 c=IN IP4 192.0.0.2 272 t=0 0 273 m=audio 30000 RTP/AVP 0 275 --boundary1 276 Content-Type: application/sdp 277 Content-Disposition: early-session 279 v=0 280 o=Bob 2890844714 2890844714 IN IP4 host.example2.com 281 s= 282 c=IN IP4 192.0.0.2 283 t=0 0 284 m=audio 30002 RTP/AVP 0 286 --boundary1-- 288 Figure 3: Early offer and answer 290 Content-Type: application/sdp 291 Content-Disposition: early-session 293 v=0 294 o=alice 2890844717 2890844717 IN IP4 host.example.com 295 s= 296 c=IN IP4 192.0.0.1 297 t=0 0 298 m=audio 20002 RTP/AVP 0 300 Figure 4: Answer 302 8. Security Considerations 304 The security implications of using early-session bodies in SIP are 305 the same as the ones of using session bodies; they are part of the 306 offer/answer model. 308 SIP uses the offer/answer model [3] to establish early sessions in 309 both the gateway and the application server models. User Agents (UAs) 310 generate a session description, which contains the transport address 311 (i.e., IP address plus port) where they want to receive media, and 312 send it to their peer in a SIP message. When media packets arrive at 313 this transport address, the UA assumes that they come from the 314 receiver of the SIP message carrying the session description. 315 Nevertheless, attackers may attempt to gain access to the contents of 316 the SIP message and send packets to the transport address contained 317 in the session description. To prevent this situation, UAs SHOULD 318 encrypt their session descriptions (e.g., using S/MIME). 320 Still, even if a UA encrypts its session descriptions, an attacker 321 may try to guess the transport address used by the UA and send media 322 packets to that address. Guessing such a transport address is 323 sometimes easier than it may seem because many UAs always pick up the 324 same initial media port. To prevent this situation, UAs SHOULD use 325 media-level authentication mechanisms (e.g., SRTP [6]). In addition, 326 UAs that wish to keep their communications confidential SHOULD use 327 media-level encryption mechanisms (e.g, SRTP [6]). 329 Attackers may attempt to make a UA send media to a victim as part of 330 a DoS attack. This can be done by sending a session description with 331 the victim's transport address to the UA. To prevent this attack, 332 the UA SHOULD engage in a handshake with the owner of the transport 333 address received in a session descriptions (just verifying 334 willingness to receive media) before sending a large amount of data 335 to the transport address. This check can be performed by using a 336 connection oriented transport protocol, by using STUN [5] in an 337 end-to-end fashion, or by the key exchange in SRTP [6]. 339 In any event, note that the previous security considerations are not 340 early media specific, but apply to the usage of the offer/answer 341 model in SIP to establish sessions in general. 343 Additionally, an early media-specific risk (roughly speaking, an 344 equivalent to forms of "toll fraud" in the PSTN) attempts to exploit 345 the different charging policies some operators apply to early and to 346 regular media. When UAs are allowed to exchange early media for free, 347 but are required to pay for regular media sessions, rogue UAs may try 348 to establish a bidirectional early media session and never send a 2xx 349 response for the INVITE. 351 On the other hand, some application servers (e.g., Interactive Voice 352 Response systems) use bidirectional early media to obtain information 353 from the callers (e.g., the PIN code of a calling card). So, we do 354 not recommend that operators disallow bidirectional early media. 355 Instead, operators should consider a remedy of charging early media 356 exchanges that last too long, or stopping them at the media level 357 (according to the operator's policy). 359 9. IANA Considerations 361 This document defines a new Content-Disposition header field 362 disposition type (early-session) in Section 4. This value should be 363 registered in the IANA registry for Content-Dispositions with the 364 following description: 366 early-session the body describes an early communications 367 session, for example, an RFC 2327 SDP body 369 This document defines a SIP option tag (early-session) in Section 6. 370 It should be registered in the SIP parameters registry (http:// 371 www.iana.org/assignments/sip-parameters) under "Option Tags", with 372 the following description. 374 A UA adding the early-session option tag to a message indicates 375 that it understands the early-session content disposition. 377 10. Acknowledgements 379 Francois Audet, Christer Holmberg, and Allison Mankin provided useful 380 comments on this document. 382 11. References 384 11.1 Normative References 386 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 387 Levels", BCP 14, RFC 2119, March 1997. 389 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 390 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 391 Session Initiation Protocol", RFC 3261, June 2002. 393 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 394 Session Description Protocol (SDP)", RFC 3264, June 2002. 396 [4] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of 397 Resource Management and Session Initiation Protocol (SIP)", RFC 398 3312, October 2002. 400 [5] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 401 Simple Traversal of User Datagram Protocol (UDP) Through Network 402 Address Translators (NATs)", RFC 3489, March 2003. 404 [6] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. 405 Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 406 3711, March 2004. 408 11.2 Informational References 410 [7] Handley, M. and V. Jacobson, "SDP: Session Description 411 Protocol", RFC 2327, April 1998. 413 [8] Camarillo, G. and H. Schulzrinne, "Early Media and Ringback Tone 414 Generation in the Session Initiation Protocol", 415 draft-camarillo-sipping-early-media-02 (work in progress), July 416 2003. 418 Author's Address 420 Gonzalo Camarillo 421 Ericsson 422 Hirsalantie 11 423 Jorvas 02420 424 Finland 426 EMail: Gonzalo.Camarillo@ericsson.com 428 Intellectual Property Statement 430 The IETF takes no position regarding the validity or scope of any 431 Intellectual Property Rights or other rights that might be claimed to 432 pertain to the implementation or use of the technology described in 433 this document or the extent to which any license under such rights 434 might or might not be available; nor does it represent that it has 435 made any independent effort to identify any such rights. Information 436 on the IETF's procedures with respect to rights in IETF Documents can 437 be found in BCP 78 and BCP 79. 439 Copies of IPR disclosures made to the IETF Secretariat and any 440 assurances of licenses to be made available, or the result of an 441 attempt made to obtain a general license or permission for the use of 442 such proprietary rights by implementers or users of this 443 specification can be obtained from the IETF on-line IPR repository at 444 http://www.ietf.org/ipr. 446 The IETF invites any interested party to bring to its attention any 447 copyrights, patents or patent applications, or other proprietary 448 rights that may cover technology that may be required to implement 449 this standard. Please address the information to the IETF at 450 ietf-ipr@ietf.org. 452 Disclaimer of Validity 454 This document and the information contained herein are provided on an 455 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 456 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 457 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 458 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 459 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 460 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 462 Copyright Statement 464 Copyright (C) The Internet Society (2004). This document is subject 465 to the rights, licenses and restrictions contained in BCP 78, and 466 except as set forth therein, the authors retain all their rights. 468 Acknowledgment 470 Funding for the RFC Editor function is currently provided by the 471 Internet Society.