idnits 2.17.1 draft-ietf-avt-tfrc-profile-03.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 522. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 528), 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. ** 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. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 October 2004) is 7116 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 483, 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: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force AVT WG 3 INTERNET-DRAFT Ladan Gharai 4 draft-ietf-avt-tfrc-profile-03.txt USC/ISI 5 24 October 2004 6 Expires: April 2005 8 RTP Profile for TCP Friendly Rate Control 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-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 technical differences as to 133 how (and which) congestion control information is exchanged between 134 DCCP with CCID3 and the RTP/AVPCC profile: 136 o A RTP/AVPCC sender transmits a send timestamp to the RTP/AVPCC 137 receiver with every data packet. In addition to congestion 138 control the send timestamp can be used by the receiver for 139 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, whereas RTP only supports a 16 bit sequence number. While 155 this makes RTP susceptible to data injection attacks, it can be 156 avoided by using the SRTP [SRTP] profile in conjunction with the 157 AVPCC profile. 159 3. Conventions Used in this Document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119 [2119]. 165 4. RTP and RTCP Packet Forms and Protocol Behavior 167 The section "RTP Profiles and Payload Format Specifications" of RFC 168 3550 enumerates a number of items that can be specified or modified 169 in a profile. This section addresses each of these items and states 170 which item is modified by the RTP/AVPCC profile: 172 RTP data header: The standard format of the fixed RTP data 173 header has been modified (see Section 6). 175 Payload types: The payload type in the RTP data header is 176 reduced to 6 bits, therefore payload types are restricted to 177 values in the range of 0 to 63. 179 RTP data header additions: Two 32 bit fixed fields, send 180 timestamp and round trip time (RTT), are added to the RTP 181 data header. The send time stamp is always present and 182 the RTT field is present if the R bit is set. 184 RTP data header extensions: No RTP header extensions are 185 defined, but applications operating under this profile 186 MAY use such extensions. Thus, applications SHOULD NOT 187 assume that the RTP header X bit is always zero and SHOULD 188 be prepared to ignore the header extension. If a header 189 extension is defined in the future, that definition MUST 190 specify the contents of the first 16 bits in such a way 191 that multiple different extensions can be identified. 193 RTCP packet types: No additional RTCP packet types are defined 194 by this profile specification. 196 RTCP report interval: This profile is restricted to unicast 197 flows, therefore at all times there is only one active sender 198 and one receiver. Sessions operating under this profile MAY 199 specify a separate parameter for the RTCP traffic bandwidth 200 rather than using the default fraction of the session 201 bandwidth. In particular this may be necessary for data 202 flows were the the RTCP recommended reduced minimum interval 203 is still greater than the RTT. 205 SR/RR extension: A 16 octet RR extension is defined for the RTCP 206 RR packet. 208 SDES use: Applications MAY use any of the SDES items described 209 in the RTP specification. 211 Security: This profile adapts the use of the SRTP profile in 212 instances where confidentiality, message authentication and 213 replay protection of the RTP data flows and RTCP control 214 flows are desired. 216 String-to-key mapping: No mapping is specified by this profile. 218 Congestion: This profile specifies how to use RTP/RTCP with TFRC 219 congestion control. 221 Underlying protocol: The profile specifies the use of RTP over 222 unicast UDP flows only, multicast MUST NOT be used. 224 Transport mapping: The standard mapping of RTP and RTCP to 225 transport-level addresses is used. 227 Encapsulation: This profile is defined for encapsulation 228 over UDP only. 230 5. The TFRC Feedback Loop 232 TFRC depends on the exchange of congestion control information 233 between a sender and receiver. In this section we reiterate which 234 items are exchanged between a TFRC sender and receiver as discussed 235 in [TFRC]. We note how the RTP/AVPCC profile accommodates these 236 exchanges. 238 5.1. Data Packets 240 As stated in [TFRC] a TFRC sender transmits the following information 241 in each data packet to the receiver: 243 o A sequence number, incremented by one for each data packet 244 transmitted. 246 o A timestamp indicating the packet send time and the sender's 247 current estimate of the round-trip time, RTT. This information 248 is then used by the receiver to compute the TFRC loss intervals. 249 - or - 250 A course-grained timestamp incrementing every quarter of a 251 round trip time, which is then used to determine the TFRC loss 252 intervals. 254 The standard RTP sequence number suffices for TFRCs functionality. 255 For the computation of the loss intervals the RTP/AVPCC profile 256 extends the RTP data header as follows: a 32 bit field to transmit a 257 send timestamp and an additional 32 bit field, present only when the 258 RTT changes, to transmit the RTT. The presence of the RTT is 259 indicated by the R bit in the RTP header (see Section 6). 261 5.2. Feedback Packets 263 As stated in [TFRC] a TFRC receiver provides the following feedback 264 to the sender at least once per RTT or per data packet received 265 (which ever time interval is larger): 267 o The timestamp of the last data packet received, t_i. 269 o The amount of time elapsed between the receipt of the last 270 data packet at the receiver, and the generation of this feedback 271 report, t_delay. This is used by the sender for RTT computations 272 (see Section 9). 274 o The rate at which the receiver estimates that data was received 275 since the last feedback report was sent, x_recv 277 o The receiver's current estimate of the loss event rate, p. 279 To accommodate the feedback of these values the RTP/AVPCC profile 280 defines a 16 octet extension to the RTCP Receiver Reports (see 281 Section 7). 283 6. RTP Data Header Additions 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |V=2|P|X| CC |M|R| PT | sequence number | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | timestamp | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | synchronization source (SSRC) identifier | 293 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 294 | send time-stamp | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | contributing source (CSRC) identifiers | 297 | .... | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 1: RTP header and additions with R=0, no RTT included. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 |V=2|P|X| CC |M|R| PT | sequence number | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | timestamp | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | synchronization source (SSRC) identifier | 309 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 310 | send time-stamp | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | RTT | 313 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 314 | contributing source (CSRC) identifiers | 315 | .... | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 2: RTP header and additions with R=1, RTT included. 319 7. Receiver Report Extensions 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 |V=2|P| RC | PT=RR=201 | length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | SSRC of packet sender | 327 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 328 | SSRC (SSRC of first source) | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | fraction lost | cumulative number of packets lost | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | extended highest sequence number received | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | interarrival jitter | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | last SR (LSR) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | delay since last SR (DLSR) | 339 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 340 | t_i | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | t_delay | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | data rate at the receiver (x_recv) | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | loss event rate (p) | 347 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 348 Figure 3: RTCP Receiver Report extensions. 350 8. RTCP Timing Intervals 352 The RTP/AVPCC profile recommends the use of the TFRC timing feedback 353 requirements for the RTCP timing intervals, only in instances where 354 control traffic bandwidth does not exceed RFC 3550's recommended 5% 355 of data traffic. 357 A TFRC sender requires feedback from its receiver at least once per 358 RTT or per packet received (based on the larger time interval). These 359 requirements are to ensure timely reaction to congestion. 361 In some instances TFRC's timing requirements may result in timing 362 intervals for RTCP traffic that are smaller than RFC 3550's 363 recommended scaled reduced minimum timing interval of 360 divided by 364 session bandwidth in kilobits/second or t(s) = 360/X(kbps). 366 For example, Figure 4 depicts two AVPCC flows and their relationship 367 with RTCP's reduced minimum interval: t(ms) = 360/X (Mbps). The two 368 flows have data rates of 2 Mbps and 4 Mbps with RTTs of 70 ms and 130 369 ms, respectively. 371 The 4 Mbps flow's TFRC feedback requirements of 130 ms falls within 372 RFC 3550's recommended reduced minimum interval for RTCP traffic. 373 However the 2 Mbps flow's TFRC feedback requirement of once per 70 ms 374 is more frequent than the 180 ms recommended by RFC 3550. 376 However in this case, it is safe to use TFRC's 70 ms interval, as at 377 the rate of roughly one 88 octet RTCP compound packet per 70 ms, the 378 feedback traffic for the 2 Mbps flow amounts to 10 kbps, that is less 379 than 1% of the data flow and well with the 5% recommended by RFC 380 3550. 382 Bandwidth (Mbps) 383 ^ 384 | \ 385 | \ 386 | \ 387 | \ 360 388 | \ t(ms)= ------- 389 | \ X (Mbps) 390 | \ 391 | \_ 392 4 | \__ x 393 | \___ 394 2 | x \____ 395 | \_________ 396 +----------------------------------> 397 70 130 398 Time (ms) 400 Figure 4: Relationship between RFC 3550 recommended reduced minimum 401 interval and session bandwidth (Mbps). 403 9. Open Issues 405 There are a number of open issues on the AVPCC on which we are 406 soliciting input from the community: 408 o RFC 3550 recommends that the percentage of control traffic 409 relative to data, be fixed at 5%. For some flows, the feedback 410 traffic for AVPCC may exceed this recommendation. Should AVPCC 411 mandate a strict limit on the percentage of control traffic 412 bandwidth? At what point is feedback too much feedback? 413 (i.e., does it make sense for control traffic be 50% of data 414 traffic?) 416 What are the implications of this limit, in terms of congestion 417 control, for flows which cannot abide by the limit? This is 418 particularly the case for low bandwidth flows, under 1 Mbps, and 419 RTTs of say less than 10 ms. 421 o RTT calculations by the sender: As an alternative to including 422 t_i and t_delay in each RTCP packet, could the sender use the LSR 423 and DLSR fields of the Receiver Reports to calculate the RTT? 425 These fields are particularly redundant in instances of two-way 426 traffic, i.e. each end point is both sending and receiving. 427 However, for one-way traffic the SR frequency would most likely 428 not be sufficient. 430 10. IANA Considerations 432 The RTP profile for TCP Friendly Rate Control extends the profile for 433 audio- visual conferences with minimal control and needs to be 434 registered for the Session Description Protocol [SDP] as "RTP/AVPCC". 436 SDP Protocol ("proto"): 438 Name: RTP/AVPCC 439 Long form: RTP Profile for TCP Friendly Rate Control 440 Type of name: proto 441 Type of attribute: Media level only 442 Purpose: RFC XXXX 443 Reference: RFC XXXX 445 11. Security Considerations 447 This profile adapts the use of the SRTP profile in instances where 448 confidentiality, message authentication and replay protection of the 449 RTP data flows and RTCP control flows is desired. When used in 450 conjunction with the SRTP profile the AVPCC profile inherits its 451 security properties from the SAVP profile. 453 12. Acknowledgments 455 This memo is based upon work supported by the U.S. National Science 456 Foundation (NSF) under Grant No. 0334182. Any opinions, findings and 457 conclusions or recommendations expressed in this material are those 458 of the authors and do not necessarily reflect the views of NSF. 460 13. Author's Address 462 Ladan Gharai 463 USC Information Sciences Institute 464 3811 N. Fairfax Drive, #200 465 Arlington, VA 22203 466 USA 468 Normative References 470 [RTP] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, 471 "RTP: A Transport Protocol for Real-Time Applications", 472 Internet Engineering Task Force, RFC 3550 (STD0064), July 473 2003. 475 [AVP] H. Schulzrinne and S. Casner, "RTP Profile for Audio and 476 Video Conferences with Minimal Control," RFC 3551 (STD0065), 477 July 2003. 479 [2119] S. Bradner, "Key words for use in RFCs to Indicate 480 Requirement Levels", Internet Engineering Task Force, 481 RFC 2119, March 1997. 483 [2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 484 Considerations Section in RFCs", Internet Engineering Task 485 Force, RFC 2434, October 1998. 487 [TFRC] M. Handley, S. Floyed, J. Padhye and J. widmer, 488 "TCP Friendly Rate Control (TRFC): Protocol Specification", 489 Internet Engineering Task Force, RFC 3448, January 2003. 491 [SDP] M. Handley and V. Jacobson, "SDP: Session Description 492 Protocol", RFC 2327, April 1998. 494 [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 495 "The Secure Real-time Transport Protocol", RFC 3711, March 496 2004. 498 Informative References 500 14. IPR Notice 502 The IETF takes no position regarding the validity or scope of any 503 Intellectual Property Rights or other rights that might be claimed to 504 pertain to the implementation or use of the technology described in 505 this document or the extent to which any license under such rights 506 might or might not be available; nor does it represent that it has 507 made any independent effort to identify any such rights. Information 508 on the procedures with respect to rights in RFC documents can be 509 found in BCP 78 and BCP 79. 511 Copies of IPR disclosures made to the IETF Secretariat and any 512 assurances of licenses to be made available, or the result of an 513 attempt made to obtain a general license or permission for the use of 514 such proprietary rights by implementers or users of this 515 specification can be obtained from the IETF on-line IPR repository at 516 http://www.ietf.org/ipr. 518 The IETF invites any interested party to bring to its attention any 519 copyrights, patents or patent applications, or other proprietary 520 rights that may cover technology that may be required to implement 521 this standard. Please address the information to the IETF at ietf- 522 ipr@ietf.org. 524 15. Full Copyright Statement 526 Copyright (C) The Internet Society (2004). This document is subject 527 to the rights, licenses and restrictions contained in BCP 78, and 528 except as set forth therein, the authors retain all their rights. 530 This document and the information contained herein are provided on an 531 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 532 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 533 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 534 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 535 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 536 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.