gosu 0.7.16 → 0.7.17

data/dependencies/libvorbis/doc/draft-ietf-avt-rtp-vorbis-06.txt

@@ -1,1401 +0,0 @@
-
-
-
-AVT Working Group                                             L. Barbato
-Internet-Draft                                                  Xiph.Org
-Expires: December 27, 2007                                  Jun 25, 2007
-
-
-                      draft-ietf-avt-rtp-vorbis-06
-              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 December 27, 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 December 27, 2007               [Page 1]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 . . . . . . . . . . . . . . . . . 11
-       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 . . . . . . . . . . . . . 14
-     5.2.  Packet Loss  . . . . . . . . . . . . . . . . . . . . . . . 16
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
-     6.1.  Packed Headers IANA Considerations . . . . . . . . . . . . 19
-   7.  SDP related considerations . . . . . . . . . . . . . . . . . . 20
-     7.1.  Mapping Media Type Parameters into SDP . . . . . . . . . . 20
-       7.1.1.  SDP Example  . . . . . . . . . . . . . . . . . . . . . 21
-     7.2.  Usage with the SDP Offer/Answer Model  . . . . . . . . . . 21
-   8.  Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22
-   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 December 27, 2007               [Page 2]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 [11], 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 a 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 December 27, 2007               [Page 3]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 [13].
-
-   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 December 27, 2007               [Page 4]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 December 27, 2007               [Page 5]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 [12] typically produces
-   packets less than ~800 bytes, except for the setup header packets
-   which are ~4-12 kilobytes.  Within an RTP context, to avoid
-   fragmentation, the Vorbis data packet size SHOULD be kept
-   sufficiently small so that after adding the RTP and payload headers,
-   the complete RTP packet is smaller than the path MTU.
-
-       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 [13].  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 December 27, 2007               [Page 6]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 [13].
-
-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 December 27, 2007               [Page 7]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 [13] 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 December 27, 2007               [Page 8]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 [13], the identification and the setup MUST be packed
-   as they are, while the comment header MAY be replaced with a dummy
-   one.  The packed configuration follows a generic way to store xiph
-   codec configurations: The first field stores the number of the
-   following packets minus one (count field), the next ones represent
-   the size of the headers (length fields), the headers immediately
-   follow the list of length fields.  The size of the last header is
-   implicit.  The count and the length fields are encoded using the
-   following logic: the data is in network order, every byte has the
-   most significant bit used as flag and the following 7 used to store
-   the value.  The first N bit are to be taken, where N is number of
-   bits representing the value modulo 7, and stored in the first byte.
-   If there are more bits, the flag bit is set to 1 and the subsequent
-   7bit are stored in the following byte, if there are remaining bits
-   set the flag to 1 and the same procedure is repeated.  The ending
-   byte has the flag bit set to 0.  In order to decode it is enough to
-   iterate over the bytes until the flag bit set to 0, for every byte
-   the data is added to the accumulated value multiplied by 128.  The
-   headers are packed in the same order they are present in ogg:
-   identification, comment, setup.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barbato                 Expires December 27, 2007               [Page 9]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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                    | 1 | 0 |      0|
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |           length              | n. of headers |    length1    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |    length2    |                  Identification              ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..                        Identification                       ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..                        Identification                       ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..                        Identification                       ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..               Identification                 |    Comment   ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..                            Comment                          ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..                            Comment                          ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..                            Comment                          ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..           Comment            |             Setup            ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..                            Setup                            ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..                            Setup                            ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                   Figure 5: Packed Configuration Figure
-
-   The Ident field is set with the value that will be used by the Raw
-   Payload Packets to address this Configuration.  The Fragment type is
-   set to 0 since the packet bears the full Packed configuration, the
-   number of packet is set to 1.
-
-
-
-
-
-Barbato                 Expires December 27, 2007              [Page 10]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
-
-
-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.
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barbato                 Expires December 27, 2007              [Page 11]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                   Ident                       |    length    ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..              | n. of headers |    length1    |    length2   ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..              |             Identification Header            ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      .................................................................
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..              |         Comment Header                       ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      .................................................................
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..                        Comment Header                        |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                          Setup Header                        ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      .................................................................
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..                         Setup Header                         |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                      Figure 7: Packed Headers Detail
-
-   The key difference between the in-band format and this one, is that
-   there is no need for the payload header octet.  In this figure the
-   comment has a size bigger than 127 bytes.
-
-3.3.  Loss of Configuration Headers
-
-   Unlike the loss of raw Vorbis payload data, loss of a configuration
-   header 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 [13].
-
-
-
-Barbato                 Expires December 27, 2007              [Page 12]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 | 2 |      1|
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |            length             |            Comment           ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..                           Comment                           ..
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      ..                           Comment                            |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                         Figure 8: Comment Packet
-
-   The 2 bytes length field is necessary since this packet could be
-   fragmented.
-
-
-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
-   [6] and [7].
-
-   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
-
-
-
-Barbato                 Expires December 27, 2007              [Page 13]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
-
-
-   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.
-
-      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 December 27, 2007              [Page 14]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 December 27, 2007              [Page 15]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 December 27, 2007              [Page 16]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 [9] representation of the Packed
-         Headers (Section 3.2.1).  It MUST follow the associated
-         delivery-method parameter ("inline").
-
-   Optional parameters:
-
-      configuration-uri:  the URI [4] 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
-         Ident number, or multiple packets could be aggregated in a
-         single stream.  Such aggregates MAY be compressed using either
-         bzip2 [16] or gzip [14].  A sha1 [10] 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 [9] 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.
-         The configuration-uri MUST follow the associated delivery
-         method parameter ("out_band").  Non hierarchical protocols and
-         protocols using for special purposes the '!' separator MAY
-         point just to a resource aggregate using their specific syntax.
-
-
-
-
-
-
-
-
-Barbato                 Expires December 27, 2007              [Page 17]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
-
-
-   Encoding considerations:
-
-      This media type is framed and 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]
-
-      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@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
-
-
-
-
-
-
-Barbato                 Expires December 27, 2007              [Page 18]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
-
-
-   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.
-
-   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
-
-
-
-
-
-Barbato                 Expires December 27, 2007              [Page 19]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
-
-
-   Person & email address to contact for further information:
-
-      Luca Barbato: <lu_zero@gentoo.org>
-      IETF Audio/Video Transport Working Group
-
-   Intended usage:  COMMON
-
-   Restriction on usage:
-
-      This media type doesn't depend on the transport.
-
-   Author:
-
-      Luca Barbato
-
-   Change controller:
-
-      IETF AVT Working Group delegated from the IESG
-
-
-7.  SDP related considerations
-
-   The following paragraphs defines the mapping of the parameters
-   described in the IANA considerations section and their usage in the
-   Offer/Answer Model [8].
-
-7.1.  Mapping Media Type 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) [5], 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.
-
-
-
-Barbato                 Expires December 27, 2007              [Page 20]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
-
-
-   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
-   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 [9] 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=inline; 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.  Media Type subtypes are commonly shown in lower case.
-   These names are case-insensitive in both places.  Similarly,
-   parameter names are case-insensitive both in Media Type types and in
-   the default mapping to the SDP a=fmtp attribute.  The 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 [8], 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.
-
-
-
-
-Barbato                 Expires December 27, 2007              [Page 21]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
-
-
-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
-   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 as it discovers a Configuration packet got lost in-
-   band or use selective retransmission [15], 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 December 27, 2007              [Page 22]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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 Media Type 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, Dario Gallucci, 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]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-         Resource Identifier (URI): Generic Syntax", RFC 3986.
-
-   [5]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
-
-
-
-Barbato                 Expires December 27, 2007              [Page 23]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
-
-
-         Description Protocol", RFC 4566, July 2006.
-
-   [6]   Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
-         November 1990.
-
-   [7]   McCann et al., J., "Path MTU Discovery for IP version 6",
-         RFC 1981.
-
-   [8]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
-         Session Description Protocol (SDP)", RFC 3264.
-
-   [9]   Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548.
-
-   [10]  National Institute of Standards and Technology, "Secure Hash
-         Standard", May 1993.
-
-12.2.  Informative References
-
-   [11]  Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
-         RFC 3533.
-
-   [12]  "libvorbis: Available from the Xiph website,
-         http://www.xiph.org".
-
-   [13]  "Ogg Vorbis I specification:  Codec setup and packet decode.
-         Available from the Xiph website, http://www.xiph.org".
-
-   [14]  Deutsch, P., "GZIP file format specification version 4.3",
-         RFC 1952.
-
-   [15]  Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
-         Extended Reports (RTCP XR)", RFC 3611, November 2003.
-
-   [16]  Seward, J., "libbz2 and bzip2".
-
-
-Author's Address
-
-   Luca Barbato
-   Xiph.Org
-
-   Email: lu_zero@gentoo.org
-   URI:   http://www.xiph.org/
-
-
-
-
-
-
-
-Barbato                 Expires December 27, 2007              [Page 24]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 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@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Barbato                 Expires December 27, 2007              [Page 25]
-
-