idnits 2.17.1 draft-ietf-avt-rtp-ipmr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 540 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 141 instances of too long lines in the document, the longest one being 27 characters in excess of 72. ** There are 64 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (February 25, 2009) is 5532 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC4566' on line 419 looks like a reference -- Missing reference section? 'RFC3550' on line 439 looks like a reference -- Missing reference section? '1' on line 453 looks like a reference -- Missing reference section? '2' on line 455 looks like a reference -- Missing reference section? '3' on line 457 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group 3 Internet Draft SPIRIT DSP 4 Intended status: Informational February 25, 2009 6 RTP Payload Format for IP-MR Speech Codec draft-ietf-avt-rtp-ipmr-02.txt 8 Status of this Memo 10 This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 11 BCP 79. 13 Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights 14 reserved. 15 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 16 Documents in effect on the date of publication of this document (http://trustee.ietf.org/license- 17 info). Please review these documents carefully, as they describe your rights and restrictions with 18 respect to this document. 20 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, 25 replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on August 25, 2009. 35 Abstract 37 This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech 38 signals into the Real-time Transport Protocol (RTP). The payload format supports transmission 39 of multiple frames per payload and introduced redundancy for robustness against packet loss. 41 Table of Contents 43 1. Introduction 2 44 2. IP-MR Codec Description 2 45 3. Payload Format 4 46 3.1. Payload Format Structure 4 47 3.2. Payload Header 4 48 3.3. Speech Table of Contents 5 49 3.4. Speech Data 5 50 3.5. Redundancy Header 5 51 3.6. Redundancy Table of Contents 6 52 3.7. Redundancy Data 6 53 4. Payload Examples 6 54 4.1. Payload Carrying a Single Frame 6 55 4.2. Payload Carrying Multiple Frames with Redundancy 7 56 5. Media Type Registration 8 57 5.1. Registration of media subtype audio/ip-mr_v2.5 8 58 5.2. Mapping Media Type Parameters into SDP 9 59 6. Security Considerations 9 60 7. IANA Considerations 10 61 8. Normative References 10 62 9. Author's Information 10 63 10. Expiration date 10 64 11. Legal Terms 10 65 1. Introduction 66 This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech 67 signals into the Real-time Transport Protocol (RTP). The payload format supports transmission 68 of multiple frames per payload and introduced redundancy for robustness against packet loss. 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119. 74 2. IP-MR Codec Description 76 The IP-MR codec is scalable adaptive multi-rate wideband speech codec designed by SPIRIT for 77 use in IP based networks. These codec is suitable for real time communications such as 78 telephony and videoconferencing. 80 The codec operates on 20 ms frames at 16 kHz sampling rate and has an algorithmic delay of 25 81 ms. 83 The IP-MR supports six wide band speech coding modes with respective bit rates ranging from 84 about 7.7 to about 34.2 kbps. The coding mode can be changed at any 20 ms frame boundary 85 making possible to dynamically adjust the speech encoding rate during a session to adapt to the 86 varying transmission conditions. 88 The coded frame consists of multiple coding layers-base (or core) layer and several enhancement 89 layers which are coded independently. These enhancement layers can be omitted and remaining 90 base layer can be meaningfully decoded without artifacts. This making bit stream scalable and 91 allows reduce bit rate during transmission without re-encoding. 93 This memo specifies an optional form of redundancy coding within RTP for protection against 94 packet loss. It is based on commonly known scheme when previously transmitted frames are 95 aggregated together with new ones. Each frame is retransmitted once in the following RTP 96 payload packet. f(n-2)...f(n+4) denote a sequence of speech frames, and p(n-1)...p(n+4) a 97 sequence of payload packets: 99 --+--------+--------+--------+--------+--------+--------+--------+-- 100 | f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) | 101 --+--------+--------+--------+--------+--------+--------+--------+-- 103 <---- p(n-1) ----> 104 <----- p(n) -----> 105 <---- p(n+1) ----> 106 <---- p(n+2) ----> 107 <---- p(n+3) ----> 108 <---- p(n+4) ----> 110 But because of scalable nature of IP-MR codec there is no need to duplicate a whole previous 111 frame - only core layer may be retransmitted. This reduces redundancy overhead while keeping 112 efficiency. Moreover, the speech bits encoded in core layer are divided on six classes (from A to 113 F) of perceptual sensitivity to errors. Using these classes as introduced redundancy make 114 possible to adjust trade-off between overhead and robustness against packet loss. 116 The mechanism described does not really require signaling at the session setup. The sender is 117 responsible for selecting an appropriate amount of redundancy based on feedback about the 118 channel conditions. 120 The main codec characteristics can be summarized as follows: 122 * Wideband, 16 kHz, speech codec 124 * Adaptive multi rate with six modes from about 7.7 to about 34.2 kbps 126 * Bit rate scalable 128 * Variable bit rate changing in accordance with actual speech content 130 * Discontinuous Transmission (DTX), silence suppression and comfort noise generation 132 * In-band redundancy scheme for protection against packet loss 134 3. Payload Format 135 3.1. Payload Format Structure 137 The IP-MR payload format consists of a payload header with general information about packet, a 138 speech table of contents (TOC), and speech data. An optional redundancy section follows after 139 speech data. The redundancy section consists of redundancy header, redundancy TOC and 140 redundancy data payload. 142 The following diagram shows the standard payload format layout: 143 +---------+--------+--------+- - - - - - +- - - - - - +- - - - - - + 144 | payload | speech | speech | redundancy | redundancy | redundancy | 145 | header | TOC | data | header | TOC | data | 146 +---------+--------+--------+- - - - - - +- - - - - - +- - - - - - + 147 3.2. Payload Header 149 The payload header has the following format: 150 0 1 151 0 1 2 3 4 5 6 7 8 9 0 1 152 +-+-+-+-+-+-+-+-+-+-+-+-+ 153 |T| CR | BR |D|A|GR |R| 154 +-+-+-+-+-+-+-+-+-+-+-+-+ 156 * T (1 bit): Reserved compatibility with future extensions. SHOULD be set to 0. 158 * CR (3 bits): coding rate of frame(s) in this packet, as per the following table: 159 +-------+--------------+ 160 | CR | avg. bitrate | 161 +-------+--------------+ 162 | 0 | 7.7 kbps | 163 | 1 | 9.8 kbps | 164 | 2 | 14.3 kbps | 165 | 3 | 20.8 kbps | 166 | 4 | 27.9 kbps | 167 | 5 | 34.2 kbps | 168 | 6 | (reserved) | 169 | 7 | NO_DATA | 170 +-------+--------------+ 172 The CR value 7 (NO_DATA) indicates that there is no speech data (and speech TOC 173 accordingly) in the payload. This MAY be used to transmit redundancy data only. The value 6 is 174 reserved. If receiving this value the packet SHOULD be discarded. 176 * BR (3 bits): base rate for core layer of frame(s) in this packet. Values in the range 0-5 177 indicate bitrates for core layer, same as for CR. Values 6 and 7 are reserved. If one of 178 these values is received the packet SHOULD be discarded. The base rate is the lowest 179 rate for scalability, so speech payload can be scaled down not lower than BR value. If a 180 received packet has BR > CR then during decoding it will be assumed that BR = CR. 182 * D (1 bit): indicates if the DTX mode is allowed or not. 184 * A (1 bit): byte-aligned payload. If A=1 then all speech frames MUST be byte-aligned. 185 This mode speeds up speech data access. The A=0 value specifies bandwidth-efficient 186 mode with no byte alignment (including end of header). 188 * GR (2 bits): number of frames in packet (grouping size). Actual grouping size is GR + 1, 189 thus maximum grouping supported is 4. 191 * R (1 bit): redundancy presence bit. If R=1 then the packet contains redundancy 192 information for lost packets recovery. In this case after speech data the redundancy 193 section is present. 195 3.3. Speech Table of Contents 197 The speech TOC contains entries for each frame in packet (grouping size in total). Each entry 198 contains a single field: 200 0 201 +-+ 202 |E| 203 +-+ 205 * E (1 bit): frame existence indicator. If set to 0, this indicates the corresponding frame is 206 absent and the receiver should set special LOST_FRAME flag for decoder. This can be 207 followed by the lost frame itself or by empty frames generated by the encoder during 208 silence intervals in DTX mode. 210 Note that if CR flag from payload header is 7 (NO_DATA) then speech TOC is empty. 212 3.4. Speech Data 214 Speech data of a payload contains one or more speech frames or comfort noise frames, as 215 specified in the speech TOC of the payload. 217 Each speech frame represents 20 ms of speech encoded with the rate indicated in the CR and 218 base rate indicated in BR field of the payload header. The length of the speech frame is variable 219 due to the nature of the codec and can be calculated after decoding. 221 3.5. Redundancy Header 223 If a packet contains redundancy (R field of payload header is 1) the speech data is followed by 224 redundancy header: 226 0 1 2 3 4 5 227 +-+-+-+-+-+-+ 228 | CL1 | CL2 | 229 +-+-+-+-+-+-+ 231 Redundancy header consists of two fields. Each field contains class specifier for amount of 232 redundancy partly taken from the preceding packet (CL1) and pre-preceding packet (CL2), e.g. 233 distant from the current packet by 1 and 2 packets accordingly. The values are listed in the table 234 below: 236 +-------+-------------------+ 237 | CL | amount redundancy | 238 +-------+-------------------+ 239 | 0 | NONE | 240 | 1 | CLASS A | 241 | 2 | CLASS B | 242 | 3 | CLASS C | 243 | 4 | CLASS D | 244 | 5 | CLASS E | 245 | 6 | CLASS F | 246 | 7 | (reserved) | 247 +-------+-------------------+ 249 Each specifier takes 3 bits, thus the total redundancy header size is 6 bits. 251 3.6. Redundancy Table of Contents 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Pkt1 Entries| Pkt2 Entries| 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 The redundancy TOC contains entries for redundancy frames from preceding and pre-preceding 258 packets. Each entry takes 1 bit like speech TOC entry (3.3): 259 0 260 +-+ 261 |E| 262 +-+ 264 * E (1 bit): frame existence indicator. If set to 0, this indicates the corresponding frame is 265 absent. 267 * For each preceding and pre-preceding packet the number of entries is equal to the 268 grouping size of the current packet. E.g. maximum number of entries is 4*2 = 8. 270 * If class specifier in the redundancy header is CL=0 (NO_DATA) then there is no entries 271 for corresponding packet redundancy. 273 3.7. Redundancy Data 275 Redundancy data of a payload contains redundancy information for one or more speech frames 276 or comfort noise frames that may be lost during transition, as specified in the redundancy TOC 277 of the payload. Actually redundancy is the most important part of preceding frames representing 278 20 ms of speech. This data MAY be used for partial reconstruction of lost frames. The amount of 279 available redundancy is specified by CL flag in redundancy header section (3.5). This flag 280 SHOULD be passed to decoder. The length of redundancy frame is variable and can be 281 calculated after decoding. 283 4. Payload Examples 284 A few examples to highlight the payload format follow. 285 4.1. Payload Carrying a Single Frame 287 The following diagram shows a standard IP-MR payload carrying a single speech frame without 288 redundancy: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |0|CR=1 |BR=0 |0|0|0 0|0|1|sp(0) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | sp(193)|P| 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 In the payload the speech frame is not damaged at the IP origin (E=1), the coding rate is 9.7 kbps 309 (CR=1), the base rate is 7.8 kbps (BR=0), and the DTX mode is off. There is no byte alignment 310 (A=0) and no redundancy (R=0). The encoded speech bits - s(0) to s(193) - are placed 311 immediately after TOC. Finally, one zero bit is added at the end as padding to make the payload 312 byte aligned. 314 4.2. Payload Carrying Multiple Frames with Redundancy 316 The following diagram shows a payload that contains three frames, one of them with no speech 317 data. The coding rate is 7.7 kbps (CR=0), the base rate is 7.7 kbps (BR=0), and the DTX mode 318 is on. The speech frames are byte aligned (A=1), so 1 zero bit is added at the end of the header. 319 Besides the speech frames the payload contains six redundancy frames (three per each delayed 320 packet). 322 The first speech frame consists of bits sp1(0) to sp1(92). After that 3 bits are added for byte 323 alignment. The second frame does not contain any speech information that is represented in the 324 payload by its TOC entry. The third frame consists of bits sp3(0) to sp3(171). 326 The redundancy header follows after speech data. The one-packet- delayed redundancy contains 327 class A+B bits (CL1=2), and two-packet- delayed redundancy contains class A bits (Cl2=1). The 328 one-packet- delayed redundancy contains three frames with 20, 39 and 35 bits respectively. The 329 first frame of two-packet-delayed redundancy is absent, it is represented in its TOC entry, and 330 two other frames have sizes 15 and 19 bits. 332 Note that all speech frames are padded with zero bits for byte alignment. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 |0|CR=0 |BR=0 |1|1|1 0|1|1 0 1|P|sp1(0) | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | sp1(92)|P|P|P|sp3(0) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | sp3(171)|P|P|P|P| 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |CL1=2|CL2=1|1 1 1|0 1 1|red1_1(0) red1_1(19)| 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 |red1_2(0) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | red1_2(38)|red1_3(0) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | red1_3(34)|red2_2(0) red2_2(14)|red2_3(0) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | red2_3(18)|P|P|P|P| 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 5. Media Type Registration 368 This section describes the media types and names associated with this payload format. 370 5.1. Registration of media subtype audio/ip-mr_v2.5 372 Type name: audio 374 Subtype name: ip-mr_v2.5 376 Required parameters: none 378 Optional parameters: 380 * ptime: Gives the length of time in milliseconds represented by the media in a packet. 381 Allowed values are: 20, 40, 60 and 80. 383 Encoding considerations: 384 This media type is framed binary data (see RFC 4288, Section 4.8). 386 Security considerations: 387 See RFC 3550 389 Interoperability considerations: none 391 Published specification: 392 RFC XXXX 394 Applications that use this media type: 395 Real-time audio applications like voice over IP and teleconference, and multi-media 396 streaming. 398 Additional information: none 400 Person & email address to contact for further information: 401 Elena Berlizova 402 berlizova@spiritdsp.com 404 Intended usage: COMMON 406 Restrictions on usage: 407 This media type depends on RTP framing, and hence is only defined for transfer via RTP 408 (RFC 3550). 410 Author: 411 Sergey Ikonin 413 Change controller: 414 IETF Audio/Video Transport working group delegated from the IESG. 416 5.2. Mapping Media Type Parameters into SDP 418 The information carried in the media type specification has a specific mapping to fields in the 419 Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP 420 sessions. When SDP is used to specify sessions employing the IP-MR codec, the mapping is as 421 follows: 423 * The media type ("audio") goes in SDP "m=" as the media name. 425 * The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The 426 RTP clock rate in "a=rtpmap" MUST 16000. 428 * The parameter "ptime" goes in the SDP "a=ptime" attributes. 430 Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the 431 media type parameter string as a semicolon- separated list of parameter=value pairs. 433 Note that the payload format (encoding) names are commonly shown in upper case. Media 434 subtypes are commonly shown in lower case. These names are case-insensitive in both places. 436 6. Security Considerations 438 RTP packets using the payload format defined in this specification are subject to the security 439 considerations discussed in the RTP specification [RFC3550], and any appropriate RTP profile. 440 This implies that confidentiality of the media streams is achieved by encryption. Encryption 441 may be performed after compression so there is no conflict between the two operations. 443 This payload format does not exhibit any significant non-uniformity in the receiver side 444 computational complexity for packet processing, and thus is unlikely to pose a denial-of-service 445 threat due to the receipt of pathological data. 447 7. IANA Considerations 449 One media type has been defined and needs registration in the media types registry. 451 8. Normative References 453 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 454 2119, March 1997. 455 [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 456 "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 457 [3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 458 4566, July 2006. 460 9. Author's Information 462 Sergey Ikonin 464 Russia 465 109004 B.Kommunisticheskaya st. 27 466 Tel: +7 495 661-2178 467 Fax: +7 495 912-6786 468 Email: ikonin@spiritdsp.com 470 10. Expiration date 472 This Internet-Draft will expire on August 25, 2009. 474 11. Legal Terms 475 All IETF Documents and the information contained therein are provided on an "AS IS" basis and 476 THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED 477 BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 478 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 479 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 480 INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 481 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 483 The IETF Trust takes no position regarding the validity or scope of any Intellectual Property 484 Rights or other rights that might be claimed to pertain to the implementation or use of the 485 technology described in any IETF Document or the extent to which any license under such rights 486 might or might not be available; nor does it represent that it has made any independent effort to 487 identify any such rights. 489 Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of 490 licenses to be made available, or the result of an attempt made to obtain a general license or 491 permission for the use of such proprietary rights by implementers or users of this specification 492 can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 494 The IETF invites any interested party to bring to its attention any copyrights, patents or patent 495 applications, or other proprietary rights that may cover technology that may be required to 496 implement any standard or specification contained in an IETF Document. Please address the 497 information to the IETF at ietf-ipr@ietf.org. 499 The definitive version of an IETF Document is that published by, or under the auspices of, the 500 IETF. Versions of IETF Documents that are published by third parties, including those that are 501 translated into other languages, should not be considered to be definitive versions of IETF 502 Documents. The definitive version of these Legal Provisions is that published by, or under the 503 auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, 504 including those that are translated into other languages, should not be considered to be definitive 505 versions of these Legal Provisions. 507 For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each 508 Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust 509 pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or 510 rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, 511 shall have any effect and shall be null and void, whether published or posted by such 512 Contributor, or included with or in such Contribution.