idnits 2.17.1 draft-ietf-mmusic-sdp-media-content-04.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 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 464. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (June 30, 2006) is 6509 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 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) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 Expires: January 1, 2007 Ericsson 5 June 30, 2006 7 The SDP (Session Description Protocol) Content Attribute 8 draft-ietf-mmusic-sdp-media-content-04.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 January 1, 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 the media description lines (e.g., 81 two video streams). The 'content' attribute is needed, so that the 82 receiving application can treat each media stream appropriately based 83 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 2. Terminology 91 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 92 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 93 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 94 described in BCP 14, RFC 2119 [3] and indicate requirement levels for 95 compliant implementations. 97 3. Related Techniques 99 The 'label' attribute [9] enables a sender to attach a pointer to a 100 particular media stream. The name space of the 'label' attribute 101 itself is unrestricted, so in principle it could also be used to 102 convey information about the content of a media stream. However, in 103 practice, this is not possible because of the need for backward 104 compatibility. Existing implementations of the 'label' attribute 105 already use values from that unrestricted namespace in an application 106 specific way. So it is not possible to reserve portions of the 107 'label' attribute's namespace without possible conflict with already 108 used, application specific labels. 110 It is possible to assign semantics to a media stream with an external 111 document that uses the 'label' attribute as a pointer. The downside 112 of this approach is that it requires external document. Typically 113 this kind of mechanism would be defined for some particular use case, 114 for example centralized conferencing. 116 Yet another way to attach semantics to a media stream is by using the 117 'i' SDP attribute, defined in [1]. However, values of the 'i' 118 attribute are intended for human users and not for automata. 120 4. Motivation for the New Content Attribute 122 Currently, SDP does not provide any means to describe what is the 123 content of a media stream (e.g., speaker's image, slides, sign 124 language) in a form that the application can understand. Of course 125 the end user can see the content of the media stream and read its 126 title, but the application cannot understand what the media stream 127 contains. 129 The application that is receiving multiple similar (e.g., same type 130 and format) media stream needs, in some cases, to know what is the 131 content of those streams. This kind of situation occurs, for 132 example, in cases where presentation slides, the speaker's image and 133 sign language are transported as separate media streams. It would be 134 desirable that the receiving application could distinguish them in a 135 way that it could handle them automatically in appropriate manner. 137 +--------------------------------------+ 138 |+------------++----------------------+| 139 || || || 140 || speaker's || || 141 || image || || 142 || || || 143 |+------------+| presentation || 144 |+------------+| slides || 145 || || || 146 || sign || || 147 || language || || 148 || || || 149 |+------------++----------------------+| 150 +--------------------------------------+ 152 Figure 1: Application's screen 154 The Figure 1 presents a screen of a typical communication 155 application. The 'content' attribute enables the application to make 156 the decision on where to show each media stream. From an end user's 157 perspective, it is desirable that the user does not need to arrange 158 media stream every time the media session starts. 160 The 'content' attribute could also be used in more complex 161 situations. This kind of complex situation could be e.g., an 162 application that is controlling the equipment in an auditorium. An 163 auditorium can have many different output channels for the video 164 (main screen and two smaller screens) and the audio (main speakers, 165 headsets for the participants). In this kind of environment, a lot 166 of interaction from the end user who is operating the application 167 would be required in absence of cues from a controlling application. 168 So, the possibility for such an application to handle the media 169 stream without end users' input is highly desirable. 171 5. The Content Attribute 173 This specification defines a new media-level value attribute, 174 'content'. Its formatting in SDP is described by the following BNF 175 [2]: 177 content-attribute = "a=content:" mediacnt-tag 178 mediacnt-tag = mediacnt *("," mediacnt) 179 mediacnt = "slides" / "speaker" / "sl" / "main" 180 / "alt" / "user-floor" / "txp" 181 / mediacnt-ext 182 mediacnt-ext = token 184 The 'content' attribute contains a token, which MAY be attached to a 185 media stream by a sending application. It describes the content of 186 the transmitted media stream to the receiving application. Multiple 187 'content' attribute values MAY be attached to a single media stream. 189 This document provides a set of pre-defined values for the 'content' 190 attribute. Other values can be defined in the future. The pre- 191 defined values are: 193 slides: This is a media stream that includes presentation slides. 194 The media type can be e.g., a video stream or a set of instant 195 message with pictures. A typical use case for this is e.g., 196 online seminars and courses. This is similar to the 197 'presentation' role in H.239 [11]. 199 speaker: This is a image from the speaker. The media can be e.g., a 200 video stream or a still image. Typical use case for this is e.g, 201 online seminars and courses. 203 sl: This means that the media stream contains sign language. The 204 media type is a video stream. A typical use case for this is one 205 where the audio stream is translated into sign language. 207 main: This means that the media stream is taken from the main source. 208 A typical use case for this is a concert, where the camera is 209 shooting the performer. 211 alt: This means that the media stream is taken from the alternative 212 source. A typical use case for this is an event, where there is a 213 separate ambient sound and the main sound. The alternative audio 214 stream could be e.g., the sound of a jungle. Another example is 215 the video of the conference room while the main is the video of 216 the speaker. This is similar to the 'live' role in H.239. 218 user-floor: This indicates that a user level floor control is 219 required. In other words, human users have to take care of the 220 floor control. The user interface of the receiving application 221 must indicate the need for user level floor control to the human 222 user. 224 A typical use case is a situation where the other endpoint of the 225 connection is a walkie-talkie type of device, and human users must 226 say 'over' each time they stop transmitting. 228 txp: This indicates that the media stream is originated from a 229 textphone that is incapable of handling simultaneous two-way 230 communication. This limitation requires special behavior from the 231 user of a terminal receiving the indication. The indication 232 should be used for an indication in the user interface. 234 A typical use case is a connection where one endpoint is an analog 235 textphone of a kind that cannot handle two-way simultaneous text 236 communication, and the other one is a native IP based real time 237 text capable terminal. The human user of the IP terminal need to 238 change behaviour when this indication is received, and apply 239 formal turn-taking habits. They may also need to figure out to 240 what extent it is possible to interrupt the other party if the 241 need arises. 243 All of these values can be used with any media type. The application 244 can make decisions on how to handle a single media stream based on 245 both the media type and the value of the 'content' attribute. 246 Therefore the situation where one value of 'content' attribute occurs 247 more than once in a single session descriptor is not problematic. 249 6. The Content Attribute in the Offer/Answer Model 251 This specification does not define a means to discover whether or not 252 the peer endpoint understands the 'content' attribute because 253 'content' values are informative only at the offer/answer model [7] 254 level. The fact that the peer endpoint does not understand the 255 'content' attribute does not keep the media session from being 256 established. The only consequence is that end user interaction on 257 the receiving side may be required to direct the individual media 258 streams appropriately. 260 Since the 'content' attribute does not have to be understood, an SDP 261 answer MAY contain 'content' attributes even if none were present in 262 the offer. Similarly, the answer MAY contain no 'content' attributes 263 even if they were present in the offer. 265 The 'content' attribute can also be used in scenarios where SDP is 266 used in declarative style. For example, 'content' attributes can be 267 used in SDP session descriptors that are distributed with Session 268 Announcement Protocol (SAP) [8]. 270 7. Examples 272 There are two examples in this section. The first example, shown 273 below, uses only one 'content' attribute value per media stream: 275 v=0 276 o=Alice 292742730 29277831 IN IP4 131.163.72.4 277 s=Second lecture from information technology 278 c=IN IP4 131.164.74.2 279 t=0 0 280 m=video 52886 RTP/AVP 31 281 a=rtpmap:31 H261/9000 282 a=content:slides 283 m=video 53334 RTP/AVP 31 284 a=rtpmap:31 H261/9000 285 a=content:speaker 286 m=video 54132 RTP/AVP 31 287 a=rtpmap:31 H261/9000 288 a=content:sl 290 The second example, below, shows a case where there is more than one 291 'content' attribute value per media stream. The difference to the 292 previous example is that now the conferencing system automatically 293 mixes the video streams from the presenter and slides: 295 v=0 296 o=Alice 292742730 29277831 IN IP4 131.163.72.4 297 s=Second lecture from information technology 298 c=IN IP4 131.164.74.2 299 t=0 0 300 m=video 52886 RTP/AVP 31 301 a=rtpmap:31 H261/9000 302 a=content:slides,speaker 303 m=video 54132 RTP/AVP 31 304 a=rtpmap:31 H261/9000 305 a=content:sl 307 8. Operation with SMIL 309 The values of 'content' attribute, defined in Section 5, can also be 310 used with SMIL [10]. SMIL contains a 'param' element, which is used 311 for describing the content of a media flow. However, this 'param' 312 element provides only application specific description of media 313 content. By using the values of the 'content' attribute, this 314 'param' element can also be used to describe the media content in 315 globally interpretable way. 317 Details on how to use the values of the 'content' attribute with 318 SMIL's 'param' element are outside the scope of this specification. 320 9. Security Considerations 322 An attacker may attempt to add, modify, or remove 'content' 323 attributes from a session description. This could result in an 324 application behaving in an undesirable way. So, it is strongly 325 RECOMMENDED that integrity protection be applied to the SDP session 326 descriptions. For session descriptions carried in SIP [5], S/MIME 327 [6] is the natural choice to provide such end-to-end integrity 328 protection, as described in RFC 3261 [5]. Other applications MAY use 329 a different form of integrity protection. 331 10. IANA Considerations 333 This document defines a new 'content' attribute for SDP. It also 334 defines an initial set of values for it. Some general information 335 regarding 'content' attribute is presented in the following: 337 Contact name: Jani Hautakorpi Jani.Hautakorpi@ericsson.com. 339 Attribute name: 'content'. 341 Type of attribute Media level. 343 Subject to charset: No. 345 Purpose of attribute: The 'content' attribute gives information from 346 the content of the media stream to the receiving application. 348 Allowed attribure values: "slides", "speaker", "sl", "main", "alt", 349 "user-floor", "txp", and any other 350 registered values. 352 The IANA is requested to create a subregistry for 'content' attribute 353 values under the Session Description Protocol (SDP) Parameters 354 registry. The initial values for the subregistry are presented in 355 the following, and IANA is requested to add them into its database: 357 Value of 'content' attribute Reference Description 358 ---------------------------- --------- ----------- 359 slides RFC xxxx Presentation slides 360 speaker RFC xxxx Image from the speaker 361 sl RFC xxxx Sign language 362 main RFC xxxx Main media stream 363 alt RFC xxxx Alternative media stream 364 user-floor RFC xxxx User level floor control req. 365 txp RFC xxxx Media from a textphone 367 Note for the RFC Editor: The 'RFC xxxx' in the above should be a 368 reference to the coming RFC number of this draft. 370 As per the terminology in RFC 2434 [4], the registration policy for 371 new values for the 'content' parameter shall be 'Specification 372 Required'. 374 11. Acknowledgements 376 Authors would like to thank Arnoud van Wijk and Roni Even, who 377 provided valuable ideas for this document. We wish to thank also Tom 378 Taylor for a thorough review. 380 12. References 381 12.1 Normative References 383 [1] Handley, M., "SDP: Session Description Protocol", 384 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 386 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 387 Specifications: ABNF", RFC 2234, November 1997. 389 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 390 Levels", BCP 14, RFC 2119, March 1997. 392 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 393 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 395 12.2 Informational References 397 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 398 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 399 Session Initiation Protocol", RFC 3261, June 2002. 401 [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 402 (S/MIME) Version 3.1 Message Specification", RFC 3851, 403 July 2004. 405 [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 406 Session Description Protocol (SDP)", RFC 3264, June 2002. 408 [8] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 409 Protocol", RFC 2974, October 2000. 411 [9] Levin, O. and G. Camarillo, "The SDP (Session Description 412 Protocol) Label Attribute", 413 draft-ietf-mmusic-sdp-media-label-01 (work in progress), 414 January 2005. 416 [10] Michel, T. and J. Ayars, "Synchronized Multimedia Integration 417 Language (SMIL 2.0) - [Second Edition]", W3C REC REC-SMIL2- 418 20050107, January 2005. 420 [11] ITU-T, "Infrastructure of audiovisual services - Systems 421 aspects; Role management and additional media channels for 422 H.300-series terminals", Series H H.239, July 2003. 424 Authors' Addresses 426 Jani Hautakorpi 427 Ericsson 428 Hirsalantie 11 429 Jorvas 02420 430 Finland 432 Email: Jani.Hautakorpi@ericsson.com 434 Gonzalo Camarillo 435 Ericsson 436 Hirsalantie 11 437 Jorvas 02420 438 Finland 440 Email: Gonzalo.Camarillo@ericsson.com 442 Intellectual Property Statement 444 The IETF takes no position regarding the validity or scope of any 445 Intellectual Property Rights or other rights that might be claimed to 446 pertain to the implementation or use of the technology described in 447 this document or the extent to which any license under such rights 448 might or might not be available; nor does it represent that it has 449 made any independent effort to identify any such rights. Information 450 on the procedures with respect to rights in RFC documents can be 451 found in BCP 78 and BCP 79. 453 Copies of IPR disclosures made to the IETF Secretariat and any 454 assurances of licenses to be made available, or the result of an 455 attempt made to obtain a general license or permission for the use of 456 such proprietary rights by implementers or users of this 457 specification can be obtained from the IETF on-line IPR repository at 458 http://www.ietf.org/ipr. 460 The IETF invites any interested party to bring to its attention any 461 copyrights, patents or patent applications, or other proprietary 462 rights that may cover technology that may be required to implement 463 this standard. Please address the information to the IETF at 464 ietf-ipr@ietf.org. 466 Disclaimer of Validity 468 This document and the information contained herein are provided on an 469 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 470 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 471 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 472 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 473 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 474 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 476 Copyright Statement 478 Copyright (C) The Internet Society (2006). This document is subject 479 to the rights, licenses and restrictions contained in BCP 78, and 480 except as set forth therein, the authors retain all their rights. 482 Acknowledgment 484 Funding for the RFC Editor function is currently provided by the 485 Internet Society.