diff options
Diffstat (limited to 'contrib/vorbis/doc/rfc5215.txt')
| -rwxr-xr-x | contrib/vorbis/doc/rfc5215.txt | 1459 |
1 files changed, 0 insertions, 1459 deletions
diff --git a/contrib/vorbis/doc/rfc5215.txt b/contrib/vorbis/doc/rfc5215.txt deleted file mode 100755 index 67adf92..0000000 --- a/contrib/vorbis/doc/rfc5215.txt +++ /dev/null @@ -1,1459 +0,0 @@ - - - - - - -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] - |