3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9
- 3.2. Packed Headers Delivery . . . . . . . . . . . . . . . . . 10
- 3.2.1. Packed Headers IANA Considerations . . . . . . . . . . 11
+ 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 10
+ 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 10
3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 12
4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 12
5. Frame Packetizing . . . . . . . . . . . . . . . . . . . . . . 13
- 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 13
+ 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 14
5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
- Intellectual Property and Copyright Statements . . . . . . . . . . 24
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ Intellectual Property and Copyright Statements . . . . . . . . . . 23
requirement poses problems in RTP, which is often used over
unreliable transports.
- Since this information must be transmitted reliably, and as the RTP
- stream may change certain configuration data mid-session there are
+ Since this information must be transmitted reliably and, as the RTP
+ stream may change certain configuration data mid-session, there are
different methods for delivering this configuration data to a client,
both in-band and out-of-band which is detailed below. SDP delivery
is used to setup an initial state for the client application. The
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 0 | 1 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Setup length | Identification ..
+ | length | Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
set to 0 since the packet bears the full Packed configuration, the
number of packet is set to 1.
-3.2. Packed Headers Delivery
+3.2. Out of Band Transmission
+
+ This section, as stated before, won't cover all the possible out-of-
+ band delivery methods since they rely to different protocols and be
+ linked to a specific application. The following packet definition
+ SHOULD be used in out-of-band delivery and MUST be used when
+ Configuration is inlined in the SDP.
+
+3.2.1. Packed Headers
As mentioned above the RECOMMENDED delivery vector for Vorbis
configuration data is via a retrieval method that can be performed
Figure 7: Packed Headers Overview
Since the Configuration Ident and the Identification Header are fixed
- length there is only a 2 byte Setup Length tag to define the length
- of the Setup header.
+ length there is only a 2 byte length tag to define the length of the
+ packed headers.
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires April 18, 2006 [Page 10]
+\f
+Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Length | Identification Header ..
+ .. length | Identification Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Packed Headers Detail
+ The key difference between the in-band format and this one, is there
+ is no need for the payload header octet.
-
-
-Barbato Expires April 18, 2006 [Page 10]
-\f
-Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
-
-
- The key difference between the in-band format is there is no need for
- the payload header octet.
-
-3.2.1. Packed Headers IANA Considerations
+3.2.1.1. Packed Headers IANA Considerations
The following IANA considerations MUST only be applied to the packed
headers.
Published specification:
+
+
+Barbato Expires April 18, 2006 [Page 11]
+\f
+Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
+
+
See RFC XXXX for details.
Applications which use this media type:
Author/Change controller:
-
-
-Barbato Expires April 18, 2006 [Page 11]
-\f
-Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
-
-
Author: Luca Barbato
Change controller: IETF AVT Working Group
completely. The details on the format of the comments can be found
in the Vorbis documentation [12].
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires April 18, 2006 [Page 12]
+\f
+Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
+
+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Comment Packet
-
-
-
-Barbato Expires April 18, 2006 [Page 12]
-\f
-Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
-
-
The 2 bytes length field is necessary since this packet could be
fragmented.
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 packets.
-
-5.1. Example Fragmented Vorbis Packet
-
- Here is an example fragmented Vorbis packet split over three RTP
- packets. Each packet contains the standard RTP headers as well as
- the 4 octet Vorbis headers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+ number incremented as normal for the subsequent RTP packets. The
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
+ length field shows the fragment length.
+
+5.1. Example Fragmented Vorbis Packet
+
+ Here is an example fragmented Vorbis packet split over three RTP
+ packets. Each packet contains the standard RTP headers as well as
+ the 4 octet Vorbis headers.
+
Packet 1:
0 1 2 3
-
-
-
-
-
-
-
-
Barbato Expires April 18, 2006 [Page 14]
\f
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
values are:inline, in_band, out_band
configuration: the base16 [9] (hexadecimal) representation of the
- Packed Headers (Section 3.2).
+ Packed Headers (Section 3.2.1).
Optional Parameters:
specified in the rtpmap attribute MUST match the Vorbis sample rate
value. An example is found below.
-
+ The answer to any offer, [8], MUST NOT change the URI specified in
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
+ the configuration-uri attribute. The Configuration inlined in the
+ configuration parameter COULD change.
+
c=IN IP4/6
m=audio RTP/AVP 98
a=rtpmap:98 VORBIS/44100/2
sensitivity is the configuration-uri URI which MUST be regarded as
being case sensitive.
- The answer to any offer, [8], MUST NOT change the URI specified in
- the configuration-uri attribute. The Configuration inlined in the
- configuration parameter COULD change.
-
7. Congestion Control
The content itself could be a mix of live stream as the dj's speech
and stored streams as the music she plays.
+ In this situation we don't know in advance how many codebooks we will
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
- In this situation we don't know in advance how many codebooks we will
use and. The clients can join anytime and users expect to start
listening to the content in a short time
Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David
Barrett, Silvia Pfeiffer, Politecnico di Torino (LS)^3/IMG Group in
particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini,
+ Juan Carlos De Martin.
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
- Juan Carlos De Martin.
-
-
11. References
11.1. Normative References
Available from the Xiph website, http://www.xiph.org".
[13] "Ogg Vorbis I specification: Comment field and header
-
-
-
-Barbato Expires April 18, 2006 [Page 21]
-\f
-Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
-
-
specification. Available from the Xiph website,
http://www.xiph.org".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barbato Expires April 18, 2006 [Page 22]
+Barbato Expires April 18, 2006 [Page 21]
\f
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
-Barbato Expires April 18, 2006 [Page 23]
+Barbato Expires April 18, 2006 [Page 22]
\f
Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
-Barbato Expires April 18, 2006 [Page 24]
+Barbato Expires April 18, 2006 [Page 23]
\f
</t>
<t>
-Since this information must be transmitted reliably, and as the RTP
-stream may change certain configuration data mid-session there are
+Since this information must be transmitted reliably and, as the RTP
+stream may change certain configuration data mid-session, there are
different methods for delivering this configuration data to a
client, both in-band and out-of-band which is detailed below. SDP
delivery is used to setup an initial state for the client application.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 0 | 1 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Setup length | Identification ..
+ | length | Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>The Ident field is set with the value that will be used by the Raw Payload Packets to address this Configuration. The Fragment type is set to 0 since the packet bears the full Packed configuration, the number of packet is set to 1.</t>
</section>
+</section>
+<section anchor="Out of Band Transmission" title="Out of Band Transmission">
-</section>
-<section anchor="Packed Headers Delivery" title="Packed Headers Delivery">
+<t>
+This section, as stated before, won't cover all the possible out-of-band delivery methods since they rely to different protocols and be linked to a specific application. The following packet definition SHOULD be used in out-of-band delivery and MUST be used when Configuration is inlined in the SDP.
+</t>
+
+<section anchor="Packed Headers" title="Packed Headers">
<t>
As mentioned above the RECOMMENDED delivery vector for Vorbis configuration 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 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.
</figure>
<t>
-Since the Configuration Ident and the Identification Header are fixed length there is only a 2 byte Setup Length tag to define the length of the Setup header.
+Since the Configuration Ident and the Identification Header are fixed length there is only a 2 byte length tag to define the length of the packed headers.
</t>
<figure anchor="Packed Headers Detail Figure" title="Packed Headers Detail">
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Length | Identification Header ..
+ .. length | Identification Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
-The key difference between the in-band format is there is no need for the payload header octet.
+The key difference between the in-band format and this one, is there is no need for the payload header octet.
</t>
<section anchor="Packed Headers IANA Considerations" title="Packed Headers IANA Considerations">
</section>
</section>
-
-<!--<section anchor="Out-of-band Header Transmission" title="Out-of-band Header Transmission">
-
-<t>
-
-</t>
-
-</section>-->
+</section>
<section anchor="Loss of Configuration Headers" title="Loss of Configuration Headers">
</t>
<t>
-If a Vorbis packet, not only data but also Configuration and Comment, is larger than 65535 octets it MUST be fragmented. A fragmented packet has a zero in the last four bits of the payload header. The first fragment will set the Fragment type to 1. Each fragment after the first will set the Fragment type to 2 in the payload header. The RTP packet containing the last fragment of the 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 packets.
+If a Vorbis packet, not only data but also Configuration and Comment, is larger than 65535 octets it MUST be fragmented. A fragmented packet has a zero in the last four bits of the payload header. The first fragment will set the Fragment type to 1. Each fragment after the first will set the Fragment type to 2 in the payload header. The RTP packet containing the last fragment of the 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 packets. The length field shows the fragment length.
</t>
<section anchor="Example Fragmented Vorbis Packet" title="Example Fragmented Vorbis Packet">
<t>
delivery-method: indicates the delivery methods in use, the possible values are:inline, in_band, out_band
</t><t>
-configuration: the <xref target="rfc3548">base16</xref> (hexadecimal) representation of the <xref target="Packed Headers Delivery">Packed Headers</xref>.
+configuration: the <xref target="rfc3548">base16</xref> (hexadecimal) representation of the <xref target="Packed Headers">Packed Headers</xref>.
</t>
<t>
The port value is specified by the server application bound to the address specified in the c attribute. The bitrate value and channels specified in the rtpmap attribute MUST match the Vorbis sample rate value. An example is found below.
</t>
+<t>
+The answer to any offer, <xref target="rfc3264"></xref>, MUST NOT change the URI specified in the configuration-uri attribute. The Configuration inlined in the configuration parameter COULD change.
+</t>
+
<vspace blankLines="1" />
<list style="empty">
<t>c=IN IP4/6 </t>
Note that the payload format (encoding) names are commonly shown in upper case. MIME subtypes are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in MIME 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.
</t>
-<t>
-The answer to any offer, <xref target="rfc3264"></xref>, MUST NOT change the URI specified in the configuration-uri attribute. The Configuration inlined in the configuration parameter COULD change.
-</t>
-
</section>
</section>
projects / platform / upstream / libvorbis.git / commitdiff