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