idnits 2.17.1 draft-jennings-mmusic-adjacent-grouping-04.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 (July 11, 2011) is 4672 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) == Missing Reference: '----------' is mentioned on line 215, but not defined == Missing Reference: '------------' is mentioned on line 215, but not defined == Missing Reference: 'RFC-AAAA' is mentioned on line 344, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft A. Begen 4 Intended status: Standards Track Cisco 5 Expires: January 12, 2012 July 11, 2011 7 Grouping of Adjacent Media in the Session Description Protocol 8 draft-jennings-mmusic-adjacent-grouping-04 10 Abstract 12 Applications such as multi-screen video conferencing systems or 13 advertisement boards often have multiple audio and video streams that 14 are organized to be rendered side by side or in a grid. This 15 specification uses the RFC 5888 Grouping Framework to define new 16 semantics for grouping the media streams to be rendered side by side 17 or in a grid and indicating their relative ordering. 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 http://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 January 12, 2012. 36 Copyright Notice 38 Copyright (c) 2011 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Adjacent Media Grouping . . . . . . . . . . . . . . . . . . . 3 56 3.1. "ADJ" Grouping Semantics . . . . . . . . . . . . . . . . . 3 57 3.2. Grouping for SSRC-Multiplexed RTP Streams . . . . . . . . 4 58 3.3. SDP Offer/Answer Model Considerations . . . . . . . . . . 5 59 4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Horizontal Layout . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Grid Layout . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.3. Layout with SSRC multiplex . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 6.1. Registration of SDP Attributes . . . . . . . . . . . . . . 8 66 6.2. Registration of Grouping Semantics . . . . . . . . . . . . 8 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 There are many situations where applications create media streams 76 that are meant do be rendered adjacent to each other. A common 77 example is a multi-screen video conferencing system. Other examples 78 are several video monitors placed side by side to display signs, and 79 audio streams from a linear array of microphones, or a grid of 80 display for monitoring security cameras. The Session Description 81 Protocol (SDP) [RFC4566] allows negotiation of multiple media streams 82 but does not have a way to describe the ordering information to 83 indicate which media stream is adjacent to which one. 85 This specification introduces new grouping semantics, using the SDP 86 Grouping Framework defined in [RFC5888], that indicate media streams 87 are adjacent, and the adjacency order is defined by the order of the 88 entries in the group. 90 2. Terminology 92 This specification uses all the terms defined in [RFC5888] and will 93 not make sense unless you have read [RFC5888]. The key words "MUST", 94 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 95 "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Adjacent Media Grouping 100 3.1. "ADJ" Grouping Semantics 102 This specification defines new grouping semantics of "ADJ" that 103 indicate the media streams in this group are meant to be played or 104 displayed adjacently. Furthermore, the order of media streams in the 105 group indicates the adjacency order. This only indicates the order 106 the device sending the SDP believes is the preferred way to display 107 the media described in this SDP. 109 N media streams could be in a linear horizontal layout, in which case 110 we use a grid size of 1 x N. Alternatively, N media streams could be 111 in a linear vertical layout, in which case we use a grid size of N x 112 1. In these configurations, the first stream in the group MUST be 113 the one corresponding to the left most and top most output unit, 114 respectively. In a more general grid size of N x M, we can group K 115 (where K <= N x M) media streams starting from the one corresponding 116 to the top-left output unit, and then doing a continuous horizontal 117 scanning of the grid row by row (i.e., scanning first the top row 118 from left to right, and then the second row from left to right, and 119 so on). When we say left most, we mean from the point of view of the 120 person looking at the display. 122 To indicate the dimensions of the layout grid in an SDP description, 123 we define a new session-level attribute. The ABNF syntax [RFC5234] 124 for the new attribute is as follows: 126 media-grid-dims-line = "a=media-grid-dims:" [gridname] 127 %20 rows "x" columns CRLF 129 gridname = token ; token is defined in RFC 4566 130 rows = %x31-39 *DIGIT 131 columns = %x31-39 *DIGIT 133 namechar = token // as defined in 135 The parameters 'rows' and 'columns' indicate the number of rows and 136 columns for this media grid. They both MUST be an integer larger 137 than zero. The gridname indicates a name for this grid. If there 138 are multiple media-grid-dims attribute in the SDP, each MUST have a 139 unique gridname. 141 If the 'media-grid-dims' attribute does not exist in the SDP 142 description, then a 1 x N horizontal linear layout MUST be assumed. 144 Per [RFC5888], there MAY be more than one adjacent media group in a 145 single SDP description. The 'media-grid-dims' attribute MUST come 146 before the group or sssrc-group that it applies to. An group or 147 SSRC-group for an ADJ group MUST use the first 'media-grid-dims' 148 attribute found above it in the SDP. 150 3.2. Grouping for SSRC-Multiplexed RTP Streams 152 [RFC5576] defines an SDP media-level attribute, called 'ssrc-group', 153 for grouping the RTP streams that are SSRC multiplexed and carried in 154 the same RTP session. The grouping is based on the SSRC identifiers. 155 Since SSRC-multiplexed RTP streams are defined in the same "m" line, 156 the 'group' attribute cannot be used. 158 This section specifies how adjacency is described with SSRC- 159 multiplexed streams using the 'ssrc-group' attribute [RFC5576]. 161 The semantics of "ADJ" for the 'ssrc-group' attribute are the same as 162 the one defined for the 'group' attribute except that the SSRC 163 identifiers are used to designate the adjacency grouping 164 associations: a=ssrc-group:ADJ *(SP ssrc-id) [RFC5576]. 166 The SSRC identifiers for the RTP streams that are carried in the same 167 RTP session MUST be unique per [RFC3550]. However, the SSRC 168 identifiers are not guaranteed to be unique among different RTP 169 sessions. Thus, the 'ssrc-group' attribute MUST only be used at the 170 media level [RFC5576]. 172 3.3. SDP Offer/Answer Model Considerations 174 When offering adjacent media grouping using SDP in an Offer/Answer 175 model [RFC3264], the following considerations apply. 177 A node that is receiving an offer from a sender may or may not 178 understand line grouping. It is also possible that the node 179 understands line grouping but it does not understand the "ADJ" 180 semantics. From the viewpoint of the sender of the offer, these 181 cases are indistinguishable. 183 When a node is offered a session with the "ADJ" grouping semantics 184 but it does not support line grouping or the adjacent media grouping 185 semantics, as per [RFC5888], the node responds to the offer either 186 (1) with an answer that ignores the grouping attribute or (2) with a 187 refusal to the request (e.g., 488 Not Acceptable Here or 606 Not 188 Acceptable in SIP). 190 In the first case, the original sender of the offer must send a new 191 offer without any grouping. In the second case, if the sender of the 192 offer still wishes to establish the session, it should retry the 193 request with an offer without the adjacent media grouping. This 194 behavior is specified in [RFC5888]. 196 The offer contains the sender's suggested layout. The answer MAY 197 contain the suggested layout of the streams that the system sending 198 the answer will be sending to the system that sent the offer. 200 4. SDP Examples 202 This section provides SDP examples showing how to use the adjacent 203 media grouping. 205 4.1. Horizontal Layout 207 A video system with two screens and one audio channels sends a SIP 208 offer. The following figure shows a top-down view of the room with 209 the three screen system that is sending the SIP offer. Screen A is 210 the left most screen for the user in this room but should be 211 displayed as the rightmost screen for the user at the far end that 212 will be viewing the video. 214 Screen A Screen B 215 [----------][------------] 217 User 219 Assume the SDP mid values for the screens are sa and sb, for Screens 220 A and B respectively. The offer contains the following in the SDP: 221 a=group:ADJ sb sa 223 The complete SDP in the offer could look like: 225 v=0 226 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 227 s= 228 c=IN IP4 host.atlanta.example.com 229 a=group:ADJ sb sa 230 t=0 0 231 m=audio 49101 RTP/AVP 101 232 a=rtpmap:101 PCMU/8000 233 a=mid:sm 234 m=video 49111 RTP/AVP 111 235 a=rtpmap:111 H261/90000 236 a=mid:sa 237 m=video 49112 RTP/AVP 112 238 a=rtpmap:112 H261/90000 239 a=mid:sb 241 There might be other media streams, such as presentation video, that 242 are not part of any "ADJ" group. 244 As a note to implementors, consider the case where each screen had 245 two media flows that were in the same FID group. In this case all 246 the media streams are still listed in the ADJ group and the order of 247 two streams in the same FID group can be arbitrarily picked as they 248 will be displayed on the same device. 250 4.2. Grid Layout 252 The following SDP is for a system providing 6 video streams. Four of 253 these streams are arranged as a wall of screens on a 2 by 2 grid 254 while the other 2 streams should be shown separate but still arranged 255 side by side. 257 v=0 258 o=bob 2890844526 2890844526 IN IP4 host.atlanta.example.com 259 s= 260 c=IN IP4 host.atlanta.example.com 261 a=media-grid-dims:A 2x2 262 a=group:ADJ 1 2 3 4 263 a=media-grid-dims:B 2x1 264 a=group:ADJ 5 6 265 t=0 0 266 m=video 49101 RTP/AVP 101 267 a=rtpmap:101 H261/90000 268 a=mid:1 269 m=video 49102 RTP/AVP 102 270 a=rtpmap:102 H261/90000 271 a=mid:2 272 m=video 49103 RTP/AVP 103 273 a=rtpmap:103 H261/90000 274 a=mid:3 275 m=video 49104 RTP/AVP 104 276 a=rtpmap:104 H261/90000 277 a=mid:4 278 m=video 49105 RTP/AVP 105 279 a=rtpmap:105 H261/90000 280 a=mid:5 281 m=video 49106 RTP/AVP 106 282 a=rtpmap:106 H261/90000 283 a=mid:6 285 4.3. Layout with SSRC multiplex 287 The following SDP is for a system providing 2 video streams using 288 SSRC multiplexing. In this example, the SSRC for one stream is 12345 289 while for the other it is 67890. 291 v=0 292 o=bob 2890844526 2890844526 IN IP4 host.atlanta.example.com 293 s= 294 c=IN IP4 host.atlanta.example.com 295 a=ssrc-group:ADJ 12345 67890 296 t=0 0 297 m=video 49170 RTP/AVP 96 298 a=rtpmap:96 H264/90000 300 5. Security Considerations 302 Like all SDP, integrity of this information is important. When 303 carrying SDP in SIP, mechanisms such as Transport Layer Security 304 (TLS) can provide hop by hop confidentiality and integrity. The 305 receiver SHOULD do an integrity check on SDP and follow the security 306 considerations of SDP [RFC4566] to trust only SDP from trusted 307 sources. End-to-end integrity can be provided by [RFC4474]. 309 6. IANA Considerations 311 Note to RFC Editor: Please replace [RFC-AAAA] with the RFC number 312 for this specification. 314 6.1. Registration of SDP Attributes 316 This document registers a new attribute name in SDP. 318 SDP Attribute ("att-field"): 319 Attribute name: media-grid-dims 320 Long form: 2-D media grid dimensions 321 Type of name: att-field 322 Type of attribute: Session level 323 Subject to charset: No 324 Purpose: Specifies the dimensions for a media grid 325 Reference: [RFC-AAAA] 326 Values: See [RFC-AAAA] 328 6.2. Registration of Grouping Semantics 330 This document, following the Standards Action policy from [RFC5226], 331 registers the following semantics with IANA in the "Semantics for the 332 "group" SDP Attribute" registry under SDP Parameters: 334 Semantics Token Reference 335 --------------------------------- ----- ----------- 336 Adjacent Media ADJ [RFC-AAAA] 338 This document also registers the following semantics with IANA in 339 "Semantics for the 'ssrc-group' SDP Attribute" registry under SDP 340 Parameters: 342 Token Semantics Reference 343 ------- ----------------------------- --------- 344 ADJ Adjacent Media [RFC-AAAA] 346 7. Acknowledgments 348 The authors would like to thank Flemming Andreasen, Allyn Romanow, 349 Roni Even, Hakon Dahle, Ingemar Johansson, Paul Kyzivat, Peter 350 Musgrave, Christer Holmberg, Magnus Westerlund, Stephen Botzko, and 351 Geir Arne Sandbakken for their review comments. 353 8. References 355 8.1. Normative References 357 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 358 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 360 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 361 Description Protocol", RFC 4566, July 2006. 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, March 1997. 366 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 367 Specifications: ABNF", STD 68, RFC 5234, January 2008. 369 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 370 Media Attributes in the Session Description Protocol 371 (SDP)", RFC 5576, June 2009. 373 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 374 with Session Description Protocol (SDP)", RFC 3264, 375 June 2002. 377 8.2. Informative References 379 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 380 Authenticated Identity Management in the Session 381 Initiation Protocol (SIP)", RFC 4474, August 2006. 383 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 384 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 385 May 2008. 387 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 388 Jacobson, "RTP: A Transport Protocol for Real-Time 389 Applications", STD 64, RFC 3550, July 2003. 391 Authors' Addresses 393 Cullen Jennings 394 Cisco 395 170 West Tasman Drive 396 San Jose, CA 95134 397 USA 399 Phone: +1 408 421-9990 400 Email: fluffy@cisco.com 402 Ali Begen 403 Cisco 404 181 Bay Street 405 Toronto, ON M5J 2T3 406 Canada 408 Email: abegen@cisco.com