Home | History | Annotate | Download | only in doc
      1 
      2 
      3 
      4 
      5 
      6 
      7 Network Working Group                                         L. Barbato
      8 Request for Comments: 5215                                          Xiph
      9 Category: Standards Track                                    August 2008
     10 
     11 
     12               RTP Payload Format for Vorbis Encoded Audio
     13 
     14 Status of This Memo
     15 
     16    This document specifies an Internet standards track protocol for the
     17    Internet community, and requests discussion and suggestions for
     18    improvements.  Please refer to the current edition of the "Internet
     19    Official Protocol Standards" (STD 1) for the standardization state
     20    and status of this protocol.  Distribution of this memo is unlimited.
     21 
     22 Abstract
     23 
     24    This document describes an RTP payload format for transporting Vorbis
     25    encoded audio.  It details the RTP encapsulation mechanism for raw
     26    Vorbis data and the delivery mechanisms for the decoder probability
     27    model (referred to as a codebook), as well as other setup
     28    information.
     29 
     30    Also included within this memo are media type registrations and the
     31    details necessary for the use of Vorbis with the Session Description
     32    Protocol (SDP).
     33 
     34 
     35 
     36 
     37 
     38 
     39 
     40 
     41 
     42 
     43 
     44 
     45 
     46 
     47 
     48 
     49 
     50 
     51 
     52 
     53 
     54 
     55 
     56 
     57 
     58 Barbato                     Standards Track                     [Page 1]
     59 
     61 RFC 5215               Vorbis RTP Payload Format             August 2008
     62 
     63 
     64 Table of Contents
     65 
     66    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     67      1.1.  Conformance and Document Conventions . . . . . . . . . . .  3
     68    2.  Payload Format . . . . . . . . . . . . . . . . . . . . . . . .  3
     69      2.1.  RTP Header . . . . . . . . . . . . . . . . . . . . . . . .  4
     70      2.2.  Payload Header . . . . . . . . . . . . . . . . . . . . . .  5
     71      2.3.  Payload Data . . . . . . . . . . . . . . . . . . . . . . .  6
     72      2.4.  Example RTP Packet . . . . . . . . . . . . . . . . . . . .  8
     73    3.  Configuration Headers  . . . . . . . . . . . . . . . . . . . .  8
     74      3.1.  In-band Header Transmission  . . . . . . . . . . . . . . .  9
     75        3.1.1.  Packed Configuration . . . . . . . . . . . . . . . . . 10
     76      3.2.  Out of Band Transmission . . . . . . . . . . . . . . . . . 12
     77        3.2.1.  Packed Headers . . . . . . . . . . . . . . . . . . . . 12
     78      3.3.  Loss of Configuration Headers  . . . . . . . . . . . . . . 13
     79    4.  Comment Headers  . . . . . . . . . . . . . . . . . . . . . . . 13
     80    5.  Frame Packetization  . . . . . . . . . . . . . . . . . . . . . 14
     81      5.1.  Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15
     82      5.2.  Packet Loss  . . . . . . . . . . . . . . . . . . . . . . . 17
     83    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
     84      6.1.  Packed Headers IANA Considerations . . . . . . . . . . . . 19
     85    7.  SDP Related Considerations . . . . . . . . . . . . . . . . . . 20
     86      7.1.  Mapping Media Type Parameters into SDP . . . . . . . . . . 20
     87        7.1.1.  SDP Example  . . . . . . . . . . . . . . . . . . . . . 21
     88      7.2.  Usage with the SDP Offer/Answer Model  . . . . . . . . . . 22
     89    8.  Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22
     90    9.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     91      9.1.  Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22
     92    10. Security Considerations  . . . . . . . . . . . . . . . . . . . 23
     93    11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 23
     94    12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
     95    13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     96      13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
     97      13.2. Informative References . . . . . . . . . . . . . . . . . . 25
     98 
     99 
    100 
    101 
    102 
    103 
    104 
    105 
    106 
    107 
    108 
    109 
    110 
    111 
    112 
    113 
    114 
    115 Barbato                     Standards Track                     [Page 2]
    116 
    118 RFC 5215               Vorbis RTP Payload Format             August 2008
    119 
    120 
    121 1.  Introduction
    122 
    123    Vorbis is a general purpose perceptual audio codec intended to allow
    124    maximum encoder flexibility, thus allowing it to scale competitively
    125    over an exceptionally wide range of bit rates.  At the high quality/
    126    bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is
    127    in the same league as MPEG-4 AAC.  Vorbis is also intended for lower
    128    and higher sample rates (from 8kHz telephony to 192kHz digital
    129    masters) and a range of channel representations (monaural,
    130    polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255
    131    discrete channels).
    132 
    133    Vorbis encoded audio is generally encapsulated within an Ogg format
    134    bitstream [RFC3533], which provides framing and synchronization.  For
    135    the purposes of RTP transport, this layer is unnecessary, and so raw
    136    Vorbis packets are used in the payload.
    137 
    138 1.1.  Conformance and Document Conventions
    139 
    140    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    141    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    142    document are to be interpreted as described in BCP 14, [RFC2119] and
    143    indicate requirement levels for compliant implementations.
    144    Requirements apply to all implementations unless otherwise stated.
    145 
    146    An implementation is a software module that supports one of the media
    147    types defined in this document.  Software modules may support
    148    multiple media types, but conformance is considered individually for
    149    each type.
    150 
    151    Implementations that fail to satisfy one or more "MUST" requirements
    152    are considered non-compliant.  Implementations that satisfy all
    153    "MUST" requirements, but fail to satisfy one or more "SHOULD"
    154    requirements, are said to be "conditionally compliant".  All other
    155    implementations are "unconditionally compliant".
    156 
    157 2.  Payload Format
    158 
    159    For RTP-based transport of Vorbis-encoded audio, the standard RTP
    160    header is followed by a 4-octet payload header, and then the payload
    161    data.  The payload headers are used to associate the Vorbis data with
    162    its associated decoding codebooks as well as indicate if the
    163    following packet contains fragmented Vorbis data and/or the number of
    164    whole Vorbis data frames.  The payload data contains the raw Vorbis
    165    bitstream information.  There are 3 types of Vorbis data; an RTP
    166    payload MUST contain just one of them at a time.
    167 
    168 
    169 
    170 
    171 
    172 Barbato                     Standards Track                     [Page 3]
    173 
    175 RFC 5215               Vorbis RTP Payload Format             August 2008
    176 
    177 
    178 2.1.  RTP Header
    179 
    180    The format of the RTP header is specified in [RFC3550] and shown in
    181    Figure 1.  This payload format uses the fields of the header in a
    182    manner consistent with that specification.
    183 
    184        0                   1                   2                   3
    185        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
    186       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    187       |V=2|P|X|  CC   |M|     PT      |       sequence number         |
    188       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    189       |                           timestamp                           |
    190       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    191       |           synchronization source (SSRC) identifier            |
    192       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    193       |            contributing source (CSRC) identifiers             |
    194       |                              ...                              |
    195       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    196 
    197                            Figure 1: RTP Header
    198 
    199    The RTP header begins with an octet of fields (V, P, X, and CC) to
    200    support specialized RTP uses (see [RFC3550] and [RFC3551] for
    201    details).  For Vorbis RTP, the following values are used.
    202 
    203    Version (V): 2 bits
    204 
    205    This field identifies the version of RTP.  The version used by this
    206    specification is two (2).
    207 
    208    Padding (P): 1 bit
    209 
    210    Padding MAY be used with this payload format according to Section 5.1
    211    of [RFC3550].
    212 
    213    Extension (X): 1 bit
    214 
    215    The Extension bit is used in accordance with [RFC3550].
    216 
    217    CSRC count (CC): 4 bits
    218 
    219    The CSRC count is used in accordance with [RFC3550].
    220 
    221    Marker (M): 1 bit
    222 
    223    Set to zero.  Audio silence suppression is not used.  This conforms
    224    to Section 4.1 of [VORBIS-SPEC-REF].
    225 
    226 
    227 
    228 
    229 Barbato                     Standards Track                     [Page 4]
    230 
    232 RFC 5215               Vorbis RTP Payload Format             August 2008
    233 
    234 
    235    Payload Type (PT): 7 bits
    236 
    237    An RTP profile for a class of applications is expected to assign a
    238    payload type for this format, or a dynamically allocated payload type
    239    SHOULD be chosen that designates the payload as Vorbis.
    240 
    241    Sequence number: 16 bits
    242 
    243    The sequence number increments by one for each RTP data packet sent,
    244    and may be used by the receiver to detect packet loss and to restore
    245    the packet sequence.  This field is detailed further in [RFC3550].
    246 
    247    Timestamp: 32 bits
    248 
    249    A timestamp representing the sampling time of the first sample of the
    250    first Vorbis packet in the RTP payload.  The clock frequency MUST be
    251    set to the sample rate of the encoded audio data and is conveyed out-
    252    of-band (e.g., as an SDP parameter).
    253 
    254    SSRC/CSRC identifiers:
    255 
    256    These two fields, 32 bits each with one SSRC field and a maximum of
    257    16 CSRC fields, are as defined in [RFC3550].
    258 
    259 2.2.  Payload Header
    260 
    261    The 4 octets following the RTP Header section are the Payload Header.
    262    This header is split into a number of bit fields detailing the format
    263    of the following payload data packets.
    264 
    265        0                   1                   2                   3
    266        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
    267       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    268       |                     Ident                     | F |VDT|# pkts.|
    269       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    270 
    271                          Figure 2: Payload Header
    272 
    273    Ident: 24 bits
    274 
    275    This 24-bit field is used to associate the Vorbis data to a decoding
    276    Configuration.  It is stored as a network byte order integer.
    277 
    278    Fragment type (F): 2 bits
    279 
    280 
    281 
    282 
    283 
    284 
    285 
    286 Barbato                     Standards Track                     [Page 5]
    287 
    289 RFC 5215               Vorbis RTP Payload Format             August 2008
    290 
    291 
    292    This field is set according to the following list:
    293 
    294       0 = Not Fragmented
    295 
    296       1 = Start Fragment
    297 
    298       2 = Continuation Fragment
    299 
    300       3 = End Fragment
    301 
    302    Vorbis Data Type (VDT): 2 bits
    303 
    304    This field specifies the kind of Vorbis data stored in this RTP
    305    packet.  There are currently three different types of Vorbis
    306    payloads.  Each packet MUST contain only a single type of Vorbis
    307    packet (e.g., you must not aggregate configuration and comment
    308    packets in the same RTP payload).
    309 
    310       0 = Raw Vorbis payload
    311 
    312       1 = Vorbis Packed Configuration payload
    313 
    314       2 = Legacy Vorbis Comment payload
    315 
    316       3 = Reserved
    317 
    318    The packets with a VDT of value 3 MUST be ignored.
    319 
    320    The last 4 bits represent the number of complete packets in this
    321    payload.  This provides for a maximum number of 15 Vorbis packets in
    322    the payload.  If the payload contains fragmented data, the number of
    323    packets MUST be set to 0.
    324 
    325 2.3.  Payload Data
    326 
    327    Raw Vorbis packets are currently unbounded in length; application
    328    profiles will likely define a practical limit.  Typical Vorbis packet
    329    sizes range from very small (2-3 bytes) to quite large (8-12
    330    kilobytes).  The reference implementation [LIBVORBIS] typically
    331    produces packets less than ~800 bytes, except for the setup header
    332    packets, which are ~4-12 kilobytes.  Within an RTP context, to avoid
    333    fragmentation, the Vorbis data packet size SHOULD be kept
    334    sufficiently small so that after adding the RTP and payload headers,
    335    the complete RTP packet is smaller than the path MTU.
    336 
    337 
    338 
    339 
    340 
    341 
    342 
    343 Barbato                     Standards Track                     [Page 6]
    344 
    346 RFC 5215               Vorbis RTP Payload Format             August 2008
    347 
    348 
    349        0                   1                   2                   3
    350        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
    351       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    352       |            length             |       vorbis packet data     ..
    353       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    354 
    355                        Figure 3: Payload Data Header
    356 
    357    Each Vorbis payload packet starts with a two octet length header,
    358    which is used to represent the size in bytes of the following data
    359    payload, and is followed by the raw Vorbis data padded to the nearest
    360    byte boundary, as explained by the Vorbis I Specification
    361    [VORBIS-SPEC-REF].  The length value is stored as a network byte
    362    order integer.
    363 
    364    For payloads that consist of multiple Vorbis packets, the payload
    365    data consists of the packet length followed by the packet data for
    366    each of the Vorbis packets in the payload.
    367 
    368    The Vorbis packet length header is the length of the Vorbis data
    369    block only and does not include the length field.
    370 
    371    The payload packing of the Vorbis data packets MUST follow the
    372    guidelines set out in [RFC3551], where the oldest Vorbis packet
    373    occurs immediately after the RTP packet header.  Subsequent Vorbis
    374    packets, if any, MUST follow in temporal order.
    375 
    376    Audio channel mapping is in accordance with the Vorbis I
    377    Specification [VORBIS-SPEC-REF].
    378 
    379 
    380 
    381 
    382 
    383 
    384 
    385 
    386 
    387 
    388 
    389 
    390 
    391 
    392 
    393 
    394 
    395 
    396 
    397 
    398 
    399 
    400 Barbato                     Standards Track                     [Page 7]
    401 
    403 RFC 5215               Vorbis RTP Payload Format             August 2008
    404 
    405 
    406 2.4.  Example RTP Packet
    407 
    408    Here is an example RTP payload containing two Vorbis packets.
    409 
    410        0                   1                   2                   3
    411        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
    412       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    413       | 2 |0|0|  0    |0|      PT     |       sequence number         |
    414       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    415       |               timestamp (in sample rate units)                |
    416       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    417       |           synchronisation source (SSRC) identifier            |
    418       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    419       |            contributing source (CSRC) identifiers             |
    420       |                              ...                              |
    421       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    422       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    423       |                     Ident                     | 0 | 0 | 2 pks |
    424       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    425       |            length             |          vorbis data         ..
    426       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    427       ..                        vorbis data                           |
    428       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    429       |            length             |   next vorbis packet data    ..
    430       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    431       ..                        vorbis data                          ..
    432       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    433       ..               vorbis data                    |
    434       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    435 
    436                     Figure 4: Example Raw Vorbis Packet
    437 
    438    The payload data section of the RTP packet begins with the 24-bit
    439    Ident field followed by the one octet bit field header, which has the
    440    number of Vorbis frames set to 2.  Each of the Vorbis data frames is
    441    prefixed by the two octets length field.  The Packet Type and
    442    Fragment Type are set to 0.  The Configuration that will be used to
    443    decode the packets is the one indexed by the ident value.
    444 
    445 3.  Configuration Headers
    446 
    447    Unlike other mainstream audio codecs, Vorbis has no statically
    448    configured probability model.  Instead, it packs all entropy decoding
    449    configuration, Vector Quantization and Huffman models into a data
    450    block that must be transmitted to the decoder with the compressed
    451    data.  A decoder also requires information detailing the number of
    452    audio channels, bitrates, and similar information to configure itself
    453    for a particular compressed data stream.  These two blocks of
    454 
    455 
    456 
    457 Barbato                     Standards Track                     [Page 8]
    458 
    460 RFC 5215               Vorbis RTP Payload Format             August 2008
    461 
    462 
    463    information are often referred to collectively as the "codebooks" for
    464    a Vorbis stream, and are included as special "header" packets at the
    465    start of the compressed data.  In addition, the Vorbis I
    466    specification [VORBIS-SPEC-REF] requires the presence of a comment
    467    header packet that gives simple metadata about the stream, but this
    468    information is not required for decoding the frame sequence.
    469 
    470    Thus, these two codebook header packets must be received by the
    471    decoder before any audio data can be interpreted.  These requirements
    472    pose problems in RTP, which is often used over unreliable transports.
    473 
    474    Since this information must be transmitted reliably and, as the RTP
    475    stream may change certain configuration data mid-session, there are
    476    different methods for delivering this configuration data to a client,
    477    both in-band and out-of-band, which are detailed below.  In order to
    478    set up an initial state for the client application, the configuration
    479    MUST be conveyed via the signalling channel used to set up the
    480    session.  One example of such signalling is SDP [RFC4566] with the
    481    Offer/Answer Model [RFC3264].  Changes to the configuration MAY be
    482    communicated via a re-invite, conveying a new SDP, or sent in-band in
    483    the RTP channel.  Implementations MUST support an in-band delivery of
    484    updated codebooks, and SHOULD support out-of-band codebook update
    485    using a new SDP file.  The changes may be due to different codebooks
    486    as well as different bitrates of the RTP stream.
    487 
    488    For non-chained streams, the recommended Configuration delivery
    489    method is inside the Packed Configuration (Section 3.1.1) in the SDP
    490    as explained the Mapping Media Type Parameters into SDP
    491    (Section 7.1).
    492 
    493    The 24-bit Ident field is used to map which Configuration will be
    494    used to decode a packet.  When the Ident field changes, it indicates
    495    that a change in the stream has taken place.  The client application
    496    MUST have in advance the correct configuration.  If the client
    497    detects a change in the Ident value and does not have this
    498    information, it MUST NOT decode the raw associated Vorbis data until
    499    it fetches the correct Configuration.
    500 
    501 3.1.  In-band Header Transmission
    502 
    503    The Packed Configuration (Section 3.1.1) Payload is sent in-band with
    504    the packet type bits set to match the Vorbis Data Type.  Clients MUST
    505    be capable of dealing with fragmentation and periodic re-transmission
    506    of [RFC4588] the configuration headers.  The RTP timestamp value MUST
    507    reflect the transmission time of the first data packet for which this
    508    configuration applies.
    509 
    510 
    511 
    512 
    513 
    514 Barbato                     Standards Track                     [Page 9]
    515 
    517 RFC 5215               Vorbis RTP Payload Format             August 2008
    518 
    519 
    520 3.1.1.  Packed Configuration
    521 
    522    A Vorbis Packed Configuration is indicated with the Vorbis Data Type
    523    field set to 1.  Of the three headers defined in the Vorbis I
    524    specification [VORBIS-SPEC-REF], the Identification and the Setup
    525    MUST be packed as they are, while the Comment header MAY be replaced
    526    with a dummy one.
    527 
    528    The packed configuration stores Xiph codec configurations in a
    529    generic way: the first field stores the number of the following
    530    packets minus one (count field), the next ones represent the size of
    531    the headers (length fields), and the headers immediately follow the
    532    list of length fields.  The size of the last header is implicit.
    533 
    534    The count and the length fields are encoded using the following
    535    logic: the data is in network byte order; every byte has the most
    536    significant bit used as a flag, and the following 7 bits are used to
    537    store the value.  The first 7 most significant bits are stored in the
    538    first byte.  If there are remaining bits, the flag bit is set to 1
    539    and the subsequent 7 bits are stored in the following byte.  If there
    540    are remaining bits, set the flag to 1 and the same procedure is
    541    repeated.  The ending byte has the flag bit set to 0.  To decode,
    542    simply iterate over the bytes until the flag bit is set to 0.  For
    543    every byte, the data is added to the accumulated value multiplied by
    544    128.
    545 
    546    The headers are packed in the same order as they are present in Ogg
    547    [VORBIS-SPEC-REF]: Identification, Comment, Setup.
    548 
    549    The 2 byte length tag defines the length of the packed headers as the
    550    sum of the Configuration, Comment, and Setup lengths.
    551 
    552 
    553 
    554 
    555 
    556 
    557 
    558 
    559 
    560 
    561 
    562 
    563 
    564 
    565 
    566 
    567 
    568 
    569 
    570 
    571 Barbato                     Standards Track                    [Page 10]
    572 
    574 RFC 5215               Vorbis RTP Payload Format             August 2008
    575 
    576 
    577        0                   1                   2                   3
    578        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
    579       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    580       |V=2|P|X|  CC   |M|     PT      |             xxxx              |
    581       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    582       |                             xxxxx                             |
    583       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    584       |           synchronization source (SSRC) identifier            |
    585       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    586       |            contributing source (CSRC) identifiers             |
    587       |                              ...                              |
    588       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    589       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    590       |                      Ident                    | 0 | 1 |      1|
    591       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    592       |           length              | n. of headers |    length1    |
    593       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    594       |    length2    |                  Identification              ..
    595       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    596       ..                        Identification                       ..
    597       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    598       ..                        Identification                       ..
    599       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    600       ..                        Identification                       ..
    601       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    602       ..               Identification                 |    Comment   ..
    603       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    604       ..                            Comment                          ..
    605       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    606       ..                            Comment                          ..
    607       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    608       ..                            Comment                          ..
    609       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    610       ..           Comment            |             Setup            ..
    611       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    612       ..                            Setup                            ..
    613       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    614       ..                            Setup                            ..
    615       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    616 
    617                    Figure 5: Packed Configuration Figure
    618 
    619    The Ident field is set with the value that will be used by the Raw
    620    Payload Packets to address this Configuration.  The Fragment type is
    621    set to 0 because the packet bears the full Packed configuration.  The
    622    number of the packet is set to 1.
    623 
    624 
    625 
    626 
    627 
    628 Barbato                     Standards Track                    [Page 11]
    629 
    631 RFC 5215               Vorbis RTP Payload Format             August 2008
    632 
    633 
    634 3.2.  Out of Band Transmission
    635 
    636    The following packet definition MUST be used when Configuration is
    637    inside in the SDP.
    638 
    639 3.2.1.  Packed Headers
    640 
    641    As mentioned above, the RECOMMENDED delivery vector for Vorbis
    642    configuration data is via a retrieval method that can be performed
    643    using a reliable transport protocol.  As the RTP headers are not
    644    required for this method of delivery, the structure of the
    645    configuration data is slightly different.  The packed header starts
    646    with a 32-bit (network-byte ordered) count field, which details the
    647    number of packed headers that are contained in the bundle.  The
    648    following shows the Packed header payload for each chained Vorbis
    649    stream.
    650 
    651       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    652       |                     Number of packed headers                  |
    653       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    654       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    655       |                          Packed header                        |
    656       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    657       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    658       |                          Packed header                        |
    659       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    660 
    661                      Figure 6: Packed Headers Overview
    662 
    663 
    664 
    665 
    666 
    667 
    668 
    669 
    670 
    671 
    672 
    673 
    674 
    675 
    676 
    677 
    678 
    679 
    680 
    681 
    682 
    683 
    684 
    685 Barbato                     Standards Track                    [Page 12]
    686 
    688 RFC 5215               Vorbis RTP Payload Format             August 2008
    689 
    690 
    691        0                   1                   2                   3
    692        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
    693       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    694       |                   Ident                       |    length    ..
    695       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    696       ..              | n. of headers |    length1    |    length2   ..
    697       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    698       ..              |             Identification Header            ..
    699       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    700       .................................................................
    701       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    702       ..              |         Comment Header                       ..
    703       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    704       .................................................................
    705       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    706       ..                        Comment Header                        |
    707       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    708       |                          Setup Header                        ..
    709       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    710       .................................................................
    711       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    712       ..                         Setup Header                         |
    713       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    714 
    715                       Figure 7: Packed Headers Detail
    716 
    717    The key difference between the in-band format and this one is that
    718    there is no need for the payload header octet.  In this figure, the
    719    comment has a size bigger than 127 bytes.
    720 
    721 3.3.  Loss of Configuration Headers
    722 
    723    Unlike the loss of raw Vorbis payload data, loss of a configuration
    724    header leads to a situation where it will not be possible to
    725    successfully decode the stream.  Implementations MAY try to recover
    726    from an error by requesting again the missing Configuration or, if
    727    the delivery method is in-band, by buffering the payloads waiting for
    728    the Configuration needed to decode them.  The baseline reaction
    729    SHOULD either be reset or end the RTP session.
    730 
    731 4.  Comment Headers
    732 
    733    Vorbis Data Type flag set to 2 indicates that the packet contains the
    734    comment metadata, such as artist name, track title, and so on.  These
    735    metadata messages are not intended to be fully descriptive but rather
    736    to offer basic track/song information.  Clients MAY ignore it
    737    completely.  The details on the format of the comments can be found
    738    in the Vorbis I Specification [VORBIS-SPEC-REF].
    739 
    740 
    741 
    742 Barbato                     Standards Track                    [Page 13]
    743 
    745 RFC 5215               Vorbis RTP Payload Format             August 2008
    746 
    747 
    748        0                   1                   2                   3
    749        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
    750       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    751       |V=2|P|X|  CC   |M|     PT      |             xxxx              |
    752       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    753       |                             xxxxx                             |
    754       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    755       |           synchronization source (SSRC) identifier            |
    756       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    757       |            contributing source (CSRC) identifiers             |
    758       |                              ...                              |
    759       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    760       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    761       |                      Ident                    | 0 | 2 |      1|
    762       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    763       |            length             |            Comment           ..
    764       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    765       ..                           Comment                           ..
    766       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    767       ..                           Comment                            |
    768       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    769 
    770                          Figure 8: Comment Packet
    771 
    772    The 2-byte length field is necessary since this packet could be
    773    fragmented.
    774 
    775 5.  Frame Packetization
    776 
    777    Each RTP payload contains either one Vorbis packet fragment or an
    778    integer number of complete Vorbis packets (up to a maximum of 15
    779    packets, since the number of packets is defined by a 4-bit value).
    780 
    781    Any Vorbis data packet that is less than path MTU SHOULD be bundled
    782    in the RTP payload with as many Vorbis packets as will fit, up to a
    783    maximum of 15, except when such bundling would exceed an
    784    application's desired transmission latency.  Path MTU is detailed in
    785    [RFC1191] and [RFC1981].
    786 
    787    A fragmented packet has a zero in the last four bits of the payload
    788    header.  The first fragment will set the Fragment type to 1.  Each
    789    fragment after the first will set the Fragment type to 2 in the
    790    payload header.  The consecutive fragments MUST be sent without any
    791    other payload being sent between the first and the last fragment.
    792    The RTP payload containing the last fragment of the Vorbis packet
    793    will have the Fragment type set to 3.  To maintain the correct
    794    sequence for fragmented packet reception, the timestamp field of
    795    fragmented packets MUST be the same as the first packet sent, with
    796 
    797 
    798 
    799 Barbato                     Standards Track                    [Page 14]
    800 
    802 RFC 5215               Vorbis RTP Payload Format             August 2008
    803 
    804 
    805    the sequence number incremented as normal for the subsequent RTP
    806    payloads; this will affect the RTCP jitter measurement.  The length
    807    field shows the fragment length.
    808 
    809 5.1.  Example Fragmented Vorbis Packet
    810 
    811    Here is an example of a fragmented Vorbis packet split over three RTP
    812    payloads.  Each of them contains the standard RTP headers as well as
    813    the 4-octet Vorbis headers.
    814 
    815       Packet 1:
    816 
    817        0                   1                   2                   3
    818        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
    819       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    820       |V=2|P|X|  CC   |M|     PT      |           1000                |
    821       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    822       |                            12345                              |
    823       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    824       |           synchronization source (SSRC) identifier            |
    825       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    826       |            contributing source (CSRC) identifiers             |
    827       |                              ...                              |
    828       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    829       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    830       |                       Ident                   | 1 | 0 |      0|
    831       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    832       |             length            |            vorbis data       ..
    833       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    834       ..                        vorbis data                           |
    835       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    836 
    837               Figure 9: Example Fragmented Packet (Packet 1)
    838 
    839    In this payload, the initial sequence number is 1000 and the
    840    timestamp is 12345.  The Fragment type is set to 1, the number of
    841    packets field is set to 0, and as the payload is raw Vorbis data, the
    842    VDT field is set to 0.
    843 
    844 
    845 
    846 
    847 
    848 
    849 
    850 
    851 
    852 
    853 
    854 
    855 
    856 Barbato                     Standards Track                    [Page 15]
    857 
    859 RFC 5215               Vorbis RTP Payload Format             August 2008
    860 
    861 
    862       Packet 2:
    863 
    864        0                   1                   2                   3
    865        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
    866       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    867       |V=2|P|X|  CC   |M|     PT      |           1001                |
    868       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    869       |                             12345                             |
    870       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    871       |           synchronization source (SSRC) identifier            |
    872       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    873       |            contributing source (CSRC) identifiers             |
    874       |                              ...                              |
    875       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    876       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    877       |                       Ident                   | 2 | 0 |      0|
    878       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    879       |             length            |          vorbis data         ..
    880       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    881       ..                        vorbis data                           |
    882       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    883 
    884               Figure 10: Example Fragmented Packet (Packet 2)
    885 
    886    The Fragment type field is set to 2, and the number of packets field
    887    is set to 0.  For large Vorbis fragments, there can be several of
    888    these types of payloads.  The maximum packet size SHOULD be no
    889    greater than the path MTU, including all RTP and payload headers.
    890    The sequence number has been incremented by one, but the timestamp
    891    field remains the same as the initial payload.
    892 
    893 
    894 
    895 
    896 
    897 
    898 
    899 
    900 
    901 
    902 
    903 
    904 
    905 
    906 
    907 
    908 
    909 
    910 
    911 
    912 
    913 Barbato                     Standards Track                    [Page 16]
    914 
    916 RFC 5215               Vorbis RTP Payload Format             August 2008
    917 
    918 
    919       Packet 3:
    920 
    921        0                   1                   2                   3
    922        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
    923       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    924       |V=2|P|X|  CC   |M|     PT      |           1002                |
    925       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    926       |                             12345                             |
    927       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    928       |           synchronization source (SSRC) identifier            |
    929       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    930       |            contributing source (CSRC) identifiers             |
    931       |                              ...                              |
    932       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    933       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    934       |                      Ident                    | 3 | 0 |      0|
    935       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    936       |             length            |          vorbis data         ..
    937       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    938       ..                        vorbis data                           |
    939       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    940 
    941               Figure 11: Example Fragmented Packet (Packet 3)
    942 
    943    This is the last Vorbis fragment payload.  The Fragment type is set
    944    to 3 and the packet count remains set to 0.  As in the previous
    945    payloads, the timestamp remains set to the first payload timestamp in
    946    the sequence and the sequence number has been incremented.
    947 
    948 5.2.  Packet Loss
    949 
    950    As there is no error correction within the Vorbis stream, packet loss
    951    will result in a loss of signal.  Packet loss is more of an issue for
    952    fragmented Vorbis packets as the client will have to cope with the
    953    handling of the Fragment Type.  In case of loss of fragments, the
    954    client MUST discard all the remaining Vorbis fragments and decode the
    955    incomplete packet.  If we use the fragmented Vorbis packet example
    956    above and the first RTP payload is lost, the client MUST detect that
    957    the next RTP payload has the packet count field set to 0 and the
    958    Fragment type 2 and MUST drop it.  The next RTP payload, which is the
    959    final fragmented packet, MUST be dropped in the same manner.  If the
    960    missing RTP payload is the last, the two fragments received will be
    961    kept and the incomplete Vorbis packet decoded.
    962 
    963    Loss of any of the Configuration fragment will result in the loss of
    964    the full Configuration packet with the result detailed in the Loss of
    965    Configuration Headers (Section 3.3) section.
    966 
    967 
    968 
    969 
    970 Barbato                     Standards Track                    [Page 17]
    971 
    973 RFC 5215               Vorbis RTP Payload Format             August 2008
    974 
    975 
    976 6.  IANA Considerations
    977 
    978    Type name:  audio
    979 
    980    Subtype name:  vorbis
    981 
    982    Required parameters:
    983 
    984       rate:  indicates the RTP timestamp clock rate as described in RTP
    985          Profile for Audio and Video Conferences with Minimal Control
    986          [RFC3551].
    987 
    988       channels:  indicates the number of audio channels as described in
    989          RTP Profile for Audio and Video Conferences with Minimal
    990          Control [RFC3551].
    991 
    992       configuration:  the base64 [RFC4648] representation of the Packed
    993          Headers (Section 3.2.1).
    994 
    995    Encoding considerations:
    996 
    997       This media type is framed and contains binary data.
    998 
    999    Security considerations:
   1000 
   1001       See Section 10 of RFC 5215.
   1002 
   1003    Interoperability considerations:
   1004 
   1005       None
   1006 
   1007    Published specification:
   1008 
   1009       RFC 5215
   1010 
   1011       Ogg Vorbis I specification: Codec setup and packet decode.
   1012       Available from the Xiph website, http://xiph.org/
   1013 
   1014    Applications which use this media type:
   1015 
   1016       Audio streaming and conferencing tools
   1017 
   1018    Additional information:
   1019 
   1020       None
   1021 
   1022 
   1023 
   1024 
   1025 
   1026 
   1027 Barbato                     Standards Track                    [Page 18]
   1028 
   1030 RFC 5215               Vorbis RTP Payload Format             August 2008
   1031 
   1032 
   1033    Person & email address to contact for further information:
   1034 
   1035       Luca Barbato: <lu_zero (a] gentoo.org>
   1036       IETF Audio/Video Transport Working Group
   1037 
   1038    Intended usage:
   1039 
   1040       COMMON
   1041 
   1042    Restriction on usage:
   1043 
   1044       This media type depends on RTP framing, hence is only defined for
   1045       transfer via RTP [RFC3550].
   1046 
   1047    Author:
   1048 
   1049       Luca Barbato
   1050 
   1051    Change controller:
   1052 
   1053       IETF AVT Working Group delegated from the IESG
   1054 
   1055 6.1.  Packed Headers IANA Considerations
   1056 
   1057    The following IANA considerations refers to the split configuration
   1058    Packed Headers (Section 3.2.1) used within RFC 5215.
   1059 
   1060    Type name:  audio
   1061 
   1062    Subtype name:  vorbis-config
   1063 
   1064    Required parameters:
   1065 
   1066       None
   1067 
   1068    Optional parameters:
   1069 
   1070       None
   1071 
   1072    Encoding considerations:
   1073 
   1074       This media type contains binary data.
   1075 
   1076    Security considerations:
   1077 
   1078       See Section 10 of RFC 5215.
   1079 
   1080 
   1081 
   1082 
   1083 
   1084 Barbato                     Standards Track                    [Page 19]
   1085 
   1087 RFC 5215               Vorbis RTP Payload Format             August 2008
   1088 
   1089 
   1090    Interoperability considerations:
   1091 
   1092       None
   1093 
   1094    Published specification:
   1095 
   1096       RFC 5215
   1097 
   1098    Applications which use this media type:
   1099 
   1100       Vorbis encoded audio, configuration data
   1101 
   1102    Additional information:
   1103 
   1104       None
   1105 
   1106    Person & email address to contact for further information:
   1107 
   1108       Luca Barbato: <lu_zero (a] gentoo.org>
   1109       IETF Audio/Video Transport Working Group
   1110 
   1111    Intended usage:  COMMON
   1112 
   1113    Restriction on usage:
   1114 
   1115       This media type doesn't depend on the transport.
   1116 
   1117    Author:
   1118 
   1119       Luca Barbato
   1120 
   1121    Change controller:
   1122 
   1123       IETF AVT Working Group delegated from the IESG
   1124 
   1125 7.  SDP Related Considerations
   1126 
   1127    The following paragraphs define the mapping of the parameters
   1128    described in the IANA considerations section and their usage in the
   1129    Offer/Answer Model [RFC3264].  In order to be forward compatible, the
   1130    implementation MUST ignore unknown parameters.
   1131 
   1132 7.1.  Mapping Media Type Parameters into SDP
   1133 
   1134    The information carried in the Media Type specification has a
   1135    specific mapping to fields in the Session Description Protocol (SDP)
   1136    [RFC4566], which is commonly used to describe RTP sessions.  When SDP
   1137    is used to specify sessions, the mapping are as follows:
   1138 
   1139 
   1140 
   1141 Barbato                     Standards Track                    [Page 20]
   1142 
   1144 RFC 5215               Vorbis RTP Payload Format             August 2008
   1145 
   1146 
   1147    o  The type name ("audio") goes in SDP "m=" as the media name.
   1148 
   1149    o  The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding
   1150       name.
   1151 
   1152    o  The parameter "rate" also goes in "a=rtpmap" as the clock rate.
   1153 
   1154    o  The parameter "channels" also goes in "a=rtpmap" as the channel
   1155       count.
   1156 
   1157    o  The mandated parameters "configuration" MUST be included in the
   1158       SDP "a=fmtp" attribute.
   1159 
   1160    If the stream comprises chained Vorbis files and all of them are
   1161    known in advance, the Configuration Packet for each file SHOULD be
   1162    passed to the client using the configuration attribute.
   1163 
   1164    The port value is specified by the server application bound to the
   1165    address specified in the c= line.  The channel count value specified
   1166    in the rtpmap attribute SHOULD match the current Vorbis stream or
   1167    should be considered the maximum number of channels to be expected.
   1168    The timestamp clock rate MUST be a multiple of the sample rate; a
   1169    different payload number MUST be used if the clock rate changes.  The
   1170    Configuration payload delivers the exact information, thus the SDP
   1171    information SHOULD be considered a hint.  An example is found below.
   1172 
   1173 7.1.1.  SDP Example
   1174 
   1175    The following example shows a basic SDP single stream.  The first
   1176    configuration packet is inside the SDP; other configurations could be
   1177    fetched at any time from the URIs provided.  The following base64
   1178    [RFC4648] configuration string is folded in this example due to RFC
   1179    line length limitations.
   1180 
   1181       c=IN IP4 192.0.2.1
   1182 
   1183       m=audio RTP/AVP 98
   1184 
   1185       a=rtpmap:98 vorbis/44100/2
   1186 
   1187       a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...;
   1188 
   1189    Note that the payload format (encoding) names are commonly shown in
   1190    uppercase.  Media Type subtypes are commonly shown in lowercase.
   1191    These names are case-insensitive in both places.  Similarly,
   1192    parameter names are case-insensitive both in Media Type types and in
   1193    the default mapping to the SDP a=fmtp attribute.  The a=fmtp line is
   1194 
   1195 
   1196 
   1197 
   1198 Barbato                     Standards Track                    [Page 21]
   1199 
   1201 RFC 5215               Vorbis RTP Payload Format             August 2008
   1202 
   1203 
   1204    a single line, even if it is shown as multiple lines in this document
   1205    for clarity.
   1206 
   1207 7.2.  Usage with the SDP Offer/Answer Model
   1208 
   1209    There are no negotiable parameters.  All of them are declarative.
   1210 
   1211 8.  Congestion Control
   1212 
   1213    The general congestion control considerations for transporting RTP
   1214    data apply to Vorbis audio over RTP as well.  See the RTP
   1215    specification [RFC3550] and any applicable RTP profile (e.g.,
   1216    [RFC3551]).  Audio data can be encoded using a range of different bit
   1217    rates, so it is possible to adapt network bandwidth by adjusting the
   1218    encoder bit rate in real time or by having multiple copies of content
   1219    encoded at different bit rates.
   1220 
   1221 9.  Example
   1222 
   1223    The following example shows a common usage pattern that MAY be
   1224    applied in such a situation.  The main scope of this section is to
   1225    explain better usage of the transmission vectors.
   1226 
   1227 9.1.  Stream Radio
   1228 
   1229    This is one of the most common situations: there is one single server
   1230    streaming content in multicast, and the clients may start a session
   1231    at a random time.  The content itself could be a mix of a live stream
   1232    (as the webjockey's voice) and stored streams (as the music she
   1233    plays).
   1234 
   1235    In this situation, we don't know in advance how many codebooks we
   1236    will use.  The clients can join anytime and users expect to start
   1237    listening to the content in a short time.
   1238 
   1239    Upon joining, the client will receive the current Configuration
   1240    necessary to decode the current stream inside the SDP so that the
   1241    decoding will start immediately after.
   1242 
   1243    When the streamed content changes, the new Configuration is sent in-
   1244    band before the actual stream, and the Configuration that has to be
   1245    sent inside the SDP is updated.  Since the in-band method is
   1246    unreliable, an out-of-band fallback is provided.
   1247 
   1248    The client may choose to fetch the Configuration from the alternate
   1249    source as soon as it discovers a Configuration packet got lost in-
   1250    band, or use selective retransmission [RFC3611] if the server
   1251    supports this feature.
   1252 
   1253 
   1254 
   1255 Barbato                     Standards Track                    [Page 22]
   1256 
   1258 RFC 5215               Vorbis RTP Payload Format             August 2008
   1259 
   1260 
   1261    A server-side optimization would be to keep a hash list of the
   1262    Configurations per session, which avoids packing all of them and
   1263    sending the same Configuration with different Ident tags.
   1264 
   1265    A client-side optimization would be to keep a tag list of the
   1266    Configurations per session and not process configuration packets that
   1267    are already known.
   1268 
   1269 10.  Security Considerations
   1270 
   1271    RTP packets using this payload format are subject to the security
   1272    considerations discussed in the RTP specification [RFC3550], the
   1273    base64 specification [RFC4648], and the URI Generic syntax
   1274    specification [RFC3986].  Among other considerations, this implies
   1275    that the confidentiality of the media stream is achieved by using
   1276    encryption.  Because the data compression used with this payload
   1277    format is applied end-to-end, encryption may be performed on the
   1278    compressed data.
   1279 
   1280 11.  Copying Conditions
   1281 
   1282    The authors agree to grant third parties the irrevocable right to
   1283    copy, use, and distribute the work, with or without modification, in
   1284    any medium, without royalty, provided that, unless separate
   1285    permission is granted, redistributed modified works do not contain
   1286    misleading author, version, name of work, or endorsement information.
   1287 
   1288 12.  Acknowledgments
   1289 
   1290    This document is a continuation of the following documents:
   1291 
   1292    Moffitt, J., "RTP Payload Format for Vorbis Encoded Audio", February
   1293    2001.
   1294 
   1295    Kerr, R., "RTP Payload Format for Vorbis Encoded Audio", December
   1296    2004.
   1297 
   1298    The Media Type declaration is a continuation of the following
   1299    document:
   1300 
   1301    Short, B., "The audio/rtp-vorbis MIME Type", January 2008.
   1302 
   1303    Thanks to the AVT, Vorbis Communities / Xiph.Org Foundation including
   1304    Steve Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia,
   1305    Pascal Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John
   1306    Lazzaro, Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry
   1307    Short, Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund,
   1308    David Barrett, Silvia Pfeiffer, Stefan Ehmann, Gianni Ceccarelli, and
   1309 
   1310 
   1311 
   1312 Barbato                     Standards Track                    [Page 23]
   1313 
   1315 RFC 5215               Vorbis RTP Payload Format             August 2008
   1316 
   1317 
   1318    Alessandro Salvatori.  Thanks to the LScube Group, in particular
   1319    Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Dario
   1320    Gallucci, and Juan Carlos De Martin.
   1321 
   1322 13.  References
   1323 
   1324 13.1.  Normative References
   1325 
   1326    [RFC1191]          Mogul, J. and S. Deering, "Path MTU discovery",
   1327                       RFC 1191, November 1990.
   1328 
   1329    [RFC1981]          McCann, J., Deering, S., and J. Mogul, "Path MTU
   1330                       Discovery for IP version 6", RFC 1981,
   1331                       August 1996.
   1332 
   1333    [RFC2119]          Bradner, S., "Key words for use in RFCs to
   1334                       Indicate Requirement Levels", BCP 14, RFC 2119,
   1335                       March 1997.
   1336 
   1337    [RFC3264]          Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
   1338                       Model with Session Description Protocol (SDP)",
   1339                       RFC 3264, June 2002.
   1340 
   1341    [RFC3550]          Schulzrinne, H., Casner, S., Frederick, R., and V.
   1342                       Jacobson, "RTP: A Transport Protocol for Real-Time
   1343                       Applications", STD 64, RFC 3550, July 2003.
   1344 
   1345    [RFC3551]          Schulzrinne, H. and S. Casner, "RTP Profile for
   1346                       Audio and Video Conferences with Minimal Control",
   1347                       STD 65, RFC 3551, July 2003.
   1348 
   1349    [RFC3986]          Berners-Lee, T., Fielding, R., and L. Masinter,
   1350                       "Uniform Resource Identifier (URI): Generic
   1351                       Syntax", STD 66, RFC 3986, January 2005.
   1352 
   1353    [RFC4566]          Handley, M., Jacobson, V., and C. Perkins, "SDP:
   1354                       Session Description Protocol", RFC 4566,
   1355                       July 2006.
   1356 
   1357    [RFC4648]          Josefsson, S., "The Base16, Base32, and Base64
   1358                       Data Encodings", RFC 4648, October 2006.
   1359 
   1360    [VORBIS-SPEC-REF]  "Ogg Vorbis I specification:  Codec setup and
   1361                       packet decode.  Available from the Xiph website,
   1362                       http://xiph.org/vorbis/doc/Vorbis_I_spec.html".
   1363 
   1364 
   1365 
   1366 
   1367 
   1368 
   1369 Barbato                     Standards Track                    [Page 24]
   1370 
   1372 RFC 5215               Vorbis RTP Payload Format             August 2008
   1373 
   1374 
   1375 13.2.  Informative References
   1376 
   1377    [LIBVORBIS]        "libvorbis: Available from the dedicated website,
   1378                       http://vorbis.com/".
   1379 
   1380    [RFC3533]          Pfeiffer, S., "The Ogg Encapsulation Format
   1381                       Version 0", RFC 3533, May 2003.
   1382 
   1383    [RFC3611]          Friedman, T., Caceres, R., and A. Clark, "RTP
   1384                       Control Protocol Extended Reports (RTCP XR)",
   1385                       RFC 3611, November 2003.
   1386 
   1387    [RFC4588]          Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
   1388                       Hakenberg, "RTP Retransmission Payload Format",
   1389                       RFC 4588, July 2006.
   1390 
   1391 Author's Address
   1392 
   1393    Luca Barbato
   1394    Xiph.Org Foundation
   1395 
   1396    EMail: lu_zero (a] gentoo.org
   1397    URI:   http://xiph.org/
   1398 
   1399 
   1400 
   1401 
   1402 
   1403 
   1404 
   1405 
   1406 
   1407 
   1408 
   1409 
   1410 
   1411 
   1412 
   1413 
   1414 
   1415 
   1416 
   1417 
   1418 
   1419 
   1420 
   1421 
   1422 
   1423 
   1424 
   1425 
   1426 Barbato                     Standards Track                    [Page 25]
   1427 
   1429 RFC 5215               Vorbis RTP Payload Format             August 2008
   1430 
   1431 
   1432 Full Copyright Statement
   1433 
   1434    Copyright (C) The IETF Trust (2008).
   1435 
   1436    This document is subject to the rights, licenses and restrictions
   1437    contained in BCP 78, and except as set forth therein, the authors
   1438    retain all their rights.
   1439 
   1440    This document and the information contained herein are provided on an
   1441    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   1442    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   1443    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   1444    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   1445    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   1446    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1447 
   1448 Intellectual Property
   1449 
   1450    The IETF takes no position regarding the validity or scope of any
   1451    Intellectual Property Rights or other rights that might be claimed to
   1452    pertain to the implementation or use of the technology described in
   1453    this document or the extent to which any license under such rights
   1454    might or might not be available; nor does it represent that it has
   1455    made any independent effort to identify any such rights.  Information
   1456    on the procedures with respect to rights in RFC documents can be
   1457    found in BCP 78 and BCP 79.
   1458 
   1459    Copies of IPR disclosures made to the IETF Secretariat and any
   1460    assurances of licenses to be made available, or the result of an
   1461    attempt made to obtain a general license or permission for the use of
   1462    such proprietary rights by implementers or users of this
   1463    specification can be obtained from the IETF on-line IPR repository at
   1464    http://www.ietf.org/ipr.
   1465 
   1466    The IETF invites any interested party to bring to its attention any
   1467    copyrights, patents or patent applications, or other proprietary
   1468    rights that may cover technology that may be required to implement
   1469    this standard.  Please address the information to the IETF at
   1470    ietf-ipr (a] ietf.org.
   1471 
   1472 
   1473 
   1474 
   1475 
   1476 
   1477 
   1478 
   1479 
   1480 
   1481 
   1482 
   1483 Barbato                     Standards Track                    [Page 26]
   1484 
   1486