One document matched: draft-jennings-mmusic-adjacent-grouping-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-jennings-mmusic-adjacent-grouping-02"
ipr="trust200902">
<front>
<title abbrev="Adjacent Media Grouping in SDP">Grouping of Adjacent Media
in the Session Description Protocol</title>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Ali Begen" initials="A." surname="Begen">
<organization>Cisco</organization>
<address>
<postal>
<street>181 Bay Street</street>
<city>Toronto</city>
<region>ON</region>
<code>M5J 2T3</code>
<country>Canada</country>
</postal>
<email>abegen@cisco.com</email>
</address>
</author>
<date day="24" month="October" year="2010" />
<area>RAI</area>
<abstract>
<t>Applications such as multi-screen video conferencing systems or
advertisement boards often have multiple audio and video streams that
are organized to be rendered side by side or in a grid. This
specification uses the RFC 5888 grouping framework to define new
semantics for grouping the media streams to be rendered side by side or
in a grid and indicating their relative ordering.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>There are many situations where applications create media streams
that are meant do be rendered adjacent to each other. A common example
is a multi-screen video conferencing system. Other examples are several
video monitors placed side by side to display signs, and audio streams
from a linear array of microphones, or a grid of display for monitoring
security cameras. The Session Description Protocol (SDP) <xref
target="RFC4566"></xref> allows negotiation of multiple media streams
but does not have a way to carry the ordering information to indicate
which media stream is adjacent to which one.</t>
<t>This specification introduces new grouping semantics, using the SDP
grouping framework defined in <xref target="RFC5888"></xref>, that
indicate media streams are adjacent, and the adjacency order is defined
by the order of the entries in the group.</t>
</section>
<section title="Terminology">
<t>This specification uses all the terms defined in <xref
target="RFC5888"></xref> and will not make sense unless you have read
<xref target="RFC5888"></xref>. The key words "MUST", "MUST NOT",
"SHOULD", "SHOULD NOT", and "MAY" in this specification are to be
interpreted as described in <xref target="RFC2119"></xref>.</t>
</section>
<section title="Adjacent Media Grouping">
<section title=""ADJ" Grouping Semantics">
<t>This specification defines new grouping semantics of "ADJ" that
indicate the media streams in this group are meant to be played or
displayed adjacently. Furthermore, the order of media streams in the
group indicates the adjacency order. This only indicates the order the
device sending the SDP believes is the preferred way to display the
media described in this SDP. This is a declarative SDP parameter and
is not negotiated.</t>
<t>N media streams could be in a linear horizontal layout, in which
case we use a grid size of 1 x N. Alternatively, N media streams could
be in a linear vertical layout, in which case we use a grid size of N
x 1. In these configurations, the first stream in the group MUST be
the one corresponding to the left most and top most output unit,
respectively. In a more general grid size of N x M, we can group K
(where K <= N x M) media streams starting from the one
corresponding to the top-left output unit, and then doing a continuous
horizontal scanning of the grid row by row (i.e., scanning first the
top row from left to right, and then the second row from left to
right, and so on). When we say leftmost, we mean from the point of
view of the person looking at the display.</t>
<t>To indicate the dimensions of the layout grid in SDP, we define a
new session-level attribute. The syntax for the new attribute in ABNF
<xref target="RFC5234"></xref> is as follows:</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
media-grid-dims-line = "a=media-grid-dims:" row "x" column CRLF
row = %x31-39 *DIGIT
column = %x31-39 *DIGIT
]]></artwork>
</figure>
<t>The parameters "row" and "column" indicate the number of rows and
columns for this media grid. They both MUST be an integer larger than
zero.</t>
<t>If the "media-grid-dims" attribute does not exist in the SDP, then
a 1 x N horizontal linear layout MUST be assumed.</t>
<t>Open Issue: I think this should be a session-level attribute,
however what if I wanna define two grids? Maybe put an identifier
field?</t>
<t>Per <xref target="RFC5888"></xref>, there MAY be more than one
adjacent media group in a single SDP session.</t>
<t>Editor's note: Should we use "output unit" or "input unit"
here?</t>
<t>Open Issue: What if the offerer wants to send 32 streams in a grid
size of 64? Consider that he wants to send a separate video to each
white-colored unit in a chessboard-like grid (skipping the
black-colored units)? These streams are still adjacent but they have a
"space" in between them. Does he need to define empty m lines for the
black-colored units? Or should we maybe define an optional "bitmap"
parameter for the media-grid-dims attribute? E.g., bitmap=101010 will
indicate that I have 3 active streams and one empty screen between
each. Given the use cases, it seems best to go with the simplest
solution and just not support this type of variable spaced layout.</t>
</section>
<section title="Grouping for SSRC-Multiplexed RTP Streams">
<t>Editor's note: We should also define the grouping semantics for
SSRC multiplexed streams (i.e., a=ssrc-group:ADJ) as in <xref
target="RFC5576"></xref>.</t>
</section>
<section title="SDP Offer/Answer Model Considerations">
<t>When offering adjacent media grouping using SDP in an Offer/Answer
model <xref target="RFC3264"></xref>, the following considerations
apply.</t>
<t>A node that is receiving an offer from a sender may or may not
understand line grouping. It is also possible that the node
understands line grouping but it does not understand the "ADJ"
semantics. From the viewpoint of the sender of the offer, these cases
are indistinguishable.</t>
<t>When a node is offered a session with the "ADJ" grouping semantics
but it does not support line grouping or the adjacent media grouping
semantics, as per <xref target="RFC5888"></xref>, the node responds to
the offer either (1) with an answer that ignores the grouping
attribute or (2) with a refusal to the request (e.g., 488 Not
Acceptable Here or 606 Not Acceptable in SIP).</t>
<t>In the first case, the original sender of the offer must send a new
offer without any grouping. In the second case, if the sender of the
offer still wishes to establish the session, it should retry the
request with an offer without the adjacent media grouping. This
behavior is specified in <xref target="RFC5888"></xref>.</t>
<t>The SIP offer MUST contain the sender's desired layout. The answer
MAY contain the desired layout of the streams that the system sending
the answer will be sending to the system that sent the offer.</t>
<t>Editor's note: Does it have to be a SIP offer/answer? Or should we
rather just say "offer/answer"?</t>
</section>
</section>
<section title="SDP Examples">
<t>This section provides SDP examples showing how to use the adjacent
media grouping.</t>
<section title="Horizontal Layout">
<t>A video conferencing system with three screens and six audio
channels sends a SIP offer to a video conferencing system with two
screens that support stereo audio. The following figure shows a
top-down view of the room with the three screen system that is sending
the SIP offer. Screen A is the left most screen for the user in this
room but should be displayed as the rightmost screen for the user at
the far end that will be viewing the video. The M1 to M6 indicate the
placement of the audio microphones for the six streams of audio.</t>
<figure>
<artwork><![CDATA[
Screen A Screen B Screen C
[----------][------------][------------]
M1 M2 M3 M4 M5 M6
User
]]></artwork>
</figure>
<t></t>
<t>Assume the SDP mid values for the screens are sa, sb, and sc, for
Screens A through C respectively, and the audio streams have mid
values m1 through m6. The offer contains the following in the SDP:</t>
<figure>
<artwork><![CDATA[ a=group:ADJ sc sb sa
a=group:ADJ m6 m5 m4 m3 m2 m1
]]></artwork>
</figure>
<t></t>
<t>There might be other media streams, such as presentation video,
that are not part of any "ADJ" group.</t>
<t>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.</t>
<t>TBD - Put in full SDP for examples.</t>
</section>
<section title="Grid Layout">
<t>A system if providing 15 video streams to a wall of screens. The
wall has 3 columns and 2 rows of screens.</t>
<t>TBD</t>
</section>
</section>
<section title="Security Considerations">
<t>Like all SDP, integrity of this information is important. When
carrying SDP in SIP, mechanisms such as Transport Layer Security (TLS)
can provide hop by hop confidentiality and integrity. The receiver
SHOULD do an integrity check on SDP and follow the security
considerations of SDP <xref target="RFC4566"></xref> to trust only SDP
from trusted sources. End-to-end integrity can be provided by <xref
target="RFC4474"></xref>.</t>
</section>
<section title="IANA Considerations">
<t>Note to RFC Editor: Please replace [RFC-AAAA] with the RFC number for
this specification.</t>
<section title="Registration of SDP Attributes">
<t>This document registers a new attribute name in SDP.</t>
<figure>
<artwork><![CDATA[
SDP Attribute ("att-field"):
Attribute name: media-grid-dims
Long form: 2-D media grid dimensions
Type of name: att-field
Type of attribute: Session level
Subject to charset: No
Purpose: Specifies the dimensions for a media grid
Reference: [RFC-AAAA]
Values: See [RFC-AAAA]
]]></artwork>
</figure>
</section>
<section title="Registration of Grouping Semantics">
<t>This document, following the Standards Action policy from <xref
target="RFC5226"></xref>, registers the following semantics with IANA
in the "Semantics for the "group" SDP Attribute" registry under SDP
Parameters:</t>
<figure>
<artwork><![CDATA[
Semantics Token Reference
--------------------------------- ----- -----------
Adjacent Media ADJ [RFC-AAAA]
]]></artwork>
</figure>
<t></t>
</section>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank Flemming Andreasen, Allyn Romanow,
Roni Even, Hakon Dahle, Ingemar Johansson, Peter Musgrave, and Geir Arne
Sandbakken for their review comments.</t>
</section>
<section title="Open Issues">
<t>More example can be added.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC5888">
<front>
<title>The Session Description Protocol (SDP) Grouping
Framework</title>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<date month="June" year="2010" />
<abstract>
<t>In this specification, we define a framework to group "m" lines
in the Session Description Protocol (SDP) for different purposes.
This framework uses the "group" and "mid" SDP attributes, both of
which are defined in this specification. Additionally, we specify
how to use the framework for two different purposes: for lip
synchronization and for receiving a media flow consisting of
several media streams on different transport addresses. This
document obsoletes RFC 3388. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5888" />
<format octets="43924"
target="http://www.rfc-editor.org/rfc/rfc5888.txt" type="TXT" />
</reference>
<reference anchor="RFC4566">
<front>
<title>SDP: Session Description Protocol</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization></organization>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization></organization>
</author>
<date month="July" year="2006" />
<abstract>
<t>This memo defines the Session Description Protocol (SDP). SDP
is intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of
multimedia session initiation. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4566" />
<format octets="108820"
target="http://www.rfc-editor.org/rfc/rfc4566.txt" type="TXT" />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list style="empty">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723"
target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT" />
<format octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
<reference anchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization></organization>
</author>
<author fullname="P. Overell" initials="P." surname="Overell">
<organization></organization>
</author>
<date month="January" year="2008" />
<abstract>
<t>Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form
(BNF), called Augmented BNF (ABNF), has been popular among many
Internet specifications. The current specification documents ABNF.
It balances compactness and simplicity with reasonable
representational power. The differences between standard BNF and
ABNF involve naming rules, repetition, alternatives,
order-independence, and value ranges. This specification also
supplies additional rule definitions and encoding for a core
lexical analyzer of the type common to several Internet
specifications. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68" />
<seriesInfo name="RFC" value="5234" />
<format octets="26359"
target="http://www.rfc-editor.org/rfc/rfc5234.txt" type="TXT" />
</reference>
<reference anchor="RFC5576">
<front>
<title>Source-Specific Media Attributes in the Session Description
Protocol (SDP)</title>
<author fullname="J. Lennox" initials="J." surname="Lennox">
<organization></organization>
</author>
<author fullname="J. Ott" initials="J." surname="Ott">
<organization></organization>
</author>
<author fullname="T. Schierl" initials="T." surname="Schierl">
<organization></organization>
</author>
<date month="June" year="2009" />
<abstract>
<t>The Session Description Protocol (SDP) provides mechanisms to
describe attributes of multimedia sessions and of individual media
streams (e.g., Real-time Transport Protocol (RTP) sessions) within
a multimedia session, but does not provide any mechanism to
describe individual media sources within a media stream. This
document defines a mechanism to describe RTP media sources, which
are identified by their synchronization source (SSRC) identifiers,
in SDP, to associate attributes with these sources, and to express
relationships among sources. It also defines several source-level
attributes that can be used to describe properties of media
sources. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5576" />
<format octets="40454"
target="http://www.rfc-editor.org/rfc/rfc5576.txt" type="TXT" />
</reference>
<reference anchor="RFC3264">
<front>
<title>An Offer/Answer Model with Session Description Protocol
(SDP)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<date month="June" year="2002" />
<abstract>
<t>This document defines a mechanism by which two entities can
make use of the Session Description Protocol (SDP) to arrive at a
common view of a multimedia session between them. In the model,
one participant offers the other a description of the desired
session from their perspective, and the other participant answers
with the desired session from their perspective. This offer/answer
model is most useful in unicast sessions where information from
both participants is needed for the complete view of the session.
The offer/answer model is used by protocols like the Session
Initiation Protocol (SIP). [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3264" />
<format octets="60854"
target="http://www.rfc-editor.org/rfc/rfc3264.txt" type="TXT" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC4474">
<front>
<title>Enhancements for Authenticated Identity Management in the
Session Initiation Protocol (SIP)</title>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization></organization>
</author>
<author fullname="C. Jennings" initials="C." surname="Jennings">
<organization></organization>
</author>
<date month="August" year="2006" />
<abstract>
<t>The existing security mechanisms in the Session Initiation
Protocol (SIP) are inadequate for cryptographically assuring the
identity of the end users that originate SIP requests, especially
in an interdomain context. This document defines a mechanism for
securely identifying originators of SIP messages. It does so by
defining two new SIP header fields, Identity, for conveying a
signature used for validating the identity, and Identity-Info, for
conveying a reference to the certificate of the signer. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4474" />
<format octets="104952"
target="http://www.rfc-editor.org/rfc/rfc4474.txt" type="TXT" />
</reference>
<reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in
RFCs</title>
<author fullname="T. Narten" initials="T." surname="Narten">
<organization></organization>
</author>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
<organization></organization>
</author>
<date month="May" year="2008" />
<abstract>
<t>Many protocols make use of identifiers consisting of constants
and other well-known values. Even after a protocol has been
defined and deployment has begun, new values may need to be
assigned (e.g., for a new option type in DHCP, or a new encryption
or authentication transform for IPsec). To ensure that such
quantities have consistent values and interpretations across all
implementations, their assignment must be administered by a
central authority. For IETF protocols, that role is provided by
the Internet Assigned Numbers Authority (IANA).</t><t>
In order for IANA to manage a given namespace prudently, it needs
guidelines describing the conditions under which new values can be
assigned or when modifications to existing values can be made. If
IANA is expected to play a role in the management of a namespace,
IANA must be given clear and concise instructions describing that
role. This document discusses issues that should be considered in
formulating a policy for assigning values to a namespace and
provides guidelines for authors on the specific text that must be
included in documents that place demands on
IANA.</t><t> This document obsoletes RFC 2434. This
document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26" />
<seriesInfo name="RFC" value="5226" />
<format octets="66160"
target="http://www.rfc-editor.org/rfc/rfc5226.txt" type="TXT" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:59:10 |