4 AVT Working Group L. Barbato
5 Internet-Draft Xiph.Org
6 Expires: April 24, 2006 October 21, 2005
9 draft-kerr-avt-vorbis-rtp-05
10 RTP Payload Format for Vorbis Encoded Audio
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 April 24, 2006.
39 Copyright (C) The Internet Society (2005).
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 the document are the necessary details for the
50 use of Vorbis with MIME and Session Description Protocol (SDP).
55 Barbato Expires April 24, 2006 [Page 1]
57 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
62 All references to RFC XXXX are to be replaced by references to the
63 RFC number of this memo, when published.
68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
70 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3
71 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 3
72 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
73 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
74 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 7
75 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
76 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
77 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9
78 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 10
79 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 10
80 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 12
81 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13
82 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 13
83 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 14
84 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16
85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
86 6.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 18
87 6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 19
88 7. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 20
89 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
90 8.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 20
91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
92 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
95 11.2. Informative References . . . . . . . . . . . . . . . . . . 22
96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
97 Intellectual Property and Copyright Statements . . . . . . . . . . 24
111 Barbato Expires April 24, 2006 [Page 2]
113 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
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-2 and MPC. Similarly, the version 1.1
123 reference encoder can encode high-quality CD and DAT rate stereo at
124 below 48k bits/sec without resampling to a lower rate. Vorbis is
125 also intended for lower and higher sample rates (from 8kHz telephony
126 to 192kHz digital masters) and a range of channel representations
127 (monaural, polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to
128 255 discrete channels).
130 Vorbis encoded audio is generally encapsulated within an Ogg format
131 bitstream [1], which provides framing and synchronization. For the
132 purposes of RTP transport, this layer is unnecessary, and so raw
133 Vorbis packets are used in the payload.
137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
139 document are to be interpreted as described in RFC 2119 [2].
144 For RTP based transportation of Vorbis encoded audio the standard RTP
145 header is followed by a 4 octet payload header, then the payload
146 data. The payload headers are used to associate the Vorbis data with
147 its associated decoding codebooks as well as indicating if the
148 following packet contains fragmented Vorbis data and/or the the
149 number of whole Vorbis data frames. The payload data contains the
150 raw Vorbis bitstream information.
154 The format of the RTP header is specified in [3] and shown in Figure
155 Figure 1. This payload format uses the fields of the header in a
156 manner consistent with that specification.
167 Barbato Expires April 24, 2006 [Page 3]
169 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
173 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
174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
175 |V=2|P|X| CC |M| PT | sequence number |
176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
179 | synchronization source (SSRC) identifier |
180 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
181 | contributing source (CSRC) identifiers |
183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
187 The RTP header begins with an octet of fields (V, P, X, and CC) to
188 support specialized RTP uses (see [3] and [4] for details). For
189 Vorbis RTP, the following values are used.
193 This field identifies the version of RTP. The version used by this
194 specification is two (2).
198 Padding MAY be used with this payload format according to section 5.1
203 The Extension bit is used in accordance with [3].
205 CSRC count (CC): 4 bits
207 The CSRC count is used in accordance with [3].
211 Set to zero. Audio silence suppression not used. This conforms to
214 Payload Type (PT): 7 bits
216 An RTP profile for a class of applications is expected to assign a
217 payload type for this format, or a dynamically allocated payload type
218 SHOULD be chosen which designates the payload as Vorbis.
223 Barbato Expires April 24, 2006 [Page 4]
225 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
228 Sequence number: 16 bits
230 The sequence number increments by one for each RTP data packet sent,
231 and may be used by the receiver to detect packet loss and to restore
232 packet sequence. This field is detailed further in [3].
236 A timestamp representing the sampling time of the first sample of the
237 first Vorbis packet in the RTP packet. The clock frequency MUST be
238 set to the sample rate of the encoded audio data and is conveyed out-
239 of-band as a SDP parameter.
241 SSRC/CSRC identifiers:
243 These two fields, 32 bits each with one SSRC field and a maximum of
244 16 CSRC fields, are as defined in [3].
248 After the RTP Header section the following 4 octets are the Payload
249 Header. This header is split into a number of bitfields detailing
250 the format of the following payload data packets.
253 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
254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
255 | Ident | F |VDT|# pkts.|
256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
258 Figure 2: Payload Header
262 This 24 bit field is used to associate the Vorbis data to a decoding
265 Fragment type (F): 2 bits
267 This field is set accordingly the following list
271 2 = Continuation Fragment
274 Vorbis Data Type (VDT): 2 bits
279 Barbato Expires April 24, 2006 [Page 5]
281 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
284 This field sets the payload type for the Vorbis data in this RTP
285 packet. There are currently three type of Vorbis payloads.
287 0 = Raw Vorbis payload
288 1 = Vorbis Packed Configuration payload
289 2 = Legacy Vorbis Comment payload
292 The last 4 bits are the number of complete packets in this payload.
293 This provides for a maximum number of 15 Vorbis packets in the
294 payload. If the packet contains fragmented data the number of
295 packets MUST be set to 0.
299 Raw Vorbis packets are unbounded in length currently, although at
300 some future point application profiles will likely define a practical
301 limit. Typical Vorbis packet sizes are from very small (2-3 bytes)
302 to quite large (8-12 kilobytes). The reference implementation [14]
303 typically produces packets less than ~800 bytes, except for the setup
304 header packets which are ~4-12 kilobytes. Within an RTP context, to
305 avoid fragmentation, the Vorbis data packet size SHOULD be kept
306 sufficiently small so that after adding the the RTP and payload
307 headers, the complete RTP packet is smaller than the path MTU.
310 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
311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
312 | length | vorbis packet data ..
313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
315 Figure 3: Payload Data Header
317 Each Vorbis payload packet starts with a two octet length header,
318 which is used to represent the size of the following data payload,
319 followed by the raw Vorbis data padded to the nearest byte boundary.
321 For payloads which consist of multiple Vorbis packets the payload
322 data consists of the packet length followed by the packet data for
323 each of the Vorbis packets in the payload.
325 The Vorbis packet length header is the length of the Vorbis data
326 block only and does not count the length field.
328 The payload packing of the Vorbis data packets MUST follow the
329 guidelines set-out in [4] where the oldest packet occurs immediately
330 after the RTP packet header. Subsequence packets, if any, MUST
331 follow in temporal order.
335 Barbato Expires April 24, 2006 [Page 6]
337 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
340 Channel mapping of the audio is in accordance with the Vorbis I
343 2.4. Example RTP Packet
345 Here is an example RTP packet containing two Vorbis packets.
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 | 2 |0|0| 0 |0| PT | sequence number |
353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
354 | timestamp (in sample rate units) |
355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
356 | synchronisation source (SSRC) identifier |
357 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
358 | contributing source (CSRC) identifiers |
360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
362 Figure 4: Example Packet (RTP Headers)
367 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
368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
369 | Ident | 0 | 0 | 2 pks |
370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
371 | length | vorbis data ..
372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
375 | length | next vorbis packet data ..
376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
380 Figure 5: Example Packet (Payload Data)
382 The payload data section of the RTP packet starts with the 24 bit
383 Ident field followed by the one octet bitfield header, which has the
384 number of Vorbis frames set to 2. Each of the Vorbis data frames is
385 prefixed by the two octet length field. The Packet Type and Fragment
386 Type are set to 0. The decode Configuration that will be used to
387 decode the packets is the one indexed by the ident value.
391 Barbato Expires April 24, 2006 [Page 7]
393 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
396 3. Configuration Headers
398 Unlike other mainstream audio codecs Vorbis has no statically
399 configured probability model. Instead, it packs all entropy decoding
400 configuration, VQ and Huffman models into a data block that must be
401 transmitted to the decoder along with the compressed data. A decoder
402 also requires information detailing the number of audio channels,
403 bitrates and similar information to configure itself for a particular
404 compressed data stream. These two blocks of information are often
405 referred to collectively as the "codebooks" for a Vorbis stream, and
406 are nominally included as special "header" packets at the start of
407 the compressed data. In addition, the Vorbis I specification [15]
408 requires the presence of a comment header packet which gives simple
409 metadata about the stream, but this information is not required for
410 decoding the frame sequence.
412 Thus these two codebook header packets must be received by the
413 decoder before any audio data can be interpreted. These requirements
414 pose problems in RTP, which is often used over unreliable transports.
416 Since this information must be transmitted reliably and, as the RTP
417 stream may change certain configuration data mid-session, there are
418 different methods for delivering this configuration data to a client,
419 both in-band and out-of-band which is detailed below. SDP delivery
420 is used to set up an initial state for the client application. The
421 changes may be due to different codebooks as well as different
422 bitrates of the stream.
424 The delivery vectors in use are specified by an SDP attribute to
425 indicate the method and the optional URI where the Vorbis Packed
426 Configuration (Section 3.1.1) Packets could be fetched. Different
427 delivery methods MAY be advertised for the same session. The in-band
428 Configuration delivery SHOULD be considered as baseline, out-of-band
429 delivery methods that don't use RTP will not be described in this
430 document. For non chained streams, the Configuration recommended
431 delivery method is inline the Packed Configuration (Section 3.1.1) in
432 the SDP as explained in the IANA considerations (Section 6.1)
435 The 24 bit Ident field is used to map which Configuration will be
436 used to decode a packet. When the Ident field changes, it indicates
437 that a change in the stream has taken place. The client application
438 MUST have in advance the correct configuration and if the client
439 detects a change in the Ident value and does not have this
440 information it MUST NOT decode the raw Vorbis data associated until
441 it fetches the correct Configuration.
447 Barbato Expires April 24, 2006 [Page 8]
449 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
452 3.1. In-band Header Transmission
454 The Packed Configuration (Section 3.1.1) Payload is sent in-band with
455 the packet type bits set to match the payload type. Clients MUST be
456 capable of dealing with fragmentation and periodic re-transmission of
457 the configuration headers.
459 3.1.1. Packed Configuration
461 A Vorbis Packed Configuration is indicated with the payload type
462 field set to 1. Of the three headers, defined in the Vorbis I
463 specification [15], the identification and the setup will be packed
464 together, the comment header is completely suppressed. Is up to the
465 client provide a minimal size comment header to the decoder if
466 required by the implementation.
469 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
470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
471 |V=2|P|X| CC |M| PT | xxxx |
472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
475 | synchronization source (SSRC) identifier |
476 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
477 | contributing source (CSRC) identifiers |
479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
483 | length | Identification ..
484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
498 Figure 6: Packed Configuration Figure
503 Barbato Expires April 24, 2006 [Page 9]
505 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
508 The Ident field is set with the value that will be used by the Raw
509 Payload Packets to address this Configuration. The Fragment type is
510 set to 0 since the packet bears the full Packed configuration, the
511 number of packet is set to 1.
513 3.2. Out of Band Transmission
515 This section, as stated above, does not cover all the possible out-
516 of-band delivery methods since they rely to different protocols and
517 are linked to specific applications. The following packet definition
518 SHOULD be used in out-of-band delivery and MUST be used when
519 Configuration is inlined in the SDP.
521 3.2.1. Packed Headers
523 As mentioned above the RECOMMENDED delivery vector for Vorbis
524 configuration data is via a retrieval method that can be performed
525 using a reliable transport protocol. As the RTP headers are not
526 required for this method of delivery the structure of the
527 configuration data is slightly different. The packed header starts
528 with a 32 bit count field which details the number of packed headers
529 that are contained in the bundle. Next is the Packed header payload
530 for each chained Vorbis stream.
532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
533 | Number of packed headers |
534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
542 Figure 7: Packed Headers Overview
544 Since the Configuration Ident and the Identification Header are fixed
545 length there is only a 2 byte length tag to define the length of the
559 Barbato Expires April 24, 2006 [Page 10]
561 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
565 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
566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
569 .. length | Identification Header ..
570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
571 .. Identification Header |
572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
578 Figure 8: Packed Headers Detail
580 The key difference between the in-band format and this one, is there
581 is no need for the payload header octet.
583 3.2.1.1. Packed Headers IANA Considerations
585 The following IANA considerations MUST only be applied to the packed
588 MIME media type name: audio
590 MIME subtype: vorbis-config
600 Encoding considerations:
602 This media type contains binary data.
604 Security Considerations:
606 See Section 6 of RFC XXXX.
615 Barbato Expires April 24, 2006 [Page 11]
617 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
620 Interoperability considerations:
624 Published specification:
626 RFC XXXX [RFC Editor: please replace by the RFC number of this
627 memo, when published]
629 Applications which use this media type:
631 Vorbis encoded audio, configuration data.
633 Additional information:
637 Person & email address to contact for further information:
639 Luca Barbato: <lu_zero@gentoo.org>
640 IETF Audio/Video Transport Working Group
642 Intended usage: COMMON
644 Restriction on usage:
646 This media type doesn't depend on the transport.
654 IETF AVT Working Group
656 3.3. Loss of Configuration Headers
658 Unlike the loss of raw Vorbis payload data, loss of a configuration
659 header can lead to a situation where it will not be possible to
660 successfully decode the stream.
662 Loss of Configuration Packet results in the halting of stream
663 decoding and SHOULD be reported to the client as well as a loss
664 report sent via RTCP.
671 Barbato Expires April 24, 2006 [Page 12]
673 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
678 With the payload type flag set to 2, this indicates that the packet
679 contain the comment metadata, such as artist name, track title and so
680 on. These metadata messages are not intended to be fully descriptive
681 but to offer basic track/song information. Clients MAY ignore it
682 completely. The details on the format of the comments can be found
683 in the Vorbis documentation [15].
686 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
687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
688 |V=2|P|X| CC |M| PT | xxxx |
689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
692 | synchronization source (SSRC) identifier |
693 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
694 | contributing source (CSRC) identifiers |
696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
700 | length | Comment ..
701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
707 Figure 9: Comment Packet
709 The 2 bytes length field is necessary since this packet could be
713 5. Frame Packetization
715 Each RTP packet contains either one Vorbis packet fragment, or an
716 integer number of complete Vorbis packets (up to a maximum of 15
717 packets, since the number of packets is defined by a 4 bit value).
719 Any Vorbis data packet that is less than path MTU SHOULD be bundled
720 in the RTP packet with as many Vorbis packets as will fit, up to a
721 maximum of 15, except when such bundling would exceed an
722 application's desired transmission latency. Path MTU is detailed in
727 Barbato Expires April 24, 2006 [Page 13]
729 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
732 If a Vorbis packet, not only data but also Configuration and Comment,
733 is larger than 65535 octets it MUST be fragmented. A fragmented
734 packet has a zero in the last four bits of the payload header. The
735 first fragment will set the Fragment type to 1. Each fragment after
736 the first will set the Fragment type to 2 in the payload header. The
737 RTP packet containing the last fragment of the Vorbis packet will
738 have the Fragment type set to 3. To maintain the correct sequence
739 for fragmented packet reception the timestamp field of fragmented
740 packets MUST be the same as the first packet sent, with the sequence
741 number incremented as normal for the subsequent RTP packets. The
742 length field shows the fragment length.
744 5.1. Example Fragmented Vorbis Packet
746 Here is an example fragmented Vorbis packet split over three RTP
747 packets. Each packet contains the standard RTP headers as well as
748 the 4 octet Vorbis headers.
753 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
754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
755 |V=2|P|X| CC |M| PT | 1000 |
756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
759 | synchronization source (SSRC) identifier |
760 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
761 | contributing source (CSRC) identifiers |
763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
767 | length | vorbis data ..
768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
772 Figure 10: Example Fragmented Packet (Packet 1)
774 In this packet the initial sequence number is 1000 and the timestamp
775 is xxxxx. The Fragment type is set to 1, the number of packets field
776 is set to 0, and as the payload is raw Vorbis data the VDT field is
783 Barbato Expires April 24, 2006 [Page 14]
785 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
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 11: 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
814 these type of payload packets. The maximum packet size SHOULD be no
815 greater than the path MTU, including all RTP and payload headers.
816 The sequence number has been incremented by one but the timestamp
817 field remains the same as the initial packet.
839 Barbato Expires April 24, 2006 [Page 15]
841 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
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 12: Example Fragmented Packet (Packet 3)
868 This is the last Vorbis fragment packet. The Fragment type is set to
869 3 and the packet count remains set to 0. As in the previous packets
870 the timestamp remains set to the first packet in the sequence and the
871 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 fragments and decode the
880 incomplete packet. If we use the fragmented Vorbis packet example
881 above and the first packet is lost the client MUST detect that the
882 next packet has the packet count field set to 0 and the Fragment type
883 2 and MUST drop it. The next packet, which is the final fragmented
884 packet, MUST be dropped in the same manner. If the missing packet is
885 the last, the received two fragments will be kept and the incomplete
886 vorbis packet decoded. Feedback reports on lost and dropped packets
887 MUST be sent back via RTCP.
889 If a particular multicast session has a large number of participants
890 care must be taken to prevent an RTCP feedback implosion, [10], in
891 the event of packet loss from a large number of participants.
895 Barbato Expires April 24, 2006 [Page 16]
897 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
900 Loss of any of the Configuration fragment will result in the loss of
901 the full Configuration packet with the result detailed in the Loss of
902 Configuration Headers (Section 3.3) section.
905 6. IANA Considerations
907 MIME media type name: audio
913 delivery-method: indicates the delivery methods in use, the
914 possible values are: inline, in_band, out_band/specific_name
915 Where "specific_name" is the name of the out of band delivery
918 configuration: the base16 [9] (hexadecimal) representation of the
919 Packed Headers (Section 3.2.1).
923 configuration-uri: the URI of the configuration headers in case of
924 out of band transmission. In the form of
925 "protocol://path/to/resource/". Depending on the specific
926 method the single ident packet could be retrived by their
927 number, or aggregated in a single stream, aggregates MAY be
928 compressed using bzip2 [13] or gzip [11] and an sha1 [12]
929 checksum MAY be provided in the form of
930 "protocol://path/to/resource/! sha1hash"
932 Encoding considerations:
934 This media type is framed and contains binary data.
936 Security Considerations:
938 See Section 6 of RFC XXXX.
940 Interoperability considerations:
951 Barbato Expires April 24, 2006 [Page 17]
953 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
956 Published specification:
958 RFC XXXX [RFC Editor: please replace by the RFC number of this
959 memo, when published]
961 Ogg Vorbis I specification: Codec setup and packet decode.
962 Available from the Xiph website, http://www.xiph.org
964 Applications which use this media type:
966 Audio streaming and conferencing tools
968 Additional information:
972 Person & email address to contact for further information:
974 Luca Barbato: <lu_zero@gentoo.org>
975 IETF Audio/Video Transport Working Group
981 Restriction on usage:
983 This media type depends on RTP framing, and hence is only defined
984 for transfer via RTP [3]
992 IETF AVT Working Group
995 6.1. Mapping MIME Parameters into SDP
997 The information carried in the MIME media type specification has a
998 specific mapping to fields in the Session Description Protocol (SDP)
999 [5], which is commonly used to describe RTP sessions. When SDP is
1000 used to specify sessions the mapping are as follows:
1007 Barbato Expires April 24, 2006 [Page 18]
1009 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1012 o The MIME type ("audio") goes in SDP "m=" as the media name.
1014 o The MIME subtype ("vorbis") goes in SDP "a=rtpmap" as the encoding
1017 o The parameter "rate" also goes in "a=rtpmap" as clock rate.
1019 o The parameter "channels" also goes in "a=rtpmap" as channel count.
1021 o The mandated parameters "delivery-method" and "configuration" MUST
1022 be included in the SDP "a=fmpt" attribute.
1024 o The optional parameter "configuration-uri", when present, MUST be
1025 included in the SDP "a=fmpt" attribute and MUST follow the
1026 delivery-method that applies.
1028 If the stream comprises chained Vorbis files and all of them are
1029 known in advance, the Configuration Packet for each file SHOULD be
1030 passed to the client using the configuration attribute.
1032 The URI specified in the configuration-uri attribute MUST point to a
1033 location where all of the Configuration Packets needed for the life
1034 of the session reside.
1036 The port value is specified by the server application bound to the
1037 address specified in the c attribute. The bitrate value and channels
1038 specified in the rtpmap attribute MUST match the Vorbis sample rate
1039 value. An example is found below.
1043 a=rtpmap:98 VORBIS/44100/2
1044 a=delivery:out_band/http
1045 a=fmtp:98 delivery-method:in_band,out_band/http;
1046 configuration=base16string1;
1047 configuration-uri=http://path/to/the/resource
1049 Note that the payload format (encoding) names are commonly shown in
1050 upper case. MIME subtypes are commonly shown in lower case. These
1051 names are case-insensitive in both places. Similarly, parameter
1052 names are case-insensitive both in MIME types and in the default
1053 mapping to the SDP a=fmtp attribute. The exception regarding case
1054 sensitivity is the configuration-uri URI which MUST be regarded as
1055 being case sensitive.
1057 6.2. Usage with the SDP Offer/Answer Model
1059 The offer, as described in An Offer/Answer Model Session Description
1063 Barbato Expires April 24, 2006 [Page 19]
1065 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1068 Protocol [8], may contain a large number of delivery methods per
1069 single fmtp attribute, the answerer MUST remove every delivery-method
1070 and configuration-uri not supported. All the parameters MUST not be
1071 altered on answer otherwise.
1074 7. Congestion Control
1076 Vorbis clients SHOULD send regular receiver reports detailing
1077 congestion. A mechanism for dynamically downgrading the stream,
1078 known as bitrate peeling, will allow for a graceful backing off of
1079 the stream bitrate. This feature is not available at present so an
1080 alternative would be to redirect the client to a lower bitrate stream
1081 if one is available.
1083 If a particular multicast session has a large number of participants
1084 care must be taken to prevent an RTCP feedback implosion, [10], in
1085 the event of congestion.
1090 The following examples are common usage patterns that MAY be applied
1091 in such situations, the main scope of this section is to explain
1092 better usage of the transmission vectors.
1096 That is one of the most common situation: one single server streaming
1097 content in multicast, the clients may start a session at random time.
1098 The content itself could be a mix of live stream, as the dj's voice,
1099 and stored streams as the music she plays.
1101 In this situation we don't know in advance how many codebooks we will
1102 use. The clients can join anytime and users expect to start
1103 listening to the content in a short time.
1105 On join the client will receive the current Configuration necessary
1106 to decode the current stream inlined in the SDP. And can start
1107 decoding the current stream as soon it joins the session.
1109 When the streamed content changes the new Configuration is sent in-
1110 band before the actual stream, and the Configuration that has to be
1111 sent inline in the SDP updated. Since the inline method is
1112 unreliable, an out of band fallback is provided. The client could
1113 choose to fetch the Configuration from the alternate source as soon
1114 it discovers a Configuration packet got lost inline or use selective
1115 retransmission [17], if the server supports that feature.
1119 Barbato Expires April 24, 2006 [Page 20]
1121 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1124 A serverside optimization would be to keep an hash list of the
1125 Configurations per session to avoid packing all of them and send the
1126 same Configuration with different Ident tags
1128 A clientside optimization would be to keep a tag list of the
1129 Configurations per session and don't process configuration packets
1132 Let's assume that the client playout buffer can store at least 7
1136 9. Security Considerations
1138 RTP packets using this payload format are subject to the security
1139 considerations discussed in the RTP specification [3]. This implies
1140 that the confidentiality of the media stream is achieved by using
1141 encryption. Because the data compression used with this payload
1142 format is applied end-to-end, encryption may be performed on the
1143 compressed data. Where the size of a data block is set care MUST be
1144 taken to prevent buffer overflows in the client applications.
1149 This document is a continuation of draft-moffitt-vorbis-rtp-00.txt
1150 and draft-kerr-avt-vorbis-rtp-04.txt. The MIME type section is a
1151 continuation of draft-short-avt-rtp-vorbis-mime-00.txt.
1153 Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including Steve
1154 Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal
1155 Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro,
1156 Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short,
1157 Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David
1158 Barrett, Silvia Pfeiffer, Politecnico di Torino (LS)^3/IMG Group in
1159 particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini,
1160 Juan Carlos De Martin.
1165 11.1. Normative References
1167 [1] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
1170 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1175 Barbato Expires April 24, 2006 [Page 21]
1177 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1180 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
1181 "RTP: A Transport Protocol for real-time applications",
1184 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
1185 Conferences with Minimal Control.", RFC 3551.
1187 [5] Handley, M. and V. Jacobson, "SDP: Session Description
1188 Protocol", RFC 2327.
1190 [6] Mogul et al., J., "Path MTU Discovery", RFC 1063.
1192 [7] McCann et al., J., "Path MTU Discovery for IP version 6",
1195 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
1196 Session Description Protocol (SDP)", RFC 3264.
1198 [9] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
1201 [10] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
1202 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
1203 Internet Draft (draft-ietf-avt-rtcp-feedback-11: Work in
1206 [11] Deutsch, P., "GZIP file format specification version 4.3",
1209 [12] National Institute of Standards and Technology, "Secure Hash
1210 Standard", May 1993.
1212 [13] Seward, J., "libbz2 and bzip2".
1214 11.2. Informative References
1216 [14] "libvorbis: Available from the Xiph website,
1217 http://www.xiph.org".
1219 [15] "Ogg Vorbis I specification: Codec setup and packet decode.
1220 Available from the Xiph website, http://www.xiph.org".
1222 [16] "Ogg Vorbis I specification: Comment field and header
1223 specification. Available from the Xiph website,
1224 http://www.xiph.org".
1226 [17] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
1227 Extended Reports (RTCP XR)", RFC 3611, November 2003.
1231 Barbato Expires April 24, 2006 [Page 22]
1233 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1241 Email: lu_zero@gentoo.org
1242 URI: http://www.xiph.org/
1287 Barbato Expires April 24, 2006 [Page 23]
1289 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1292 Intellectual Property Statement
1294 The IETF takes no position regarding the validity or scope of any
1295 Intellectual Property Rights or other rights that might be claimed to
1296 pertain to the implementation or use of the technology described in
1297 this document or the extent to which any license under such rights
1298 might or might not be available; nor does it represent that it has
1299 made any independent effort to identify any such rights. Information
1300 on the procedures with respect to rights in RFC documents can be
1301 found in BCP 78 and BCP 79.
1303 Copies of IPR disclosures made to the IETF Secretariat and any
1304 assurances of licenses to be made available, or the result of an
1305 attempt made to obtain a general license or permission for the use of
1306 such proprietary rights by implementers or users of this
1307 specification can be obtained from the IETF on-line IPR repository at
1308 http://www.ietf.org/ipr.
1310 The IETF invites any interested party to bring to its attention any
1311 copyrights, patents or patent applications, or other proprietary
1312 rights that may cover technology that may be required to implement
1313 this standard. Please address the information to the IETF at
1317 Disclaimer of Validity
1319 This document and the information contained herein are provided on an
1320 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1321 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1322 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1323 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1324 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1325 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1330 Copyright (C) The Internet Society (2005). This document is subject
1331 to the rights, licenses and restrictions contained in BCP 78, and
1332 except as set forth therein, the authors retain all their rights.
1337 Funding for the RFC Editor function is currently provided by the
1343 Barbato Expires April 24, 2006 [Page 24]