idnits 2.17.1 draft-ietf-avt-tfrc-profile-02.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 3667, Section 5.1 on line 14. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 513), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There are 51 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 51 has weird spacing: '...defines a pro...' == Line 78 has weird spacing: '...ions to the r...' == Line 419 has weird spacing: '... mainly a que...' == Line 523 has weird spacing: '...for the purpo...' -- 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 (17 August 2004) is 7186 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: '2434' is defined on line 474, but no explicit reference was found in the text ** 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: 13 errors (**), 0 flaws (~~), 7 warnings (==), 3 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-02.txt USC/ISI 4 17 August 2004 5 Expires: February 2005 7 RTP Profile for TCP Friendly Rate Control 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This memo specifies a profile called "RTP/AVPCC" for the use of the 39 real-time transport protocol (RTP) and its associated control 40 protocol, RTCP, with the TCP Friendly Rate Control (TFRC). TFRC is 41 an equation based congestion control scheme for unicast flows 42 operating in a best effort Internet environment. This profile 43 provides RTP flows with the mechanism to use congestion control in 44 best effort IP networks. 46 1. Introduction 48 [Note to RFC Editor: All references to RFC XXXX are to be replaced 49 with the RFC number of this memo, when published] 51 This memo defines a profile called "RTP/AVPCC" for the use of the 52 real-time transport protocol (RTP) [RTP] and its associated control 53 protocol, RTCP, with the TCP Friendly Rate Control (TFRC) [TFRC]. 54 TFRC is an equation based congestion control scheme for unicast flows 55 operating in a best effort Internet environment and competing with 56 TCP traffic. 58 Due to a number of inherent TFRC characteristics, the RTP/AVPCC 59 profile differs from other RTP profiles [AVP] in the following ways: 61 o TFRC is a unicast congestion control scheme, therefore by 62 extension the RTP/AVPCC profile can only be used by unicast RTP 63 flows. 65 o A TFRC sender relies on receiving feedback from the receiver 66 either once per round-trip time (RTT) or per data packet. For 67 certain flows (depending on RTTs and data rates) these TFRC 68 requirements can result in control traffic that exceeds RFC 3550's 69 bandwidth and/or timing recommendations for control traffic. The 70 RTP/AVPCC profile recommends modifications to these 71 recommendations in order to satisfy TFRCs timing needs for control 72 traffic in a safe manner. 74 This memo primarily addresses the means of supporting TFRC's 75 exchange of congestion control information between senders and 76 receivers via the following modifications to RTP and RTCP: (1) RTP 77 data header additions; (2) extensions to the RTCP Receiver Reports; 78 and (3) modifications to the recommended RTCP timing intervals. For 79 details on TFRC congestion control readers are referred to [TFRC]. 81 The current TFRC standard, RFC3448, only targets applications with 82 fixed packet size. TFRC-PS is a variant of TFRC for applications with 83 varying packet sizes. The RTP/AVPCC profile is applicable to both 84 congestion control schemes. 86 2. Relation to the Datagram Congestion Control Protocol 88 The Datagram Congestion Control Protocol (DCCP) is a minimal general 89 purpose transport-layer protocol with unreliable yet congestion- 90 controlled packet delivery semantics and reliable connection setup 91 and teardown. DCCP currently supports both TFRC and TCP-like 92 congestion control. In addition DCCP supports a host of other 93 features, such as: use of Explicit Congestion Notification (ECN) and 94 the ECN Nonce, reliable option negotiation and Path Maximum Transfer 95 Unit (PMTU). Naturally an application using RTP/DCCP as its 96 transport protocol will benefit from the protocol features supported 97 by DCCP. 99 In contrast the RTP Profile for TFRC only provides RTP applications a 100 standardized means for using the TFRC congestion control scheme, 101 without any of the protocol features of DCCP. However there are a 102 number of benefits to be gained by the development and 103 standardization of a RTP Profile for TFRC: 105 o Media applications lacking congestion control can incorporate 106 congestion controlled transport without delay by using the 107 RTP/AVPCC profile. The DCCP protocol is currently under 108 development and widespread deployment is not yet in place. 110 o Use of the RTP/AVPCC profile is not contingent on any OS level 111 changes and can be quickly deployed, as the AVPCC profile is 112 implemented at the application layer. 114 o AVPCC/RTP/UDP flows face the same restrictions in firewall 115 traversal as do UDP flows and do not require NATs and firewall 116 modifications. DCCP flows, on the other hand, do require NAT 117 and firewall modifications, however once these modifications 118 are in place, they can result in easier NAT and firewall 119 traversal for RTP/DCCP flows in the future. 121 o Use of the RTP/AVPCC profile with various media applications will 122 give researchers, implementors and developers a better 123 understanding of the intricate relationship between media 124 quality and equation based congestion control. Hopefully this 125 experience with congestion control and TFRC will ease the 126 migration of media applications to DCCP once DCCP is deployed. 128 Overall, the RTP/AVPCC profile provides an immediate means for 129 congestion control in media streams, in the time being until DCCP is 130 deployed. 132 Additionally, there are also a number of differences in the exchange 133 of congestion control information between DCCP with CCID3 and the 134 RTP/AVPCC profile: 136 o A RTP/AVPCC sender transmits the round trip time and 137 the send timestamp to the RTP/AVPCC receiver. In addition 138 to congestion control the send timestamp can be used by the 139 receiver for jitter calculations. 141 In contrast DCCP with CCID3 transmits a quad round trip 142 counter to the receiver. 144 o A RTP/AVPCC receiver only provides the RTP/AVPCC sender 145 with the loss event rate as computed by the receiver. 147 In contrast DCCP with CCID3, provides 2 other options for the 148 transport of loss event rate. A sender may choose to receive 149 loss intervals or an Ack Vector. These two options provide the 150 sender with the necessary information to compute the loss event 151 rate. 153 o Sequence number: DCCP supports a 48 bit and a 24 bit sequence 154 number. RTP supports a 16 bit sequence number. 156 3. Conventions Used in this Document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [2119]. 162 4. RTP and RTCP Packet Forms and Protocol Behavior 164 The section "RTP Profiles and Payload Format Specifications" of RFC 165 3550 enumerates a number of items that can be specified or modified 166 in a profile. This section addresses each of these items and states 167 which item is modified by the RTP/AVPCC profile: 169 RTP data header: The standard format of the fixed RTP data 170 header is used (one marker bit). 172 Payload types: This profile does not define new payload types, 173 and has no payload type restrictions. 175 RTP data header additions: A 16 bit fixed field is added to 176 the RTP data header for the transport of the quad RTT 177 counter to the TFRC receiver. 179 RTP data header extensions: No RTP header extensions are 180 defined, but applications operating under this profile 181 MAY use such extensions. Thus, applications SHOULD NOT 182 assume that the RTP header X bit is always zero and SHOULD 183 be prepared to ignore the header extension. If a header 184 extension is defined in the future, that definition MUST 185 specify the contents of the first 16 bits in such a way 186 that multiple different extensions can be identified. 188 RTCP packet types: No additional RTCP packet types are defined 189 by this profile specification. 191 RTCP report interval: This profile is restricted to unicast 192 flows, therefore at all times there is only one active sender 193 and one receiver. Sessions operating under this profile MAY 194 specify a separate parameter for the RTCP traffic bandwidth 195 rather than using the default fraction of the session 196 bandwidth. In particular this may be necessary for data 197 flows were the the RTCP recommended reduced minimum interval 198 is still greater than the RTT. 200 SR/RR extension: A 16 octet RR extension is defined for the RTCP 201 RR packet. 203 SDES use: Applications MAY use any of the SDES items described 204 in the RTP specification. 206 Security: See Section 9. 208 String-to-key mapping: No mapping is specified by this profile. 210 Congestion: This profile specifies how to use RTP/RTCP with TFRC 211 congestion control. 213 Underlying protocol: The profile specifies the use of RTP over 214 unicast UDP flows only, multicast MUST NOT be used. 216 Transport mapping: The standard mapping of RTP and RTCP to 217 transport-level addresses is used. 219 Encapsulation: This profile is defined for encapsulation 220 over UDP only. 222 5. The TFRC Feedback Loop 224 TFRC depends on the exchange of congestion control information 225 between a sender and receiver. In this section we reiterate which 226 items are exchanged between a TFRC sender and receiver as discussed 227 in [TFRC]. We note how the RTP/AVPCC profile accommodates these 228 exchanges. 230 5.1. Data Packets 232 As stated in [TFRC] a TFRC sender transmits the following information 233 in each data packet to the receiver: 235 o A sequence number, incremented by one for each data packet 236 transmitted. 238 o A timestamp indicating the packet send time and the sender's 239 current estimate of the round-trip time, RTT. This information 240 is then used by the receiver to compute the TFRC loss intervals. 241 - or - 242 A course-grained timestamp incrementing every quarter of a 243 round trip time, which is then used to determine the TFRC loss 244 intervals. 246 The standard RTP sequence number suffices for TFRCs functionality. 247 For the computation of the loss intervals the RTP/AVPCC profile 248 extends the RTP data header as follows: a 32 bit field to transmit a 249 send timestamp and an additional 32 bit field, present only when the 250 RTT changes, to transmit the RTT. The presence of the RTT is 251 indicated by the R bit in the RTP header (see Section 6). 253 5.2. Feedback Packets 255 As stated in [TFRC] a TFRC receiver provides the following feedback 256 to the sender at least once per RTT or per data packet received 257 (which ever time interval is larger): 259 o The timestamp of the last data packet received, t_i. 261 o The amount of time elapsed between the receipt of the last 262 data packet at the receiver, and the generation of this feedback 263 report, t_delay. This is used by the sender for RTT computations 264 (see Section 9). 266 o The rate at which the receiver estimates that data was received 267 since the last feedback report was sent, x_recv 269 o The receiver's current estimate of the loss event rate, p. 271 To accommodate the feedback of these values the RTP/AVPCC profile 272 defines a 16 octet extension to the RTCP Receiver Reports (see 273 Section 7). 275 6. RTP Data Header Additions 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |V=2|P|X| CC |M|R| PT | sequence number | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | timestamp | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | synchronization source (SSRC) identifier | 285 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 286 | send time-stamp | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | contributing source (CSRC) identifiers | 289 | .... | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 1: RTP header and additions with R=0, no RTT included. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |V=2|P|X| CC |M|R| PT | sequence number | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | timestamp | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | synchronization source (SSRC) identifier | 301 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 302 | send time-stamp | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | RTT | 305 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 306 | contributing source (CSRC) identifiers | 307 | .... | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 2: RTP header and additions with R=1, RTT included. 311 7. Receiver Report Extensions 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |V=2|P| RC | PT=RR=201 | length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | SSRC of packet sender | 318 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 319 | SSRC (SSRC of first source) | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | fraction lost | cumulative number of packets lost | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | extended highest sequence number received | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | interarrival jitter | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | last SR (LSR) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | delay since last SR (DLSR) | 330 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 331 | t_i | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | t_delay | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | data rate at the receiver (x_recv) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | loss event rate (p) | 338 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 339 Figure 3: RTCP Receiver Report extensions. 341 8. RTCP Timing Intervals 343 The RTP/AVPCC profile recommends the use of the TFRC timing feedback 344 requirements for the RTCP timing intervals, only in instances where 345 control traffic bandwidth does not exceed RFC 3550's recommended 5% 346 of data traffic. 348 A TFRC sender requires feedback from its receiver at least once per 349 RTT or per packet received (based on the larger time interval). These 350 requirements are to ensure timely reaction to congestion. 352 In some instances TFRC's timing requirements may result in timing 353 intervals for RTCP traffic that are smaller than RFC 3550's 354 recommended scaled reduced minimum timing interval of 360 divided by 355 session bandwidth in kilobits/second or t(s) = 360/X(kbps). 357 For example, Figure 4 depicts two AVPCC flows and their relationship 358 with RTCP's reduced minimum interval: t(ms) = 360/X (Mbps). The two 359 flows have data rates of 2 Mbps and 4 Mbps with RTTs of 70 ms and 130 360 ms, respectively. 362 The 4 Mbps flow's TFRC feedback requirements of 130 ms falls within 363 RFC 3550's recommended reduced minimum interval for RTCP traffic. 364 However the 2 Mbps flow's TFRC feedback requirement of once per 70 ms 365 is more frequent than the 180 ms recommended by RFC 3550. 367 However in this case, it is safe to use TFRC's 70 ms interval, as at 368 the rate of roughly one 88 octet RTCP compound packet per 70 ms, the 369 feedback traffic for the 2 Mbps flow amounts to 10 kbps, that is less 370 than 1% of the data flow and well with the 5% recommended by RFC 371 3550. 373 Bandwidth (Mbps) 374 ^ 375 | \ 376 | \ 377 | \ 378 | \ 360 379 | \ t(ms)= ------- 380 | \ X (Mbps) 381 | \ 382 | \_ 383 4 | \__ x 384 | \___ 385 2 | x \____ 386 | \_________ 387 +----------------------------------> 388 70 130 389 Time (ms) 391 Figure 4: Relationship between RFC 3550 recommended reduced minimum 392 interval and session bandwidth (Mbps). 394 9. Open Issues 396 There are a number of open issues on the AVPCC on which we are 397 soliciting input from the community: 399 o RFC 3550 recommends that the percentage of control traffic 400 relative to data, be fixed at 5%. For some flows, the feedback 401 traffic for AVPCC may exceed this recommendation. Should AVPCC 402 mandate a strict limit on the percentage of control traffic 403 bandwidth? At what point is feedback too much feedback? 404 (i.e., does it make sense for control traffic be 50% of data 405 traffic?) 407 What are the implications of this limit, in terms of congestion 408 control, for flows which cannot abide by the limit? This is 409 particularly the case for low bandwidth flows, under 1 Mbps, and 410 RTTs of say less than 10 ms. 412 o Security: Is it possible for the AVPCC to use the security 413 mechanisms of SRTP as defined in RFC 3711 or is it necessary 414 to define alternative security profile and mechanisms? 416 o RTT calculations by the sender: As an alternative to including 417 t_i and t_delay in each RTCP packet, could the sender use the LSR 418 and DLSR fields of the Receiver Reports to calculate the RTT? 419 This is mainly a question of: is the frequency of the RTTs 420 computed from Sender Reports sufficient for the sender to react 421 to changes in the RTT and congestion? 423 o How does this profile relate to other RTP profiles? 425 10. IANA Considerations 427 The RTP profile for TCP Friendly Rate Control extends the profile for 428 audio- visual conferences with minimal control and needs to be 429 registered for the Session Description Protocol [SDP] as "RTP/AVPCC". 431 SDP Protocol ("proto"): 433 Name: RTP/AVPCC 434 Long form: RTP Profile for TCP Friendly Rate Control 435 Type of name: proto 436 Type of attribute: Media level only 437 Purpose: RFC XXXX 438 Reference: RFC XXXX 440 11. Security Considerations 442 See Section 9 (Open Issues). 444 12. Acknowledgments 446 This memo is based upon work supported by the U.S. National Science 447 Foundation (NSF) under Grant No. 0334182. Any opinions, findings and 448 conclusions or recommendations expressed in this material are those 449 of the authors and do not necessarily reflect the views of NSF. 451 13. Author's Address 453 Ladan Gharai 454 USC Information Sciences Institute 455 3811 N. Fairfax Drive, #200 456 Arlington, VA 22203 457 USA 459 Normative References 461 [RTP] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, 462 "RTP: A Transport Protocol for Real-Time Applications", 463 Internet Engineering Task Force, RFC 3550 (STD0064), July 464 2003. 466 [AVP] H. Schulzrinne and S. Casner, "RTP Profile for Audio and 467 Video Conferences with Minimal Control," RFC 3551 (STD0065), 468 July 2003. 470 [2119] S. Bradner, "Key words for use in RFCs to Indicate 471 Requirement Levels", Internet Engineering Task Force, 472 RFC 2119, March 1997. 474 [2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 475 Considerations Section in RFCs", Internet Engineering Task 476 Force, RFC 2434, October 1998. 478 [TFRC] M. Handley, S. Floyed, J. Padhye and J. widmer, 479 "TCP Friendly Rate Control (TRFC): Protocol Specification", 480 Internet Engineering Task Force, RFC 3448, January 2003. 482 [SDP] M. Handley and V. Jacobson, "SDP: Session Description 483 Protocol", RFC 2327, April 1998. 485 Informative References 487 14. IPR Notice 489 The IETF takes no position regarding the validity or scope of any 490 intellectual property or other rights that might be claimed to 491 pertain to the implementation or use of the technology described in 492 this document or the extent to which any license under such rights 493 might or might not be available; neither does it represent that it 494 has made any effort to identify any such rights. Information on the 495 IETF's procedures with respect to rights in standards-track and 496 standards-related documentation can be found in BCP-11. Copies of 497 claims of rights made available for publication and any assurances of 498 licenses to be made available, or the result of an attempt made to 499 obtain a general license or permission for the use of such 500 proprietary rights by implementors or users of this specification can 501 be obtained from the IETF Secretariat. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights which may cover technology that may be required to practice 506 this standard. Please address the information to the IETF Executive 507 Director. 509 15. Full Copyright Statement 511 Copyright (C) The Internet Society (2004). This document is subject 512 to the rights, licenses and restrictions contained in BCP 78, and 513 except as set forth therein, the authors retain all their rights. 515 This document and translations of it may be copied and furnished to 516 others, and derivative works that comment on or otherwise explain it 517 or assist in its implementation may be prepared, copied, published 518 and distributed, in whole or in part, without restriction of any 519 kind, provided that the above copyright notice and this paragraph are 520 included on all such copies and derivative works. However, this 521 document itself may not be modified in any way, such as by removing 522 the copyright notice or references to the Internet Society or other 523 Internet organizations, except as needed for the purpose of 524 developing Internet standards in which case the procedures for 525 copyrights defined in the Internet Standards process must be 526 followed, or as required to translate it into languages other than 527 English. 529 The limited permissions granted above are perpetual and will not be 530 revoked by the Internet Society or its successors or assigns. 532 This document and the information contained herein is provided on an 533 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 534 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 535 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 536 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 537 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.