4 AVT Working Group L. Barbato
5 Internet-Draft Xiph.Org
6 Expires: October 8, 2007 April 6, 2007
9 draft-ietf-avt-rtp-vorbis-02
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 October 8, 2007.
39 Copyright (C) The IETF Trust (2007).
43 This document describes an RTP payload format for transporting Vorbis
44 encoded audio. It details the RTP encapsulation mechanism for raw
45 Vorbis data and details the delivery mechanisms for the decoder
46 probability model, referred to as a codebook and other setup
49 Also included within this memo are media type registrations, and the
50 details necessary for the use of Vorbis with the Session Description
55 Barbato Expires October 8, 2007 [Page 1]
57 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
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 . . . . . . . . . . . . . . . . . . . . 11
80 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 12
81 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 12
82 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 13
83 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 13
84 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16
85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
86 6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 18
87 7. SDP related considerations . . . . . . . . . . . . . . . . . . 20
88 7.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 20
89 7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 21
90 7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 21
91 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21
92 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
93 9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22
94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
95 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
98 12.2. Informative References . . . . . . . . . . . . . . . . . . 24
99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
100 Intellectual Property and Copyright Statements . . . . . . . . . . 25
111 Barbato Expires October 8, 2007 [Page 2]
113 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
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 AAC. Vorbis is also intended for lower and
123 higher sample rates (from 8kHz telephony to 192kHz digital masters)
124 and a range of channel representations (monaural, polyphonic, stereo,
125 quadraphonic, 5.1, ambisonic, or up to 255 discrete channels).
127 Vorbis encoded audio is generally encapsulated within an Ogg format
128 bitstream [10], which provides framing and synchronization. For the
129 purposes of RTP transport, this layer is unnecessary, and so raw
130 Vorbis packets are used in the payload.
134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
136 document are to be interpreted as described in RFC 2119 [1].
141 For RTP based transport of Vorbis encoded audio the standard RTP
142 header is followed by a 4 octets payload header, then the payload
143 data. The payload headers are used to associate the Vorbis data with
144 its associated decoding codebooks as well as indicating if the
145 following packet contains fragmented Vorbis data and/or the number of
146 whole Vorbis data frames. The payload data contains the raw Vorbis
147 bitstream information. There are 3 types of Vorbis payload data, an
148 RTP packet MUST contain just one of them at time.
152 The format of the RTP header is specified in [2] and shown in Figure
153 Figure 1. This payload format uses the fields of the header in a
154 manner consistent with that specification.
167 Barbato Expires October 8, 2007 [Page 3]
169 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
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 [2] and [3] 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 [2].
205 CSRC count (CC): 4 bits
207 The CSRC count is used in accordance with [2].
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 October 8, 2007 [Page 4]
225 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
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 [2].
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 [2].
248 The 4 octets following the RTP Header section are the Payload Header.
249 This header is split into a number of bitfields detailing the format
250 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
263 Configuration. It is stored as network byte order integer.
265 Fragment type (F): 2 bits
267 This field is set according to the following list
271 2 = Continuation Fragment
274 Vorbis Data Type (VDT): 2 bits
279 Barbato Expires October 8, 2007 [Page 5]
281 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
284 This field specifies the kind of Vorbis data stored in this RTP
285 packet. There are currently three different types of Vorbis
286 payloads. Each packet MUST contain only a single type of Vorbis
289 0 = Raw Vorbis payload
290 1 = Vorbis Packed Configuration payload
291 2 = Legacy Vorbis Comment payload
294 The packets with a VDT of value 3 MUST be ignored
296 The last 4 bits represent the number of complete packets in this
297 payload. This provides for a maximum number of 15 Vorbis packets in
298 the payload. If the packet contains fragmented data the number of
299 packets MUST be set to 0.
303 Raw Vorbis packets are currently unbounded in length, application
304 profiles will likely define a practical limit. Typical Vorbis packet
305 sizes range from very small (2-3 bytes) to quite large (8-12
306 kilobytes). The reference implementation [11] typically produces
307 packets less than ~800 bytes, except for the setup header packets
308 which are ~4-12 kilobytes. Within an RTP context, to avoid
309 fragmentation, the Vorbis data packet size SHOULD be kept
310 sufficiently small so that after adding the the RTP and payload
311 headers, the complete RTP packet is smaller than the path MTU.
314 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
315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
316 | length | vorbis packet data ..
317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
319 Figure 3: Payload Data Header
321 Each Vorbis payload packet starts with a two octet length header,
322 which is used to represent the size in bytes of the following data
323 payload, followed by the raw Vorbis data padded to the nearest byte
324 boundary. The length value is stored as network byte order integer.
326 For payloads which consist of multiple Vorbis packets the payload
327 data consists of the packet length followed by the packet data for
328 each of the Vorbis packets in the payload.
330 The Vorbis packet length header is the length of the Vorbis data
331 block only and does not count the length field.
335 Barbato Expires October 8, 2007 [Page 6]
337 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
340 The payload packing of the Vorbis data packets MUST follow the
341 guidelines set-out in [3] where the oldest packet occurs immediately
342 after the RTP packet header. Subsequent packets, if any, MUST follow
345 Channel mapping of the audio is in accordance with the Vorbis I
348 2.4. Example RTP Packet
350 Here is an example RTP packet containing two Vorbis packets.
355 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
356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
357 | 2 |0|0| 0 |0| PT | sequence number |
358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
359 | timestamp (in sample rate units) |
360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
361 | synchronisation source (SSRC) identifier |
362 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
363 | contributing source (CSRC) identifiers |
365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
367 Figure 4: Example Packet (RTP Headers)
372 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
373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
374 | Ident | 0 | 0 | 2 pks |
375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
376 | length | vorbis data ..
377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
380 | length | next vorbis packet data ..
381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
385 Figure 5: Example Packet (Payload Data)
387 The payload data section of the RTP packet begins with the 24 bit
391 Barbato Expires October 8, 2007 [Page 7]
393 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
396 Ident field followed by the one octet bitfield header, which has the
397 number of Vorbis frames set to 2. Each of the Vorbis data frames is
398 prefixed by the two octets length field. The Packet Type and
399 Fragment Type are set to 0. The Configuration that will be used to
400 decode the packets is the one indexed by the ident value.
403 3. Configuration Headers
405 Unlike other mainstream audio codecs Vorbis has no statically
406 configured probability model. Instead, it packs all entropy decoding
407 configuration, VQ and Huffman models into a data block that must be
408 transmitted to the decoder along with the compressed data. A decoder
409 also requires information detailing the number of audio channels,
410 bitrates and similar information to configure itself for a particular
411 compressed data stream. These two blocks of information are often
412 referred to collectively as the "codebooks" for a Vorbis stream, and
413 are nominally included as special "header" packets at the start of
414 the compressed data. In addition, the Vorbis I specification [12]
415 requires the presence of a comment header packet which gives simple
416 metadata about the stream, but this information is not required for
417 decoding the frame sequence.
419 Thus these two codebook header packets must be received by the
420 decoder before any audio data can be interpreted. These requirements
421 pose problems in RTP, which is often used over unreliable transports.
423 Since this information must be transmitted reliably and, as the RTP
424 stream may change certain configuration data mid-session, there are
425 different methods for delivering this configuration data to a client,
426 both in-band and out-of-band which is detailed below. SDP delivery
427 is used to set up an initial state for the client application. The
428 changes may be due to different codebooks as well as different
429 bitrates of the stream.
431 The delivery vectors in use are specified by an SDP attribute to
432 indicate the method and the optional URI where the Vorbis Packed
433 Configuration (Section 3.1.1) Packets could be fetched. Different
434 delivery methods MAY be advertised for the same session. The in-band
435 Configuration delivery SHOULD be considered as baseline, out-of-band
436 delivery methods that don't use RTP will not be described in this
437 document. For non chained streams, the Configuration recommended
438 delivery method is inline the Packed Configuration (Section 3.1.1) in
439 the SDP as explained in the IANA considerations (Section 7.1)
442 The 24 bit Ident field is used to map which Configuration will be
443 used to decode a packet. When the Ident field changes, it indicates
447 Barbato Expires October 8, 2007 [Page 8]
449 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
452 that a change in the stream has taken place. The client application
453 MUST have in advance the correct configuration and if the client
454 detects a change in the Ident value and does not have this
455 information it MUST NOT decode the raw Vorbis data associated until
456 it fetches the correct Configuration.
458 3.1. In-band Header Transmission
460 The Packed Configuration (Section 3.1.1) Payload is sent in-band with
461 the packet type bits set to match the Vorbis Data Type. Clients MUST
462 be capable of dealing with fragmentation and periodic re-transmission
463 of the configuration headers.
465 3.1.1. Packed Configuration
467 A Vorbis Packed Configuration is indicated with the Vorbis Data Type
468 field set to 1. Of the three headers, defined in the Vorbis I
469 specification [12], the identification and the setup will be packed
470 together, the comment header is completely suppressed. Is up to the
471 client to provide a minimal size comment header to the decoder if
472 required by the implementation.
503 Barbato Expires October 8, 2007 [Page 9]
505 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
509 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
511 |V=2|P|X| CC |M| PT | xxxx |
512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
515 | synchronization source (SSRC) identifier |
516 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
517 | contributing source (CSRC) identifiers |
519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
523 | length | Identification ..
524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
538 Figure 6: Packed Configuration Figure
540 The Ident field is set with the value that will be used by the Raw
541 Payload Packets to address this Configuration. The Fragment type is
542 set to 0 since the packet bears the full Packed configuration, the
543 number of packet is set to 1.
545 3.2. Out of Band Transmission
547 This section, as stated above, does not cover all the possible out-
548 of-band delivery methods since they rely on different protocols and
549 are linked to specific applications. The following packet definition
550 SHOULD be used in out-of-band delivery and MUST be used when
551 Configuration is inlined in the SDP.
559 Barbato Expires October 8, 2007 [Page 10]
561 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
564 3.2.1. Packed Headers
566 As mentioned above the RECOMMENDED delivery vector for Vorbis
567 configuration data is via a retrieval method that can be performed
568 using a reliable transport protocol. As the RTP headers are not
569 required for this method of delivery the structure of the
570 configuration data is slightly different. The packed header starts
571 with a 32 bit count field which details the number of packed headers
572 that are contained in the bundle. Next is the Packed header payload
573 for each chained Vorbis stream.
575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
576 | Number of packed headers |
577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
585 Figure 7: Packed Headers Overview
587 Since the Configuration Ident and the Identification Header are fixed
588 length there is only a 2 byte length tag to define the length of the
592 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
593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
596 .. length | Identification Header ..
597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
598 .. Identification Header |
599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
605 Figure 8: Packed Headers Detail
607 The key difference between the in-band format and this one, is there
608 is no need for the payload header octet.
615 Barbato Expires October 8, 2007 [Page 11]
617 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
620 3.3. Loss of Configuration Headers
622 Unlike the loss of raw Vorbis payload data, loss of a configuration
623 header can lead to a situation where it will not be possible to
624 successfully decode the stream.
626 Loss of Configuration Packet results in the halting of stream
632 With the Vorbis Data Type flag set to 2, this indicates that the
633 packet contain the comment metadata, such as artist name, track title
634 and so on. These metadata messages are not intended to be fully
635 descriptive but to offer basic track/song information. Clients MAY
636 ignore it completely. The details on the format of the comments can
637 be found in the Vorbis documentation [12].
640 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
641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
642 |V=2|P|X| CC |M| PT | xxxx |
643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
646 | synchronization source (SSRC) identifier |
647 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
648 | contributing source (CSRC) identifiers |
650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
654 | length | Comment ..
655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
661 Figure 9: Comment Packet
663 The 2 bytes length field is necessary since this packet could be
671 Barbato Expires October 8, 2007 [Page 12]
673 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
676 5. Frame Packetization
678 Each RTP packet contains either one Vorbis packet fragment, or an
679 integer number of complete Vorbis packets (up to a maximum of 15
680 packets, since the number of packets is defined by a 4 bit value).
682 Any Vorbis data packet that is less than path MTU SHOULD be bundled
683 in the RTP packet with as many Vorbis packets as will fit, up to a
684 maximum of 15, except when such bundling would exceed an
685 application's desired transmission latency. Path MTU is detailed in
688 A fragmented packet has a zero in the last four bits of the payload
689 header. The first fragment will set the Fragment type to 1. Each
690 fragment after the first will set the Fragment type to 2 in the
691 payload header. The RTP packet containing the last fragment of the
692 Vorbis packet will have the Fragment type set to 3. To maintain the
693 correct sequence for fragmented packet reception the timestamp field
694 of fragmented packets MUST be the same as the first packet sent, with
695 the sequence number incremented as normal for the subsequent RTP
696 packets. The length field shows the fragment length.
698 5.1. Example Fragmented Vorbis Packet
700 Here is an example fragmented Vorbis packet split over three RTP
701 packets. Each packet contains the standard RTP headers as well as
702 the 4 octets Vorbis headers.
727 Barbato Expires October 8, 2007 [Page 13]
729 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
735 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
736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
737 |V=2|P|X| CC |M| PT | 1000 |
738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
741 | synchronization source (SSRC) identifier |
742 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
743 | contributing source (CSRC) identifiers |
745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
749 | length | vorbis data ..
750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
754 Figure 10: Example Fragmented Packet (Packet 1)
756 In this packet the initial sequence number is 1000 and the timestamp
757 is xxxxx. The Fragment type is set to 1, the number of packets field
758 is set to 0, and as the payload is raw Vorbis data the VDT field is
783 Barbato Expires October 8, 2007 [Page 14]
785 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
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 October 8, 2007 [Page 15]
841 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
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.
888 Loss of any of the Configuration fragment will result in the loss of
889 the full Configuration packet with the result detailed in the Loss of
890 Configuration Headers (Section 3.3) section.
895 Barbato Expires October 8, 2007 [Page 16]
897 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
900 6. IANA Considerations
908 rate: indicates the RTP timestamp clock rate as described in RTP
909 Profile for Audio and Video Conferences with Minimal Control.
912 channels: indicates the number of audio channels as described in
913 RTP Profile for Audio and Video Conferences with Minimal
916 delivery-method: indicates the delivery methods in use, the
917 possible values are: inline, in_band, out_band
919 configuration: the base64 [8] representation of the Packed
920 Headers (Section 3.2.1).
924 configuration-uri: the URI of the configuration headers in case
925 of out of band transmission. In the form of
926 "protocol://path/to/resource/". Depending on the specific
927 method, a single configuration packet could be retrived by its
928 number, or multiple packets could be aggregated in a single
929 stream. Such aggregates MAY be compressed using either bzip2
930 [15] or gzip [13]. A sha1 [9] checksum MAY be provided for
931 aggregates. In this latter case the URI will end with the
932 aggregate name, followed by its compressed extension if
933 applies, a "!" and the base64 [8] representation of the
934 sha1hash of the above mentioned compressed aggregated as in:
935 "protocol://path/to/resource/aggregated.bz2!sha1hash". The
936 trailing '/' discriminates which of two methods are in use.
938 Encoding considerations:
940 This media type is framed and contains binary data.
942 Security considerations:
944 See Section 10 of RFC XXXX.
951 Barbato Expires October 8, 2007 [Page 17]
953 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
956 Interoperability considerations:
960 Published specification:
962 RFC XXXX [RFC Editor: please replace by the RFC number of this
963 memo, when published]
965 Ogg Vorbis I specification: Codec setup and packet decode.
966 Available from the Xiph website, http://www.xiph.org
968 Applications which use this media type:
970 Audio streaming and conferencing tools
972 Additional information:
976 Person & email address to contact for further information:
978 Luca Barbato: <lu_zero@gentoo.org> IETF Audio/Video Transport
985 Restriction on usage:
987 This media type depends on RTP framing, and hence is only defined
988 for transfer via RTP [2]
996 IETF AVT Working Group delegated from the IESG
999 6.1. Packed Headers IANA Considerations
1001 The following IANA considerations MUST only be applied to the packed
1007 Barbato Expires October 8, 2007 [Page 18]
1009 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
1014 Subtype name: vorbis-config
1016 Required parameters:
1020 Optional parameters:
1024 Encoding considerations:
1026 This media type contains binary data.
1028 Security considerations:
1030 See Section 10 of RFC XXXX.
1032 Interoperability considerations:
1036 Published specification:
1038 RFC XXXX [RFC Editor: please replace by the RFC number of this
1039 memo, when published]
1041 Applications which use this media type:
1043 Vorbis encoded audio, configuration data.
1045 Additional information:
1049 Person & email address to contact for further information:
1051 Luca Barbato: <lu_zero@gentoo.org>
1052 IETF Audio/Video Transport Working Group
1054 Intended usage: COMMON
1063 Barbato Expires October 8, 2007 [Page 19]
1065 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
1068 Restriction on usage:
1070 This media type doesn't depend on the transport.
1078 IETF AVT Working Group delegated from the IESG
1081 7. SDP related considerations
1083 The following paragraphs defines the mapping of the parameters
1084 described in the IANA considerations section and their usage in the
1085 Offer/Answer Model [7].
1087 7.1. Mapping MIME Parameters into SDP
1089 The information carried in the MIME media type specification has a
1090 specific mapping to fields in the Session Description Protocol (SDP)
1091 [4], which is commonly used to describe RTP sessions. When SDP is
1092 used to specify sessions the mapping are as follows:
1094 o The MIME type ("audio") goes in SDP "m=" as the media name.
1096 o The MIME subtype ("vorbis") goes in SDP "a=rtpmap" as the encoding
1099 o The parameter "rate" also goes in "a=rtpmap" as clock rate.
1101 o The parameter "channels" also goes in "a=rtpmap" as channel count.
1103 o The mandated parameters "delivery-method" and "configuration" MUST
1104 be included in the SDP "a=fmpt" attribute.
1106 o The optional parameter "configuration-uri", when present, MUST be
1107 included in the SDP "a=fmpt" attribute and MUST follow the
1108 delivery-method that applies.
1110 If the stream comprises chained Vorbis files and all of them are
1111 known in advance, the Configuration Packet for each file SHOULD be
1112 passed to the client using the configuration attribute.
1114 The URI specified in the configuration-uri attribute MUST point to a
1115 location where all of the Configuration Packets needed for the life
1119 Barbato Expires October 8, 2007 [Page 20]
1121 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
1124 of the session reside.
1126 The port value is specified by the server application bound to the
1127 address specified in the c attribute. The bitrate value and channels
1128 specified in the rtpmap attribute MUST match the Vorbis sample rate
1129 value. An example is found below.
1133 The following example shows a basic SDP single stream. The first
1134 configuration packet is inlined in the sdp, other configurations
1135 could be fetched at any time from the first provided uri using or all
1136 the known configuration could be downloaded using the second uri.
1137 The inline base64 [8] configuration string is omitted because of the
1141 a=rtpmap:98 vorbis/44100/2
1142 a=fmtp:98 delivery-method=in_band; configuration=base64string;
1143 delivery-method=out_band/rtsp;
1144 configuration-uri=rtsp://path/to/the/resource; delivery-
1145 method=out_band/http; configuration-uri=http://another/path/to/
1146 resource/aggregate.bz2!8b6237eb5154a0ea12811a94e8e2697b3312bc6c;
1148 Note that the payload format (encoding) names are commonly shown in
1149 upper case. MIME subtypes are commonly shown in lower case. These
1150 names are case-insensitive in both places. Similarly, parameter
1151 names are case-insensitive both in MIME types and in the default
1152 mapping to the SDP a=fmtp attribute. The exception regarding case
1153 sensitivity is the configuration-uri URI which MUST be regarded as
1154 being case sensitive. The a=fmtp line is a single line even if it is
1155 presented broken because of clarity.
1157 7.2. Usage with the SDP Offer/Answer Model
1159 The offer, as described in An Offer/Answer Model Session Description
1160 Protocol [7], may contain a large number of delivery methods per
1161 single fmtp attribute, the answerer MUST remove every delivery-method
1162 and configuration-uri not supported. All the parameters MUST not be
1163 altered on answer otherwise.
1166 8. Congestion Control
1168 Vorbis clients SHOULD send regular receiver reports detailing
1169 congestion. A mechanism for dynamically downgrading the stream,
1170 known as bitrate peeling, will allow for a graceful backing off of
1171 the stream bitrate. This feature is not available at present so an
1175 Barbato Expires October 8, 2007 [Page 21]
1177 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
1180 alternative would be to redirect the client to a lower bitrate stream
1181 if one is available.
1186 The following examples are common usage patterns that MAY be applied
1187 in such situations, the main scope of this section is to explain
1188 better usage of the transmission vectors.
1192 This is one of the most common situation: one single server streaming
1193 content in multicast, the clients may start a session at random time.
1194 The content itself could be a mix of live stream, as the wj's voice,
1195 and stored streams as the music she plays.
1197 In this situation we don't know in advance how many codebooks we will
1198 use. The clients can join anytime and users expect to start
1199 listening to the content in a short time.
1201 On join the client will receive the current Configuration necessary
1202 to decode the current stream inlined in the SDP so that the decoding
1203 will start immediately after.
1205 When the streamed content changes the new Configuration is sent in-
1206 band before the actual stream, and the Configuration that has to be
1207 sent inline in the SDP updated. Since the in-band method is
1208 unreliable, an out of band fallback is provided.
1210 The client could choose to fetch the Configuration from the alternate
1211 source as soon it discovers a Configuration packet got lost in-band
1212 or use selective retransmission [14], if the server supports the
1215 A serverside optimization would be to keep an hash list of the
1216 Configurations per session to avoid packing all of them and send the
1217 same Configuration with different Ident tags
1219 A clientside optimization would be to keep a tag list of the
1220 Configurations per session and don't process configuration packets
1224 10. Security Considerations
1226 RTP packets using this payload format are subject to the security
1227 considerations discussed in the RTP specification [2]. This implies
1231 Barbato Expires October 8, 2007 [Page 22]
1233 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
1236 that the confidentiality of the media stream is achieved by using
1237 encryption. Because the data compression used with this payload
1238 format is applied end-to-end, encryption may be performed on the
1239 compressed data. Where the size of a data block is set care MUST be
1240 taken to prevent buffer overflows in the client applications.
1245 This document is a continuation of draft-moffitt-vorbis-rtp-00.txt
1246 and draft-kerr-avt-vorbis-rtp-04.txt. The MIME type section is a
1247 continuation of draft-short-avt-rtp-vorbis-mime-00.txt.
1249 Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including Steve
1250 Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal
1251 Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro,
1252 Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short,
1253 Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David
1254 Barrett, Silvia Pfeiffer, Stefan Ehmann, Alessandro Salvatori.
1255 Politecnico di Torino (LS)^3/IMG Group in particular Federico
1256 Ridolfo, Francesco Varano, Giampaolo Mancini, Juan Carlos De Martin.
1261 12.1. Normative References
1263 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1266 [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
1267 "RTP: A Transport Protocol for real-time applications",
1270 [3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
1271 Conferences with Minimal Control.", RFC 3551.
1273 [4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
1274 Description Protocol", RFC 4566, July 2006.
1276 [5] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
1279 [6] McCann et al., J., "Path MTU Discovery for IP version 6",
1282 [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
1283 Session Description Protocol (SDP)", RFC 3264.
1287 Barbato Expires October 8, 2007 [Page 23]
1289 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
1292 [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
1295 [9] National Institute of Standards and Technology, "Secure Hash
1296 Standard", May 1993.
1298 12.2. Informative References
1300 [10] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
1303 [11] "libvorbis: Available from the Xiph website,
1304 http://www.xiph.org".
1306 [12] "Ogg Vorbis I specification: Codec setup and packet decode.
1307 Available from the Xiph website, http://www.xiph.org".
1309 [13] Deutsch, P., "GZIP file format specification version 4.3",
1312 [14] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
1313 Extended Reports (RTCP XR)", RFC 3611, November 2003.
1315 [15] Seward, J., "libbz2 and bzip2".
1323 Email: lu_zero@gentoo.org
1324 URI: http://www.xiph.org/
1343 Barbato Expires October 8, 2007 [Page 24]
1345 Internet-Draft draft-ietf-avt-rtp-vorbis-02 April 2007
1348 Full Copyright Statement
1350 Copyright (C) The IETF Trust (2007).
1352 This document is subject to the rights, licenses and restrictions
1353 contained in BCP 78, and except as set forth therein, the authors
1354 retain all their rights.
1356 This document and the information contained herein are provided on an
1357 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1358 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1359 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1360 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1361 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1362 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1365 Intellectual Property
1367 The IETF takes no position regarding the validity or scope of any
1368 Intellectual Property Rights or other rights that might be claimed to
1369 pertain to the implementation or use of the technology described in
1370 this document or the extent to which any license under such rights
1371 might or might not be available; nor does it represent that it has
1372 made any independent effort to identify any such rights. Information
1373 on the procedures with respect to rights in RFC documents can be
1374 found in BCP 78 and BCP 79.
1376 Copies of IPR disclosures made to the IETF Secretariat and any
1377 assurances of licenses to be made available, or the result of an
1378 attempt made to obtain a general license or permission for the use of
1379 such proprietary rights by implementers or users of this
1380 specification can be obtained from the IETF on-line IPR repository at
1381 http://www.ietf.org/ipr.
1383 The IETF invites any interested party to bring to its attention any
1384 copyrights, patents or patent applications, or other proprietary
1385 rights that may cover technology that may be required to implement
1386 this standard. Please address the information to the IETF at
1392 Funding for the RFC Editor function is provided by the IETF
1393 Administrative Support Activity (IASA).
1399 Barbato Expires October 8, 2007 [Page 25]