1
2
3
4
5
6
7Network Working Group                                         L. Barbato
8Request for Comments: 5215                                          Xiph
9Category: Standards Track                                    August 2008
10
11
12              RTP Payload Format for Vorbis Encoded Audio
13
14Status 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
22Abstract
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
58Barbato                     Standards Track                     [Page 1]
59
60RFC 5215               Vorbis RTP Payload Format             August 2008
61
62
63Table 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
114Barbato                     Standards Track                     [Page 2]
115
116RFC 5215               Vorbis RTP Payload Format             August 2008
117
118
1191.  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
1361.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
1552.  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
170Barbato                     Standards Track                     [Page 3]
171
172RFC 5215               Vorbis RTP Payload Format             August 2008
173
174
1752.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
226Barbato                     Standards Track                     [Page 4]
227
228RFC 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
2552.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
282Barbato                     Standards Track                     [Page 5]
283
284RFC 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
3202.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
338Barbato                     Standards Track                     [Page 6]
339
340RFC 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
394Barbato                     Standards Track                     [Page 7]
395
396RFC 5215               Vorbis RTP Payload Format             August 2008
397
398
3992.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
4383.  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
450Barbato                     Standards Track                     [Page 8]
451
452RFC 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
4933.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
506Barbato                     Standards Track                     [Page 9]
507
508RFC 5215               Vorbis RTP Payload Format             August 2008
509
510
5113.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
562Barbato                     Standards Track                    [Page 10]
563
564RFC 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
618Barbato                     Standards Track                    [Page 11]
619
620RFC 5215               Vorbis RTP Payload Format             August 2008
621
622
6233.2.  Out of Band Transmission
624
625   The following packet definition MUST be used when Configuration is
626   inside in the SDP.
627
6283.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
674Barbato                     Standards Track                    [Page 12]
675
676RFC 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
7093.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
7194.  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
730Barbato                     Standards Track                    [Page 13]
731
732RFC 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
7625.  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
786Barbato                     Standards Track                    [Page 14]
787
788RFC 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
7955.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
842Barbato                     Standards Track                    [Page 15]
843
844RFC 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
898Barbato                     Standards Track                    [Page 16]
899
900RFC 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
9325.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
954Barbato                     Standards Track                    [Page 17]
955
956RFC 5215               Vorbis RTP Payload Format             August 2008
957
958
9596.  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
1010Barbato                     Standards Track                    [Page 18]
1011
1012RFC 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
10376.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
1066Barbato                     Standards Track                    [Page 19]
1067
1068RFC 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
11067.  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
11137.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
1122Barbato                     Standards Track                    [Page 20]
1123
1124RFC 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
11537.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
1178Barbato                     Standards Track                    [Page 21]
1179
1180RFC 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
11867.2.  Usage with the SDP Offer/Answer Model
1187
1188   There are no negotiable parameters.  All of them are declarative.
1189
11908.  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
12009.  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
12069.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
1234Barbato                     Standards Track                    [Page 22]
1235
1236RFC 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
124710.  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
125811.  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
126612.  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
1290Barbato                     Standards Track                    [Page 23]
1291
1292RFC 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
129913.  References
1300
130113.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
1346Barbato                     Standards Track                    [Page 24]
1347
1348RFC 5215               Vorbis RTP Payload Format             August 2008
1349
1350
135113.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
1367Author'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
1402Barbato                     Standards Track                    [Page 25]
1403
1404RFC 5215               Vorbis RTP Payload Format             August 2008
1405
1406
1407Full 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
1423Intellectual 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
1458Barbato                     Standards Track                    [Page 26]
1459
1460