idnits 2.17.1 draft-westerlund-avt-rtp-g719-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1085. 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 Copyright Line does not match the current year == Line 652 has weird spacing: '... Packet n: 1...' -- 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 (June 16, 2008) is 5792 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) -- Looks like a reference, but probably isn't: '12' on line 195 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-08 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T-G719' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft I. Johansson 4 Intended status: Standards Track Ericsson AB 5 Expires: December 18, 2008 June 16, 2008 7 RTP Payload format for G.719 8 draft-westerlund-avt-rtp-g719-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 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 December 18, 2008. 35 Abstract 37 This document specifies the payload format for packetization of the 38 G.719 full-band codec encoded audio signals into the Real-time 39 Transport Protocol (RTP). The payload format supports transmission 40 of multiple channels, multiple frames per payload, and interleaving. 42 Requirements Language 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 52 3. G.719 Description . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Payload format Capabilities . . . . . . . . . . . . . . . . . 4 54 4.1. Multi-rate Encoding and Rate Adaptation . . . . . . . . . 4 55 4.2. Support for Multi-Channel Sessions . . . . . . . . . . . . 4 56 4.3. Robustness against Packet Loss . . . . . . . . . . . . . . 5 57 4.3.1. Use of Forward Error Correction (FEC) . . . . . . . . 5 58 4.3.2. Use of Frame Interleaving . . . . . . . . . . . . . . 6 59 5. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 8 61 5.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 8 62 5.2.1. Basic ToC element . . . . . . . . . . . . . . . . . . 8 63 5.3. Basic mode . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5.4. Interleaved mode . . . . . . . . . . . . . . . . . . . . . 10 65 5.5. Audio Data . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5.6. Implementation Considerations . . . . . . . . . . . . . . 11 67 5.6.1. Receiving Redundant Frames . . . . . . . . . . . . . . 11 68 5.6.2. Interleaving . . . . . . . . . . . . . . . . . . . . . 11 69 5.6.3. Decoding Validation . . . . . . . . . . . . . . . . . 13 70 6. Payload Examples . . . . . . . . . . . . . . . . . . . . . . . 13 71 6.1. 3 mono frames with 2 different bitrates . . . . . . . . . 13 72 6.2. 2 stereo frame-blocks of the same bitrate . . . . . . . . 14 73 6.3. 4 mono frames interleaved . . . . . . . . . . . . . . . . 14 74 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 15 75 7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 15 76 7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 17 77 7.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 18 78 7.2.2. Declarative SDP Considerations . . . . . . . . . . . . 19 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 80 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 20 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 82 10.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 20 83 10.2. Authentication and Integrity . . . . . . . . . . . . . . . 21 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 12.1. Informative References . . . . . . . . . . . . . . . . . . 21 87 12.2. Normative References . . . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 89 Intellectual Property and Copyright Statements . . . . . . . . . . 24 91 1. Introduction 93 This document specifies the payload format for packetization of the 94 G.719 719 full-band(FB) codec encoded audio signals into the Real- 95 time Transport Protocol (RTP) [RFC3550]. The payload format supports 96 transmission of multiple channels, multiple frames per payload, 97 packet loss robustness methods using redundancy or interleaving. 99 This document starts with conventions, a brief description of the 100 codec, and the payload formats capabilities. The payload format is 101 specified in Section 5. Examples can be found in Section 6. The 102 media type and its mappings to SDP, usage in SDP offer/answer is then 103 specified. The document ends with considerations around congestion 104 control and security. 106 2. Conventions, Definitions and Acronyms 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119. 112 The term "frame-block" is used in this document to describe the time- 113 synchronized set of audio frames in a multi-channel audio session. 114 In particular, in an N-channel session, a frame-block will contain N 115 audio frames, one from each of the channels, and all N speech frames 116 represents exactly the same time period. 118 3. G.719 Description 120 The ITU-T G.719 full-band codec is a transform coder based on 121 Modulated Lapped Transform (MLT) . G.719 is a low complexity full 122 bandwidth codec for conversational speech and audio coding. The 123 encoder input and decoder output are sampled at 48 kHz. The codec 124 enables full bandwidth, from 20 Hz to 20 kHz, encoding of speech, 125 music and general audio content at rates from 32 kbit/s up to 128 126 kbit/s. The codec operates on 20ms frames and has an algorithmic 127 delay of 40 ms. 129 The codec provides excellent quality for speech, music and other 130 types of audio. Some of the applications for which this coder is 131 suitable are: 133 o Real-time communications such as video conferencing and telephony. 135 o Streaming audio 136 o Archival and messaging 138 The encoding and decoding algorithm can change the bit rate at any 139 20ms frame boundary. The encoder receives the audio sampled at 140 48kHz. The support of other sampling rates is possible by re- 141 sampling the input signal to the codec's sampling rate, i.e. 48kHz, 142 however, this functionality is not part of the standard. 144 The encoding is performed on equally sized frames. For each frame, 145 the encoder decides on two encoding modes, a transient mode and a 146 stationary mode. The decision is based on statistics derived from 147 the input signal. The stationary mode uses a long MLT that leads to 148 a spectrum of 960 coefficients while the transient encoding mode uses 149 a short MLT (higher time resolution transform) which results in 4 150 spectra (4 x 240 = 960 coefficients). The encoding of the spectrum 151 is done in two steps. First, the spectral envelope is computed, 152 quantized and Huffman encoded. The envelope is computed on a non- 153 uniform frequency subdivision. From the coded spectral envelope, a 154 weighted spectral envelope is derived and is used for bit-allocation, 155 this process is also repeated at the decoder, thus only the spectral 156 envelope is transmitted. The output of the bit-allocation is used in 157 order to quantize the spectra. In addition, for stationary frames 158 the encoder estimates the amount of noise level. The decoder applies 159 the reverse operation upon reception of the bitstream. The non-coded 160 coefficients (i.e. no bits allocated) are replaced by entries of a 161 noise codebook which is built based on the decoded coefficients. 163 4. Payload format Capabilities 165 This payload format have a number of capabilities and this section 166 discuss them in some detail. 168 4.1. Multi-rate Encoding and Rate Adaptation 170 G.719 supports multi-rate encoding capability that enables on a per 171 frame basis variation of the encoding rate. This enables support for 172 bit-rate adaptation and congestion control. The possibility to 173 aggregate multiple audio frames into a single RTP payload is another 174 dimension of adaptation. The RTP and payload format overhead can 175 thus be reduced by the aggregation at the cost of increased delay and 176 reduced packet-loss robustness. 178 4.2. Support for Multi-Channel Sessions 180 The RTP payload format defined in this document supports multi- 181 channel audio content (e.g. stereophonic or surround audio sessions). 182 Although the G.719 codec itself does not support encoding of multi- 183 channel audio content into a single bit stream, it can be used to 184 separately encode and decode each of the individual channels. To 185 transport (or store) the separately encoded multi-channel content, 186 the audio frames for all channels that are framed and encoded for the 187 same 20 ms period are logically collected in a "frame-block". 189 At the session setup, out-of-band signaling must be used to indicate 190 the number of channels in the session, and the order of the audio 191 frames from different channels in each frame-block. When using SDP 192 for signaling, the number of channels is specified in the rtpmap 193 attribute and the order of channels carried in each frame-block is 194 implied by the number of channels as specified in Section 4.1 in 195 [12]. 197 4.3. Robustness against Packet Loss 199 The payload format supports several means, including forward error 200 correction (FEC) and frame interleaving, to increase robustness 201 against packet loss. 203 4.3.1. Use of Forward Error Correction (FEC) 205 Generic forward error correction within RTP is defined, for example, 206 in RFC 5109 [RFC5109]. Audio redundancy coding is defined in RFC 207 2198 [RFC2198]. Either scheme can be used to add redundant 208 information to the RTP packet stream and make it more resilient to 209 packet losses, at the expense of a higher bit rate. Please see 210 either RFC for a discussion of the implications of the higher bit 211 rate to network congestion. 213 In addition to these media-unaware mechanisms, this memo specifies an 214 optional G.719 specific form of audio redundancy coding, which may be 215 beneficial in terms of packetization overhead. Conceptually, 216 previously transmitted transport frames are aggregated together with 217 new ones. A sliding window is used to group the frames to be sent in 218 each payload. Figure 1 below shows an example. 219 --+--------+--------+--------+--------+--------+--------+--------+-- 220 | f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) | 221 --+--------+--------+--------+--------+--------+--------+--------+-- 223 <---- p(n-1) ----> 224 <----- p(n) -----> 225 <---- p(n+1) ----> 226 <---- p(n+2) ----> 227 <---- p(n+3) ----> 228 <---- p(n+4) ----> 230 Figure 1: An example of redundant transmission 232 Here, each frame is retransmitted once in the following RTP payload 233 packet. F(n-2)...f(n+4) denote a sequence of audio frames, and p(n- 234 1)...p(n+4) a sequence of payload packets. 236 The mechanism described does not require signaling at the session 237 setup. In other words, the audio sender can choose to use this 238 scheme without consulting the receiver. For a certain timestamp, the 239 receiver may receive multiple copies of a frame containing encoded 240 audio data, even at different encoding rates. The cost of this 241 scheme is bandwidth and the receiver delay necessary to allow the 242 redundant copy to arrive. 244 This redundancy scheme provides a functionality similar to the one 245 described in RFC 2198, but it works only if both original frames and 246 redundant representations are G.719 frames. When the use of other 247 media coding schemes is desirable, one has to resort to RFC 2198. 249 The sender is responsible for selecting an appropriate amount of 250 redundancy based on feedback about the channel conditions, e.g., in 251 the RTP Control Protocol (RTCP) [RFC3550] receiver reports. The 252 sender is also responsible for avoiding congestion, which may be 253 exacerbated by redundancy (see Section 9 for more details). 255 4.3.2. Use of Frame Interleaving 257 To decrease protocol overhead, the payload design allows several 258 audio transport frames to be encapsulated into a single RTP packet. 259 One of the drawbacks of such an approach is that in case of packet 260 loss several consecutive frames are lost. Consecutive frame loss 261 normally renders error concealment less efficient and usually causes 262 clearly audible and annoying distortions in the reconstructed audio. 263 Interleaving of transport frames can improve the audio quality in 264 such cases by distributing the consecutive losses into a number of 265 isolated frame losses, which are easier to conceal. However, 266 interleaving and bundling several frames per payload also increases 267 end-to-end delay and sets higher buffering requirements. Therefore, 268 interleaving is not appropriate for all use cases or devices. 269 Streaming applications should most likely be able to exploit 270 interleaving to improve audio quality in lossy transmission 271 conditions. 273 Note that this payload design supports the use of frame interleaving 274 as an option. The usage of this feature needs to be negotiated in 275 the session setup. 277 The interleaving supported by this format is rather flexible. For 278 example, a continuous pattern can be defined, as depicted in 279 Figure 2. 281 --+--------+--------+--------+--------+--------+--------+--------+-- 282 | f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) | 283 --+--------+--------+--------+--------+--------+--------+--------+-- 285 [ P(n) ] 286 [ P(n+1) ] [ P(n+1) ] 287 [ P(n+2) ] [ P(n+2) ] 288 [ P(n+3) ] 289 [ P(n+4) ] 291 Figure 2: An example of interleaving pattern that has constant delay 293 In Figure 2 the consecutive frames, denoted f(n-2) to f(n+4), are 294 aggregated into packets P(n) to P(n+4), each packet carrying two 295 frames. This approach provides an interleaving pattern that allows 296 for constant delay in both the interleaving and de-interleaving 297 processes. The de-interleaving buffer needs to have room for at 298 least three frames, including the one that is ready to be consumed. 299 The storage space for three frames is needed, for example, when f(n) 300 is the next frame to be decoded: since frame f(n) was received in 301 packet P(n+2), which also carried frame f(n+3), both these frames are 302 stored in the buffer. Furthermore, frame f(n+1) received in the 303 previous packet, P(n+1), is also in the de-interleaving buffer. Note 304 also that in this example the buffer occupancy varies: when frame 305 f(n+1) is the next one to be decoded, there are only two frames, 306 f(n+1) and f(n+3), in the buffer. 308 5. Payload format 310 The main purpose of the payload design for G.719 is to maximize the 311 potential of the codec to its fullest degree with an as minimal 312 overhead as possible. In the design both basic and interleaved modes 313 have been included as the codec is suitable both for conversational 314 and other low delay applications as well as streaming, where more 315 delay is acceptable. 317 The main structural difference between the basic and interleaved 318 modes is the extension of the table of content entries with frame 319 displacement fields in the interleaved mode. The basic mode supports 320 aggregation of multiple consecutive frames in a payload. The 321 interleaved mode supports aggregation of multiple frames that are 322 non-consecutive in time. In both modes it is possible to have frames 323 encoded with different frame types in the same payload. 325 The payload format also supports the usage of G.719 for carrying 326 multi-channel content using one discrete encoder per channel all 327 using the same bit-rate. In this case a complete frame-block with 328 data from all channels are included in the RTP payload. The data is 329 the concatenation of all the encoded audio frames in the order 330 specified for that number of included channels. Also interleaving is 331 done on complete frame-blocks rather than individual audio frames. 333 5.1. RTP Header Usage 335 The RTP timestamp corresponds to the sampling instant of the first 336 sample encoded for the first frame-block in the packet. The 337 timestamp clock frequency SHALL be 48000 Hz. The timestamp is thus 338 also used to recover the correct decoding order of the frame-blocks. 340 The RTP header marker bit (M) SHALL be set to 1 whenever the first 341 frame-block carried in the packet is the first frame-block in a 342 talkspurt (see definition of the talkspurt in section 4.1 of 343 [RFC3551]). For all other packets the marker bit SHALL be set to 344 zero (M=0). 346 The assignment of an RTP payload type for the format defined in this 347 memo is outside the scope of this document. The RTP profiles in use 348 currently mandates binding the payload type dynamically for this 349 payload format. This is basically necessary due to that the payload 350 type expresses the configuration of the payload itself, i.e. basic or 351 interleaved mode and the number of channels carried. 353 The remaining RTP header fields are used as specified in RFC 3550 354 [RFC3550]. 356 5.2. Payload Structure 358 The payload consists of one or more table of contents (ToC) entires 359 followed by the audio data corresponding to the ToC entries. The 360 following sections describe both the basic mode and the interleaved 361 mode. Each ToC entry MUST be padded to a byte boundary to ensure 362 octet alignment. The rules regarding maximum payload size given in 363 [I-D.ietf-tsvwg-udp-guidelines] SHOULD be followed. 365 5.2.1. Basic ToC element 367 All the different formats and modes in this draft use a common basic 368 ToC which may be extended in the different options described below. 370 0 1 2 3 4 5 6 7 371 +-+-+-+-+-+-+-+-+ 372 |F| L |R|R| 373 +-+-+-+-+-+-+-+-+ 375 Figure 3: Basic TOC element 377 F (1 bit): If set to 1, indicates that this ToC entry is followed by 378 another ToC entry; if set to 0, indicates that this ToC entry is 379 the last one in the ToC. 381 L (5 bits): A field that gives the frame length of each individual 382 frame within the frame-block. 384 L length(bytes) 385 ============================ 386 0 0 NO_DATA 387 1-7 N/A (reserved) 388 8-22 80+10*(L-8) 389 23-27 240+20*(L-23) 390 28-31 N/A (reserved) 392 Figure 4: How to map L values to frame lengths 394 L=0 is used to indicate an empty frame, this may be useful if 395 frames are missing e.g at re-packetization. 396 The value range [1..7] and [28..31] inclusive is reserved for 397 future use in this draft version, if these values occur in a ToC 398 the entire packet SHOULD be treated as invalid and discarded. 399 A few examples are given below where the frame size and the 400 corresponding codec bitrate is computed based on the value L. 402 L Bytes Bitrate(kbps) 403 ============================= 404 8 80 32 405 9 90 36 406 10 100 40 407 12 120 48 408 16 160 64 409 22 220 88 410 23 240 96 411 25 280 112 412 27 320 128 414 Figure 5: Examples of L values and corresponding frame lengths 416 This encoding yields a granularity of 4kbps between 32 and 88kbps 417 and a granularity of 8kps between 88 and 128kbps with a defined 418 range of 32-128kbps. 420 R (2bits): Reserved bits. SHALL be set to 0 on sending and SHALL be 421 ignored on reception. 423 5.3. Basic mode 425 The basic ToC element Figure 3 is extended with a number of frame- 426 blocks field (#frames) to form the ToC entry. The frame-blocks field 427 tells how many frame-blocks of the same length the ToC entry relates 428 to. 430 +-+-+-+-+-+-+-+-+ 431 | #frames | 432 +-+-+-+-+-+-+-+-+ 434 Figure 6: Number of frame-blocks field 436 5.4. Interleaved mode 438 The basic ToC is extended with a number of frame-blocks field 439 (#frames) and the DIS fields to form a ToC entry in interleaved mode. 440 The frame-blocks field tells how many frame-blocks of the same length 441 the ToC relates to. The DIS fields, one for each frame-block 442 indicated by the #frames field, express the interleaving distance 443 between audio frames carried in the payload. If necessary to achieve 444 octet alignment, a 4-bit padding is added. 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | #frames | DIS1 | ... | DISi | ... | DISn | Padd | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 7: Number of frame-block + interleave fields 452 DIS1...DISn (4 bits): A list of n (n=#frames) displacement fields 453 indicating the displacement of the i:th (i=1..n) audio frame-block 454 relative to the preceding frame-block in the payload, in units of 455 20 ms long audio frame-blocks). The four-bit unsigned integer 456 displacement values may be between 0 and 15 indicating the number 457 of audio frame-blocks in decoding order between the (i-1):th and 458 the i:th frame in the payload. Note that for the first ToC entry 459 of the payload the value of DIS1 is meaningless. It SHALL be set 460 to zero by a sender, and SHALL be ignored by a receiver. This 461 frame-block's location in the decoding order is uniquely defined 462 by the RTP timestamp. Note also that for subsequent ToC entries 463 DIS1 indicates the number of frames between the last frame of the 464 previous group and the first frame of this group. 466 Padd (4 bits): To ensure octet alignment, four padding bits SHALL be 467 included at the end of the ToC entry in case there is an odd 468 number of frame-blocks in the group referenced by this ToC entry. 469 These bits SHALL be set to zero and SHALL be ignored by the 470 receiver. If a group containing an even number of frames is 471 referenced by this ToC entry, these padding bits SHALL NOT be 472 included in the payload. 474 5.5. Audio Data 476 The audio data part follows the table of contents. All the octets 477 comprising an audio frame SHALL be appended to the payload as a unit. 478 For each frame-block the audio frames are concatenated in order 479 indicated by table in Section 4.1 of [RFC3551] for the number of 480 channels configured for the payload type in use. So the first 481 channel (left most) indicated comes first followed by the next 482 channel. The audio frame-blocks are packetized in increasing 483 timestamp order within each group of frame-blocks (per ToC entry), 484 i.e. oldest frame-block first. The groups of frame-blocks are 485 packetized in the same order as their corresponding ToC entries. 487 The audio frames are specified in ITU recommendation [ITU-T-G719]. 489 5.6. Implementation Considerations 491 An application implementing this payload format MUST understand all 492 the payload parameters. Any mapping of the parameters to a signaling 493 protocol MUST support all parameters. So an implementation of this 494 payload format in an application using SDP is required to understand 495 all the payload parameters in their SDP-mapped form. This 496 requirement ensures that an implementation always can decide whether 497 it is capable of communicating. 499 Basic mode SHALL be implemented and the interleaved mode SHOULD be 500 implemented. The implementation burden of both is rather small, and 501 supporting both ensures interoperability. However, interleaving is 502 not mandated as it has limited applicability for conversational 503 application that requires tight delay boundaries. 505 5.6.1. Receiving Redundant Frames 507 The reception of redundant audio frames, i.e. more than one audio 508 frame from the same source for the same time slot, MUST be supported 509 by the implementation. In the case that the receiver gets multiple 510 audio frames in different bit-rates for the same time slot it is 511 RECOMMENDED that the receiver keeps the one with the highest bit- 512 rate. 514 5.6.2. Interleaving 516 The use of interleaving requires further considerations. As 517 presented in the example in Section 4.3.2, a given interleaving 518 pattern requires a certain amount of the de-interleaving buffer. 520 This buffer space, expressed in a number of transport frame slots, is 521 indicated by the "interleaving" media type parameter. The number of 522 frame slots needed can be converted into actual memory requirements 523 by considering the 320 bytes per frame used by the highest bit-rate 524 rate of G.719. 526 The information about the frame buffer size is not always sufficient 527 to determine when it is appropriate to start consuming frames from 528 the interleaving buffer. Additional information is needed when the 529 interleaving pattern changes. The "int-delay" media type parameter 530 is defined to convey this information. It allows a sender to 531 indicate the minimal media time that needs to be present in the 532 buffer before the decoder can start consuming frames from the buffer. 533 Because the sender has full control over the interleaving pattern, it 534 can calculate this value. In certain cases (for example, if joining 535 a multicast session with interleaving mid-session), a receiver may 536 initially receive only part of the packets in the interleaving 537 pattern. This initial partial reception (in frame sequence order) of 538 frames can yield too few frames for acceptable quality from the audio 539 decoding. This problem also arises when using encryption for access 540 control, and the receiver does not have the previous key. Although 541 the G.719 is robust and thus tolerant to a high random frame erasure 542 rate, it would have difficulties handling consecutive frame losses at 543 startup. Thus, some special implementation considerations are 544 described. 546 In order to handle this type of startup efficiently, decoding can 547 start provided that: 549 1. There are at least two consecutive frames available. 551 2. More than or equal to half the frames are available in the time 552 period from where decoding was planned to start and the most 553 forward received decoding. 555 After receiving a number of packets, in the worst case as many 556 packets as the interleaving pattern covers, the previously described 557 effects disappear and normal decoding is resumed. Similar issues 558 arise when a receiver leaves a session or has lost access to the 559 stream. If the receiver leaves the session, this would be a minor 560 issue since playout is normally stopped. The sender can avoid this 561 type of problem in many sessions by starting and ending interleaving 562 patterns correctly when risks of losses occur. One such example is a 563 key-change done for access control to encrypted streams. If only 564 some keys are provided to clients and there is a risk of they 565 receiving content for which they do not have the key, it is 566 recommended that interleaving patterns do not overlap key changes. 568 5.6.3. Decoding Validation 570 If the receiver finds a mismatch between the size of a received 571 payload and the size indicated by the ToC of the payload, the 572 receiver SHOULD discard the packet. This is recommended because 573 decoding a frame parsed from a payload based on erroneous ToC data 574 could severely degrade the audio quality. 576 6. Payload Examples 578 A few examples to highlight the payload format 580 6.1. 3 mono frames with 2 different bitrates 582 The first example is a payload consisting of 3 mono frames where the 583 2 first frames correspond to a bitrate of 32kbps (80byte/frame) and 584 the last is 48kbps (120byte/frame). 586 The first 32 bits are ToC fields. 587 Bit 0 is '1' as another ToC field follow. 588 Bits 1..5 is 01000 = 80bytes/frame 589 Bits 8..15 is 00000010 = 2 frame-blocks with 80bytes/frame 590 Bit 16 is '0', no more ToC follows 591 Bits 17..21 is 01100 = 120 bytes/frame 592 Bits 24..31 = 00000001 = 1 frame-block with 120bytes/frame 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 |1|0 1 0 0 0|0 0|0 0 0 0 0 0 1 0|0|0 1 1 0 0|0 0|0 0 0 0 0 0 0 1| 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |d(0) frame 1 | 600 . . 601 | d(639)| 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |d(0) frame 2 | 604 . . 605 | d(639)| 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 |d(0) frame 3 | 608 . . 609 | d(959)| 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 6.2. 2 stereo frame-blocks of the same bitrate 614 A payload consisting of 2 stereo frames corresponding to a bitrate of 615 32kbps (80byte/frame) per channel. The receiver calculates the 616 number of frames in the audio block by multiplying the value of the 617 channels parameter (2) with the #frames field value (2) to derive 618 that there are 4 audio frames in the payload. 620 The first 16 bits is the ToC field. 621 Bit 0 is '0' as no ToC field follow. 622 Bits 1..5 is 01000 = 80bytes/frame 623 Bits 8..15 is 00000010 = 2 frame-blocks with 80bytes/frame 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 |0|0 1 0 0 0|0 0|0 0 0 0 0 0 1 0| d(0) frame 1 left ch. | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 . . 631 | d(639)| d(0) frame 1 right ch. | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 . . 634 | d(639)| d(0) frame 2 left ch. | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 . . 637 | d(639)| d(0) frame 2 right ch. | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | d(639)| 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 6.3. 4 mono frames interleaved 644 A payload consisting of 4 stereo frames corresponding to a bitrate of 645 32kbps (80byte/frame) interleaved. A pattern of interleaving for 646 constant delay when aggregating 4 frames is the below one used in 647 this example. The actual packet illustrate 649 Packet n-3: 1, 6, 11, 16 650 Packet n-2: 5, 10, 15, 20 651 Packet n-1: 9, 14, 19, 24 652 Packet n: 13, 18, 23, 28 653 Packet n+1: 17, 22, 27, 32 654 Packet n+2: 21, 26, 31, 36 656 The first 16 bits is the ToC field. 657 Bit 0 is '0' as there are no ToC field following. 658 Bits 1..5 is 01000 = 80bytes/frame 659 Bits 8..15 is 00000100 = 4 frame-blocks with 80bytes/frame 660 0 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |0|0 1 0 0 0|0 0|0 0 0 0 0 1 0 0|0 0 0 0|0 1 0 0|0 1 0 0|0 1 0 0| 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | d(0) frame 13 | 666 . . 667 | d(639)| 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | d(0) frame 18 | 670 . . 671 | d(639)| 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | d(0) frame 23 | 674 . . 675 | d(639)| 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | d(0) frame 28 | 678 . . 679 | d(639)| 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 7. Payload Format Parameters 684 This RTP payload format is identified using the media type audio/g719 685 which is registered in accordance with [RFC4855] and using the 686 template of [RFC4288]. 688 7.1. Media Type Definition 690 The media type for the G.719 codec is allocated from the IETF tree 691 since G.719 is a has the potential to become a widely used audio 692 codec in general VoIP, teleconferencing and streaming applications. 693 This media type registration covers real-time transfer via RTP. 695 Note, any unspecified parameter MUST be ignored by the receiver to 696 ensure that additional parameters can be added in the future. 698 Type name: audio 700 Subtype name: g719 702 Required parameters: none 704 Optional parameters: 706 interleaving: Indicates that interleaved mode SHALL be used for the 707 payload. The parameter specifies the number of transport frame 708 slots required in a de-interleaving buffer (including the frame 709 that is ready to be consumed). Its value is equal to one plus the 710 maximum number of frames that precede any frame in transmission 711 order and follow the frame in RTP timestamp order. The value MUST 712 be greater than zero. If this parameter is not present, 713 interleaved mode SHALL NOT be used. 715 int-delay: The minimal media time delay in RTP timestamp ticks that 716 is needed in the de-interleaving buffer, i.e., the difference in 717 RTP timestamp ticks between the earliest and latest audio frame 718 present in the de-interleaving buffer. 720 max-red: The maximum duration in milliseconds that elapses between 721 the primary (first) transmission of a frame and any redundant 722 transmission that the sender will use. This parameter allows a 723 receiver to have a bounded delay when redundancy is used. Allowed 724 values are between 0 (no redundancy will be used) and 65535. If 725 the parameter is omitted, no limitation on the use of redundancy 726 is present. 728 channels: The number of audio channels. The possible values (1-6) 729 and their respective channel order is specified in Section 4.1 in 730 [RFC3551]. If omitted, it has the default value of 1. 732 CBR: Constant Bit Rate (CBR), indicates the exact codec-bitrate in 733 bits per second (not including the overhead from packetization, 734 RTP header or lower layers) that the codec MUST use. CBR is to be 735 used when dynamic rate cannot be supported (one case is e.g GW to 736 H.320). 738 ptime: see [RFC4566]. 740 maxptime: see [RFC4566]. 742 Encoding considerations: 744 This media type is framed and binary, see section 4.8 in RFC4288 745 [RFC4288]. 747 Security considerations: none 749 See Section 10 of RFCXXXX. 751 Interoperability considerations: 753 Published specification: 755 RFC XXXX 757 Applications that use this media type: 759 Real-time audio applications like voice over IP and 760 teleconference, and multi-media streaming. 762 Additional information: none 764 Person & email address to contact for further information: 766 Payload format: IngemarJohansson 767 769 Codec spec.: Anisse Taleb talebericssoncom> 771 Intended usage: COMMON 773 Restrictions on usage: 775 This media type depends on RTP framing, and hence is only defined 776 for transfer via RTP [RFC3550]. Transport within other framing 777 protocols is not defined at this time. 779 Author: 781 Ingemar Johansson 783 Magnus Westerlund 785 Change controller: 787 IETF Audio/Video Transport working group delegated from the IESG. 789 7.2. Mapping to SDP 791 The information carried in the media type specification has a 792 specific mapping to fields in the Session Description Protocol (SDP) 793 [RFC4566], which is commonly used to describe RTP sessions. When SDP 794 is used to specify sessions employing the G.719 codec, the mapping is 795 as follows: 797 o The media type ("audio") goes in SDP "m=" as the media name. 799 o The media subtype (payload format name) goes in SDP "a=rtpmap" as 800 the encoding name. The RTP clock rate in "a=rtpmap" MUST be 801 48000, and the encoding parameters (number of channels) MUST 802 either be explicitly set to N or omitted, implying a default value 803 of 1. The values of N that are allowed are specified in Section 804 4.1 in [RFC3551]. 806 o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and 807 "a=maxptime" attributes, respectively. 809 o Any remaining parameters go in the SDP "a=fmtp" attribute by 810 copying them directly from the media type parameter string as a 811 semicolon-separated list of parameter=value pairs. 813 7.2.1. Offer/Answer Considerations 815 The following considerations apply when using SDP Offer-Answer 816 procedures to negotiate the use of G.719 payload in RTP: 818 o Each combination of the RTP payload transport format configuration 819 parameters ( interleaving, and channels) is unique in its bit- 820 pattern and not compatible with any other combination. When 821 creating an offer in an application desiring to use the more 822 advanced features (interleaving, or more than one channel), the 823 offerer is RECOMMENDED to also offer a payload type containing 824 only the configuration with a single channel. If multiple 825 configurations are of interest to the application, they may all be 826 offered; however, care should be taken not to offer too many 827 payload types. An SDP answerer MUST include, in the SDP answer 828 for a payload type, the following parameters unmodified from the 829 SDP offer (unless it removes the payload type): "interleaving"; 830 and "channels". The SDP offerer and answerer MUST generate G.719 831 packets as described by these parameters. 833 o The "int-delay" parameter is declarative. For streams declared as 834 sendrecv or recvonly, the value indicates the maximum initial 835 delay the receiver will accept in the de-interleaving buffer. For 836 sendonly streams, the value is the amount of media time the sender 837 desires to use. The value SHOULD be copied into any response. 839 o In most cases, the parameters "maxptime" and "ptime" will not 840 affect interoperability; however, the setting of the parameters 841 can affect the performance of the application. The SDP offer- 842 answer handling of the "ptime" parameter is described in 843 [RFC3264]. The "maxptime" parameter MUST be handled in the same 844 way. 846 o The parameter "max-red" is a stream property parameter. For 847 sendonly or sendrecv unicast media streams, the parameter declares 848 the limitation on redundancy that the stream sender will use. For 849 recvonly streams, it indicates the desired value for the stream 850 sent to the receiver. The answerer MAY change the value, but is 851 RECOMMENDED to use the same limitation as the offer declares. In 852 the case of multicast, the offerer MAY declare a limitation; this 853 SHALL be answered using the same value. A media sender using this 854 payload format is RECOMMENDED to always include the "max-red" 855 parameter. This information is likely to simplify the media 856 stream handling in the receiver. This is especially true if no 857 redundancy will be used, in which case "max-red" is set to 0. 859 o Any unknown parameter in an offer SHALL be removed in the answer. 861 o The b= SDP parameter SHOULD be used to negotiate the maximum 862 bandwidth to be used for the audio stream. The offerer may offer 863 a maximum rate and the answer may contain a lower rate. If no b= 864 parameter is present in the offer or answer it implies a rate up 865 to 128kbps 867 o The parameter "CBR" is a receiver capability. For recvonly and 868 sendrecv streams, it indicates the desired constant bit rate that 869 the receiver wants to accept. A sender MUST be able to send 870 constant bit rate stream since it is a subset of the variable bit 871 rate capability. If the offer includes this parameter the 872 answerer SHOULD send at the constant bit rate if it is within the 873 allowed call bit rate (b= parameter). The Answerer MAY change the 874 value of CBR to a lower rate but it is RECOMMENDED to use the same 875 rate. The answerer MAY add this parameter if it wants to receive 876 at a constant bit rate even if the offer did not include the CBR 877 parameter. In this case, the offerer SHOULD send at the constant 878 bit rate but SHOULD be able to accept media at variable bit rate. 880 7.2.2. Declarative SDP Considerations 882 In declarative usage, like SDP in RTSP [RFC2326] or SAP [RFC2974], 883 the parameters SHALL be interpreted as follows: 885 o The payload format configuration parameters (interleaving, and 886 channels) are all declarative, and a participant MUST use the 887 configuration(s) that is provided for the session. More than one 888 configuration may be provided if necessary by declaring multiple 889 RTP payload types; however, the number of types should be kept 890 small. 892 o Any "maxptime" and "ptime" values should be selected with care to 893 ensure that the session's participants can achieve reasonable 894 performance. 896 8. IANA Considerations 898 One media type (audio/g719) has been defined and needs registration 899 in the media types registry; see Section 7.1. 901 9. Congestion Control 903 The general congestion control considerations for transporting RTP 904 data apply; see RTP [RFC3550] and any applicable RTP profile like AVP 905 [RFC3551]. However, the multi-rate capability of G.719 audio coding 906 provides a mechanism that may help to control congestion, since the 907 bandwidth demand can be adjusted (within the limits of the codec) by 908 selecting a different encoding bit-rate. 910 The number of frames encapsulated in each RTP payload highly 911 influences the overall bandwidth of the RTP stream due to header 912 overhead constraints. Packetizing more frames in each RTP payload 913 can reduce the number of packets sent and hence the header overhead, 914 at the expense of increased delay and reduced error robustness. If 915 forward error correction (FEC) is used, the amount of FEC-induced 916 redundancy needs to be regulated such that the use of FEC itself does 917 not cause a congestion problem. 919 10. Security Considerations 921 RTP packets using the payload format defined in this specification 922 are subject to the general security considerations discussed in RTP 923 [RFC3550] and any applicable profile such as AVP [RFC3551] or SAVP 924 [RFC3711]. As this format transports encoded audio, the main 925 security issues include confidentiality, integrity protection, and 926 data origin authentication of the audio itself. The payload format 927 itself does not have any built-in security mechanisms. Any suitable 928 external mechanisms, such as SRTP [RFC3711], MAY be used. 930 This payload format and the G.719 decoder do not exhibit any 931 significant non-uniformity in the receiver-side computational 932 complexity for packet processing, and thus are unlikely to pose a 933 denial-of-service threat due to the receipt of pathological data. 935 10.1. Confidentiality 937 In order to ensure confidentiality of the encoded audio, all audio 938 data bits MUST be encrypted. There is less need to encrypt the 939 payload header or the table of contents since they only carry 940 information about the frame type. This information could also be 941 useful to a third party, for example, for quality monitoring. 943 The use of interleaving in conjunction with encryption can have a 944 negative impact on confidentiality, for a short period of time. 945 Consider the following packets (in brackets) containing frame numbers 946 as indicated: {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (a popular 947 continuous diagonal interleaving pattern). The originator wishes to 948 deny some participants the ability to hear material starting at time 949 16. Simply changing the key on the packet with the timestamp at or 950 after 16, and denying that new key to those participants, does not 951 achieve this; frames 17, 18, and 21 have been supplied in prior 952 packets under the prior key, and error concealment may make the audio 953 intelligible at least as far as frame 18 or 19, and possibly further. 955 10.2. Authentication and Integrity 957 To authenticate the sender of the audio-stream, an external mechanism 958 MUST be used. It is RECOMMENDED that such a mechanism protects both 959 the complete RTP header and the payload (audio and data bits). Data 960 tampering by a man-in-the-middle attacker could replace audio content 961 and also result in erroneous depacketization/decoding that could 962 lower the audio quality. 964 11. Acknowledgements 966 The authors would like to thank Roni Even and Anisse Taleb for their 967 help with this draft. 969 12. References 971 12.1. Informative References 973 [I-D.ietf-tsvwg-udp-guidelines] 974 Eggert, L. and G. Fairhurst, "Guidelines for Application 975 Designers on Using Unicast UDP", 976 draft-ietf-tsvwg-udp-guidelines-08 (work in progress), 977 June 2008. 979 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 980 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 981 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 982 September 1997. 984 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 985 Streaming Protocol (RTSP)", RFC 2326, April 1998. 987 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 988 Announcement Protocol", RFC 2974, October 2000. 990 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 991 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 992 RFC 3711, March 2004. 994 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 995 Registration Procedures", BCP 13, RFC 4288, December 2005. 997 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 998 Formats", RFC 4855, February 2007. 1000 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1001 Correction", RFC 5109, December 2007. 1003 12.2. Normative References 1005 [ITU-T-G719] 1006 ITU-T, "Specification : ITU-T G.719 extension for 20 kHz 1007 fullband audio", April 2008. 1009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1010 Requirement Levels", BCP 14, RFC 2119, March 1997. 1012 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1013 with Session Description Protocol (SDP)", RFC 3264, 1014 June 2002. 1016 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1017 Jacobson, "RTP: A Transport Protocol for Real-Time 1018 Applications", STD 64, RFC 3550, July 2003. 1020 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1021 Video Conferences with Minimal Control", STD 65, RFC 3551, 1022 July 2003. 1024 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1025 Description Protocol", RFC 4566, July 2006. 1027 Authors' Addresses 1029 Magnus Westerlund 1030 Ericsson AB 1031 Torshamnsgatan 21-23 1032 SE-164 83 Stockholm 1033 SWEDEN 1035 Phone: +46 8 7190000 1036 Email: magnus.westerlund@ericsson.com 1038 Ingemar Johansson 1039 Ericsson AB 1040 Laboratoriegrand 11 1041 SE-971 28 Lulea 1042 SWEDEN 1044 Phone: +46 73 0783289 1045 Email: ingemar.s.johansson@ericsson.com 1047 Full Copyright Statement 1049 Copyright (C) The IETF Trust (2008). 1051 This document is subject to the rights, licenses and restrictions 1052 contained in BCP 78, and except as set forth therein, the authors 1053 retain all their rights. 1055 This document and the information contained herein are provided on an 1056 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1057 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1058 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1059 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1060 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1061 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1063 Intellectual Property 1065 The IETF takes no position regarding the validity or scope of any 1066 Intellectual Property Rights or other rights that might be claimed to 1067 pertain to the implementation or use of the technology described in 1068 this document or the extent to which any license under such rights 1069 might or might not be available; nor does it represent that it has 1070 made any independent effort to identify any such rights. Information 1071 on the procedures with respect to rights in RFC documents can be 1072 found in BCP 78 and BCP 79. 1074 Copies of IPR disclosures made to the IETF Secretariat and any 1075 assurances of licenses to be made available, or the result of an 1076 attempt made to obtain a general license or permission for the use of 1077 such proprietary rights by implementers or users of this 1078 specification can be obtained from the IETF on-line IPR repository at 1079 http://www.ietf.org/ipr. 1081 The IETF invites any interested party to bring to its attention any 1082 copyrights, patents or patent applications, or other proprietary 1083 rights that may cover technology that may be required to implement 1084 this standard. Please address the information to the IETF at 1085 ietf-ipr@ietf.org.