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