5 AVT Working Group L. Barbato
6 Internet-Draft Xiph.Org
7 Expires: August 24, 2006 February 20, 2006
10 draft-ietf-avt-vorbis-rtp-00
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 August 24, 2006.
40 Copyright (C) The Internet Society (2006).
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 August 24, 2006 [Page 1]
58 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 20
89 6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 21
90 7. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21
91 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
92 8.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 21
93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
94 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
96 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
97 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
99 Intellectual Property and Copyright Statements . . . . . . . . . . 26
112 Barbato Expires August 24, 2006 [Page 2]
114 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 transport of Vorbis encoded audio the standard RTP
146 header is followed by a 4 octets 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 number of
150 whole Vorbis data frames. The payload data contains the raw Vorbis
151 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 August 24, 2006 [Page 3]
170 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 August 24, 2006 [Page 4]
226 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 The 4 octets following the RTP Header section are the Payload Header.
250 This header is split into a number of bitfields detailing the format
251 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 according to the following list
272 2 = Continuation Fragment
275 Vorbis Data Type (VDT): 2 bits
280 Barbato Expires August 24, 2006 [Page 5]
282 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 represent the number of complete packets in this
296 payload. This provides for a maximum number of 15 Vorbis packets in
297 the payload. If the packet contains fragmented data the number of
298 packets MUST be set to 0.
302 Raw Vorbis packets are currently unbounded in length, application
303 profiles will likely define a practical limit. Typical Vorbis packet
304 sizes range from very small (2-3 bytes) to quite large (8-12
305 kilobytes). The reference implementation [14] typically produces
306 packets less than ~800 bytes, except for the setup header packets
307 which are ~4-12 kilobytes. Within an RTP context, to avoid
308 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 August 24, 2006 [Page 6]
338 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
341 after the RTP packet header. Subsequent packets, if any, MUST follow
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 begins 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 August 24, 2006 [Page 7]
394 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
397 prefixed by the two octets length field. The Packet Type and
398 Fragment Type are set to 0. The 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 August 24, 2006 [Page 8]
450 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 August 24, 2006 [Page 9]
506 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 on 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 August 24, 2006 [Page 10]
562 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 August 24, 2006 [Page 11]
618 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 August 24, 2006 [Page 12]
674 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 August 24, 2006 [Page 13]
730 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 A fragmented packet has a zero in the last four bits of the payload
774 header. The first fragment will set the Fragment type to 1. Each
775 fragment after the first will set the Fragment type to 2 in the
776 payload header. The RTP packet containing the last fragment of the
777 Vorbis packet will have the Fragment type set to 3. To maintain the
778 correct sequence for fragmented packet reception the timestamp field
779 of fragmented packets MUST be the same as the first packet sent, with
780 the sequence number incremented as normal for the subsequent RTP
784 Barbato Expires August 24, 2006 [Page 14]
786 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
789 packets. The length field shows the fragment length.
791 5.1. Example Fragmented Vorbis Packet
793 Here is an example fragmented Vorbis packet split over three RTP
794 packets. Each packet contains the standard RTP headers as well as
795 the 4 octets Vorbis headers.
800 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
801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802 |V=2|P|X| CC |M| PT | 1000 |
803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
806 | synchronization source (SSRC) identifier |
807 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
808 | contributing source (CSRC) identifiers |
810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
814 | length | vorbis data ..
815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
819 Figure 10: Example Fragmented Packet (Packet 1)
821 In this packet the initial sequence number is 1000 and the timestamp
822 is xxxxx. The Fragment type is set to 1, the number of packets field
823 is set to 0, and as the payload is raw Vorbis data the VDT field is
840 Barbato Expires August 24, 2006 [Page 15]
842 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 August 24, 2006 [Page 16]
898 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 August 24, 2006 [Page 17]
954 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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/aggregated.bz2!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 August 24, 2006 [Page 18]
1010 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 August 24, 2006 [Page 19]
1066 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 The following example shows a basic SDP single stream. The first
1101 configuration packet is inlined in the sdp, other configurations
1102 could be fetched at any time from the first provided uri using or all
1103 the known configuration could be downloaded using the second uri.
1104 The inline base16 [9] configuration string is omitted because of the
1108 a=rtpmap:98 vorbis/44100/2
1109 a=delivery:out_band/http
1110 a=fmtp:98 delivery-method=in_band; configuration=base16string1;
1111 delivery-method=out_band/rtsp;
1112 configuration-uri=rtsp://path/to/the/resource; delivery-
1113 method=out_band/http; configuration-uri=http://another/path/to/
1114 resource/aggregate.bz2!sha1hash;
1116 Note that the payload format (encoding) names are commonly shown in
1120 Barbato Expires August 24, 2006 [Page 20]
1122 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
1125 upper case. MIME subtypes are commonly shown in lower case. These
1126 names are case-insensitive in both places. Similarly, parameter
1127 names are case-insensitive both in MIME types and in the default
1128 mapping to the SDP a=fmtp attribute. The exception regarding case
1129 sensitivity is the configuration-uri URI which MUST be regarded as
1130 being case sensitive.
1132 6.2. Usage with the SDP Offer/Answer Model
1134 The offer, as described in An Offer/Answer Model Session Description
1135 Protocol [8], may contain a large number of delivery methods per
1136 single fmtp attribute, the answerer MUST remove every delivery-method
1137 and configuration-uri not supported. All the parameters MUST not be
1138 altered on answer otherwise.
1141 7. Congestion Control
1143 Vorbis clients SHOULD send regular receiver reports detailing
1144 congestion. A mechanism for dynamically downgrading the stream,
1145 known as bitrate peeling, will allow for a graceful backing off of
1146 the stream bitrate. This feature is not available at present so an
1147 alternative would be to redirect the client to a lower bitrate stream
1148 if one is available.
1150 If a particular multicast session has a large number of participants
1151 care must be taken to prevent an RTCP feedback implosion, [10], in
1152 the event of congestion.
1157 The following examples are common usage patterns that MAY be applied
1158 in such situations, the main scope of this section is to explain
1159 better usage of the transmission vectors.
1163 This is one of the most common situation: one single server streaming
1164 content in multicast, the clients may start a session at random time.
1165 The content itself could be a mix of live stream, as the wj's voice,
1166 and stored streams as the music she plays.
1168 In this situation we don't know in advance how many codebooks we will
1169 use. The clients can join anytime and users expect to start
1170 listening to the content in a short time.
1172 On join the client will receive the current Configuration necessary
1176 Barbato Expires August 24, 2006 [Page 21]
1178 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
1181 to decode the current stream inlined in the SDP so that the decoding
1182 will start immediately after.
1184 When the streamed content changes the new Configuration is sent in-
1185 band before the actual stream, and the Configuration that has to be
1186 sent inline in the SDP updated. Since the inline method is
1187 unreliable, an out of band fallback is provided.
1189 The client could choose to fetch the Configuration from the alternate
1190 source as soon it discovers a Configuration packet got lost inline or
1191 use selective retransmission [17], if the server supports the
1194 A serverside optimization would be to keep an hash list of the
1195 Configurations per session to avoid packing all of them and send the
1196 same Configuration with different Ident tags
1198 A clientside optimization would be to keep a tag list of the
1199 Configurations per session and don't process configuration packets
1203 9. Security Considerations
1205 RTP packets using this payload format are subject to the security
1206 considerations discussed in the RTP specification [3]. This implies
1207 that the confidentiality of the media stream is achieved by using
1208 encryption. Because the data compression used with this payload
1209 format is applied end-to-end, encryption may be performed on the
1210 compressed data. Where the size of a data block is set care MUST be
1211 taken to prevent buffer overflows in the client applications.
1216 This document is a continuation of draft-moffitt-vorbis-rtp-00.txt
1217 and draft-kerr-avt-vorbis-rtp-04.txt. The MIME type section is a
1218 continuation of draft-short-avt-rtp-vorbis-mime-00.txt.
1220 Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including Steve
1221 Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal
1222 Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro,
1223 Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short,
1224 Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David
1225 Barrett, Silvia Pfeiffer, Stefan Ehmann, Alessandro Salvatori.
1226 Politecnico di Torino (LS)^3/IMG Group in particular Federico
1227 Ridolfo, Francesco Varano, Giampaolo Mancini, Juan Carlos De Martin.
1232 Barbato Expires August 24, 2006 [Page 22]
1234 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
1239 11.1. Normative References
1241 [1] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
1244 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1247 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
1248 "RTP: A Transport Protocol for real-time applications",
1251 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
1252 Conferences with Minimal Control.", RFC 3551.
1254 [5] Handley, M. and V. Jacobson, "SDP: Session Description
1255 Protocol", RFC 2327.
1257 [6] Mogul et al., J., "Path MTU Discovery", RFC 1063.
1259 [7] McCann et al., J., "Path MTU Discovery for IP version 6",
1262 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
1263 Session Description Protocol (SDP)", RFC 3264.
1265 [9] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
1268 [10] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
1269 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
1270 Internet Draft (draft-ietf-avt-rtcp-feedback-11: Work in
1273 [11] Deutsch, P., "GZIP file format specification version 4.3",
1276 [12] National Institute of Standards and Technology, "Secure Hash
1277 Standard", May 1993.
1279 [13] Seward, J., "libbz2 and bzip2".
1281 11.2. Informative References
1283 [14] "libvorbis: Available from the Xiph website,
1284 http://www.xiph.org".
1288 Barbato Expires August 24, 2006 [Page 23]
1290 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
1293 [15] "Ogg Vorbis I specification: Codec setup and packet decode.
1294 Available from the Xiph website, http://www.xiph.org".
1296 [16] "Ogg Vorbis I specification: Comment field and header
1297 specification. Available from the Xiph website,
1298 http://www.xiph.org".
1300 [17] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
1301 Extended Reports (RTCP XR)", RFC 3611, November 2003.
1344 Barbato Expires August 24, 2006 [Page 24]
1346 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
1354 Email: lu_zero@gentoo.org
1355 URI: http://www.xiph.org/
1400 Barbato Expires August 24, 2006 [Page 25]
1402 Internet-Draft draft-ietf-avt-vorbis-rtp-00 February 2006
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 (2006). 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 August 24, 2006 [Page 26]