Mercurial > hg > sv-dependency-builds
diff src/libvorbis-1.3.3/doc/rfc5215.txt @ 1:05aa0afa9217
Bring in flac, ogg, vorbis
| author | Chris Cannam |
|---|---|
| date | Tue, 19 Mar 2013 17:37:49 +0000 |
| parents | |
| children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/libvorbis-1.3.3/doc/rfc5215.txt Tue Mar 19 17:37:49 2013 +0000 @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group L. Barbato +Request for Comments: 5215 Xiph +Category: Standards Track August 2008 + + + RTP Payload Format for Vorbis Encoded Audio + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes an RTP payload format for transporting Vorbis + encoded audio. It details the RTP encapsulation mechanism for raw + Vorbis data and the delivery mechanisms for the decoder probability + model (referred to as a codebook), as well as other setup + information. + + Also included within this memo are media type registrations and the + details necessary for the use of Vorbis with the Session Description + Protocol (SDP). + + + + + + + + + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 1] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Conformance and Document Conventions . . . . . . . . . . . 3 + 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 8 + 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8 + 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9 + 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 10 + 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 12 + 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 12 + 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13 + 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13 + 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 14 + 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15 + 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 19 + 7. SDP Related Considerations . . . . . . . . . . . . . . . . . . 20 + 7.1. Mapping Media Type Parameters into SDP . . . . . . . . . . 20 + 7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 21 + 7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 22 + 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22 + 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 23 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 2] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +1. Introduction + + Vorbis is a general purpose perceptual audio codec intended to allow + maximum encoder flexibility, thus allowing it to scale competitively + over an exceptionally wide range of bit rates. At the high quality/ + bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is + in the same league as MPEG-4 AAC. Vorbis is also intended for lower + and higher sample rates (from 8kHz telephony to 192kHz digital + masters) and a range of channel representations (monaural, + polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 + discrete channels). + + Vorbis encoded audio is generally encapsulated within an Ogg format + bitstream [RFC3533], which provides framing and synchronization. For + the purposes of RTP transport, this layer is unnecessary, and so raw + Vorbis packets are used in the payload. + +1.1. Conformance and Document Conventions + + 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, [RFC2119] and + indicate requirement levels for compliant implementations. + Requirements apply to all implementations unless otherwise stated. + + 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. + + 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". + +2. Payload Format + + For RTP-based transport of Vorbis-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 Vorbis data with + its associated decoding codebooks as well as indicate if the + following packet contains fragmented Vorbis data and/or the number of + whole Vorbis data frames. The payload data contains the raw Vorbis + bitstream information. There are 3 types of Vorbis data; an RTP + payload MUST contain just one of them at a time. + + + + + +Barbato Standards Track [Page 3] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +2.1. RTP Header + + The format of the RTP header is specified in [RFC3550] and shown in + Figure 1. This payload format uses the fields of the header in a + manner consistent with that specification. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |V=2|P|X| CC |M| PT | sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | timestamp | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | synchronization source (SSRC) identifier | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + | contributing source (CSRC) identifiers | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: RTP Header + + The RTP header begins with an octet of fields (V, P, X, and CC) to + support specialized RTP uses (see [RFC3550] and [RFC3551] for + details). For Vorbis RTP, the following values are used. + + Version (V): 2 bits + + This field identifies the version of RTP. The version used by this + specification is two (2). + + Padding (P): 1 bit + + Padding MAY be used with this payload format according to Section 5.1 + of [RFC3550]. + + Extension (X): 1 bit + + The Extension bit is used in accordance with [RFC3550]. + + CSRC count (CC): 4 bits + + The CSRC count is used in accordance with [RFC3550]. + + Marker (M): 1 bit + + Set to zero. Audio silence suppression is not used. This conforms + to Section 4.1 of [VORBIS-SPEC-REF]. + + + + +Barbato Standards Track [Page 4] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + Payload Type (PT): 7 bits + + An RTP profile for a class of applications is expected to assign a + payload type for this format, or a dynamically allocated payload type + SHOULD be chosen that designates the payload as Vorbis. + + Sequence number: 16 bits + + 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 + the packet sequence. This field is detailed further in [RFC3550]. + + Timestamp: 32 bits + + A timestamp representing the sampling time of the first sample of the + first Vorbis packet in the RTP payload. The clock frequency MUST be + set to the sample rate of the encoded audio data and is conveyed out- + of-band (e.g., as an SDP parameter). + + SSRC/CSRC identifiers: + + These two fields, 32 bits each with one SSRC field and a maximum of + 16 CSRC fields, are as defined in [RFC3550]. + +2.2. Payload Header + + 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. + + 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 | F |VDT|# pkts.| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Payload Header + + Ident: 24 bits + + This 24-bit field is used to associate the Vorbis data to a decoding + Configuration. It is stored as a network byte order integer. + + Fragment type (F): 2 bits + + + + + + + +Barbato Standards Track [Page 5] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + This field is set according to the following list: + + 0 = Not Fragmented + + 1 = Start Fragment + + 2 = Continuation Fragment + + 3 = End Fragment + + Vorbis Data Type (VDT): 2 bits + + This field specifies the kind of Vorbis data stored in this RTP + packet. There are currently three different types of Vorbis + payloads. Each packet MUST contain only a single type of Vorbis + packet (e.g., you must not aggregate configuration and comment + packets in the same RTP payload). + + 0 = Raw Vorbis payload + + 1 = Vorbis Packed Configuration payload + + 2 = Legacy Vorbis Comment payload + + 3 = Reserved + + The packets with a VDT of value 3 MUST be ignored. + + The last 4 bits represent the number of complete packets in this + payload. This provides for a maximum number of 15 Vorbis packets in + the payload. If the payload contains fragmented data, the number of + packets MUST be set to 0. + +2.3. Payload Data + + Raw Vorbis packets are currently unbounded in length; application + profiles will likely define a practical limit. Typical Vorbis packet + sizes range from very small (2-3 bytes) to quite large (8-12 + kilobytes). The reference implementation [LIBVORBIS] typically + produces packets less than ~800 bytes, except for the setup header + packets, which are ~4-12 kilobytes. Within an RTP context, to avoid + fragmentation, the Vorbis data packet size SHOULD be kept + sufficiently small so that after adding the RTP and payload headers, + the complete RTP packet is smaller than the path MTU. + + + + + + + +Barbato Standards Track [Page 6] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | length | vorbis packet data .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Payload Data Header + + Each Vorbis payload packet starts with a two octet length header, + which is used to represent the size in bytes of the following data + payload, and is followed by the raw Vorbis data padded to the nearest + byte boundary, as explained by the Vorbis I Specification + [VORBIS-SPEC-REF]. The length value is stored as a network byte + order integer. + + For payloads that consist of multiple Vorbis packets, the payload + data consists of the packet length followed by the packet data for + each of the Vorbis packets in the payload. + + The Vorbis packet length header is the length of the Vorbis data + block only and does not include the length field. + + The payload packing of the Vorbis data packets MUST follow the + guidelines set out in [RFC3551], where the oldest Vorbis packet + occurs immediately after the RTP packet header. Subsequent Vorbis + packets, if any, MUST follow in temporal order. + + Audio channel mapping is in accordance with the Vorbis I + Specification [VORBIS-SPEC-REF]. + + + + + + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 7] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +2.4. Example RTP Packet + + Here is an example RTP payload containing two Vorbis packets. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 |0|0| 0 |0| PT | sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | timestamp (in sample rate units) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | synchronisation source (SSRC) identifier | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + | contributing source (CSRC) identifiers | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ident | 0 | 0 | 2 pks | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | length | vorbis data .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. vorbis data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | length | next vorbis packet data .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. vorbis data .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. vorbis data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: Example Raw Vorbis Packet + + The payload data section of the RTP packet begins with the 24-bit + Ident field followed by the one octet bit field header, which has the + number of Vorbis frames set to 2. Each of the Vorbis data frames is + prefixed by the two octets length field. The Packet Type and + Fragment Type are set to 0. The Configuration that will be used to + decode the packets is the one indexed by the ident value. + +3. Configuration Headers + + Unlike other mainstream audio codecs, Vorbis has no statically + configured probability model. Instead, it packs all entropy decoding + configuration, Vector Quantization and Huffman models into a data + block that must be transmitted to the decoder with the compressed + data. A decoder also requires information detailing the number of + audio channels, bitrates, and similar information to configure itself + for a particular compressed data stream. These two blocks of + + + +Barbato Standards Track [Page 8] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + information are often referred to collectively as the "codebooks" for + a Vorbis stream, and are included as special "header" packets at the + start of the compressed data. In addition, the Vorbis I + specification [VORBIS-SPEC-REF] requires the presence of a comment + header packet that gives simple metadata about the stream, but this + information is not required for decoding the frame sequence. + + Thus, these two codebook header packets must be received by the + decoder before any audio data can be interpreted. These requirements + pose 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 + different methods for delivering this configuration data to a client, + both in-band and out-of-band, which are detailed below. In order to + set up an initial state for the client application, the configuration + MUST be conveyed via the signalling channel used to set up the + session. One example of such signalling is SDP [RFC4566] with the + Offer/Answer Model [RFC3264]. Changes to the configuration MAY be + communicated via a re-invite, conveying a new SDP, or sent in-band in + the RTP channel. Implementations MUST support an in-band delivery of + updated codebooks, and SHOULD support out-of-band codebook update + using a new SDP file. The changes may be due to different codebooks + as well as different bitrates of the RTP stream. + + For non-chained streams, the recommended Configuration delivery + method is inside the Packed Configuration (Section 3.1.1) in the SDP + as explained the Mapping Media Type Parameters into SDP + (Section 7.1). + + The 24-bit Ident field is used to map which Configuration will be + used to decode a packet. When the Ident field changes, it indicates + that a change in the stream has taken place. The client application + MUST have in advance the correct configuration. If the client + detects a change in the Ident value and does not have this + information, it MUST NOT decode the raw associated Vorbis data until + it fetches the correct Configuration. + +3.1. In-band Header Transmission + + The Packed Configuration (Section 3.1.1) Payload is 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 re-transmission + of [RFC4588] the configuration headers. The RTP timestamp value MUST + reflect the transmission time of the first data packet for which this + configuration applies. + + + + + +Barbato Standards Track [Page 9] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +3.1.1. Packed Configuration + + A Vorbis Packed Configuration is indicated with the Vorbis Data Type + field set to 1. Of the three headers defined in the Vorbis I + specification [VORBIS-SPEC-REF], the Identification and the Setup + MUST be packed as they are, while the Comment header MAY be replaced + with a dummy one. + + The packed configuration stores Xiph codec configurations in a + generic way: the first field stores the number of the following + packets minus one (count field), the next ones represent the size of + the headers (length fields), and the headers immediately follow the + list of length fields. The size of the last header is implicit. + + The count and the length fields are encoded using the following + logic: the data is in network byte order; every byte has the most + significant bit used as a flag, and the following 7 bits are used to + store the value. The first 7 most significant bits are stored in the + first byte. If there are remaining bits, the flag bit is set to 1 + and the subsequent 7 bits are stored in the following byte. If there + are remaining bits, set the flag to 1 and the same procedure is + repeated. The ending byte has the flag bit set to 0. To decode, + simply iterate over the bytes until the flag bit is set to 0. For + every byte, the data is added to the accumulated value multiplied by + 128. + + The headers are packed in the same order as they are present in Ogg + [VORBIS-SPEC-REF]: Identification, Comment, Setup. + + The 2 byte length tag defines the length of the packed headers as the + sum of the Configuration, Comment, and Setup lengths. + + + + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 10] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |V=2|P|X| CC |M| PT | xxxx | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | xxxxx | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | synchronization source (SSRC) identifier | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + | contributing source (CSRC) identifiers | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ident | 0 | 1 | 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | length | n. of headers | length1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | length2 | Identification .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Identification .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Identification .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Identification .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Identification | Comment .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Comment .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Comment .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Comment .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Comment | Setup .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Setup .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Setup .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Packed Configuration Figure + + 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 because the packet bears the full Packed configuration. The + number of the packet is set to 1. + + + + + +Barbato Standards Track [Page 11] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +3.2. Out of Band Transmission + + The following packet definition MUST be used when Configuration is + inside 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 + 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. The + following shows the Packed header payload for each chained Vorbis + stream. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Number of packed headers | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packed header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packed header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: Packed Headers Overview + + + + + + + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 12] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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 .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. | n. of headers | length1 | length2 .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. | Identification Header .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ................................................................. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. | Comment Header .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ................................................................. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Comment Header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Setup Header .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ................................................................. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Setup Header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: Packed Headers Detail + + The key difference between the in-band format and this one is that + there is no need for the payload header octet. In this figure, the + comment has a size bigger than 127 bytes. + +3.3. Loss of Configuration Headers + + Unlike the loss of raw Vorbis payload data, loss of a configuration + header leads to a situation where it will not be possible to + successfully decode the stream. Implementations MAY try to recover + from an error by requesting again the missing Configuration or, if + the delivery method is in-band, by buffering the payloads waiting for + the Configuration needed to decode them. The baseline reaction + SHOULD either be reset or end the RTP session. + +4. Comment Headers + + Vorbis Data Type flag set to 2 indicates that the packet contains the + comment metadata, such as artist name, track title, and so on. These + metadata messages are not intended to be fully descriptive but rather + to offer basic track/song information. Clients MAY ignore it + completely. The details on the format of the comments can be found + in the Vorbis I Specification [VORBIS-SPEC-REF]. + + + +Barbato Standards Track [Page 13] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |V=2|P|X| CC |M| PT | xxxx | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | xxxxx | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | synchronization source (SSRC) identifier | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + | contributing source (CSRC) identifiers | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ident | 0 | 2 | 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | length | Comment .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Comment .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. Comment | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: Comment Packet + + The 2-byte length field is necessary since this packet could be + fragmented. + +5. Frame Packetization + + Each RTP payload contains either one Vorbis packet fragment or an + integer number of complete Vorbis packets (up to a maximum of 15 + packets, since the number of packets is defined by a 4-bit value). + + Any Vorbis data packet that is less than path MTU SHOULD be bundled + in the RTP payload with as many Vorbis packets as will fit, up to a + maximum of 15, except when such bundling would exceed an + application's desired transmission latency. Path MTU is detailed in + [RFC1191] and [RFC1981]. + + 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 consecutive fragments MUST be sent without any + other payload being sent between the first and the last fragment. + The RTP payload 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 + + + +Barbato Standards Track [Page 14] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + 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. + +5.1. Example Fragmented Vorbis Packet + + Here is an example of a fragmented Vorbis packet split over three RTP + payloads. Each of them contains the standard RTP headers as well as + the 4-octet Vorbis headers. + + Packet 1: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |V=2|P|X| CC |M| PT | 1000 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 12345 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | synchronization source (SSRC) identifier | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + | contributing source (CSRC) identifiers | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ident | 1 | 0 | 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | length | vorbis data .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. vorbis data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9: Example Fragmented Packet (Packet 1) + + In this payload, the initial sequence number is 1000 and the + timestamp is 12345. The Fragment type is set to 1, the number of + packets field is set to 0, and as the payload is raw Vorbis data, the + VDT field is set to 0. + + + + + + + + + + + + + +Barbato Standards Track [Page 15] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + Packet 2: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |V=2|P|X| CC |M| PT | 1001 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 12345 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | synchronization source (SSRC) identifier | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + | contributing source (CSRC) identifiers | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ident | 2 | 0 | 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | length | vorbis data .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. vorbis data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 10: Example Fragmented Packet (Packet 2) + + The Fragment type field is set to 2, and the number of packets field + is set to 0. For large Vorbis fragments, there can be several of + these types of payloads. The maximum packet size SHOULD be no + greater than the path MTU, including all RTP and payload headers. + The sequence number has been incremented by one, but the timestamp + field remains the same as the initial payload. + + + + + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 16] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + Packet 3: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |V=2|P|X| CC |M| PT | 1002 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 12345 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | synchronization source (SSRC) identifier | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + | contributing source (CSRC) identifiers | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ident | 3 | 0 | 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | length | vorbis data .. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + .. vorbis data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 11: Example Fragmented Packet (Packet 3) + + This is the last Vorbis fragment payload. The Fragment type is set + to 3 and the packet count remains set to 0. As in the previous + payloads, the timestamp remains set to the first payload timestamp in + the sequence and the sequence number has been incremented. + +5.2. Packet Loss + + As there is no error correction within the Vorbis stream, packet loss + will result in a loss of signal. Packet loss is more of an issue for + fragmented Vorbis packets as the client will have to cope with the + handling of the Fragment Type. In case of loss of fragments, the + client MUST discard all the remaining Vorbis fragments and decode the + incomplete packet. If we use the fragmented Vorbis packet example + above and the first RTP payload is lost, the client MUST detect that + the next RTP payload has the packet count field set to 0 and the + Fragment type 2 and MUST drop it. The next RTP payload, which is the + final fragmented packet, MUST be dropped in the same manner. If the + missing RTP payload is the last, the two fragments received will be + kept and the incomplete Vorbis packet decoded. + + Loss of any of the Configuration fragment will result in the loss of + the full Configuration packet with the result detailed in the Loss of + Configuration Headers (Section 3.3) section. + + + + +Barbato Standards Track [Page 17] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +6. IANA Considerations + + Type name: audio + + Subtype name: vorbis + + Required parameters: + + rate: indicates the RTP timestamp clock rate as described in RTP + Profile for Audio and Video Conferences with Minimal Control + [RFC3551]. + + channels: indicates the number of audio channels as described in + RTP Profile for Audio and Video Conferences with Minimal + Control [RFC3551]. + + configuration: the base64 [RFC4648] representation of the Packed + Headers (Section 3.2.1). + + Encoding considerations: + + This media type is framed and contains binary data. + + Security considerations: + + See Section 10 of RFC 5215. + + Interoperability considerations: + + None + + Published specification: + + RFC 5215 + + Ogg Vorbis I specification: Codec setup and packet decode. + Available from the Xiph website, http://xiph.org/ + + Applications which use this media type: + + Audio streaming and conferencing tools + + Additional information: + + None + + + + + + +Barbato Standards Track [Page 18] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + Person & email address to contact for further information: + + Luca Barbato: <lu_zero@gentoo.org> + IETF Audio/Video Transport Working Group + + Intended usage: + + COMMON + + Restriction on usage: + + This media type depends on RTP framing, hence is only defined for + transfer via RTP [RFC3550]. + + Author: + + Luca Barbato + + Change controller: + + IETF AVT Working Group delegated from the IESG + +6.1. Packed Headers IANA Considerations + + The following IANA considerations refers to the split configuration + Packed Headers (Section 3.2.1) used within RFC 5215. + + Type name: audio + + Subtype name: vorbis-config + + Required parameters: + + None + + Optional parameters: + + None + + Encoding considerations: + + This media type contains binary data. + + Security considerations: + + See Section 10 of RFC 5215. + + + + + +Barbato Standards Track [Page 19] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + Interoperability considerations: + + None + + Published specification: + + RFC 5215 + + Applications which use this media type: + + Vorbis encoded audio, configuration data + + Additional information: + + None + + Person & email address to contact for further information: + + Luca Barbato: <lu_zero@gentoo.org> + IETF Audio/Video Transport Working Group + + Intended usage: COMMON + + Restriction on usage: + + This media type doesn't depend on the transport. + + Author: + + Luca Barbato + + Change controller: + + IETF AVT Working Group delegated from the IESG + +7. SDP Related Considerations + + The following paragraphs define the mapping of the parameters + described in the IANA considerations section and their usage in the + Offer/Answer Model [RFC3264]. In order to be forward compatible, the + implementation MUST ignore unknown parameters. + +7.1. Mapping Media Type Parameters into SDP + + The information carried in the Media Type specification has a + specific mapping to fields in the Session Description Protocol (SDP) + [RFC4566], which is commonly used to describe RTP sessions. When SDP + is used to specify sessions, the mapping are as follows: + + + +Barbato Standards Track [Page 20] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + o The type name ("audio") goes in SDP "m=" as the media name. + + o The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding + name. + + o The parameter "rate" also goes in "a=rtpmap" as the clock rate. + + o The parameter "channels" also goes in "a=rtpmap" as the channel + count. + + o The mandated parameters "configuration" MUST be included in the + SDP "a=fmtp" attribute. + + If the stream comprises chained Vorbis files and all of them are + known in advance, the Configuration Packet for each file SHOULD be + passed to the client using the configuration attribute. + + The port value is specified by the server application bound to the + address specified in the c= line. The channel count value specified + in the rtpmap attribute SHOULD match the current Vorbis stream or + should be considered the maximum number of channels to be expected. + The timestamp clock rate MUST be a multiple of the sample rate; a + different payload number MUST be used if the clock rate changes. The + Configuration payload delivers the exact information, thus the SDP + information SHOULD be considered a hint. An example is found below. + +7.1.1. SDP Example + + The following example shows a basic SDP single stream. The first + configuration packet is inside the SDP; other configurations could be + fetched at any time from the URIs provided. The following base64 + [RFC4648] configuration string is folded in this example due to RFC + line length limitations. + + c=IN IP4 192.0.2.1 + + m=audio RTP/AVP 98 + + a=rtpmap:98 vorbis/44100/2 + + a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...; + + Note that the payload format (encoding) names are commonly shown in + uppercase. Media Type subtypes are commonly shown in lowercase. + 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 a=fmtp line is + + + + +Barbato Standards Track [Page 21] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + a single line, even if it is shown as multiple lines in this document + for clarity. + +7.2. Usage with the SDP Offer/Answer Model + + There are no negotiable parameters. All of them are declarative. + +8. Congestion Control + + The general congestion control considerations for transporting RTP + data apply to Vorbis audio over RTP as well. See the RTP + specification [RFC3550] and any applicable RTP profile (e.g., + [RFC3551]). Audio data can be encoded using a range of different bit + rates, so it is possible to adapt network bandwidth by adjusting the + encoder bit rate in real time or by having multiple copies of content + encoded at different bit rates. + +9. Example + + The following example shows a common usage pattern that MAY be + applied in such a situation. The main scope of this section is to + explain better usage of the transmission vectors. + +9.1. Stream Radio + + This is one of the most common situations: there is one single server + streaming content in multicast, and the clients may start a session + at a random time. The content itself could be a mix of a live stream + (as the webjockey's voice) and stored streams (as the music she + plays). + + In this situation, we don't know in advance how many codebooks we + will use. The clients can join anytime and users expect to start + listening to the content in a short time. + + Upon joining, the client will receive the current Configuration + necessary to decode the current stream inside the SDP so that the + decoding will start immediately after. + + When the streamed content changes, the new Configuration is sent in- + band before the actual stream, and the Configuration that has to be + sent inside the SDP is updated. Since the in-band method is + unreliable, an out-of-band fallback is provided. + + The client may choose to fetch the Configuration from the alternate + source as soon as it discovers a Configuration packet got lost in- + band, or use selective retransmission [RFC3611] if the server + supports this feature. + + + +Barbato Standards Track [Page 22] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + A server-side optimization would be to keep a hash list of the + Configurations per session, which avoids packing all of them and + sending the same Configuration with different Ident tags. + + A client-side optimization would be to keep a tag list of the + Configurations per session and not process configuration packets that + are already known. + +10. Security Considerations + + RTP packets using this payload format are subject to the security + considerations discussed in the RTP specification [RFC3550], the + base64 specification [RFC4648], and the URI Generic syntax + specification [RFC3986]. Among other considerations, 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. + +11. Copying Conditions + + The authors agree to grant third parties the irrevocable right to + copy, use, and distribute the work, with or without modification, in + any medium, without royalty, provided that, unless separate + permission is granted, redistributed modified works do not contain + misleading author, version, name of work, or endorsement information. + +12. Acknowledgments + + This document is a continuation of the following documents: + + Moffitt, J., "RTP Payload Format for Vorbis Encoded Audio", February + 2001. + + Kerr, R., "RTP Payload Format for Vorbis Encoded Audio", December + 2004. + + The Media Type declaration is a continuation of the following + document: + + Short, B., "The audio/rtp-vorbis MIME Type", January 2008. + + Thanks to the AVT, Vorbis Communities / Xiph.Org Foundation including + Steve Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, + Pascal Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John + Lazzaro, Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry + Short, Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, + David Barrett, Silvia Pfeiffer, Stefan Ehmann, Gianni Ceccarelli, and + + + +Barbato Standards Track [Page 23] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + + Alessandro Salvatori. Thanks to the LScube Group, in particular + Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Dario + Gallucci, and Juan Carlos De Martin. + +13. References + +13.1. Normative References + + [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", + RFC 1191, November 1990. + + [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU + Discovery for IP version 6", RFC 1981, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer + Model with Session Description Protocol (SDP)", + RFC 3264, June 2002. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for + Audio and Video Conferences with Minimal Control", + STD 65, RFC 3551, July 2003. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic + Syntax", STD 66, RFC 3986, January 2005. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: + Session Description Protocol", RFC 4566, + July 2006. + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 + Data Encodings", RFC 4648, October 2006. + + [VORBIS-SPEC-REF] "Ogg Vorbis I specification: Codec setup and + packet decode. Available from the Xiph website, + http://xiph.org/vorbis/doc/Vorbis_I_spec.html". + + + + + + +Barbato Standards Track [Page 24] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +13.2. Informative References + + [LIBVORBIS] "libvorbis: Available from the dedicated website, + http://vorbis.com/". + + [RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format + Version 0", RFC 3533, May 2003. + + [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP + Control Protocol Extended Reports (RTCP XR)", + RFC 3611, November 2003. + + [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. + Hakenberg, "RTP Retransmission Payload Format", + RFC 4588, July 2006. + +Author's Address + + Luca Barbato + Xiph.Org Foundation + + EMail: lu_zero@gentoo.org + URI: http://xiph.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barbato Standards Track [Page 25] + +RFC 5215 Vorbis RTP Payload Format August 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Barbato Standards Track [Page 26] +