idnits 2.17.1 draft-ietf-avt-tfrc-profile-04.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 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 548. ** 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 351 has weird spacing: '...profile defin...' -- 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 (16 July 2005) is 6859 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 509, 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: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 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-04.txt USC/ISI 4 16 July 2005 5 Expires: January 2006 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 (2005). 35 Abstract 37 This memo specifies a profile called "RTP/AVPCC" for the use of the 38 real-time transport protocol (RTP) and its associated control 39 protocol, RTCP, with the TCP Friendly Rate Control (TFRC). TFRC is 40 an equation based congestion control scheme for unicast flows 41 operating in a best effort Internet environment. This profile 42 provides RTP flows with the mechanism to use congestion control in 43 best effort IP networks. 45 1. Introduction 47 [Note to RFC Editor: All references to RFC XXXX are to be replaced 48 with the RFC number of this memo, when published] 50 This memo defines a profile called "RTP/AVPCC" for the use of the 51 real-time transport protocol (RTP) [RTP] and its associated control 52 protocol, RTCP, with the TCP Friendly Rate Control (TFRC) [TFRC]. 53 TFRC is an equation based congestion control scheme for unicast flows 54 operating in a best effort Internet environment and competing with 55 TCP traffic. 57 Due to a number of inherent TFRC characteristics, the RTP/AVPCC 58 profile differs from other RTP profiles [AVP] in the following ways: 60 o TFRC is a unicast congestion control scheme, therefore by 61 extension the RTP/AVPCC profile can only be used by unicast RTP 62 flows. 64 o A TFRC sender relies on receiving feedback from the receiver 65 either once per round-trip time (RTT) or per data packet. For 66 certain flows (depending on RTTs and data rates) these TFRC 67 requirements can result in control traffic that exceeds RFC 3550's 68 bandwidth and/or timing recommendations for control traffic. The 69 RTP/AVPCC profile recommends modifications to these 70 recommendations in order to satisfy TFRCs timing needs for control 71 traffic in a safe manner. 73 This memo primarily addresses the means of supporting TFRC's 74 exchange of congestion control information between senders and 75 receivers via the following modifications to RTP and RTCP: (1) RTP 76 data header additions; (2) extensions to the RTCP Receiver Reports; 77 and (3) modifications to the recommended RTCP timing intervals. For 78 details on TFRC congestion control readers are referred to [TFRC]. 80 The current TFRC standard, RFC3448, only targets applications with 81 fixed packet size. TFRC-PS is a variant of TFRC for applications with 82 varying packet sizes. The RTP/AVPCC profile is applicable to both 83 congestion control schemes. 85 2. Relation to the Datagram Congestion Control Protocol 87 The Datagram Congestion Control Protocol (DCCP) is a minimal general 88 purpose transport-layer protocol with unreliable yet congestion 89 controlled packet delivery semantics and reliable connection setup 90 and teardown. DCCP currently supports both TFRC and TCP-like 91 congestion control. In addition DCCP supports a host of other 92 features, such as: use of Explicit Congestion Notification (ECN) and 93 the ECN Nonce, reliable option negotiation and Path Maximum Transfer 94 Unit (PMTU). Naturally an application using RTP/DCCP as its 95 transport protocol will benefit from the protocol features supported 96 by DCCP. 98 In contrast the RTP Profile for TFRC only provides RTP applications a 99 standardized means for using the TFRC congestion control scheme, 100 without any of the protocol features of DCCP. However there are a 101 number of benefits to be gained by the development and 102 standardization of a RTP Profile for TFRC: 104 o Media applications lacking congestion control can incorporate 105 congestion controlled transport without delay by using the 106 RTP/AVPCC profile. The DCCP protocol is currently under 107 development and widespread deployment is not yet in place. 109 o Use of the RTP/AVPCC profile is not contingent on any OS level 110 changes and can be quickly deployed, as the AVPCC profile is 111 implemented at the application layer. 113 o AVPCC/RTP/UDP flows face the same restrictions in firewall 114 traversal as do UDP flows and do not require NATs and firewall 115 modifications. DCCP flows, on the other hand, do require NAT 116 and firewall modifications, however once these modifications 117 are in place, they can result in easier NAT and firewall 118 traversal for RTP/DCCP flows in the future. 120 o Use of the RTP/AVPCC profile with various media applications will 121 give researchers, implementors and developers a better 122 understanding of the intricate relationship between media 123 quality and equation based congestion control. Hopefully this 124 experience with congestion control and TFRC will ease the 125 migration of media applications to DCCP once DCCP is deployed. 127 Overall, the RTP/AVPCC profile provides an immediate means for 128 congestion control in media streams, in the time being until DCCP is 129 deployed. 131 Additionally, there are also a number of technical differences as to 132 how (and which) congestion control information is exchanged between 133 DCCP with CCID3 and the RTP/AVPCC profile: 135 o A RTP/AVPCC sender transmits a send timestamp to the RTP/AVPCC 136 receiver with every data packet. In addition to congestion 137 control the send timestamp can be used by the receiver for 138 jitter calculations. 140 In contrast DCCP with CCID3 transmits a quad round trip 141 counter to the receiver. 143 o A RTP/AVPCC receiver only provides the RTP/AVPCC sender 144 with the loss event rate as computed by the receiver. 146 In contrast DCCP with CCID3, provides 2 other options for the 147 transport of loss event rate. A sender may choose to receive 148 loss intervals or an Ack Vector. These two options provide the 149 sender with the necessary information to compute the loss event 150 rate. 152 o Sequence number: DCCP supports a 48 bit and a 24 bit sequence 153 number, whereas RTP only supports a 16 bit sequence number. While 154 this makes RTP susceptible to data injection attacks, it can be 155 avoided by using the SRTP [SRTP] profile in conjunction with the 156 AVPCC profile. 158 3. Conventions Used in this Document 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [2119]. 164 4. RTP and RTCP Packet Forms and Protocol Behavior 166 The section "RTP Profiles and Payload Format Specifications" of RFC 167 3550 enumerates a number of items that can be specified or modified 168 in a profile. This section addresses each of these items and states 169 which item is modified by the RTP/AVPCC profile: 171 RTP data header: The standard format of the fixed RTP data 172 header has been modified (see Section 6). 174 Payload types: The payload type in the RTP data header is 175 reduced to 6 bits, therefore payload types are restricted to 176 values in the range of 0 to 63. 178 RTP data header additions: Two 32 bit fixed fields, send 179 timestamp and round trip time (RTT), are added to the RTP 180 data header. The send time stamp is always present and 181 the RTT field is present if the R bit is set. 183 RTP data header extensions: No RTP header extensions are 184 defined, but applications operating under this profile 185 MAY use such extensions. Thus, applications SHOULD NOT 186 assume that the RTP header X bit is always zero and SHOULD 187 be prepared to ignore the header extension. If a header 188 extension is defined in the future, that definition MUST 189 specify the contents of the first 16 bits in such a way 190 that multiple different extensions can be identified. 192 RTCP packet types: No additional RTCP packet types are defined 193 by this profile specification. 195 RTCP report interval: This profile is restricted to unicast 196 flows, therefore at all times there is only one active sender 197 and one receiver. Sessions operating under this profile MAY 198 specify a separate parameter for the RTCP traffic bandwidth 199 rather than using the default fraction of the session 200 bandwidth. In particular this may be necessary for data 201 flows were the the RTCP recommended reduced minimum interval 202 is still greater than the RTT. 204 SR/RR extension: A 16 octet RR extension is defined for the RTCP 205 RR packet. 207 SDES use: Applications MAY use any of the SDES items described 208 in the RTP specification. 210 Security: This profile is subject to the security considerations 211 discussed in the TFRC and RTP specifications [TFRC][RTP]. This 212 profile does not specify any additional security services. 214 String-to-key mapping: No mapping is specified by this profile. 216 Congestion: This profile specifies how to use RTP/RTCP with TFRC 217 congestion control. 219 Underlying protocol: The profile specifies the use of RTP over 220 unicast UDP flows only, multicast MUST NOT be used. 222 Transport mapping: The standard mapping of RTP and RTCP to 223 transport-level addresses is used. 225 Encapsulation: This profile is defined for encapsulation 226 over UDP only. 228 5. The TFRC Feedback Loop 230 TFRC depends on the exchange of congestion control information 231 between a sender and receiver. In this section we reiterate which 232 items are exchanged between a TFRC sender and receiver as discussed 233 in [TFRC]. We note how the RTP/AVPCC profile accommodates these 234 exchanges. 236 5.1. Data Packets 238 As stated in [TFRC] a TFRC sender transmits the following information 239 in each data packet to the receiver: 241 o A sequence number, incremented by one for each data packet 242 transmitted. 244 o A timestamp indicating the packet send time and the sender's 245 current estimate of the round-trip time, RTT. This information 246 is then used by the receiver to compute the TFRC loss intervals. 247 - or - 248 A course-grained timestamp incrementing every quarter of a 249 round trip time, which is then used to determine the TFRC loss 250 intervals. 252 The standard RTP sequence number suffices for TFRCs functionality. 253 For the computation of the loss intervals the RTP/AVPCC profile 254 extends the RTP data header as follows: a 32 bit field to transmit a 255 send timestamp and an additional 32 bit field, present only when the 256 RTT changes, to transmit the RTT. The presence of the RTT is 257 indicated by the R bit in the RTP header (see Section 6). 259 5.2. Feedback Packets 261 As stated in [TFRC] a TFRC receiver provides the following feedback 262 to the sender at least once per RTT or per data packet received 263 (which ever time interval is larger): 265 o The timestamp of the last data packet received, t_i. 267 o The amount of time elapsed between the receipt of the last 268 data packet at the receiver, and the generation of this feedback 269 report, t_delay. This is used by the sender for RTT computations 270 (see Section 9). 272 o The rate at which the receiver estimates that data was received 273 since the last feedback report was sent, x_recv. 275 o The receiver's current estimate of the loss event rate, p. 277 To accommodate the feedback of these values the RTP/AVPCC profile 278 defines a 16 octet extension to the RTCP Receiver Reports (see 279 Section 7). 281 6. RTP Data Header Additions 283 The RTP/AVPCC profile makes the following changes to the RTP header 284 (other fields of the payload header are defined as in RFC 3550 285 [RTP]): 287 o the profile uses a 6 bit payload type (PT) field, 288 o defines a 1 bit R field in the second octet, and 289 o defines two additional 32 bit fixed fields: 290 1. the packets send timestamp, 291 2. the round trip time (RTT) as measured by the sender. This 292 field is present if the R bit is set (see Figures 1 and 2). 294 The additional fields of the RTP header are defined and used as 295 follows: 297 Round trip time indicator (R): 1 bit 298 This field indicates the existence of the additional RTT field. If 299 the R bit is set, the RTP payload header includes a 32 bit field 300 representing the current round trip time (Figure 2). 302 Payload type (PT): 6 bits 303 The RTP/AVPCC profile uses a 6 bit field for the payload type 304 (instead of a 7 bit field). 306 Send timestamp: 32 bits 307 The timestamp indicating when the packet is sent. This timestamp 308 is measured in milliseconds and is used for round trip time 309 calculations. 311 Round trip time (RTT): 32 bits 312 The round trip time as measured by the RTP/AVPCC sender in 313 milliseconds. This field is only present if the R bit is set. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |V=2|P|X| CC |M|R| PT | sequence number | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | timestamp | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | synchronization source (SSRC) identifier | 323 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 324 | send timestamp | 325 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 326 | contributing source (CSRC) identifiers | 327 | .... | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 1: RTP header and additions with R=0, no RTT included. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 |V=2|P|X| CC |M|R| PT | sequence number | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | timestamp | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | synchronization source (SSRC) identifier | 339 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 340 | send timestamp | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | RTT | 343 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 344 | contributing source (CSRC) identifiers | 345 | .... | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 2: RTP header and additions with R=1, RTT included. 349 7. Receiver Report Extensions 351 The RTP/AVPCC profile defines four 32 bit fixed fields as profile- 352 specific extensions to the receiver reports (Figure 3). These four 353 fields are: 355 Timestamp (t_i): 32 bits 356 The timestamp of the last data packet received, t_i, in 357 milliseconds. 359 Delay (t_delay): 32 bits 360 The amount of time elapsed between the receipt of the last data 361 packet at the receiver, and the generation of this feedback report, 362 t_delay. This is used by the sender for RTT computations 364 Data rate (x_recv): 32 bits 365 The rate at which the receiver estimates that data was received 366 since the last feedback report was sent in bits per second. 368 Loss event rate (p): 32 bits 369 The receiver's current estimate of the loss event rate, p. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |V=2|P| RC | PT=RR=201 | length | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | SSRC of packet sender | 377 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 378 | SSRC (SSRC of first source) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | fraction lost | cumulative number of packets lost | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | extended highest sequence number received | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | interarrival jitter | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | last SR (LSR) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | delay since last SR (DLSR) | 389 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 390 | t_i | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | t_delay | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | data rate at the receiver (x_recv) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | loss event rate (p) | 397 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 398 Figure 3: RTCP Receiver Report extensions. 400 8. RTCP Timing Intervals 402 The RTP/AVPCC profile recommends the use of the TFRC timing feedback 403 requirements for the RTCP timing intervals, only in instances where 404 control traffic bandwidth does not exceed RFC 3550's recommended 5% 405 of data traffic. 407 A TFRC sender requires feedback from its receiver at least once per 408 RTT or per packet received (based on the larger time interval). These 409 requirements are to ensure timely reaction to congestion. 411 In some instances TFRC's timing requirements may result in timing 412 intervals for RTCP traffic that are smaller than RFC 3550's 413 recommended scaled reduced minimum timing interval of 360 divided by 414 session bandwidth in kilobits/second or t(s) = 360/X(kbps). 416 For example, Figure 4 depicts two AVPCC flows and their relationship 417 with RTCP's reduced minimum interval: t(ms) = 360/X (Mbps). The two 418 flows have data rates of 2 Mbps and 4 Mbps with RTTs of 70 ms and 130 419 ms, respectively. 421 The 4 Mbps flow's TFRC feedback requirements of 130 ms falls within 422 RFC 3550's recommended reduced minimum interval for RTCP traffic. 423 However the 2 Mbps flow's TFRC feedback requirement of once per 70 ms 424 is more frequent than the 180 ms recommended by RFC 3550. 426 However in this case, it is safe to use TFRC's 70 ms interval, as at 427 the rate of roughly one 88 octet RTCP compound packet per 70 ms, the 428 feedback traffic for the 2 Mbps flow amounts to 10 kbps, that is less 429 than 1% of the data flow and well with the 5% recommended by RFC 430 3550. 432 Bandwidth (Mbps) 433 ^ 434 | \ 435 | \ 436 | \ 437 | \ 360 438 | \ t(ms)= ------- 439 | \ X (Mbps) 440 | \ 441 | \_ 442 4 | \__ x 443 | \___ 444 2 | x \____ 445 | \_________ 446 +----------------------------------> 447 70 130 448 Time (ms) 450 Figure 4: Relationship between RFC 3550 recommended reduced minimum 451 interval and session bandwidth (Mbps). 453 9. IANA Considerations 455 The RTP profile for TCP Friendly Rate Control extends the profile for 456 audio- visual conferences with minimal control and needs to be 457 registered for the Session Description Protocol [SDP] as "RTP/AVPCC". 459 SDP Protocol ("proto"): 461 Name: RTP/AVPCC 462 Long form: RTP Profile for TCP Friendly Rate Control 463 Type of name: proto 464 Type of attribute: Media level only 465 Purpose: RFC XXXX 466 Reference: RFC XXXX 468 10. Security Considerations 470 The RTP/AVPCC profile is subject to the security considerations 471 discussed in the TFRC and RTP specifications [TFRC][RTP]. This 472 profile does not specify any additional security services. 474 To guard against spoofed feedback attacks using false RTCP packets, 475 authentication can be used for all RTCP messages. This can be done 476 by defining a combined secure SAVPCC profile, by using the AVPCC 477 profile together with the Secure RTP profile [SRTP]. 479 11. Acknowledgments 481 This memo is based upon work supported by the U.S. National Science 482 Foundation (NSF) under Grant No. 0334182. Any opinions, findings and 483 conclusions or recommendations expressed in this material are those 484 of the authors and do not necessarily reflect the views of NSF. 486 12. Author's Address 488 Ladan Gharai 489 USC Information Sciences Institute 490 3811 N. Fairfax Drive, #200 491 Arlington, VA 22203 492 USA 494 Normative References 496 [RTP] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, 497 "RTP: A Transport Protocol for Real-Time Applications", 498 Internet Engineering Task Force, RFC 3550 (STD0064), July 499 2003. 501 [AVP] H. Schulzrinne and S. Casner, "RTP Profile for Audio and 502 Video Conferences with Minimal Control," RFC 3551 (STD0065), 503 July 2003. 505 [2119] S. Bradner, "Key words for use in RFCs to Indicate 506 Requirement Levels", Internet Engineering Task Force, 507 RFC 2119, March 1997. 509 [2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 510 Considerations Section in RFCs", Internet Engineering Task 511 Force, RFC 2434, October 1998. 513 [TFRC] M. Handley, S. Floyed, J. Padhye and J. widmer, 514 "TCP Friendly Rate Control (TRFC): Protocol Specification", 515 Internet Engineering Task Force, RFC 3448, January 2003. 517 [SDP] M. Handley and V. Jacobson, "SDP: Session Description 518 Protocol", RFC 2327, April 1998. 520 [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 521 "The Secure Real-time Transport Protocol", RFC 3711, March 522 2004. 524 Informative References 526 13. IPR Notice 528 The IETF takes no position regarding the validity or scope of any 529 Intellectual Property Rights or other rights that might be claimed to 530 pertain to the implementation or use of the technology described in 531 this document or the extent to which any license under such rights 532 might or might not be available; nor does it represent that it has 533 made any independent effort to identify any such rights. Information 534 on the procedures with respect to rights in RFC documents can be 535 found in BCP 78 and BCP 79. 537 Copies of IPR disclosures made to the IETF Secretariat and any 538 assurances of licenses to be made available, or the result of an 539 attempt made to obtain a general license or permission for the use of 540 such proprietary rights by implementers or users of this 541 specification can be obtained from the IETF on-line IPR repository at 542 http://www.ietf.org/ipr. 544 The IETF invites any interested party to bring to its attention any 545 copyrights, patents or patent applications, or other proprietary 546 rights that may cover technology that may be required to implement 547 this standard. Please address the information to the IETF at ietf- 548 ipr@ietf.org. 550 14. Full Copyright Statement 552 Copyright (C) The Internet Society (2005). This document is subject 553 to the rights, licenses and restrictions contained in BCP 78, and 554 except as set forth therein, the authors retain all their rights. 556 This document and the information contained herein are provided on an 557 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 558 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 559 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 560 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 561 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 562 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.