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