RTP Payload Format for Vorbis Encoded Audio
Extracted elements (25)
The Ogg framing layer is stripped for RTP transport because it provides framing and synchronization that is unnecessary when RTP is used. Raw Vorbis packets are used directly in the payload instead.
The recommended configuration delivery vector is the SDP 'configuration' attribute using a reliable transport, because the codebooks must be received before decoding can begin and in-band delivery over RTP (UDP) is unreliable. In-band delivery is retained as a fallback for mid-session configuration changes.
Unlike other mainstream audio codecs, Vorbis has no statically configured probability model; all entropy decoding configuration (VQ and Huffman models) must be transmitted to the decoder as codebook headers before any audio can be decoded. This necessitates special in-band and out-of-band delivery mechanisms for configuration data in RTP.
The SDP channel count in the 'a=rtpmap' attribute SHOULD match the current Vorbis stream or be considered the maximum expected channel count. The Configuration payload delivers exact information, so SDP information SHOULD be considered a hint only.
An RTP payload MUST contain just one type of Vorbis data at a time; aggregating configuration and comment packets in the same RTP payload is prohibited.
For fragmented packets, consecutive fragments MUST be sent without any other payload between the first and last fragment. The timestamp MUST be the same as the first packet sent across all fragments, while the sequence number increments normally.
Implementations MUST ignore unknown SDP parameters to ensure forward compatibility.
In case of fragment loss, the client MUST discard all remaining Vorbis fragments associated with a fragmented packet and decode the incomplete packet. Fragments with continuation type (F=2) or end type (F=3) received without a corresponding start fragment (F=1) MUST be dropped.
Packets with a VDT value of 3 (reserved) MUST be ignored by receivers.
Payload data packing MUST follow RFC 3551 guidelines, with the oldest Vorbis packet immediately after the RTP header; subsequent Vorbis packets MUST follow in temporal order.
The RTP timestamp 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).
The SDP 'configuration' parameter (base64-encoded Packed Headers) MUST be included in the SDP 'a=fmtp' attribute. 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 Vorbis configuration MUST be conveyed via the signalling channel (e.g., SDP) used to set up the session as initial state. Implementations MUST support in-band delivery of updated codebooks and SHOULD support out-of-band codebook update using a new SDP file.
Upon loss of configuration headers, the baseline reaction SHOULD either reset or end the RTP session. Implementations MAY try to recover by re-requesting the missing Configuration or buffering payloads while waiting for the needed Configuration.
Vorbis data packet size SHOULD be kept sufficiently small so that after adding RTP and payload headers, the complete RTP packet is smaller than the path MTU, to avoid fragmentation.
When the Ident field changes, indicating a stream configuration change, the client MUST have the correct configuration in advance. If the client detects a changed Ident value for which it lacks the configuration, it MUST NOT decode the associated raw Vorbis data until it fetches the correct Configuration.
A Vorbis Packed Configuration (VDT=1) packs the Identification and Setup headers (which MUST be packed as-is) and a Comment header (which MAY be replaced with a dummy). The count and length fields use a variable-length encoding where the MSB of each byte is a continuation flag and the lower 7 bits carry data.
The RTP payload format for Vorbis consists of a standard RTP header followed by a 4-octet payload header (Ident: 24 bits, Fragment type F: 2 bits, Vorbis Data Type VDT: 2 bits, packet count: 4 bits), then payload data. There are 3 types of Vorbis data and an RTP payload MUST contain just one at a time.
This document registers the 'audio/vorbis-config' media type for the Packed Headers configuration data used in out-of-band delivery. This type has no required or optional parameters and is not transport-dependent.
This document registers the 'audio/vorbis' media type with required parameters 'rate' (RTP timestamp clock rate), 'channels' (number of audio channels), and 'configuration' (base64-encoded Packed Headers). Transfer is only defined via RTP.
RTP packets using this payload format are subject to the security considerations of RFC 3550, RFC 4648, and RFC 3986. Confidentiality of the media stream is achieved using encryption, which may be applied to the compressed data end-to-end since compression is applied end-to-end.
Fragment reassembly follows a state based on the Fragment type field: a packet with F=1 (Start) begins a fragment sequence; F=2 (Continuation) extends it; F=3 (End) completes it. If any fragment is lost, all remaining fragments for that Vorbis packet must be discarded.
Each Vorbis payload packet begins with a 2-octet length header (network byte order) indicating the size in bytes of the following Vorbis data, followed by the raw Vorbis data padded to the nearest byte boundary. The length value excludes the length field itself.
The out-of-band Packed Headers format starts with a 32-bit (network byte order) count of packed headers, followed by each packed header containing a 24-bit Ident, a variable-length 2-byte length tag, a header count, per-header length fields, and then the Identification, Comment, and Setup headers in order.
The Payload Header is 4 octets: a 24-bit Ident field (network byte order) identifying the decoding configuration, a 2-bit Fragment type field (0=not fragmented, 1=start, 2=continuation, 3=end), a 2-bit Vorbis Data Type field (0=raw, 1=packed config, 2=legacy comment, 3=reserved), and a 4-bit packet count field (max 15 packets; set to 0 for fragmented data).