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