doc/rfc5215.txt

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