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 described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Terminology
3.  Semantics
    3.1.  Use in Offer/Answer systems
4.  Examples
5.  IANA Considerations
6.  Security Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Author's Address

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] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) 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] (Camarillo, G. and H. Schulzrinne, “The Session Description Protocol (SDP) Grouping Framework,” June 2010.) 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] (Camarillo, G. and H. Schulzrinne, “The Session Description Protocol (SDP) Grouping Framework,” June 2010.) 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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 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] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.), adds the following entry to the "Semantics for the group SDP Attribute" registry defined by [RFC5888] (Camarillo, G. and H. Schulzrinne, “The Session Description Protocol (SDP) Grouping Framework,” June 2010.). [Note to RFC Editor: Please replace RFC-AAAA with the RFC number for this specification.]

Semantics                         Token Reference
--------------------------------- ----- -----------
Adjacent Media                    ADJ   RFC-AAAA

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] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.).

Further discussion of security proprieties can be found in [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.).

7.  Acknowledgements

I would like to thank Flemming Andreasen, Allyn Romanow, and <get your name here> for their review comments.

8.  References

8.1. Normative References

8.2. Informative References

Author's Address