idnits 2.17.1 draft-ietf-mmusic-sdp-media-content-06.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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 478. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 == 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 (September 22, 2006) is 6419 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 4566 (ref. '1') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3851 (ref. '6') (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. '7') (Obsoleted by RFC 5246) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group J. Hautakorpi 3 Internet-Draft G. Camarillo 4 Intended status: Standards Track Ericsson 5 Expires: March 26, 2007 September 22, 2006 7 The SDP (Session Description Protocol) Content Attribute 8 draft-ietf-mmusic-sdp-media-content-06.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 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 28 http://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 26, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document defines a new Session Description Protocol (SDP) media- 42 level attribute, 'content'. The 'content' attribute defines the 43 content of the media stream in more detailed level than the media 44 description line. The sender of an SDP session description can 45 attach the 'content' attribute to one or more media streams. The 46 receiving application can then treat each media stream differently 47 (e.g., show it on a big screen or small screen) based on its content. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Related Techniques . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Motivation for the New Content Attribute . . . . . . . . . . . 4 55 5. The Content Attribute . . . . . . . . . . . . . . . . . . . . 5 56 6. The Content Attribute in the Offer/Answer Model . . . . . . . 6 57 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 8. Operation with SMIL . . . . . . . . . . . . . . . . . . . . . 8 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 62 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 64 12.2. Informational References . . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 66 Intellectual Property and Copyright Statements . . . . . . . . . . 12 68 1. Introduction 70 The Session Description Protocol (SDP) [1] is a protocol that is 71 intended for describing multimedia sessions for the purposes of 72 session announcement, session invitation, and other forms of 73 multimedia session initiation. One of the most typical use cases of 74 SDP is the one where it is used with the Session Initiation Protocol 75 (SIP) [5]. 77 There are situations where one application receives several similar 78 media streams which are described in an SDP session description. The 79 media streams can be similar in the sense that their content cannot 80 be distinguished just by examining their media description lines 81 (e.g., two video streams). The 'content' attribute is needed so that 82 the receiving application can treat each media stream appropriately 83 based on its content. 85 This specification defines the SDP 'content' media-level attribute, 86 which provides more information about the media stream than the 'm' 87 line in an SDP session description. 89 The main purpose of this specification is to allow applications to 90 take automated actions based on the 'content' attributes. However, 91 this specification does not define those actions. Consequently, two 92 implementations can behave completely differently when receiving the 93 same 'content' attribute. 95 2. Terminology 97 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 98 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 99 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 100 described in BCP 14, RFC 2119 [3] and indicate requirement levels for 101 compliant implementations. 103 3. Related Techniques 105 The 'label' attribute [10] enables a sender to attach a pointer to a 106 particular media stream. The name space of the 'label' attribute 107 itself is unrestricted; so, in principle it could also be used to 108 convey information about the content of a media stream. However, in 109 practice, this is not possible because of the need for backward 110 compatibility. Existing implementations of the 'label' attribute 111 already use values from that unrestricted namespace in an 112 application-specific way. So, it is not possible to reserve portions 113 of the 'label' attribute's namespace without possible conflict with 114 already-used application-specific labels. 116 It is possible to assign semantics to a media stream with an external 117 document that uses the 'label' attribute as a pointer. The downside 118 of this approach is that it requires an external document. 119 Therefore, this kind of mechanism is only applicable to special use 120 cases where such external documents are used (e.g., centralized 121 conferencing). 123 Yet another way to attach semantics to a media stream is to use the 124 'i' SDP attribute, defined in [1]. However, values of the 'i' 125 attribute are intended for human users and not for automata. 127 4. Motivation for the New Content Attribute 129 Currently, SDP does not provide any means to describe what is the 130 content of a media stream (e.g., speaker's image, slides, sign 131 language) in a form that the application can understand. Of course, 132 the end user can see the content of the media stream and read its 133 title, but the application cannot understand what the media stream 134 contains. 136 The application that is receiving multiple similar (e.g., same type 137 and format) media stream needs, in some cases, to know what is the 138 content of those streams. This kind of situation occurs, for 139 example, in cases where presentation slides, the speaker's image, and 140 sign language are transported as separate media streams. It would be 141 desirable that the receiving application could distinguish them in a 142 way that it could handle them automatically in an appropriate manner. 144 +--------------------------------------+ 145 |+------------++----------------------+| 146 || || || 147 || speaker's || || 148 || image || || 149 || || || 150 |+------------+| presentation || 151 |+------------+| slides || 152 || || || 153 || sign || || 154 || language || || 155 || || || 156 |+------------++----------------------+| 157 +--------------------------------------+ 159 Figure 1: Application's screen 161 The Figure 1 presents a screen of a typical communication 162 application. The 'content' attribute makes it possible for the 163 application to decide where to show each media stream. From an end 164 user's perspective, it is desirable that the user does not need to 165 arrange media stream every time a new media session starts. 167 The 'content' attribute could also be used in more complex 168 situations. An example of such a complex situation is an application 169 controlling equipment in an auditorium. An auditorium can have many 170 different output channels for video (e.g., main screen and two 171 smaller screens) and audio (e.g., main speakers, headsets for the 172 participants). In this kind of environment, a lot of interaction 173 from the end user who operates the application would be required in 174 absence of cues from a controlling application. The 'content' 175 attribute would make it possible, for example, for an end user needs 176 to specify, only once, which output each media stream of a given 177 session should use. The application could automatically apply the 178 same media layout for subsequent sessions. So, the 'content' 179 attribute can help to reduce the amount of required end user 180 interaction considerably. 182 5. The Content Attribute 184 This specification defines a new media-level value attribute, 185 'content'. Its formatting in SDP is described by the following BNF 186 [2]: 188 content-attribute = "a=content:" mediacnt-tag 189 mediacnt-tag = mediacnt *("," mediacnt) 190 mediacnt = "slides" / "speaker" / "sl" / "main" 191 / "alt" / mediacnt-ext 192 mediacnt-ext = token 194 The 'content' attribute contains a token, which MAY be attached to a 195 media stream by a sending application. An application MAY attach a 196 content attribute to any media stream it describes. That attribute 197 contains one or more tokens describing the content of the transmitted 198 media stream to the receiving application. 200 This document provides a set of pre-defined values for the 'content' 201 attribute. Other values can be defined in the future. The pre- 202 defined values are: 204 slides: the media stream includes presentation slides. The media 205 type can be, for example, a video stream or a number of instant 206 messages with pictures. Typical use cases for this are online 207 seminars and courses. This is similar to the 'presentation' role 208 in H.239 [12]. 210 speaker: the media stream contains the image of the speaker. The 211 media can be, for example, a video stream or a still image. 212 Typical use case for this are online seminars and courses. 214 sl: the media stream contains sign language. A typical use case for 215 this is an audio stream that is translated into sign language, 216 which is sent over a video stream. 218 main: the media stream is taken from the main source. A typical use 219 case for this is a concert where the camera is shooting the 220 performer. 222 alt: the media stream is taken from the alternative source. A 223 typical use case for this is an event where the ambient sound is 224 separated from the main sound. The alternative audio stream could 225 be, for example, the sound of a jungle. Another example is the 226 video of a conference room while the main stream carries the video 227 of the speaker. This is similar to the 'live' role in H.239. 229 All these values can be used with any media type. The application 230 can make decisions on how to handle a single media stream based on 231 both the media type and the value of the 'content' attribute. 232 Therefore the situation where one value of 'content' attribute occurs 233 more than once in a single session descriptor is not problematic. 235 6. The Content Attribute in the Offer/Answer Model 237 This specification does not define a means to discover whether or not 238 the peer endpoint understands the 'content' attribute because 239 'content' values are just informative at the offer/answer model [8] 240 level. The fact that the peer endpoint does not understand the 241 'content' attribute does not keep the media session from being 242 established. The only consequence is that end user interaction on 243 the receiving side may be required to direct the individual media 244 streams appropriately. 246 Since the 'content' attribute does not have to be understood, an SDP 247 answer MAY contain 'content' attributes even if none were present in 248 the offer. Similarly, the answer MAY contain no 'content' attributes 249 even if they were present in the offer. Furthermore, the values of 250 'content' attributes does not need to match in an offer and an 251 answer. 253 The 'content' attribute can also be used in scenarios where SDP is 254 used in a declarative style. For example, 'content' attributes can 255 be used in SDP session descriptors that are distributed with Session 256 Announcement Protocol (SAP) [9]. 258 7. Examples 260 There are two examples in this section. The first example, shown 261 below, uses a single 'content' attribute value per media stream: 263 v=0 264 o=Alice 292742730 29277831 IN IP4 131.163.72.4 265 s=Second lecture from information technology 266 c=IN IP4 131.164.74.2 267 t=0 0 268 m=video 52886 RTP/AVP 31 269 a=rtpmap:31 H261/9000 270 a=content:slides 271 m=video 53334 RTP/AVP 31 272 a=rtpmap:31 H261/9000 273 a=content:speaker 274 m=video 54132 RTP/AVP 31 275 a=rtpmap:31 H261/9000 276 a=content:sl 278 The second example, below, shows a case where there is more than one 279 'content' attribute value per media stream. The difference with the 280 previous example is that now the conferencing system might 281 automatically mix the video streams from the presenter and slides: 283 v=0 284 o=Alice 292742730 29277831 IN IP4 131.163.72.4 285 s=Second lecture from information technology 286 c=IN IP4 131.164.74.2 287 t=0 0 288 m=video 52886 RTP/AVP 31 289 a=rtpmap:31 H261/9000 290 a=content:slides,speaker 291 m=video 54132 RTP/AVP 31 292 a=rtpmap:31 H261/9000 293 a=content:sl 295 8. Operation with SMIL 297 The values of 'content' attribute, defined in Section 5, can also be 298 used with SMIL [11]. SMIL contains a 'param' element, which is used 299 for describing the content of a media flow. However, this 'param' 300 element, like 'content' attribute, provides application specific 301 description of media content. 303 Details on how to use the values of the 'content' attribute with 304 SMIL's 'param' element are outside the scope of this specification. 306 9. Security Considerations 308 An attacker may attempt to add, modify, or remove 'content' 309 attributes from a session description. Depending on how an 310 implementation chooses to react to the presence or absence of a given 311 'content' attribute, this could result in an application behaving in 312 an undesirable way. So, it is strongly RECOMMENDED that integrity 313 protection be applied to the SDP session descriptions. 315 Integrity protection can be provided for session description carried 316 in SIP [5] e.g., by using S/MIME [6] or Transport Layer Security 317 (TLS) [7]. 319 It is assumed that values of 'content' attribute do not contain data 320 that would be truly harmful if it is exposed to an possible attacker. 321 It must be noted that the initial set of values does not contain any 322 data that would require confidentiality protection. However, S/MIME 323 and TLS can be used to protect confidentiality, if needed. 325 10. IANA Considerations 327 This document defines a new 'content' attribute for SDP. It also 328 defines an initial set of values for it. Some general information 329 regarding 'content' attribute is presented in the following: 331 Contact name: Jani Hautakorpi Jani.Hautakorpi@ericsson.com. 333 Attribute name: 'content'. 335 Type of attribute Media level. 337 Subject to charset: No. 339 Purpose of attribute: The 'content' attribute gives information from 340 the content of the media stream to the receiving application. 342 Allowed attribure values: "slides", "speaker", "sl", "main", "alt", 343 and any other registered values. 345 The IANA is requested to create a subregistry for 'content' attribute 346 values under the Session Description Protocol (SDP) Parameters 347 registry. The initial values for the subregistry are presented in 348 the following, and IANA is requested to add them into its database: 350 Value of 'content' attribute Reference Description 351 ---------------------------- --------- ----------- 352 slides RFC xxxx Presentation slides 353 speaker RFC xxxx Image from the speaker 354 sl RFC xxxx Sign language 355 main RFC xxxx Main media stream 356 alt RFC xxxx Alternative media stream 358 Note for the RFC Editor: 'RFC xxxx' above should be replaced by a 359 reference to the coming RFC number of this draft. 361 As per the terminology in RFC 2434 [4], the registration policy for 362 new values for the 'content' parameter shall be 'Specification 363 Required'. 365 If new values for 'content' attribute are specified in the future, 366 they should consist of a meta description of the contents of a media 367 stream. New values for 'content' attribute should not describe 368 things like what to do in order to handle a stream. 370 11. Acknowledgements 372 Authors would like to thank Arnoud van Wijk and Roni Even, who 373 provided valuable ideas for this document. We wish to thank also Tom 374 Taylor for a thorough review. 376 12. References 378 12.1. Normative References 380 [1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 381 Description Protocol", RFC 4566, July 2006. 383 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 384 Specifications: ABNF", RFC 2234, November 1997. 386 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 387 Levels", BCP 14, RFC 2119, March 1997. 389 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 390 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 392 12.2. Informational References 394 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 395 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 396 Session Initiation Protocol", RFC 3261, June 2002. 398 [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 399 (S/MIME) Version 3.1 Message Specification", RFC 3851, 400 July 2004. 402 [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 403 Protocol Version 1.1", RFC 4346, April 2006. 405 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 406 Session Description Protocol (SDP)", RFC 3264, June 2002. 408 [9] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 409 Protocol", RFC 2974, October 2000. 411 [10] Levin, O. and G. Camarillo, "The Session Description Protocol 412 (SDP) Label Attribute", RFC 4574, August 2006. 414 [11] Michel, T. and J. Ayars, "Synchronized Multimedia Integration 415 Language (SMIL 2.0) - [Second Edition]", W3C REC REC-SMIL2- 416 20050107, January 2005. 418 [12] ITU-T, "Infrastructure of audiovisual services - Systems 419 aspects; Role management and additional media channels for 420 H.300-series terminals", Series H H.239, July 2003. 422 Authors' Addresses 424 Jani Hautakorpi 425 Ericsson 426 Hirsalantie 11 427 Jorvas 02420 428 Finland 430 Email: Jani.Hautakorpi@ericsson.com 432 Gonzalo Camarillo 433 Ericsson 434 Hirsalantie 11 435 Jorvas 02420 436 Finland 438 Email: Gonzalo.Camarillo@ericsson.com 440 Full Copyright Statement 442 Copyright (C) The Internet Society (2006). 444 This document is subject to the rights, licenses and restrictions 445 contained in BCP 78, and except as set forth therein, the authors 446 retain all their rights. 448 This document and the information contained herein are provided on an 449 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 450 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 451 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 452 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 453 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 454 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 456 Intellectual Property 458 The IETF takes no position regarding the validity or scope of any 459 Intellectual Property Rights or other rights that might be claimed to 460 pertain to the implementation or use of the technology described in 461 this document or the extent to which any license under such rights 462 might or might not be available; nor does it represent that it has 463 made any independent effort to identify any such rights. Information 464 on the procedures with respect to rights in RFC documents can be 465 found in BCP 78 and BCP 79. 467 Copies of IPR disclosures made to the IETF Secretariat and any 468 assurances of licenses to be made available, or the result of an 469 attempt made to obtain a general license or permission for the use of 470 such proprietary rights by implementers or users of this 471 specification can be obtained from the IETF on-line IPR repository at 472 http://www.ietf.org/ipr. 474 The IETF invites any interested party to bring to its attention any 475 copyrights, patents or patent applications, or other proprietary 476 rights that may cover technology that may be required to implement 477 this standard. Please address the information to the IETF at 478 ietf-ipr@ietf.org. 480 Acknowledgment 482 Funding for the RFC Editor function is provided by the IETF 483 Administrative Support Activity (IASA).