One document matched: draft-jennings-mmusic-adjacent-grouping-00.txt
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 <get
your name here> 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]
| PAFTECH AB 2003-2026 | 2026-04-22 23:31:24 |