idnits 2.17.1 draft-abhishek-mmusic-superimposition-grouping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 11, 2020) is 1230 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 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 mmusic R. Abhishek 2 Internet-Draft S. Wenger 3 Intended status: Standards Track Tencent 4 Expires: June 14, 2021 December 11, 2020 6 SDP Superimposition Grouping framework 7 draft-abhishek-mmusic-superimposition-grouping-00 9 Abstract 11 This document defines semantics that allow for signaling a new SDP 12 group "S" for superimposed media in an SDP session. The "S" 13 attribute can be used by the application to relate all the 14 superimposed media streams enabling them to be added as an overlay on 15 top of any media stream. The superimposition grouping semantics is 16 required, if the media data is separate and transported via different 17 sessions. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 14, 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Superimposition Group Identification Attribute . . . . . . . 4 56 4. Use of group and mid . . . . . . . . . . . . . . . . . . . . 4 57 5. "transparency" Attribute for Superimposition Group 58 Identification Attribute . . . . . . . . . . . . . . . . . . 5 59 6. Example of S . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7. Relationship with CLUE (informative) . . . . . . . . . . . . 6 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 10.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 Media superimposition can be defined to be a visual media 71 (video/image/text) which is superimposed on top of an already 72 existing visual media such that the resulting foreground and 73 background media can be displayed simultaneously. Superimposition 74 can be recursive in that a visual media that is superimposed against 75 its background can, in turn, be the background of a another 76 superimposed visual media. The superimposed visual media displayed 77 over a background media content may vary in transparency. Examples 78 of video superimposition include real-time multi-party gaming, where 79 these superimposed media maybe used to provide additional details or 80 stats about each player, or multi-party teleconferencing where visual 81 media from users in the teleconference may be superimposed on a 82 background media or over each other. An example is shown in figure 83 below, where three foreground media has been superimposed over a 84 background media with one foreground media being partly superimposed 85 over another foreground media. 87 ---------------------------- 88 | Background media | 89 | _________ | 90 | | Media A | | 91 | |_________| | 92 | __________ | 93 | ______|__ Media B| | 94 | |Media |__|_______| | 95 | |_C_______| | 96 ---------------------------- 98 Figure 1: A example of media superimpostion 100 SDP is being predominantly used for describing the format for 101 multimedia communication sessions. Many SDP-based systems use open 102 standards such as RTP [RFC3550] for media transport and and SIP 103 [RFC3261] for session setup and control. An SDP session may contain 104 more than one media description with each media description 105 identified by "m"=line. Each line denotes a single media stream. If 106 multiple visual media lines are present in a session, at present, 107 their spatial relationship at the rendering device is undefined. 108 This memo introduces a mechanism in which certain rendering 109 information becomes available. The rendering information herein is 110 limited to the foreground/background relationship of each grouped 111 media vis-a-vis each other, and optionally a transparency value. 112 Where, spatially, the media is rendered is not covered by this memo 113 and is in many application scenarios a function of the user 114 interface. However, the superimposition grouping as described below 115 enables a compliant receiver/renderer implementation to know the 116 relative relevance of the visual media as coded by the sender(s) and, 117 in a compliant implementation, observed by the renderer through 118 superimposition. 120 When multiple superimposed streams are transmitted within a session, 121 the receiver needs to be able to relate the media streams to each 122 other. This is achieved by the SDP grouping framework [RFC5888] by 123 using the "group" attribute that groups different "m" lines in a 124 session. By using a new superimpose group semantic defined in this 125 memo, a group's media streams can be uniquely identified across 126 multiple SDP descriptions exchanged with different receivers, thereby 127 identifying the streams in terms of their role in the session 128 irrespective of its media type and transport protocol. These 129 superimposed streams within the group may be multiplexed based on the 130 guidelines defined in [draft-ietf-avtcore-multiplex-guidelines-12]. 132 This document describes a new SDP group semantics for grouping the 133 superimposition in an SDP session. An SDP session description 134 consists of one or multiple media lines know as "m" lines which can 135 be identified by a token carried in a "mid" attribute. The SDP 136 session describes a session-level group level attribute that groups 137 different media lines using a defined group semantics. The semantics 138 defined in this memo is to be used in conjunction with "The Session 139 Description Protocol (SDP) Grouping Framework"[RFC5888]. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 3. Superimposition Group Identification Attribute 149 The "superimposition media stream identification" attribute is used 150 to identify the relationship of superimposed media streams within a 151 session description. In a superimposition group, the media lines MAY 152 have different media formats. Its formatting in SDP [RFC4566] is 153 described by the following Augmented Backus-Naur Form (ABNF) 154 [RFC5234]: 156 mid-attribute = "a=mid:" identification-tag 157 identification-tag = token 158 ; token is defined in RFC4566 160 This documents defines a new group semantics "S" identification media 161 attribute, which is used to identify super group media streams within 162 a session description. It is used for grouping the foreground media 163 streams to be superimposed on top of a background media stream 164 together within a session. An application that receives a session 165 description that contains "m" lines grouped together using "S" 166 semantics MUST superimpose the corresponding media streams on top of 167 the background media stream. The ordering of the "m" lines is 168 significant: assuming the "m" lines to be counted from 0 to n, for 169 each k within 0..n, a reconstructed sample of the k-th media is 170 superimposed (while perhaps applying an alpha transparency value) on 171 the 0 to k-th reconstructed samples in the same spatial position. 173 4. Use of group and mid 175 All group and mid attributes MUST follow the rules defined in 176 [RFC5888]. The "mid" attribute MUST be used for all "m" lines 177 covering visual media within a session description for which a 178 foreground/background relationship is to be defined. The foreground/ 179 background relationship of visual media within a session description 180 that is not covered in a group is undefined. No more than one group 181 MUST be used within one session. If the identification-tags 182 associated with "a=group" lines do not map to any "m" lines, it MUST 183 be ignored. 185 group-attribute ="a=group:" semantics 186 *(SP identification-tag) 187 semantics = "S" / semantics-extension 188 semantics-extension = token 189 ; token is defined in RFC4566 191 5. "transparency" Attribute for Superimposition Group Identification 192 Attribute 194 This memo defines a new media-level attribute, "transparency", with 195 the following ABNF [RFC5234]. The identification-tag is defined in 196 [RFC5888]. 198 transparency-attribute = 199 "a=transparency:" transparency-tag 200 transparency-tag =tranparency-value *("," tranparency-value) CRLF 201 transparency-value= alpha 203 Alpha describes the transparency for the foreground media stream. It 204 is identified by its transparency-tag values in the transparency- 205 attribute. It could be an integer with values between 0 and 100. 206 This is an informative value. Details of interpretion to be left 207 open to the renderer, expect that a value of 0 means foreground media 208 is opaque and value of 100 means that it is transparent. 210 6. Example of S 212 The following example shows a session description for superimposed 213 media stream in an SDP session. The "group" line indicates that the 214 "m" lines with tokens 1 and 2 are grouped for the purpose of 215 superimpositon and intended to be overlaid on top of a background 216 video. 218 In the example shown below, two superimposed media streams are being 219 transmitted. Both media types are video with transparency attribute 220 ("transparency"). The current focus of the draft is defining a group 221 semantics for superimposed media stream. The relationship between 222 the background and foreground media stream maybe defined in the 223 future version of the draft. 225 v=0 226 o=Alice 292742730 29277831 IN IP4 233.252.0.74 227 c=IN IP4 233.252.0.79 228 t=0 0 229 a=group:S 1 2 230 m=video 30000 RTP/AVP 31 231 a=mid:1 232 a= transparency: 17 233 m=video 30002 RTP/AVP 31 234 a=mid:2 235 a= transparency: 35 237 7. Relationship with CLUE (informative) 239 Edt. Note: maybe we remove this section later once there is a general 240 understanding why CLUE in its current form is unsuitable. The CLUE 241 framework [I-D.ietf-clue-framework] and its associated suite of I-Ds 242 and RFCs describe a telepresence framework that, at the first glance 243 seems to have a lot in common with the technology proposed herein. 244 CLUE defines captures (camera ports), and their geo-spatial 245 relationship to each other. A render can use this information to put 246 the reconstructed samples of the streams from the various captures 247 into a suitable arrangement such that visually pleasant rendering can 248 be achieved. However, CLUE does not describe the relative relevance 249 of the captures. For that reason, CLUE would need to be extended in 250 a spirit very similar to the one described in this memo to achieve 251 the desired functionality. CLUE has not seen wide deployment outside 252 its intended key application (large room, multiple camera 253 telepresence systems). It's not reasonable to assume that small 254 systems would willingly implement the overhead the (comparatively 255 complex) CLUE protocols require when a simple SDP extension can serve 256 the same purpose. 258 8. Security Considerations 260 All security considerations as defined in [RFC5888] apply: 262 Using the "group" parameter with FID semantics, an entity that 263 managed to modify the session descriptions exchanged between the 264 participants to establish a multimedia session could force the 265 participants to send a copy of the media to any destination of its 266 choosing. 268 Integrity mechanisms provided by protocols used to exchange session 269 descriptions and media encryption can be used to prevent this attack. 270 In SIP, Secure/Multipurpose Internet Mail Extensions (S/MIME) 271 [RFC8550] and Transport Layer Security (TLS) [RFC8446] can be used to 272 protect session description exchanges in an end-to-end and a hop- 273 byhop fashion, respectively. 275 9. IANA Considerations 277 The following contact information shall be used for all registrations 278 included here: 280 Contact: Rohit Abhishek 281 email: rabhishek@rabhishek.com 282 tel : +1-816-585-7500 284 This document defines a new SDP group semantics for media 285 superimposition for a SDP session. This attribute can be used by the 286 application to group all the foreground media to be superimposed on a 287 background media in a session. Semantics values to be used with this 288 framework should be registered by the IANA following the Standards 289 Action policy [RFC8126]. This document adds a new group semantics 290 and follows the registry group defined in [RFC5888]. 292 The following semantics needs to be registered by IANA in Semantics 293 for the "group" SDP Attribute under SDP Parameters. 295 Semantics Token Reference 296 ---------------------------------------------- 297 Superimposition S RFCXXXX 299 The "S" attribute is used to group different foreground media streams 300 to be superimposed on a background media stream . Its format is 301 defined in Section 3. 303 The SDP media-level attribute "transparency" needs to be registered 304 by IANA Semantics for "att-field (media-level only)". The 305 registration procedure in [RFC4566] applies. 307 SDP Attribute ("att-field (media level only)"): 309 Attribute name: transparency 310 Long form: superimposition transparency 311 Type of name: att-field 312 Type of attribute: media level only 313 Subject to charset: no 314 Purpose: RFC 5583 315 Reference: RFC 5583 316 Values: alpha 318 The IANA Considerations section of the RFC MUST include the following 319 information, which appears in the IANA registry along with the RFC 320 number of the publication. 322 o A brief description of the semantics. 324 o Token to be used within the "group" attribute. This token may be 325 of any length, but SHOULD be no more than four characters long. 327 o Reference to a standards track RFC. 329 10. References 331 10.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, 335 DOI 10.17487/RFC2119, March 1997, 336 . 338 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 339 A., Peterson, J., Sparks, R., Handley, M., and E. 340 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 341 DOI 10.17487/RFC3261, June 2002, 342 . 344 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 345 Jacobson, "RTP: A Transport Protocol for Real-Time 346 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 347 July 2003, . 349 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 350 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 351 July 2006, . 353 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 354 Specifications: ABNF", STD 68, RFC 5234, 355 DOI 10.17487/RFC5234, January 2008, 356 . 358 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 359 Protocol (SDP) Grouping Framework", RFC 5888, 360 DOI 10.17487/RFC5888, June 2010, 361 . 363 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 364 Writing an IANA Considerations Section in RFCs", BCP 26, 365 RFC 8126, DOI 10.17487/RFC8126, June 2017, 366 . 368 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 369 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 370 . 372 [RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 373 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 374 Certificate Handling", RFC 8550, DOI 10.17487/RFC8550, 375 April 2019, . 377 10.2. Informative References 379 [draft-ietf-avtcore-multiplex-guidelines-12] 380 Westerlund, M., Burman, B., Perkins, C., Alvestrand, H., 381 and R. Even, "Guidelines for using the Multiplexing 382 Features of RTP to Support Multiple Media Streams", draft- 383 ietf-avtcore-multiplex-guidelines-12 (work in progress), 384 June 2020. 386 [I-D.ietf-clue-framework] 387 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 388 for Telepresence Multi-Streams", draft-ietf-clue- 389 framework-25 (work in progress), January 2016. 391 Authors' Addresses 393 Rohit Abhishek 394 Tencent 395 2747 Park Blvd 396 Palo Alto 94588 397 USA 399 Email: rabhishek@rabhishek.com 401 Stephan Wenger 402 Tencent 403 2747 Park Blvd 404 Palo Alto 94588 405 USA 407 Email: stewe@stewe.org