[xiph-commits] r8812 - trunk/vorbis/doc

philkerr at motherfish-iii.xiph.org philkerr at motherfish-iii.xiph.org
Mon Jan 31 19:53:03 PST 2005


Author: philkerr
Date: 2005-01-31 19:52:58 -0800 (Mon, 31 Jan 2005)
New Revision: 8812

Added:
   trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.txt
Log:
Initial commit.

Added: trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.txt
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.txt	2005-02-01 03:52:09 UTC (rev 8811)
+++ trunk/vorbis/doc/draft-ietf-avt-vorbis-rtp-00.txt	2005-02-01 03:52:58 UTC (rev 8812)
@@ -0,0 +1,1400 @@
+
+
+AVT Working Group                                                P. Kerr
+Internet-Draft                                                  Xiph.Org
+Expires: August 1, 2005                                 January 31, 2005
+
+
+                      draft-ietf-avt-vorbis-rtp-00
+              RTP Payload Format for Vorbis Encoded Audio
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 August 1, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+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, metadata and other
+   setup information.
+
+   Also included within the document are the necessary details for the
+   use of Vorbis with MIME and Session Description Protocol (SDP).
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 1]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+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.  Frame Packetizing  . . . . . . . . . . . . . . . . . . . . . .  8
+     3.1   Example Fragmented Vorbis Packet . . . . . . . . . . . . .  8
+     3.2   Packet Loss  . . . . . . . . . . . . . . . . . . . . . . . 11
+   4.  Configuration Headers  . . . . . . . . . . . . . . . . . . . . 12
+     4.1   In-band Header Transmission  . . . . . . . . . . . . . . . 12
+       4.1.1   Setup Header . . . . . . . . . . . . . . . . . . . . . 13
+       4.1.2   Codebook Header  . . . . . . . . . . . . . . . . . . . 13
+       4.1.3   Metadata Header  . . . . . . . . . . . . . . . . . . . 15
+     4.2   Packed Headers Delivery  . . . . . . . . . . . . . . . . . 16
+       4.2.1   Packed Headers IANA Considerations . . . . . . . . . . 19
+     4.3   Codebook Caching . . . . . . . . . . . . . . . . . . . . . 20
+     4.4   Loss of Configuration Headers  . . . . . . . . . . . . . . 20
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
+     5.1   Mapping MIME Parameters into SDP . . . . . . . . . . . . . 21
+   6.  Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
+   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 23
+   9.2   Informative References . . . . . . . . . . . . . . . . . . . 24
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24
+       Intellectual Property and Copyright Statements . . . . . . . . 25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 2]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+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 MPEG-2 and MPC.  Similarly, the 1.0
+   encoder can encode high-quality CD and DAT rate stereo at below 48k
+   bits/sec without resampling to a lower rate.  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 [1], 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 [2].
+
+2.  Payload Format
+
+   For RTP based transportation of Vorbis encoded audio the standard RTP
+   header is followed by a 5 octet 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 the
+   number of whole Vorbis data frames.  The payload data contains the
+   raw Vorbis bitstream information.
+
+2.1  RTP Header
+
+   The format of the RTP header is specified in [3] and shown in Figure
+   1.  This payload format uses the fields of the header in a manner
+   consistent with that specification.
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 3]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+       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 [3] and [4] 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 [3].
+
+   Extension (X): 1 bit
+
+   The Extension bit is used in accordance with [3].
+
+   CSRC count (CC): 4 bits
+
+   The CSRC count is used in accordance with [3].
+
+   Marker (M): 1 bit
+
+   Set to zero.  Audio silence suppression not used.  This conforms to
+   section 4.1 of [11].
+
+   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.
+
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 4]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+   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 [3].
+
+   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 attribute.
+
+   SSRC/CSRC identifiers:
+
+   These two fields, 32 bits each with one SSRC field and a maximum of
+   16 CSRC fields, are as defined in [3].
+
+2.2  Payload Header
+
+   After the RTP Header section the following five octets 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Codebook Ident                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |C|F|VDT|# pkts.|
+      +-+-+-+-+-+-+-+-+
+
+                        Figure 2: Payload Header
+
+   Codebook Ident: 32 bits
+
+   This 32 bit field is used to associate the Vorbis data to a decoding
+   Codebook.  It is created by making a CRC32 checksum of the codebook
+   required to decode the particular Vorbis audio stream.
+
+   Continuation (C): 1 bit
+
+   Set to one if this is a continuation of a fragmented packet.
+
+   Fragmented (F): 1 bit
+
+   Set to one if the payload contains complete packets or if it contains
+   the last fragment of a fragmented packet.
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 5]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+   Vorbis Data Type (VDT): 2 bits
+
+   This field sets the packet payload type for the Vorbis data.  There
+   are currently four type of Vorbis payloads.
+
+      0 = Raw Vorbis payload
+      1 = Vorbis Setup payload
+      2 = Vorbis Codebook payload
+      3 = Vorbis Metadata payload
+
+   The last 4 bits are 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 unbounded in length currently, although at
+   some future point there will likely be a practical limit placed on
+   them.  Typical Vorbis packet sizes are from very small (2-3 bytes) to
+   quite large (8-12 kilobytes).  The reference implementation [10]
+   typically produces packets less than ~800 bytes, except for the
+   codebook header packets which are ~4-12 kilobytes.  Within an RTP
+   context the maximum Vorbis packet size, including the RTP and payload
+   headers, SHOULD be kept below the path MTU to avoid packet
+   fragmentation.
+
+       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 of the following data payload,
+   followed by the raw Vorbis data.
+
+   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.
+
+   The payload packing of the Vorbis data packets SHOULD follow the
+   guidelines set-out in [4] where the oldest packet occurs immediately
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 6]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+   after the RTP packet header.
+
+   Channel mapping of the audio is in accordance with BS.  775-1 ITU-R
+   [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             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Codebook Ident                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |0|1| 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 starts with the 32 bit
+   Codebook Ident field followed by the one octet configuration header,
+   which has the number of Vorbis frames set to 2.  Each of the Vorbis
+   data frames is prefixed by the two octet length field.
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 7]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+3.  Frame Packetizing
+
+   Each RTP packet contains either one complete Vorbis packet, one
+   Vorbis packet fragment, or an integer number of complete Vorbis
+   packets (up to a max 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.  Path MTU is detailed in [6] and [7].
+
+   If a Vorbis packet is larger than 65535 octets it MUST be fragmented.
+   A fragmented packet has a zero in the last four bits of the payload
+   header.  Each fragment after the first will also set the Continued
+   (C) bit to one in the payload header.  The RTP packet containing the
+   last fragment of the Vorbis packet will have the Fragmented (F) bit
+   set to one.  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.
+
+3.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 5 octet Vorbis headers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 8]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+      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             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Codebook Ident                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |0|0| 0 |      0|             length            | vorbis data  ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        vorbis data                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 6: Example Fragmented Packet (Packet 1)
+
+   In this packet the initial sequence number is 1000 and the timestamp
+   is xxxxx.  The Continuation (C) bit is set to one, indicating it is
+   not the continuation of a fragmented bit, and the Fragmentation (F)
+   is set to 0 indicating it is a fragmented packet.  The number of
+   packets field is set to 0, and as the payload is raw Vorbis data the
+   VDT field is set to 0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                 [Page 9]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+      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             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Codebook Ident                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |1|0| 0 |      0|             length            | vorbis data  ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        vorbis data                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 7: Example Fragmented Packet (Packet 2)
+
+   The C bit is set to 1 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 10]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+      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             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Codebook Ident                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |1|1| 0 |      0|             length            | vorbis data  ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        vorbis data                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 8: Example Fragmented Packet (Packet 3)
+
+   This is the last Vorbis fragment packet.  The C and F bits are set
+   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.
+
+3.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 C and F flags.  If we use the fragmented Vorbis
+   packet example above and the first packet is lost the client SHOULD
+   detect that the next packet has the packet count field set to 0 and
+   the C bit is set and MUST drop it.  The next packet, which is the
+   final fragmented packet, SHOULD be dropped in the same manner, or
+   buffered.  Feedback reports on lost and dropped packets MUST be sent
+   back via RTCP.
+
+   If a particular multicast session has a large number of participants
+   care must be taken to prevent an RTCP feedback implosion, [9], in the
+   event of packet loss from a large number of participants.
+
+   Loss of any of the configuration headers, detailed below, is dealt
+   with in the Loss of Configuration Headers Section later.
+
+
+
+Kerr                     Expires August 1, 2005                [Page 11]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+4.  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 self-contained codebook.
+   This codebook block also requires additional identification
+   information detailing the number of audio channels, bitrates and
+   other information used to initialise the Vorbis stream.
+
+   To decode a Vorbis stream three configuration header blocks are
+   needed.  The first header indicates the sample and bitrates, the
+   number of channels and the version of the Vorbis encoder used.  The
+   second header contains the decoders probability model, or codebook
+   and the third header details stream metadata.
+
+   As the RTP stream may change certain configuration data mid-session
+   there are two different methods for delivering this configuration
+   data to a client, in-band and SDP which is detailed below.  SDP
+   delivery is used to set-up an initial state for the client
+   application and in-band is used to change state during the session.
+   The changes may be due to different metadata or codebooks as well as
+   different bitrates of the stream.
+
+   Out of the two delivery vectors the use of an SDP attribute to
+   indicate an URI where the configuration and codebook data can be
+   obtained is preferred as they can be fetched reliably using TCP.  The
+   in-band codebook delivery SHOULD only be used in situations where the
+   link between the client is unidirectional or if the SDP-based
+   information is not available.
+
+   Synchronizing the configuration and codebook headers to the RTP
+   stream is critical.  The 32 bit Codebook Ident field is used to
+   indicate when a change in the stream has taken place.  The client
+   application MUST have in advance the correct configuration and
+   codebook headers 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.
+
+4.1  In-band Header Transmission
+
+   The three header data blocks are sent in-band with the packet type
+   bits set to match the payload type.  Normally the codebook and
+   configuration headers are sent once per session if the stream is an
+   encoding of live audio, as typically the encoder state will not
+   change, but the encoder state can change at the boundary of chained
+   Vorbis audio files.  Metadata can be sent at the start as well as any
+   time during the life of the session.  Clients MUST be capable of
+   dealing with periodic re-transmission of the configuration headers.
+
+
+
+Kerr                     Expires August 1, 2005                [Page 12]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+4.1.1  Setup Header
+
+   A Vorbis Setup header is indicated with the payload type field set to
+   1.  The Vorbis version MUST be set to zero to comply with this
+   document.  The fields Sample Rate, Bitrate Maximum/Nominal/Minimum
+   and Num Audio Channels are set in accordance with [11] with the bsz
+   fields above referring to the blocksize parameters.  The framing bit
+   is not used for RTP transportation and so applications constructing
+   Vorbis files MUST take care to set this if required.
+
+       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             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Codebook Ident                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |0|1| 2 |      1| bsz 0 | bsz 1 |       Num Audio Channels      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Vorbis Version                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Audio Sample Rate                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Bitrate Maximum                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Bitrate Nominal                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Bitrate Minimum                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                         Figure 9: Setup Header
+
+
+4.1.2  Codebook Header
+
+   If the payload type field is set to 2, this indicates the packet
+   contains Codebook data.
+
+   The configuration information detailed below MUST be completely
+   intact, as a client can not decode a stream with an incomplete or
+
+
+
+Kerr                     Expires August 1, 2005                [Page 13]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+   corrupted codebook set.
+
+   A 16 bit codebook length field precedes the codebook datablock.  The
+   length field  allows for codebooks to be up to 64K in size.  Packet
+   fragmentation, as per the Vorbis data, MUST be performed if the
+   codebooks size exceeds path MTU.  The Codebook Ident field MUST be
+   set to match the associated codebook needed to decode the Vorbis
+   stream.
+
+   The Codebook Ident is the CRC32 checksum of the codebook and is used
+   to detect a corrupted codebook as well as associating it with its
+   Vorbis data stream.  This Ident value MUST NOT be set to the value of
+   the current stream if this header is being sent before the boundary
+   of the chained file has been reached.  If a checksum failure is
+   detected then this is considered to be a failure and MUST be reported
+   to the client application.
+
+       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             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           Codebook Ident                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |0|1| 2 |      1|           Codebook Length                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    length     |           Codebook                           ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                          Codebook                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 10: Codebook Header
+
+
+4.1.2.1  Codebook CRC32 Generation
+
+   In order for different implementations of Vorbis RTP clients and
+   servers to interoperate with each other a common format for the
+   production of the CRC32 hash is required.  The polynomial is
+   X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0.
+
+
+
+Kerr                     Expires August 1, 2005                [Page 14]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+   The following C code function SHOULD be used by implementations, if
+   not then the code responsible for generating the CRC32 value MUST use
+   the polynomial function above.
+
+   unsigned int crc32 (int length, unsigned char *crcdata)
+   {
+       int index, loop;
+       unsigned int byte, crc, mask;
+
+       index = 0;
+       crc = 0xFFFFFFFF;
+
+       while (index < length) {
+           byte = crcdata [index];
+           crc = crc ^ byte;
+
+           for (loop = 7; loop >= 0; loop--) {
+               mask = -(crc & 1);
+               crc = (crc >> 1) ^ (0xEDB88320 & mask);
+           }
+           index++;
+       }
+       return ~crc;
+   }
+
+
+4.1.3  Metadata Header
+
+   With the payload type flag set to 3, 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.  This message MUST be sent
+   at the start of the stream, together with the setup and codebook
+   headers, even if it contains no information.  During a session the
+   metadata associated with the stream may change from that specified at
+   the start, e.g.  a live concert broadcast changing acts/scenes, so
+   clients MUST have the ability to receive Metadata header blocks.
+   Details on the format of the comments can be found in the Vorbis
+   documentation [12].
+
+   The format for the data takes the form of a 32 bit codec vendors name
+   length field followed by the name encoded in UTF-8.  The next 32 bit
+   field denotes the number of user comments.  Each of the user comments
+   is prefixed by a 32 bit length field followed by the comment text.
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 15]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+       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             |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Codebook Ident                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |0|1| 3 |      1|          Vendor string length                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    length     |          Vendor string                       ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    User comments list length                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       User comment length                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          User comment                        ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                         User comment                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 11: Metadata Header
+
+
+4.2  Packed Headers Delivery
+
+   As mentioned above the RECOMMENDED delivery vector for Vorbis
+   configuration data is via an SDP attribute as this retrieval method
+   can be performed using a reliable transport protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 16]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     Number of packed headers                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Packed header                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Packed header                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 12: Packed Headers Overview
+
+   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 file.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Header Length                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Codebook Ident                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Setup Header                         ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                        Setup Header                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Codebook Header                       ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                       Codebook Header                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Metadata Header                       ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                       Metadata Header                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 13: Packed Headers Detail
+
+   The key difference between the in-band format is there is no need for
+   the payload header octet and Codebook Ident field.  Below are
+   examples of the packed headers format.
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 17]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |0|1| 2 |      1| bsz 0 | bsz 1 |       Num Audio Channels      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Vorbis Version                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Audio Sample Rate                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Bitrate Maximum                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Bitrate Nominal                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Bitrate Minimum                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 14: Packed Setup Header
+
+   The alignment of the packed Setup Header is slightly different from
+   the RTP payload type as the payload header is not used.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Codebook Length                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           Codebook                           ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ..                          Codebook                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 15: Packed Codebook Header
+
+   The packed Codebook header also has a slightly different structure to
+   that of the RTP payload type.  The Codebook Ident field that is
+   normally part of this structure is moved to the second field of the
+   overall packed structure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 18]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Vendor string length                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Vendor string                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    User comments list length                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                User comment length / User comment            ..
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 16: Packed Metadata Header
+
+   The packed Metadata header also as a slightly different structure to
+   that of the RTP payload type with the payload header not being used.
+
+4.2.1  Packed Headers IANA Considerations
+
+   The following IANA considerations MUST only be applied to the packed
+   headers.
+
+   MIME media type name: audio
+
+   MIME subtype: vorbis-config
+
+   Required Parameters:
+
+   None.
+
+   Optional Parameters:
+
+   None.
+
+   Encoding considerations:
+
+   This type is only defined for transfer via HTTP as specified in RFC
+   XXXX.
+
+   Security Considerations:
+
+   See Section 6 of RFC 3047.
+
+   Interoperability considerations: none
+
+   Published specification:
+
+   See RFC XXXX for details.
+
+
+
+Kerr                     Expires August 1, 2005                [Page 19]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+   Applications which use this media type:
+
+   Vorbis encoded audio, configuration data.
+
+   Additional information: none
+
+   Person & email address to contact for further information:
+
+   Phil Kerr: <phil at plus24.com>
+
+   Intended usage: COMMON
+
+   Author/Change controller:
+
+   Author: Phil Kerr
+
+   Change controller: IETF AVT Working Group
+
+4.3  Codebook Caching
+
+   Codebook caching allows clients that have previously connected to a
+   stream to re-use the associated codebooks and configuration data.
+   When a client receives a codebook it may store it locally and can
+   compare the CRC32 key with that of the new stream and begin decoding
+   before it has received any of the headers.
+
+4.4  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.
+
+   Out of the three headers, loss of either the Codebook or Setup
+   headers MUST result in the halting of stream decoding.  Loss of the
+   Metadata header SHOULD NOT be regarded as fatal for decoding.  Loss
+   of any of the headers SHOULD be reported to the client as well as a
+   loss report sent via RTCP.
+
+5.  IANA Considerations
+
+   MIME media type name: audio
+
+   MIME subtype: vorbis
+
+   Required Parameters:
+
+   header indicates the URI of the decoding configuration headers.
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 20]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+   Optional Parameters:
+
+   None.
+
+   Encoding considerations:
+
+   This type is only defined for transfer via RTP as specified in RFC
+   XXXX.
+
+   Security Considerations:
+
+   See Section 6 of RFC 3047.
+
+   Interoperability considerations: none
+
+   Published specification:
+
+   See the Vorbis documentation [11] for details.
+
+   Applications which use this media type:
+
+   Audio streaming and conferencing tools
+
+   Additional information: none
+
+   Person & email address to contact for further information:
+
+   Phil Kerr: <phil at plus24.com>
+
+   Intended usage: COMMON
+
+   Author/Change controller:
+
+   Author: Phil Kerr
+
+   Change controller: IETF AVT Working Group
+
+5.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)
+   [5], 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.
+
+
+
+Kerr                     Expires August 1, 2005                [Page 21]
+
+
+   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 parameter "header" goes in the SDP "a=fmpt" attribute.
+
+   If the stream comprises chained Vorbis files the configuration and
+   codebook headers for each file SHOULD be packaged together and passed
+   to the client using the headers attribute if all the files to be
+   played are known in advance.
+
+   The Vorbis configuration specified in the header attribute MUST
+   contain all of the configuration data and codebooks needed for the
+   life of the session.
+
+   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.
+
+      c=IN IP4/6
+      m=audio  RTP/AVP 98
+      a=rtpmap:98 VORBIS/44100/2
+      a=fmtp:98 header=<URL of configuration header>
+
+   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 header URL which MUST be regarded as
+   being case sensitive.
+
+   The answer to any offer, [8], MUST NOT change the URL specified in
+   the header attribute.
+
+6.  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.
+
+   If a particular multicast session has a large number of participants
+   care must be taken to prevent an RTCP feedback implosion, [9], in the
+   event of congestion.
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 22]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+7.  Security Considerations
+
+   RTP packets using this payload format are subject to the security
+   considerations discussed in the RTP specification [3].  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.
+
+8.  Acknowledgments
+
+   This document is a continuation of draft-moffitt-vorbis-rtp-00.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, Michael Sparks, Magnus Westerlund.
+
+9.  References
+
+9.1  Normative References
+
+   [1]  Pfeiffer, S., "The Ogg Encapsulation Format Version 0", RFC
+        3533.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", RFC 2119.
+
+   [3]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+        "RTP: A Transport Protocol for real-time applications", RFC
+        3550.
+
+   [4]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+        Conferences with Minimal Control.", RFC 3551.
+
+   [5]  Handley, M. and V. Jacobson, "SDP: Session Description
+        Protocol", RFC 2327.
+
+   [6]  Mogul et al., J., "Path MTU Discovery", RFC 1063.
+
+   [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
+
+
+
+Kerr                     Expires August 1, 2005                [Page 23]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+        Session Description Protocol (SDP)", RFC 3264.
+
+   [9]  Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey,
+        "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
+        Internet Draft (draft-ietf-avt-rtcp-feedback-11: Work in
+        progress).
+
+9.2  Informative References
+
+   [10]  "libvorbis: Available from the Xiph website,
+         http://www.xiph.org".
+
+   [11]  "Ogg Vorbis I specification:  Codec setup and packet decode.
+         Available from the Xiph website, http://www.xiph.org".
+
+   [12]  "Ogg Vorbis I specification:  Comment field and header
+         specification.  Available from the Xiph website,
+         http://www.xiph.org".
+
+   [13]  "ITU (1992-1994) ITU-R Recommendation BS. 775-1 Multi-channel
+         stereophonic sound system with or without accompanying
+         picture. International Telecommunications Union.  Available
+         from the ITU website, http://www.itu.int".
+
+
+Author's Address
+
+   Phil Kerr
+   Xiph.Org
+
+   EMail: phil at plus24.com
+   URI:   http://www.xiph.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 24]
+
+Internet-Draft        draft-ietf-avt-vorbis-rtp-00          January 2005
+
+
+Intellectual Property Statement
+
+   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.
+
+
+Disclaimer of Validity
+
+   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 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  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.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Kerr                     Expires August 1, 2005                [Page 25]
+



More information about the commits mailing list