5 AVT Working Group L. Barbato
6 Internet-Draft Xiph.Org
7 Expires: April 24, 2006 October 21, 2005
10 draft-kerr-avt-vorbis-rtp-05
11 RTP Payload Format for Vorbis Encoded Audio
15 By submitting this Internet-Draft, each author represents that any
16 applicable patent or other IPR claims of which he or she is aware
17 have been or will be disclosed, and any of which he or she becomes
18 aware will be disclosed, in accordance with Section 6 of BCP 79.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on April 24, 2006.
40 Copyright (C) The Internet Society (2005).
44 This document describes an RTP payload format for transporting Vorbis
45 encoded audio. It details the RTP encapsulation mechanism for raw
46 Vorbis data and details the delivery mechanisms for the decoder
47 probability model, referred to as a codebook and other setup
50 Also included within the document are the necessary details for the
51 use of Vorbis with MIME and Session Description Protocol (SDP).
56 Barbato Expires April 24, 2006 [Page 1]
58 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
63 All references to RFC XXXX are to be replaced by references to the
64 RFC number of this memo, when published.
69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
70 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
71 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3
72 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 3
73 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
74 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
75 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 7
76 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
77 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
78 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9
79 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 10
80 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 10
81 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13
82 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13
83 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 14
84 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15
85 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17
86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
87 6.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 19
88 6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 20
89 7. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21
90 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
91 8.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 21
92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
93 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
95 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
96 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
98 Intellectual Property and Copyright Statements . . . . . . . . . . 26
112 Barbato Expires April 24, 2006 [Page 2]
114 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
119 Vorbis is a general purpose perceptual audio codec intended to allow
120 maximum encoder flexibility, thus allowing it to scale competitively
121 over an exceptionally wide range of bitrates. At the high quality/
122 bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is
123 in the same league as MPEG-2 and MPC. Similarly, the version 1.1
124 reference encoder can encode high-quality CD and DAT rate stereo at
125 below 48k bits/sec without resampling to a lower rate. Vorbis is
126 also intended for lower and higher sample rates (from 8kHz telephony
127 to 192kHz digital masters) and a range of channel representations
128 (monaural, polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to
129 255 discrete channels).
131 Vorbis encoded audio is generally encapsulated within an Ogg format
132 bitstream [1], which provides framing and synchronization. For the
133 purposes of RTP transport, this layer is unnecessary, and so raw
134 Vorbis packets are used in the payload.
138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
140 document are to be interpreted as described in RFC 2119 [2].
145 For RTP based transportation of Vorbis encoded audio the standard RTP
146 header is followed by a 4 octet payload header, then the payload
147 data. The payload headers are used to associate the Vorbis data with
148 its associated decoding codebooks as well as indicating if the
149 following packet contains fragmented Vorbis data and/or the the
150 number of whole Vorbis data frames. The payload data contains the
151 raw Vorbis bitstream information.
155 The format of the RTP header is specified in [3] and shown in Figure
156 Figure 1. This payload format uses the fields of the header in a
157 manner consistent with that specification.
168 Barbato Expires April 24, 2006 [Page 3]
170 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
174 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
175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
176 |V=2|P|X| CC |M| PT | sequence number |
177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
180 | synchronization source (SSRC) identifier |
181 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
182 | contributing source (CSRC) identifiers |
184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
188 The RTP header begins with an octet of fields (V, P, X, and CC) to
189 support specialized RTP uses (see [3] and [4] for details). For
190 Vorbis RTP, the following values are used.
194 This field identifies the version of RTP. The version used by this
195 specification is two (2).
199 Padding MAY be used with this payload format according to section 5.1
204 The Extension bit is used in accordance with [3].
206 CSRC count (CC): 4 bits
208 The CSRC count is used in accordance with [3].
212 Set to zero. Audio silence suppression not used. This conforms to
215 Payload Type (PT): 7 bits
217 An RTP profile for a class of applications is expected to assign a
218 payload type for this format, or a dynamically allocated payload type
219 SHOULD be chosen which designates the payload as Vorbis.
224 Barbato Expires April 24, 2006 [Page 4]
226 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
229 Sequence number: 16 bits
231 The sequence number increments by one for each RTP data packet sent,
232 and may be used by the receiver to detect packet loss and to restore
233 packet sequence. This field is detailed further in [3].
237 A timestamp representing the sampling time of the first sample of the
238 first Vorbis packet in the RTP packet. The clock frequency MUST be
239 set to the sample rate of the encoded audio data and is conveyed out-
240 of-band as a SDP parameter.
242 SSRC/CSRC identifiers:
244 These two fields, 32 bits each with one SSRC field and a maximum of
245 16 CSRC fields, are as defined in [3].
249 After the RTP Header section the following 4 octets are the Payload
250 Header. This header is split into a number of bitfields detailing
251 the format of the following payload data packets.
254 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
255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
256 | Ident | F |VDT|# pkts.|
257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
259 Figure 2: Payload Header
263 This 24 bit field is used to associate the Vorbis data to a decoding
266 Fragment type (F): 2 bits
268 This field is set accordingly the following list
272 2 = Continuation Fragment
275 Vorbis Data Type (VDT): 2 bits
280 Barbato Expires April 24, 2006 [Page 5]
282 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
285 This field sets the payload type for the Vorbis data in this RTP
286 packet. There are currently three type of Vorbis payloads.
288 0 = Raw Vorbis payload
289 1 = Vorbis Packed Configuration payload
290 2 = Legacy Vorbis Comment payload
293 The packets with a TDT of value 3 MUST be ignored
295 The last 4 bits are the number of complete packets in this payload.
296 This provides for a maximum number of 15 Vorbis packets in the
297 payload. If the packet contains fragmented data the number of
298 packets MUST be set to 0.
302 Raw Vorbis packets are unbounded in length currently, although at
303 some future point application profiles will likely define a practical
304 limit. Typical Vorbis packet sizes are from very small (2-3 bytes)
305 to quite large (8-12 kilobytes). The reference implementation [14]
306 typically produces packets less than ~800 bytes, except for the setup
307 header packets which are ~4-12 kilobytes. Within an RTP context, to
308 avoid fragmentation, the Vorbis data packet size SHOULD be kept
309 sufficiently small so that after adding the the RTP and payload
310 headers, the complete RTP packet is smaller than the path MTU.
313 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
314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
315 | length | vorbis packet data ..
316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
318 Figure 3: Payload Data Header
320 Each Vorbis payload packet starts with a two octet length header,
321 which is used to represent the size of the following data payload,
322 followed by the raw Vorbis data padded to the nearest byte boundary.
324 For payloads which consist of multiple Vorbis packets the payload
325 data consists of the packet length followed by the packet data for
326 each of the Vorbis packets in the payload.
328 The Vorbis packet length header is the length of the Vorbis data
329 block only and does not count the length field.
331 The payload packing of the Vorbis data packets MUST follow the
332 guidelines set-out in [4] where the oldest packet occurs immediately
336 Barbato Expires April 24, 2006 [Page 6]
338 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
341 after the RTP packet header. Subsequence packets, if any, MUST
342 follow in temporal order.
344 Channel mapping of the audio is in accordance with the Vorbis I
347 2.4. Example RTP Packet
349 Here is an example RTP packet containing two Vorbis packets.
354 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
355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
356 | 2 |0|0| 0 |0| PT | sequence number |
357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
358 | timestamp (in sample rate units) |
359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
360 | synchronisation source (SSRC) identifier |
361 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
362 | contributing source (CSRC) identifiers |
364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
366 Figure 4: Example Packet (RTP Headers)
371 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
372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
373 | Ident | 0 | 0 | 2 pks |
374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
375 | length | vorbis data ..
376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
379 | length | next vorbis packet data ..
380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
384 Figure 5: Example Packet (Payload Data)
386 The payload data section of the RTP packet starts with the 24 bit
387 Ident field followed by the one octet bitfield header, which has the
388 number of Vorbis frames set to 2. Each of the Vorbis data frames is
392 Barbato Expires April 24, 2006 [Page 7]
394 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
397 prefixed by the two octet length field. The Packet Type and Fragment
398 Type are set to 0. The decode Configuration that will be used to
399 decode the packets is the one indexed by the ident value.
402 3. Configuration Headers
404 Unlike other mainstream audio codecs Vorbis has no statically
405 configured probability model. Instead, it packs all entropy decoding
406 configuration, VQ and Huffman models into a data block that must be
407 transmitted to the decoder along with the compressed data. A decoder
408 also requires information detailing the number of audio channels,
409 bitrates and similar information to configure itself for a particular
410 compressed data stream. These two blocks of information are often
411 referred to collectively as the "codebooks" for a Vorbis stream, and
412 are nominally included as special "header" packets at the start of
413 the compressed data. In addition, the Vorbis I specification [15]
414 requires the presence of a comment header packet which gives simple
415 metadata about the stream, but this information is not required for
416 decoding the frame sequence.
418 Thus these two codebook header packets must be received by the
419 decoder before any audio data can be interpreted. These requirements
420 pose problems in RTP, which is often used over unreliable transports.
422 Since this information must be transmitted reliably and, as the RTP
423 stream may change certain configuration data mid-session, there are
424 different methods for delivering this configuration data to a client,
425 both in-band and out-of-band which is detailed below. SDP delivery
426 is used to set up an initial state for the client application. The
427 changes may be due to different codebooks as well as different
428 bitrates of the stream.
430 The delivery vectors in use are specified by an SDP attribute to
431 indicate the method and the optional URI where the Vorbis Packed
432 Configuration (Section 3.1.1) Packets could be fetched. Different
433 delivery methods MAY be advertised for the same session. The in-band
434 Configuration delivery SHOULD be considered as baseline, out-of-band
435 delivery methods that don't use RTP will not be described in this
436 document. For non chained streams, the Configuration recommended
437 delivery method is inline the Packed Configuration (Section 3.1.1) in
438 the SDP as explained in the IANA considerations (Section 6.1)
441 The 24 bit Ident field is used to map which Configuration will be
442 used to decode a packet. When the Ident field changes, it indicates
443 that a change in the stream has taken place. The client application
444 MUST have in advance the correct configuration and if the client
448 Barbato Expires April 24, 2006 [Page 8]
450 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
453 detects a change in the Ident value and does not have this
454 information it MUST NOT decode the raw Vorbis data associated until
455 it fetches the correct Configuration.
457 3.1. In-band Header Transmission
459 The Packed Configuration (Section 3.1.1) Payload is sent in-band with
460 the packet type bits set to match the payload type. Clients MUST be
461 capable of dealing with fragmentation and periodic re-transmission of
462 the configuration headers.
464 3.1.1. Packed Configuration
466 A Vorbis Packed Configuration is indicated with the payload type
467 field set to 1. Of the three headers, defined in the Vorbis I
468 specification [15], the identification and the setup will be packed
469 together, the comment header is completely suppressed. Is up to the
470 client provide a minimal size comment header to the decoder if
471 required by the implementation.
504 Barbato Expires April 24, 2006 [Page 9]
506 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
510 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
511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
512 |V=2|P|X| CC |M| PT | xxxx |
513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
516 | synchronization source (SSRC) identifier |
517 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
518 | contributing source (CSRC) identifiers |
520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
524 | length | Identification ..
525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
539 Figure 6: Packed Configuration Figure
541 The Ident field is set with the value that will be used by the Raw
542 Payload Packets to address this Configuration. The Fragment type is
543 set to 0 since the packet bears the full Packed configuration, the
544 number of packet is set to 1.
546 3.2. Out of Band Transmission
548 This section, as stated above, does not cover all the possible out-
549 of-band delivery methods since they rely to different protocols and
550 are linked to specific applications. The following packet definition
551 SHOULD be used in out-of-band delivery and MUST be used when
552 Configuration is inlined in the SDP.
554 3.2.1. Packed Headers
556 As mentioned above the RECOMMENDED delivery vector for Vorbis
560 Barbato Expires April 24, 2006 [Page 10]
562 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
565 configuration data is via a retrieval method that can be performed
566 using a reliable transport protocol. As the RTP headers are not
567 required for this method of delivery the structure of the
568 configuration data is slightly different. The packed header starts
569 with a 32 bit count field which details the number of packed headers
570 that are contained in the bundle. Next is the Packed header payload
571 for each chained Vorbis stream.
573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
574 | Number of packed headers |
575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
583 Figure 7: Packed Headers Overview
585 Since the Configuration Ident and the Identification Header are fixed
586 length there is only a 2 byte length tag to define the length of the
590 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
591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
594 .. length | Identification Header ..
595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
596 .. Identification Header |
597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
603 Figure 8: Packed Headers Detail
605 The key difference between the in-band format and this one, is there
606 is no need for the payload header octet.
608 3.2.1.1. Packed Headers IANA Considerations
610 The following IANA considerations MUST only be applied to the packed
616 Barbato Expires April 24, 2006 [Page 11]
618 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
621 MIME media type name: audio
623 MIME subtype: vorbis-config
633 Encoding considerations:
635 This media type contains binary data.
637 Security Considerations:
639 See Section 6 of RFC XXXX.
641 Interoperability considerations:
645 Published specification:
647 RFC XXXX [RFC Editor: please replace by the RFC number of this
648 memo, when published]
650 Applications which use this media type:
652 Vorbis encoded audio, configuration data.
654 Additional information:
658 Person & email address to contact for further information:
660 Luca Barbato: <lu_zero@gentoo.org>
661 IETF Audio/Video Transport Working Group
663 Intended usage: COMMON
672 Barbato Expires April 24, 2006 [Page 12]
674 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
677 Restriction on usage:
679 This media type doesn't depend on the transport.
687 IETF AVT Working Group
689 3.3. Loss of Configuration Headers
691 Unlike the loss of raw Vorbis payload data, loss of a configuration
692 header can lead to a situation where it will not be possible to
693 successfully decode the stream.
695 Loss of Configuration Packet results in the halting of stream
696 decoding and SHOULD be reported to the client as well as a loss
697 report sent via RTCP.
702 With the payload type flag set to 2, this indicates that the packet
703 contain the comment metadata, such as artist name, track title and so
704 on. These metadata messages are not intended to be fully descriptive
705 but to offer basic track/song information. Clients MAY ignore it
706 completely. The details on the format of the comments can be found
707 in the Vorbis documentation [15].
728 Barbato Expires April 24, 2006 [Page 13]
730 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
734 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
735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
736 |V=2|P|X| CC |M| PT | xxxx |
737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
740 | synchronization source (SSRC) identifier |
741 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
742 | contributing source (CSRC) identifiers |
744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
748 | length | Comment ..
749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
755 Figure 9: Comment Packet
757 The 2 bytes length field is necessary since this packet could be
761 5. Frame Packetization
763 Each RTP packet contains either one Vorbis packet fragment, or an
764 integer number of complete Vorbis packets (up to a maximum of 15
765 packets, since the number of packets is defined by a 4 bit value).
767 Any Vorbis data packet that is less than path MTU SHOULD be bundled
768 in the RTP packet with as many Vorbis packets as will fit, up to a
769 maximum of 15, except when such bundling would exceed an
770 application's desired transmission latency. Path MTU is detailed in
773 If a Vorbis packet, not only data but also Configuration and Comment,
774 is larger than 65535 octets it MUST be fragmented. A fragmented
775 packet has a zero in the last four bits of the payload header. The
776 first fragment will set the Fragment type to 1. Each fragment after
777 the first will set the Fragment type to 2 in the payload header. The
778 RTP packet containing the last fragment of the Vorbis packet will
779 have the Fragment type set to 3. To maintain the correct sequence
780 for fragmented packet reception the timestamp field of fragmented
784 Barbato Expires April 24, 2006 [Page 14]
786 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
789 packets MUST be the same as the first packet sent, with the sequence
790 number incremented as normal for the subsequent RTP packets. The
791 length field shows the fragment length.
793 5.1. Example Fragmented Vorbis Packet
795 Here is an example fragmented Vorbis packet split over three RTP
796 packets. Each packet contains the standard RTP headers as well as
797 the 4 octet Vorbis headers.
802 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
803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
804 |V=2|P|X| CC |M| PT | 1000 |
805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
808 | synchronization source (SSRC) identifier |
809 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
810 | contributing source (CSRC) identifiers |
812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
816 | length | vorbis data ..
817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
821 Figure 10: Example Fragmented Packet (Packet 1)
823 In this packet the initial sequence number is 1000 and the timestamp
824 is xxxxx. The Fragment type is set to 1, the number of packets field
825 is set to 0, and as the payload is raw Vorbis data the VDT field is
840 Barbato Expires April 24, 2006 [Page 15]
842 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
848 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
849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
850 |V=2|P|X| CC |M| PT | 1001 |
851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
854 | synchronization source (SSRC) identifier |
855 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
856 | contributing source (CSRC) identifiers |
858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
862 | length | vorbis data ..
863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
867 Figure 11: Example Fragmented Packet (Packet 2)
869 The Fragment type field is set to 2 and the number of packets field
870 is set to 0. For large Vorbis fragments there can be several of
871 these type of payload packets. The maximum packet size SHOULD be no
872 greater than the path MTU, including all RTP and payload headers.
873 The sequence number has been incremented by one but the timestamp
874 field remains the same as the initial packet.
896 Barbato Expires April 24, 2006 [Page 16]
898 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
904 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
905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
906 |V=2|P|X| CC |M| PT | 1002 |
907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
910 | synchronization source (SSRC) identifier |
911 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
912 | contributing source (CSRC) identifiers |
914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
918 | length | vorbis data ..
919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
923 Figure 12: Example Fragmented Packet (Packet 3)
925 This is the last Vorbis fragment packet. The Fragment type is set to
926 3 and the packet count remains set to 0. As in the previous packets
927 the timestamp remains set to the first packet in the sequence and the
928 sequence number has been incremented.
932 As there is no error correction within the Vorbis stream, packet loss
933 will result in a loss of signal. Packet loss is more of an issue for
934 fragmented Vorbis packets as the client will have to cope with the
935 handling of the Fragment Type. In case of loss of fragments the
936 client MUST discard all the remaining fragments and decode the
937 incomplete packet. If we use the fragmented Vorbis packet example
938 above and the first packet is lost the client MUST detect that the
939 next packet has the packet count field set to 0 and the Fragment type
940 2 and MUST drop it. The next packet, which is the final fragmented
941 packet, MUST be dropped in the same manner. If the missing packet is
942 the last, the received two fragments will be kept and the incomplete
943 vorbis packet decoded. Feedback reports on lost and dropped packets
944 MUST be sent back via RTCP.
946 If a particular multicast session has a large number of participants
947 care must be taken to prevent an RTCP feedback implosion, [10], in
948 the event of packet loss from a large number of participants.
952 Barbato Expires April 24, 2006 [Page 17]
954 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
957 Loss of any of the Configuration fragment will result in the loss of
958 the full Configuration packet with the result detailed in the Loss of
959 Configuration Headers (Section 3.3) section.
962 6. IANA Considerations
964 MIME media type name: audio
970 delivery-method: indicates the delivery methods in use, the
971 possible values are: inline, in_band, out_band/specific_name
972 Where "specific_name" is the name of the out of band delivery
975 configuration: the base16 [9] (hexadecimal) representation of the
976 Packed Headers (Section 3.2.1).
980 configuration-uri: the URI of the configuration headers in case of
981 out of band transmission. In the form of
982 "protocol://path/to/resource/". Depending on the specific
983 method the single ident packet could be retrived by their
984 number, or aggregated in a single stream, aggregates MAY be
985 compressed using bzip2 [13] or gzip [11] and an sha1 [12]
986 checksum MAY be provided in the form of
987 "protocol://path/to/resource/! sha1hash"
989 Encoding considerations:
991 This media type is framed and contains binary data.
993 Security Considerations:
995 See Section 6 of RFC XXXX.
997 Interoperability considerations:
1008 Barbato Expires April 24, 2006 [Page 18]
1010 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1013 Published specification:
1015 RFC XXXX [RFC Editor: please replace by the RFC number of this
1016 memo, when published]
1018 Ogg Vorbis I specification: Codec setup and packet decode.
1019 Available from the Xiph website, http://www.xiph.org
1021 Applications which use this media type:
1023 Audio streaming and conferencing tools
1025 Additional information:
1029 Person & email address to contact for further information:
1031 Luca Barbato: <lu_zero@gentoo.org>
1032 IETF Audio/Video Transport Working Group
1038 Restriction on usage:
1040 This media type depends on RTP framing, and hence is only defined
1041 for transfer via RTP [3]
1049 IETF AVT Working Group
1052 6.1. Mapping MIME Parameters into SDP
1054 The information carried in the MIME media type specification has a
1055 specific mapping to fields in the Session Description Protocol (SDP)
1056 [5], which is commonly used to describe RTP sessions. When SDP is
1057 used to specify sessions the mapping are as follows:
1064 Barbato Expires April 24, 2006 [Page 19]
1066 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1069 o The MIME type ("audio") goes in SDP "m=" as the media name.
1071 o The MIME subtype ("vorbis") goes in SDP "a=rtpmap" as the encoding
1074 o The parameter "rate" also goes in "a=rtpmap" as clock rate.
1076 o The parameter "channels" also goes in "a=rtpmap" as channel count.
1078 o The mandated parameters "delivery-method" and "configuration" MUST
1079 be included in the SDP "a=fmpt" attribute.
1081 o The optional parameter "configuration-uri", when present, MUST be
1082 included in the SDP "a=fmpt" attribute and MUST follow the
1083 delivery-method that applies.
1085 If the stream comprises chained Vorbis files and all of them are
1086 known in advance, the Configuration Packet for each file SHOULD be
1087 passed to the client using the configuration attribute.
1089 The URI specified in the configuration-uri attribute MUST point to a
1090 location where all of the Configuration Packets needed for the life
1091 of the session reside.
1093 The port value is specified by the server application bound to the
1094 address specified in the c attribute. The bitrate value and channels
1095 specified in the rtpmap attribute MUST match the Vorbis sample rate
1096 value. An example is found below.
1100 a=rtpmap:98 VORBIS/44100/2
1101 a=delivery:out_band/http
1102 a=fmtp:98 delivery-method:in_band,out_band/http;
1103 configuration=base16string1;
1104 configuration-uri=http://path/to/the/resource
1106 Note that the payload format (encoding) names are commonly shown in
1107 upper case. MIME subtypes are commonly shown in lower case. These
1108 names are case-insensitive in both places. Similarly, parameter
1109 names are case-insensitive both in MIME types and in the default
1110 mapping to the SDP a=fmtp attribute. The exception regarding case
1111 sensitivity is the configuration-uri URI which MUST be regarded as
1112 being case sensitive.
1114 6.2. Usage with the SDP Offer/Answer Model
1116 The offer, as described in An Offer/Answer Model Session Description
1120 Barbato Expires April 24, 2006 [Page 20]
1122 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1125 Protocol [8], may contain a large number of delivery methods per
1126 single fmtp attribute, the answerer MUST remove every delivery-method
1127 and configuration-uri not supported. All the parameters MUST not be
1128 altered on answer otherwise.
1131 7. Congestion Control
1133 Vorbis clients SHOULD send regular receiver reports detailing
1134 congestion. A mechanism for dynamically downgrading the stream,
1135 known as bitrate peeling, will allow for a graceful backing off of
1136 the stream bitrate. This feature is not available at present so an
1137 alternative would be to redirect the client to a lower bitrate stream
1138 if one is available.
1140 If a particular multicast session has a large number of participants
1141 care must be taken to prevent an RTCP feedback implosion, [10], in
1142 the event of congestion.
1147 The following examples are common usage patterns that MAY be applied
1148 in such situations, the main scope of this section is to explain
1149 better usage of the transmission vectors.
1153 That is one of the most common situation: one single server streaming
1154 content in multicast, the clients may start a session at random time.
1155 The content itself could be a mix of live stream, as the wj's voice,
1156 and stored streams as the music she plays.
1158 In this situation we don't know in advance how many codebooks we will
1159 use. The clients can join anytime and users expect to start
1160 listening to the content in a short time.
1162 On join the client will receive the current Configuration necessary
1163 to decode the current stream inlined in the SDP so that the decoding
1164 will start immediately after.
1166 When the streamed content changes the new Configuration is sent in-
1167 band before the actual stream, and the Configuration that has to be
1168 sent inline in the SDP updated. Since the inline method is
1169 unreliable, an out of band fallback is provided.
1171 The client could choose to fetch the Configuration from the alternate
1172 source as soon it discovers a Configuration packet got lost inline or
1176 Barbato Expires April 24, 2006 [Page 21]
1178 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1181 use selective retransmission [17], if the server supports that
1184 A serverside optimization would be to keep an hash list of the
1185 Configurations per session to avoid packing all of them and send the
1186 same Configuration with different Ident tags
1188 A clientside optimization would be to keep a tag list of the
1189 Configurations per session and don't process configuration packets
1192 Let's assume that the client playout buffer can store at least 7
1196 9. Security Considerations
1198 RTP packets using this payload format are subject to the security
1199 considerations discussed in the RTP specification [3]. This implies
1200 that the confidentiality of the media stream is achieved by using
1201 encryption. Because the data compression used with this payload
1202 format is applied end-to-end, encryption may be performed on the
1203 compressed data. Where the size of a data block is set care MUST be
1204 taken to prevent buffer overflows in the client applications.
1209 This document is a continuation of draft-moffitt-vorbis-rtp-00.txt
1210 and draft-kerr-avt-vorbis-rtp-04.txt. The MIME type section is a
1211 continuation of draft-short-avt-rtp-vorbis-mime-00.txt.
1213 Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including Steve
1214 Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal
1215 Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro,
1216 Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short,
1217 Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David
1218 Barrett, Silvia Pfeiffer, Politecnico di Torino (LS)^3/IMG Group in
1219 particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini,
1220 Juan Carlos De Martin.
1225 11.1. Normative References
1227 [1] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
1232 Barbato Expires April 24, 2006 [Page 22]
1234 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1237 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1240 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
1241 "RTP: A Transport Protocol for real-time applications",
1244 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
1245 Conferences with Minimal Control.", RFC 3551.
1247 [5] Handley, M. and V. Jacobson, "SDP: Session Description
1248 Protocol", RFC 2327.
1250 [6] Mogul et al., J., "Path MTU Discovery", RFC 1063.
1252 [7] McCann et al., J., "Path MTU Discovery for IP version 6",
1255 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
1256 Session Description Protocol (SDP)", RFC 3264.
1258 [9] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
1261 [10] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
1262 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
1263 Internet Draft (draft-ietf-avt-rtcp-feedback-11: Work in
1266 [11] Deutsch, P., "GZIP file format specification version 4.3",
1269 [12] National Institute of Standards and Technology, "Secure Hash
1270 Standard", May 1993.
1272 [13] Seward, J., "libbz2 and bzip2".
1274 11.2. Informative References
1276 [14] "libvorbis: Available from the Xiph website,
1277 http://www.xiph.org".
1279 [15] "Ogg Vorbis I specification: Codec setup and packet decode.
1280 Available from the Xiph website, http://www.xiph.org".
1282 [16] "Ogg Vorbis I specification: Comment field and header
1283 specification. Available from the Xiph website,
1284 http://www.xiph.org".
1288 Barbato Expires April 24, 2006 [Page 23]
1290 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1293 [17] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
1294 Extended Reports (RTCP XR)", RFC 3611, November 2003.
1344 Barbato Expires April 24, 2006 [Page 24]
1346 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1354 Email: lu_zero@gentoo.org
1355 URI: http://www.xiph.org/
1400 Barbato Expires April 24, 2006 [Page 25]
1402 Internet-Draft draft-kerr-avt-vorbis-rtp-05 October 2005
1405 Intellectual Property Statement
1407 The IETF takes no position regarding the validity or scope of any
1408 Intellectual Property Rights or other rights that might be claimed to
1409 pertain to the implementation or use of the technology described in
1410 this document or the extent to which any license under such rights
1411 might or might not be available; nor does it represent that it has
1412 made any independent effort to identify any such rights. Information
1413 on the procedures with respect to rights in RFC documents can be
1414 found in BCP 78 and BCP 79.
1416 Copies of IPR disclosures made to the IETF Secretariat and any
1417 assurances of licenses to be made available, or the result of an
1418 attempt made to obtain a general license or permission for the use of
1419 such proprietary rights by implementers or users of this
1420 specification can be obtained from the IETF on-line IPR repository at
1421 http://www.ietf.org/ipr.
1423 The IETF invites any interested party to bring to its attention any
1424 copyrights, patents or patent applications, or other proprietary
1425 rights that may cover technology that may be required to implement
1426 this standard. Please address the information to the IETF at
1430 Disclaimer of Validity
1432 This document and the information contained herein are provided on an
1433 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1434 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1435 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1436 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1437 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1438 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1443 Copyright (C) The Internet Society (2005). This document is subject
1444 to the rights, licenses and restrictions contained in BCP 78, and
1445 except as set forth therein, the authors retain all their rights.
1450 Funding for the RFC Editor function is currently provided by the
1456 Barbato Expires April 24, 2006 [Page 26]