idnits 2.17.00 (12 Aug 2021) /tmp/idnits48417/draft-kerr-avt-vorbis-rtp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 978. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 968. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2005) is 6055 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '13' is defined on line 934, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3533 (ref. '1') ** Obsolete normative reference: RFC 2327 (ref. '5') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 1063 (ref. '6') (Obsoleted by RFC 1191) ** Obsolete normative reference: RFC 1981 (ref. '7') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 3548 (ref. '9') (Obsoleted by RFC 4648) == Outdated reference: draft-ietf-avt-rtcp-feedback has been published as RFC 4585 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Working Group L. Barbato 3 Internet-Draft Xiph.Org 4 Expires: April 24, 2006 October 21, 2005 6 draft-kerr-avt-vorbis-rtp-05 7 RTP Payload Format for Vorbis Encoded Audio 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 24, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes an RTP payload format for transporting Vorbis 41 encoded audio. It details the RTP encapsulation mechanism for raw 42 Vorbis data and details the delivery mechanisms for the decoder 43 probability model, referred to as a codebook and other setup 44 information. 46 Also included within the document are the necessary details for the 47 use of Vorbis with MIME and Session Description Protocol (SDP). 49 Editors Note 51 All references to RFC XXXX are to be replaced by references to the 52 RFC number of this memo, when published. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 7 63 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8 64 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9 65 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9 66 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 10 67 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 10 68 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 12 69 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 12 70 5. Frame Packetizing . . . . . . . . . . . . . . . . . . . . . . 13 71 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 14 72 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 6.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 18 75 7. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 19 76 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 8.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 19 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 82 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 Intellectual Property and Copyright Statements . . . . . . . . . . 23 86 1. Introduction 88 Vorbis is a general purpose perceptual audio codec intended to allow 89 maximum encoder flexibility, thus allowing it to scale competitively 90 over an exceptionally wide range of bitrates. At the high quality/ 91 bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is 92 in the same league as MPEG-2 and MPC. Similarly, the version 1.1 93 reference encoder can encode high-quality CD and DAT rate stereo at 94 below 48k bits/sec without resampling to a lower rate. Vorbis is 95 also intended for lower and higher sample rates (from 8kHz telephony 96 to 192kHz digital masters) and a range of channel representations 97 (monaural, polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 98 255 discrete channels). 100 Vorbis encoded audio is generally encapsulated within an Ogg format 101 bitstream [1], which provides framing and synchronization. For the 102 purposes of RTP transport, this layer is unnecessary, and so raw 103 Vorbis packets are used in the payload. 105 1.1. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [2]. 111 2. Payload Format 113 For RTP based transportation of Vorbis encoded audio the standard RTP 114 header is followed by a 4 octet payload header, then the payload 115 data. The payload headers are used to associate the Vorbis data with 116 its associated decoding codebooks as well as indicating if the 117 following packet contains fragmented Vorbis data and/or the the 118 number of whole Vorbis data frames. The payload data contains the 119 raw Vorbis bitstream information. 121 2.1. RTP Header 123 The format of the RTP header is specified in [3] and shown in Figure 124 Figure 1. This payload format uses the fields of the header in a 125 manner consistent with that specification. 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 |V=2|P|X| CC |M| PT | sequence number | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | timestamp | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | synchronization source (SSRC) identifier | 135 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 136 | contributing source (CSRC) identifiers | 137 | ... | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 1: RTP Header 142 The RTP header begins with an octet of fields (V, P, X, and CC) to 143 support specialized RTP uses (see [3] and [4] for details). For 144 Vorbis RTP, the following values are used. 146 Version (V): 2 bits 148 This field identifies the version of RTP. The version used by this 149 specification is two (2). 151 Padding (P): 1 bit 153 Padding MAY be used with this payload format according to section 5.1 154 of [3]. 156 Extension (X): 1 bit 158 The Extension bit is used in accordance with [3]. 160 CSRC count (CC): 4 bits 162 The CSRC count is used in accordance with [3]. 164 Marker (M): 1 bit 166 Set to zero. Audio silence suppression not used. This conforms to 167 section 4.1 of [12]. 169 Payload Type (PT): 7 bits 171 An RTP profile for a class of applications is expected to assign a 172 payload type for this format, or a dynamically allocated payload type 173 SHOULD be chosen which designates the payload as Vorbis. 175 Sequence number: 16 bits 177 The sequence number increments by one for each RTP data packet sent, 178 and may be used by the receiver to detect packet loss and to restore 179 packet sequence. This field is detailed further in [3]. 181 Timestamp: 32 bits 183 A timestamp representing the sampling time of the first sample of the 184 first Vorbis packet in the RTP packet. The clock frequency MUST be 185 set to the sample rate of the encoded audio data and is conveyed out- 186 of-band as a SDP attribute. 188 SSRC/CSRC identifiers: 190 These two fields, 32 bits each with one SSRC field and a maximum of 191 16 CSRC fields, are as defined in [3]. 193 2.2. Payload Header 195 After the RTP Header section the following 4 octets are the Payload 196 Header. This header is split into a number of bitfields detailing 197 the format of the following payload data packets. 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Ident | F |VDT|# pkts.| 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2: Payload Header 207 Ident: 24 bits 209 This 24 bit field is used to associate the Vorbis data to a decoding 210 Configuration. 212 Fragment type (F): 2 bits 214 This field is set accordingly the following list 216 0 = Not Fragmented 217 1 = Start Fragment 218 2 = Continuation Fragment 219 3 = End Fragment 221 Vorbis Data Type (VDT): 2 bits 222 This field sets the packet payload type for the Vorbis data. There 223 are currently three type of Vorbis payloads. 225 0 = Raw Vorbis payload 226 1 = Vorbis Packed Configuration payload 227 2 = Legacy Vorbis Comment payload 228 3 = Reserved 230 The last 4 bits are the number of complete packets in this payload. 231 This provides for a maximum number of 15 Vorbis packets in the 232 payload. If the packet contains fragmented data the number of 233 packets MUST be set to 0. 235 2.3. Payload Data 237 Raw Vorbis packets are unbounded in length currently, although at 238 some future point there will likely be a practical limit placed on 239 them. Typical Vorbis packet sizes are from very small (2-3 bytes) to 240 quite large (8-12 kilobytes). The reference implementation [11] 241 typically produces packets less than ~800 bytes, except for the setup 242 header packets which are ~4-12 kilobytes. Within an RTP context the 243 maximum packet size, including the RTP and payload headers, SHOULD be 244 kept below the path MTU to avoid packet fragmentation. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | length | vorbis packet data .. 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 3: Payload Data Header 254 Each Vorbis payload packet starts with a two octet length header, 255 which is used to represent the size of the following data payload, 256 followed by the raw Vorbis data padded to the nearest byte boundary. 258 For payloads which consist of multiple Vorbis packets the payload 259 data consists of the packet length followed by the packet data for 260 each of the Vorbis packets in the payload. 262 The Vorbis packet length header is the length of the Vorbis data 263 block only and does not count the length field. 265 The payload packing of the Vorbis data packets MUST follow the 266 guidelines set-out in [4] where the oldest packet occurs immediately 267 after the RTP packet header. 269 Channel mapping of the audio is in accordance with the Vorbis I 270 Specification [12]. 272 2.4. Example RTP Packet 274 Here is an example RTP packet containing two Vorbis packets. 276 RTP Packet Header: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | 2 |0|0| 0 |0| PT | sequence number | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | timestamp (in sample rate units) | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | synchronisation source (SSRC) identifier | 286 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 287 | contributing source (CSRC) identifiers | 288 | ... | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 4: Example Packet (RTP Headers) 293 Payload Data: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Ident | 0 | 0 | 2 pks | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | length | vorbis data .. 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 .. vorbis data | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | length | next vorbis packet data .. 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 .. vorbis data | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 5: Example Packet (Payload Data) 311 The payload data section of the RTP packet starts with the 24 bit 312 Ident field followed by the one octet bitfield header, which has the 313 number of Vorbis frames set to 2. Each of the Vorbis data frames is 314 prefixed by the two octet length field. The Packet Type and Fragment 315 Type are set to 0. The decode Configuration that will be used to 316 decode the packets is the one indexed by the ident value. 318 3. Configuration Headers 320 Unlike other mainstream audio codecs Vorbis has no statically 321 configured probability model. Instead, it packs all entropy decoding 322 configuration, VQ and Huffman models into a data block that must be 323 transmitted to the decoder along with the compressed data. A decoder 324 also requires identification information detailing the number of 325 audio channels, bitrates and other information to configure itself 326 for a particular compressed data stream. These two blocks of 327 information are often referred to collectively as the "codebooks" for 328 a Vorbis stream, and are nominally included as special "header" 329 packets at the start of the compressed data. 331 Thus these two codebook header packets must be received by the 332 decoder before any audio data can be interpreted. In addition, the 333 Vorbis I specification [12] requires the presense of a comment header 334 packet which gives simple metadata about the stream. This 335 requirement poses problems in RTP, which is often used over 336 unreliable transports. 338 Since this information must be transmitted reliably and, as the RTP 339 stream may change certain configuration data mid-session, there are 340 different methods for delivering this configuration data to a client, 341 both in-band and out-of-band which is detailed below. SDP delivery 342 is used to setup an initial state for the client application. The 343 changes may be due to different codebooks as well as different 344 bitrates of the stream. 346 The delivery vectors in use are specified by an SDP attribute to 347 indicate the method and the optional URI where the Vorbis Packed 348 Configuration (Section 3.1.1) Packets could be fetched. Different 349 delivery methods MAY be advertised for the same session. The in-band 350 Configuration delivery SHOULD be considered as baseline, out-of-band 351 delivery methods that don't use RTP will not be described in this 352 document. For non chained streams, the Configuration delivery method 353 RECOMMENDED is inline the Packed Configuration (Section 3.1.1) in the 354 SDP as explained in the IANA considerations (Section 6.1) section. 356 The 24 bit Ident field is used to map which Configuration will be 357 used to decodea packet. When the Ident field changes, it indicates 358 that a change in the stream has taken place. The client application 359 MUST have in advance the correct configuration and if the client 360 detects a change in the Ident value and does not have this 361 information it MUST NOT decode the raw Vorbis data associated until 362 it fetches the correct Configuration. 364 3.1. In-band Header Transmission 366 The Packed Configuration (Section 3.1.1) Payload is sent in-band with 367 the packet type bits set to match the payload type. Clients MUST be 368 capable of dealing with fragmentation and periodic re-transmission of 369 the configuration headers. 371 3.1.1. Packed Configuration 373 A Vorbis Packed Configuration is indicated with the payload type 374 field set to 1. Of the three headers, defined in the Vorbis I 375 specification [12], the identification and the setup will be packed 376 together, the comment header is completely suppressed. Is up to the 377 client provide a minimal size comment header to the decoder if 378 required by the implementation. 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 |V=2|P|X| CC |M| PT | xxxx | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | xxxxx | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | synchronization source (SSRC) identifier | 388 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 389 | contributing source (CSRC) identifiers | 390 | ... | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Ident | 0 | 1 | 1| 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | length | Identification .. 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 .. Identification .. 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 .. Identification .. 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 .. Identification .. 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 .. | Setup .. 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 .. Setup .. 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 .. Setup | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 6: Packed Configuration Figure 411 The Ident field is set with the value that will be used by the Raw 412 Payload Packets to address this Configuration. The Fragment type is 413 set to 0 since the packet bears the full Packed configuration, the 414 number of packet is set to 1. 416 3.2. Out of Band Transmission 418 This section, as stated before, won't cover all the possible out-of- 419 band delivery methods since they rely to different protocols and be 420 linked to a specific application. The following packet definition 421 SHOULD be used in out-of-band delivery and MUST be used when 422 Configuration is inlined in the SDP. 424 3.2.1. Packed Headers 426 As mentioned above the RECOMMENDED delivery vector for Vorbis 427 configuration data is via a retrieval method that can be performed 428 using a reliable transport protocol. As the RTP headers are not 429 required for this method of delivery the structure of the 430 configuration data is slightly different. The packed header starts 431 with a 32 bit count field which details the number of packed headers 432 that are contained in the bundle. Next is the Packed header payload 433 for each chained Vorbis stream. 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Number of packed headers | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Packed header | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Packed header | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Figure 7: Packed Headers Overview 447 Since the Configuration Ident and the Identification Header are fixed 448 length there is only a 2 byte length tag to define the length of the 449 packed headers. 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Ident | .. 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 .. length | Identification Header .. 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 .. Identification Header | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Setup Header .. 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 .. Setup Header | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 8: Packed Headers Detail 467 The key difference between the in-band format and this one, is there 468 is no need for the payload header octet. 470 3.2.1.1. Packed Headers IANA Considerations 472 The following IANA considerations MUST only be applied to the packed 473 headers. 475 MIME media type name: audio 477 MIME subtype: vorbis-config 479 Required Parameters: 481 None. 483 Optional Parameters: 485 None. 487 Encoding considerations: 489 This type is only defined for transfer via non RTP protocols as 490 specified in RFC XXXX. 492 Security Considerations: 494 See Section 6 of RFC 3047. 496 Interoperability considerations: none 498 Published specification: 500 See RFC XXXX for details. 502 Applications which use this media type: 504 Vorbis encoded audio, configuration data. 506 Additional information: none 508 Person & email address to contact for further information: 510 Luca Barbato: 512 Intended usage: COMMON 514 Author/Change controller: 516 Author: Luca Barbato 518 Change controller: IETF AVT Working Group 520 3.3. Loss of Configuration Headers 522 Unlike the loss of raw Vorbis payload data, loss of a configuration 523 header can lead to a situation where it will not be possible to 524 successfully decode the stream. 526 Loss of Configuration Packet results in the halting of stream 527 decoding and SHOULD be reported to the client as well as a loss 528 report sent via RTCP. 530 4. Comment Headers 532 With the payload type flag set to 2, this indicates that the packet 533 contain the comment metadata, such as artist name, track title and so 534 on. These metadata messages are not intended to be fully descriptive 535 but to offer basic track/song information. Clients MAY ignore it 536 completely. The details on the format of the comments can be found 537 in the Vorbis documentation [12]. 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 |V=2|P|X| CC |M| PT | xxxx | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | xxxxx | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | synchronization source (SSRC) identifier | 547 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 548 | contributing source (CSRC) identifiers | 549 | ... | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Ident | 0 | 2 | 1| 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | length | Comment .. 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 .. Comment .. 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 .. Comment | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 9: Comment Packet 563 The 2 bytes length field is necessary since this packet could be 564 fragmented. 566 5. Frame Packetizing 568 Each RTP packet contains either one Vorbis packet fragment, or an 569 integer number of complete Vorbis packets (up to a max of 15 packets, 570 since the number of packets is defined by a 4 bit value). 572 Any Vorbis data packet that is less than path MTU SHOULD be bundled 573 in the RTP packet with as many Vorbis packets as will fit, up to a 574 maximum of 15. Path MTU is detailed in [6] and [7]. 576 If a Vorbis packet, not only data but also Configuration and Comment, 577 is larger than 65535 octets it MUST be fragmented. A fragmented 578 packet has a zero in the last four bits of the payload header. The 579 first fragment will set the Fragment type to 1. Each fragment after 580 the first will set the Fragment type to 2 in the payload header. The 581 RTP packet containing the last fragment of the Vorbis packet will 582 have the Fragment type set to 3. To maintain the correct sequence 583 for fragmented packet reception the timestamp field of fragmented 584 packets MUST be the same as the first packet sent, with the sequence 585 number incremented as normal for the subsequent RTP packets. The 586 length field shows the fragment length. 588 5.1. Example Fragmented Vorbis Packet 590 Here is an example fragmented Vorbis packet split over three RTP 591 packets. Each packet contains the standard RTP headers as well as 592 the 4 octet Vorbis headers. 594 Packet 1: 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |V=2|P|X| CC |M| PT | 1000 | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | xxxxx | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | synchronization source (SSRC) identifier | 604 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 605 | contributing source (CSRC) identifiers | 606 | ... | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Ident | 1 | 0 | 0| 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | length | vorbis data .. 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 .. vorbis data | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Figure 10: Example Fragmented Packet (Packet 1) 618 In this packet the initial sequence number is 1000 and the timestamp 619 is xxxxx. The Fragment type is set to 1, the number of packets field 620 is set to 0, and as the payload is raw Vorbis data the VDT field is 621 set to 0. 623 Packet 2: 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 |V=2|P|X| CC |M| PT | 1001 | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | xxxxx | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | synchronization source (SSRC) identifier | 633 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 634 | contributing source (CSRC) identifiers | 635 | ... | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Ident | 2 | 0 | 0| 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | length | vorbis data .. 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 .. vorbis data | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 Figure 11: Example Fragmented Packet (Packet 2) 647 The Fragment type field is set to 2 and the number of packets field 648 is set to 0. For large Vorbis fragments there can be several of 649 these type of payload packets. The maximum packet size SHOULD be no 650 greater than the path MTU, including all RTP and payload headers. 651 The sequence number has been incremented by one but the timestamp 652 field remains the same as the initial packet. 654 Packet 3: 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |V=2|P|X| CC |M| PT | 1002 | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | xxxxx | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | synchronization source (SSRC) identifier | 664 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 665 | contributing source (CSRC) identifiers | 666 | ... | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Ident | 3 | 0 | 0| 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | length | vorbis data .. 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 .. vorbis data | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 Figure 12: Example Fragmented Packet (Packet 3) 678 This is the last Vorbis fragment packet. The Fragment type is set to 679 3 and the packet count remains set to 0. As in the previous packets 680 the timestamp remains set to the first packet in the sequence and the 681 sequence number has been incremented. 683 5.2. Packet Loss 685 As there is no error correction within the Vorbis stream, packet loss 686 will result in a loss of signal. Packet loss is more of an issue for 687 fragmented Vorbis packets as the client will have to cope with the 688 handling of the Fragment Type. In case of loss of fragments the 689 client MUST discard all the remaining fragments and decode the 690 incomplete packet. If we use the fragmented Vorbis packet example 691 above and the first packet is lost the client MUST detect that the 692 next packet has the packet count field set to 0 and the Fragment type 693 2 and MUST drop it. The next packet, which is the final fragmented 694 packet, MUST be dropped in the same manner. If the missing packet is 695 the last, the received two fragments will be kept and the incomplete 696 vorbis packet decoded. Feedback reports on lost and dropped packets 697 MUST be sent back via RTCP. 699 If a particular multicast session has a large number of participants 700 care must be taken to prevent an RTCP feedback implosion, [10], in 701 the event of packet loss from a large number of participants. 703 Loss of any of the Configuration fragment will result in the loss of 704 the full Configuration packet with the result detailed in the Loss of 705 Configuration Headers (Section 3.3) section. 707 6. IANA Considerations 709 MIME media type name: audio 711 MIME subtype: vorbis 713 Required Parameters: 715 delivery-method: indicates the delivery methods in use, the possible 716 values are:inline, in_band, out_band 718 configuration: the base16 [9] (hexadecimal) representation of the 719 Packed Headers (Section 3.2.1). 721 Optional Parameters: 723 configuration-uri: the URI of the configuration headers in case of 724 out of band transmission. In the form of 725 "protocol://path/to/resource/". Depending on the specific method the 726 single ident packet could be retrived by their number, or aggregated 727 in a single stream. 729 Encoding considerations: 731 This type is only defined for transfer via RTP as specified in RFC 732 XXXX. 734 Security Considerations: 736 See Section 6 of RFC 3047. 738 Interoperability considerations: none 740 Published specification: 742 See the Vorbis documentation [12] for details. 744 Applications which use this media type: 746 Audio streaming and conferencing tools 748 Additional information: none 749 Person & email address to contact for further information: 751 Luca Barbato: 753 Intended usage: COMMON 755 Author/Change controller: 757 Author: Luca Barbato 759 Change controller: IETF AVT Working Group 761 6.1. Mapping MIME Parameters into SDP 763 The information carried in the MIME media type specification has a 764 specific mapping to fields in the Session Description Protocol (SDP) 765 [5], which is commonly used to describe RTP sessions. When SDP is 766 used to specify sessions the mapping are as follows: 768 o The MIME type ("audio") goes in SDP "m=" as the media name. 770 o The MIME subtype ("vorbis") goes in SDP "a=rtpmap" as the encoding 771 name. 773 o The parameter "rate" also goes in "a=rtpmap" as clock rate. 775 o The parameter "channels" also goes in "a=rtpmap" as channel count. 777 o The mandated parameters "delivery-method" and "configuration" MUST 778 be included in the SDP "a=fmpt" attribute. 780 o The optional parameter "configuration-uri", when present, MUST be 781 included in the SDP "a=fmpt" attribute. 783 If the stream comprises chained Vorbis files and all of them are 784 known in advance, the Configuration Packet for each file SHOULD be 785 passed to the client using the configuration attribute. 787 The URI specified in the configuration-uri attribute MUST point to a 788 location where all of the Configuration Packets needed for the life 789 of the session reside. 791 The port value is specified by the server application bound to the 792 address specified in the c attribute. The bitrate value and channels 793 specified in the rtpmap attribute MUST match the Vorbis sample rate 794 value. An example is found below. 796 The answer to any offer, [8], MUST NOT change the URI specified in 797 the configuration-uri attribute. The Configuration inlined in the 798 configuration parameter MAY change. 800 c=IN IP4/6 801 m=audio RTP/AVP 98 802 a=rtpmap:98 VORBIS/44100/2 803 a=delivery:out_band/http 804 a=fmtp:98 delivery-method:in_band,out_band/http; 805 configuration=base16string1; 806 configuration-uri=http://path/to/the/resource 808 Note that the payload format (encoding) names are commonly shown in 809 upper case. MIME subtypes are commonly shown in lower case. These 810 names are case-insensitive in both places. Similarly, parameter 811 names are case-insensitive both in MIME types and in the default 812 mapping to the SDP a=fmtp attribute. The exception regarding case 813 sensitivity is the configuration-uri URI which MUST be regarded as 814 being case sensitive. 816 7. Congestion Control 818 Vorbis clients SHOULD send regular receiver reports detailing 819 congestion. A mechanism for dynamically downgrading the stream, 820 known as bitrate peeling, will allow for a graceful backing off of 821 the stream bitrate. This feature is not available at present so an 822 alternative would be to redirect the client to a lower bitrate stream 823 if one is available. 825 If a particular multicast session has a large number of participants 826 care must be taken to prevent an RTCP feedback implosion, [10], in 827 the event of congestion. 829 8. Examples 831 The following examples are common usage patterns that MAY be applied 832 in such situations, the main scope of this section is to explain 833 better usage of the transmission vectors. 835 8.1. Stream Radio 837 That is one of the most common situation: one single server streaming 838 content in multicast, the clients may start a session at random time. 839 The content itself could be a mix of live stream as the dj's speech 840 and stored streams as the music she plays. 842 In this situation we don't know in advance how many codebooks we will 843 use and. The clients can join anytime and users expect to start 844 listening to the content in a short time 846 On join the client will receive the current Configuration necessary 847 to decode the current stream inlined in the SDP. And can start 848 decoding the current stream. 850 When the streamed content changes the new Configuration is sent in- 851 band befoe the actual stream, and the Configuration that has to be 852 sent inline in the SDP updated. 854 A serverside optimization would be keep an hash list of the 855 Configurations per session to avoid packing them and send the same 856 Configuration with different Ident tags 858 A clientside optimization would be keep a tag list of the 859 Configurations per session and don't process configuration packets 860 already known. 862 Let's assume that the client playout buffer can store at least 7 863 packets and that is the maximum latency. 865 9. Security Considerations 867 RTP packets using this payload format are subject to the security 868 considerations discussed in the RTP specification [3]. This implies 869 that the confidentiality of the media stream is achieved by using 870 encryption. Because the data compression used with this payload 871 format is applied end-to-end, encryption may be performed on the 872 compressed data. Where the size of a data block is set care MUST be 873 taken to prevent buffer overflows in the client applications. 875 10. Acknowledgments 877 This document is a continuation of draft-moffitt-vorbis-rtp-00.txt 878 and draft-kerr-avt-vorbis-rtp-04.txt. The MIME type section is a 879 continuation of draft-short-avt-rtp-vorbis-mime-00.txt. 881 Thanks to the AVT, Ogg Vorbis Communities / Xiph.org including Steve 882 Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal 883 Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro, 884 Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short, 885 Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David 886 Barrett, Silvia Pfeiffer, Politecnico di Torino (LS)^3/IMG Group in 887 particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini, 888 Juan Carlos De Martin. 890 11. References 892 11.1. Normative References 894 [1] Pfeiffer, S., "The Ogg Encapsulation Format Version 0", 895 RFC 3533. 897 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 898 Levels", RFC 2119. 900 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 901 "RTP: A Transport Protocol for real-time applications", 902 RFC 3550. 904 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 905 Conferences with Minimal Control.", RFC 3551. 907 [5] Handley, M. and V. Jacobson, "SDP: Session Description 908 Protocol", RFC 2327. 910 [6] Mogul et al., J., "Path MTU Discovery", RFC 1063. 912 [7] McCann et al., J., "Path MTU Discovery for IP version 6", 913 RFC 1981. 915 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 916 Session Description Protocol (SDP)", RFC 3264. 918 [9] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 919 RFC 3548. 921 [10] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 922 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 923 Internet Draft (draft-ietf-avt-rtcp-feedback-11: Work in 924 progress). 926 11.2. Informative References 928 [11] "libvorbis: Available from the Xiph website, 929 http://www.xiph.org". 931 [12] "Ogg Vorbis I specification: Codec setup and packet decode. 932 Available from the Xiph website, http://www.xiph.org". 934 [13] "Ogg Vorbis I specification: Comment field and header 935 specification. Available from the Xiph website, 936 http://www.xiph.org". 938 Author's Address 940 Luca Barbato 941 Xiph.Org 943 Email: lu_zero@gentoo.org 944 URI: http://www.xiph.org/ 946 Intellectual Property Statement 948 The IETF takes no position regarding the validity or scope of any 949 Intellectual Property Rights or other rights that might be claimed to 950 pertain to the implementation or use of the technology described in 951 this document or the extent to which any license under such rights 952 might or might not be available; nor does it represent that it has 953 made any independent effort to identify any such rights. Information 954 on the procedures with respect to rights in RFC documents can be 955 found in BCP 78 and BCP 79. 957 Copies of IPR disclosures made to the IETF Secretariat and any 958 assurances of licenses to be made available, or the result of an 959 attempt made to obtain a general license or permission for the use of 960 such proprietary rights by implementers or users of this 961 specification can be obtained from the IETF on-line IPR repository at 962 http://www.ietf.org/ipr. 964 The IETF invites any interested party to bring to its attention any 965 copyrights, patents or patent applications, or other proprietary 966 rights that may cover technology that may be required to implement 967 this standard. Please address the information to the IETF at 968 ietf-ipr@ietf.org. 970 Disclaimer of Validity 972 This document and the information contained herein are provided on an 973 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 974 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 975 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 976 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 977 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 978 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 980 Copyright Statement 982 Copyright (C) The Internet Society (2005). This document is subject 983 to the rights, licenses and restrictions contained in BCP 78, and 984 except as set forth therein, the authors retain all their rights. 986 Acknowledgment 988 Funding for the RFC Editor function is currently provided by the 989 Internet Society.