One document matched: draft-jennings-mmusic-adjacent-grouping-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?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-00"
ipr="trust200902">
<front>
<title abbrev="SDP Adjacent Grouping">Grouping of Adjacent Media in
SDP</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>
<date day="21" month="September" year="2010" />
<area>RAI</area>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 <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 are
adjacent to each other.</t>
<t>This specification defines a new group, using the SDP grouping
framework defined in <xref target="RFC5888"></xref> that indicates media
streams are adjacent, and the adjacency order is defined by the order of
the entires 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
RFC 5888. 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="Semantics">
<t>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.</t>
<section title="Use in Offer/Answer systems">
<t>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.</t>
</section>
</section>
<section title="Examples">
<t>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.</t>
<figure>
<artwork><![CDATA[
Screen A Screen B Screen C
[----------][------------][------------]
M1 M2 M3 M4 M5 M6
User
]]></artwork>
</figure>
<t>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:</t>
<figure>
<artwork><![CDATA[
a=group:ADJ sc sb sa
a=group:ADJ m6 m5 m4 m3 m2 m1
]]></artwork>
</figure>
<t>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:</t>
<figure>
<artwork><![CDATA[
a=group:ADJ sb sa
a=group:ADJ m6 m1
]]></artwork>
</figure>
<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>
</section>
<section title="IANA Considerations">
<t>This specification, following the Standards Action policy from <xref
target="RFC5226"></xref>, adds the following entry to the "Semantics for
the group SDP Attribute" registry defined by <xref
target="RFC5888"></xref>. [Note to RFC Editor: Please replace RFC-AAAA
with the RFC number for this specification.]</t>
<t></t>
<figure>
<artwork><![CDATA[
Semantics Token Reference
--------------------------------- ----- -----------
Adjacent Media ADJ RFC-AAAA
]]></artwork>
</figure>
<t></t>
</section>
<section title="Security Considerations">
<t>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 <xref
target="RFC4474"></xref>.</t>
<t>Further discussion of security proprieties can be found in <xref
target="RFC4566"></xref>.</t>
</section>
<section title="Acknowledgements">
<t>I would like to thank Flemming Andreasen, Allyn Romanow, and <get
your name here> for their review comments.</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>
</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 11:02:22 |