idnits 2.17.1 draft-ietf-avt-rtcp-feedback-11.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.5 on line 2406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2390. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2397), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2271 has weird spacing: '...meister burm...' -- 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 (February 2005) is 7009 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) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-18 ** Obsolete normative reference: RFC 2032 (ref. '6') (Obsoleted by RFC 4587) ** Obsolete normative reference: RFC 3388 (ref. '7') (Obsoleted by RFC 5888) ** Obsolete normative reference: RFC 3448 (ref. '8') (Obsoleted by RFC 5348) ** Obsolete normative reference: RFC 2434 (ref. '10') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2733 (ref. '12') (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 2429 (ref. '14') (Obsoleted by RFC 4629) -- Obsolete informational reference (is this intentional?): RFC 2833 (ref. '18') (Obsoleted by RFC 4733, RFC 4734) -- No information found for draft-ietf-dccp-spec-076 - is the name correct? -- Duplicate reference: RFC3448, mentioned in '20', was also mentioned in '8'. -- Obsolete informational reference (is this intentional?): RFC 3448 (ref. '20') (Obsoleted by RFC 5348) == Outdated reference: A later version (-12) exists of draft-ietf-avt-profile-savpf-01 -- Obsolete informational reference (is this intentional?): RFC 3016 (ref. '23') (Obsoleted by RFC 6416) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Joerg Ott/Uni Bremen TZI 3 draft-ietf-avt-rtcp-feedback-11.txt Stephan Wenger/TU Berlin 4 Noriyuki Sato/Oki 5 Carsten Burmeister/Matsushita 6 Jose Rey/Matsushita 8 10 August 2004 9 Expires February 2005 11 Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) 13 Status of this Memo 15 By submitting this Internet-Draft, each author certifies that any 16 applicable patent or other IPR claims of which the author is aware 17 have been disclosed, or will be disclosed, and any of which each 18 author becomes aware will be disclosed, in accordance with RFC 3668 19 (BCP 79). 21 By submitting this Internet-Draft, each author accepts the 22 provisions of Section 3 of RFC 3667 (BCP 78). 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet- Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 This document is a product of the Audio-Visual Transport (AVT) 44 working group of the Internet Engineering Task Force. Comments are 45 solicited and should be addressed to the working group's mailing 46 list at avt@ietf.org and/or the authors. 48 Abstract 50 Real-time media streams that use RTP are, to some degree, resilient 51 against packet losses. Receivers may use the base mechanisms of 52 RTCP to report packet reception statistics and thus allow a sender 53 to adapt its transmission behavior in the mid-term as sole means 54 for feedback and feedback-based error repair (besides a few codec- 55 specific mechanisms). This document defines an extension to the 56 Audio-visual Profile (AVP) that enables receivers to provide, 57 statistically, more immediate feedback to the senders and thus 58 allow for short-term adaptation and efficient feedback-based repair 59 mechanisms to be implemented. This early feedback profile (AVPF) 60 maintains the AVP bandwidth constraints for RTCP and preserves 61 scalability to large groups. 63 Table of Contents 65 1 Introduction..................................................3 66 1.1 Definitions.............................................4 67 1.2 Terminology.............................................6 68 2 RTP and RTCP Packet Formats and Protocol Behavior.............6 69 2.1 RTP.....................................................6 70 2.2 Underlying Transport Protocols..........................7 71 3 Rules for RTCP Feedback.......................................8 72 3.1 Compound RTCP Feedback Packets..........................8 73 3.2 Algorithm Outline.......................................9 74 3.3 Modes of Operation.....................................10 75 3.4 Definitions and Algorithm Overview.....................12 76 3.5 AVPF RTCP Scheduling Algorithm.........................15 77 3.5.1 Initialization...................................15 78 3.5.2 Early Feedback Transmission......................16 79 3.5.3 Regular RTCP Transmission........................19 80 3.5.4 Other Considerations.............................20 81 3.6 Considerations on the Group Size.......................20 82 3.6.1 ACK mode.........................................20 83 3.6.2 NACK mode........................................21 84 3.7 Summary of decision steps..............................22 85 3.7.1 General Hints....................................22 86 3.7.2 Media Session Attributes.........................23 87 4 SDP Definitions..............................................24 88 4.1 Profile identification.................................24 89 4.2 RTCP Feedback Capability Attribute.....................24 90 4.3 RTCP Bandwidth Modifiers...............................28 91 4.4 Examples...............................................28 93 5 Interworking and Co-Existence of AVP and AVPF Entities.......30 94 6 Format of RTCP Feedback Messages.............................31 95 6.1 Common Packet Format for Feedback Messages.............32 96 6.2 Transport Layer Feedback Messages......................34 97 6.2.1 Generic NACK.....................................34 98 6.3 Payload Specific Feedback Messages.....................36 99 6.3.1 Picture Loss Indication (PLI)....................36 100 6.3.1.1 Semantics...............................36 101 6.3.1.2 Message Format..........................37 102 6.3.1.3 Timing Rules............................37 103 6.3.1.4 Remarks.................................37 104 6.3.2 Slice Lost Indication (SLI)......................37 105 6.3.2.1 Semantics...............................38 106 6.3.2.2 Format..................................38 107 6.3.2.3 Timing Rules............................39 108 6.3.2.4 Remarks.................................39 109 6.3.3 Reference Picture Selection Indication (RPSI)....39 110 6.3.3.1 Semantics...............................40 111 6.3.3.2 Format..................................40 112 6.3.3.3 Timing Rules............................41 113 6.4 Application Layer Feedback Messages....................41 114 7 Early Feedback and Congestion Control........................42 115 8 Security Considerations......................................43 116 9 IANA Considerations..........................................44 117 10 Acknowledgements............................................48 118 11 Authors' Addresses..........................................48 119 12 Bibliography................................................49 120 12.1 Normative references...................................49 121 12.2 Informative References.................................50 122 13 Disclaimer of Validity......................................51 123 14 Full Copyright Statement....................................51 124 15 Acknowledgment..............................................52 126 1 Introduction 128 Real-time media streams that use RTP are, to some degree, resilient 129 against packet losses. RTP [1] provides all the necessary 130 mechanisms to restore ordering and timing present at the sender to 131 properly reproduce a media stream at a recipient. RTP also 132 provides continuous feedback about the overall reception quality 133 from all receivers -- thereby allowing the sender(s) in the mid- 134 term (in the order of several seconds to minutes) to adapt their 135 coding scheme and transmission behavior to the observed network 136 QoS. However, except for a few payload specific mechanisms [6], 137 RTP makes no provision for timely feedback that would allow a 138 sender to repair the media stream immediately: through 139 retransmissions, retro-active FEC control, or media-specific 140 mechanisms for some video codecs, such as reference picture 141 selection. 143 Current mechanisms available with RTP to improve error resilience 144 include audio redundancy coding [13], video redundancy coding [14], 145 RTP-level FEC [11], and general considerations on more robust media 146 streams transmission [12]. These mechanisms may be applied pro- 147 actively (thereby increasing the bandwidth of a given media 148 stream). Alternatively, in sufficiently small groups with small 149 RTTs, the senders may perform repair on-demand, using the above 150 mechanisms and/or media-encoding-specific approaches. Note that 151 "small group" and "sufficiently small RTT" are both highly 152 application dependent. 154 This document specifies a modified RTP Profile for audio and video 155 conferences with minimal control based upon [1] and [2] by means of 156 two modifications/additions: to achieve timely feedback, the 157 concept of Early RTCP messages as well as algorithms allowing for 158 low delay feedback in small multicast groups (and preventing 159 feedback implosion in large ones) are introduced. Special 160 consideration is given to point-to-point scenarios. A small number 161 of general-purpose feedback messages as well as a format for codec 162 and application-specific feedback information are defined for 163 transmission in the RTCP payloads. 165 1.1 Definitions 167 The definitions from RTP/RTCP [1] and the RTP Profile for Audio and 168 Video Conferences with Minimal Control [2] apply. In addition, the 169 following definitions are used in this document: 171 Early RTCP mode: 172 The mode of operation in which a receiver of a media stream 173 is often (but not always) capable of reporting events of 174 interest back to the sender close to their occurrence. In 175 Early RTCP mode, RTCP packets are transmitted according to 176 the timing rules defined in this document. 178 Early RTCP packet: 179 An Early RTCP packet is a packet which is transmitted 180 earlier than would be allowed if following the scheduling 181 algorithm of [1], the reason being an "event" observed by a 182 receiver. Early RTCP packets may be sent in Immediate 183 Feedback and in Early RTCP mode. Sending an Early RTCP 184 packet is also referred to as sending Early Feedback in 185 this document. 187 Event: 188 An observation made by the receiver of a media stream that 189 is (potentially) of interest to the sender -- such as a 190 packet loss or packet reception, frame loss, etc. -- and 191 thus useful to be reported back to the sender by means of a 192 Feedback message. 194 Feedback (FB) message: 195 An RTCP message as defined in this document is used to 196 convey information about events observed at a receiver -- 197 in addition to long-term receiver status information which 198 is carried in RTCP RRs -- back to the sender of the media 199 stream. For the sake of clarity, feedback message is 200 referred to as FB message throughout this document. 202 Feedback (FB) threshold: 203 The FB threshold indicates the transition between Immediate 204 Feedback and Early RTCP mode. For a multiparty scenario, 205 the FB threshold indicates the maximum group size at which, 206 on average, each receiver is able to report each event back 207 to the sender(s) immediately, i.e. by means of an Early 208 RTCP packet without having to wait for its regularly 209 scheduled RTCP interval. This threshold is highly 210 dependent on the type of feedback to be provided, network 211 QoS (e.g. packet loss probability and distribution), codec 212 and packetization scheme in use, the session bandwidth, and 213 application requirements. Note that the algorithms do not 214 depend on all senders and receivers agreeing on the same 215 value for this threshold. It is merely intended to provide 216 conceptual guidance to application designers and is not 217 used in any calculations. For the sake of clarity, the term 218 feedback threshold is referred to as FB threshold 219 throughout this document. 221 Immediate Feedback mode: 222 A mode of operation in which each receiver of a media 223 stream is, statistically, capable of reporting each event 224 of interest immediately back to the media stream sender. 225 In Immediate Feedback mode, RTCP FB messages are 226 transmitted according to the timing rules defined in this 227 document. 229 Media packet: 230 A media packet is an RTP packet. 232 Regular RTCP mode: 233 Mode of operation in which no preferred transmission of FB 234 messages is allowed. Instead, RTCP messages are sent 235 following the rules of [1]. Nevertheless, such RTCP 236 messages may contain feedback information as defined in 237 this document. 239 Regular RTCP packet: 240 An RTCP packet that is not sent as an Early RTCP packet. 242 RTP sender: 243 An RTP sender is an RTP entity that transmits media packets 244 as well as RTCP packets and receives Regular as well as 245 Early RTCP (i.e. feedback) packets. Note that the RTP 246 sender is a logical role and that the same RTP entity may 247 at the same time act as an RTP receiver. 249 RTP receiver: 250 An RTP receiver is an RTP entity that receives media 251 packets as well as RTCP packets and transmits Regular as 252 well as Early RTCP (i.e. feedback) packets. Note that the 253 RTP receiver is a logical role and that the same RTP entity 254 may at the same time act as an RTP sender. 256 1.2 Terminology 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 259 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 260 in this document are to be interpreted as described in RFC 2119 261 [5]. 263 2 RTP and RTCP Packet Formats and Protocol Behavior 265 2.1 RTP 267 The rules defined in [2] also apply to this profile except for 268 those rules mentioned in the following: 270 RTCP packet types: 271 Two additional RTCP packet types are registered and the 272 corresponding FB messages to convey feedback information 273 are defined in section 6 of this memo. 275 RTCP report intervals: 276 This document describes three modes of operation which 277 influence the RTCP report intervals (see section 3.2 of 278 this memo). In Regular RTCP mode, all rules from [1] apply 279 except for the recommended minimal interval of five seconds 280 between two RTCP reports from the same RTP entity. In both 281 Immediate Feedback and Early RTCP modes, the minimal 282 interval of five seconds between two RTCP reports is 283 dropped and, additionally, the rules specified in section 3 284 of this memo apply if RTCP packets containing FB messages 285 (defined in section 4 of this memo) are to be transmitted. 287 The rules set forth in [1] may be overridden by session 288 descriptions specifying different parameters (e.g. for the 289 bandwidth share assigned to RTCP for senders and receivers, 290 respectively). For sessions defined using the Session 291 Description Protocol (SDP) [3], the rules of [4] apply. 293 Congestion control: 294 The same basic rules as detailed in [2] apply. Beyond 295 this, in section 7, further consideration is given to the 296 impact of feedback and a sender's reaction to FB messages. 298 2.2 Underlying Transport Protocols 300 RTP is intended to be used on top of unreliable transport 301 protocols, including UDP and DCCP. This section briefly describes 302 the specifics beyond plain RTP operation introduced by RTCP 303 feedback as specified in this memo. 305 UDP: UDP provides best effort delivery of datagrams for point- 306 to-point as well as for multicast communications. UDP does 307 not support congestion control or error repair. The RTCP- 308 based feedback defined in this memo is able to provide 309 minimal support for limited error repair. As RTCP feedback 310 is not guaranteed to operate on sufficiently small 311 timescales (in the order of RTT), RTCP feedback is not 312 suitable to support congestion control. This memo 313 addresses both unicast and multicast operation. 315 DCCP: DCCP [19] provides for congestion-controlled but unreliable 316 datagram flows for unicast communications. With TFRC-based 317 [20] congestion control (CCID 3), DCCP is particularly 318 suitable for audio and video communications. DCCP's 319 acknowledgement messages may provide detailed feedback 320 reporting about received and missed datagrams (and thus 321 about congestion). 323 When running RTP over DCCP, congestion control is performed 324 at the DCCP layer and no additional mechanisms are required 325 at the RTP layer. Furthermore, an RTCP-feedback capable 326 sender may leverage the more frequent DCCP-based feedback 327 and thus a receiver may abstain from using (additional) 328 Generic Feedback messages where appropriate. 330 3 Rules for RTCP Feedback 332 3.1 Compound RTCP Feedback Packets 334 Two components constitute RTCP-based feedback as described in this 335 document: 337 o Status reports are contained in SR/RR packets and are 338 transmitted at regular intervals as part of compound RTCP 339 packets (which also include SDES and possibly other messages); 340 these status reports provide an overall indication for the 341 recent reception quality of a media stream. 343 o FB messages as defined in this document that indicate loss or 344 reception of particular pieces of a media stream (or provide 345 some other form of rather immediate feedback on the data 346 received). Rules for the transmission of FB messages are newly 347 introduced in this document. 349 RTCP FB messages are just another RTCP packet type (see section 350 4). Therefore, multiple FB messages MAY be combined in a single 351 compound RTCP packet and they MAY also be sent combined with other 352 RTCP packets. 354 Compound RTCP packets containing FB messages as defined in this 355 document MUST contain RTCP packets in the order defined in [1]: 357 o OPTIONAL encryption prefix that MUST be present if the RTCP 358 packet(s) is to be encrypted according to section 9.1 of [1]. 359 o MANDATORY SR or RR. 360 o MANDATORY SDES which MUST contain the CNAME item; all other SDES 361 items are OPTIONAL. 362 o One or more FB messages. 364 The FB message(s) MUST be placed in the compound packet after RR 365 and SDES RTCP packets defined in [1]. The ordering with respect to 366 other RTCP extensions is not defined. 368 Two types of compound RTCP packets carrying feedback packets are 369 used in this document: 371 a) Minimal compound RTCP feedback packet 373 A minimal compound RTCP feedback packet MUST contain only the 374 mandatory information as listed above: encryption prefix if 375 necessary, exactly one RR or SR, exactly one SDES with only the 376 CNAME item present, and the FB message(s). This is to minimize 377 the size of the RTCP packet transmitted to convey feedback and 378 thus to maximize the frequency at which feedback can be 379 provided while still adhering to the RTCP bandwidth 380 limitations. 382 This packet format SHOULD be used whenever an RTCP FB message 383 is sent as part of an Early RTCP packet. This packet type is 384 referred to as minimal compound RTCP packet in this document. 386 b) (Full) compound RTCP feedback packet 388 A (full) compound RTCP feedback packet MAY contain any 389 additional number of RTCP packets (additional RRs, further SDES 390 items, etc.). The above ordering rules MUST be adhered to. 392 This packet format MUST be used whenever an RTCP FB message is 393 sent as part of a Regular RTCP packet or in Regular RTCP mode. 394 It MAY also be used to send RTCP FB messages in Immediate 395 Feedback or Early RTCP mode. This packet type is referred to as 396 full compound RTCP packet in this document. 398 RTCP packets that do not contain FB messages are referred to as 399 non-FB RTCP packets. Such packets MUST follow the format rules in 400 [1]. 402 3.2 Algorithm Outline 404 FB messages are part of the RTCP control streams and thus subject 405 to the RTCP bandwidth constraints. This means, in particular, that 406 it may not be possible to report an event observed at a receiver 407 immediately back to the sender. However, the value of feedback 408 given to a sender typically decreases over time -- in terms of the 409 media quality as perceived by the user at the receiving end and/or 410 the cost required to achieve media stream repair. 412 RTP [1] and the commonly used RTP profile [2] specify rules when 413 compound RTCP packets should be sent. This document modifies those 414 rules in order to allow applications to timely report events (e.g. 415 loss or reception of RTP packets) and to accommodate algorithms 416 that use FB messages. 418 The modified RTCP transmission algorithm can be outlined as 419 follows: As long as no FB messages have to be conveyed, compound 420 RTCP packets are sent following the rules of RTP [1] -- except that 421 the five second minimum interval between RTCP reports is not 422 enforced. Hence, the interval between RTCP reports is only derived 423 from the average RTCP packet size and the RTCP bandwidth share 424 available to the RTP/RTCP entity. Optionally, a minimum interval 425 between Regular RTCP packets may be enforced. 427 If a receiver detects the need to send an FB message, it may do so 428 earlier than the next regular RTCP reporting interval (for which it 429 would be scheduled following the above regular RTCP algorithm). 430 Feedback suppression is used to avoid feedback implosion in 431 multiparty sessions: The receiver waits for a (short) random 432 dithering interval to check whether it sees a corresponding FB 433 message from any other receiver reporting the same event. Note 434 that for point-to-point sessions there is no such delay. If a 435 corresponding FB message from another member is received, this 436 receiver refrains from sending the FB message and continues to 437 follow the Regular RTCP transmission schedule. In case the 438 receiver has not yet seen a corresponding FB message from any other 439 member, it checks whether it is allowed to send Early feedback. If 440 sending Early feedback is permissible , the receiver sends the FB 441 message as part of a minimal compound RTCP packet. The permission 442 to send Early feedback depends on the type of the previous RTCP 443 packet sent by this receiver and the time the previous Early 444 feedback message was sent. 446 FB messages may also be sent as part of full compound RTCP packets 447 which are transmitted as per [1] (except for the five second lower 448 bound) in regular intervals. 450 3.3 Modes of Operation 452 RTCP-based feedback may operate in one of three modes (figure 1) as 453 described below. The mode of operation is just an indication of 454 whether or not the receiver will, on average, be able to report all 455 events to the sender in a timely fashion; the mode does not 456 influence the algorithm used for scheduling the transmission of FB 457 messages. And, depending on the reception quality and the locally 458 monitored state of the RTP session, individual receivers may not 459 (and not have to) agree on a common perception on the current mode 460 of operation. 462 a) Immediate Feedback mode: the group size is below the FB 463 threshold which gives each receiving party sufficient bandwidth 464 to transmit the RTCP feedback packets for the intended purpose. 465 This means that, for each receiver, there is enough bandwidth 466 to report each event by means of a virtually "immediate" RTCP 467 feedback packet. 469 The group size threshold is a function of a number of 470 parameters including (but not necessarily limited to): the type 471 of feedback used (e.g. ACK vs. NACK), bandwidth, packet rate, 472 packet loss probability and distribution, media type, codec, 473 and the (worst case or observed) frequency of events to report 474 (e.g. frame received, packet lost). 476 As a rough estimate, let N be the average number of events to 477 be reported per interval T by a receiver, B the RTCP bandwidth 478 fraction for this particular receiver and R the average RTCP 479 packet size, then the receiver operates in Immediate Feedback 480 mode as long as N<=B*T/R. 482 b) Early RTCP mode: In this mode, the group size and other 483 parameters no longer allow each receiver to react to each event 484 that would be worth (or needed) to report. But feedback can 485 still be given sufficiently often so that it allows the sender 486 to adapt the media stream transmission accordingly and thereby 487 increase the overall media playback quality. 489 Using the above notation, Early RTCP mode can be roughly 490 characterized by N > B*T/R as "lower bound". An estimate for 491 an upper bound is more difficult. Setting N=1, we obtain for a 492 given R and B the interval T = R/B as average interval between 493 events to be reported. This information can be used as a hint 494 to determine whether or not early transmission of RTCP packets 495 is useful. 497 c) Regular RTCP Mode: From some group size upwards, it is no 498 longer useful to provide feedback for individual events from 499 receivers at all -- because of the time scale in which the 500 feedback could be provided and/or because in large groups the 501 sender(s) have no chance to react to individual feedback 502 anymore. 504 No precise group size threshold can be specified at which this 505 mode starts but, obviously, this boundary matches the upper 506 bound of the Early RTCP mode as specified in item b). 508 As the feedback algorithm described in this document scales 509 smoothly, there is no need for an agreement among the participants 510 on the precise values of the respective FB thresholds within the 511 group. Hence the borders between all these modes are soft. 513 ACK 514 feedback 515 V 516 :<- - - - NACK feedback - - - ->// 517 : 518 : Immediate || 519 : Feedback mode ||Early RTCP mode Regular RTCP mode 520 :<=============>||<=============>//<=================> 521 : || 522 -+---------------||---------------//------------------> group size 523 2 || 524 Application-specific FB Threshold 525 = f(data rate, packet loss, codec, ...) 527 Figure 1: Modes of operation 529 As stated before, the respective FB thresholds depend on a number 530 of technical parameters (of the codec, the transport, the type of 531 feedback used, etc.) but also on the respective application 532 scenarios. Section 3.6 provides some useful hints (but no precise 533 calculations) on estimating these thresholds. 535 3.4 Definitions and Algorithm Overview 537 The following pieces of state information need to be maintained per 538 receiver (largely taken from [1]). Note that all variables (except 539 in item h) below) are calculated independently at each receiver. 540 Therefore, their local values may differ at any given point in 541 time. 543 a) Let "senders" be the number of active senders in the RTP 544 session. 546 b) Let "members" be the current estimate of the number of receivers 547 in the RTP session. 549 c) Let tn and tp be the time for the next (last) scheduled 550 RTCP RR transmission calculated prior to reconsideration. 552 d) Let Tmin be the minimal interval between RTCP packets as per 553 [1]. Unlike in [1], the initial Tmin is set to 1 second to 554 allow for some group size sampling before sending the first RTCP 555 packet. After the first RTCP packet is sent, Tmin is set to 0. 557 e) Let T_rr be the interval after which, having just sent a 558 regularly scheduled RTCP packet, a receiver would schedule the 559 transmission of its next Regular RTCP packet. This value is 560 obtained following the rules of [1] but with Tmin as defined in 561 this document: T_rr = T (the "calculated interval" as defined in 562 [1]) with tn = tp + T. T_rr always refers to the last value of 563 T that has been computed (because of reconsideration or to 564 determine tn). T_rr is also referred to as Regular RTCP interval 565 in this document. 567 f) Let t0 be the time at which an event that is to be reported is 568 detected by a receiver. 570 g) Let T_dither_max be the maximum interval for which an RTCP 571 feedback packet MAY be additionally delayed to prevent 572 implosions in multiparty sessions; the value for T_dither_max is 573 dynamically calculated based upon T_rr (or may be derived by 574 means of another mechanism common across all RTP receivers to be 575 specified in the future). For point-to-point sessions (i.e. 576 sessions with exactly two members with no change in the group 577 size expected, e.g. unicast streaming sessions), T_dither_max is 578 set to 0. 580 h) Let T_max_fb_delay be the upper bound within which feedback to 581 an event needs to be reported back to the sender to be useful at 582 all. This value is application-specific; and no values are 583 defined in this document. 585 i) Let te be the time for which a feedback packet is scheduled. 587 j) Let T_fd be the actual (randomized) delay for the transmission 588 of FB message in response to an event at time t0. 590 k) Let allow_early be a Boolean variable that indicates whether the 591 receiver currently may transmit FB messages prior to its next 592 regularly scheduled RTCP interval tn. This variable is used to 593 throttle the feedback sent by a single receiver. allow_early is 594 set to FALSE after Early feedback transmission and is set to 595 TRUE as soon as the next Regular RTCP transmission takes place. 597 l) Let avg_rtcp_size be the moving average on the RTCP packet size 598 as defined in [1]. 600 m) Let T_rr_interval be an OPTIONAL minimal interval to be used 601 between Regular RTCP packets. If T_rr_interval == 0, then this 602 variable does not have any impact on the overall operation of 603 the RTCP feedback algorithm. If T_rr_interval != 0 then the 604 next Regular RTCP packet will not be scheduled T_rr after the 605 last Regular RTCP transmission (i.e. at tp+T_rr). Instead, the 606 next Regular RTCP packet will be delayed until at least 607 T_rr_interval after the last Regular RTCP transmission, i.e. it 608 will be scheduled at or later than tp+T_rr_interval. Note that 609 T_rr_interval does not affect the calculation of T_rr and tp; 610 instead, Regular RTCP packets scheduled for transmission before 611 tp+T_rr_interval will be suppressed if, for example, they do not 612 contain any FB messages. The T_rr_interval does not affect 613 transmission scheduling of Early RTCP packets. 615 NOTE: Providing T_rr_interval as an independent variable is meant 616 to minimize Regular RTCP feedback (and thus bandwidth consumption) 617 as needed by the application while additionally allowing the use of 618 more frequent Early RTCP packets to provide timely feedback. This 619 goal could not be achieved by reducing the overall RTCP bandwidth 620 as RTCP bandwidth reduction would also impact the frequency of 621 Early feedback. 623 n) Let t_rr_last be the point in time at which the last Regular 624 RTCP packet has been scheduled and sent, i.e. has not been 625 suppressed due to T_rr_interval. 627 o) Let T_retention be the time window for which past FB messages 628 are stored by an AVPF entity. This is to ensure that feedback 629 suppression also works for entities that have received FB 630 messages from other entities prior to noticing the feedback 631 event itself. T_retention MUST be set to at least 2 seconds. 633 p) Let M*Td be the timeout value for a receiver to be considered 634 inactive (as defined in [1]). 636 The feedback situation for an event to report at a receiver is 637 depicted in figure 2 below. At time t0, such an event (e.g. a 638 packet loss) is detected at the receiver. The receiver decides -- 639 based upon current bandwidth, group size, and other application- 640 specific parameters -- that a FB message needs to be sent back to 641 the sender. 643 To avoid an implosion of feedback packets in multiparty sessions, 644 the receiver MUST delay the transmission of the RTCP feedback 645 packet by a random amount of time T_fd (with the random number 646 evenly distributed in the interval [0, T_dither_max]). 647 Transmission of the compound RTCP packet MUST then be scheduled for 648 te = t0 + T_fd. 650 The T_dither_max parameter is derived from the Regular RTCP 651 interval, T_rr, which, in turn, is based upon the group size. A 652 future document may also specify other calculations for 653 T_dither_max (e.g. based upon RTT) if it can be assured that all 654 RTP receivers will use the same mechanism for calculating 655 T_dither_max. 657 For a certain application scenario, a receiver may determine an 658 upper bound for the acceptable local delay of FB messages: 659 T_max_fb_delay. If an a priori estimation or the actual 660 calculation of T_dither_max indicates that this upper bound MAY be 661 violated (e.g. because T_dither_max > T_max_fb_delay), the receiver 662 MAY decide not to send any feedback at all because the achievable 663 gain is considered insufficient. 665 If an Early RTCP packet is scheduled, the time slot for the next 666 Regular RTCP packet MUST be updated accordingly to a new tn: 667 tn=tp+2*T_rr and so MUST tp: tp=tp+T_rr afterwards. This is to 668 ensure that the short-term average RTCP bandwidth used with Early 669 feedback does not exceed the bandwidth used without Early feedback. 671 event to 672 report 673 detected 674 | 675 | RTCP feedback range 676 | (T_max_fb_delay) 677 vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) ) 678 |---+--------+-------------+-----+------------| |--------+---> 679 | | | | ( ( | 680 | t0 te | 681 tp tn 682 \_______ ________/ 683 \/ 684 T_dither_max 686 Figure 2: Event report and parameters for Early RTCP scheduling 688 3.5 AVPF RTCP Scheduling Algorithm 690 Let S0 be an active sender (out of S senders) and let N be the 691 number of receivers with R being one of these receivers. 693 Assume that R has verified that using feedback mechanisms is 694 reasonable at the current constellation (which is highly 695 application specific and hence not specified in this document). 697 Assume further that T_rr_interval is 0, if no minimal interval 698 between Regular RTCP packets is to be enforced, or T_rr_interval is 699 set to some meaningful value, as given by the application. This 700 value then denotes the minimal interval between Regular RTCP 701 packets. 703 With this, a receiver R MUST use the following rules for 704 transmitting one or more FB messages as minimal or full compound 705 RTCP packet: 707 3.5.1 Initialization 708 Initially, R MUST set allow_early = TRUE and t_rr_last = NaN (Not- 709 a-Number, i.e. some invalid value that can be distinguished from a 710 valid time). 712 Furthermore, the initialization of the RTCP variables as per [1] 713 applies except that the initial value for Tmin. For a point-to- 714 point session, the initial Tmin is set to 0. For a multiparty 715 session, Tmin is initialized to 1.0 seconds. 717 3.5.2 Early Feedback Transmission 719 Assume that R had scheduled the last Regular RTCP RR packet for 720 transmission at tp (and sent or suppressed this packet at tp) and 721 has scheduled the next transmission (including possible 722 reconsideration as per [1]) for tn = tp + T_rr. Assume also that 723 the last Regular RTCP packet transmission has occurred at 724 t_rr_last. 726 The Early Feedback algorithm then comprises the following steps: 728 1. At time t0, R detects the need to transmit one or more FB 729 messages, e.g. because media "units" need to be ACKed or NACKed, 730 and finds that providing the feedback information is potentially 731 useful for the sender. 733 2. R first checks whether there is already a compound RTCP packet 734 containing one or more FB messages scheduled for transmission 735 (either as Early or as Regular RTCP packet). 737 2.a) If so, the new FB message MUST be included in the 738 scheduled packet; the scheduling of the waiting compound RTCP 739 packet MUST remain unchanged. When doing so, the available 740 feedback information SHOULD be merged to produce as few FB 741 messages as possible. This completes the course of immediate 742 actions to be taken. 744 2.b) If no compound RTCP packet is already scheduled for 745 transmission, a new (minimal or full) compound RTCP packet 746 MUST be created and the minimal interval for T_dither_max MUST 747 be chosen as follows: 749 i) If the session is a point-to-point session then 750 T_dither_max = 0. 752 ii) If the session is a multiparty session then 754 T_dither_max = l * T_rr 756 with l=0.5. 758 The value for T_dither_max MAY be calculated differently (e.g. 759 based upon RTT) which MUST then be specified in a future 760 document. Such a future specification MUST ensure that all 761 RTP receivers use the same mechanism to calculate 762 T_dither_max. 764 The values given above for T_dither_max are minimal values. 765 Application-specific feedback considerations may make it 766 worthwhile to increase T_dither_max beyond this value. This 767 is up to the discretion of the implementer. 769 3. Then, R MUST check whether its next Regular RTCP packet would be 770 within the time bounds for the Early RTCP packet triggered at t0, 771 i.e. if t0 + T_dither_max > tn. 773 3.a) If so, an Early RTCP packet MUST NOT be scheduled; 774 instead the FB message(s) MUST be stored to be included in the 775 Regular RTCP packet scheduled for tn. This completes the 776 course of immediate actions to be taken. 778 3.b) Otherwise, the following steps are carried out. 780 4. R MUST check whether it is allowed to transmit an Early RTCP 781 packet, i.e. allow_early == TRUE, or not. 783 4.a) If allow_early == FALSE then R MUST check the time for the 784 next scheduled Regular RTCP packet: 786 1. If tn - t0 < T_max_fb_delay then the feedback could 787 still be useful for the sender, despite the late 788 reporting. Hence, R MAY create an RTCP FB message to 789 be included in the Regular RTCP packet for 790 transmission at tn. 792 2. Otherwise, R MUST discard the RTCP FB message. 794 This completes the immediate course of actions to be taken. 796 4.b) If allow_early == TRUE then R MUST schedule an Early RTCP 797 packet for te = t0 + RND * T_dither_max with RND being a pseudo 798 random function evenly distributed between 0 and 1. 800 5. R MUST detect overlaps in FB messages received from other 801 members of the RTP session and the FB messages R wants to send. 802 Therefore, while member of the RTP session, R MUST continuously 803 monitor the arrival of (minimal) compound RTCP packets and store 804 each FB message contained in these RTCP packets for at least 805 T_retention. When scheduling the transmission of its own FB 806 message following steps 1. through 4. above, R MUST check each of 807 the stored and newly received FB messages from the RTCP packets 808 received during the interval [t0 - T_retention ; te] and act as 809 follows: 811 5.a) If R understands the received FB message's semantics and 812 the message contents is a superset of the feedback R wanted to 813 send then R MUST discard its own FB message and MUST re- 814 schedule the next Regular RTCP packet transmission for tn (as 815 calculated before). 817 5.b) If R understands the received FB message's semantics and 818 the message contents is not a superset of the feedback R wanted 819 to send then R SHOULD transmit its own FB message as scheduled. 820 If there is an overlap between the feedback information to send 821 and the feedback information received, the amount of feedback 822 transmitted is up to R: R MAY leave its feedback information to 823 be sent unchanged, R MAY as well eliminate any redundancy 824 between its own feedback and the feedback received so far from 825 other session members. 827 5.c) If R does not understand the received FB message's 828 semantics, R MAY keep its own FB message scheduled as an Early 829 RTCP packet, or R MAY re-schedule the next Regular RTCP packet 830 transmission for tn (as calculated before) and MAY append the 831 FB message to the now regularly scheduled RTCP message. 833 Note: With 5.c), receiving unknown FB messages may not lead to 834 feedback suppression at a particular receiver. As a 835 consequence, a given event may cause M different types of FB 836 messages (which are all appropriate but not mutually 837 understood) to be scheduled, so that a "large" receiver group 838 may effectively be partitioned into at most M groups. Among 839 members of each of these M groups, feedback suppression will 840 occur following 5.a and 5.b but no suppression will happen 841 across groups. As a result, O(M) RTCP FB messages may be 842 received by the sender. Hence, there is a chance for a very 843 limited feedback implosion. However, as sender(s) and all 844 receivers make up the same application using the same (set of) 845 codecs in the same RTP session, only little divergence in 846 semantics for FB messages can safely be assumed and, therefore, 847 M is assumed to be small in the general case. Given further 848 that the O(M) FB messages are randomly distributed over a time 849 interval of T_dither_max we find that the resulting limited 850 number of extra compound RTCP packets (a) is assumed not to 851 overwhelm the sender and (b) should be conveyed as all contain 852 complementary pieces of information. 854 6. If R's FB message(s) was not suppressed by other receiver FB 855 messages as per 5., when te is reached, R MUST transmit the 856 (minimal) compound RTCP packet containing its FB message(s). R 857 then MUST set allow_early = FALSE, MUST recalculate tn = tp + 858 2*T_rr, and MUST set tp to the previous tn. As soon as the newly 859 calculated tn is reached, regardless whether R sends its next 860 Regular RTCP packet or suppresses it because of T_rr_interval, it 861 MUST set allow_early = TRUE again. 863 3.5.3 Regular RTCP Transmission 865 Full compound RTCP packets MUST be sent in regular intervals. 866 These packets MAY also contain one or more FB messages. 867 Transmission of Regular RTCP packets is scheduled as follows: 869 If T_rr_interval == 0 then the transmission MUST follow the rules 870 as specified in section 3.2 and 3.4 of this document and MUST 871 adhere to the adjustments of tn specified in section 3.5.2, i.e. 872 skip one regular transmission if an Early RTCP packet transmission 873 has occurred. Timer reconsideration takes place when tn is reached 874 as per [1]. The Regular RTCP packet is transmitted after timer 875 reconsideration. Whenever a Regular RTCP packet is sent or 876 suppressed, allow_early MUST be set to TRUE and tp, tn MUST be 877 updated as per [1]. After the first transmission of a Regular RTCP 878 packet, Tmin MUST be set to 0. 880 If T_rr_interval != 0 then the calculation for the transmission 881 times MUST follow the rules as specified in section 3.2 and 3.4 of 882 this document and MUST adhere to the adjustments of tn specified in 883 section 3.5.2 (i.e. skip one regular transmission if an Early RTCP 884 transmission has occurred). Timer reconsideration takes place when 885 tn is reached as per [1]. After timer reconsideration, the 886 following actions are taken: 888 1. If no Regular RTCP packet has been sent before (i.e. if 889 t_rr_last == NaN) then a Regular RTCP packet MUST be 890 scheduled. Stored FB messages MAY be included in the 891 Regular RTCP packet. After the scheduled packet has been 892 sent, t_rr_last MUST be set to tn. Tmin MUST be set to 0. 894 2. Otherwise, a temporary value T_rr_current_interval is 895 calculated as follows: 897 T_rr_current_interval = RND*T_rr_interval 899 with RND being a pseudo random function evenly distributed 900 between 0.5 and 1.5. This dithered value is used to 901 determine one of the following alternatives: 903 2a) If t_rr_last + T_rr_current_interval <= tn then a 904 Regular RTCP packet MUST be scheduled. Stored RTCP FB 905 messages MAY be included in the Regular RTCP packet. 907 After the scheduled packet has been sent, t_rr_last 908 MUST be set to tn. 910 2b) If t_rr_last + T_rr_current_interval > tn and RTCP FB 911 messages have been stored and are awaiting 912 transmission, an RTCP packet MUST be scheduled for 913 transmission at tn. This RTCP packet MAY be a minimal 914 or a Regular RTCP packet (at the discretion of the 915 implementer) and the compound RTCP packet MUST include 916 the stored RTCP FB message(s). t_rr_last MUST remain 917 unchanged. 919 2c) Otherwise (if t_rr_last + T_rr_current_interval > tn 920 but no stored RTCP FB messages are awaiting 921 transmission), the compound RTCP packet MUST be 922 suppressed (i.e. it MUST NOT be scheduled). t_rr_last 923 MUST remain unchanged. 925 In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST 926 be set to TRUE (possibly after sending the Regular RTCP packet) and 927 tp and tn MUST be updated following the rules of [1] except for the 928 five second minimum. 930 3.5.4 Other Considerations 932 If T_rr_interval != 0 then the timeout calculation for RTP/AVPF 933 entities (section 6.3.5 of [1]) MUST be modified to use 934 T_rr_interval instead of Tmin for computing Td and thus M*Td. 936 Whenever a compound RTCP packet is sent or received -- minimal or 937 full compound, Early or Regular -- the avg_rtcp_size variable MUST 938 be updated accordingly (see [1]) and subsequent computations of tn 939 MUST use the new avg_rtcp_size. 941 3.6 Considerations on the Group Size 943 This section provides some guidelines to the group sizes at which 944 the various feedback modes may be used. 946 3.6.1 ACK mode 948 The RTP session MUST have exactly two members and this group size 949 MUST NOT grow, i.e. it MUST be point-to-point communications. 950 Unicast addresses SHOULD be used in the session description. 952 For unidirectional as well as bi-directional communication between 953 two parties, 2.5% of the RTP session bandwidth is available for 954 RTCP traffic from the receivers including feedback. For a 64 955 kbit/s stream this yields 1,600 bit/s for RTCP. If we assume an 956 average of 96 bytes (=768 bits) per RTCP packet a receiver can 957 report 2 events per second back to the sender. If acknowledgments 958 for 10 events are collected in each FB message then 20 events can 959 be acknowledged per second. At 256 kbit/s, 8 events could be 960 reported per second; thus the ACKs may be sent in a finer 961 granularity (e.g. only combining three ACKs per FB message). 963 From 1 Mbit/s upwards, a receiver would be able to acknowledge each 964 individual frame (not packet!) in a 30 fps video stream. 966 ACK strategies MUST be defined to work properly with these 967 bandwidth limitations. An indication whether or not ACKs are 968 allowed for a session and, if so, which ACK strategy should be 969 used, MAY be conveyed by out-of-band mechanisms, e.g. media- 970 specific attributes in a session description using SDP. 972 3.6.2 NACK mode 974 Negative acknowledgements (and other types of feedback exhibiting 975 similar reporting characteristics) MUST be used for all sessions 976 with a group size that may grow larger than two. Of course, NACKs 977 MAY be used for point-to-point communications as well. 979 Whether or not the use of Early RTCP packets should be considered 980 depends upon a number of parameters including session bandwidth, 981 codec, special type of feedback, number of senders and receivers. 983 The most important parameters when determining the mode of 984 operation are the allowed minimal interval between two compound 985 RTCP packets (T_rr) and the average number of events that 986 presumably need reporting per time interval (plus their 987 distribution over time, of course). The minimum interval can be 988 derived from the available RTCP bandwidth and the expected average 989 size of an RTCP packet. The number of events to report e.g. per 990 second may be derived from the packet loss rate and sender's rate 991 of transmitting packets. From these two values, the allowable 992 group size for the Immediate Feedback mode can be calculated. 994 Let N be the average number of events to be reported per 995 interval T by a receiver, B the RTCP bandwidth fraction for 996 this particular receiver and R the average RTCP packet size, 997 then the receiver operates in Immediate Feedback mode as long 998 as N<=B*T/R. 1000 The upper bound for the Early RTCP mode then solely depends on the 1001 acceptable quality degradation, i.e. how many events per time 1002 interval may go unreported. 1004 Using the above notation, Early RTCP mode can be roughly 1005 characterized by N > B*T/R as "lower bound". An estimate for 1006 an upper bound is more difficult. Setting N=1, we obtain for a 1007 given R and B the interval T = R/B as average interval between 1008 events to be reported. This information can be used as a hint 1009 to determine whether or not early transmission of RTCP packets 1010 is useful. 1012 Example: If a 256kbit/s video with 30 fps is transmitted through a 1013 network with an MTU size of some 1,500 bytes, then, in most cases, 1014 each frame would fit in into one packet leading to a packet rate of 1015 30 packets per second. If 5% packet loss occurs in the network 1016 (equally distributed, no inter-dependence between receivers), then 1017 each receiver will, on average, have to report 3 packets lost each 1018 two seconds. Assuming a single sender and more than three 1019 receivers, this yields 3.75% of the RTCP bandwidth allocated to the 1020 receivers and thus 9.6kbit/s. Assuming further a size of 120 bytes 1021 for the average compound RTCP packet allows 10 RTCP packets to be 1022 sent per second or 20 in two seconds. If every receiver needs to 1023 report three lost packets per two seconds, this yields a maximum 1024 group size of 6-7 receivers if all loss events shall be reported. 1025 The rules for transmission of Early RTCP packets should provide 1026 sufficient flexibility for most of this reporting to occur in a 1027 timely fashion. 1029 Extending this example to determine the upper bound for Early RTCP 1030 mode could lead to the following considerations: assume that the 1031 underlying coding scheme and the application (as well as the 1032 tolerant users) allow on the order of one loss without repair per 1033 two seconds. Thus the number of packets to be reported by each 1034 receiver decreases to two per two seconds second and increases the 1035 group size to 10. Assuming further that some number of packet 1036 losses are correlated, feedback traffic is further reduced and 1037 group sizes of some 12 to 16 (maybe even 20) can be reasonably well 1038 supported using Early RTCP mode. Note that all these 1039 considerations are based upon statistics and will fail to hold in 1040 some cases. 1042 3.7 Summary of decision steps 1044 3.7.1 General Hints 1046 Before even considering whether or not to send RTCP feedback 1047 information an application has to determine whether this mechanism 1048 is applicable: 1050 1) An application has to decide whether -- for the current ratio of 1051 packet rate with the associated (application-specific) maximum 1052 feedback delay and the currently observed round-trip time (if 1053 available) -- feedback mechanisms can be applied at all. 1055 This decision may be based upon (and dynamically revised 1056 following) RTCP reception statistics as well as out-of-band 1057 mechanisms. 1059 2) The application has to decide -- for a certain observed error 1060 rate, assigned bandwidth, frame/packet rate, and group size -- 1061 whether (and which) feedback mechanisms can be applied. 1063 Regular RTCP reception statistics provide valuable input to this 1064 step, too. 1066 3) If the application decides to send feedback, the application has 1067 to follow the rules for transmitting Early RTCP packets or 1068 Regular RTCP packets containing FB messages. 1070 4) The type of RTCP feedback sent should not duplicate information 1071 available to the sender from a lower layer transport protocol. 1072 That is, if the transport protocol provides negative or positive 1073 acknowledgements about packet reception (such as DCCP), the 1074 receiver should avoid repeating the same information at the RTCP 1075 layer (i.e. abstain from sending Generic NACKs). 1077 3.7.2 Media Session Attributes 1079 Media sessions are typically described using out-of-band mechanisms 1080 to convey transport addresses, codec information, etc. between 1081 sender(s) and receiver(s). Such a mechanism is two-fold: a format 1082 used to describe a media session and another mechanism for 1083 transporting this description. 1085 In the IETF, the Session Description Protocol (SDP) is currently 1086 used to describe media sessions while protocols such as SIP, SAP, 1087 RTSP, and HTTP (among others) are used to convey the descriptions. 1089 A media session description format MAY include parameters to 1090 indicate that RTCP feedback mechanisms are supported in this 1091 session and which of the feedback mechanisms MAY be applied. 1093 To do so, the profile "AVPF" MUST be indicated instead of "AVP". 1094 Further attributes may be defined to show which type(s) of feedback 1095 are supported. 1097 Section 4 contains the syntax specification to support RTCP 1098 feedback with SDP. Similar specifications for other media session 1099 description formats are outside the scope of this document. 1101 4 SDP Definitions 1103 This section defines a number of additional SDP parameters that are 1104 used to describe a session. All of these are defined as media 1105 level attributes. 1107 4.1 Profile identification 1109 The AV profile defined in [4] is referred to as "AVP" in the 1110 context of e.g. the Session Description Protocol (SDP) [3]. The 1111 profile specified in this document is referred to as "AVPF". 1113 Feedback information following the modified timing rules as 1114 specified in this document MUST NOT be sent for a particular media 1115 session unless the description for this session indicates the use 1116 of the "AVPF" profile (exclusively or jointly with other AV 1117 profiles). 1119 4.2 RTCP Feedback Capability Attribute 1121 A new payload format-specific SDP attribute is defined to indicate 1122 the capability of using RTCP feedback as specified in this 1123 document: "a=rtcp-fb". The "rtcp-fb" attribute MUST only be used 1124 as an SDP media attribute and MUST NOT be provided at the session 1125 level. The "rtcp-fb" attribute MUST only be used in media sessions 1126 for which the "AVPF" is specified. 1128 The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB 1129 messages MAY be used in this media session for the indicated 1130 payload type. A wildcard payload type ("*") MAY be used to 1131 indicate that the RTCP feedback attribute applies to all payload 1132 types. If several types of feedback are supported and/or the same 1133 feedback shall be specified for a subset of the payload types, 1134 several "a=rtcp-fb" lines MUST be used. 1136 If no "rtcp-fb" attribute is specified the RTP receivers MAY send 1137 feedback using other suitable RTCP feedback packets as defined for 1138 the respective media type. The RTP receivers MUST NOT rely on the 1139 RTP senders reacting to any of the FB messages. The RTP sender MAY 1140 choose to ignore some feedback messages. 1142 If one or more "rtcp-fb" attributes are present in a media session 1143 description, the RTCP receivers for the media session(s) containing 1144 the "rtcp-fb" 1146 o MUST ignore all "rtcp-fb" attributes of which they do not fully 1147 understand the semantics (i.e. where they do not understand the 1148 meaning of all values in the "a=rtcp-fb" line); 1150 o SHOULD provide feedback information as specified in this 1151 document using any of the RTCP feedback packets as specified in 1152 one of the "rtcp-fb" attributes for this media session; and 1154 o MUST NOT use other FB messages than those listed in one of the 1155 "rtcp-fb" attribute lines. 1157 When used in conjunction with the offer/answer model [9], the 1158 offerer MAY present a set of these AVPF attributes to its peer. 1159 The answerer MUST remove all attributes it does not understand as 1160 well as those it does not support in general or does not wish to 1161 use in this particular media session. The answerer MUST NOT add 1162 feedback parameters to the media description and MUST NOT alter 1163 values of such parameters. The answer is binding for the media 1164 session and both offerer and answerer MUST only use feedback 1165 mechanisms negotiated in this way. Both offerer and answerer MAY 1166 independently decide to send RTCP FB messages of only a subset of 1167 the negotiated feedback mechanisms; but they SHOULD react properly 1168 to all types of the negotiated FB messages when received. 1170 RTP senders MUST be prepared to receive any kind of RTCP FB 1171 messages and MUST silently discard all those RTCP FB messages that 1172 they do not understand. 1174 The syntax of the "rtcp-fb" attribute is as follows (the feedback 1175 types and optional parameters are all case sensitive): 1177 (In the following ABNF, fmt, SP and CRLF are used as defined in 1178 [3].) 1180 rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF 1182 rtcp-fb-pt = "*" ; wildcard: applies to all formats 1183 / fmt ; as defined in SDP spec 1185 rtcp-fb-val = "ack" rtcp-fb-ack-param 1186 / "nack" rtcp-fb-nack-param 1187 / "trr-int" SP 1*DIGIT 1188 / rtcp-fb-id rtcp-fb-param 1190 rtcp-fb-id = 1*(alpha-numeric / "-" / "_") 1192 rtcp-fb-param = SP "app" [SP byte-string] 1193 / SP token [SP byte-string] 1194 / ; empty 1196 rtcp-fb-ack-param = SP "rpsi" 1197 / SP "app" [SP byte-string] 1198 / SP token [SP byte-string] 1199 / ; empty 1201 rtcp-fb-nack-param = SP "pli" 1202 / SP "sli" 1203 / SP "rpsi" 1204 / SP "app" [SP byte-string] 1205 / SP token [SP byte-string] 1206 / ; empty 1208 The literals of the above grammar have the following semantics: 1210 Feedback type "ack": 1212 This feedback type indicates that positive acknowledgements 1213 for feedback are supported. 1215 The feedback type "ack" MUST only be used if the media session 1216 is allowed to operate in ACK mode as defined in 3.6.1.2. 1218 Parameters MUST be provided to further distinguish different 1219 types of positive acknowledgement feedback. 1221 The parameter "rpsi" indicates the use of Reference Picture 1222 Selection Indication feedback as defined in section 6.3.3. 1224 If the parameter "app" is specified, this indicates the use of 1225 application layer feedback. In this case, additional 1226 parameters following "app" MAY be used to further 1227 differentiate various types of application layer feedback. 1228 This document does not define any parameters specific to 1229 "app". 1231 Further parameters for "ack" MAY be defined in other 1232 documents. 1234 Feedback type "nack": 1236 This feedback type indicates that negative acknowledgements 1237 for feedback are supported. 1239 The feedback type "nack", without parameters, indicates use of 1240 the General NACK feedback format as defined in section 6.2.1. 1242 The following three parameters are defined in this document 1243 for use with "nack" in conjunction with the media type 1244 "video": 1246 o "pli" indicates the use of Picture Loss Indication feedback 1247 as defined in section 6.3.1. 1248 o "sli" indicates the use of Slice Loss Indication feedback 1249 as defined in section 6.3.2. 1250 o "rpsi" indicates the use of Reference Picture Selection 1251 Indication feedback as defined in section 6.3.3. 1253 "app" indicates the use of application layer feedback. 1254 Additional parameters after "app" MAY be provided to 1255 differentiate different types of application layer feedback. 1256 No parameters specific to "app" are defined in this document. 1258 Further parameters for "nack" MAY be defined in other 1259 documents. 1261 Other feedback types : 1263 Other documents MAY define additional types of feedback; to 1264 keep the grammar extensible for those cases, the rtcp-fb-id is 1265 introduced as a placeholder. A new feedback scheme name MUST 1266 to be unique (and thus MUST be registered with IANA). Along 1267 with a new name, its semantics, packet formats (if necessary), 1268 and rules for its operation MUST be specified. 1270 Regular RTCP minimum interval "trr-int": 1272 The attribute "trr-int" is used to specify the minimum 1273 interval T_rr_interval between two Regular (full compound) 1274 RTCP packets in milliseconds for this media session. If "trr- 1275 int" is not specified, a default value of 0 is assumed. 1277 Note that it is assumed that more specific information about 1278 application layer feedback (as defined in section 6.4) will be 1279 conveyed as feedback types and parameters defined elsewhere. 1280 Hence, no further provision for any types and parameters is made in 1281 this document. 1283 Further types of feedback as well as further parameters may be 1284 defined in other documents. 1286 It is up to the recipients whether or not they send feedback 1287 information and up to the sender(s) (how) to make use of feedback 1288 provided. 1290 4.3 RTCP Bandwidth Modifiers 1292 The standard RTCP bandwidth assignments as defined in [1] and [2] 1293 MAY be overridden by bandwidth modifiers that explicitly define the 1294 maximum RTCP bandwidth. For use with SDP, such modifiers are 1295 specified in [4]: "b=RS:" and "b=RR:" MAY be used to assign 1296 a different bandwidth (measured in bits per second) to RTP senders 1297 and receivers, respectively. The precedence rules of [4] apply to 1298 determine the actual bandwidth to be used by senders and receivers. 1300 Applications operating knowingly over highly asymmetric links (such 1301 as satellite links) SHOULD use this mechanism to reduce the 1302 feedback rate for high bandwidth streams to prevent deterministic 1303 congestion of the feedback path(s). 1305 4.4 Examples 1307 Example 1: The following session description indicates a session 1308 made up from audio and DTMF [18] for point-to-point communication 1309 in which the DTMF stream uses Generic NACKs. This session 1310 description could be contained in a SIP INVITE, 200 OK, or ACK 1311 message to indicate that its sender is capable of and willing to 1312 receive feedback for the DTMF stream it transmits. 1314 v=0 1315 o=alice 3203093520 3203093520 IN IP4 host.example.com 1316 s=Media with feedback 1317 t=0 0 1318 c=IN IP4 host.example.com 1319 m=audio 49170 RTP/AVPF 0 96 1320 a=rtpmap:0 PCMU/8000 1321 a=rtpmap:96 telephone-event/8000 1322 a=fmtp:96 0-16 1323 a=rtcp-fb:96 nack 1325 This allows sender and receiver to provide reliable transmission of 1326 DTMF events in an audio session. Assuming a 64kbit/s audio stream 1327 with one receiver, the receiver has 2.5% RTCP bandwidth available 1328 for the negative acknowledgment stream, i.e. 250 bytes per second 1329 or some 2 RTCP feedback messages every second. Hence, the receiver 1330 can individually communicate up to two missing DTMF audio packets 1331 per second. 1333 Example 2: The following session description indicates a multicast 1334 video-only session (using either H.261 or H.263+) with the video 1335 source accepting Generic NACKs for both codecs and Reference 1336 Picture Selection for H.263. Such a description may have been 1337 conveyed using the Session Announcement Protocol (SAP). 1339 v=0 1340 o=alice 3203093520 3203093520 IN IP4 host.example.com 1341 s=Multicast video with feedback 1342 t=3203130148 3203137348 1343 m=audio 49170 RTP/AVP 0 1344 c=IN IP4 224.2.1.183 1345 a=rtpmap:0 PCMU/8000 1346 m=video 51372 RTP/AVPF 98 99 1347 c=IN IP4 224.2.1.184 1348 a=rtpmap:98 H263-1998/90000 1349 a=rtpmap:99 H261/90000 1350 a=rtcp-fb:* nack 1351 a=rtcp-fb:98 nack rpsi 1353 The sender may use an incoming Generic NACK as a hint to send a new 1354 intra-frame as soon as possible (congestion control permitting). 1355 Receipt of an RPSI message allows the sender to avoid sending a 1356 large intra-frame; instead it may continue to send inter-frames, 1357 however, choosing the indicated frame as new encoding reference. 1359 Example 3: The following session description defines the same media 1360 session as example 2 but allows for mixed mode operation of AVP and 1361 AVPF RTP entities (see also next section). Note that both media 1362 descriptions use the same addresses; however, two m= lines are 1363 needed to convey information about both applicable RTP profiles. 1365 v=0 1366 o=alice 3203093520 3203093520 IN IP4 host.example.com 1367 s=Multicast video with feedback 1368 t=3203130148 3203137348 1369 m=audio 49170 RTP/AVP 0 1370 c=IN IP4 224.2.1.183 1371 a=rtpmap:0 PCMU/8000 1372 m=video 51372 RTP/AVP 98 99 1373 c=IN IP4 224.2.1.184 1374 a=rtpmap:98 H263-1998/90000 1375 a=rtpmap:99 H261/90000 1376 m=video 51372 RTP/AVPF 98 99 1377 c=IN IP4 224.2.1.184 1378 a=rtpmap:98 H263-1998/90000 1379 a=rtpmap:99 H261/90000 1380 a=rtcp-fb:* nack 1381 a=rtcp-fb:98 nack rpsi 1383 Note that these two m= lines SHOULD be grouped by some appropriate 1384 mechanism to indicate that both are alternatives actually conveying 1385 the same contents. A sample mechanism by which this can be 1386 achieved is defined in [7]. 1388 In this example, the RTCP feedback-enabled receivers will gain an 1389 occasional advantage to report events earlier back to the sender 1390 (which may benefit the entire group). On average, however, all RTP 1391 receivers will provide the same amount of feedback. The 1392 interworking between AVP and AVPF entities is discussed in depth in 1393 the next section. 1395 5 Interworking and Co-Existence of AVP and AVPF Entities 1397 The AVPF profile defined in this document is an extension of the 1398 AVP profile as defined in [2]. Both profiles follow the same basic 1399 rules (including the upper bandwidth limit for RTCP and the 1400 bandwidth assignments to senders and receivers). Therefore, 1401 senders and receivers of using either of the two profiles can be 1402 mixed in a single session (see e.g. example 3 in section 4.5). 1404 AVP and AVPF are defined in a way that, from a robustness point of 1405 view, the RTP entities do not need to be aware of entities of the 1406 respective other profile: they will not disturb each other's 1407 functioning. However, the quality of the media presented may 1408 suffer. 1410 The following considerations apply to senders and receivers when 1411 used in a combined session. 1413 o AVP entities (senders and receivers) 1415 AVP senders will receive RTCP feedback packets from AVPF 1416 receivers and ignore these packets. They will see occasional 1417 closer spacing of RTCP messages (e.g. violating the five second 1418 rule) by AVPF entities. As the overall bandwidth constraints 1419 are adhered to by both types of entities, they will still get 1420 their share of the RTCP bandwidth. However, while AVP entities 1421 are bound by the five second rule, depending on the group size 1422 and session bandwidth, AVPF entities may provide more frequent 1423 RTCP reports than AVP ones will. Also, the overall reporting 1424 may decrease slightly as AVPF entities may send bigger compound 1425 RTCP packets (due to the extra RTCP packets). 1427 If T_rr_interval is used as lower bound between Regular RTCP 1428 packets, T_rr_interval is sufficiently large (e.g. T_rr_interval 1429 > M*Td as per section 6.3.5 of [1]), and no Early RTCP packets 1430 are sent by AVPF entities, AVP entities may accidentally time 1431 out those AVPF group members and hence under-estimate the group 1432 size. Therefore, if AVP entities may be involved in a media 1433 session, T_rr_interval SHOULD NOT be larger than five seconds. 1435 o AVPF entities (senders and receivers) 1437 If the dynamically calculated T_rr is sufficiently small (e.g. 1438 less than one second), AVPF entities may accidentally time out 1439 AVP group members and hence under-estimate the group size. 1440 Therefore, if AVP entities may be involved in a media session, 1441 T_rr_interval SHOULD be used and SHOULD be set to five seconds. 1443 In conclusion, if AVP entities may be involved in a media 1444 session and T_rr_interval is to be used, T_rr_interval SHOULD be 1445 set to five seconds. 1447 o AVPF senders 1449 AVPF senders will receive feedback information only from AVPF 1450 receivers. If they rely on feedback to provide the target media 1451 quality, the quality achieved for AVP receivers may be sub- 1452 optimal. 1454 o AVPF receivers 1456 AVPF receivers SHOULD send Early RTCP feedback packets only if 1457 all sending entities in the media session support AVPF. AVPF 1458 receivers MAY send feedback information as part of regularly 1459 scheduled compound RTCP packets following the timing rules of 1460 [1] and [2] also in media sessions operating in mixed mode. 1461 However, the receiver providing feedback MUST NOT rely on the 1462 sender reacting to the feedback at all. 1464 6 Format of RTCP Feedback Messages 1466 This section defines the format of the low delay RTCP feedback 1467 messages. These messages are classified into three categories as 1468 follows: 1470 - Transport layer FB messages 1471 - Payload-specific FB messages 1472 - Application layer FB messages 1474 Transport layer FB messages are intended to transmit general 1475 purpose feedback information, i.e. information independent of the 1476 particular codec or the application in use. The information is 1477 expected to be generated and processed at the transport/RTP layer. 1478 Currently, only a generic negative acknowledgement (NACK) message 1479 is defined. 1481 Payload-specific FB messages transport information that is specific 1482 to a certain payload type and will be generated and acted upon at 1483 the codec "layer". This document defines a common header to be 1484 used in conjunction with all payload-specific FB messages. The 1485 definition of specific messages is left to either RTP payload 1486 format specifications or to additional feedback format documents. 1488 Application layer FB messages provide a means to transparently 1489 convey feedback from the receiver's to the sender's application. 1490 The information contained in such a message is not expected to be 1491 acted upon at the transport/RTP or the codec layer. The data to be 1492 exchanged between two application instances is usually defined in 1493 the application protocol specification and thus can be identified 1494 by the application so that there is no need for additional external 1495 information. Hence, this document defines only a common header to 1496 be used along with all application layer FB messages. From a 1497 protocol point of view, an application layer FB message is treated 1498 as a special case of a payload-specific FB message. 1500 NOTE: Proper processing of some FB messages at the media 1501 sender side may require the sender to know which payload type 1502 the FB message refers to. Most of the time, this knowledge 1503 can likely be derived from a media stream using only a single 1504 payload type. However, if several codecs are used 1505 simultaneously (e.g. with audio and DTMF) or when codec 1506 changes occur, the payload type information may need to be 1507 conveyed explicitly as part of the FB message. This applies 1508 to all payload-specific as well as application layer FB 1509 messages. It is up to the specification of a FB message to 1510 define how payload type information is transmitted. 1512 This document defines two transport layer and three (video) 1513 payload-specific FB messages as well as a single container for 1514 application layer FB messages. Additional transport layer and 1515 payload specific FB messages MAY be defined in other documents and 1516 MUST be registered through IANA (see section IANA considerations). 1518 The general syntax and semantics for the above RTCP FB message 1519 types are described in the following subsections. 1521 6.1 Common Packet Format for Feedback Messages 1523 All FB messages MUST use a common packet format that is depicted in 1524 figure 3: 1526 0 1 2 3 1527 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 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 |V=2|P| FMT | PT | length | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | SSRC of packet sender | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | SSRC of media source | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 : Feedback Control Information (FCI) : 1536 : : 1538 Figure 3: Common Packet Format for Feedback Messages 1540 The various fields V, P, SSRC and length are defined in the RTP 1541 specification [2], the respective meaning being summarized below: 1543 version (V): 2 bits 1544 This field identifies the RTP version. The current version is 1545 2. 1547 padding (P): 1 bit 1548 If set, the padding bit indicates that the packet contains 1549 additional padding octets at the end which are not part of the 1550 control information but are included in the length field. 1552 Feedback message type (FMT): 5 bits 1553 This field identifies the type of the FB message and is 1554 interpreted relative to the type (transport, payload-specific, 1555 or application layer feedback). The values for each of the 1556 three feedback types are defined in the respective sections 1557 below. 1559 Payload type (PT): 8 bits 1560 This is the RTCP packet type which identifies the packet as 1561 being an RTCP FB message. Two values are defined (TBA. by 1562 IANA): 1564 Name | Value | Brief Description 1565 ----------+-------+------------------------------------ 1566 RTPFB | 205 | Transport layer FB message 1567 PSFB | 206 | Payload-specific FB message 1569 Length: 16 bits 1570 The length of this packet in 32-bit words minus one, including 1571 the header and any padding. This is in line with the 1572 definition of the length field used in RTCP sender and receiver 1573 reports [3]. 1575 SSRC of packet sender: 32 bits 1576 The synchronization source identifier for the originator of 1577 this packet. 1579 SSRC of media source: 32 bits 1580 The synchronization source identifier of the media source that 1581 this piece of feedback information is related to. 1583 Feedback Control Information (FCI): variable length 1584 The following three sections define which additional 1585 information MAY be included in the FB message for each type of 1586 feedback: transport layer, payload-specific or application 1587 layer feedback. Note that further FCI contents MAY be specified 1588 in further documents. 1590 Each RTCP feedback packet MUST contain at least one FB message in 1591 the FCI field. Sections 6.2 and 6.3 define for each FCI type, 1592 whether or not multiple FB messages MAY be compressed into a single 1593 FCI field. If this is the case, they MUST be of the same type, 1594 i.e. same FMT. If multiple types of feedback messages, i.e. 1595 several FMTs, need to be conveyed, then several RTCP FB messages 1596 MUST be generated and SHOULD be concatenated in the same compound 1597 RTCP packet. 1599 6.2 Transport Layer Feedback Messages 1601 Transport Layer FB messages are identified by the value RTPFB as 1602 RTCP message type. 1604 A single general purpose transport layer FB messages are defined so 1605 far: Generic NACK. It is identified by means of the FMT parameter 1606 as follows: 1608 0: unassigned 1609 1: Generic NACK 1610 2-30: unassigned 1611 31: reserved for future expansion of the identifier number space 1613 The following subsection defines the formats of the FCI field for 1614 this type of FB message. Further generic feedback messages MAY be 1615 defined in the future. 1617 6.2.1 Generic NACK 1619 The Generic NACK message is identified by PT=RTPFB and FMT=1. 1621 The FCI field MUST contain at least one and MAY contain more than 1622 one Generic NACK. 1624 The Generic NACK packet is used to indicate the loss of one or more 1625 RTP packets. The lost packet(s) are identified by the means of a 1626 packet identifier and a bit mask. 1628 Generic NACK feedback SHOULD NOT be used if the underlying 1629 transport protocol is capable of providing similar feedback 1630 information to the sender (as may be the case e.g. with DCCP). 1632 The Feedback control information (FCI) field has the following 1633 Syntax (figure 4): 1635 0 1 2 3 1636 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 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | PID | BLP | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 Figure 4: Syntax for the Generic NACK message 1643 Packet ID (PID): 16 bits 1644 The PID field is used to specify a lost packet. The PID field 1645 refers to the RTP sequence number of the lost packet. 1647 bitmask of following lost packets (BLP): 16 bits 1648 The BLP allows for reporting losses of any of the 16 RTP 1649 packets immediately following the RTP packet indicated by the 1650 PID. The BLP's definition is identical to that given in [6]. 1651 Denoting the BLP's least significant bit as bit 1, and its most 1652 significant bit as bit 16, then bit i of the bit mask is set to 1653 1 if the receiver has not received RTP packet number (PID+i) 1654 (modulo 2^16) and indicates this packet is lost; bit i is set 1655 to 0 otherwise. Note that the sender MUST NOT assume that a 1656 receiver has received a packet because its bit mask was set to 1657 0. For example, the least significant bit of the BLP would be 1658 set to 1 if the packet corresponding to the PID and the 1659 following packet have been lost. However, the sender cannot 1660 infer that packets PID+2 through PID+16 have been received 1661 simply because bits 2 through 15 of the BLP are 0; all the 1662 sender knows is that the receiver has not reported them as lost 1663 at this time. 1665 The length of the FB message MUST be set to 2+n, with n being the 1666 number of Generic NACKs contained in the FCI field. 1668 The Generic NACK message implicitly references the payload type 1669 through the sequence number(s). 1671 6.3 Payload Specific Feedback Messages 1673 Payload-Specific FB messages are identified by the value PT=PSFB as 1674 RTCP message type. 1676 Three payload-specific FB messages are defined so far plus an 1677 application layer FB message. They are identified by means of the 1678 FMT parameter as follows: 1680 0: unassigned 1681 1: Picture Loss Indication (PLI) 1682 2: Slice Lost Indication (SLI) 1683 3: Reference Picture Selection Indication (RPSI) 1684 4-14: unassigned 1685 15: Application layer FB message 1686 16-30: unassigned 1687 31: reserved for future expansion of the sequence number space 1689 The following subsections define the FCI formats for the payload- 1690 specific FB messages, section 6.4 defines FCI format for the 1691 application layer FB message. 1693 6.3.1 Picture Loss Indication (PLI) 1695 The PLI FB message is identified by PT=PSFB and FMT=1. 1697 There MUST be exactly one PLI contained in the FCI field. 1699 6.3.1.1 Semantics 1701 With the Picture Loss Indication message, a decoder informs the 1702 encoder about the loss of an undefined amount of coded video data 1703 belonging to one or more pictures. When used in conjunction with 1704 any video coding scheme that is based on inter-picture prediction, 1705 an encoder that receives a PLI becomes aware that the prediction 1706 chain may be broken. The sender MAY react to a PLI by transmitting 1707 an intra-picture to achieve resynchronization (making effectively 1708 similar to the FIR as defined in [6]); however, the sender MUST 1709 consider congestion control as outlined in section 7 which MAY 1710 restrict its ability to send an intra frame. 1712 Other RTP payload specifications such as RFC 2032 [6] already 1713 define a feedback mechanism for some for certain codecs. An 1714 application supporting both schemes MUST use the feedback mechanism 1715 defined in this specification when sending feedback. For backward 1716 compatibility reasons, such an application SHOULD also be capable 1717 to receive and react to the feedback scheme defined in the 1718 respective RTP payload format, if this is required by that payload 1719 format. 1721 6.3.1.2 Message Format 1723 PLI does not require parameters. Therefore, the length field MUST 1724 be 2, and there MUST NOT be any Feedback Control Information. 1726 The semantics of this FB message is independent of the payload 1727 type. 1729 6.3.1.3 Timing Rules 1731 The timing follows the rules outlined in section 3. In systems 1732 that employ both PLI and other types of feedback it may be 1733 advisable to follow the Regular RTCP RR timing rules for PLI, since 1734 PLI is not as delay critical as other FB types. 1736 6.3.1.4 Remarks 1738 PLI messages typically trigger the sending of full intra pictures. 1739 Intra pictures are several times larger then predicted (inter) 1740 pictures. Their size is independent of the time they are 1741 generated. In most environments, especially when employing 1742 bandwidth-limited links, the use of an intra picture implies an 1743 allowed delay that is a significant multitude of the typical frame 1744 duration. An example: If the sending frame rate is 10 fps, and an 1745 intra picture is assumed to be 10 times as big as an inter picture, 1746 then a full second of latency has to be accepted. In such an 1747 environment there is no need for a particular short delay in 1748 sending the FB message. Hence waiting for the next possible time 1749 slot allowed by RTCP timing rules as per [2] does not have a 1750 negative impact on the system performance. 1752 6.3.2 Slice Lost Indication (SLI) 1754 The SLI FB message is identified by PT=PSFB and FMT=2. 1756 The FCI field MUST contain at least one and MAY contain more than 1757 one SLI. 1759 6.3.2.1 Semantics 1761 With the Slice Lost Indication a decoder can inform an encoder that 1762 it has detected the loss or corruption of one or several 1763 consecutive macroblock(s) in scan order (see below). This FB 1764 message MUST NOT be used for video codecs with non-uniform, 1765 dynamically changeable macroblock sizes such as H.263 with enabled 1766 Annex Q. In such a case, an encoder cannot always identify the 1767 corrupted spatial region. 1769 6.3.2.2 Format 1771 The Slice Lost Indication uses one additional PCI field the 1772 content of which is depicted in figure 6. The length of the FB 1773 message MUST be set to 2+n, with n being the number of SLIs 1774 contained in the FCI field. 1776 0 1 2 3 1777 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 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | First | Number | PictureID | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 Figure 6: Syntax of the Slice Lost Indication (SLI) 1784 First: 13 bits 1785 The macroblock (MB) address of the first lost macroblock. The 1786 MB numbering is done such that the macroblock in the upper left 1787 corner of the picture is considered macroblock number 1 and the 1788 number for each macroblock increases from left to right and 1789 then from top to bottom in raster-scan order (such that if 1790 there is a total of N macroblocks in a picture, the bottom 1791 right macroblock is considered macroblock number N). 1793 Number: 13 bits 1794 The number of lost macroblocks, in scan order as discussed 1795 above. 1797 PictureID: 6 bits 1798 The six least significant bits of the a codec-specific 1799 identifier that is used to reference the picture in which the 1800 loss of the macroblock (s) has occurred. For many video 1801 codecs, the PictureID is identical to the Temporal Reference. 1803 The applicability of this FB message is limited to a small set of 1804 video codecs and therefore, no explicit payload type information is 1805 provided. 1807 6.3.2.3 Timing Rules 1809 The efficiency of algorithms using the Slice Lost Indication is 1810 reduced greatly when the Indication is not transmitted in a timely 1811 fashion. Motion compensation propagates corrupted pixels that are 1812 not reported as being corrupted. Therefore, the use of the 1813 algorithm discussed in section 3 is highly recommended. 1815 6.3.2.4 Remarks 1817 The term Slice is defined and used here in the sense of MPEG-1 -- a 1818 consecutive number of macroblocks in scan order. More recent video 1819 coding standards sometimes have a different understanding of the 1820 term Slice. In H.263 (1998), for example, a concept known as 1821 "rectangular Slice" exists. The loss of one Rectangular Slice may 1822 lead to the necessity of sending more than one SLI in order to 1823 precisely identify the region of lost/damaged MBs. 1825 The first field of the FCI defines the first macroblock of a 1826 picture as 1 and not, as one could suspect, as 0. This was done to 1827 align this specification with the comparable mechanism available in 1828 H.245. The maximum number of macroblocks in a picture (2**13 or 1829 8192) corresponds to the maximum picture sizes of most of the ITU-T 1830 and ISO/IEC video codecs. If future video codecs offer larger 1831 picture sizes and/or smaller macroblock sizes, then an additional 1832 FB message has to be defined. The six least significant bits of 1833 the Temporal Reference field are deemed to be sufficient to 1834 indicate the picture in which the loss occurred. 1836 The reaction to a SLI is not part of this specification. One 1837 typical way of reacting to a SLI is to use intra refresh for the 1838 affected spatial region. 1840 Algorithms were reported that keep track of the regions affected by 1841 motion compensation, in order to allow for a transmission of Intra 1842 macroblocks to all those areas, regardless of the timing of the FB 1843 (see H.263 (2000) Appendix I [17] and [15]). While, when those 1844 algorithms are used, the timing of the FB is less critical then 1845 without, it has to be observed that those algorithms correct large 1846 parts of the picture and, therefore, have to transmit much higher 1847 data volume in case of delayed FBs. 1849 6.3.3 Reference Picture Selection Indication (RPSI) 1851 The RPSI FB message is identified by PT=PSFB and FMT=3. 1853 There MUST be exactly one RPSI contained in the FCI field. 1855 6.3.3.1 Semantics 1857 Modern video coding standards such as MPEG-4 visual version 2 [16] 1858 or H.263 version 2 [17] allow to use older reference pictures than 1859 the most recent one for predictive coding. Typically, a first-in- 1860 first-out queue of reference pictures is maintained. If an encoder 1861 has learned about a loss of encoder-decoder synchronicity, a known- 1862 as-correct reference picture can be used. As this reference picture 1863 is temporally further away then usual, the resulting predictively 1864 coded picture will use more bits. 1866 Both MPEG-4 and H.263 define a binary format for the "payload" of 1867 an RPSI message that includes information such as the temporal ID 1868 of the damaged picture and the size of the damaged region. This 1869 bit string is typically small -- a couple of dozen bits --, of 1870 variable length, and self-contained, i.e. contains all information 1871 that is necessary to perform reference picture selection. 1873 Note that both MPEG-4 and H.263 allow the use of RPSI with positive 1874 feedback information as well. That is, pictures (or Slices) are 1875 reported that were decoded without error. Note that any form of 1876 positive feedback MUST NOT be used when in a multiparty session 1877 (reporting positive feedback about individual reference pictures at 1878 RTCP intervals is not expected to be of much use anyway). 1880 6.3.3.2 Format 1882 The FCI for the RPSI message follows the format depicted in figure 1883 7: 1885 0 1 2 3 1886 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 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 | PB |0| Payload Type| Native RPSI bit string | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | defined per codec ... | Padding (0) | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 Figure 7: Syntax of the Reference Picture Selection Indication 1894 (RPSI) 1896 PB: 8 bits 1897 The number of unused bits required to pad the length of the 1898 RPSI message to a multiple of 32 bits. 1900 0: 1 bit 1901 MUST be set to zero upon transmission and ignored upon 1902 reception. 1904 Payload Type: 7 bits 1905 Indicates the RTP payload type in the context of which the 1906 native RPSI bit string MUST be interpreted. 1908 Native RPSI bit string: variable length 1909 The RPSI information as natively defined by the video codec. 1911 Padding: #PB bits 1912 A number of bits set to zero to fill up the contents of the 1913 RPSI message to the next 32 bit boundary. The number of 1914 padding bits MUST be indicated by the PB field. 1916 6.3.3.3 Timing Rules 1918 RPS is even more critical to delay then algorithms using SLI. This 1919 is due to the fact that the older the RPS message is, the more bits 1920 the encoder has to spend to re-establish encoder-decoder 1921 synchronicity. See [15] for some information about the overhead of 1922 RPS for certain bit rate/frame rate/loss rate scenarios. 1924 Therefore, RPS messages should typically be sent as soon as 1925 possible, employing the algorithm of section 3. 1927 6.4 Application Layer Feedback Messages 1929 Application Layer FB messages are a special case of payload- 1930 specific messages and identified by PT=PSFB and FMT=15. 1931 There MUST be exactly one Application Layer FB message contained in 1932 the FCI field, unless the Application Layer FB message structure 1933 itself allows for stacking (e.g. by means of a fixed size or 1934 explicit length indicator). 1936 These messages are used to transport application defined data 1937 directly from the receiver's to the sender's application. The data 1938 that is transported is not identified by the FB message. 1939 Therefore, the application MUST be able to identify the messages 1940 payload. 1942 Usually, applications define their own set of messages, e.g. 1943 NEWPRED messages in MPEG-4 [16] (carried in RTP packets according 1944 to RFC 3016 [23]) or FB messages in H.263/Annex N, U [17] 1945 (packetized as per RFC 2429 [14]). These messages do not need any 1946 additional information from the RTCP message. Thus the application 1947 message is simply placed into the FCI field as follows and the 1948 length field is set accordingly. 1950 Application Message (FCI): variable length 1951 This field contains the original application message that 1952 should be transported from the receiver to the source. The 1953 format is application dependent. The length of this field is 1954 variable. If the application data is not 32-bit-aligned, 1955 padding bits and bytes must be added. Identification of 1956 padding is up to the application layer and not defined in this 1957 specification. 1959 The application layer FB message specification MUST define whether 1960 or not the message needs to be interpreted specifically in the 1961 context of a certain codec (identified by the RTP payload type). 1962 If a reference to the payload type is required for proper 1963 processing, the application layer FB message specification MUST 1964 define a way to communicate the payload type information as part of 1965 the application layer FB message itself. 1967 7 Early Feedback and Congestion Control 1969 In the previous sections, the FB messages were defined as well as 1970 the timing rules according to which to send these messages. The 1971 way to react to the feedback received depends on the application 1972 using the feedback mechanisms and hence is beyond the scope of this 1973 document. 1975 However, across all applications, there is a common requirement for 1976 (TCP-friendly) congestion control on the media stream as defined in 1977 [1] and [2] when operating in a best-effort network environment. 1979 It should be noted that RTCP feedback itself is insufficient for 1980 congestion control purposes as it is likely to operate at much 1981 slower timescales than other transport layer feedback mechanisms 1982 (that usually operate in the order of RTT). Therefore, additional 1983 mechanisms are required to perform proper congestion control. 1985 A congestion control algorithm that shares the available bandwidth 1986 reasonably fairly with competing TCP connections, e.g. TFRC [8], 1987 MUST be used to determine the data rate for the media stream within 1988 the bounds of the RTP sender's and the media session's capabilities 1989 if the RTP/AVPF session is transmitted in a best effort 1990 environment. 1992 8 Security Considerations 1994 RTP packets transporting information with the proposed payload 1995 format are subject to the security considerations discussed in the 1996 RTP specification [1] and in the RTP/AVP profile specification [2]. 1997 This profile does not specify any additional security services. 1999 This profile modifies the timing behavior of RTCP and eliminates 2000 the minimum RTCP interval of five seconds and allows for earlier 2001 feedback to be provided by receivers. Group members of the 2002 associated RTP session (possibly pretending to represent a large 2003 number of entities) may disturb the operation of RTCP by sending 2004 large numbers of RTCP packets thereby reducing the RTCP bandwidth 2005 available for Regular RTCP reporting as well as for Early FB 2006 messages. (Note that an entity need not be member of a multicast 2007 group to cause these effects.) Similarly, malicious members may 2008 send very large RTCP messages, thereby increasing the avg_rtcp_size 2009 variable and reducing the effectively available RTCP bandwidth. 2011 Feedback information may be suppressed if unknown RTCP feedback 2012 packets are received. This introduces the risk of a malicious 2013 group member reducing Early feedback by simply transmitting 2014 payload-specific RTCP feedback packets with random contents that 2015 are neither recognized by any receiver (so they will suppress 2016 feedback) nor by the sender (so no repair actions will be taken). 2018 A malicious group member can also report arbitrary high loss rates 2019 in the feedback information to make the sender throttle the data 2020 transmission and increase the amount of redundancy information or 2021 take other action to deal with the pretended packet loss (e.g. send 2022 fewer frames or decrease audio/video quality). This may result in 2023 a degradation of the quality of the reproduced media stream. 2025 Finally, a malicious group member can act as a large number of 2026 group members and thereby obtain an artificially large share of the 2027 Early feedback bandwidth and reduce the reactivity of the other 2028 group members -- possibly even causing them to no longer operate in 2029 Immediate or Early feedback mode and thus undermining the whole 2030 purpose of this profile. 2032 Senders as well as receivers SHOULD behave conservatively when 2033 observing strange reporting behavior. For excessive failure 2034 reporting from one or a few receivers, the sender MAY decide to no 2035 longer consider this feedback when adapting its transmission 2036 behavior for the media stream. In any case, senders and receivers 2037 SHOULD still adhere to the maximum RTCP bandwidth but make sure 2038 that they are capable of transmitting at least regularly scheduled 2039 RTCP packets. Senders SHOULD carefully consider how to adjust 2040 their transmission bandwidth when encountering strange reporting 2041 behavior; they MUST NOT increase their transmission bandwidth even 2042 if ignoring suspicious feedback. 2044 Attacks using false RTCP packets (Regular as well as Early ones) 2045 can be avoided by authenticating all RTCP messages. This can be 2046 achieved by using the AVPF profile together with the Secure RTP 2047 profile as defined in [22]; as a prerequisite, an appropriate 2048 combination of those two profiles (an "SAVPF") is being specified 2049 [21]. Note that, when employing group authentication (as opposed 2050 to source authentication), the aforementioned attacks may be 2051 carried out by malicious or malfunctioning group members in 2052 possession of the right keying material. 2054 9 IANA Considerations 2056 The following contact information shall be used for all 2057 registrations included here: 2059 Contact: Joerg Ott 2060 mailto:jo@acm.org 2061 tel:+49-421-201-7028 2063 The feedback profile as an extension to the profile for audio- 2064 visual conferences with minimal control needs to be registered for 2065 the Session Description Protocol (specifically the type "proto"): 2066 "RTP/AVPF". 2068 SDP Protocol ("proto"): 2070 Name: RTP/AVPF 2071 Long form: Extended RTP Profile with RTCP-based Feedback 2072 Type of name: proto 2073 Type of attribute: Media level only 2074 Purpose: RFC XXXX 2075 Reference: RFC XXXX 2077 SDP Attribute ("att-field"): 2079 Attribute name: rtcp-fb 2080 Long form: RTCP Feedback parameter 2081 Type of name: att-field 2082 Type of attribute: Media level only 2083 Subject to charset: No 2084 Purpose: RFC XXXX 2085 Reference: RFC XXXX 2086 Values: See this document and registrations below 2088 A new registry needs to be set up for the "rtcp-fb" attribute, with 2089 the following registrations created initially: "ack", "nack", "trr- 2090 int", and "app" as defined in this document. 2092 Initial value registration for the attribute "rtcp-fb" 2094 Value name: ack 2095 Long name: Positive acknowledgement 2096 Reference: RFC XXXX. 2098 Value name: nack 2099 Long name: Negative Acknowledgement 2100 Reference: RFC XXXX. 2102 Value name: trr-int 2103 Long name: Minimal receiver report interval 2104 Reference: RFC XXXX. 2106 Value name: app 2107 Long name: Application-defined paramater 2108 Reference: RFC XXXX. 2110 Further entries may be registered on a first-come first-serve 2111 basis. Each new registration needs to indicate the parameter name 2112 and the syntax of possible additional arguments. For each new 2113 registration, it is mandatory that a permanent, stable, and 2114 publicly accessible document exists that specifies the semantics of 2115 the registered parameter, the syntax and semantics of its 2116 parameters as well as corresponding feedback packet formats (if 2117 needed). The general registration procedures of [3] apply. 2119 For use with both "ack" and "nack", a joint sub-registry needs to 2120 be set up that initially registers the following values: 2122 Initial value registration for the attribute values "ack" and 2123 "nack": 2125 Value name: sli 2126 Long name: Slice Loss Indication 2127 Usable with: nack 2128 Reference: RFC XXXX. 2130 Value name: pli 2131 Long name: Picture Loss Indication 2132 Usable with: nack 2133 Reference: RFC XXXX. 2135 Value name: rpsi 2136 Long name: Reference Picture Selection Indication 2137 Usable with: ack, nack 2138 Reference: RFC XXXX. 2140 Value name: app 2141 Long name: Application layer feedback 2142 Usable with: ack, nack 2143 Reference: RFC XXXX. 2145 Further entries may be registered on a first-come first-serve 2146 basis. Each registrations needs to indicate the parameter name, 2147 the syntax of possible additional arguments, and whether the 2148 parameter is applicable to "ack" or "nack" feedback or both or some 2149 different "rtcp-fb" attribute parameter. For each new 2150 registration, it is mandatory that a permanent, stable, and 2151 publicly accessible document exists that specifies the semantics of 2152 the registered parameter, the syntax and semantics of its 2153 parameters as well as corresponding feedback packet formats (if 2154 needed). The general registration procedures of [3] apply. 2156 Two RTCP Control Packet Types: for the class of transport layer FB 2157 messages ("RTPFB") and for the class of payload-specific FB 2158 messages ("PSFB"). Section 6 suggests RTPFB=205 and PSFB=206 to be 2159 added to the RTCP registry. 2161 RTP RTCP Control Packet types (PT): 2163 Name: RTPFB 2164 Long name: Generic RTP Feedback 2165 Value: 205 2166 Reference: RFC XXXX. 2168 Name: PSFB 2169 Long name: Payload-specific 2170 Value: 206 2171 Reference: RFC XXXX. 2173 As AVPF defines additional RTCP payload types, the corresponding 2174 "reserved" RTP payload type space (72--76, as defined in [2]), 2175 needs to be expanded accordingly. 2177 A new sub-registry needs to be set up for the FMT values for both 2178 the RTPFB payload type and the PSFB payload type, with the 2179 following registrations created initially: 2181 Within the RTPFB range, the following two format (FMT) values are 2182 initially registered: 2184 Name: Generic NACK 2185 Long name: Generic negative acknowledgement 2186 Value: 1 2187 Reference: RFC XXXX. 2189 Name: Extension 2190 Long name: Reserved for future extensions 2191 Value: 31 2192 Reference: RFC XXXX. 2194 Within the PSFB range, the following five format (FMT) values are 2195 initially registered: 2197 Name: PLI 2198 Long name: Picture Loss Indication 2199 Value: 1 2200 Reference: RFC XXXX. 2202 Name: SLI 2203 Long name: Slice Loss Indication 2204 Value: 2 2205 Reference: RFC XXXX. 2207 Name: RPSI 2208 Long name: Reference Picture Selection Indication 2209 Value: 3 2210 Reference: RFC XXXX. 2212 Name: AFB 2213 Long name: Application Layer Feedback 2214 Value: 15 2215 Reference: RFC XXXX. 2217 Name: Extension 2218 Long name: Reserved for future extensions. 2219 Value: 31 2220 Reference: RFC XXXX. 2222 Further entries may be registered following the "Specification 2223 Required" rules as defined in RFC 2434 [10]. Each registration 2224 needs to indicate the FMT value, if there is a specific FB message 2225 to go into the FCI field, and whether or not multiple FB messages 2226 may be stacked in a single FCI field. For each new registration, 2227 it is mandatory that a permanent, stable, and publicly accessible 2228 document exists that specifies the semantics of the registered 2229 parameter as well as the syntax and semantics of the associated FB 2230 message (if any). The general registration procedures of [3] 2231 apply. 2233 NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by 2234 the RFC number assigned to this document. 2236 10 Acknowledgements 2238 This document is a product of the Audio-Visual Transport (AVT) 2239 Working Group of the IETF. The authors would like to thank Steve 2240 Casner and Colin Perkins for their comments and suggestions as well 2241 as for their responsiveness to numerous questions. The authors 2242 would also like to particularly thank Magnus Westerlund for his 2243 review and his valuable suggestions, Shigeru Fukunaga for the 2244 contributions on for FB message formats and semantics. 2246 We would also like to thank Andreas Buesching and people at 2247 Panasonic for their simulations and the first independent 2248 implementations of the feedback profile. 2250 11 Authors' Addresses 2252 Joerg Ott {sip,mailto}:jo@tzi.org 2253 Uni Bremen TZI 2254 MZH 5180 2255 Bibliothekstr. 1 2256 D-28359 Bremen 2257 Germany 2259 Stephan Wenger stewe@stewe.org 2260 TU Berlin 2261 Sekr. FR 6-3 2262 Franklinstr. 28-29 2263 D-10587 Berlin 2264 Germany 2265 Noriyuki Sato sato652@oki.com 2266 Oki Electric Industry Co., Ltd. 2267 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan 2268 Tel. +81 6 6949 5101 2269 Fax. +81 6 6949 5108 2271 Carsten Burmeister burmeister@panasonic.de 2272 Panasonic European Laboratories GmbH 2274 Jose Rey rey@panasonic.de 2275 Panasonic European Laboratories GmbH 2276 Monzastr. 4c, 63225 Langen, Germany 2277 Tel. +49-(0)6103-766-134 2278 Fax. +49-(0)6103-766-166 2280 12 Bibliography 2282 12.1 Normative references 2284 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP 2285 - A Transport Protocol for Real-time Applications," RFC 3550 2286 (STD0064), July 2003. 2288 [2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video 2289 Conferences with Minimal Control," RFC 3551 (STD0065), July 2290 2003. 2292 [3] M. Handley, V. Jacobson, and Colin Perkins, "SDP: Session 2293 Description Protocol", Internet Draft draft-ietf-mmusic-sdp- 2294 new-18.txt, June 2004. 2296 [4] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", RFC 2297 3556, July 2003. 2299 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 2300 Levels," RFC 2119, March 1997. 2302 [6] T. Turletti and C. Huitema, "RTP Payload Format for H.261 2303 Video Streams, RFC 2032, October 1996. 2305 [7] G. Camarillo, J. Holler, G. Eriksson, H. Schulzrinne, 2306 "Grouping of media lines in SDP," RFC 3388, December 2002. 2308 [8] M. Handley, J. Padhye, S. Floyd, J. Widmer, "TCP friendly Rate 2309 Control (TFRC): Protocol Specification," RFC 3448, January 2310 2003. 2312 [9] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 2313 SDP," RFC 3264, June 2002. 2315 [10] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 2316 Considerations Section in RFCs," RFC 2434, October 1998. 2318 12.2 Informative References 2320 [11] C. Perkins and O. Hodson, "Options for Repair of Streaming 2321 Media," RFC 2354, June 1998. 2323 [12] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for 2324 Generic Forward Error Correction,", RFC 2733, December 1999. 2326 [13] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, 2327 J.C. Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload 2328 for Redundant Audio Data," RFC 2198, September 1997. 2330 [14] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. 2331 Newell, J. Ott, G. Sullivan, S. Wenger, and C. Zhu, "RTP 2332 Payload Format for the 1998 Version of ITU-T Rec. H.263 Video 2333 (H.263+)," RFC 2429, October 1998. 2335 [15] B. Girod, N. Faerber, "Feedback-based error control for mobile 2336 video transmission," Proceedings IEEE, Vol. 87, No. 10, pp. 2337 1707 - 1723, October, 1999. 2339 [16] ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology - 2340 Coding of audio-visual objects - Part2: Visual", 2001. 2342 [17] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate 2343 Communication," November 2000. 2345 [18] H. Schulzrinne and S. Petrack, "RTP Payload for DTMF Digits, 2346 Telephony Tones and Telephony Signals," RFC 2833, May 2000. 2348 [19] E. Kohler, M. Handley, and S. Floyd, "Datagram Congestion 2349 Control Protocol (DCCP)," Internet Draft draft-ietf-dccp-spec- 2350 076.txt, Work in Progress, February July 2004. 2352 [20] M. Handley, S. Floyd, J. Padhye, and J. Widmer, "TCP Friendly 2353 Rate Control (TFRC): Protocol Specification," RFC 3448, 2354 January 2003. 2356 [21] J. Ott and E. Carrara, "Extended Secure RTP Profile for RTCP- 2357 based Feedback (RTP/SAVPF)," Internet Draft draft-ietf-avt- 2358 profile-savpf-01.txt, Work in Progress, July 2004. 2360 [22] M. Baugher, D. McGrew, M. Naslund, E. Carrarra, and K. 2361 Norrman, "The Secure Real-Time Transport Protocol," RFC 3711, 2362 March 2004. 2364 [23] Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, and H. Kimata, 2365 "RTP Payload Format for MPEG-4 Audio/Visual Streams," RFC 2366 3016, November 2000. 2368 13 Disclaimer of Validity 2370 The IETF takes no position regarding the validity or scope of any 2371 Intellectual Property Rights or other rights that might be claimed 2372 to pertain to the implementation or use of the technology described 2373 in this document or the extent to which any license under such 2374 rights might or might not be available; nor does it represent that 2375 it has made any independent effort to identify any such rights. 2376 Information on the procedures with respect to rights in RFC 2377 documents can be found in BCP 78 and BCP 79. 2379 Copies of IPR disclosures made to the IETF Secretariat and any 2380 assurances of licenses to be made available, or the result of an 2381 attempt made to obtain a general license or permission for the use 2382 of such proprietary rights by implementers or users of this 2383 specification can be obtained from the IETF on-line IPR repository 2384 at http://www.ietf.org/ipr. 2386 The IETF invites any interested party to bring to its attention any 2387 copyrights, patents or patent applications, or other proprietary 2388 rights that may cover technology that may be required to implement 2389 this standard. Please address the information to the IETF at ietf- 2390 ipr@ietf.org. 2392 14 Full Copyright Statement 2394 Copyright (C) The Internet Society (2004). This document is 2395 subject to the rights, licenses and restrictions contained in BCP 2396 78, and except as set forth therein, the authors retain all their 2397 rights. 2399 This document and the information contained herein are provided on 2400 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2401 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 2402 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 2403 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 2404 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 2405 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2406 PARTICULAR PURPOSE. 2408 15 Acknowledgment 2410 Funding for the RFC Editor function is currently provided by the 2411 Internet Society.