summaryrefslogtreecommitdiffhomepage
path: root/vorbis/doc/rfc5215.txt
diff options
context:
space:
mode:
Diffstat (limited to 'vorbis/doc/rfc5215.txt')
-rwxr-xr-xvorbis/doc/rfc5215.txt1459
1 files changed, 0 insertions, 1459 deletions
diff --git a/vorbis/doc/rfc5215.txt b/vorbis/doc/rfc5215.txt
deleted file mode 100755
index 67adf92..0000000
--- a/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]
-