One document matched: draft-schmidt-avt-mps-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/rfc2629.dtd"[
<!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3640 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3640.xml">
]>
<?xml-stylesheet type='text/xsl' href="http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std"
docName="draft-schmidt-avt-mps-00.txt"
ipr="full3978"
obsoletes=""
updates="3640"
submissionType="IETF"
xml:lang="en">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Transport of MPEG Surround">RTP Payload Format for Elementary Streams with MPEG Surround multi-channel audio</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Frans de Bont"
initials="F.d.B."
surname="de Bont">
<organization>Philips Electronics</organization>
<address>
<postal>
<street>High Tech Campus 5</street>
<!-- Reorder these if your country does things differently -->
<city>5656 AE Eindhoven</city>
<region></region>
<country>NL</country>
</postal>
<phone>++31 40 2740234</phone>
<email>frans.de.bont@philips.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Stefan Doehla"
initials="S.D."
surname="Doehla">
<organization>Fraunhofer IIS</organization>
<address>
<postal>
<street>Am Wolfmantel 33</street>
<!-- Reorder these if your country does things differently -->
<city>91058 Erlangen</city>
<region></region>
<country>DE</country>
</postal>
<phone>+49 9131 776 6042</phone>
<email>stefan.doehla@iis.fraunhofer.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Malte Schmidt"
initials="M.S."
surname="Schmidt">
<organization>Dolby Laboratories</organization>
<address>
<postal>
<street>Deutschherrnstr. 15-19</street>
<!-- Reorder these if your country does things differently -->
<city>90537 Nuernberg</city>
<region></region>
<country>DE</country>
</postal>
<phone>+49 911 928 91 42</phone>
<email>malte.schmidt@dolby.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Ralph Sperschneider"
initials="R.S."
surname="Sperschneider">
<organization>Fraunhofer IIS</organization>
<address>
<postal>
<street>Am Wolfmantel 33</street>
<!-- Reorder these if your country does things differently -->
<city>91058 Erlangen</city>
<region></region>
<country>DE</country>
</postal>
<phone>+49 9131 776 6167</phone>
<email>ralph.sperschneider@iis.fraunhofer.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2008" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>AVT</area>
<workgroup>AVT</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>MPEG Surround, RFC3640, RTP, MPEG-4, AAC</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This memo describes extensions for the RTP payload format defined in RFC3640 for the transport of MPEG Surround multi-channel audio. Additional MIME Type parameters are defined to signal backwards compatible transmission inside an MPEG-4 audio elementary stream. In addition a layered transmission scheme without using the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data.</t>
</abstract>
</front>
<!-- ----------------------------------------------------------------- -->
<middle>
<section title="Introduction"
toc="default">
<t>
<xref target="23003-1">MPEG Surround (Spatial Audio Coding, SAC)</xref> is an International Standard that was finalized by MPEG in January 2007. It is capable of re-creating N channels based on M<N transmitted channels and additional control data. In the preferred modes of operating the spatial audio coding system, the M channels can either be a single mono channel or a stereo channel pair. The control data represents a significant lower data rate than the data rate required for transmitting all N channels, making the coding very efficient while at the same time ensuring compatibility with M channel devices.
</t>
<t>
The MPEG Surround standard incorporates a number of tools enabling features that allow for broad application of the standard. A key feature is the ability to scale the spatial image quality gradually from very low spatial overhead towards transparency. Another key feature is that the decoder input can be made compatible to existing matrixed surround technologies.
</t>
<t>
As an example, for 5.1 multi-channel audio, the MPEG Surround encoder creates a stereo (or mono) downmix signal and spatial information describing the full 5.1 material in a highly efficient parameterised format. The spatial information is transmitted alongside the downmix.
</t>
<t>
By using MPEG Surround, existing services can easily be upgraded to provide surround sound in a backward compatible fashion. While a stereo decoder in an existing legacy consumer device ignores the MPEG Surround data and plays back the stereo signal without any quality degradation, an MPEG Surround enabled decoder will deliver high quality multi-channel audio.
</t>
<t>The MPEG Surround decoder can operate in modes that render the multi-channel signal to multi-channel output, stereo output or operate in a two-channel headphone mode to produce a virtual surround output signal.
</t>
</section>
<section title="Conventions"
toc="default">
<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 <xref target="RFC2119" />.
</t>
</section>
<section title="Definitions and Abbreviations"
toc="default">
<section title="Definitions"
toc="default">
<t>
This memo makes use of the definitions specified in <xref target="14496-1" />, <xref target="14496-3" />, <xref target="23003-1" /> and <xref target="RFC3640" />. Frequently used terms are summed up for convenience:
<list>
<t>Access Unit: An MPEG Access Unit is the smallest data entity to which timing information is attributed. In the case of audio, an Access Unit is the smallest individually accessible portion of coded audio data within an elementary stream.</t>
<t>AudioSpecificConfig(): Extends the class DecoderSpecificInfo(), as defined in <xref target="14496-1" /> when the objectType indication refers to a stream complying with <xref target="14496-3" />. AudioSpecificConfig() is used as the configuration structure for MPEG-4 Audio as specified in <xref target="14496-3" />. It contains the field audioObjectType that distincts between the different audio codecs defined in <xref target="14496-3" />, general audio information (e.g. the sampling frequency and number of channels) and further codec-dependent information structures.</t>
<t>SpatialSpecificConfig(): Configuration structure for MPEG Surround audio coding as specified in <xref target="23003-1" />. An AudioSpecificConfig() with an audioObjectType of value 30 contains a SpatialSpecificConfig() structure.</t>
</list>
</t>
</section>
<section title="Abbreviations"
toc="default">
<t>
<figure>
<artwork> AOT: Audio Object Type
ASC: AudioSpecificConfig() structure
AU: Access Unit
PLI: Profile and Level Indication
SSC: SpatialSpecificConfig() structure</artwork>
</figure>
</t>
</section>
</section>
<section title="Transport of MPEG Surround"
toc="default">
<t>
From a top-level perspective MPEG Surround data can be subdivided into configuration data contained in the SpatialSpecificConfig() (SSC) and the SpatialFrame() that contains the MPEG Surround payload. The configuration data can be signaled in-band or out-of-band. In the case of in-band signaling the SSC is conveyed in an SacDataFrame() jointly with a SpatialFrame(). In the case of out-of-band signaling the SSC is transmitted to the decoder separately, e.g. by SDP means.
</t>
<t>
SpatialFrame()s may be transmitted either embedded into the downmix stream (<xref target="Embedded spatial audio data in AAC payloads" />) or as an individual elementary stream besides the downmix audio stream (<xref target="MPEG Surround Elementary Streams" />).
</t>
<t>The buffer definition for AAC decoders limits the size of an AU as specified in <xref target="14496-3" />. For high-bitrate applications that exceed this limit all MPEG Surround data MUST be put in a separate stream as defined in <xref target="MPEG Surround Elementary Streams" />.
</t>
<section title="Embedded spatial audio data in AAC payloads" anchor="Embedded spatial audio data in AAC payloads">
<t>
<xref target="14496-3" /> define the extension_payload() as a mechanism for transport of extension data inside AAC payloads. Typical extension data include SBR data and MPEG Surround data, i.e. a SacDataFrame() in extension_payload()s of type EXT_SAC_DATA. extension_payload()s reside inside the downmix AAC elementary stream. The resulting single elementary stream is transported as specified in <xref target="RFC3640" />. As AAC decoders are required to skip unknown extension data, MPEG Surround data can be embedded backwards compatible and be transported with the mechanism already described in <xref target="RFC3640" />.
</t>
<t>
The SacDataFrame() includes a SpatialFrame() and an optional header that contains an SSC. Any SSC in a SacDataFrame() MUST be identical to the SSC conveyed via SDP for that stream.
</t>
<t>No new mode is introduced for SpatialFrame()s being embedded into AAC payloads. Either the modes AAC-lbr or AAC-hbr SHOULD be used. The additional MIME Type parameters as defined in <xref target="MIME Type registration" /> MUST be present when SpatialFrame()s are embedded into AAC payloads.
</t>
<t>For example:</t>
<t>
<figure>
<artwork> m=audio 5000 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/48000/2
a=fmtp:96 streamType=5; profile-level-id=44; mode=AAC-hbr; config=131
056E598; sizeLength=13; indexLength=3; indexDeltaLength=3; constant
Duration=2048; MPS-profile-level-id=55; MPS-config=F1B4CF920442029B
501185B6DA00;</artwork>
</figure>
</t>
<t>In this example the stream specifies the HE-AAC Profile at Level 2 [Profile and Level Indication (PLI) 44] and the config string contains the hexadecimal representation of the HE-AAC ASC [audioObjectType=2 (AAC LC); extensionAudioObjectType=5 (SBR); samplingFrequencyIndex=0x6 (24kHz); extensionSamplingFrequencyIndex=0x3 (48kHz); channelConfiguration=2 (2.0 channels)] of the downmix AAC elementary stream using explicit backward compatible signaling.
</t>
<t>Furthermore, the stream specifies the MPEG Surround Baseline Profile at Level 3 (PLI55) and the MPS-config string contains the hexadecimal representation of the MPEG Surround ASC [audioObjectType=30 (MPEG Surround); samplingFrequencyIndex=0x3 (48kHz); channelConfiguration=6 (5.1 channels); sacPayloadEmbedding=1; SSC=(48 kHz; 32 slots; 525 tree; ResCoding=1; ResBands=[0,13,13,13])].
</t>
<t>Note that the a=fmtp lines of the example above have been wrapped to fit the page; they comprise each a single line in the SDP file.
</t>
</section>
<section title="MPEG Surround Elementary Stream" anchor="MPEG Surround Elementary Streams">
<t>
MPEG Surround SpatialFrame()s can be present in an individual elementary stream. This stream complements the stream containing the downmix audio data, which may be coded by an arbitrary coding scheme. MPEG Surround elementary streams are packetized as specified in <xref target="RFC3640" />. The mode signaled and used for an MPEG Surround elementary stream MUST be either MPS-hbr or MPS-lbr. The MPS-hbr mode SHALL be used when the frame size may exceed 63 bytes, e.g. when high-bitrate residual coding is in use.
</t>
<t>
The dependency relationships between the MPEG Surround elementary stream and the downmix stream are signaled as specified in <xref target="I-D.ietf-mmusic-decoding-dependency" />.
</t>
<t>
The media clocks of the MPEG Surround elementary stream and the downmix stream SHALL operate in the same clock domain, i.e. the clocks MUST NOT drift. RTCP sender reports MUST indicate that the stream timestamps are not drifting, i.e. that a single sender report for each stream is sufficient to establish unambiguous timing. The sampling rate of the MPEG Surround signal and the decoded downmix signal MUST be identical.
</t>
<t>
If HE-AAC is used as the coding scheme for the downmix, the RTP clock-rate of the downmix MAY be the sampling rate of the AAC core, i.e. the clock-rate of the MPEG Surround elementary stream is an integer multiple of the clock-rate of the downmix stream.
</t>
<t>
Note that separate RTP streams have different random RTP timestamp offsets and therefore RTCP MUST be used to synchronize the coded downmix audio data and the MPEG surround elementary stream.
</t>
<t>For example:</t>
<t>
<figure>
<artwork> a=group:DDP 1 2
m=audio 5000 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/48000/2
a=fmtp:96 streamType=5; profile-level-id=44; mode=AAC-hbr; config=2B1
18800; sizeLength=13; indexLength=3; indexDeltaLength=3; constantDu
ration=2048
a=mid:1
m=audio 5002 RTP/AVP 97
a=rtpmap:97 mpeg4-generic/48000/6
a=fmtp:97 streamType=5; profile-level-id=55; mode=MPS-hbr; config=F1B
0CF920460029B601189E79E70; sizeLength=13; indexLength=3; indexDelt
aLength=3; constantDuration=2048
a=mid:2
a=depend:97 lay 1:96;</artwork>
</figure>
</t>
<t>In this example the first stream specifies the High Efficiency AAC Profile at Level 2 (PLI44) and the config string contains the hexadecimal representation of the HE-AAC ASC [audioObjectType=2 (AAC LC); extensionAudioObjectType=5 (SBR); samplingFrequencyIndex=0x6 (24kHz); extensionSamplingFrequencyIndex=0x3 (48kHz); channelConfiguration=2 (2.0 channels)].
</t>
<t>The second stream specifies Baseline MPEG Surround Profile at Level 3 (PLI55) and the config string contains the hexadecimal represenation of the ASC [AOT=30(MPEG Surround); 48 kHz; 5.1-ch; sacPayloadEmbedding=0; SSC=(48 kHz; 32 slots; 525 tree; ResCoding=1; ResBands=[7,7,7,7])]
</t>
<t>Note that the a=fmtp lines of the example above have been wrapped to fit the page; they comprise each a single line in the SDP file.
</t>
<section title="Low Bit-rate MPEG Surround"
toc="default">
<t>This mode is signaled by mode=MPS-lbr. This mode supports the transport of one or more complete Access Units, each consisting of a single MPEG Surround SpatialFrame(). The AUs can be variably sized and interleaved. The maximum size of a SpatialFrame() is 63 bytes. Fragmentation MUST NOT be used in this mode. Receivers MUST support de-interleaving.
</t>
<t>The payload configuration is the same as in the AAC-lbr mode. It consists of the AU Header Section, followed by concatenated AUs. Note that Access Units are byte-aligned. The Auxiliary Section MUST be empty in the MPS-lbr mode. The one-octet AU-header MUST provide:
<list hangIndent="0"
style="numbers">
<t>the size of each AAC frame encoded as 6 bits</t>
<t>2 bits index information for computing the sequence (and hence timing) of each SpatialFrame().</t>
</list>
</t>
<t>The concatenated AU-header Section MUST be preceded by the 16-bit AU-header-length field.</t>
<t>In addition to the required MIME format parameters, the following parameters MUST be present with fixed values: sizeLength (fixed value 6), indexLength (fixed value 2) and indexDeltaLength (fixed value 2). The parameter maxDisplacement MUST be present when interleaving. SpatialFrame()s always have a fixed duration per AU; the fixed duration MUST be signaled by the MIME format parameter constantDuration.
</t>
<t>
The value of the "config" parameter is the hexadecimal representation of the ASC, as defined in <xref target="14496-3" /> with an AOT of 30 and the sacPayloadEmbedding flag set to 0.
</t>
<t>
The "profile-level-id" parameter SHALL contain a valid PLI for MPEG Surround as specified in <xref target="14496-3" />.
</t>
</section>
<section title="High Bit-rate MPEG Surround"
toc="default">
<t>This mode is signaled by mode=MPS-hbr. This mode supports the transportation of either one fragment of an Access Unit or one complete AU or several complete AUs. Each AU consists of a single MPEG Surround SpatialFrame(). The AUs can be variably sized and interleaved. The maximum size of a SpatialFrame() is 8191 bytes. Receivers MUST support de-interleaving.
</t>
<t>The payload configuration is the same as in the AAC-hbr mode. It consists of the AU Header Section, followed by either one SpatialFrame(), a fragment of a SpatialFrame() or several concatenated SpatialFrame()s. Note that Access Units are byte-aligned. The Auxiliary Section MUST be empty in the MPS-hbr mode. The two-octet AU-header MUST provide:
<list hangIndent="0"
style="numbers">
<t>the size of each AAC frame encoded as 13 bits</t>
<t>3 bits index information for computing the sequence (and hence timing) of each SpatialFrame(), i.e. the AU-Index or AU-Index-delta field.</t>
</list>
</t>
<t>Each AU-Index field MUST be coded with the value 0. The concatenated AU-header Section MUST be preceded by the 16-bit AU-header-length field.</t>
<t>In addition to the required MIME format parameters, the following parameters MUST be present with fixed values: sizeLength (fixed value 13), indexLength (fixed value 3) and indexDeltaLength (fixed value 3). The parameter maxDisplacement MUST be present when interleaving. SpatialFrame()s always have a fixed duration per AU; the fixed duration MUST be signaled by the MIME format parameter constantDuration.
</t>
<t>
The value of the "config" parameter is the hexadecimal representation of the ASC, as defined in <xref target="14496-3" /> with an AOT of 30 and the sacPayloadEmbedding flag set to 0.
</t>
<t>
The "profile-level-id" parameter SHALL contain a valid PLI for MPEG Surround as specified in <xref target="14496-3" />.
</t>
</section>
</section>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<section title="IANA Considerations"
toc="default">
<t>
This memo defines additional optional format parameters to the MIME subtype mpeg4-generic. These parameters SHALL only be used in combination with the AAC-lbr or AAC-hbr modes (cf. <xref target="RFC3640" /> section 3.3).
</t>
<section title="MIME Type registration" anchor="MIME Type registration">
<t>
This memo defines the following additional optional parameters which SHALL be used if MPEG Surround data is present inside the payload of an AAC elementary stream.
<list hangIndent="2"
style="empty">
<t>
MPS-profile-level-id: A decimal representation of the MPEG Surround Profile Level indication as defined in <xref target="14496-3" />. This parameter MUST be used in the capability exchange or session set-up procedure to indicate the MPEG Surround Profile and Level that the decoder must be capable in order to decode the stream.
</t>
<t>
MPS-config: A hexadecimal representation of an octet string that expresses the AudioSpecificConfig (ASC) as defined in <xref target="14496-3" /> for MPEG Surround. The ASC is mapped onto the hexadecimal octet string in an MSB-first basis.
The AOT in this ASC SHALL have the value 30. The SSC inside the ASC MUST have the sacPayloadEmbedding flag set to 1.
</t>
</list>
</t>
</section>
<section title="Registration of Mode Definitions with IANA"
toc="default">
<t>This memo defines the modes MPS-hbr and MPS-lbr.</t>
</section>
<section title="Usage of SDP"
toc="default">
<t>It is assumed that the MIME format parameters are conveyed via an SDP message as specified in <xref target="RFC3640" />, section 4.4.</t>
</section>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="Security"
title="Security Considerations"
toc="default">
<t>
RTP packets using the payload format defined in this memo are subject to the security considerations of the RTP specification <xref target="RFC3550" /> and <xref target="RFC3640" /> which is extended with this memo. This implies that confideniality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed on the compressed data so there is no conflict between the two operations.
</t>
</section>
</middle>
<!-- ----------------------------------------------------------------- -->
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<reference anchor="RFC3640">
<front>
<title>RTP Payload Format for Transport of MPEG-4 Elementary Streams</title>
<author initials="J."
surname="van der Meer"
fullname="J. van der Meer">
<organization />
</author>
<author initials="D."
surname="Mackie"
fullname="D. Mackie">
<organization />
</author>
<author initials="V."
surname="Swaminathan"
fullname="V. Swaminathan">
<organization />
</author>
<author initials="D."
surname="Singer"
fullname="D. Singer">
<organization />
</author>
<author initials="P."
surname="Gentric"
fullname="P. Gentric">
<organization />
</author>
<date year="2003"
month="November" />
<abstract>
<t>The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream.</t>
</abstract>
</front>
<seriesInfo name="RFC"
value="3640" />
<format type="TXT"
octets="102606"
target="ftp://ftp.isi.edu/in-notes/rfc3640.txt" />
</reference>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S."
surname="Bradner"
fullname="Scott 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 year="1997"
month="March" />
<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>
<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 type="TXT"
octets="4723"
target="ftp://ftp.isi.edu/in-notes/rfc2119.txt" />
<format type="HTML"
octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html" />
<format type="XML"
octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" />
</reference>
<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization/></author>
<author initials="S." surname="Casner" fullname="S. Casner">
<organization/></author>
<author initials="R." surname="Frederick" fullname="R. Frederick">
<organization/></author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization/></author>
<date year="2003" month="July"/>
<abstract>
<t>This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS TRACK]
</t>
</abstract>
</front>
<seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<format type="TXT" octets="259985" target="ftp://ftp.isi.edu/in-notes/rfc3550.txt"/>
<format type="PS" octets="630740" target="ftp://ftp.isi.edu/in-notes/rfc3550.ps"/>
<format type="PDF" octets="504117" target="ftp://ftp.isi.edu/in-notes/rfc3550.pdf"/>
</reference>
<reference anchor="I-D.ietf-mmusic-decoding-dependency">
<front>
<title>Signaling media decoding dependency in Session Description Protocol (SDP)</title>
<author initials="T."
surname="Schierl"
fullname="Thomas Schierl">
<organization>Fraunhofer HHI</organization>
</author>
<author initials="S."
surname="Wenger"
fullname="Stephan Wenger">
<organization>Nokia</organization>
</author>
<date year="2008" month="February" />
</front>
<seriesInfo name="I-D"
value="ietf-mmusic-decoding-dependency" />
<format type="TXT"
octets="102606"
target="http://tools.ietf.org/id/draft-ietf-mmusic-decoding-dependency-01.txt" />
</reference>
<reference anchor="23003-1">
<front>
<title>ISO/IEC International Standard 23003-1 - MPEG Surround (MPEG D)</title>
<author initials=""
surname="MPEG">
<organization></organization>
</author>
<date year="2007" />
</front>
</reference>
<reference anchor="14496-1">
<front>
<title>ISO/IEC International Standard 14496-1 - Coding of audio-visual objects, Part 1 Systems</title>
<author initials=""
surname="MPEG">
<organization></organization>
</author>
<date year="2004" />
</front>
</reference>
<reference anchor="14496-3">
<front>
<title>ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio</title>
<author initials=""
surname="MPEG">
<organization></organization>
</author>
<date year="2005" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:40:10 |