4 AVT Working Group L. Barbato
6 Expires: August 20, 2008 Feb 17, 2008
9 RTP Payload Format for Vorbis Encoded Audio
10 draft-ietf-avt-rtp-vorbis-09
14 By submitting this Internet-Draft, each author represents that any
15 applicable patent or other IPR claims of which he or she is aware
16 have been or will be disclosed, and any of which he or she becomes
17 aware will be disclosed, in accordance with Section 6 of BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on August 20, 2008.
39 Copyright (C) The IETF Trust (2008).
43 This document describes an RTP payload format for transporting Vorbis
44 encoded audio. It details the RTP encapsulation mechanism for raw
45 Vorbis data and details the delivery mechanisms for the decoder
46 probability model, referred to as a codebook and other setup
49 Also included within this memo are media type registrations, and the
50 details necessary for the use of Vorbis with the Session Description
55 Barbato Expires August 20, 2008 [Page 1]
57 Internet-Draft Vorbis RTP Payload Format Feb 2008
62 All references to RFC XXXX are to be replaced by references to the
63 RFC number of this memo, when published.
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
68 1.1. Conformance and Document Conventions . . . . . . . . . . . 3
69 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3
70 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4
71 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
72 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
73 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 7
74 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
75 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
76 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9
77 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 11
78 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 11
79 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 12
80 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 12
81 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 13
82 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 14
83 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16
84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
85 6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 18
86 7. SDP related considerations . . . . . . . . . . . . . . . . . . 19
87 7.1. Mapping Media Type Parameters into SDP . . . . . . . . . . 20
88 7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 20
89 7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 21
90 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21
91 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
92 9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 21
93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
94 11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 22
95 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
96 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
97 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23
98 13.2. Informative References . . . . . . . . . . . . . . . . . . 23
111 Barbato Expires August 20, 2008 [Page 2]
113 Internet-Draft Vorbis RTP Payload Format Feb 2008
118 Vorbis is a general purpose perceptual audio codec intended to allow
119 maximum encoder flexibility, thus allowing it to scale competitively
120 over an exceptionally wide range of bitrates. At the high quality/
121 bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is
122 in the same league as MPEG-4 AAC. Vorbis is also intended for lower
123 and higher sample rates (from 8kHz telephony to 192kHz digital
124 masters) and a range of channel representations (monaural,
125 polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255
128 Vorbis encoded audio is generally encapsulated within an Ogg format
129 bitstream [11], which provides framing and synchronization. For the
130 purposes of RTP transport, this layer is unnecessary, and so raw
131 Vorbis packets are used in the payload.
133 1.1. Conformance and Document Conventions
135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
137 document are to be interpreted as described in BCP 14, [1] and
138 indicate requirement levels for compliant implementations.
139 Requirements apply to all implementations unless otherwise stated.
141 An implementation is a software module that supports one of the media
142 types defined in this document. Software modules may support
143 multiple media types, but conformance is considered individually for
146 Implementations that fail to satisfy one or more "MUST" requirements
147 are considered non-compliant. Implementations that satisfy all
148 "MUST" requirements, but fail to satisfy one or more "SHOULD"
149 requirements, are said to be "conditionally compliant". All other
150 implementations are "unconditionally compliant".
154 For RTP based transport of Vorbis encoded audio the standard RTP
155 header is followed by a 4 octets payload header, then the payload
156 data. The payload headers are used to associate the Vorbis data with
157 its associated decoding codebooks as well as indicating if the
158 following packet contains fragmented Vorbis data and/or the number of
159 whole Vorbis data frames. The payload data contains the raw Vorbis
160 bitstream information. There are 3 types of Vorbis data, an RTP
161 payload MUST contain just one of them at a time.
167 Barbato Expires August 20, 2008 [Page 3]
169 Internet-Draft Vorbis RTP Payload Format Feb 2008
174 The format of the RTP header is specified in [2] and shown in Figure
175 Figure 1. This payload format uses the fields of the header in a
176 manner consistent with that specification.
180 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
181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
182 |V=2|P|X| CC |M| PT | sequence number |
183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
186 | synchronization source (SSRC) identifier |
187 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
188 | contributing source (CSRC) identifiers |
190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
194 The RTP header begins with an octet of fields (V, P, X, and CC) to
195 support specialized RTP uses (see [2] and [3] for details). For
196 Vorbis RTP, the following values are used.
200 This field identifies the version of RTP. The version used by this
201 specification is two (2).
205 Padding MAY be used with this payload format according to section 5.1
210 The Extension bit is used in accordance with [2].
212 CSRC count (CC): 4 bits
214 The CSRC count is used in accordance with [2].
218 Set to zero. Audio silence suppression not used. This conforms to
223 Barbato Expires August 20, 2008 [Page 4]
225 Internet-Draft Vorbis RTP Payload Format Feb 2008
228 Payload Type (PT): 7 bits
230 An RTP profile for a class of applications is expected to assign a
231 payload type for this format, or a dynamically allocated payload type
232 SHOULD be chosen which designates the payload as Vorbis.
234 Sequence number: 16 bits
236 The sequence number increments by one for each RTP data packet sent,
237 and may be used by the receiver to detect packet loss and to restore
238 packet sequence. This field is detailed further in [2].
242 A timestamp representing the sampling time of the first sample of the
243 first Vorbis packet in the RTP payload. The clock frequency MUST be
244 set to the sample rate of the encoded audio data and is conveyed out-
245 of-band (e.g. as an SDP parameter).
247 SSRC/CSRC identifiers:
249 These two fields, 32 bits each with one SSRC field and a maximum of
250 16 CSRC fields, are as defined in [2].
254 The 4 octets following the RTP Header section are the Payload Header.
255 This header is split into a number of bitfields detailing the format
256 of the following payload data packets.
259 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
260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
261 | Ident | F |VDT|# pkts.|
262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
264 Figure 2: Payload Header
268 This 24 bit field is used to associate the Vorbis data to a decoding
269 Configuration. It is stored as network byte order integer.
271 Fragment type (F): 2 bits
273 This field is set according to the following list
279 Barbato Expires August 20, 2008 [Page 5]
281 Internet-Draft Vorbis RTP Payload Format Feb 2008
286 2 = Continuation Fragment
289 Vorbis Data Type (VDT): 2 bits
291 This field specifies the kind of Vorbis data stored in this RTP
292 packet. There are currently three different types of Vorbis
293 payloads. Each packet MUST contain only a single type of Vorbis
294 packet (e.g. you must not aggregate configuration and comment packets
295 in the same RTP payload)
297 0 = Raw Vorbis payload
298 1 = Vorbis Packed Configuration payload
299 2 = Legacy Vorbis Comment payload
302 The packets with a VDT of value 3 MUST be ignored
304 The last 4 bits represent the number of complete packets in this
305 payload. This provides for a maximum number of 15 Vorbis packets in
306 the payload. If the payload contains fragmented data the number of
307 packets MUST be set to 0.
311 Raw Vorbis packets are currently unbounded in length, application
312 profiles will likely define a practical limit. Typical Vorbis packet
313 sizes range from very small (2-3 bytes) to quite large (8-12
314 kilobytes). The reference implementation [12] typically produces
315 packets less than ~800 bytes, except for the setup header packets
316 which are ~4-12 kilobytes. Within an RTP context, to avoid
317 fragmentation, the Vorbis data packet size SHOULD be kept
318 sufficiently small so that after adding the RTP and payload headers,
319 the complete RTP packet is smaller than the path MTU.
322 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
323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
324 | length | vorbis packet data ..
325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
327 Figure 3: Payload Data Header
329 Each Vorbis payload packet starts with a two octet length header,
330 which is used to represent the size in bytes of the following data
331 payload, followed by the raw Vorbis data padded to the nearest byte
335 Barbato Expires August 20, 2008 [Page 6]
337 Internet-Draft Vorbis RTP Payload Format Feb 2008
340 boundary, as explained by the vorbis specification [10]. The length
341 value is stored as network byte order integer.
343 For payloads which consist of multiple Vorbis packets the payload
344 data consists of the packet length followed by the packet data for
345 each of the Vorbis packets in the payload.
347 The Vorbis packet length header is the length of the Vorbis data
348 block only and does not include the length field.
350 The payload packing of the Vorbis data packets MUST follow the
351 guidelines set-out in [3] where the oldest Vorbis packet occurs
352 immediately after the RTP packet header. Subsequent Vorbis packets,
353 if any, MUST follow in temporal order.
355 Channel mapping of the audio is in accordance with the Vorbis I
358 2.4. Example RTP Packet
360 Here is an example RTP payload containing two Vorbis packets.
363 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
364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
365 | 2 |0|0| 0 |0| PT | sequence number |
366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
367 | timestamp (in sample rate units) |
368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
369 | synchronisation source (SSRC) identifier |
370 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
371 | contributing source (CSRC) identifiers |
373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
375 | Ident | 0 | 0 | 2 pks |
376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
377 | length | vorbis data ..
378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
381 | length | next vorbis packet data ..
382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
391 Barbato Expires August 20, 2008 [Page 7]
393 Internet-Draft Vorbis RTP Payload Format Feb 2008
396 Figure 4: Example Raw Vorbis Packet
398 The payload data section of the RTP packet begins with the 24 bit
399 Ident field followed by the one octet bitfield header, which has the
400 number of Vorbis frames set to 2. Each of the Vorbis data frames is
401 prefixed by the two octets length field. The Packet Type and
402 Fragment Type are set to 0. The Configuration that will be used to
403 decode the packets is the one indexed by the ident value.
405 3. Configuration Headers
407 Unlike other mainstream audio codecs Vorbis has no statically
408 configured probability model. Instead, it packs all entropy decoding
409 configuration, Vector Quantization and Huffman models into a data
410 block that must be transmitted to the decoder along with the
411 compressed data. A decoder also requires information detailing the
412 number of audio channels, bitrates and similar information to
413 configure itself for a particular compressed data stream. These two
414 blocks of information are often referred to collectively as the
415 "codebooks" for a Vorbis stream, and are nominally included as
416 special "header" packets at the start of the compressed data. In
417 addition, the Vorbis I specification [10] requires the presence of a
418 comment header packet which gives simple metadata about the stream,
419 but this information is not required for decoding the frame sequence.
421 Thus these two codebook header packets must be received by the
422 decoder before any audio data can be interpreted. These requirements
423 pose problems in RTP, which is often used over unreliable transports.
425 Since this information must be transmitted reliably and, as the RTP
426 stream may change certain configuration data mid-session, there are
427 different methods for delivering this configuration data to a client,
428 both in-band and out-of-band which is detailed below. In order to
429 set up an initial state for the client application the configuration
430 MUST be conveyed via the signalling channel used to setup the
431 session. One example of such signalling is SDP [5] with the Offer/
432 Answer Model [8]. Changes to the configuration MAY be communicated
433 via a re-invite, conveying new SDP, or sent in-band in the RTP
434 channel. Implementations MUST support in-band delivery of updated
435 codebooks, and SHOULD support out-of-band codebook update using a new
436 SDP file. The changes may be due to different codebooks as well as
437 different bitrates of the RTP stream.
439 For non chained streams, the recommended Configuration delivery
440 method is inline the Packed Configuration (Section 3.1.1) in the SDP
441 as explained in the IANA considerations (Section 7.1).
443 The 24 bit Ident field is used to map which Configuration will be
447 Barbato Expires August 20, 2008 [Page 8]
449 Internet-Draft Vorbis RTP Payload Format Feb 2008
452 used to decode a packet. When the Ident field changes, it indicates
453 that a change in the stream has taken place. The client application
454 MUST have in advance the correct configuration and if the client
455 detects a change in the Ident value and does not have this
456 information it MUST NOT decode the raw Vorbis data associated until
457 it fetches the correct Configuration.
459 3.1. In-band Header Transmission
461 The Packed Configuration (Section 3.1.1) Payload is sent in-band with
462 the packet type bits set to match the Vorbis Data Type. Clients MUST
463 be capable of dealing with fragmentation and periodic re-transmission
464 of [14] the configuration headers. The RTP timestamp value MUST
465 reflect the transmission time of the first data packet for which this
466 configuration applies.
468 3.1.1. Packed Configuration
470 A Vorbis Packed Configuration is indicated with the Vorbis Data Type
471 field set to 1. Of the three headers defined in the Vorbis I
472 specification [10], the Identification and the Setup MUST be packed
473 as they are, while the comment header MAY be replaced with a dummy
476 The packed configuration follows a generic way to store Xiph codec
477 configurations: The first field stores the number of the following
478 packets minus one (count field), the next ones represent the size of
479 the headers (length fields), the headers immediately follow the list
480 of length fields. The size of the last header is implicit.
482 The count and the length fields are encoded using the following
483 logic: the data is in network byte order, every byte has the most
484 significant bit used as flag and the following 7 used to store the
485 value. The first N bit are to be taken, where N is number of bits
486 needed to represent the value, taken modulo 7, and stored in the
487 first byte. If there are more bits, the flag bit is set to 1 and the
488 subsequent 7bit are stored in the following byte, if there are
489 remaining bits set the flag to 1 and the same procedure is repeated.
490 The ending byte has the flag bit set to 0. In order to decode it is
491 enough to iterate over the bytes until the flag bit set to 0, for
492 every byte the data is added to the accumulated value multiplied by
495 The headers are packed in the same order they are present in ogg:
496 Identification, Comment, Setup.
498 The 2 byte length tag defines the length of the packed headers as the
499 sum of the Configuration, Comment and Setup lengths.
503 Barbato Expires August 20, 2008 [Page 9]
505 Internet-Draft Vorbis RTP Payload Format Feb 2008
509 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
510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
511 |V=2|P|X| CC |M| PT | xxxx |
512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
515 | synchronization source (SSRC) identifier |
516 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
517 | contributing source (CSRC) identifiers |
519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
523 | length | n. of headers | length1 |
524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
525 | length2 | Identification ..
526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
533 .. Identification | Comment ..
534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
541 .. Comment | Setup ..
542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
548 Figure 5: Packed Configuration Figure
550 The Ident field is set with the value that will be used by the Raw
551 Payload Packets to address this Configuration. The Fragment type is
552 set to 0 since the packet bears the full Packed configuration, the
553 number of packet is set to 1.
559 Barbato Expires August 20, 2008 [Page 10]
561 Internet-Draft Vorbis RTP Payload Format Feb 2008
564 3.2. Out of Band Transmission
566 The following packet definition MUST be used when Configuration is
569 3.2.1. Packed Headers
571 As mentioned above the RECOMMENDED delivery vector for Vorbis
572 configuration data is via a retrieval method that can be performed
573 using a reliable transport protocol. As the RTP headers are not
574 required for this method of delivery the structure of the
575 configuration data is slightly different. The packed header starts
576 with a 32 bit (network byte ordered) count field which details the
577 number of packed headers that are contained in the bundle. Next is
578 the Packed header payload for each chained Vorbis stream.
580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
581 | Number of packed headers |
582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
590 Figure 6: Packed Headers Overview
615 Barbato Expires August 20, 2008 [Page 11]
617 Internet-Draft Vorbis RTP Payload Format Feb 2008
621 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
622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
625 .. | n. of headers | length1 | length2 ..
626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
627 .. | Identification Header ..
628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
629 .................................................................
630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
631 .. | Comment Header ..
632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
633 .................................................................
634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
639 .................................................................
640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
644 Figure 7: Packed Headers Detail
646 The key difference between the in-band format and this one, is that
647 there is no need for the payload header octet. In this figure the
648 comment has a size bigger than 127 bytes.
650 3.3. Loss of Configuration Headers
652 Unlike the loss of raw Vorbis payload data, loss of a configuration
653 header lead to a situation where it will not be possible to
654 successfully decode the stream. Implementations MAY try to recover
655 from error by requesting again the missing Configuration or, if the
656 delivery method is in-band, by buffering the payloads waiting for the
657 Configuration needed to decode them. The baseline reaction SHOULD be
658 either reset or end the RTP session.
662 With the Vorbis Data Type flag set to 2, this indicates that the
663 packet contain the comment metadata, such as artist name, track title
664 and so on. These metadata messages are not intended to be fully
665 descriptive but to offer basic track/song information. Clients MAY
666 ignore it completely. The details on the format of the comments can
667 be found in the Vorbis documentation [10].
671 Barbato Expires August 20, 2008 [Page 12]
673 Internet-Draft Vorbis RTP Payload Format Feb 2008
677 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
678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
679 |V=2|P|X| CC |M| PT | xxxx |
680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
683 | synchronization source (SSRC) identifier |
684 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
685 | contributing source (CSRC) identifiers |
687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
691 | length | Comment ..
692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
698 Figure 8: Comment Packet
700 The 2 bytes length field is necessary since this packet could be
703 5. Frame Packetization
705 Each RTP payload contains either one Vorbis packet fragment, or an
706 integer number of complete Vorbis packets (up to a maximum of 15
707 packets, since the number of packets is defined by a 4 bit value).
709 Any Vorbis data packet that is less than path MTU SHOULD be bundled
710 in the RTP payload with as many Vorbis packets as will fit, up to a
711 maximum of 15, except when such bundling would exceed an
712 application's desired transmission latency. Path MTU is detailed in
715 A fragmented packet has a zero in the last four bits of the payload
716 header. The first fragment will set the Fragment type to 1. Each
717 fragment after the first will set the Fragment type to 2 in the
718 payload header. The consecutive fragments MUST be sent without any
719 other payloads being sent between the first and the last fragment.
720 The RTP payload containing the last fragment of the Vorbis packet
721 will have the Fragment type set to 3. To maintain the correct
722 sequence for fragmented packet reception the timestamp field of
723 fragmented packets MUST be the same as the first packet sent, with
727 Barbato Expires August 20, 2008 [Page 13]
729 Internet-Draft Vorbis RTP Payload Format Feb 2008
732 the sequence number incremented as normal for the subsequent RTP
733 payloads, this will affect the RTCP jitter measurement. The length
734 field shows the fragment length.
736 5.1. Example Fragmented Vorbis Packet
738 Here is an example fragmented Vorbis packet split over three RTP
739 payloads. Each of them contains the standard RTP headers as well as
740 the 4 octets Vorbis headers.
745 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
746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
747 |V=2|P|X| CC |M| PT | 1000 |
748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
751 | synchronization source (SSRC) identifier |
752 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
753 | contributing source (CSRC) identifiers |
755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
759 | length | vorbis data ..
760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
764 Figure 9: Example Fragmented Packet (Packet 1)
766 In this payload the initial sequence number is 1000 and the timestamp
767 is 12345. The Fragment type is set to 1, the number of packets field
768 is set to 0, and as the payload is raw Vorbis data the VDT field is
783 Barbato Expires August 20, 2008 [Page 14]
785 Internet-Draft Vorbis RTP Payload Format Feb 2008
791 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
792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
793 |V=2|P|X| CC |M| PT | 1001 |
794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
797 | synchronization source (SSRC) identifier |
798 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
799 | contributing source (CSRC) identifiers |
801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
805 | length | vorbis data ..
806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
810 Figure 10: Example Fragmented Packet (Packet 2)
812 The Fragment type field is set to 2 and the number of packets field
813 is set to 0. For large Vorbis fragments there can be several of this
814 type of payloads. The maximum packet size SHOULD be no greater than
815 the path MTU, including all RTP and payload headers. The sequence
816 number has been incremented by one but the timestamp field remains
817 the same as the initial payload.
839 Barbato Expires August 20, 2008 [Page 15]
841 Internet-Draft Vorbis RTP Payload Format Feb 2008
847 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
848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
849 |V=2|P|X| CC |M| PT | 1002 |
850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
853 | synchronization source (SSRC) identifier |
854 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
855 | contributing source (CSRC) identifiers |
857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
861 | length | vorbis data ..
862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
866 Figure 11: Example Fragmented Packet (Packet 3)
868 This is the last Vorbis fragment payload. The Fragment type is set
869 to 3 and the packet count remains set to 0. As in the previous
870 payloads the timestamp remains set to the first payload timestamp in
871 the sequence and the sequence number has been incremented.
875 As there is no error correction within the Vorbis stream, packet loss
876 will result in a loss of signal. Packet loss is more of an issue for
877 fragmented Vorbis packets as the client will have to cope with the
878 handling of the Fragment Type. In case of loss of fragments the
879 client MUST discard all the remaining Vorbis fragments and decode the
880 incomplete packet. If we use the fragmented Vorbis packet example
881 above and the first RTP payload is lost the client MUST detect that
882 the next RTP payload has the packet count field set to 0 and the
883 Fragment type 2 and MUST drop it. The next RTP payload, which is the
884 final fragmented packet, MUST be dropped in the same manner. If the
885 missing RTP payload is the last, the received two fragments will be
886 kept and the incomplete Vorbis packet decoded.
888 Loss of any of the Configuration fragment will result in the loss of
889 the full Configuration packet with the result detailed in the Loss of
890 Configuration Headers (Section 3.3) section.
895 Barbato Expires August 20, 2008 [Page 16]
897 Internet-Draft Vorbis RTP Payload Format Feb 2008
900 6. IANA Considerations
908 rate: indicates the RTP timestamp clock rate as described in RTP
909 Profile for Audio and Video Conferences with Minimal Control.
912 channels: indicates the number of audio channels as described in
913 RTP Profile for Audio and Video Conferences with Minimal
916 configuration: the base64 [9] representation of the Packed
917 Headers (Section 3.2.1).
919 Encoding considerations:
921 This media type is framed and contains binary data.
923 Security considerations:
925 See Section 10 of RFC XXXX.
927 Interoperability considerations:
931 Published specification:
933 RFC XXXX [RFC Editor: please replace by the RFC number of this
934 memo, when published]
936 Ogg Vorbis I specification: Codec setup and packet decode.
937 Available from the Xiph website, http://xiph.org
939 Applications which use this media type:
941 Audio streaming and conferencing tools
943 Additional information:
951 Barbato Expires August 20, 2008 [Page 17]
953 Internet-Draft Vorbis RTP Payload Format Feb 2008
956 Person & email address to contact for further information:
958 Luca Barbato: <lu_zero@gentoo.org> IETF Audio/Video Transport
965 Restriction on usage:
967 This media type depends on RTP framing, and hence is only defined
968 for transfer via RTP [2]
976 IETF AVT Working Group delegated from the IESG
979 6.1. Packed Headers IANA Considerations
981 The following IANA considerations refers to the split configuration
982 Packed Headers (Section 3.2.1) used within RFC XXXX.
986 Subtype name: vorbis-config
996 Encoding considerations:
998 This media type contains binary data.
1007 Barbato Expires August 20, 2008 [Page 18]
1009 Internet-Draft Vorbis RTP Payload Format Feb 2008
1012 Security considerations:
1014 See Section 10 of RFC XXXX.
1016 Interoperability considerations:
1020 Published specification:
1022 RFC XXXX [RFC Editor: please replace by the RFC number of this
1023 memo, when published]
1025 Applications which use this media type:
1027 Vorbis encoded audio, configuration data.
1029 Additional information:
1033 Person & email address to contact for further information:
1035 Luca Barbato: <lu_zero@gentoo.org>
1036 IETF Audio/Video Transport Working Group
1038 Intended usage: COMMON
1040 Restriction on usage:
1042 This media type doesn't depend on the transport.
1050 IETF AVT Working Group delegated from the IESG
1052 7. SDP related considerations
1054 The following paragraphs define the mapping of the parameters
1055 described in the IANA considerations section and their usage in the
1056 Offer/Answer Model [8]. In order to be forward compatible the
1057 implementation MUST ignore unknown parameters.
1063 Barbato Expires August 20, 2008 [Page 19]
1065 Internet-Draft Vorbis RTP Payload Format Feb 2008
1068 7.1. Mapping Media Type Parameters into SDP
1070 The information carried in the Media Type specification has a
1071 specific mapping to fields in the Session Description Protocol (SDP)
1072 [5], which is commonly used to describe RTP sessions. When SDP is
1073 used to specify sessions the mapping are as follows:
1075 o The type name ("audio") goes in SDP "m=" as the media name.
1077 o The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding
1080 o The parameter "rate" also goes in "a=rtpmap" as clock rate.
1082 o The parameter "channels" also goes in "a=rtpmap" as channel count.
1084 o The mandated parameters "configuration" MUST be included in the
1085 SDP "a=fmtp" attribute.
1088 If the stream comprises chained Vorbis files and all of them are
1089 known in advance, the Configuration Packet for each file SHOULD be
1090 passed to the client using the configuration attribute.
1092 The port value is specified by the server application bound to the
1093 address specified in the c= line. The channel count value specified
1094 in the rtpmap attribute SHOULD match the current Vorbis stream or
1095 considered the maximum number of channels to be expected. The
1096 timestamp clock rate MUST be a multiple of the sample rate, different
1097 payload number MUST be used if the clock rate changes. The
1098 Configuration payload delivers the exact information, thus the SDP
1099 information SHOULD be considered as a hint. An example is found
1104 The following example shows a basic SDP single stream. The first
1105 configuration packet is inlined in the SDP, other configurations
1106 could be fetched at any time from the URIs provided. The inline
1107 base64 [9] configuration string is folded in this example due to RFC
1108 line length limitations.
1111 a=rtpmap:98 vorbis/44100/2
1112 a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...;
1114 Note that the payload format (encoding) names are commonly shown in
1115 upper case. Media Type subtypes are commonly shown in lower case.
1119 Barbato Expires August 20, 2008 [Page 20]
1121 Internet-Draft Vorbis RTP Payload Format Feb 2008
1124 These names are case-insensitive in both places. Similarly,
1125 parameter names are case-insensitive both in Media Type types and in
1126 the default mapping to the SDP a=fmtp attribute. The a=fmtp line is
1127 a single line even if it is shown as multiple lines in this document
1130 7.2. Usage with the SDP Offer/Answer Model
1132 The are no negotiable parameters. All the of them are declarative.
1134 8. Congestion Control
1136 The general congestion control considerations for transporting RTP
1137 data apply to vorbis audio over RTP as well. See the RTP
1138 specification [2] and any applicable RTP profile (e.g., [3]). Audio
1139 data can be encoded using a range of different bit rates, so it is
1140 possible to adapt network bandwidth by adjusting the encoder bit rate
1141 in real time or by having multiple copies of content encoded at
1142 different bit rates.
1146 The following example shows a common usage pattern that MAY be
1147 applied in such situation, the main scope of this section is to
1148 explain better usage of the transmission vectors.
1152 This is one of the most common situation: one single server streaming
1153 content in multicast, the clients may start a session at random time.
1154 The content itself could be a mix of live stream, as the webjockey's
1155 voice, and stored streams as the music she plays.
1157 In this situation we don't know in advance how many codebooks we will
1158 use. The clients can join anytime and users expect to start
1159 listening to the content in a short time.
1161 On join the client will receive the current Configuration necessary
1162 to decode the current stream inlined in the SDP so that the decoding
1163 will start immediately after.
1165 When the streamed content changes the new Configuration is sent in-
1166 band before the actual stream and the Configuration that has to be
1167 sent inline in the SDP updated. Since the in-band method is
1168 unreliable, an out of band fallback is provided.
1170 The client may choose to fetch the Configuration from the alternate
1171 source as soon as it discovers a Configuration packet got lost in-
1175 Barbato Expires August 20, 2008 [Page 21]
1177 Internet-Draft Vorbis RTP Payload Format Feb 2008
1180 band or use selective retransmission [13], if the server supports the
1183 A serverside optimization would be to keep an hash list of the
1184 Configurations per session to avoid packing all of them and send the
1185 same Configuration with different Ident tags
1187 A clientside optimization would be to keep a tag list of the
1188 Configurations per session and don't process configuration packets
1191 10. Security Considerations
1193 RTP packets using this payload format are subject to the security
1194 considerations discussed in the RTP specification [2], the base64
1195 specification [9] and the URI Generic syntax specification [4].
1196 Among other considerations, this implies that the confidentiality of
1197 the media stream is archieved by using encryption. Because the data
1198 compression used with this payload format is applied end-to-end,
1199 encryption may be performed on the compressed data.
1201 11. Copying Conditions
1203 The authors agree to grant third parties the irrevocable right to
1204 copy, use and distribute the work, with or without modification, in
1205 any medium, without royalty, provided that, unless separate
1206 permission is granted, redistributed modified works do not contain
1207 misleading author, version, name of work, or endorsement information.
1211 This document is a continuation of draft-moffitt-vorbis-rtp-00.txt
1212 and draft-kerr-avt-vorbis-rtp-04.txt. The Media Type declaration is
1213 a continuation of draft-short-avt-rtp-vorbis-mime-00.txt.
1215 Thanks to the AVT, Vorbis Communities / Xiph.Org Foundation including
1216 Steve Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia,
1217 Pascal Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John
1218 Lazzaro, Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry
1219 Short, Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund,
1220 David Barrett, Silvia Pfeiffer, Stefan Ehmann, Alessandro Salvatori.
1221 Politecnico di Torino (LS)^3/IMG Group in particular Federico
1222 Ridolfo, Francesco Varano, Giampaolo Mancini, Dario Gallucci, Juan
1231 Barbato Expires August 20, 2008 [Page 22]
1233 Internet-Draft Vorbis RTP Payload Format Feb 2008
1236 13.1. Normative References
1238 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1241 [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
1242 "RTP: A Transport Protocol for real-time applications", STD 64,
1245 [3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
1246 Conferences with Minimal Control.", STD 65, RFC 3551.
1248 [4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1249 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986.
1251 [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
1252 Description Protocol", RFC 4566, July 2006.
1254 [6] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
1257 [7] McCann et al., J., "Path MTU Discovery for IP version 6",
1260 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
1261 Session Description Protocol (SDP)", RFC 3264.
1263 [9] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
1266 [10] "Ogg Vorbis I specification: Codec setup and packet decode.
1267 Available from the Xiph website,
1268 http://xiph.org/vorbis/doc/Vorbis_I_spec.html".
1270 13.2. Informative References
1272 [11] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
1275 [12] "libvorbis: Available from the dedicated website,
1278 [13] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
1279 Extended Reports (RTCP XR)", RFC 3611, November 2003.
1281 [14] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg,
1282 "RTP Retransmission Payload Format", RFC 4588, July 2006.
1287 Barbato Expires August 20, 2008 [Page 23]
1289 Internet-Draft Vorbis RTP Payload Format Feb 2008
1297 EMail: lu_zero@gentoo.org
1298 URI: http://xiph.org/
1343 Barbato Expires August 20, 2008 [Page 24]
1345 Internet-Draft Vorbis RTP Payload Format Feb 2008
1348 Full Copyright Statement
1350 Copyright (C) The IETF Trust (2008).
1352 This document is subject to the rights, licenses and restrictions
1353 contained in BCP 78, and except as set forth therein, the authors
1354 retain all their rights.
1356 This document and the information contained herein are provided on an
1357 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1358 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1359 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1360 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1361 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1362 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1364 Intellectual Property
1366 The IETF takes no position regarding the validity or scope of any
1367 Intellectual Property Rights or other rights that might be claimed to
1368 pertain to the implementation or use of the technology described in
1369 this document or the extent to which any license under such rights
1370 might or might not be available; nor does it represent that it has
1371 made any independent effort to identify any such rights. Information
1372 on the procedures with respect to rights in RFC documents can be
1373 found in BCP 78 and BCP 79.
1375 Copies of IPR disclosures made to the IETF Secretariat and any
1376 assurances of licenses to be made available, or the result of an
1377 attempt made to obtain a general license or permission for the use of
1378 such proprietary rights by implementers or users of this
1379 specification can be obtained from the IETF on-line IPR repository at
1380 http://www.ietf.org/ipr.
1382 The IETF invites any interested party to bring to its attention any
1383 copyrights, patents or patent applications, or other proprietary
1384 rights that may cover technology that may be required to implement
1385 this standard. Please address the information to the IETF at
1390 Funding for the RFC Editor function is provided by the IETF
1391 Administrative Support Activity (IASA).
1399 Barbato Expires August 20, 2008 [Page 25]