[xiph-commits] r12908 - trunk/vorbis/doc
lu_zero at svn.xiph.org
lu_zero at svn.xiph.org
Wed May 2 13:26:10 PDT 2007
Author: lu_zero
Date: 2007-05-02 13:26:10 -0700 (Wed, 02 May 2007)
New Revision: 12908
Added:
trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-04.txt
Removed:
trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-03.txt
Log:
Update the text document
Deleted: trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-03.txt
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-03.txt 2007-05-02 20:18:26 UTC (rev 12907)
+++ trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-03.txt 2007-05-02 20:26:10 UTC (rev 12908)
@@ -1,1401 +0,0 @@
-
-
-
-AVT Working Group L. Barbato
-Internet-Draft Xiph.Org
-Expires: October 19, 2007 April 17, 2007
-
-
- draft-ietf-avt-rtp-vorbis-03
- RTP Payload Format for Vorbis Encoded Audio
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on October 19, 2007.
-
-Copyright Notice
-
- Copyright (C) The IETF Trust (2007).
-
-Abstract
-
- This document describes an RTP payload format for transporting Vorbis
- encoded audio. It details the RTP encapsulation mechanism for raw
- Vorbis data and details the delivery mechanisms for the decoder
- probability model, referred to as a codebook and other setup
- information.
-
- Also included within this memo are media type registrations, and the
- details necessary for the use of Vorbis with the Session Description
- Protocol (SDP).
-
-
-
-Barbato Expires October 19, 2007 [Page 1]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
-Editors Note
-
- All references to RFC XXXX are to be replaced by references to the
- RFC number of this memo, when published.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
- 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
- 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 7
- 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
- 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
- 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9
- 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 10
- 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 11
- 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 12
- 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 12
- 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 13
- 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 13
- 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
- 6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 18
- 7. SDP related considerations . . . . . . . . . . . . . . . . . . 20
- 7.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 20
- 7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 21
- 7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 21
- 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21
- 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
- 9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22
- 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
- 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
- 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
- 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
- 12.2. Informative References . . . . . . . . . . . . . . . . . . 24
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
- Intellectual Property and Copyright Statements . . . . . . . . . . 25
-
-
-
-
-
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 2]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
-1. Introduction
-
- Vorbis is a general purpose perceptual audio codec intended to allow
- maximum encoder flexibility, thus allowing it to scale competitively
- over an exceptionally wide range of bitrates. At the high quality/
- bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is
- in the same league as AAC. Vorbis is also intended for lower and
- higher sample rates (from 8kHz telephony to 192kHz digital masters)
- and a range of channel representations (monaural, polyphonic, stereo,
- quadraphonic, 5.1, ambisonic, or up to 255 discrete channels).
-
- Vorbis encoded audio is generally encapsulated within an Ogg format
- bitstream [10], which provides framing and synchronization. For the
- purposes of RTP transport, this layer is unnecessary, and so raw
- Vorbis packets are used in the payload.
-
-1.1. Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [1].
-
-
-2. Payload Format
-
- For RTP based transport of Vorbis encoded audio the standard RTP
- header is followed by a 4 octets payload header, then the payload
- data. The payload headers are used to associate the Vorbis data with
- its associated decoding codebooks as well as indicating if the
- following packet contains fragmented Vorbis data and/or the number of
- whole Vorbis data frames. The payload data contains the raw Vorbis
- bitstream information. There are 3 types of Vorbis payload data, an
- RTP packet MUST contain just one of them at time.
-
-2.1. RTP Header
-
- The format of the RTP header is specified in [2] and shown in Figure
- Figure 1. This payload format uses the fields of the header in a
- manner consistent with that specification.
-
-
-
-
-
-
-
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 3]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |V=2|P|X| CC |M| PT | sequence number |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | timestamp |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | synchronization source (SSRC) identifier |
- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
- | contributing source (CSRC) identifiers |
- | ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 1: RTP Header
-
- The RTP header begins with an octet of fields (V, P, X, and CC) to
- support specialized RTP uses (see [2] and [3] for details). For
- Vorbis RTP, the following values are used.
-
- Version (V): 2 bits
-
- This field identifies the version of RTP. The version used by this
- specification is two (2).
-
- Padding (P): 1 bit
-
- Padding MAY be used with this payload format according to section 5.1
- of [2].
-
- Extension (X): 1 bit
-
- The Extension bit is used in accordance with [2].
-
- CSRC count (CC): 4 bits
-
- The CSRC count is used in accordance with [2].
-
- Marker (M): 1 bit
-
- Set to zero. Audio silence suppression not used. This conforms to
- section 4.1 of [12].
-
- Payload Type (PT): 7 bits
-
- An RTP profile for a class of applications is expected to assign a
- payload type for this format, or a dynamically allocated payload type
- SHOULD be chosen which designates the payload as Vorbis.
-
-
-
-
-Barbato Expires October 19, 2007 [Page 4]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- Sequence number: 16 bits
-
- The sequence number increments by one for each RTP data packet sent,
- and may be used by the receiver to detect packet loss and to restore
- packet sequence. This field is detailed further in [2].
-
- Timestamp: 32 bits
-
- A timestamp representing the sampling time of the first sample of the
- first Vorbis packet in the RTP packet. The clock frequency MUST be
- set to the sample rate of the encoded audio data and is conveyed out-
- of-band as a SDP parameter.
-
- SSRC/CSRC identifiers:
-
- These two fields, 32 bits each with one SSRC field and a maximum of
- 16 CSRC fields, are as defined in [2].
-
-2.2. Payload Header
-
- The 4 octets following the RTP Header section are the Payload Header.
- This header is split into a number of bitfields detailing the format
- of the following payload data packets.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | F |VDT|# pkts.|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 2: Payload Header
-
- Ident: 24 bits
-
- This 24 bit field is used to associate the Vorbis data to a decoding
- Configuration. It is stored as network byte order integer.
-
- Fragment type (F): 2 bits
-
- This field is set according to the following list
-
- 0 = Not Fragmented
- 1 = Start Fragment
- 2 = Continuation Fragment
- 3 = End Fragment
-
- Vorbis Data Type (VDT): 2 bits
-
-
-
-
-Barbato Expires October 19, 2007 [Page 5]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- This field specifies the kind of Vorbis data stored in this RTP
- packet. There are currently three different types of Vorbis
- payloads. Each packet MUST contain only a single type of Vorbis
- payload.
-
- 0 = Raw Vorbis payload
- 1 = Vorbis Packed Configuration payload
- 2 = Legacy Vorbis Comment payload
- 3 = Reserved
-
- The packets with a VDT of value 3 MUST be ignored
-
- The last 4 bits represent the number of complete packets in this
- payload. This provides for a maximum number of 15 Vorbis packets in
- the payload. If the packet contains fragmented data the number of
- packets MUST be set to 0.
-
-2.3. Payload Data
-
- Raw Vorbis packets are currently unbounded in length, application
- profiles will likely define a practical limit. Typical Vorbis packet
- sizes range from very small (2-3 bytes) to quite large (8-12
- kilobytes). The reference implementation [11] typically produces
- packets less than ~800 bytes, except for the setup header packets
- which are ~4-12 kilobytes. Within an RTP context, to avoid
- fragmentation, the Vorbis data packet size SHOULD be kept
- sufficiently small so that after adding the the RTP and payload
- headers, the complete RTP packet is smaller than the path MTU.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | length | vorbis packet data ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 3: Payload Data Header
-
- Each Vorbis payload packet starts with a two octet length header,
- which is used to represent the size in bytes of the following data
- payload, followed by the raw Vorbis data padded to the nearest byte
- boundary. The length value is stored as network byte order integer.
-
- For payloads which consist of multiple Vorbis packets the payload
- data consists of the packet length followed by the packet data for
- each of the Vorbis packets in the payload.
-
- The Vorbis packet length header is the length of the Vorbis data
- block only and does not count the length field.
-
-
-
-Barbato Expires October 19, 2007 [Page 6]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- The payload packing of the Vorbis data packets MUST follow the
- guidelines set-out in [3] where the oldest packet occurs immediately
- after the RTP packet header. Subsequent packets, if any, MUST follow
- in temporal order.
-
- Channel mapping of the audio is in accordance with the Vorbis I
- Specification [12].
-
-2.4. Example RTP Packet
-
- Here is an example RTP packet containing two Vorbis packets.
-
- RTP Packet Header:
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 2 |0|0| 0 |0| PT | sequence number |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | timestamp (in sample rate units) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | synchronisation source (SSRC) identifier |
- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
- | contributing source (CSRC) identifiers |
- | ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 4: Example Packet (RTP Headers)
-
- Payload Data:
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | 0 | 0 | 2 pks |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | length | vorbis data ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. vorbis data |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | length | next vorbis packet data ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. vorbis data |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 5: Example Packet (Payload Data)
-
- The payload data section of the RTP packet begins with the 24 bit
-
-
-
-Barbato Expires October 19, 2007 [Page 7]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- Ident field followed by the one octet bitfield header, which has the
- number of Vorbis frames set to 2. Each of the Vorbis data frames is
- prefixed by the two octets length field. The Packet Type and
- Fragment Type are set to 0. The Configuration that will be used to
- decode the packets is the one indexed by the ident value.
-
-
-3. Configuration Headers
-
- Unlike other mainstream audio codecs Vorbis has no statically
- configured probability model. Instead, it packs all entropy decoding
- configuration, VQ and Huffman models into a data block that must be
- transmitted to the decoder along with the compressed data. A decoder
- also requires information detailing the number of audio channels,
- bitrates and similar information to configure itself for a particular
- compressed data stream. These two blocks of information are often
- referred to collectively as the "codebooks" for a Vorbis stream, and
- are nominally included as special "header" packets at the start of
- the compressed data. In addition, the Vorbis I specification [12]
- requires the presence of a comment header packet which gives simple
- metadata about the stream, but this information is not required for
- decoding the frame sequence.
-
- Thus these two codebook header packets must be received by the
- decoder before any audio data can be interpreted. These requirements
- pose problems in RTP, which is often used over unreliable transports.
-
- Since this information must be transmitted reliably and, as the RTP
- stream may change certain configuration data mid-session, there are
- different methods for delivering this configuration data to a client,
- both in-band and out-of-band which is detailed below. SDP delivery
- is used to set up an initial state for the client application. The
- changes may be due to different codebooks as well as different
- bitrates of the stream.
-
- The delivery vectors in use are specified by an SDP attribute to
- indicate the method and the optional URI where the Vorbis Packed
- Configuration (Section 3.1.1) Packets could be fetched. Different
- delivery methods MAY be advertised for the same session. The in-band
- Configuration delivery SHOULD be considered as baseline, out-of-band
- delivery methods that don't use RTP will not be described in this
- document. For non chained streams, the Configuration recommended
- delivery method is inline the Packed Configuration (Section 3.1.1) in
- the SDP as explained in the IANA considerations (Section 7.1)
- section.
-
- The 24 bit Ident field is used to map which Configuration will be
- used to decode a packet. When the Ident field changes, it indicates
-
-
-
-Barbato Expires October 19, 2007 [Page 8]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- that a change in the stream has taken place. The client application
- MUST have in advance the correct configuration and if the client
- detects a change in the Ident value and does not have this
- information it MUST NOT decode the raw Vorbis data associated until
- it fetches the correct Configuration.
-
-3.1. In-band Header Transmission
-
- The Packed Configuration (Section 3.1.1) Payload is sent in-band with
- the packet type bits set to match the Vorbis Data Type. Clients MUST
- be capable of dealing with fragmentation and periodic re-transmission
- of the configuration headers.
-
-3.1.1. Packed Configuration
-
- A Vorbis Packed Configuration is indicated with the Vorbis Data Type
- field set to 1. Of the three headers, defined in the Vorbis I
- specification [12], the identification and the setup will be packed
- together, the comment header is completely suppressed. Is up to the
- client to provide a minimal size comment header to the decoder if
- required by the implementation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 9]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |V=2|P|X| CC |M| PT | xxxx |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | synchronization source (SSRC) identifier |
- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
- | contributing source (CSRC) identifiers |
- | ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | 0 | 1 | 1|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | length | Identification ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Identification ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Identification ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Identification ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. | Setup ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Setup ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Setup |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 6: Packed Configuration Figure
-
- The Ident field is set with the value that will be used by the Raw
- Payload Packets to address this Configuration. The Fragment type is
- set to 0 since the packet bears the full Packed configuration, the
- number of packet is set to 1.
-
-3.2. Out of Band Transmission
-
- This section, as stated above, does not cover all the possible out-
- of-band delivery methods since they rely on different protocols and
- are linked to specific applications. The following packet definition
- SHOULD be used in out-of-band delivery and MUST be used when
- Configuration is inlined in the SDP.
-
-
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 10]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
-3.2.1. Packed Headers
-
- As mentioned above the RECOMMENDED delivery vector for Vorbis
- configuration data is via a retrieval method that can be performed
- using a reliable transport protocol. As the RTP headers are not
- required for this method of delivery the structure of the
- configuration data is slightly different. The packed header starts
- with a 32 bit count field which details the number of packed headers
- that are contained in the bundle. Next is the Packed header payload
- for each chained Vorbis stream.
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Number of packed headers |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Packed header |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Packed header |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 7: Packed Headers Overview
-
- Since the Configuration Ident and the Identification Header are fixed
- length there is only a 2 byte length tag to define the length of the
- packed headers.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. length | Identification Header ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Identification Header |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Setup Header ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Setup Header |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 8: Packed Headers Detail
-
- The key difference between the in-band format and this one, is there
- is no need for the payload header octet.
-
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 11]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
-3.3. Loss of Configuration Headers
-
- Unlike the loss of raw Vorbis payload data, loss of a configuration
- header can lead to a situation where it will not be possible to
- successfully decode the stream.
-
- Loss of Configuration Packet results in the halting of stream
- decoding.
-
-
-4. Comment Headers
-
- With the Vorbis Data Type flag set to 2, this indicates that the
- packet contain the comment metadata, such as artist name, track title
- and so on. These metadata messages are not intended to be fully
- descriptive but to offer basic track/song information. Clients MAY
- ignore it completely. The details on the format of the comments can
- be found in the Vorbis documentation [12].
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |V=2|P|X| CC |M| PT | xxxx |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | synchronization source (SSRC) identifier |
- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
- | contributing source (CSRC) identifiers |
- | ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | 0 | 2 | 1|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | length | Comment ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Comment ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Comment |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 9: Comment Packet
-
- The 2 bytes length field is necessary since this packet could be
- fragmented.
-
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 12]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
-5. Frame Packetization
-
- Each RTP packet contains either one Vorbis packet fragment, or an
- integer number of complete Vorbis packets (up to a maximum of 15
- packets, since the number of packets is defined by a 4 bit value).
-
- Any Vorbis data packet that is less than path MTU SHOULD be bundled
- in the RTP packet with as many Vorbis packets as will fit, up to a
- maximum of 15, except when such bundling would exceed an
- application's desired transmission latency. Path MTU is detailed in
- [5] and [6].
-
- A fragmented packet has a zero in the last four bits of the payload
- header. The first fragment will set the Fragment type to 1. Each
- fragment after the first will set the Fragment type to 2 in the
- payload header. The RTP packet containing the last fragment of the
- Vorbis packet will have the Fragment type set to 3. To maintain the
- correct sequence for fragmented packet reception the timestamp field
- of fragmented packets MUST be the same as the first packet sent, with
- the sequence number incremented as normal for the subsequent RTP
- packets. The length field shows the fragment length.
-
-5.1. Example Fragmented Vorbis Packet
-
- Here is an example fragmented Vorbis packet split over three RTP
- packets. Each packet contains the standard RTP headers as well as
- the 4 octets Vorbis headers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 13]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- Packet 1:
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |V=2|P|X| CC |M| PT | 1000 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | synchronization source (SSRC) identifier |
- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
- | contributing source (CSRC) identifiers |
- | ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | 1 | 0 | 0|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | length | vorbis data ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. vorbis data |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 10: Example Fragmented Packet (Packet 1)
-
- In this packet the initial sequence number is 1000 and the timestamp
- is xxxxx. The Fragment type is set to 1, the number of packets field
- is set to 0, and as the payload is raw Vorbis data the VDT field is
- set to 0.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 14]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- Packet 2:
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |V=2|P|X| CC |M| PT | 1001 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | synchronization source (SSRC) identifier |
- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
- | contributing source (CSRC) identifiers |
- | ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | 2 | 0 | 0|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | length | vorbis data ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. vorbis data |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 11: Example Fragmented Packet (Packet 2)
-
- The Fragment type field is set to 2 and the number of packets field
- is set to 0. For large Vorbis fragments there can be several of
- these type of payload packets. The maximum packet size SHOULD be no
- greater than the path MTU, including all RTP and payload headers.
- The sequence number has been incremented by one but the timestamp
- field remains the same as the initial packet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 15]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- Packet 3:
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |V=2|P|X| CC |M| PT | 1002 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | synchronization source (SSRC) identifier |
- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
- | contributing source (CSRC) identifiers |
- | ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident | 3 | 0 | 0|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | length | vorbis data ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. vorbis data |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 12: Example Fragmented Packet (Packet 3)
-
- This is the last Vorbis fragment packet. The Fragment type is set to
- 3 and the packet count remains set to 0. As in the previous packets
- the timestamp remains set to the first packet in the sequence and the
- sequence number has been incremented.
-
-5.2. Packet Loss
-
- As there is no error correction within the Vorbis stream, packet loss
- will result in a loss of signal. Packet loss is more of an issue for
- fragmented Vorbis packets as the client will have to cope with the
- handling of the Fragment Type. In case of loss of fragments the
- client MUST discard all the remaining fragments and decode the
- incomplete packet. If we use the fragmented Vorbis packet example
- above and the first packet is lost the client MUST detect that the
- next packet has the packet count field set to 0 and the Fragment type
- 2 and MUST drop it. The next packet, which is the final fragmented
- packet, MUST be dropped in the same manner. If the missing packet is
- the last, the received two fragments will be kept and the incomplete
- vorbis packet decoded.
-
- Loss of any of the Configuration fragment will result in the loss of
- the full Configuration packet with the result detailed in the Loss of
- Configuration Headers (Section 3.3) section.
-
-
-
-
-Barbato Expires October 19, 2007 [Page 16]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
-6. IANA Considerations
-
- Type name: audio
-
- Subtype name: vorbis
-
- Required parameters:
-
- rate: indicates the RTP timestamp clock rate as described in RTP
- Profile for Audio and Video Conferences with Minimal Control.
- [3]
-
- channels: indicates the number of audio channels as described in
- RTP Profile for Audio and Video Conferences with Minimal
- Control. [3]
-
- delivery-method: indicates the delivery methods in use, the
- possible values are: inline, in_band, out_band
-
- configuration: the base64 [8] representation of the Packed
- Headers (Section 3.2.1).
-
- Optional parameters:
-
- configuration-uri: the URI of the configuration headers in case
- of out of band transmission. In the form of
- "protocol://path/to/resource/". Depending on the specific
- method, a single configuration packet could be retrived by its
- number, or multiple packets could be aggregated in a single
- stream. Such aggregates MAY be compressed using either bzip2
- [15] or gzip [13]. A sha1 [9] checksum MAY be provided for
- aggregates. In this latter case the URI will end with the
- aggregate name, followed by its compressed extension if
- applies, a "!" and the base64 [8] representation of the
- sha1hash of the above mentioned compressed aggregated as in:
- "protocol://path/to/resource/aggregated.bz2!sha1hash". The
- trailing '/' discriminates which of two methods are in use.
-
- Encoding considerations:
-
- This media type is framed and contains binary data.
-
- Security considerations:
-
- See Section 10 of RFC XXXX.
-
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 17]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- Interoperability considerations:
-
- None
-
- Published specification:
-
- RFC XXXX [RFC Editor: please replace by the RFC number of this
- memo, when published]
-
- Ogg Vorbis I specification: Codec setup and packet decode.
- Available from the Xiph website, http://www.xiph.org
-
- Applications which use this media type:
-
- Audio streaming and conferencing tools
-
- Additional information:
-
- None
-
- Person & email address to contact for further information:
-
- Luca Barbato: <lu_zero at gentoo.org> IETF Audio/Video Transport
- Working Group
-
- Intended usage:
-
- COMMON
-
- Restriction on usage:
-
- This media type depends on RTP framing, and hence is only defined
- for transfer via RTP [2]
-
- Author:
-
- Luca Barbato
-
- Change controller:
-
- IETF AVT Working Group delegated from the IESG
-
-
-6.1. Packed Headers IANA Considerations
-
- The following IANA considerations MUST only be applied to the packed
- headers.
-
-
-
-
-Barbato Expires October 19, 2007 [Page 18]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- Type name: audio
-
- Subtype name: vorbis-config
-
- Required parameters:
-
- None
-
- Optional parameters:
-
- None
-
- Encoding considerations:
-
- This media type contains binary data.
-
- Security considerations:
-
- See Section 10 of RFC XXXX.
-
- Interoperability considerations:
-
- None
-
- Published specification:
-
- RFC XXXX [RFC Editor: please replace by the RFC number of this
- memo, when published]
-
- Applications which use this media type:
-
- Vorbis encoded audio, configuration data.
-
- Additional information:
-
- None
-
- Person & email address to contact for further information:
-
- Luca Barbato: <lu_zero at gentoo.org>
- IETF Audio/Video Transport Working Group
-
- Intended usage: COMMON
-
-
-
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 19]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- Restriction on usage:
-
- This media type doesn't depend on the transport.
-
- Author:
-
- Luca Barbato
-
- Change controller:
-
- IETF AVT Working Group delegated from the IESG
-
-
-7. SDP related considerations
-
- The following paragraphs defines the mapping of the parameters
- described in the IANA considerations section and their usage in the
- Offer/Answer Model [7].
-
-7.1. Mapping MIME Parameters into SDP
-
- The information carried in the MIME media type specification has a
- specific mapping to fields in the Session Description Protocol (SDP)
- [4], which is commonly used to describe RTP sessions. When SDP is
- used to specify sessions the mapping are as follows:
-
- o The MIME type ("audio") goes in SDP "m=" as the media name.
-
- o The MIME subtype ("vorbis") goes in SDP "a=rtpmap" as the encoding
- name.
-
- o The parameter "rate" also goes in "a=rtpmap" as clock rate.
-
- o The parameter "channels" also goes in "a=rtpmap" as channel count.
-
- o The mandated parameters "delivery-method" and "configuration" MUST
- be included in the SDP "a=fmpt" attribute.
-
- o The optional parameter "configuration-uri", when present, MUST be
- included in the SDP "a=fmpt" attribute and MUST follow the
- delivery-method that applies.
-
- If the stream comprises chained Vorbis files and all of them are
- known in advance, the Configuration Packet for each file SHOULD be
- passed to the client using the configuration attribute.
-
- The URI specified in the configuration-uri attribute MUST point to a
- location where all of the Configuration Packets needed for the life
-
-
-
-Barbato Expires October 19, 2007 [Page 20]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- of the session reside.
-
- The port value is specified by the server application bound to the
- address specified in the c attribute. The bitrate value and channels
- specified in the rtpmap attribute MUST match the Vorbis sample rate
- value. An example is found below.
-
-7.1.1. SDP Example
-
- The following example shows a basic SDP single stream. The first
- configuration packet is inlined in the sdp, other configurations
- could be fetched at any time from the first provided uri using or all
- the known configuration could be downloaded using the second uri.
- The inline base64 [8] configuration string is omitted because of the
- lenght.
- c=IN IP4 192.0.2.1
- m=audio RTP/AVP 98
- a=rtpmap:98 vorbis/44100/2
- a=fmtp:98 delivery-method=in_band; configuration=base64string;
- delivery-method=out_band;
- configuration-uri=rtsp://path/to/the/resource; delivery-
- method=out_band; configuration-uri=http://another/path/to/
- resource/aggregate.bz2!8b6237eb5154a0ea12811a94e8e2697b3312bc6c;
-
- Note that the payload format (encoding) names are commonly shown in
- upper case. MIME subtypes are commonly shown in lower case. These
- names are case-insensitive in both places. Similarly, parameter
- names are case-insensitive both in MIME types and in the default
- mapping to the SDP a=fmtp attribute. The exception regarding case
- sensitivity is the configuration-uri URI which MUST be regarded as
- being case sensitive. The a=fmtp line is a single line even if it is
- presented broken because of clarity.
-
-7.2. Usage with the SDP Offer/Answer Model
-
- The only paramenter negotiable is the delivery method. All the
- others are declarative: the offer, as described in An Offer/Answer
- Model Session Description Protocol [7], may contain a large number of
- delivery methods per single fmtp attribute, the answerer MUST remove
- every delivery-method and configuration-uri not supported. All the
- parameters MUST not be altered on answer otherwise.
-
-
-8. Congestion Control
-
- Vorbis clients SHOULD send regular receiver reports detailing
- congestion. A mechanism for dynamically downgrading the stream,
- known as bitrate peeling, will allow for a graceful backing off of
-
-
-
-Barbato Expires October 19, 2007 [Page 21]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- the stream bitrate. This feature is not available at present so an
- alternative would be to redirect the client to a lower bitrate stream
- if one is available.
-
-
-9. Examples
-
- The following examples are common usage patterns that MAY be applied
- in such situations, the main scope of this section is to explain
- better usage of the transmission vectors.
-
-9.1. Stream Radio
-
- This is one of the most common situation: one single server streaming
- content in multicast, the clients may start a session at random time.
- The content itself could be a mix of live stream, as the wj's voice,
- and stored streams as the music she plays.
-
- In this situation we don't know in advance how many codebooks we will
- use. The clients can join anytime and users expect to start
- listening to the content in a short time.
-
- On join the client will receive the current Configuration necessary
- to decode the current stream inlined in the SDP so that the decoding
- will start immediately after.
-
- When the streamed content changes the new Configuration is sent in-
- band before the actual stream, and the Configuration that has to be
- sent inline in the SDP updated. Since the in-band method is
- unreliable, an out of band fallback is provided.
-
- The client could choose to fetch the Configuration from the alternate
- source as soon it discovers a Configuration packet got lost in-band
- or use selective retransmission [14], if the server supports the
- feature.
-
- A serverside optimization would be to keep an hash list of the
- Configurations per session to avoid packing all of them and send the
- same Configuration with different Ident tags
-
- A clientside optimization would be to keep a tag list of the
- Configurations per session and don't process configuration packets
- already known.
-
-
-10. Security Considerations
-
- RTP packets using this payload format are subject to the security
-
-
-
-Barbato Expires October 19, 2007 [Page 22]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- considerations discussed in the RTP specification [2]. This implies
- that the confidentiality of the media stream is achieved by using
- encryption. Because the data compression used with this payload
- format is applied end-to-end, encryption may be performed on the
- compressed data. Where the size of a data block is set care MUST be
- taken to prevent buffer overflows in the client applications.
-
-
-11. Acknowledgments
-
- This document is a continuation of draft-moffitt-vorbis-rtp-00.txt
- and draft-kerr-avt-vorbis-rtp-04.txt. The MIME type section is a
- continuation of draft-short-avt-rtp-vorbis-mime-00.txt.
-
- Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including Steve
- Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal
- Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro,
- Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short,
- Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David
- Barrett, Silvia Pfeiffer, Stefan Ehmann, Alessandro Salvatori.
- Politecnico di Torino (LS)^3/IMG Group in particular Federico
- Ridolfo, Francesco Varano, Giampaolo Mancini, Juan Carlos De Martin.
-
-
-12. References
-
-12.1. Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119.
-
- [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
- "RTP: A Transport Protocol for real-time applications",
- RFC 3550.
-
- [3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
- Conferences with Minimal Control.", RFC 3551.
-
- [4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
- Description Protocol", RFC 4566, July 2006.
-
- [5] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
- November 1990.
-
- [6] McCann et al., J., "Path MTU Discovery for IP version 6",
- RFC 1981.
-
- [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
-
-
-
-Barbato Expires October 19, 2007 [Page 23]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
- Session Description Protocol (SDP)", RFC 3264.
-
- [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
- RFC 3548.
-
- [9] National Institute of Standards and Technology, "Secure Hash
- Standard", May 1993.
-
-12.2. Informative References
-
- [10] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
- RFC 3533.
-
- [11] "libvorbis: Available from the Xiph website,
- http://www.xiph.org".
-
- [12] "Ogg Vorbis I specification: Codec setup and packet decode.
- Available from the Xiph website, http://www.xiph.org".
-
- [13] Deutsch, P., "GZIP file format specification version 4.3",
- RFC 1952.
-
- [14] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
- Extended Reports (RTCP XR)", RFC 3611, November 2003.
-
- [15] Seward, J., "libbz2 and bzip2".
-
-
-Author's Address
-
- Luca Barbato
- Xiph.Org
-
- Email: lu_zero at gentoo.org
- URI: http://www.xiph.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 24]
-
-Internet-Draft draft-ietf-avt-rtp-vorbis-03 April 2007
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2007).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr at ietf.org.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-Barbato Expires October 19, 2007 [Page 25]
-
-
Copied: trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-04.txt (from rev 12905, trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-03.txt)
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-04.txt (rev 0)
+++ trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-04.txt 2007-05-02 20:26:10 UTC (rev 12908)
@@ -0,0 +1,1401 @@
+
+
+
+AVT Working Group L. Barbato
+Internet-Draft Xiph.Org
+Expires: November 5, 2007 May 04, 2007
+
+
+ draft-ietf-avt-rtp-vorbis-04
+ RTP Payload Format for Vorbis Encoded Audio
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on November 5, 2007.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This document describes an RTP payload format for transporting Vorbis
+ encoded audio. It details the RTP encapsulation mechanism for raw
+ Vorbis data and details the delivery mechanisms for the decoder
+ probability model, referred to as a codebook and other setup
+ information.
+
+ Also included within this memo are media type registrations, and the
+ details necessary for the use of Vorbis with the Session Description
+ Protocol (SDP).
+
+
+
+Barbato Expires November 5, 2007 [Page 1]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+Editors Note
+
+ All references to RFC XXXX are to be replaced by references to the
+ RFC number of this memo, when published.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 7
+ 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
+ 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
+ 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9
+ 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 10
+ 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 11
+ 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 12
+ 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 13
+ 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 13
+ 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
+ 6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 19
+ 7. SDP related considerations . . . . . . . . . . . . . . . . . . 20
+ 7.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 20
+ 7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 21
+ 7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 21
+ 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21
+ 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
+ 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
+ 12.2. Informative References . . . . . . . . . . . . . . . . . . 24
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ Intellectual Property and Copyright Statements . . . . . . . . . . 25
+
+
+
+
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 2]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+1. Introduction
+
+ Vorbis is a general purpose perceptual audio codec intended to allow
+ maximum encoder flexibility, thus allowing it to scale competitively
+ over an exceptionally wide range of bitrates. At the high quality/
+ bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is
+ in the same league as AAC. Vorbis is also intended for lower and
+ higher sample rates (from 8kHz telephony to 192kHz digital masters)
+ and a range of channel representations (monaural, polyphonic, stereo,
+ quadraphonic, 5.1, ambisonic, or up to 255 discrete channels).
+
+ Vorbis encoded audio is generally encapsulated within an Ogg format
+ bitstream [10], which provides framing and synchronization. For the
+ purposes of RTP transport, this layer is unnecessary, and so raw
+ Vorbis packets are used in the payload.
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [1].
+
+
+2. Payload Format
+
+ For RTP based transport of Vorbis encoded audio the standard RTP
+ header is followed by a 4 octets payload header, then the payload
+ data. The payload headers are used to associate the Vorbis data with
+ its associated decoding codebooks as well as indicating if the
+ following packet contains fragmented Vorbis data and/or the number of
+ whole Vorbis data frames. The payload data contains the raw Vorbis
+ bitstream information. There are 3 types of Vorbis payload data, an
+ RTP packet MUST contain just one of them at time.
+
+2.1. RTP Header
+
+ The format of the RTP header is specified in [2] and shown in Figure
+ Figure 1. This payload format uses the fields of the header in a
+ manner consistent with that specification.
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 3]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: RTP Header
+
+ The RTP header begins with an octet of fields (V, P, X, and CC) to
+ support specialized RTP uses (see [2] and [3] for details). For
+ Vorbis RTP, the following values are used.
+
+ Version (V): 2 bits
+
+ This field identifies the version of RTP. The version used by this
+ specification is two (2).
+
+ Padding (P): 1 bit
+
+ Padding MAY be used with this payload format according to section 5.1
+ of [2].
+
+ Extension (X): 1 bit
+
+ The Extension bit is used in accordance with [2].
+
+ CSRC count (CC): 4 bits
+
+ The CSRC count is used in accordance with [2].
+
+ Marker (M): 1 bit
+
+ Set to zero. Audio silence suppression not used. This conforms to
+ section 4.1 of [12].
+
+ Payload Type (PT): 7 bits
+
+ An RTP profile for a class of applications is expected to assign a
+ payload type for this format, or a dynamically allocated payload type
+ SHOULD be chosen which designates the payload as Vorbis.
+
+
+
+
+Barbato Expires November 5, 2007 [Page 4]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ Sequence number: 16 bits
+
+ The sequence number increments by one for each RTP data packet sent,
+ and may be used by the receiver to detect packet loss and to restore
+ packet sequence. This field is detailed further in [2].
+
+ Timestamp: 32 bits
+
+ A timestamp representing the sampling time of the first sample of the
+ first Vorbis packet in the RTP packet. The clock frequency MUST be
+ set to the sample rate of the encoded audio data and is conveyed out-
+ of-band (e.g. as a SDP parameter).
+
+ SSRC/CSRC identifiers:
+
+ These two fields, 32 bits each with one SSRC field and a maximum of
+ 16 CSRC fields, are as defined in [2].
+
+2.2. Payload Header
+
+ The 4 octets following the RTP Header section are the Payload Header.
+ This header is split into a number of bitfields detailing the format
+ of the following payload data packets.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | F |VDT|# pkts.|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 2: Payload Header
+
+ Ident: 24 bits
+
+ This 24 bit field is used to associate the Vorbis data to a decoding
+ Configuration. It is stored as network byte order integer.
+
+ Fragment type (F): 2 bits
+
+ This field is set according to the following list
+
+ 0 = Not Fragmented
+ 1 = Start Fragment
+ 2 = Continuation Fragment
+ 3 = End Fragment
+
+ Vorbis Data Type (VDT): 2 bits
+
+
+
+
+Barbato Expires November 5, 2007 [Page 5]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ This field specifies the kind of Vorbis data stored in this RTP
+ packet. There are currently three different types of Vorbis
+ payloads. Each packet MUST contain only a single type of Vorbis
+ payload (e.g. you MUST not aggregate configuration and comment
+ payload in the same packet)
+
+ 0 = Raw Vorbis payload
+ 1 = Vorbis Packed Configuration payload
+ 2 = Legacy Vorbis Comment payload
+ 3 = Reserved
+
+ The packets with a VDT of value 3 MUST be ignored
+
+ The last 4 bits represent the number of complete packets in this
+ payload. This provides for a maximum number of 15 Vorbis packets in
+ the payload. If the packet contains fragmented data the number of
+ packets MUST be set to 0.
+
+2.3. Payload Data
+
+ Raw Vorbis packets are currently unbounded in length, application
+ profiles will likely define a practical limit. Typical Vorbis packet
+ sizes range from very small (2-3 bytes) to quite large (8-12
+ kilobytes). The reference implementation [11] typically produces
+ packets less than ~800 bytes, except for the setup header packets
+ which are ~4-12 kilobytes. Within an RTP context, to avoid
+ fragmentation, the Vorbis data packet size SHOULD be kept
+ sufficiently small so that after adding the the RTP and payload
+ headers, the complete RTP packet is smaller than the path MTU.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis packet data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: Payload Data Header
+
+ Each Vorbis payload packet starts with a two octet length header,
+ which is used to represent the size in bytes of the following data
+ payload, followed by the raw Vorbis data padded to the nearest byte
+ boundary, as explained by the vorbis specification [12]. The length
+ value is stored as network byte order integer.
+
+ For payloads which consist of multiple Vorbis packets the payload
+ data consists of the packet length followed by the packet data for
+ each of the Vorbis packets in the payload.
+
+
+
+
+Barbato Expires November 5, 2007 [Page 6]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ The Vorbis packet length header is the length of the Vorbis data
+ block only and does not count the length field.
+
+ The payload packing of the Vorbis data packets MUST follow the
+ guidelines set-out in [3] where the oldest packet occurs immediately
+ after the RTP packet header. Subsequent packets, if any, MUST follow
+ in temporal order.
+
+ Channel mapping of the audio is in accordance with the Vorbis I
+ Specification [12].
+
+2.4. Example RTP Packet
+
+ Here is an example RTP packet containing two Vorbis packets.
+
+ RTP Packet Header:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 2 |0|0| 0 |0| PT | sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | timestamp (in sample rate units) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronisation source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 0 | 0 | 2 pks |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | next vorbis packet data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 4: Example Raw Vorbis Packet
+
+ The payload data section of the RTP packet begins with the 24 bit
+ Ident field followed by the one octet bitfield header, which has the
+ number of Vorbis frames set to 2. Each of the Vorbis data frames is
+
+
+
+Barbato Expires November 5, 2007 [Page 7]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ prefixed by the two octets length field. The Packet Type and
+ Fragment Type are set to 0. The Configuration that will be used to
+ decode the packets is the one indexed by the ident value.
+
+
+3. Configuration Headers
+
+ Unlike other mainstream audio codecs Vorbis has no statically
+ configured probability model. Instead, it packs all entropy decoding
+ configuration, Vector Quantization and Huffman models into a data
+ block that must be transmitted to the decoder along with the
+ compressed data. A decoder also requires information detailing the
+ number of audio channels, bitrates and similar information to
+ configure itself for a particular compressed data stream. These two
+ blocks of information are often referred to collectively as the
+ "codebooks" for a Vorbis stream, and are nominally included as
+ special "header" packets at the start of the compressed data. In
+ addition, the Vorbis I specification [12] requires the presence of a
+ comment header packet which gives simple metadata about the stream,
+ but this information is not required for decoding the frame sequence.
+
+ Thus these two codebook header packets must be received by the
+ decoder before any audio data can be interpreted. These requirements
+ pose problems in RTP, which is often used over unreliable transports.
+
+ Since this information must be transmitted reliably and, as the RTP
+ stream may change certain configuration data mid-session, there are
+ different methods for delivering this configuration data to a client,
+ both in-band and out-of-band which is detailed below. SDP delivery
+ is typically used to set up an initial state for the client
+ application. The changes may be due to different codebooks as well
+ as different bitrates of the stream.
+
+ The delivery vectors in use can be specified by an SDP attribute to
+ indicate the method and the optional URI where the Vorbis Packed
+ Configuration (Section 3.1.1) Packets could be fetched. Different
+ delivery methods MAY be advertised for the same session. The in-band
+ Configuration delivery SHOULD be considered as baseline, out-of-band
+ delivery methods that don't use RTP will not be described in this
+ document. For non chained streams, the Configuration recommended
+ delivery method is inline the Packed Configuration (Section 3.1.1) in
+ the SDP as explained in the IANA considerations (Section 7.1).
+
+ The 24 bit Ident field is used to map which Configuration will be
+ used to decode a packet. When the Ident field changes, it indicates
+ that a change in the stream has taken place. The client application
+ MUST have in advance the correct configuration and if the client
+ detects a change in the Ident value and does not have this
+
+
+
+Barbato Expires November 5, 2007 [Page 8]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ information it MUST NOT decode the raw Vorbis data associated until
+ it fetches the correct Configuration.
+
+3.1. In-band Header Transmission
+
+ The Packed Configuration (Section 3.1.1) Payload is sent in-band with
+ the packet type bits set to match the Vorbis Data Type. Clients MUST
+ be capable of dealing with fragmentation and periodic re-transmission
+ of the configuration headers.
+
+3.1.1. Packed Configuration
+
+ A Vorbis Packed Configuration is indicated with the Vorbis Data Type
+ field set to 1. Of the three headers, defined in the Vorbis I
+ specification [12], the identification and the setup MUST be packed
+ together, while the comment header MUST be completely suppressed. Is
+ up to the client to provide a minimal size comment header to the
+ decoder if required by the implementation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 9]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | xxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 0 | 1 | 1|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. | Setup ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 5: Packed Configuration Figure
+
+ The Ident field is set with the value that will be used by the Raw
+ Payload Packets to address this Configuration. The Fragment type is
+ set to 0 since the packet bears the full Packed configuration, the
+ number of packet is set to 1.
+
+3.2. Out of Band Transmission
+
+ This section, as stated above, does not cover all the possible out-
+ of-band delivery methods since they rely on different protocols and
+ are linked to specific applications. The following packet definition
+ SHOULD be used in out-of-band delivery and MUST be used when
+ Configuration is inlined in the SDP.
+
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 10]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+3.2.1. Packed Headers
+
+ As mentioned above the RECOMMENDED delivery vector for Vorbis
+ configuration data is via a retrieval method that can be performed
+ using a reliable transport protocol. As the RTP headers are not
+ required for this method of delivery the structure of the
+ configuration data is slightly different. The packed header starts
+ with a 32 bit (network ordered) count field which details the number
+ of packed headers that are contained in the bundle. Next is the
+ Packed header payload for each chained Vorbis stream.
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of packed headers |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packed header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packed header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 6: Packed Headers Overview
+
+ Since the Configuration Ident and the Identification Header are fixed
+ length there is only a 2 byte length tag to define the length of the
+ packed headers.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. length | Identification Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 7: Packed Headers Detail
+
+ The key difference between the in-band format and this one, is there
+ is no need for the payload header octet.
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 11]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+3.3. Loss of Configuration Headers
+
+ Unlike the loss of raw Vorbis payload data, loss of a configuration
+ header can lead to a situation where it will not be possible to
+ successfully decode the stream.
+
+ Loss of Configuration Packet results in the halting of stream
+ decoding.
+
+
+4. Comment Headers
+
+ With the Vorbis Data Type flag set to 2, this indicates that the
+ packet contain the comment metadata, such as artist name, track title
+ and so on. These metadata messages are not intended to be fully
+ descriptive but to offer basic track/song information. Clients MAY
+ ignore it completely. The details on the format of the comments can
+ be found in the Vorbis documentation [12].
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | xxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 0 | 2 | 1|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Comment |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 8: Comment Packet
+
+ The 2 bytes length field is necessary since this packet could be
+ fragmented.
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 12]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+5. Frame Packetization
+
+ Each RTP packet contains either one Vorbis packet fragment, or an
+ integer number of complete Vorbis packets (up to a maximum of 15
+ packets, since the number of packets is defined by a 4 bit value).
+
+ Any Vorbis data packet that is less than path MTU SHOULD be bundled
+ in the RTP packet with as many Vorbis packets as will fit, up to a
+ maximum of 15, except when such bundling would exceed an
+ application's desired transmission latency. Path MTU is detailed in
+ [5] and [6].
+
+ A fragmented packet has a zero in the last four bits of the payload
+ header. The first fragment will set the Fragment type to 1. Each
+ fragment after the first will set the Fragment type to 2 in the
+ payload header. The RTP packet containing the last fragment of the
+ Vorbis packet will have the Fragment type set to 3. To maintain the
+ correct sequence for fragmented packet reception the timestamp field
+ of fragmented packets MUST be the same as the first packet sent, with
+ the sequence number incremented as normal for the subsequent RTP
+ packets. The length field shows the fragment length.
+
+5.1. Example Fragmented Vorbis Packet
+
+ Here is an example fragmented Vorbis packet split over three RTP
+ packets. Each packet contains the standard RTP headers as well as
+ the 4 octets Vorbis headers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 13]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ Packet 1:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1000 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 12345 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 1 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 9: Example Fragmented Packet (Packet 1)
+
+ In this packet the initial sequence number is 1000 and the timestamp
+ is 12345. The Fragment type is set to 1, the number of packets field
+ is set to 0, and as the payload is raw Vorbis data the VDT field is
+ set to 0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 14]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ Packet 2:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1001 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 12345 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 2 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 10: Example Fragmented Packet (Packet 2)
+
+ The Fragment type field is set to 2 and the number of packets field
+ is set to 0. For large Vorbis fragments there can be several of
+ these type of payload packets. The maximum packet size SHOULD be no
+ greater than the path MTU, including all RTP and payload headers.
+ The sequence number has been incremented by one but the timestamp
+ field remains the same as the initial packet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 15]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ Packet 3:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1002 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 12345 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 3 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 11: Example Fragmented Packet (Packet 3)
+
+ This is the last Vorbis fragment packet. The Fragment type is set to
+ 3 and the packet count remains set to 0. As in the previous packets
+ the timestamp remains set to the first packet in the sequence and the
+ sequence number has been incremented.
+
+5.2. Packet Loss
+
+ As there is no error correction within the Vorbis stream, packet loss
+ will result in a loss of signal. Packet loss is more of an issue for
+ fragmented Vorbis packets as the client will have to cope with the
+ handling of the Fragment Type. In case of loss of fragments the
+ client MUST discard all the remaining fragments and decode the
+ incomplete packet. If we use the fragmented Vorbis packet example
+ above and the first packet is lost the client MUST detect that the
+ next packet has the packet count field set to 0 and the Fragment type
+ 2 and MUST drop it. The next packet, which is the final fragmented
+ packet, MUST be dropped in the same manner. If the missing packet is
+ the last, the received two fragments will be kept and the incomplete
+ vorbis packet decoded.
+
+ Loss of any of the Configuration fragment will result in the loss of
+ the full Configuration packet with the result detailed in the Loss of
+ Configuration Headers (Section 3.3) section.
+
+
+
+
+Barbato Expires November 5, 2007 [Page 16]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+6. IANA Considerations
+
+ Type name: audio
+
+ Subtype name: vorbis
+
+ Required parameters:
+
+ rate: indicates the RTP timestamp clock rate as described in RTP
+ Profile for Audio and Video Conferences with Minimal Control.
+ [3]
+
+ channels: indicates the number of audio channels as described in
+ RTP Profile for Audio and Video Conferences with Minimal
+ Control. [3]
+
+ delivery-method: indicates the delivery methods in use, the
+ possible values are: inline, in_band, out_band, MAY be included
+ multiple times
+
+ configuration: the base64 [8] representation of the Packed
+ Headers (Section 3.2.1). It MUST follow the associated
+ delivery-method parameter ("inline").
+
+ Optional parameters:
+
+ configuration-uri: the URI of the configuration headers in case
+ of out of band transmission. In the form of
+ "protocol://path/to/resource/". Depending on the specific
+ method, a single configuration packet could be retrived by its
+ number, or multiple packets could be aggregated in a single
+ stream. Such aggregates MAY be compressed using either bzip2
+ [15] or gzip [13]. A sha1 [9] checksum MAY be provided for
+ aggregates. In this latter case the URI will end with the
+ aggregate name, followed by its compressed extension if
+ applies, a "!" and the base64 [8] representation of the
+ sha1hash of the above mentioned compressed aggregated as in:
+ "protocol://path/to/resource/aggregated.bz2!sha1hash". The
+ trailing '/' discriminates which of two methods are in use. It
+ MUST follow the associated delivery method parameter (either
+ "in_band" or "out_band").
+
+ Encoding considerations:
+
+ This media type is framed and contains binary data.
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 17]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ Security considerations:
+
+ See Section 10 of RFC XXXX.
+
+ Interoperability considerations:
+
+ None
+
+ Published specification:
+
+ RFC XXXX [RFC Editor: please replace by the RFC number of this
+ memo, when published]
+
+ Ogg Vorbis I specification: Codec setup and packet decode.
+ Available from the Xiph website, http://www.xiph.org
+
+ Applications which use this media type:
+
+ Audio streaming and conferencing tools
+
+ Additional information:
+
+ None
+
+ Person & email address to contact for further information:
+
+ Luca Barbato: <lu_zero at gentoo.org> IETF Audio/Video Transport
+ Working Group
+
+ Intended usage:
+
+ COMMON
+
+ Restriction on usage:
+
+ This media type depends on RTP framing, and hence is only defined
+ for transfer via RTP [2]
+
+ Author:
+
+ Luca Barbato
+
+ Change controller:
+
+ IETF AVT Working Group delegated from the IESG
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 18]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+6.1. Packed Headers IANA Considerations
+
+ The following IANA considerations MUST only be applied to the packed
+ headers.
+
+ Type name: audio
+
+ Subtype name: vorbis-config
+
+ Required parameters:
+
+ None
+
+ Optional parameters:
+
+ None
+
+ Encoding considerations:
+
+ This media type contains binary data.
+
+ Security considerations:
+
+ See Section 10 of RFC XXXX.
+
+ Interoperability considerations:
+
+ None
+
+ Published specification:
+
+ RFC XXXX [RFC Editor: please replace by the RFC number of this
+ memo, when published]
+
+ Applications which use this media type:
+
+ Vorbis encoded audio, configuration data.
+
+ Additional information:
+
+ None
+
+ Person & email address to contact for further information:
+
+ Luca Barbato: <lu_zero at gentoo.org>
+ IETF Audio/Video Transport Working Group
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 19]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ Intended usage: COMMON
+
+ Restriction on usage:
+
+ This media type doesn't depend on the transport.
+
+ Author:
+
+ Luca Barbato
+
+ Change controller:
+
+ IETF AVT Working Group delegated from the IESG
+
+
+7. SDP related considerations
+
+ The following paragraphs defines the mapping of the parameters
+ described in the IANA considerations section and their usage in the
+ Offer/Answer Model [7].
+
+7.1. Mapping MIME Parameters into SDP
+
+ The information carried in the Media Type media type specification
+ has a specific mapping to fields in the Session Description Protocol
+ (SDP) [4], which is commonly used to describe RTP sessions. When SDP
+ is used to specify sessions the mapping are as follows:
+
+ o The type name ("audio") goes in SDP "m=" as the media name.
+
+ o The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding
+ name.
+
+ o The parameter "rate" also goes in "a=rtpmap" as clock rate.
+
+ o The parameter "channels" also goes in "a=rtpmap" as channel count.
+
+ o The mandated parameters "delivery-method" and "configuration" MUST
+ be included in the SDP "a=fmtp" attribute.
+
+ o The optional parameter "configuration-uri", when present, MUST be
+ included in the SDP "a=fmtp" attribute and MUST follow the
+ delivery-method that applies.
+
+ If the stream comprises chained Vorbis files and all of them are
+ known in advance, the Configuration Packet for each file SHOULD be
+ passed to the client using the configuration attribute.
+
+
+
+
+Barbato Expires November 5, 2007 [Page 20]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ The URI specified in the configuration-uri attribute MUST point to a
+ location where all of the Configuration Packets needed for the life
+ of the session reside.
+
+ The port value is specified by the server application bound to the
+ address specified in the c= line. The bitrate value and channels
+ specified in the rtpmap attribute MUST match the Vorbis sample rate
+ value. An example is found below.
+
+7.1.1. SDP Example
+
+ The following example shows a basic SDP single stream. The first
+ configuration packet is inlined in the sdp, other configurations
+ could be fetched at any time from the first provided uri using or all
+ the known configuration could be downloaded using the second uri.
+ The inline base64 [8] configuration string is omitted because of the
+ length.
+ c=IN IP4 192.0.2.1
+ m=audio RTP/AVP 98
+ a=rtpmap:98 vorbis/44100/2
+ a=fmtp:98 delivery-method=in_band; configuration=base64string;
+ delivery-method=out_band;
+ configuration-uri=rtsp://path/to/the/resource; delivery-
+ method=out_band; configuration-uri=http://another/path/to/
+ resource/aggregate.bz2!8b6237eb5154a0ea12811a94e8e2697b3312bc6c;
+
+ Note that the payload format (encoding) names are commonly shown in
+ upper case. MIME subtypes are commonly shown in lower case. These
+ names are case-insensitive in both places. Similarly, parameter
+ names are case-insensitive both in MIME types and in the default
+ mapping to the SDP a=fmtp attribute. The exception regarding case
+ sensitivity is the configuration-uri URI which MUST be regarded as
+ being case sensitive. The a=fmtp line is a single line even if it is
+ presented broken because of clarity.
+
+7.2. Usage with the SDP Offer/Answer Model
+
+ The only paramenter negotiable is the delivery method. All the
+ others are declarative: the offer, as described in An Offer/Answer
+ Model Session Description Protocol [7], may contain a large number of
+ delivery methods per single fmtp attribute, the answerer MUST remove
+ every delivery-method and configuration-uri not supported. All the
+ parameters MUST not be altered on answer otherwise.
+
+
+8. Congestion Control
+
+ Vorbis clients SHOULD send regular receiver reports detailing
+
+
+
+Barbato Expires November 5, 2007 [Page 21]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ congestion. A mechanism for dynamically downgrading the stream,
+ known as bitrate peeling, will allow for a graceful backing off of
+ the stream bitrate. This feature is not available at present so an
+ alternative would be to redirect the client to a lower bitrate stream
+ if one is available.
+
+
+9. Examples
+
+ The following examples are common usage patterns that MAY be applied
+ in such situations, the main scope of this section is to explain
+ better usage of the transmission vectors.
+
+9.1. Stream Radio
+
+ This is one of the most common situation: one single server streaming
+ content in multicast, the clients may start a session at random time.
+ The content itself could be a mix of live stream, as the wj's voice,
+ and stored streams as the music she plays.
+
+ In this situation we don't know in advance how many codebooks we will
+ use. The clients can join anytime and users expect to start
+ listening to the content in a short time.
+
+ On join the client will receive the current Configuration necessary
+ to decode the current stream inlined in the SDP so that the decoding
+ will start immediately after.
+
+ When the streamed content changes the new Configuration is sent in-
+ band before the actual stream, and the Configuration that has to be
+ sent inline in the SDP updated. Since the in-band method is
+ unreliable, an out of band fallback is provided.
+
+ The client could choose to fetch the Configuration from the alternate
+ source as soon it discovers a Configuration packet got lost in-band
+ or use selective retransmission [14], if the server supports the
+ feature.
+
+ A serverside optimization would be to keep an hash list of the
+ Configurations per session to avoid packing all of them and send the
+ same Configuration with different Ident tags
+
+ A clientside optimization would be to keep a tag list of the
+ Configurations per session and don't process configuration packets
+ already known.
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 22]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+10. Security Considerations
+
+ RTP packets using this payload format are subject to the security
+ considerations discussed in the RTP specification [2]. This implies
+ that the confidentiality of the media stream is achieved by using
+ encryption. Because the data compression used with this payload
+ format is applied end-to-end, encryption may be performed on the
+ compressed data. Additional care MAY be needed for delivery methods
+ that point to external resources, using secure protocols to fetch the
+ configuration payloads. Where the size of a data block is set, care
+ MUST be taken to prevent buffer overflows in the client applications.
+
+
+11. Acknowledgments
+
+ This document is a continuation of draft-moffitt-vorbis-rtp-00.txt
+ and draft-kerr-avt-vorbis-rtp-04.txt. The MIME type section is a
+ continuation of draft-short-avt-rtp-vorbis-mime-00.txt.
+
+ Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including Steve
+ Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal
+ Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro,
+ Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short,
+ Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David
+ Barrett, Silvia Pfeiffer, Stefan Ehmann, Alessandro Salvatori.
+ Politecnico di Torino (LS)^3/IMG Group in particular Federico
+ Ridolfo, Francesco Varano, Giampaolo Mancini, Juan Carlos De Martin.
+
+
+12. References
+
+12.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119.
+
+ [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+ "RTP: A Transport Protocol for real-time applications",
+ RFC 3550.
+
+ [3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+ Conferences with Minimal Control.", RFC 3551.
+
+ [4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [5] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+ November 1990.
+
+
+
+Barbato Expires November 5, 2007 [Page 23]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+ [6] McCann et al., J., "Path MTU Discovery for IP version 6",
+ RFC 1981.
+
+ [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+ Session Description Protocol (SDP)", RFC 3264.
+
+ [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+ RFC 3548.
+
+ [9] National Institute of Standards and Technology, "Secure Hash
+ Standard", May 1993.
+
+12.2. Informative References
+
+ [10] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
+ RFC 3533.
+
+ [11] "libvorbis: Available from the Xiph website,
+ http://www.xiph.org".
+
+ [12] "Ogg Vorbis I specification: Codec setup and packet decode.
+ Available from the Xiph website, http://www.xiph.org".
+
+ [13] Deutsch, P., "GZIP file format specification version 4.3",
+ RFC 1952.
+
+ [14] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
+ Extended Reports (RTCP XR)", RFC 3611, November 2003.
+
+ [15] Seward, J., "libbz2 and bzip2".
+
+
+Author's Address
+
+ Luca Barbato
+ Xiph.Org
+
+ Email: lu_zero at gentoo.org
+ URI: http://www.xiph.org/
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 24]
+
+Internet-Draft draft-ietf-avt-rtp-vorbis-04 May 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Barbato Expires November 5, 2007 [Page 25]
+
+
More information about the commits
mailing list