[xiph-commits] r14398 - trunk/vorbis/doc
lu_zero at svn.xiph.org
lu_zero at svn.xiph.org
Mon Jan 14 11:14:25 PST 2008
Author: lu_zero
Date: 2008-01-14 11:14:25 -0800 (Mon, 14 Jan 2008)
New Revision: 14398
Modified:
trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-08.xml
Log:
Initial changes from the confcall
Modified: trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-08.xml
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-08.xml 2008-01-14 12:32:08 UTC (rev 14397)
+++ trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-08.xml 2008-01-14 19:14:25 UTC (rev 14398)
@@ -17,7 +17,7 @@
</address>
</author>
-<date day="05" month="Jan" year="2008" />
+<date day="14" month="Jan" year="2008" />
<area>General</area>
<workgroup>AVT Working Group</workgroup>
@@ -399,14 +399,14 @@
different bitrates of the RTP stream.
</t>
+<!--
<t>
The delivery vectors in use can be specified by an SDP attribute to indicate the
method and the optional URI where the Vorbis
<xref target="Packed Configuration">Packed Configuration</xref> Packets could
-be fetched. Different delivery methods MAY be advertised for the same session.
-The in-band Configuration 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
+be fetched.
+-->
+<t>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>
@@ -426,7 +426,7 @@
sent in-band with the packet type bits set to match the Vorbis Data Type.
Clients MUST be capable of dealing with fragmentation and periodic
<xref target="rfc4588">re-transmission of</xref> the configuration headers.
-The RTP timestamp value MUST reflect the transmission time of the next data packet.
+The RTP timestamp value MUST reflect the transmission time of the first data packet for which this configuration applies.
</t>
<section anchor="Packed Configuration" title="Packed Configuration">
@@ -516,10 +516,8 @@
<section anchor="Out of Band Transmission" title="Out of Band Transmission">
<t>
-This section, as stated above, does not cover all the possible out-of-band
-delivery methods since they rely on different protocols and are linked to
-specific applications. The following packet definition SHOULD be used in
-out-of-band delivery and MUST be used when Configuration is inlined in the SDP.
+The following packet definition MUST be used when Configuration is inlined
+in the SDP.
</t>
<section anchor="Packed Headers" title="Packed Headers">
@@ -529,8 +527,7 @@
data is via a retrieval method that can be performed using a reliable transport
protocol. As the RTP headers are not required for this method of delivery the
structure of the configuration data is slightly different. The packed header
-starts with a 32 bit (network byte ordered) count field which details the number of
-packed headers that are contained in the bundle. Next is the Packed header
+starts with a 32 bit (network byte ordered) count field which details the number of packed headers that are contained in the bundle. Next is the Packed header
payload for each chained Vorbis stream.
</t>
@@ -663,8 +660,8 @@
Vorbis packet will have the Fragment type set to 3. To maintain the correct
sequence for fragmented packet reception the timestamp field of fragmented
packets MUST be the same as the first packet sent, with the sequence number
-incremented as normal for the subsequent RTP payloads, this will affect the RTCP jitter measurement. The length field shows
-the fragment length.
+incremented as normal for the subsequent RTP payloads, this will affect the
+RTCP jitter measurement. The length field shows the fragment length.
</t>
<section anchor="Example Fragmented Vorbis Packet" title="Example Fragmented Vorbis Packet">
@@ -822,36 +819,13 @@
<vspace blankLines="1" />
-<t hangText="delivery-method:"> indicates the delivery methods in use, the possible values are: inline, in_band, out_band. The parameter MAY be included multiple time, followed by the configuration or configuration-uri parameter associated.
+<t hangText="configuration:"> the <xref target="rfc3548">base64</xref> representation of the <xref target="Packed Headers">Packed Headers</xref>.
</t>
-
-<vspace blankLines="1" />
-
-<t hangText="configuration:"> the <xref target="rfc3548">base64</xref> representation of the <xref target="Packed Headers">Packed Headers</xref>. It MUST follow the associated delivery-method parameter ("inline").
-</t>
</list>
</t>
<vspace blankLines="1" />
-<t hangText="Optional parameters:">
-
-<vspace blankLines="1" />
-
-<list style="hanging">
-<t hangText="configuration-uri:"> the <xref target="rfc3986">URI</xref> of
-the configuration headers in case of out of band transmission.
-In the form of "scheme://path/to/resource/", depending on the specific
-method, a single configuration packet could be retrived by its Ident number, or
-multiple packets could be aggregated in a single stream.
-Non hierarchical protocols MAY point to a resource using their specific
-syntax.
-</t>
-</list>
-</t>
-
-<vspace blankLines="1" />
-
<t hangText="Encoding considerations:">
<vspace blankLines="1" />
This media type is framed and contains binary data.
@@ -928,7 +902,7 @@
<section anchor="Packed Headers IANA Considerations" title="Packed Headers IANA Considerations">
<t>
-The following IANA considerations MUST only be applied to the <xref target="Packed Headers">Packed Headers</xref>.
+The following IANA considerations refers to the split configuration <xref target="Packed Headers">Packed Headers</xref> used within RFC XXXX.
</t>
<vspace blankLines="1" />
@@ -1038,7 +1012,7 @@
<section anchor="SDP related considerations" title="SDP related considerations">
<t>
-The following paragraphs define the mapping of the parameters described in the IANA considerations section and their usage in the <xref target="rfc3264">Offer/Answer Model</xref>.
+The following paragraphs define the mapping of the parameters described in the IANA considerations section and their usage in the <xref target="rfc3264">Offer/Answer Model</xref>. In order to be forward compatible the implementation MUST ignore unknown parameters.
</t>
<section anchor="Mapping Media Type Parameters into SDP" title="Mapping Media Type Parameters into SDP">
@@ -1065,13 +1039,10 @@
<t>The parameter "channels" also goes in "a=rtpmap" as channel count.</t>
<vspace blankLines="1" />
-<t>The mandated parameters "delivery-method" and "configuration" MUST be
-included in the SDP "a=fmtp" attribute.</t>
+<t>The mandated parameters "configuration" MUST be included in the SDP
+"a=fmtp" attribute.</t>
<vspace blankLines="1" />
-<t>The optional parameter "configuration-uri", when present, MUST be included
-in the SDP "a=fmtp" attribute and MUST follow the delivery-method that applies.</t>
-
</list>
<t>
@@ -1081,18 +1052,12 @@
</t>
<t>
-The URI specified in the configuration-uri attribute MUST point to a location
-where all of the Configuration Packets needed for the life of the session
-reside.
-</t>
-
-<t>
The port value is specified by the server application bound to the address
specified in the c= line. The sample rate and channel count value specified
in the rtpmap attribute SHOULD match the current Vorbis stream or considered
the maximum number of channels to be expected and the least common multiple
-for the session. The Configuration payload delivers the exact information,
-thus the SDP information SHOULD be considered as a hint.
+sample rate for the session. The Configuration payload delivers the exact
+information, thus the SDP information SHOULD be considered as a hint.
An example is found below.
</t>
@@ -1107,20 +1072,16 @@
<t>c=IN IP4 192.0.2.1</t>
<t>m=audio RTP/AVP 98</t>
<t>a=rtpmap:98 vorbis/44100/2</t>
-<t>a=fmtp:98 delivery-method=inline; configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...; delivery-method=out_band; configuration-uri=rtsp://path/to/the/resource; delivery-method=out_band; configuration-uri=http://another/path/to/resource/;</t>
+<t>a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...;</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 shown as multiple lines in this
-document for clarity.
+a=fmtp attribute. The a=fmtp line is a single line even if it is shown as multiple lines in this document for clarity.
</t>
</section>
@@ -1128,18 +1089,19 @@
<section anchor="Usage with the SDP Offer/Answer Mode" title="Usage with the SDP Offer/Answer Model">
<t>
-The only parameter 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.
+The are no negotiable parameters. All the of them are declarative.
</t>
</section>
</section>
-
+<section anchor="Congestion Control" title="Congestion Control">
+<t>
+ Vorbis clients SHOULD send regular receiver reports detailing
+ congestion. A way to handle bandwidth changes MAY be redirect
+ the client to a lower bitrate stream if one is available.
+</t>
+</section>
<section anchor="Example" title="Example">
<t>
@@ -1193,10 +1155,7 @@
Among other considerations, this implies that the confidentiality of the
media stream is archieved 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.
+the compressed data.
</t>
</section>
More information about the commits
mailing list