Network Working Group C. Jennings Internet-Draft Cisco Intended status: Standards Track September 21, 2010 Expires: March 25, 2011 Grouping of Adjacent Media in SDP draft-jennings-mmusic-adjacent-grouping-00 Abstract Applications, such as multiple screen teleconference systems, often have multiple video streams that are organized to be displayed side by side. This specification defines uses the RFC 5888 grouping semantics to define a new group type that indicates that multiple audio or video streams may be rendered side by side and also indicates the relative ordering of streams. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 25, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Jennings Expires March 25, 2011 [Page 1] Internet-Draft SDP Adjacent Grouping September 2010 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Use in Offer/Answer systems . . . . . . . . . . . . . . . . 3 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Jennings Expires March 25, 2011 [Page 2] Internet-Draft SDP Adjacent Grouping September 2010 1. Introduction There are many situations where applications create media streams that are meant do be displayed adjacent to each other. A common example is a multi screen teleconference system. Another examples are several video monitors placed side by side to display signs, and audio streams from a linear array of microphones. SDP [RFC4566] allows negotiation of multiple media streams but does not have a way to carry the ordering information to indicate which media stream are adjacent to each other. This specification defines a new group, using the SDP grouping framework defined in [RFC5888] that indicates media streams are adjacent, and the adjacency order is defined by the order of the entires in the group. 2. Terminology This specification uses all the terms defined in [RFC5888] and will not make sense unless you have read RFC 5888. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this specification are to be interpreted as described in [RFC2119]. 3. Semantics This specification defines a new SDP group attribute of "ADJ" that indicates the media stream in this group are meant to be displayed adjacently. Furthermore, the order of media streams in the group indicates the display order. The first stream in the group MUST be the left most media stream then working to the right or clockwise from point of view of person viewing the media. 3.1. Use in Offer/Answer systems The offer MUST contains the senders desired layout. If the system sending the Answer supports this specification, then the Answer SHOULD indicate the actual layout selected. 4. Examples A telepresence system with three screen and six audio channels, sends an SIP Offer to a two video conferencing system that with two screens that support stereo audio. The following figure shows a top down view of the room with the telepresence system that is sending the Offer. Screen A is the left most screen for the user in this room Jennings Expires March 25, 2011 [Page 3] Internet-Draft SDP Adjacent Grouping September 2010 but should be displayed as the rightmost screen for user at the far end. The M1 to M6 indicate the placement of the audio microphones for the six streams of audio. Screen A Screen B Screen C [----------][------------][------------] M1 M2 M3 M4 M5 M6 User Assume the SDP mid values for the screens are sa, sb, and sc, for screens a to c respectively and the audio streams have mid values m1 to m6. The offer would contain the following in the SDP: a=group:ADJ sc sb sa a=group:ADJ m6 m5 m4 m3 m2 m1 There might be other media streams, such as presentation video, that are not part of any adjacency group. If the far end decided to only accept the video from screen A and scene B and takes the audio from M1 and m6. The answer would contain the following in the SDP: a=group:ADJ sb sa a=group:ADJ m6 m1 As a note to implementors, consider the case where each screen had two media flows that were in the same FID group. In this case all the media streams are still listed in the ADJ group and the order of two streams in the same FID group can be arbitrarily picked as they will be displayed on the same device. 5. IANA Considerations This specification, following the Standards Action policy from [RFC5226], adds the following entry to the "Semantics for the group SDP Attribute" registry defined by [RFC5888]. [Note to RFC Editor: Please replace RFC-AAAA with the RFC number for this specification.] Semantics Token Reference --------------------------------- ----- ----------- Adjacent Media ADJ RFC-AAAA Jennings Expires March 25, 2011 [Page 4] Internet-Draft SDP Adjacent Grouping September 2010 6. Security Considerations Like all SDP, integrity of this information is important. When caring SDP in SIP, mechanisms such as TLS can provide hop by confidentiality and integrity. End to end integrity can be provided by [RFC4474]. Further discussion of security proprieties can be found in [RFC4566]. 7. Acknowledgements I would like to thank Flemming Andreasen, Allyn Romanow, and for their review comments. 8. References 8.1. Normative References [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Jennings Expires March 25, 2011 [Page 5] Internet-Draft SDP Adjacent Grouping September 2010 Author's Address Cullen Jennings Cisco 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 421-9990 Email: fluffy@cisco.com Jennings Expires March 25, 2011 [Page 6]