VirtualBox

source: vbox/trunk/src/libs/libvorbis-1.3.7/doc/rfc5215.txt@ 107044

Last change on this file since 107044 was 96468, checked in by vboxsync, 2 years ago

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

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette