idnits 2.17.1 draft-ietf-mmusic-sdp-media-content-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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 433. ** 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 2 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 (April 11, 2006) is 6590 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: October 13, 2006 Ericsson 5 April 11, 2006 7 The SDP (Session Description Protocol) Content Attribute 8 draft-ietf-mmusic-sdp-media-content-03.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 October 13, 2006. 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. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 8. Operation with SMIL . . . . . . . . . . . . . . . . . . . . . 7 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 62 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 64 12.2. Informational References . . . . . . . . . . . . . . . . 9 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]. 198 speaker: This is a image from the speaker. The media can be e.g., a 199 video stream or a still image. Typical use case for this is e.g, 200 online seminars and courses. 201 sl: This means that the media stream contains sign language. The 202 media type is a video stream. A typical use case for this is one 203 where the audio stream is translated into sign language. 205 main: This means that the media stream is taken from the main source. 206 A typical use case for this is a concert, where the camera is 207 shooting the performer. 208 alt: This means that the media stream is taken from the alternative 209 source. A typical use case for this is an event, where there is a 210 separate ambient sound and the main sound. The alternative audio 211 stream could be e.g., the sound of a jungle. Another example is 212 the video of the conference room while the main is the video of 213 the speaker. This is similar to the 'live' role in H.239. 214 user-floor: This indicates that a user level floor control is 215 required. In other words, this is meant for system without any 216 mechanism for floor control, where a human needs to figure out 217 whether an act of floor control, e.g., saying 'over', is needed or 218 not. A typical use case for this is a situation where the other 219 endpoint of the connection is a walkie-talkie type of device. 220 txp: This indicates that the media stream is originated from a 221 textphone, and it requires special behavior from the receiving 222 application. A typical use case for this is a connection where 223 one endpoint is an analog textphone of a kind that cannot handle 224 two-way simultaneous text communication, and the other one is a 225 native IP based real time text capable terminal. The human users 226 normally need to apply formal turn-taking habits, and need to 227 figure out to what extent it is possible to interrupt the other 228 party if the need arises. 230 All of these values can be used with any media type. The application 231 can make decisions on how to handle a single media stream based on 232 both the media type and the value of the 'content' attribute. 233 Therefore the situation where one value of 'content' attribute occurs 234 more than once in a single session descriptor is not problematic. 236 6. The Content Attribute in the Offer/Answer Model 238 This specification does not define a means to discover whether or not 239 the peer endpoint understands the 'content' attribute because 240 'content' values are informative only at the offer/answer model [7] 241 level. The fact that the peer endpoint does not understand the 242 'content' attribute does not keep the media session from being 243 established. The only consequence is that end user interaction on 244 the receiving side may be required to direct the individual media 245 streams appropriately. 247 Since the 'content' attribute does not have to be understood, an SDP 248 answer MAY contain 'content' attributes even if none were present in 249 the offer. Similarly, the answer MAY contain no 'content' attributes 250 even if they were present in the offer. 252 The 'content' attribute can also be used in scenarios where SDP is 253 used in declarative style. For example, 'content' attributes can be 254 used in SDP session descriptors that are distributed with Session 255 Announcement Protocol (SAP) [8]. 257 7. Example 259 The following is an example of the SDP session description that uses 260 the 'content' attribute: 262 v=0 263 o=Alice 292742730 29277831 IN IP4 131.163.72.4 264 s=Second lecture from information technology 265 c=IN IP4 131.164.74.2 266 t=0 0 267 m=video 52886 RTP/AVP 31 268 a=rtpmap:31 H261/9000 269 a=content:slides 270 m=video 53334 RTP/AVP 31 271 a=rtpmap:31 H261/9000 272 a=content:speaker 273 m=video 54132 RTP/AVP 31 274 a=rtpmap:31 H261/9000 275 a=content:sl 277 8. Operation with SMIL 279 The values of 'content' attribute, defined in Section 5, can also be 280 used with SMIL [10]. SMIL contains a 'param' element, which is used 281 for describing the content of a media flow. However, this 'param' 282 element provides only application specific description of media 283 content. By using the values of the 'content' attribute, this 284 'param' element can also be used to describe the media content in 285 globally interpretable way. 287 Details on how to use the values of the 'content' attribute with 288 SMIL's 'param' element are outside the scope of this specification. 290 9. Security Considerations 292 An attacker may attempt to add, modify, or remove 'content' 293 attributes from a session description. This could result in an 294 application behaving in an undesirable way. So, it is strongly 295 RECOMMENDED that integrity protection be applied to the SDP session 296 descriptions. For session descriptions carried in SIP [5], S/MIME 297 [6] is the natural choice to provide such end-to-end integrity 298 protection, as described in RFC 3261 [5]. Other applications MAY use 299 a different form of integrity protection. 301 10. IANA Considerations 303 This document defines a new 'content' attribute for SDP. It also 304 defines an initial set of values for it. 306 Contact name: Jani Hautakorpi Jani.Hautakorpi@ericsson.com. 308 Attribute name: 'content'. 310 Type of attribute Media level. 312 Subject to charset: No. 314 Purpose of attribute: The 'content' attribute gives information from 315 the content of the media stream to the receiving application. 317 Allowed attribure values: "slides", "speaker", "sl", "main", "alt", 318 "user-floor", "txp", and any other 319 registered values. 321 The IANA is requested to create a subregistry for 'content' attribute 322 values under the Session Description Protocol (SDP) Parameters 323 registry. The following are the initial values for the subregistry: 325 Value of 'content' attribute Reference Description 326 ---------------------------- --------- ----------- 327 slides RFC xxxx Presentation slides 328 speaker RFC xxxx Image from the speaker 329 sl RFC xxxx Sign language 330 main RFC xxxx Main media stream 331 alt RFC xxxx Alternative media stream 332 user-floor RFC xxxx User level floor control req. 333 txp RFC xxxx Media from a textphone 335 Note for the RFC Editor: The 'RFC xxxx' in the above should be a 336 reference to the coming RFC number of this draft. 338 As per the terminology in RFC 2434 [4], the registration policy for 339 new values for the 'content' parameter shall be 'Specification 340 Required'. 342 11. Acknowledgements 344 Authors would like to thank Arnoud van Wijk and Roni Even, who 345 provided valuable ideas for this document. We wish to thank also Tom 346 Taylor for a thorough review. 348 12. References 350 12.1. Normative References 352 [1] Handley, M., "SDP: Session Description Protocol", 353 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 355 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 356 Specifications: ABNF", RFC 2234, November 1997. 358 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 359 Levels", BCP 14, RFC 2119, March 1997. 361 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 362 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 364 12.2. Informational References 366 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 367 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 368 Session Initiation Protocol", RFC 3261, June 2002. 370 [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 371 (S/MIME) Version 3.1 Message Specification", RFC 3851, 372 July 2004. 374 [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 375 Session Description Protocol (SDP)", RFC 3264, June 2002. 377 [8] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 378 Protocol", RFC 2974, October 2000. 380 [9] Levin, O. and G. Camarillo, "The SDP (Session Description 381 Protocol) Label Attribute", 382 draft-ietf-mmusic-sdp-media-label-01 (work in progress), 383 January 2005. 385 [10] Michel, T. and J. Ayars, "Synchronized Multimedia Integration 386 Language (SMIL 2.0) - [Second Edition]", W3C REC REC-SMIL2- 387 20050107, January 2005. 389 [11] ITU-T, "Infrastructure of audiovisual services - Systems 390 aspects; Role management and additional media channels for 391 H.300-series terminals", Series H H.239, July 2003. 393 Authors' Addresses 395 Jani Hautakorpi 396 Ericsson 397 Hirsalantie 11 398 Jorvas 02420 399 Finland 401 Email: Jani.Hautakorpi@ericsson.com 403 Gonzalo Camarillo 404 Ericsson 405 Hirsalantie 11 406 Jorvas 02420 407 Finland 409 Email: Gonzalo.Camarillo@ericsson.com 411 Intellectual Property Statement 413 The IETF takes no position regarding the validity or scope of any 414 Intellectual Property Rights or other rights that might be claimed to 415 pertain to the implementation or use of the technology described in 416 this document or the extent to which any license under such rights 417 might or might not be available; nor does it represent that it has 418 made any independent effort to identify any such rights. Information 419 on the procedures with respect to rights in RFC documents can be 420 found in BCP 78 and BCP 79. 422 Copies of IPR disclosures made to the IETF Secretariat and any 423 assurances of licenses to be made available, or the result of an 424 attempt made to obtain a general license or permission for the use of 425 such proprietary rights by implementers or users of this 426 specification can be obtained from the IETF on-line IPR repository at 427 http://www.ietf.org/ipr. 429 The IETF invites any interested party to bring to its attention any 430 copyrights, patents or patent applications, or other proprietary 431 rights that may cover technology that may be required to implement 432 this standard. Please address the information to the IETF at 433 ietf-ipr@ietf.org. 435 Disclaimer of Validity 437 This document and the information contained herein are provided on an 438 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 439 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 440 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 441 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 442 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 443 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 445 Copyright Statement 447 Copyright (C) The Internet Society (2006). This document is subject 448 to the rights, licenses and restrictions contained in BCP 78, and 449 except as set forth therein, the authors retain all their rights. 451 Acknowledgment 453 Funding for the RFC Editor function is currently provided by the 454 Internet Society.