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