idnits 2.17.1 draft-ietf-avt-tfrc-profile-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 529. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 71 has weird spacing: '...extends the R...' -- 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 (6 September 2006) is 6413 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'AVP' is defined on line 477, but no explicit reference was found in the text == Unused Reference: '2434' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'SDP' is defined on line 498, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AVPF' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3448 (ref. 'TFRC') (Obsoleted by RFC 5348) ** Obsolete normative reference: RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force AVT WG 2 INTERNET-DRAFT Ladan Gharai 3 draft-ietf-avt-tfrc-profile-06.txt USC/ISI 4 6 September 2006 5 Expires: March 2007 7 RTP Profile for TCP Friendly Rate Control 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2006). 35 Abstract 37 This memo specifies a profile called "RTP/AVPFCC" for the use of the 38 real-time transport protocol (RTP) and its associated control 39 protocol, RTCP, with TCP Friendly Rate Control (TFRC). This profile 40 extends the RTP/AVPF profile with RTP data header additions and new 41 AVPF feedback packets, in order to support TFRCs integration with 42 RTP. TFRC is an equation based congestion control scheme for unicast 43 flows operating in a best effort Internet environment. This profile 44 provides RTP flows with the mechanism to use congestion control in 45 best effort IP networks. 47 1. Introduction 49 [Note to RFC Editor: All references to RFC XXXX are to be replaced 50 with the RFC number of this memo, when published] 52 This memo defines a profile called "RTP/AVPFCC" for the use of the 53 real-time transport protocol (RTP) [RTP] and its associated control 54 protocol, RTCP, with the TCP Friendly Rate Control (TFRC) [TFRC]. 55 RTP/AVPFCC extends the RTP profile for RTCP-based feedback (RTP/AVPF) 56 to provide support for TFRC. 58 TFRC is an equation based congestion control scheme for unicast flows 59 operating in a best effort Internet environment and competing with 60 TCP traffic. TFRC computes a TCP-friendly data rate based on current 61 network conditions, as represented by the latest round trip time and 62 packet loss calculations. The complete TFRC mechanism is described in 63 detail in [TFRC]. 65 To calculate a TCP-friendly data rate and keep track of round trip 66 times and packet losses, TFRC senders and receivers rely on 67 exchanging specific information between each other, i.e: the sender 68 provides the receiver with the latest updates to round trip time 69 calculations, while the receiver provides feedback needed to compute 70 round trip times and on packet losses. The RTP/AVPFCC profile, 71 extends the RTP/AVPF profile with RTP data header additions and new 72 AVPF feedback packets to support the TFRC feedback and information 73 exchange requirements. 75 2. Terminology 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 [2119]. 81 3. Relation to the Datagram Congestion Control Protocol 83 The TFRC congestion control mechanism is also supported by the 84 Datagram Congestion Control Protocol (DCCP). In this section we 85 detail the pros and cons of using TFRC with RTP versus DCCP. 87 DCCP is a minimal general purpose transport-layer protocol with 88 unreliable yet congestion controlled packet delivery semantics and 89 reliable connection setup and teardown. DCCP currently supports both 90 TFRC and TCP-like congestion control, and the protocol is structured 91 to support new congestion control mechanisms defined in the future. 92 In addition DCCP supports a host of other features, such as: use of 93 Explicit Congestion Notification (ECN) and the ECN Nonce, reliable 94 option negotiation and Path Maximum Transfer Unit (PMTU). Naturally 95 an application using RTP/DCCP as its transport protocol will benefit 96 from the protocol features supported by DCCP. 98 However there are a number of benefits to be gained by the 99 development and standardization of the RTP/AVPFCC profile: 101 o Media applications lacking congestion control can incorporate 102 congestion controlled transport without delay by using the 103 RTP/AVPFCC profile. The DCCP protocol is currently under 104 development and widespread deployment is not yet in place. 106 o Use of the RTP/AVPFCC profile is not contingent on any OS level 107 changes and can be quickly deployed, as the AVPFCC profile is 108 implemented at the application layer. 110 o AVPFCC/RTP/UDP flows face the same restrictions in firewall 111 traversal as do UDP flows and do not require NATs and firewall 112 modifications. DCCP flows, on the other hand, do require NAT and 113 firewall modifications, however once these modifications are in 114 place, they can result in easier NAT and firewall traversal for 115 RTP/DCCP flows in the future. 117 o Use of the RTP/AVPFCC profile with various media applications 118 will give researchers, implementors and developers a better 119 understanding of the intricate relationship between media quality 120 and equation based congestion control. Hopefully this experience 121 with congestion control and TFRC will ease the migration of media 122 applications to DCCP once DCCP is deployed. 124 Overall, the RTP/AVPFCC profile provides an immediate means for 125 congestion control in media streams, in the time being until DCCP is 126 deployed. 128 Additionally, there are also a number of technical differences as to 129 how (and which) congestion control information is exchanged between 130 DCCP with CCID3 and the RTP/AVPFCC profile: 132 o A RTP/AVPFCC sender transmits a send timestamp to the RTP/AVPFCC 133 receiver with every data packet. In addition to congestion 134 control the send timestamp can be used by the receiver for 135 jitter calculations. 137 In contrast DCCP with CCID3 transmits a quad round trip 138 counter to the receiver. 140 o A RTP/AVPFCC receiver only provides the RTP/AVPFCC sender 141 with the loss event rate as computed by the receiver. 143 In contrast DCCP with CCID3, provides 2 other options for the 144 transport of loss event rate. A sender may choose to receive 145 loss intervals or an Ack Vector. These two options provide the 146 sender with the necessary information to compute the loss event 147 rate. 149 o Sequence number: DCCP supports a 48 bit and a 24 bit sequence 150 number, whereas RTP only supports a 16 bit sequence number. While 151 this makes RTP susceptible to data injection attacks, it can be 152 avoided by using the SRTP [SRTP] profile in conjunction with the 153 AVPFCC profile. 155 4. RTP and RTCP Packet Forms and Protocol Behavior 157 The section "RTP Profiles and Payload Format Specifications" of RFC 158 3550 enumerates a number of items that can be specified or modified 159 in a profile. This section addresses each of these items and states 160 which item is modified by the RTP/AVPFCC profile: 162 RTP data header: The standard format of the fixed RTP data 163 header has been modified (see Section 6). 165 Payload types: The payload type in the RTP data header is 166 reduced to 6 bits, therefore payload types are restricted to 167 values in the range of 0 to 63. 169 RTP data header additions: Two 32 bit fixed fields, send 170 timestamp and round trip time (RTT), are added to the RTP 171 data header. The send time stamp is always present and 172 the RTT field is present if the R bit is set. 174 RTP data header extensions: No RTP header extensions are 175 defined, but applications operating under this profile 176 MAY use such extensions. Thus, applications SHOULD NOT 177 assume that the RTP header X bit is always zero and SHOULD 178 be prepared to ignore the header extension. If a header 179 extension is defined in the future, that definition MUST 180 specify the contents of the first 16 bits in such a way 181 that multiple different extensions can be identified. 183 RTCP packet types: Additional RTCP packet types are defined 184 by this profile per the RTP/AVPF profile [AVPF]. 186 RTCP report interval: This profile is restricted to unicast 187 flows, therefore at all times there is only one active sender 188 and one receiver. Sessions operating under this profile MAY 189 specify a separate parameter for the RTCP traffic bandwidth 190 rather than using the default fraction of the session 191 bandwidth. In particular this may be necessary for data 192 flows were the the RTCP recommended reduced minimum interval 193 is still greater than the RTT. 195 SR/RR extension: The SR/RR extensions are defined per RFC 3550. 196 No changes are specified. 198 SDES use: Applications MAY use any of the SDES items described 199 in the RTP specification. 201 Security: This profile is subject to the security considerations 202 discussed in the TFRC and RTP specifications [TFRC][RTP]. This 203 profile does not specify any additional security services. 205 String-to-key mapping: No mapping is specified by this profile. 207 Congestion: This profile specifies how to use RTP/RTCP with TFRC 208 congestion control. 210 Underlying protocol: The profile specifies the use of RTP over 211 unicast UDP flows only, multicast MUST NOT be used. 213 Transport mapping: The standard mapping of RTP and RTCP to 214 transport-level addresses is used. 216 Encapsulation: This profile is defined for encapsulation 217 over UDP only. 219 5. The TFRC Information Exchange Loop 221 TFRC depends on the exchange of congestion control information 222 between a sender and receiver. In this section we reiterate which 223 items are exchanged between a TFRC sender and receiver as discussed 224 in [TFRC]. We note how the RTP/AVPFCC profile accommodates these 225 exchanges. 227 5.1. Data Packets 229 As stated in [TFRC] a TFRC sender transmits the following information 230 in each data packet to the receiver: 232 o A sequence number, incremented by one for each data packet 233 transmitted. 235 o A timestamp indicating the packet send time and the sender's 236 current estimate of the round-trip time, RTT. This information 237 is then used by the receiver to compute the TFRC loss intervals. 238 - or - 239 A course-grained timestamp incrementing every quarter of a 240 round trip time, which is then used to determine the TFRC loss 241 intervals. 243 The standard RTP sequence number suffices for TFRCs functionality. 244 For the computation of the loss intervals the RTP/AVPFCC profile 245 extends the RTP data header as follows: a 32 bit field to transmit a 246 send timestamp and an additional 32 bit field, present only when the 247 RTT changes, to transmit the RTT. The presence of the RTT is 248 indicated by the R bit in the RTP header (see Section 6). 250 5.2. Feedback Packets 252 As stated in [TFRC] a TFRC receiver provides the following feedback 253 to the sender at least once per RTT or per data packet received 254 (which ever time interval is larger): 256 o The send timestamp of the last data packet received, t_i. 258 o The amount of time elapsed between the receipt of the last 259 data packet at the receiver, and the generation of this feedback 260 report, t_delay. This is used by the sender for RTT computations. 262 o The rate at which the receiver estimates that data was received 263 since the last feedback report was sent, x_recv. 265 o The receiver's current estimate of the loss event rate, p, a real 266 value between 0 and 1.0. 268 To accommodate the feedback of these values the RTP/AVPFCC profile 269 defines a new AVPF transport layer feedback message, as detailed in 270 Section 7. 272 6. RTP Data Header Additions 274 The RTP/AVPFCC profile makes the following changes to the RTP header 275 (other fields of the payload header are defined as in RFC 3550 276 [RTP]): 278 o the profile uses a 6 bit payload type (PT) field, 279 o defines a 1 bit R field in the second octet, and 280 o defines two additional 32 bit fixed fields: 281 1. the packets send timestamp, 282 2. the round trip time (RTT) as measured by the sender. This 283 field is present if the R bit is set (see Figures 1 and 2). 285 The additional fields of the RTP header are defined and used as 286 follows: 288 Round trip time indicator (R): 1 bit 289 This field indicates the existence of the additional RTT field. If 290 the R bit is set, the RTP payload header includes a 32 bit field 291 representing the current round trip time (Figures 1 and 2). 293 Payload type (PT): 6 bits 294 The RTP/AVPFCC profile uses a 6 bit field for the payload type 295 (instead of a 7 bit field). 297 Send timestamp: 32 bits 298 The timestamp indicating when the packet is sent. This timestamp 299 is measured in microseconds and is used for round trip time 300 calculations. At microsecond granularity the send timestamp 301 wraps around in approximately 71 minutes. 303 Round trip time (RTT): 32 bits 304 The round trip time as measured by the RTP/AVPFCC sender in 305 microseconds. This field is only present if the R bit is set 306 (Figure 2). 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 |V=2|P|X| CC |M|R| PT | sequence number | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | timestamp | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | synchronization source (SSRC) identifier | 316 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 317 | send timestamp | 318 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 319 | contributing source (CSRC) identifiers | 320 | .... | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 1: RTP header and additions with R=0, no RTT included. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 |V=2|P|X| CC |M|R| PT | sequence number | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | timestamp | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | synchronization source (SSRC) identifier | 332 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 333 | send timestamp | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | RTT | 336 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 337 | contributing source (CSRC) identifiers | 338 | .... | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 2: RTP header and additions with R=1, RTT included. 342 7. TFRC-FB: A New AVPF Transport Layer Feedback Message 344 To support feedback to the RTP/AVPFCC receivers a new transport layer 345 AVPF feedback message is defined: TFRC-FB. This message is depicted 346 in Figure 3. It is defined according to [AVPF] and includes the 347 following four fields: 349 Timestamp (t_i): 32 bits 350 The send timestamp of the last data packet received by the 351 RTP/AVPFCC receiver, t_i, in microseconds. 353 Delay (t_delay): 32 bits 354 The amount of time elapsed between the receipt of the last data 355 packet at the RTP/AVPFCC receiver, and the generation of this 356 feedback report in microseconds. This is used by the TFRC RTP 357 sender for RTT computations. 359 Data rate (x_recv): 32 bits 360 The rate at which the receiver estimates that data was received 361 since the last feedback report was sent in bytes per second. 363 Loss event rate (p): 32 bits 364 The receiver's current estimate of the loss event rate, p, 365 expressed as a fixed point number with the binary point at the 366 left edge of the field. (That is equivalent to taking the integer 367 part after multiplying the loss event rate by 2^32.) 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |V=2|P| FMT=2 | PT=RTPFB | length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | SSRC of packet sender | 375 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 376 | SSRC (SSRC of first source) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | t_i | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | t_delay | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | data rate at the receiver (x_recv) | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | loss event rate (p) | 385 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 386 Figure 3 388 8. RTCP Transmission Intervals, TFRC and the AVPF Profile 390 The AVPFCC profile recommends setting RTCP transmission intervals 391 according to the requirements of the TFRC algorithm. TFRC requires a 392 receiver to generate a feedback packet at least once per RTT or per 393 packet received (based on the larger time interval). These 394 requirements are to ensure timely reaction to congestion. 396 Other requirements that AVPFCC must contend with are AVPF feedback 397 rules and AVP RTCP bandwidth constraints. In general the AVPFCC 398 profile complies with the rules of AVPF for sending RTCP feedback 399 packets with the following two exceptions: 401 o allow_early is set to "true" at all times. Essentially, this means 402 that a receiver can always generate an early feedback packet, and 403 does not need to alternate between early and regular RTCP packets 404 (see RFC 4585, Section 3.4,k). 406 o T_rr_interval must not be set to a value larger than the current 407 round trip time, as this would prevent generating feedback packets 408 at least once per RTT (see RFC 4585, Section 3.4,m). 410 The TFRC requirements of receiving feedback once per RTT can at times 411 conflict with the AVP RTCP bandwidth constraints, particularly at 412 small RTTs of 20ms or less. Assuming only one TFRC-FB report per 413 RTCP compound packet, Table 1 lists the RTCP bandwidths at RTTs of 2, 414 5, 10 and 20 ms and the minimum corresponding RTP data rates, where 415 RTCP(X) <= (0.05)*RTP(X) is true. For example, according to Table 416 1, an AVPFCC flow of less than 3.2 Mbps and a RTT of 5 ms, can not 417 comply with the 5% RTCP bandwidth constraints (Table 1 assumes each 418 RTCP packet is 100 bytes). 420 The correct operation of TFRC at RTTs of 20ms and less, at data rates 421 less than those list in Table 1 is an open issue and is TBD. 423 RTT RTCP(X) RTP(X) 424 +------------------------------+ 425 | 20 ms | 40 kbps | 0.8 Mbps | 426 | 10 ms | 80 kbps | 1.6 Mbps | 427 | 5 ms | 160 kbps | 3.2 Mbps | 428 | 2 ms | 400 kbps | 8.0 Mbps | 429 +------------------------------+ 430 Table 1 432 9. SDP Definitions 434 Applications using RTP integrated with TFRC and sending or receiving 435 packets as defined in this document MUST use "AVPFCC" as part of 436 their session description. The session will inherit the properties of 437 the AVPF profile. 439 10. IANA Considerations 441 In this section we detail IANA registry values that need to be 442 registered. In particular the new RTP/AVPF feedback packet, TFRC-FB. 443 For the RTPFB range of packets, the following format (FMT) value 444 needs to be registered: 446 Value name: TFRC-FB 447 Long name: TFRC feedback 448 Value: 2 449 Reference: RFC XXXX 451 11. Security Considerations 453 TBC 455 12. Acknowledgments 457 This memo is based upon work supported by the U.S. National Science 458 Foundation (NSF) under Grant No. 0334182. Any opinions, findings and 459 conclusions or recommendations expressed in this material are those 460 of the authors and do not necessarily reflect the views of NSF. 462 13. Author's Address 464 Ladan Gharai 465 USC Information Sciences Institute 466 3811 N. Fairfax Drive, #200 467 Arlington, VA 22203 468 USA 470 Normative References 472 [RTP] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, 473 "RTP: A Transport Protocol for Real-Time Applications", 474 Internet Engineering Task Force, RFC 3550 (STD0064), July 475 2003. 477 [AVP] H. Schulzrinne and S. Casner, "RTP Profile for Audio and 478 Video Conferences with Minimal Control," RFC 3551 (STD0065), 479 July 2003. 481 [AVPF] J. Ott, S. Wenger, A. Sato, C. Burmeister and J. Ray, 482 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 484 RFC 4585, July 2006. 486 [2119] S. Bradner, "Key words for use in RFCs to Indicate 487 Requirement Levels", Internet Engineering Task Force, 488 RFC 2119, March 1997. 490 [2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 491 Considerations Section in RFCs", Internet Engineering Task 492 Force, RFC 2434, October 1998. 494 [TFRC] M. Handley, S. Floyed, J. Padhye and J. widmer, 495 "TCP Friendly Rate Control (TRFC): Protocol Specification", 496 Internet Engineering Task Force, RFC 3448, January 2003. 498 [SDP] M. Handley and V. Jacobson, "SDP: Session Description 499 Protocol", RFC 2327, April 1998. 501 [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 502 "The Secure Real-time Transport Protocol", RFC 3711, March 503 2004. 505 Informative References 507 14. IPR Notice 509 The IETF takes no position regarding the validity or scope of any 510 Intellectual Property Rights or other rights that might be claimed to 511 pertain to the implementation or use of the technology described in 512 this document or the extent to which any license under such rights 513 might or might not be available; nor does it represent that it has 514 made any independent effort to identify any such rights. Information 515 on the procedures with respect to rights in RFC documents can be 516 found in BCP 78 and BCP 79. 518 Copies of IPR disclosures made to the IETF Secretariat and any 519 assurances of licenses to be made available, or the result of an 520 attempt made to obtain a general license or permission for the use of 521 such proprietary rights by implementers or users of this 522 specification can be obtained from the IETF on-line IPR repository at 523 http://www.ietf.org/ipr. 525 The IETF invites any interested party to bring to its attention any 526 copyrights, patents or patent applications, or other proprietary 527 rights that may cover technology that may be required to implement 528 this standard. Please address the information to the IETF at ietf- 529 ipr@ietf.org. 531 15. Full Copyright Statement 533 Copyright (C) The Internet Society (2006). This document is subject 534 to the rights, licenses and restrictions contained in BCP 78, and 535 except as set forth therein, the authors retain all their rights. 537 This document and the information contained herein are provided on an 538 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 539 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 540 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 541 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 542 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 543 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.