[xiph-commits] r16084 - trunk/theora/doc
lu_zero at svn.xiph.org
lu_zero at svn.xiph.org
Wed Jun 3 03:17:33 PDT 2009
Author: lu_zero
Date: 2009-06-03 03:17:33 -0700 (Wed, 03 Jun 2009)
New Revision: 16084
Modified:
trunk/theora/doc/draft-ietf-avt-rtp-theora-00.xml
Log:
Partial update, 1/4 to the vorbis rfc
Modified: trunk/theora/doc/draft-ietf-avt-rtp-theora-00.xml
===================================================================
--- trunk/theora/doc/draft-ietf-avt-rtp-theora-00.xml 2009-06-03 06:10:43 UTC (rev 16083)
+++ trunk/theora/doc/draft-ietf-avt-rtp-theora-00.xml 2009-06-03 10:17:33 UTC (rev 16084)
@@ -6,7 +6,7 @@
<rfc ipr="full3978" docName="RTP Payload Format for Theora Encoded Video">
<front>
-<title>draft-ietf-avt-rtp-theora-00</title>
+<title>draft-ietf-avt-rtp-theora-01</title>
<author initials="L" surname="Barbato" fullname="Luca Barbato">
<organization>Xiph.Org</organization>
@@ -16,7 +16,7 @@
</address>
</author>
-<date day="21" month="July" year="2006" />
+<date day="19" month="May" year="2009" />
<area>General</area>
<workgroup>AVT Working Group</workgroup>
<keyword>I-D</keyword>
@@ -31,7 +31,8 @@
</t>
<t>
-Also included within the document are the necessary details for the use of Theora with MIME and Session Description Protocol (SDP).
+Also included within this memo are media type registrations, and the details
+necessary for the use of Theora with the Session Description Protocol (SDP).
</t>
</abstract>
@@ -55,7 +56,7 @@
</t>
<t>
-Theora provides none of its own framing, synchronization, or protection against transmission errors. Instead, the codec expects to receive a discrete sequence of data packets. Theora is a free-form variable bit rate (VBR) codec, and these packets have no minimum size, maximum size, or fixed/expected size. Theora packets are thus intended to be used with a transport mechanism that provides free-form framing, synchronization, positioning, and error correction in accordance with these design assumptions, such as Ogg <xref target="rfc3533"></xref> or RTP/AVP <xref target="rfc3550"></xref>.
+Theora provides none of its own framing, synchronization, or protection against transmission errors. Instead, the codec expects to receive a discrete sequence of data packets. Theora is a free-form variable bit rate (VBR) codec, and these packets have no minimum size, maximum size, or fixed/expected size. Theora packets are thus intended to be used with a transport mechanism that provides free-form framing, synchronization, positioning, and error correction in accordance with these design assumptions, such as Ogg <xref target="rfc3533"></xref> or RTP/AVP <xref target="RFC3550"></xref>.
</t>
<t>
@@ -64,33 +65,33 @@
</t>
<t>
-Theora is similar to the Vorbis audio <xref target="vorbisrtp"></xref> in that the decoder reads the probability model for the entropy coder and all quantization parameters from special "header" packets at the start of the compressed data. It is therefore impossible to decode any video data without having previously fetched the codec info and codec setup headers, although Theora can begin to decode at an arbitrary intra-frame packet so long as the codec has been initialized with the associated headers.
+Theora is similar to the Vorbis audio <xref target="RFC5215"></xref> in that the decoder reads the probability model for the entropy coder and all quantization parameters from special "header" packets at the start of the compressed data. It is therefore impossible to decode any video data without having previously fetched the codec info and codec setup headers, although Theora can begin to decode at an arbitrary intra-frame packet so long as the codec has been initialized with the associated headers.
</t>
+<section anchor="Terminology" title="Conformance and Document Conventions">
-<section anchor="Terminology" title="Terminology">
+<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 BCP 14, <xref target="RFC2119"/> and indicate requirement levels for compliant implementations. Requirements apply to all implementations unless otherwise stated.</t>
+<t>An implementation is a software module that supports one of the media types defined in this document. Software modules may support multiple media types, but conformance is considered individually for each type.</t>
+<t>Implementations that fail to satisfy one or more "MUST" requirements are considered non-compliant. Implementations that satisfy all "MUST" requirements, but fail to satisfy one or more "SHOULD" requirements, are said to be "conditionally compliant". All other implementations are "unconditionally compliant".</t>
-<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 <xref target="rfc2119"></xref>.
-</t>
-
</section>
</section>
<section anchor="Payload Format" title="Payload Format">
<t>
-For RTP based transportation of Theora encoded video the standard RTP header is followed by a 4 octets payload header, then the payload data. The payload headers are used to associate the Theora data with its associated decoding codebooks as well as indicating if the following packet contains fragmented Theora data and/or the number of whole Theora data frames. The payload data contains the raw Theora bitstream information.
+For RTP-based transport of Theora-encoded audio, the standard RTP header is
+followed by a 4-octet payload header, and then the payload data. The payload
+headers are used to associate the Theora data with its associated decoding
+codebooks as well as indicate if the following packet contains fragmented
+Theora data and/or the number of whole Theora data frames. The payload data
+contains the raw Theora bitstream information. There are 3 types of Theora
+data; an RTP payload MUST contain just one of them at a time.
</t>
-<t>
-For RTP based transport of Theora encoded video the standard RTP header is followed by a 4 octets payload header, then the payload data.
-</t>
-
<section anchor="RTP Header" title="RTP Header">
<t>
-The format of the RTP header is specified in <xref target="rfc3550"></xref> and shown in Figure 1. This payload format uses the fields of the header in a manner consistent with that specification.
+The format of the RTP header is specified in <xref target="RFC3550"></xref> and shown in <xref target="RTP Header Figure"/>. This payload format uses the fields of the header in a manner consistent with that specification.
</t>
<figure anchor="RTP Header Figure" title="RTP Header">
@@ -111,7 +112,10 @@
</figure>
<t>
-The RTP header begins with an octet of fields (V, P, X, and CC) to support specialized RTP uses (see <xref target="rfc3550"></xref> and <xref target="rfc3551"></xref> for details). For Theora RTP, the following values are used.
+The RTP header begins with an octet of fields (V, P, X, and CC) to support
+specialized RTP uses (see <xref target="RFC3550"></xref> and
+<xref target="RFC3551"></xref> for details). For Theora RTP, the following
+values are used.
</t>
<t>
@@ -121,22 +125,22 @@
<t>
Padding (P): 1 bit</t><t>
-Padding MAY be used with this payload format according to section 5.1 of <xref target="rfc3550"></xref>.
+Padding MAY be used with this payload format according to section 5.1 of <xref target="RFC3550"></xref>.
</t>
<t>
Extension (X): 1 bit</t><t>
-The Extension bit is used in accordance with <xref target="rfc3550"></xref>.
+The Extension bit is used in accordance with <xref target="RFC3550"></xref>.
</t>
<t>
CSRC count (CC): 4 bits</t><t>
-The CSRC count is used in accordance with <xref target="rfc3550"></xref>.
+The CSRC count is used in accordance with <xref target="RFC3550"></xref>.
</t>
<t>
Marker (M): 1 bit</t><t>
-The Marker bit is used in accordance with <xref target="rfc3550"></xref>.
+The Marker bit is used in accordance with <xref target="RFC3550"></xref>.
</t>
<t>
@@ -146,7 +150,7 @@
<t>
Sequence number: 16 bits</t><t>
-The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. This field is detailed further in <xref target="rfc3550"></xref>.
+The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. This field is detailed further in <xref target="RFC3550"></xref>.
</t>
<t>
@@ -156,7 +160,7 @@
<t>
SSRC/CSRC identifiers: </t><t>
-These two fields, 32 bits each with one SSRC field and a maximum of 16 CSRC fields, are as defined in <xref target="rfc3550"></xref>.
+These two fields, 32 bits each with one SSRC field and a maximum of 16 CSRC fields, are as defined in <xref target="RFC3550"></xref>.
</t>
</section>
@@ -164,7 +168,9 @@
<section anchor="Payload Header" title="Payload Header">
<t>
-The 4 octets following the RTP Header section represent the Payload Header. This header is split into a number of bitfields detailing the format of the following Payload Datagrams.
+The 4 octets following the RTP Header section are the Payload Header. This
+header is split into a number of bit fields detailing the format of the
+following payload data packets.
</t>
<figure anchor="Payload Header Figure" title="Payload Header">
@@ -182,7 +188,8 @@
<t>
Configuration Ident: 24 bits</t>
<t>
-This 24 bit field is used to associate the Theora data to a decoding Packed Configuration.
+This 24-bit field is used to associate the Theora data to a decoding
+Configuration. It is stored as a network byte order integer.
</t>
<t>
@@ -198,12 +205,11 @@
<t> 3 = End Fragment</t>
</list>
-<t>This field must be zero if the number of packets field is non-zero.</t>
-
<t>
Theora Data Type (TDT): 2 bits</t>
<t>
-This field sets the packet payload type for the Theora data. There are currently three Theora payload types currently used and one reserved for future use.
+This field specifies the kind of Theora data stored in this RTP packet. There
+are currently three different types of Theora payloads. Each packet MUST contain only a single type of Theora packet (e.g., you must not aggregate configuration and comment packets in the same RTP payload).
</t>
<vspace blankLines="1" />
@@ -217,7 +223,9 @@
<t> The packets with a TDT of value 3 MUST be ignored </t>
<t>
-The last 4 bits represent the number of complete packets in this payload. This provides a maximum number of 15 Theora packets in the payload. If the packet contains fragmented data the number of packets MUST be set to 0.
+The last 4 bits represent the number of complete packets in this payload. This
+provides for a maximum number of 15 Theora packets in the payload. If the
+payload contains fragmented data, the number of packets MUST be set to 0.
</t>
</section>
@@ -243,9 +251,22 @@
</t>
<t>
-For payloads which consist of multiple Theora packets the payload data consists of the payload length field followed by the first Theora packet's data, then the payload length followed by the second Theora packet, and so on for each of the Theora packets in the payload.
+For payloads that consist of multiple Theora packets, the payload data consists
+of the packet length followed by the packet data for each of the Theora packets
+in the payload.
</t>
+<t>
+The Theora packet length header is the length of the Theora data block only and
+does not include the length field.
+</t>
+
+<t>
+The payload packing of the Theora data packets MUST follow the guidelines
+set out in <xref target="RFC3551"></xref>.
+</t>
+
+
</section>
<section anchor="Example RTP Packet" title="Example RTP Packet">
@@ -320,7 +341,7 @@
</t>
<t>
-The delivery vectors in use are specified by an SDP attribute that indicates the method and the optional URI where the Theora <xref target="Packed Configuration">Packed Configuration</xref> Packets could be fetched. Different delivery methods MAY be advertised for the same session. The in-band codebook delivery SHOULD be considered as baseline, out-of-band delivery methods that don't use RTP will not be described in this document. For non chained streams, the RECOMMENDED Configuration delivery method is inline the <xref target="Packed Configuration">Packed Configuration</xref> in the SDP as explained in the <xref target="Mapping MIME Parameters into SDP"> IANA considerations</xref>
+The delivery vectors in use are specified by an SDP attribute that indicates the method and the optional URI where the Theora <xref target="Packed Configuration">Packed Configuration</xref> Packets could be fetched. Different delivery methods MAY be advertised for the same session. The in-band codebook delivery SHOULD be considered as baseline, out-of-band delivery methods that don't use RTP will not be described in this document. For non chained streams, the RECOMMENDED Configuration delivery method is inline the <xref target="Packed Configuration">Packed Configuration</xref> in the SDP as explained in the <xref target="Mapping Media Type Parameters into SDP"> IANA considerations</xref>
</t>
<t>
@@ -430,115 +451,7 @@
<t>The key difference from the in-band format is that there is no need for the payload header octet.
</t>
-<section anchor="Packed Headers IANA Considerations" title="Packed Headers IANA Considerations">
-
-<t>
-The following IANA considerations MUST only be applied to the packed headers.
-</t>
-
-<vspace blankLines="1" />
-
-<list style="hanging">
-<t hangText="MIME media type name:"> video </t>
-
-<vspace blankLines="1" />
-
-<t hangText="MIME subtype:"> theora-config </t>
-
-<vspace blankLines="1" />
-
-<t hangText="Required Parameters:">
-<vspace blankLines="1" />
-None
-</t>
-
-<vspace blankLines="1" />
-
-<t hangText="Optional Parameters:">
-<vspace blankLines="1" />
-None
-</t>
-
-<vspace blankLines="1" />
-
-<t hangText="Encoding considerations:">
-<vspace blankLines="1" />
-This media type contains binary data.
-</t>
-
-<vspace blankLines="1" />
-
-<t hangText="Security Considerations:">
-<vspace blankLines="1" />
-See Section 6 of RFC XXXX.
-</t>
-
-<vspace blankLines="1" />
-
-<t hangText="Interoperability considerations:">
-<vspace blankLines="1" />
-None
-</t>
-
-<vspace blankLines="1" />
-
-<t hangText="Published specification:">
-<vspace blankLines="1" />
-RFC XXXX [RFC Editor: please replace by the RFC number of this memo,
- when published]
-</t>
-
-<vspace blankLines="1" />
-
-<t hangText="Applications which use this media type:">
-<vspace blankLines="1" />
-Theora encoded video, configuration data.
-</t>
-
-<vspace blankLines="1" />
-
-<t hangText="Additional information:">
-<vspace blankLines="1" />
-None
-</t>
-
-<vspace blankLines="1" />
-
-<t hangText="Person & email address to contact for further information:">
-<vspace blankLines="1" />
-Luca Barbato: <lu_zero at gentoo.org>
-<vspace blankLines="0" />
-IETF Audio/Video Transport Working Group
-</t>
-
-<vspace blankLines="1" />
-
-<t hangText="Intended usage:">
-COMMON
-</t>
-
-<vspace blankLines="1" />
-
-<t hangText="Restriction on usage:">
-<vspace blankLines="1" />
-This media type does not depend on the transport.
-</t>
-
-<vspace blankLines="1" />
-
-<t hangText="Author:">
-<vspace blankLines="1" />
-Luca Barbato</t>
-
-<vspace blankLines="1" />
-
-<t hangText="Change controller:">
-<vspace blankLines="1" />
-IETF AVT Working Group</t>
-</list>
-
</section>
-</section>
</section>
@@ -725,11 +638,11 @@
<vspace blankLines="1" />
<list style="hanging">
-<t hangText="MIME media type name:"> video </t>
+<t hangText="Type name:"> video </t>
<vspace blankLines="1" />
-<t hangText="MIME subtype:"> theora </t>
+<t hangText="Subtype name:"> theora </t>
<vspace blankLines="1" />
@@ -739,40 +652,50 @@
<list style="hanging">
-<t hangText="sampling:"> Determines the chroma subsampling format.
+<t hangText="delivery-method:"> indicates the delivery methods in use, the possible values are: inline, in_band, out_band/specific_name<vspace blankLines="0" />
+Where "specific_name" is the name of the out of band delivery method.
</t>
<vspace blankLines="1" />
-<t hangText="width:"> Determines the number of pixels per line. This is an integer between 1 and 1048561 and MUST be in multiples of 16.
+<t hangText="configuration:"> the <xref target="rfc3548">base64</xref> (hexadecimal) representation of the <xref target="Packed Headers">Packed Headers</xref>.
</t>
+</list>
+</t>
<vspace blankLines="1" />
-<t hangText="height:">Determines the number of lines per frame encoded. This is an integer between 1 and 1048561 and MUST be in multiples of 16.
+<t hangText="Optional Parameters:">
+
+<t hangText="sampling:"> Determines the chroma subsampling format.
</t>
<vspace blankLines="1" />
-<t hangText="delivery-method:"> indicates the delivery methods in use, the possible values are: inline, in_band, out_band/specific_name<vspace blankLines="0" />
-Where "specific_name" is the name of the out of band delivery method.
+<t hangText="width:"> Determines the number of pixels per line. This is an integer between 1 and 1048561 and MUST be in multiples of 16.
</t>
<vspace blankLines="1" />
-<t hangText="configuration:"> the <xref target="rfc3548">base16</xref> (hexadecimal) representation of the <xref target="Packed Headers">Packed Headers</xref>.
+<t hangText="height:">Determines the number of lines per frame encoded. This is an integer between 1 and 1048561 and MUST be in multiples of 16.
</t>
-</list>
-</t>
<vspace blankLines="1" />
-<t hangText="Optional Parameters:">
-
-<vspace blankLines="1" />
-
<list style="hanging">
-<t hangText="configuration-uri:"> the URI of the configuration headers in case of out of band transmission. In the form of "protocol://path/to/resource/". Depending on the specific method the single ident packets could be retrived by their number or aggregated in a single stream, aggregates MAY be compressed using <xref target="rfc1952">gzip</xref> or <xref target="BZ2">bzip2</xref> and an <xref target="FIPS180">sha1</xref> checksum MAY be provided in the form of "protocol://path/to/resource/aggregated.bz2!sha1hash"</t>
+<t hangText="configuration-uri:"> the URI of the configuration headers in case
+of out of band transmission. In the form of "protocol://path/to/resource/".
+Depending on the specific method, a single configuration packet could be
+retrived by its number, or multiple packets could be aggregated in a single
+stream. Such aggregates MAY be compressed using either
+<xref target="BZ2">bzip2</xref> or <xref target="rfc1952">gzip</xref>.
+A <xref target="FIPS180">sha1</xref> checksum MAY be provided for aggregates.
+In this latter case the URI will end with the aggregate name, followed by its
+compressed extension if applies, a "!" and the <xref target="rfc3548">base64</xref> representation of the sha1hash of the above mentioned compressed aggregated
+as in: "protocol://path/to/resource/aggregated.bz2!sha1hash".
+The trailing '/' discriminates which of two methods are in use.
+It MUST follow the associated delivery method parameter (either "in_band" or "out_band").
+</t>
</list>
</t>
@@ -840,7 +763,7 @@
<t hangText="Restriction on usage:">
<vspace blankLines="1" />
-This media type depends on RTP framing, and hence is only defined for transfer via <xref target="rfc3550">RTP</xref></t>
+This media type depends on RTP framing, and hence is only defined for transfer via <xref target="RFC3550">RTP</xref></t>
<vspace blankLines="1" />
@@ -849,25 +772,143 @@
<vspace blankLines="1" />
-<t hangText="Change controller:"><vspace blankLines="1"/> IETF AVT Working Group</t>
+<t hangText="Change controller:"><vspace blankLines="1"/>
+IETF AVT Working Group delegated from the IESG
+</t>
<vspace blankLines="1" />
</list>
-<section anchor="Mapping MIME Parameters into SDP" title="Mapping MIME Parameters into SDP">
+<section anchor="Packed Headers IANA Considerations" title="Packed Headers IANA Considerations">
<t>
-The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) <xref target="rfc2327"></xref>, which is commonly used to describe RTP sessions. When SDP is used to specify sessions the mapping are as follows:
+The following IANA considerations MUST only be applied to the packed headers.
</t>
<vspace blankLines="1" />
+
+<list style="hanging">
+<t hangText="Type name:"> video </t>
+
+<vspace blankLines="1" />
+
+<t hangText="Subtype name:"> theora-config </t>
+
+<vspace blankLines="1" />
+
+<t hangText="Required Parameters:">
+<vspace blankLines="1" />
+None
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Optional Parameters:">
+<vspace blankLines="1" />
+None
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Encoding considerations:">
+<vspace blankLines="1" />
+This media type contains binary data.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Security Considerations:">
+<vspace blankLines="1" />
+See Section 6 of RFC XXXX.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Interoperability considerations:">
+<vspace blankLines="1" />
+None
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Published specification:">
+<vspace blankLines="1" />
+RFC XXXX [RFC Editor: please replace by the RFC number of this memo,
+ when published]
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Applications which use this media type:">
+<vspace blankLines="1" />
+Theora encoded video, configuration data.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Additional information:">
+<vspace blankLines="1" />
+None
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Person & email address to contact for further information:">
+<vspace blankLines="1" />
+Luca Barbato: <lu_zero at gentoo.org>
+<vspace blankLines="0" />
+IETF Audio/Video Transport Working Group
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Intended usage:">
+COMMON
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Restriction on usage:">
+<vspace blankLines="1" />
+This media type does not depend on the transport.
+</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Author:">
+<vspace blankLines="1" />
+Luca Barbato</t>
+
+<vspace blankLines="1" />
+
+<t hangText="Change controller:">
+<vspace blankLines="1" />
+IETF AVT Working Group delegated from the IESG</t>
+</list>
+
+</section>
+
+</section>
+
+<section anchor="SDP related considerations" title="SDP related considerations">
+<t>
+The following paragraphs defines the mapping of the parameters described in the IANA considerations section and their usage in the <xref target="rfc3264">Offer/Answer Model</xref>.
+</t>
+
+<section anchor="Mapping Media Type Parameters into SDP" title="Mapping Media Type Parameters into SDP">
+
+<t>
+The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) <xref target="rfc2327"></xref>, which is commonly used to describe RTP sessions. When SDP is used to specify sessions the mapping are as follows:
+</t>
+
+<vspace blankLines="1" />
<list style="symbols">
-<t>The MIME type ("video") goes in SDP "m=" as the media name.</t>
+<t>The type ("video") goes in SDP "m=" as the media name.</t>
<vspace blankLines="1" />
-<t>The MIME subtype ("theora") goes in SDP "a=rtpmap" as the encoding name.</t>
+<t>The subtype ("theora") goes in SDP "a=rtpmap" as the encoding name.</t>
<vspace blankLines="1" />
<t>The clock rate in the "a=rtpmap" line MUST be 90000</t>
@@ -889,24 +930,40 @@
</t>
<section anchor="SDP Example" title="SDP Example">
-<t>The following example shows a basic SDP for a single stream. The first configuration packet is inlined in the sdp, other configurations could be fetched at any time from the first provided uri using or all the known configuration could be downloaded using the second uri. The inline <xref target="rfc3548">base16</xref> configuration string is omitted because of the lenght.</t>
+<t>The following example shows a basic SDP for a single stream. The first configuration packet is inlined in the sdp, other configurations could be fetched at any time from the first provided uri using or all the known configuration could be downloaded using the second uri. The inline <xref target="rfc3548">base64</xref> configuration string is omitted because of the lenght.</t>
<list style="empty">
<t>c=IN IP4 192.0.0.1</t>
-<t>m=video RTP/AVP 98</t>
+<t>m=video RTP/AVP 98</t>
<t>a=rtpmap:98 theora/90000</t>
-<t>a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720; delivery-method=inline; configuration=base16string1; delivery-method=out_band/rtsp; delivery-method=out_band/rtsp; configuration-uri=rtsp://path/to/resource/; delivery-method=out_band/http; configuration-uri=http://another/path/to/resource/aggregate.bz2!sha1hash;</t>
+<t>a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720; delivery-method=inline; configuration=base64string1; delivery-method=out_band/rtsp; delivery-method=out_band/rtsp; configuration-uri=rtsp://path/to/resource/; delivery-method=out_band/http; configuration-uri=http://another/path/to/resource/aggregate.bz2!sha1hash;</t>
</list>
</section>
+<t>
+Note that the payload format (encoding) names are commonly shown in upper case.
+Media Type subtypes are commonly shown in lower case. These names are
+case-insensitive in both places. Similarly, parameter names are
+case-insensitive both in Media Type types and in the default mapping to the SDP
+a=fmtp attribute. The exception regarding case sensitivity is the
+configuration-uri URI which MUST be regarded as being case sensitive. The
+a=fmtp line is a single line even if it is presented broken because of clarity.
+</t>
+
</section>
<section anchor="Usage with the SDP Offer/Answer Mode" title="Usage with the SDP Offer/Answer Model">
<t>
-The offer, as described in <xref target="rfc3264">An Offer/Answer Model Session Description Protocol</xref>, may contain a large number of delivery methods per single fmtp attribute, the answerer MUST remove every delivery-method and configuration-uri not supported. All the parameters MUST not be altered on answer otherwise.
+The only paramenter negotiable is the delivery method. All the others are
+declarative: the offer, as described in <xref target="rfc3264">An Offer/Answer
+Model Session Description Protocol</xref>, may contain a large number of
+delivery methods per single fmtp attribute, the answerer MUST remove every
+delivery-method and configuration-uri not supported. All the parameters MUST
+not be altered on answer otherwise.
</t>
+
</section>
</section>
@@ -938,9 +995,9 @@
<t>On join the client will receive the current Configuration necessary to decode the current streams inlined in the SDP so that the decoding will start immediately after.</t>
-<t>When the streamed content changes the new Configuration is sent in-band before the actual stream, and the Configuration that has to be sent inline in the SDP updated. Since the inline method is unreliable, an out of band fallback is provided.</t>
+<t>When the streamed content changes the new Configuration is sent in-band before the actual stream, and the Configuration that has to be sent inline in the SDP updated. Since the in-band method is unreliable, an out of band fallback is provided.</t>
-<t>The client could choose to fetch the Configuration from the alternate source as soon it discovers a Configuration packet got lost inline or use <xref target="rfc3611">selective retransmission</xref>, if the server supports the feature.</t>
+<t>The client could choose to fetch the Configuration from the alternate source as soon it discovers a Configuration packet got lost in-band or use <xref target="rfc3611">selective retransmission</xref>, if the server supports the feature.</t>
<t>A serverside optimization would be to keep an hash list of the Configurations per session to avoid packing all of them and send the same Configuration with different Ident tags</t>
@@ -952,7 +1009,15 @@
<section anchor="Security Considerations" title="Security Considerations">
<t>
-RTP packets using this payload format are subject to the security considerations discussed in the RTP specification <xref target="rfc3550"></xref>. This implies that the confidentiality of the media stream is achieved by using encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed on the compressed data. Where the size of a data block is set care MUST be taken to prevent buffer overflows in the client applications.
+RTP packets using this payload format are subject to the security
+considerations discussed in the RTP specification
+<xref target="RFC3550"></xref>. This implies that the confidentiality of the
+media stream is achieved by using encryption. Because the data compression used
+with this payload format is applied end-to-end, encryption may be performed on
+the compressed data. Additional care MAY be needed for delivery methods that
+point to external resources, using secure protocols to fetch the configuration
+payloads. Where the size of a data block is set, care MUST be taken to prevent
+buffer overflows in the client applications.
</t>
</section>
@@ -989,27 +1054,9 @@
<seriesInfo name="RFC" value="2119" />
</reference>
-<reference anchor="rfc3550">
-<front>
-<title>RTP: A Transport Protocol for real-time applications</title>
-<author initials="H." surname="Schulzrinne" fullname=""></author>
-<author initials="S." surname="Casner" fullname=""></author>
-<author initials="R." surname="Frederick" fullname=""></author>
-<author initials="V." surname="Jacobson" fullname=""></author>
-</front>
-<seriesInfo name="RFC" value="3550" />
-</reference>
+<?rfc include="reference.RFC.3550" ?>
+<?rfc include="reference.RFC.3551" ?>
-<reference anchor="rfc3551">
-<front>
-<title>RTP Profile for video and Video Conferences with Minimal Control.</title>
-<author initials="H." surname="Schulzrinne" fullname=""></author>
-<author initials="S." surname="Casner" fullname=""></author>
-</front>
-<date month="July" year="2003" />
-<seriesInfo name="RFC" value="3551" />
-</reference>
-
<reference anchor="rfc3264">
<front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
@@ -1056,14 +1103,9 @@
<seriesInfo name="Internet Draft" value="(draft-ietf-avt-rtcp-feedback-11: Work in progress)" />
</reference>
-<reference anchor="vorbisrtp">
-<front>
-<title>RTP Payload Format for Vorbis Encoded Audio - draft-ietf-avt-vorbis-rtp-00</title>
-<author initials="L." surname="Barbato" fullname="Luca Barbato"></author>
-</front>
-<seriesInfo name="Internet Draft" value="(Work in progress)" />
-</reference>
+<?rfc include="reference.RFC.5215" ?>
+
<reference anchor="rfc3548">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
More information about the commits
mailing list