idnits 2.17.1 draft-ietf-avt-rtcp-feedback-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 Internet-Drafts being working documents. ** 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? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [10], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 236: '...tiple FB messages MAY be combined in a...' RFC 2119 keyword, line 237: '... packet and they MAY also be sent comb...' RFC 2119 keyword, line 241: '... document MUST contain RTCP packets in the order as defined in [1]:...' RFC 2119 keyword, line 243: '... o OPTIONAL encryption prefix that M...' RFC 2119 keyword, line 246: '...ATORY SDES which MUST contain the CNAM...' (122 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1598 has weird spacing: '... These messa...' == Line 1805 has weird spacing: '... Mail fukun...' == Line 1812 has weird spacing: '... Mail sato6...' == Line 1824 has weird spacing: '... Mail akihi...' == Line 1831 has weird spacing: '... Mail hata@...' == (2 more instances...) -- 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 (September 2002) is 7888 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1849 looks like a reference -- Missing reference section? '10' on line 1880 looks like a reference -- Missing reference section? '2' on line 1854 looks like a reference -- Missing reference section? '7' on line 1870 looks like a reference -- Missing reference section? '11' on line 1883 looks like a reference -- Missing reference section? '5' on line 1864 looks like a reference -- Missing reference section? '6' on line 1867 looks like a reference -- Missing reference section? '8' on line 1874 looks like a reference -- Missing reference section? '3' on line 1858 looks like a reference -- Missing reference section? '4' on line 1861 looks like a reference -- Missing reference section? '14' on line 1894 looks like a reference -- Missing reference section? '13' on line 1891 looks like a reference -- Missing reference section? '15' on line 1898 looks like a reference -- Missing reference section? '12' on line 1888 looks like a reference -- Missing reference section? '16' on line 1902 looks like a reference -- Missing reference section? '17' on line 1906 looks like a reference -- Missing reference section? '9' on line 1877 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 20 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-02.txt Stephan Wenger/TU Berlin 4 Shigeru Fukunaga/Oki 5 Noriyuki Sato/Oki 6 Koichi Yano/Fast Forward Networks 7 Akihiro Miyazaki/Matsushita 8 Koichi Hata/Matsushita 9 Rolf Hakenberg/Matsushita 10 Carsten Burmeister/Matsushita 12 1 March 2002 13 Expires September 2002 15 Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC 2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 Real-time media streams that use RTP are not resilient against 39 packet losses. RTP [1] provides all the necessary mechanisms to 40 restore ordering and timing to properly reproduce a media stream at 41 the recipient. RTP also provides continuous feedback about the 42 overall reception quality from all receivers -- thereby allowing 43 the sender(s) in the mid-term (in the order of several seconds to 44 minutes) to adapt their coding scheme and transmission behavior to 45 the observed network QoS. However, except for a few payload 46 specific mechanisms [10], RTP makes no provision for timely 47 feedback that would allow a sender to repair the media stream 48 immediately: through retransmissions, retro-active FEC, or media- 49 specific mechanisms such as reference picture selection for some 50 video codecs. 52 Generally, real-time transport of media streams across IP 53 networks follows RTP[1] in conjunction with the RTP Profile for 54 Audio and Video Conferences with Minimal Control [2]. This 55 document modifies the profile defined in [2] in two ways: 57 o by providing additional RTCP messages that enable a receiver to 58 convey more precise feedback to a sender and 60 o by adapting the timing algorithm for scheduling RTCP packets in 61 order to allow for occasional timely feedback about events 62 observed by a receiver (such as lost packets). 64 The result is an RTP Profile for Audio and Video Conferences with 65 Minimal Control that allows for more explicit and more immediate 66 receiver feedback but shares all other properties (including all 67 other message types and formats, all code points for codecs, 68 payload formats, scaling capabilities, etc. of [2]). Therefore, 69 this document only specifies the additions and modifications to [2] 70 rather than the repeating the entire specification. 72 1. Introduction 74 Real-time media streams that use RTP are not resilient against 75 packet losses. RTP [1] provides all the necessary mechanisms to 76 restore ordering and timing present at the sender to properly 77 reproduce a media stream at a recipient. RTP also provides 78 continuous feedback about the overall reception quality from all 79 receivers -- thereby allowing the sender(s) in the mid-term (in the 80 order of several seconds to minutes) to adapt their coding scheme 81 and transmission behavior to the observed network QoS. However, 82 except for a few payload specific mechanisms [10], RTP makes no 83 provision for timely feedback that would allow a sender to repair 84 the media stream immediately: through retransmissions, retro-active 85 FEC, or media-specific mechanisms such as reference picture 86 selection for some video codecs. 88 Current mechanisms available with RTP to improve error resilience 89 include audio redundancy coding [7], video redundancy coding [11], 90 RTP-level FEC [5], and general considerations on more robust media 91 streams transmission [6]. These mechanisms may be applied pro- 92 actively (thereby increasing the bandwidth of a given media 93 stream). Alternatively, in sufficiently small groups with small 94 RTTs, the senders may perform repair on-demand, using the above 95 mechanisms and/or media-encoding-specific approaches. Note that 96 "small group" and "sufficiently small RTT" are both highly 97 application dependent. 99 This document specifies a modified RTP Profile for audio and video 100 conferences with minimal control based upon [1] and [2] by means of 101 two modifications/additions: To achieve timely feedback, the 102 concepts of Immediate Feedback messages and Early RTCP messages as 103 well as algorithms allowing for low delay feedback in small 104 multicast groups (and preventing feedback implosion in large ones) 105 are introduced. Special consideration is given to point-to-point 106 scenarios. And a small number of general-purpose feedback messages 107 as well as a format for codec and application-specific feedback 108 information are defined as specific RTCP payloads. 110 1.1 Definitions 112 The definitions from [1] and [2] apply. In addition, the following 113 definitions are used in this document: 115 Early RTCP mode: 116 The mode of operation in which a receiver of a media stream 117 is, statistically, often (but not always) capable of 118 reporting events of interest back to the sender close to 119 their occurrence. In Early RTCP mode, RTCP feedback 120 messages are transmitted according to the timing rules 121 defined in this document. 123 Early RTCP packet: 124 An Early RTCP packet is a packet which is transmitted 125 earlier than would be allowed following the scheduling 126 algorithm of [1], the reason being an "event" observed by a 127 receiver. Early RTCP packets may be sent in Immediate 128 feedback and in Early RTCP mode. 130 Event: 131 An observation made by the receiver of a media stream that 132 is (potentially) of interest to the sender -- such as a 133 packet loss or packet reception, frame loss, etc. -- and 134 thus useful to be reported back to the sender by means of a 135 Feedback message. 137 Feedback (FB) message: 138 An RTCP message as defined in this document is used to 139 convey information about events observed at a receiver -- 140 in addition to long term receiver status information which 141 is carried in RTCP RRs -- back to the sender of the media 142 stream. 144 Feedback (FB) threshold: 145 The FB threshold indicates the transition between Immediate 146 Feedback and Early RTCP mode. For a multicast scenario, 147 the FB threshold indicates the maximum group size at which, 148 on average, each receiver is able to report each event back 149 to the sender(s) immediately, i.e. by means of an Early 150 RTCP packet without having to wait for its regularly 151 scheduled RTCP interval. This threshold is highly 152 dependent on the type of feedback to be provided, network 153 QoS (e.g. packet loss probability and distribution), codec 154 and packetization in use, the session bandwidth, and 155 application requirements. Note that the algorithms do 156 not depend on all senders and receivers agreeing on the 157 same value for this threshold. It is merely intended to 158 provide conceptual guidance to application designers and is 159 not used in any calculations. 161 Immediate Feedback mode: 162 A mode of operation in which each receiver of a media 163 stream is, statistically, capable of reporting each event 164 of interest immediately back to the media stream sender. 165 In Immediate Feedback mode, RTCP feedback messages are 166 transmitted according to the timing rules defined in this 167 document. 169 Regular RTCP mode: 170 Mode of operation in which no preferred transmission of 171 feedback messages is allowed. Instead, RTCP messages are 172 sent following the rules of [1]. Such RTCP messages may 173 contain feedback information as defined in this document. 175 Regularly Scheduled RTCP packet: 176 An RTCP packet that is not sent as an Early RTCP packet. 178 1.2 Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 181 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 182 in this document are to be interpreted as described in RFC 2119 183 [8] 185 2. RTP and RTCP Packet Formats and Protocol Behavior 187 The rules defined in [2] also apply to this profile except for 188 those rules mentioned in the following: 190 RTCP packet types: 191 Three additional RTCP packet types to convey feedback 192 information are defined in section 4. 194 RTCP report intervals: 195 This memo describes three modes of operation which 196 influence the RTCP report intervals (see section 3.2). In 197 regular RTCP mode, all rules from [1] apply. In both 198 Immediate Feedback and Early RTCP modes the minimal 199 interval of 5 seconds between 2 RTCP reports is dropped and 200 the rules specified in section 3 apply if RTCP packets 201 containing feedback messages (defined in section 4) are to 202 be transmitted. 204 The rules set forth in [1] may be overridden by session 205 descriptions specifying different parameters (e.g. for the 206 bandwidth share assigned to RTCP for senders and receivers, 207 respectively). For sessions defined using the Session 208 Description Protocol (SDP) [3], the rules of [4] apply. 210 Congestion control: 211 The same basic rules as detailed in [2] apply. Beyond 212 this, in section 5, further consideration is given to the 213 impact of feedback and a sender's reaction to feedback 214 messages. 216 3. Rules for RTCP Feedback 218 3.1 Compound RTCP Feedback Packets 220 Two components constitute RTCP-based feedback as described in this 221 memo: 223 o Status reports are contained in SR/RR messages and are 224 transmitted at regular intervals as part of compound RTCP 225 packets (which also include SDES and possibly other messages); 226 these status reports provide an overall indication for the 227 recent reception quality of a media stream. 229 o Feedback messages as defined in this document that indicate loss 230 or reception of particular pieces of a media stream (or provide 231 some other form of rather immediate feedback on the data 232 received). Rules for the transmission of feedback messages are 233 newly introduced in this memo. 235 RTCP Feedback (FB) messages are just another RTCP packet type (see 236 section 4). Therefore, multiple FB messages MAY be combined in a 237 single compound RTCP packet and they MAY also be sent combined with 238 other RTCP packets. 240 RTCP packets containing Feedback packets as defined in this 241 document MUST contain RTCP packets in the order as defined in [1]: 243 o OPTIONAL encryption prefix that MUST be present if the RTCP 244 message is to be encrypted. 245 o MANDATORY SR or RR. 246 o MANDATORY SDES which MUST contain the CNAME item; all other SDES 247 items are OPTIONAL. 248 o One or more FB messages. 250 The FB message(s) MUST be placed in the compound packet after RR 251 and SDES RTCP packets defined in [1]. The ordering with respect to 252 other RTCP extensions is not defined. 254 Two types of compound RTCP packets carrying feedback packets are 255 used in this document: 257 a) Minimal compound RTCP feedback packet 259 A minimal compound RTCP feedback packet MUST contain only the 260 mandatory information as listed above: encryption prefix if 261 necessary, exactly one RR or SR, exactly one SDES with only the 262 CNAME item present, and the feedback message(s). This is to 263 minimize the size of the RTCP packet transmitted to convey 264 feedback and thus to maximize the frequency at which feedback 265 can be provided while still adhering to the RTCP bandwidth 266 limitations. 268 This packet format SHOULD be used whenever an RTCP feedback 269 message is sent as part of an Early RTCP packet. 271 b) (Full) compound RTCP feedback packet 273 A (full) compound RTCP feedback packet MAY contain any 274 additional number of RTCP packets (additional RRs, further SDES 275 items, etc.). The above ordering rules MUST be adhered to. 277 This packet format MUST be used whenever an RTCP feedback 278 message is sent as part of a regularly scheduled RTCP packet or 279 in Regular RTCP mode. It MAY also be used to send RTCP 280 feedback messages in Immediate Feedback or Early RTCP mode. 282 RTCP packets that do not contain FB messages are referred to as 283 non-FB RTCP packets. Such packets MUST follow the format rules in 284 [1]. 286 3.2 Algorithm Outline 288 FB messages are part of the RTCP control streams and are thus 289 subject to the same bandwidth constraints as other RTCP traffic. 290 This means in particular that it may not be possible to report an 291 event observed at a receiver immediately back to the sender. 293 However, the value of feedback given to a sender typically 294 decreases over time -- in terms of the media quality as perceived 295 by the user at the receiving end and/or the cost required to 296 achieve media stream repair. 298 RTP [1] and the commonly used RTP profile [2] specify rules when 299 compound RTCP packets should be sent. This document modifies those 300 rules in order to allow applications to timely report events (e.g. 301 loss or reception of media packets) to accommodate algorithms that 302 use FB messages and are sensitive to the feedback timing. 304 The modified RTCP transmission algorithm can be outlined as 305 follows: Normally, when no FB messages have to be conveyed, 306 compound RTCP packets are sent following the rules of RTP [1] -- 307 except that the 5s minimum interval between RTCP reports is not 308 enforced and the interval between RTCP reports is only derived from 309 the average RTCP packet size and the RTCP bandwidth share available 310 to the RTP/RTCP entity. If a receiver detects the need to send an 311 FB message, the receiver waits for a short, random dithering 312 interval (in case of multicast) and then checks whether it has 313 already seen a corresponding FB message from any other receiver 314 (which it can do with all FB messages that are transmitted via 315 multicast; for unicast sessions, there is no such delay). If this 316 is the case then the receiver refrains from sending the FB message 317 and continues to follow the regular RTCP sending schedule. If the 318 receiver has not yet seen a similar FB message from any other 319 receiver, it checks whether it has recently exceeded its RTCP bit 320 rate budget to transmit another FB message (without waiting for its 321 regularly scheduled RTCP transmission time). Only if this is not 322 the case, it sends the FB message as part of a (minimal) compound 323 RTCP packet. 325 FB messages may also be sent as part of full compound RTCP packets 326 which are interspersed as per [1] (except for the five second lower 327 bound) in regular intervals. 329 3.3 Modes of Operation 331 RTCP-based feedback may operate in one of three modes (figure 1) as 332 described below. The mode is a hint whether or not a receiver 333 should send early feedback at all and, if so, whether, 334 statistically, all events observed at the receiver can be reported 335 back to the sender in a timely fashion. The current mode of 336 operation is continuously derived independently at each receiver 337 and the receivers do not have to agree on a common mode. 339 a) Immediate feedback mode: the group size is below the FB 340 threshold which gives each receiving party sufficient bandwidth 341 to transmit the RTCP feedback packets for the intended purpose. 343 This means that, for each receiver, there is enough bandwidth 344 to report each event it is supposed/expected to by means of a 345 virtually "immediate" RTCP feedback packet. 347 The group size threshold is a function of a number of 348 parameters including (but not necessarily limited to) the type 349 of feedback used (e.g. ACK vs. NACK), bandwidth, packet rate, 350 packet loss probability and distribution, media type, codec, 351 and -- again depending on the type of FB used -- the (worst 352 case or observed) frequency of events to report (e.g. frame 353 received, packet lost). 355 A special case of this is the ACK mode (where positive 356 acknowledgements are used to confirm reception of data) which 357 is restricted to point-to-point communications. 359 As a rough estimate, let N be the average number of events to 360 be reported per interval T by a receiver, B the RTCP bandwidth 361 fraction for this particular receiver and R the average RTCP 362 packet size, then the receiver operates in Immediate Feedback 363 mode as long as N<=B*T/R. 365 b) Early RTCP mode: In this mode, the group size and other 366 parameters no longer allow each receiver to react to each event 367 that would be worth (or needed) to report. But feedback can 368 still be given sufficiently often so that it allows the sender 369 to adapt the media stream transmission accordingly and thereby 370 increase the overall reproduced media quality. 372 Using the above notation, Early RTCP mode can be roughly 373 characterized by N > B*T/R as "lower bound". An estimate for 374 an upper bound is more difficult. Setting N=1, we obtain for a 375 given R and B the interval T = R/B as average interval between 376 events to be reported. This information can be used as a hint 377 to determine whether or not early transmission of RTCP packets 378 is useful. 380 c) From some group size upwards, it is no longer useful to provide 381 feedback from individual receivers at all -- because of the 382 time scale in which the feedback could be provided and/or 383 because in large groups the sender(s) have no chance to react 384 to individual feedback anymore. 386 No threshold can be specified when this occurs. 388 As the feedback algorithm described in this memo scales smoothly, 389 there is no need for an agreement among the participants on the 390 precise values of the respective "thresholds" within the group. 391 Hence the borders between all these modes are allowed to be 392 fluent. 394 ACK 395 feedback 396 V 397 :<- - - - NACK feedback - - - ->// 398 : 399 : Immediate || 400 : Feedback mode ||Early RTCP mode Regular RTCP mode 401 :<=============>||<=============>//<=================> 402 : || 403 -+---------------||---------------//------------------> group size 404 2 || 405 Application-specific FB Threshold 406 = f(data rate, packet loss, codec, ...) 408 Figure 1: Modes of operation 410 As stated before, the respective thresholds depend on a number of 411 technical parameters (of the codec, the transport, the type of 412 feedback used, etc.) but also on the respective application 413 scenarios. Section 3.6 provides some useful hints (but no precise 414 calculations) on estimating these thresholds. 416 3.4 Definitions 418 The following pieces of state information need to be maintained per 419 receiver (largely taken from [1]). Note that all variables (except 420 for g) are calculated independently at each receiver and so their 421 local values may differ at a given point in time. 423 a) Let senders be the number of active senders in the RTP session. 425 b) Let members be the current estimate of the number of receivers 426 in the RTP session. 428 c) Let tn and tp be the time for the next (last) scheduled 429 RTCP RR transmission calculated prior to reconsideration. 431 d) Let T_rr be the interval after which, having just sent a 432 regularly scheduled RTCP packet, a receiver would schedule the 433 transmission of its next RTCP packet following the rules of [1]: 434 T_rr = tn - tp. Note that the 5s minimum interval between two 435 report as defined in [1] SHOULD NOT be enforced. 437 e) Let t0 be the time at which an event that is to be reported is 438 detected by a receiver. 440 f) Let T_dither_max be the maximum interval for which an RTCP 441 feedback packet may be additionally delayed (to prevent 442 implosions). 444 g) Let T_max_fb_delay be the upper bound within which feedback to 445 an event needs to be reported back to the sender to be useful at 446 all. Note that this value is application-specific. 448 h) Let te be the time for which a feedback packet is scheduled. 450 i) Let T_fd be the actual (randomized) delay for the transmission 451 of feedback message in response to an event that a certain 452 packet P caused. 454 j) Let allow_early be a Boolean variable that indicates whether the 455 receiver currently may transmit feedback messages prior to its 456 next regularly scheduled RTCP interval tn. This variable is 457 used to throttle the feedback sent by a single receiver. 458 allow_early is adjusted (set to FALSE) after early feedback 459 transmission and is reset to TRUE as soon as the next regular 460 RTCP transmission is scheduled. 462 k) Let avg_rtcp_size be the moving average on the RTCP packet size 463 as defined in [1]. 465 The feedback situation for an event to report at a receiver is 466 depicted in figure 2 below. At time t0, such an event (e.g. a 467 packet loss) is detected at the receiver. The receiver decides -- 468 based upon current bandwidth, group size, and other (application- 469 specific) parameters -- that a feedback message needs to be sent 470 back to the sender. 472 To avoid an implosion of immediate feedback packets, the receiver 473 MUST delay the transmission of the RTCP feedback packet by a random 474 amount T_fd (with the random number evenly distributed in the 475 interval [0, T_dither_max]). Transmission of the compound RTCP 476 packet MUST then be scheduled for te = t0 + T_fd. 478 The T_dither_max parameter is derived from the regular RTCP 479 interval (which, in turn, is based upon the group size). 481 For a certain application scenario, a receiver may determine an 482 upper bound for the acceptable local delay of feedback messages: 483 T_max_fb_delay. If an a priori estimation or the actual 484 calculation of T_dither_max indicates that this upper bound MAY be 485 violated (e.g. because T_dither_max > T_max_fb_delay), the receiver 486 MAY decide not to send any feedback at all because the achievable 487 gain is considered insufficient. 489 If an RTCP feedback packet is scheduled, the time slot for the next 490 scheduled (full) compound RTCP packet MUST be updated accordingly 491 to a new tn (which will then be in the order of tn=tp+2*T_rr). 492 This is to ensure that the short term average bandwidth used for 493 RTCP with feedback does not exceed the bandwidth limit that would 494 be used without feedback. 496 event to 497 report 498 detected 499 | 500 | RTCP feedback range 501 | (T_max_fb_delay) 502 vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) ) 503 |---+--------+-------------+-----+------------| |--------+---> 504 | | | | ( ( | 505 | t0 te | 506 tp tn 507 \_______ ________/ 508 \/ 509 T_dither_max 511 Figure 2: Event report and parameters for Early RTCP scheduling 513 3.5 Early RTCP Algorithm 515 Assume an active sender S0 (out of S senders) and a number N of 516 receivers with R being one of these receivers. 518 Assume further that R has verified that using feedback mechanisms 519 is reasonable at the current constellation (which is highly 520 application specific and hence not specified in this memo). 522 Then, receiver R MUST use the following rules for transmitting one 523 or more Feedback messages as minimal or full compound RTCP packet: 525 Initially, R MUST set allow_early = TRUE. 527 Assume that R has transmitted the last RTCP RR packet at tp and has 528 scheduled the next transmission (prior to reconsideration) for tn. 530 At time t0, R detects the need to transmit one or more RTCP 531 feedback messages (e.g. because media "units" needs to be ACKed or 532 NACKed) and finds that sending the feedback information is useful 533 for the sender. 535 R first checks whether there is still a compound RTCP feedback 536 packet waiting for transmission (scheduled as early or regular RTCP 537 packet). If so, the new feedback message MUST be appended to the 538 packet; the schedule for the waiting RTCP feedback packet MUST 539 remain unchanged. When appending, the feedback information of 540 several RTCP feedback packets SHOULD be merged to produce as few 541 packets as possible. 543 If no RTCP feedback message is already awaiting transmission, a new 544 (minimal or full) compound RTCP feedback packet MUST be created and 545 the minimal interval for T_dither_max MUST be chosen as follows: 547 i) If the session is a unicast session (group size = 2) then 548 T_dither_max = 0. 550 ii) If the session is a multicast session with potentially more 551 than two group members then 553 T_dither_max = l * T_rr 555 with l=0.5. 557 The values given above for T_dither_max are minimal values. 558 Application-specific feedback considerations may make it worthwhile 559 to increase T_dither_max beyond this value. This is up to the 560 discretion of the implementer. 562 Then, R MUST check whether its next regularly scheduled RTCP packet 563 is within the time bounds for the RTCP FB (t0 + T_dither_max > tn). 564 If so, an Early RTCP packet MUST NOT be scheduled; instead the FB 565 message(s) MUST be stored to be appended to the regular RTCP packet 566 scheduled for tn. 568 Otherwise, R MUST check whether it is allowed to transmit an Early 569 RTCP packet (allow_early == TRUE). 571 If so, R MUST schedule an Early RTCP packet for te = t0 + RND * 572 T_dither_max with RND being a pseudo random function evenly 573 distributed between 0 and 1. 575 If, while waiting for te, R receives RTCP feedback packets 576 contained in one or more (minimal) compound RTCP packets, R MUST 577 act as follows for each of the RTCP feedback packets in the one 578 or more compound RTCP packets received: 580 1. If R understands the received feedback message's semantics 581 and the message contents is a superset of the feedback R 582 wanted to send then R MUST discard its own feedback message 583 and MUST re-schedule the next regular RTCP message 584 transmission for tn (as calculated before). 586 2. If R understands the received feedback message's semantics 587 and the message contents is not a superset of the feedback R 588 wanted to send then R SHOULD transmit its own feedback 589 message as scheduled. If there is an overlap between the 590 feedback information to send and the feedback information 591 received, the amount of feedback transmitted is up to R: R 592 MAY send its feedback information unchanged, R MAY as well 593 eliminate any redundancy between its own feedback and the 594 feedback received so far. 596 3. If R does not understand the received feedback message's 597 semantics, R MAY send its own feedback message as Early RTCP 598 packet, or R MAY re-schedule the next regular RTCP message 599 transmission for tn (as calculated before) and MAY append 600 the feedback message to the now regularly scheduled RTCP 601 message. 603 Note: With rule #3, receiving unknown feedback packets may 604 not lead to feedback suppression at a particular receiver. 605 As a consequence, a given event may cause M different types 606 of feedback packets (which are all appropriate but not the 607 same and mutually not understood) to be scheduled, and a 608 "large" receiver group may be partitioned into at most M 609 groups. Among members of each of these M groups, feedback 610 suppression will occur following the rules #1 and #2 but no 611 suppression will happen across groups. As a result, O(M) 612 RTCP feedback messages may be received by the sender. Given 613 that these M groups consist of receivers for the same 614 application using the same (set of) codecs in the same RTP 615 session, M is assumed to be small in the general case. 616 Given further that the O(M) feedback packets are randomly 617 distributed over a time interval of T_dither_max, the 618 resulting limited number of extra feedback packets (a) is 619 assumed not to overwhelm the sender and (b) should be 620 conveyed as all contain complementary pieces of information. 622 Refer to section 4 on the comparison of feedback messages and 623 for which feedback messages MUST be understood by a receiver. 625 Otherwise, when te is reached, R MUST transmit the RTCP packet 626 containing the FB message. R then MUST set allow_early = FALSE 627 and MUST recalculate tn = tp + 2*T_rr. The value from the last 628 calculation of T_rr SHOULD be used. As soon as R sends its next 629 regularly scheduled RTCP RR (at the new tn), it MUST set 630 allow_early = TRUE again. 632 If allow_early == FALSE then R MUST check the time for the next 633 scheduled RR: 635 1. If tn - t0 < T_max_fb_delay (i.e. if, despite late reception, 636 the feedback could still be useful for the sender) then R MAY 637 create an RTCP FB message for transmission along with the RTCP 638 packet at tn. 640 2. Otherwise, R MUST discard the RTCP feedback message. 642 In regular RTCP intervals as specified by [1] (except for the five 643 second minimum), a full compound RTCP packet MUST be sent (which 644 MAY also contain a feedback message if one has been created 645 according to the above rules and scheduled for transmission along 646 the full compound RTCP message). 648 Whenever an RTCP packet is sent or received -- minimal or full 649 compound, early or regularly scheduled -- the avg_rtcp_size 650 variable MUST be updated accordingly (see [1]) and the tn MUST be 651 calculated using the new avg_rtcp_size. 653 3.6 Considerations on the Group Size 655 This section provides some guidelines to the group sizes at which 656 the various feedback modes may be used. 658 3.6.1 ACK mode 660 The group size MUST be exactly two participants, i.e. point-to- 661 point communications. Unicast addresses MUST be used in the 662 session description. 664 For unidirectional as well as bi-directional communication between 665 two parties, 2.5% of the RTP session bandwidth are available for 666 RTCP traffic from the receivers including feedback. For a 64 667 kbit/s stream this yields 1600 bit/s for RTCP. As every other RTCP 668 packet needs to be a full compound packet, we assume an average of 669 96 bytes (=768 bits) per RTCP packet so that a receiver can report 670 2 events per second back to the sender. If acknowledgments for 10 671 events are collected in each feedback message then 20 events can be 672 acknowledged per second. At 256 kbit/s 8 events could be reported 673 per second; thus the ACKs may be sent in a finer granularity (e.g. 674 only combining only three ACKs per RTCP feedback message). 676 From 1 Mbit/s upwards, a receiver would be able to acknowledge each 677 individual frame (not packet!) in a 30 fps video stream. 679 ACK strategies MUST be defined accordingly to work properly with 680 these bandwidth limitations. An indication whether or not ACKs are 681 allowed for a session and, if so, which ACK strategy should be 682 used, MAY be conveyed by out-of-band mechanisms, e.g. media- 683 specific attributes in a session description using SDP. 685 3.6.2 NACK mode 687 Negative acknowledgements (or similar types of feedback) MUST be 688 used for all groups larger than two. Of course, NACKs MAY be used 689 for point-to-point communications as well. 691 Whether or not the use of Immediate or Early RTCP packets should be 692 considered depends upon a number of parameters including session 693 bandwidth, codec, special type of feedback, number of senders and 694 receivers, among many others. 696 The crucial parameters -- to which virtually all of the above can 697 be reduced -- is the allowed minimal interval between two RTCP 698 reports and the (average) number of events that presumably need 699 reporting per time interval (plus their distribution over time, of 700 course). The minimum interval can be derived from the available 701 RTCP bandwidth and the expected average size of an RTCP packet. 702 The number of events to report e.g. per second may be derived from 703 the packet loss rate and sender's rate of transmitting packets. 704 From these two values, the allowable group size for the Immediate 705 feedback mode can be calculated. 707 Let N be the average number of events to be reported per 708 interval T by a receiver, B the RTCP bandwidth fraction for 709 this particular receiver and R the average RTCP packet size, 710 then the receiver operates in Immediate Feedback mode is used 711 as long as N<=B*T/R. 713 The upper bound for the Early RTCP mode then solely depends on the 714 acceptable quality degradation, i.e. how many events per time 715 interval may go unreported. 717 Using the above notation, Early RTCP mode can be roughly 718 characterized by N > B*T/R as "lower bound". An estimate for 719 an upper bound is more difficult. Setting N=1, we obtain for a 720 given R and B the interval T = R/B as average interval between 721 events to be reported. This information can be used as a hint 722 to determine whether or not early transmission of RTCP packets 723 is useful. 725 Example: If a 256kbit/s video with 30 fps is transmitted through a 726 network with an MTU size of some 1500 bytes, then, in most cases, 727 each frame would fit in its own packet leading to a packet rate of 728 30 packets per second. If 5% packet loss occurs in the network 729 (equally distributed, no inter-dependence between receivers), then 730 each receiver will have to report 3 packets lost each two seconds. 732 Assuming a single sender and more than three receivers, this yields 733 3.75% of the RTCP bandwidth allocated to the receivers and thus 734 9.6kbit/s. Assuming further a size of 120 bytes for the average 735 compound RTCP packet allows 10 RTCP packets to be sent per second 736 or 20 in two seconds. If every receiver needs to report three 737 packets, this yields a maximum group size of 6-7 receivers if all 738 loss events shall be reported. The rules for transmission of 739 immediate RTCP packets should provide sufficient flexibility for 740 most of this reporting to occur in a timely fashion. 742 Extending this example to determine the upper bound for Early RTCP 743 mode could lead to the following considerations: assume that the 744 underlying coding scheme and the application (as well as the 745 tolerant users) allow on the order of one loss without repair per 746 two seconds. Thus the number of packets to be reported by each 747 receiver decreases to two per two seconds second and increases the 748 group size to 10. Assuming further that some number of packet 749 losses are correlated, feedback traffic is further reduced and 750 group sizes of some 12 to 16 (maybe even 20) can be reasonably well 751 supported using Early RTCP mode. Note, of course, that all those 752 considerations are based upon statistics and will fail to hold in 753 some cases. 755 3.7 Summary of decision steps 757 3.7.1 General Hints 759 Before even considering whether or not to send RTCP feedback 760 information an application has to determine whether this mechanism 761 is applicable: 763 1) An application has to decide whether -- for the current ratio of 764 packet rate with the associated (application-specific) maximum 765 feedback delay and the currently observed round-trip time (if 766 available) -- feedback mechanisms can be applied at all. 768 This decision may obviously be based upon (and dynamically 769 revised following) regular RTCP reception statistics as well as 770 out-of-band mechanisms. 772 2) The application has to decide -- for a certain observed error 773 rate, assigned bandwidth, frame/packet rate, and group size -- 774 whether (and which) feedback mechanisms can be applied. 776 Regular RTCP provides valuable input to this step, too. 778 3) If these tests pass, the application has to follow the rules for 779 transmitting Early RTCP packets or regularly scheduled RTCP 780 packets with piggybacked feedback. 782 3.7.2 Media Session Attributes 784 Media sessions are typically described using out-of-band mechanisms 785 to convey transport addresses, codec information, etc. between 786 sender(s) and receiver(s). Such a mechanisms consists of a format 787 used to describe a media session and another mechanism for 788 transporting this description. 790 In the IETF, the Session Description Protocol (SDP) is currently 791 used to describe media sessions while protocols such as SIP, SAP, 792 RTSP, and HTTP (among others) are used to convey the descriptions. 794 A media session description format MAY include parameters to 795 indicate that RTCP feedback mechanisms MAY be used (=are supported) 796 in this session and which of the feedback mechanisms MAY be 797 applied. 799 To do so, the profile "AVPF" MUST be indicated instead of "AVP". 800 Further attributes may be defined to show which type(s) of feedback 801 are supported. 803 Section 4 contains the syntax specification to support RTCP 804 feedback with SDP. Similar specifications for other media session 805 description formats are outside the scope of this document. 807 4. SDP Definitions 809 This section defines a number of additional SDP parameters that are 810 used to describe a session. All of these are defined as media 811 level attributes. 813 4.1 Profile identification 815 The AV profile defined in [4] is referred to as "AVP" in the 816 context of e.g. the Session Description Protocol (SDP) [3]. The 817 profile specified in this document is referred to as "AVPF". 819 Feedback information following the modified timing rules as 820 specified in this document MUST NOT be sent for a particular media 821 session unless the profile for this session indicates the use of 822 the "AVPF" profile (exclusively or jointly with other AV profiles). 824 4.2 RTCP Feedback Capability Attribute 826 A new payload format-specific SDP attribute (for use with 827 "a=fmtp:") is defined to indicate the capability of using RTCP 828 feedback as specified in this document: "rtcp-fb". The "rtcp-fb" 829 attribute MUST only be used as an SDP media attribute and MUST NOT 830 be provided at the session level. The "rtcp-fb" attribute MUST 831 only be used in media sessions for which the "AVPF" is specified. 833 The "rtcp-fb" attribute SHOULD be used to indicate which RTCP 834 feedback messages MAY be used in this media session for the 835 indicated payload type. If several types of feedback are 836 supported, several "a=rtcp-fb:" lines MUST be used. 838 If no "rtcp-fb" attribute is specified the RTP receivers SHOULD 839 assume that the RTP senders only support generic NACKs. In 840 addition, the RTP receivers MAY send feedback using other suitable 841 RTCP feedback packets as defined for the respective media type. 842 The RTP receivers MUST NOT rely on the RTP senders reacting to any 843 of the feedback messages. 845 If one or more "rtcp-fb" attributes are present in a media session 846 description, the RTCP receivers for the media session(s) containing 847 the "rtcp-fb" 849 o MUST ignore all "rtcp-fb" attributes of which they do not fully 850 understand the semantics (i.e. where they do not understand the 851 meaning of all values in the a=fmtp:rtcp-fb line); 853 o SHOULD provide feedback information as specified in this 854 document using any of the RTCP feedback packets as specified in 855 one of the "rtcp-fb" attributes for this media session; and 857 o MUST NOT use other feedback messages than those listed in one of 858 the "rtcp-fb" attribute lines. 860 RTP senders MUST be prepared to receive any kind of RTCP feedback 861 messages and MUST silently discard all those RTCP feedback messages 862 that they do not understand. 864 The syntax of the "rtcp-fb" attribute is as follows (the feedback 865 types and optional parameters are all case sensitive): 867 rtcp-fb-syntax = "a=fmtp:" WS "rtcp-fb" WS rtcp-fb-val 869 rtcp-fb-val = "ack" rtcp-fb-ack-param 870 | "nack" rtcp-fb-nack-param 871 | rtcp-fb-id rtcp-fb-param 873 rtcp-fb-id = 1*(alpha-numeric | "-" | "_") 875 rtcp-fb-param = "app" 876 | byte-string 877 | ; empty 879 rtcp-fb-ack-param = "rpsi" 880 | "app" 881 | byte-string 882 | ; empty 884 rtcp-fb-nack-param = "pli" 885 | "sli" 886 | "rpsi" 887 | "app" 888 | byte-string 889 | ; empty 891 The literals of the above grammar have the following semantics: 893 Feedback type "ack": 895 This feedback type indicates that positive acknowledgements 896 for feedback are supported. 898 The feedback type "ack" MUST only be used if the media session 899 is allowed to operate in ACK mode as defined in 3.6.1.2. 901 Parameters MAY be provided to further distinguish different 902 types of positive acknowledgement feedback. If no parameters 903 are present, the Generic ACK as specified in section 6.2.2 is 904 implied. 906 The parameter "rpsi" indicates the use of Reference Picture 907 Selection Indication feedback as defined in section 6.3.3. 909 If the parameter "app" is specified, this indicates the use of 910 application layer feedback. In this case, additional 911 parameters following "app" MAY be used to further 912 differentiate various types of application layer feedback. 913 This document does not define any parameters specific to 914 "app". 916 Further parameters for "ack" MAY be defined in other 917 documents. 919 Feedback type "nack": 921 This feedback type indicates that negative acknowledgements 922 for feedback are supported. 924 The feedback type "nack", without parameters, indicates use of 925 the General NACK feedback format as defined in section 6.2.1. 927 The following three parameters are defined in this document 928 for use with "nack" in conjunction with the media type 929 "video": 931 o "pli" indicates the use of Picture Loss Indication feedback 932 as defined in section 6.3.1. 933 o "sli" indicates the use of Slice Loss Indication feedback 934 as defined in section 6.3.2. 935 o "rpsi" indicates the use of Reference Picture Selection 936 Indication feedback as defined in section 6.3.3. 938 "app" indicates the use of application layer feedback. 939 Additional parameters after "app" MAY be provided to 940 differentiate different types of application layer feedback. 941 No parameters specific to "app" are defined in this document. 943 Further parameters for "nack" MAY be defined in other 944 documents. 946 Other feedback types : 948 Other documents MAY define additional types of feedback; to 949 keep the grammar extensible for those cases, the rtcp-fb-id is 950 introduced as a placeholder. A new feedback scheme name MUST 951 to be unique (and thus MUST be registered with IANA). Along 952 with a new name, its semantics, packet formats (if necessary), 953 and rules for its operation MUST be specified. 955 Note that it is assumed that more specific information about 956 application layer feedback (as defined in section 6.4) will be 957 conveyed as feedback types and parameters defined elsewhere. 958 Hence, no further provision for any types and parameters is made in 959 this document. 961 Further types of feedback as well as further parameters may be 962 defined in other documents. 964 It is up to the recipients whether or not they send feedback 965 information and up to the sender(s) to make use of feedback 966 provided. 968 4.3 Unicasting vs. Multicasting 970 If a media session description indicates unicast addresses for a 971 particular media type (and does not operate in multi-unicast mode 972 with all recipients listed explicitly but still addressed via 973 unicast), the RTCP feedback MAY operate in ACK feedback mode. 975 If a media session description indicates multicast addresses for a 976 particular media type or a multi-unicast session, ACK feedback mode 977 MUST NOT be used. 979 4.4 RTCP Bandwidth Modifiers 981 The standard RTCP bandwidth assignments as defined in [1] and [2] 982 may be overridden by bandwidth modifiers that explicitly define the 983 maximum RTCP bandwidth. For use with SDP, such modifiers are 984 specified in [4]: "b=RS:" and "b=RR:" MAY be used to assign 985 a different bandwidth (measured in bits per second) to RTP senders 986 and receivers, respectively. The precedence rules of [4] apply to 987 determine the actual bandwidth to be used by senders and receivers. 989 Applications operating knowingly over highly asymmetric links (such 990 as satellite links) SHOULD use this mechanism to reduce the 991 feedback rate for high bandwidth streams to prevent deterministic 992 congestion of the feedback path(s). 994 4.5 Examples 996 Example 1: The following session description indicates a session 997 made up from an audio and a DTMF for point-to-point communication 998 in which the DTMF stream uses Generic ACKs. This session 999 description could be contained in a SIP INVITE, 200 OK, or ACK 1000 message to indicate that its sender is capable of and willing to 1001 receive feedback for the DTMF stream it transmits. 1003 v=0 1004 o=alice 3203093520 3203093520 IN IP4 host.example.com 1005 s=Media with feedback 1006 t=0 0 1007 c=IN IP4 host.example.com 1008 m=audio 49170 RTP/AVPF 0 96 1009 a=rtpmap:0 PCMU/8000 1010 a=rtpmap:96 telephone-event/8000 1011 a=fmtp:96 0-16 1012 a=fmtp:96 rtcp-fb ack 1014 Example 2: The following session description indicates a multicast 1015 video-only session (using H.263+) with the video source accepting 1016 Generic NACKs and Reference Picture Selection. Such a description 1017 may have been conveyed using the Session Announcement Protocol 1018 (SAP). 1020 v=0 1021 o=alice 3203093520 3203093520 IN IP4 host.example.com 1022 s=Multicast video with feedback 1023 t=3203130148 3203137348 1024 m=audio 49170 RTP/AVP 0 1025 c=IN IP4 224.2.1.183 1026 a=rtpmap:0 PCMU/8000 1027 m=video 51372 RTP/AVPF 98 1028 c=IN IP4 224.2.1.184 1029 a=rtpmap:98 H263-1998/90000 1030 a=fmtp:98 rtcp-fb nack 1031 a=fmtp:98 rtcp-fb nack rpsi 1033 Example 3: The following session description defines the same media 1034 session as example 2 but allows for mixed mode operation of AVP and 1035 AVPF RTP entities (see also next section). Note that both media 1036 descriptions use the same addresses; however, two m= lines are 1037 needed to convey information about both applicable RTP profiles. 1039 v=0 1040 o=alice 3203093520 3203093520 IN IP4 host.example.com 1041 s=Multicast video with feedback 1042 t=3203130148 3203137348 1043 m=audio 49170 RTP/AVP 0 1044 c=IN IP4 224.2.1.183 1045 a=rtpmap:0 PCMU/8000 1046 m=video 51372 RTP/AVP 98 1047 c=IN IP4 224.2.1.184 1048 a=rtpmap:98 H263-1998/90000 1049 m=video 51372 RTP/AVPF 98 1050 c=IN IP4 224.2.1.184 1051 a=rtpmap:98 H263-1998/90000 1052 a=fmtp:98 rtcp-fb nack 1053 a=fmtp:98 rtcp-fb nack rpsi 1055 Note that these two m= lines SHOULD be grouped by some appropriate 1056 mechanisms to indicate that both are alternatives actually 1057 conveying the same contents. A sample mechanism by which this can 1058 be achieved is defined in [14]. 1060 5. Interworking and Co-Existence of AVP and AVPF Entities 1062 The AVPF profile defined in this document is an extension of the 1063 AVP profile as defined in [2]. Both profiles follow the same basic 1064 rules (including the upper bandwidth limit for RTCP and the 1065 bandwidth assignments to senders and receivers). Therefore, 1066 senders and receivers of using either of the two profiles can be 1067 mixed in a single session (see e.g. example 3 in section 4.5). 1069 AVP and AVPF are defined in a way that, from a robustness point of 1070 view, the RTP entities do not need to be aware of entities of the 1071 respective other profile: they will not disturb each other's 1072 functioning. However, the quality of the media presented may 1073 suffer. 1075 The following considerations apply to senders and receivers when 1076 used in a combined session. 1078 o AVP entities (senders and receivers) 1080 AVP senders will receive RTCP feedback packets from AVPF 1081 receivers and ignore these packets. They will see occasional 1082 closer spacing of RTCP messages (e.g. violating the 5s rule) by 1083 AVPF entities. As the overall bandwidth constraints are adhered 1084 to by both types of entities, they will still get their share of 1085 the RTCP bandwidth. However, while AVP entities are bound by 1086 the 5s rule, depending on the group size and session bandwidth, 1087 AVPF entities may provide more frequent RTCP reports than AVP 1088 ones will. Also, the overall reporting may decrease slightly as 1089 AVPF entities may send bigger compound RTCP packets (due to the 1090 extra RTCP packets). 1092 o AVPF senders 1094 AVPF senders will receive feedback information only from AVPF 1095 receivers. If they rely on feedback to provide the target media 1096 quality, the quality achieved for AVP receivers may be sub- 1097 optimal. 1099 o AVPF receivers 1101 AVPF receivers SHOULD send immediate or early RTCP feedback 1102 packets only if all (sending) entities in the media session 1103 support AVPF. AVPF receivers MAY send feedback information as 1104 part of regularly scheduled compound RTCP packets following the 1105 timing rules of [1] and [2] also in media sessions operating in 1106 mixed mode. However, the receiver providing feedback MUST NOT 1107 rely on the sender reacting to the feedback at all. 1109 6. Format of RTCP Feedback Messages 1111 This section defines the format of the low delay RTCP feedback 1112 messages. These messages classified into three categories as 1113 follows: 1115 - Transport layer feedback messages 1116 - Payload-specific feedback messages 1117 - Application layer feedback messages 1119 Transport layer feedback messages are intended to transmit general 1120 purpose feedback information, i.e. information independent of the 1121 particular codec or the application in use. The information is 1122 expected to be generated and processed at the transport/RTP layer. 1123 Currently, only a general positive acknowledgement (ACK) and 1124 negative acknowledgement (NACK) message are defined. 1126 Payload-specific feedback messages transport information that is 1127 specific to a certain payload type and will be generated and acted 1128 upon at the codec "layer". This document defines a common header 1129 to be used in conjunction with all payload-specific feedback 1130 messages. The definition of specific messages is left to either 1131 RTP Payload Format specifications or to additional feedback format 1132 documents. 1134 Application layer feedback messages provide a means to 1135 transparently convey feedback from the receiver's to the sender's 1136 application. The information contained in such a message is not 1137 expected to be acted upon at the transport/RTP or the codec layer. 1138 The data to be exchanged between two application instances is 1139 usually defined in the application protocol's specification and 1140 thus can be identified by the application so that there is no need 1141 for additional external information. Hence, this document defines 1142 only a common header to be used along with all application layer 1143 feedback messages. From a protocol point of view, an application 1144 layer feedback message is treated as a special case of a payload- 1145 specific feedback message. 1147 This document defines two transport layer feedback and three 1148 (video) payload-specific feedback messages as well as a single 1149 container for application layer feedback messages. Additional 1150 transport layer and payload specific feedback messages MAY be 1151 defined in other documents and MUST be registered through IANA (see 1152 section IANA considerations). 1154 The general syntax and semantics for the above RTCP feedback 1155 message types is described in the following subsections. 1157 6.1 Common Packet Format for Feedback Message 1159 All feedback message MUST use a common packet format that is 1160 depicted in figure 3: 1162 0 1 2 3 1163 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 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 |V=2|P|0| FMT | PT | length | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | SSRC of packet sender | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | SSRC of media source | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 : Feedback Control Information (FCI) : 1172 : : 1174 Figure 3: Common Packet Format for Feedback Messages 1176 The various fields V, P, SSRC and length are defined in the RTP 1177 specification [2], the respective meaning being summarized below: 1179 version (V): 2 bits 1180 This field identifies the RTP version. The current version is 1181 2. 1183 padding (P): 1 bit 1184 If set, the padding bit indicates that the packet contains 1185 additional padding octets at the end which are not part of the 1186 control information but are included in the length field. 1188 Feedback message type (FMT): 4 bits 1189 This field identifies the type of the feedback message and is 1190 interpreted relative to the RTCP message type (transport, 1191 payload-specific, or application layer feedback). The values 1192 for each of the three feedback types are defined in the 1193 respective sections below. 1195 Payload type (PT): 8 bits 1196 This is the RTCP packet type which identifies the packet as 1197 being an RTCP Feedback Message. Two values are defined (TBA. 1198 by IANA): 1200 Name | Value | Brief Description 1201 ----------+-------+------------------------------------ 1202 RTPFB | 205 | Transport layer feedback message 1203 PSFB | 206 | Payload-specific feedback message 1205 Length: 16 bits 1206 The length of this packet in 32-bit words minus one, including 1207 the header and any padding. This is in line with the 1208 definition of the length field used in RTCP sender and receiver 1209 reports [3]. 1211 SSRC of packet sender: 32 bits 1212 The synchronization source identifier for the originator of 1213 this packet. 1215 SSRC of media source: 32 bits 1216 The synchronization source identifier of the media source that 1217 this piece of feedback information is related to. 1219 Feedback Control Information (FCI): variable length 1220 The following three sections define which additional 1221 information MAY be included in the feedback message for each 1222 type of feedback (further FCI contents MAY be specified in 1223 further documents). Each RTCP feedback packet MUST contain 1224 exactly one FCI field of the types defined in sections 6.2 and 1225 6.3. If multiple FCI fields (even of the same type) need to be 1226 conveyed, then several RTCP feedback packets MUST be generated 1227 and concatenated in the same compound RTCP packet. 1229 6.2 Transport Layer Feedback Messages 1231 Transport Layer Feedback messages are identified by the value RTPFB 1232 as RTCP message type. 1234 Two general purpose transport layer feedback messages are defined 1235 so far: General ACK and General NACK. They are identified by means 1236 of the FMT parameter as follows: 1238 0: forbidden 1239 1: Generic NACK 1240 2: Generic ACK 1241 3-15: reserved 1243 The following two subsections define the packet formats for these 1244 messages. 1246 6.2.1 Generic NACK 1248 The Generic NACK message is identified by PT=RTPFB and FMT=1. 1250 The Generic NACK packet is used to indicate the loss of one or more 1251 RTP packets. The lost packet(s) are identified by the means of a 1252 packet identifier and a bit mask. 1254 The Feedback control information (FCI) field has the following 1255 Syntax (figure 4): 1257 0 1 2 3 1258 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 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | PID | BLP | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 Figure 4: Syntax for the Generic NACK message 1265 Packet ID (PID): 16 bits 1266 The PID field is used to specify a lost packet. Typically, the 1267 RTP sequence number is used for PID as the default format, but 1268 RTP Payload Formats may decide to identify a packet 1269 differently. 1271 bitmask of following lost packets (BLP): 16 bits 1272 The BLP allows for reporting losses of any of the 16 RTP 1273 packets immediately following the RTP packet indicated by the 1274 PID. The BLP's definition is identical to that given in [10]. 1275 Denoting the BLP's least significant bit as bit 1, and its most 1276 significant bit as bit 16, then bit i of the bit mask is set to 1277 1 if the sender has not received RTP packet number PID+i 1278 (modulo 2^16) and the receiver decides this packet is lost; bit 1279 i is set to 0 otherwise. Note that the sender MUST NOT assume 1280 that a receiver has received a packet because its bit mask was 1281 set to 0. For example, the least significant bit of the BLP 1282 would be set to 1 if the packet corresponding to the PID and 1283 the following packet have been lost. However, the sender 1284 cannot infer that packets PID+2 through PID+16 have been 1285 received simply because bits 2 through 15 of the BLP are 0; all 1286 the sender knows is that the receiver has not reported them as 1287 lost at this time. 1289 6.2.2 Generic ACK 1291 The Generic ACK message is identified by PT=RTPFB and FMT=2. 1293 The Generic ACK packet is used to indicate that one or several RTP 1294 packets were received correctly. The received packet(s) are 1295 identified by the means of a packet identifier and a bit mask. 1296 ACKing of a range of consecutive packets is also possible. 1298 The Feedback control information (FCI) field has the following 1299 syntax: 1301 0 1 2 3 1302 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 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | PID |R| BLP/#packets | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 Figure 5: Syntax for the Generic ACK message 1309 Packet ID (1st PID): 16 bits 1310 This PID field is used to specify a correctly received packet. 1311 Typically, the RTP sequence number is used for PID as the 1312 default format, but RTP Payload Formats may decide to identify 1313 a packet differently. 1315 Range of ACKs (R): 1 bit 1316 The R-bit indicates that a range of consecutive packets are 1317 received correctly. If R=1 then the PID field specifies the 1318 first packet of that range and the next field (BLP/#packets) 1319 will carry the number of packets being acknowledged. If R=0 1320 then PID specifies the first packet to be acknowledged and 1321 BLP/#packets provides a bit mask to selectively indicate 1322 individual packets that are acknowledged. 1324 Bit mask of lost packets (BLP)/#packets (PID): 15 bits 1325 The semantics of this field depends on the value of the R-bit. 1327 If R=1, this field is used to identify the number of additional 1328 packets of to be acknowledged: 1330 #packets = - 1332 That is, #packets MUST indicate the number of packet to be 1333 ACKed minus one. In particular, if only a single packet is to 1334 be ACKed and R=1 then #packets MUST be set to 0x0000. 1336 Example: If all packets between and including PIDx = 380 and 1337 PIDy = 422 have been received, the Generic ACK would contain 1338 PID = PIDx = 380 and #packets = PIDy - PID = 42. In case the 1339 PID wraps around, modulo arithmetic is used to calculate the 1340 number of packets. 1342 If R=0, this field carries a bit mask. The BLP allows for 1343 reporting reception of any of the 15 RTP packets immediately 1344 following the RTP packet indicated by the PID. The BLP's 1345 definition is identical to that given in [10] except that, 1346 here, BLP is only 15 bits wide. Denoting the BLP's least 1347 significant bit as bit 1, and its most significant bit as bit 1348 15, then bit i of the bitmask is set to 1 if the sender has 1349 received RTP packet number PID+i (modulo 2^16) and the receiver 1350 decides to ACK this packet; bit i is set to 0 otherwise. If 1351 only the packet indicated by PID is to be ACKed and R=0 then 1352 BLP MUST be set to 0x0000. 1354 6.3 Payload Specific Feedback Messages 1356 Payload-Specific Feedback Messages are identified by the value 1357 PT=PSFB as RTCP message type. 1359 Three payload-specific feedback messages are defined so far plus an 1360 application layer feedback message. They are identified by means 1361 of the FMT parameter as follows: 1363 0: forbidden 1364 1: Picture Loss Indication (PLI) 1365 2: Slice Lost Indication (SLI) 1366 3: Reference Picture Selection Indication (RPSI) 1367 4-14: reserved 1368 15: Application layer feedback message 1370 The following subsections define the packet formats for the 1371 payload-specific messages, section 6.4 defines the application 1372 layer feedback message. 1374 6.3.1 Picture Loss Indication (PLI) 1376 The PLI feedback message is identified by PT=PSFB and FMT=1. 1378 6.3.1.1 Semantics 1380 With the Picture Loss Indication message, a decoder informs the 1381 encoder about the loss of an undefined amount of coded video data 1382 belonging to one or more pictures. When used in conjunction with 1383 any video coding scheme that is based on inter-picture prediction, 1384 an encoder that receives a PLI becomes aware that the prediction 1385 chain may be broken. The sender MAY react to a PLI by transmitting 1386 an intra-picture to achieve resynchronization (making effectively 1387 similar to the FIR as defined in [10]); however, the sender MUST 1388 consider congestion control as outlined in section 7 which MAY 1389 restrict its ability to send an intra frame. 1391 Other RTP payload specifications such as RFC 2032 [10] already 1392 define a feedback mechanism for some for certain codecs. An 1393 application supporting both schemes MUST use the feedback mechanism 1394 defined in this specification when sending feedback. For backward 1395 compatibility reasons, such an application SHOULD also be capable 1396 to receive and react to the feedback scheme defined in the 1397 respective RTP payload format, if this is required by that payload 1398 format. 1400 6.3.1.2 Message Format 1402 PLI does not require parameters. Therefore, the length field MUST 1403 be 2, and there MUST NOT be any Feedback Control Information. 1405 6.3.1.3 Timing Rules 1407 The timing follows the rules outlined in section 3. In systems 1408 that employ both PLI and other types of feedback it may be 1409 advisable to follow the regular RTCP RR timing rules for PLI, since 1410 PLI is not as delay critical as other FB types. 1412 6.3.1.4 Remarks 1414 PLI messages typically trigger the sending of full intra pictures. 1415 Intra pictures are several times larger then predicted (inter) 1416 pictures. Their size is independent of the time they are 1417 generated. In most environments, especially when employing 1418 bandwidth-limited links, the use of an intra picture implies an 1419 allowed delay that is a significant multitude of the typical frame 1420 duration. An example: If the sending frame rate is 10 fps, and an 1421 intra picture is assumed to be 10 times as big as an inter picture, 1422 then a full second of latency has to be accepted. In such an 1423 environment there is no need for a particular short delay in 1424 sending the feedback message. Hence waiting for the next possible 1425 time slot allowed by RTCP timing rules as per [2] does not have a 1426 negative impact on the system performance. 1428 6.3.2 Slice Lost Indication (SLI) 1430 The SLI feedback message is identified by PT=PSFB and FMT=2. 1432 6.3.2.1 Semantics 1434 With the Slice Lost Indication a decoder can inform an encoder that 1435 it has detected the loss or corruption of one or several 1436 consecutive macroblock(s) in scan order (see below). This feedback 1437 message MUST NOT be used for video codecs with non-uniform, 1438 dynamically changeable macroblock sizes such as H.263 with enabled 1439 Annex Q. In such a case, an encoder cannot always identify the 1440 corrupted spatial region. 1442 6.3.2.2 Format 1444 The Slice Lost Indication uses one additional PCI field the 1445 content of which is depicted in figure 6. The length of the 1446 feedback message MUST be set to 3. 1448 0 1 2 3 1449 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 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | First | Number | PictureID | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 Figure 6: Syntax of the Slice Lost Indication (SLI) 1456 First: 13 bits 1457 The macroblock (MB) address of the first lost macroblock. The 1458 MB numbering is done such that the macroblock in the upper left 1459 corner of the picture is considered macroblock number 1 and the 1460 number for each macroblock increases from left to right and 1461 then from top to bottom in raster-scan order (such that if 1462 there is a total of N macroblocks in a picture, the bottom 1463 right macroblock is considered macroblock number N). 1465 Number: 13 bits 1466 The number of lost macroblocks, in scan order as discussed 1467 above. 1469 PictureID: 6 bits 1470 The six least significant bits of the a codec-specific 1471 identifier that is used to reference the picture in which the 1472 loss of the macroblock (s) has occurred. For many video 1473 codecs, the PictureID is identical to the Temporal Reference.. 1475 6.3.2.3 Timing Rules 1477 The efficiency of algorithms using the Slice Lost Indication is 1478 reduced greatly when the Indication is not transmitted in a timely 1479 fashion. Motion compensation propagates corrupted pixels that are 1480 not reported as being corrupted. Therefore, the use of the 1481 algorithm discussed in section 3 is highly recommended. 1483 6.3.2.4 Remarks 1485 The term Slice is defined and used here in the sense of MPEG-1 -- a 1486 consecutive number of macroblocks in scan order. More recent video 1487 coding standards sometimes have a different understanding of the 1488 term Slice. In H.263 (1998), for example, a concept known as 1489 "rectangular Slice" exist. The loss of one Rectangular Slice may 1490 lead to the necessity of sending more than one SLI in order to 1491 precisely identify the region of lost/damaged MBs. 1493 The first field of the FCI defines the first macroblock of a 1494 picture as 1 and not, as one could suspect, as 0. This was done to 1495 align this specification with the comparable mechanism available in 1496 H.245. The maximum number of macroblocks in a picture (2**13 or 1497 8192) corresponds to the maximum picture sizes of most of the ITU-T 1498 and ISO/IEC video codecs. If future video codecs offer larger 1499 picture sizes and/or smaller macroblock sizes, then an additional 1500 feedback message has to be defined. The six least significant bits 1501 of the Temporal Reference field are deemed to be sufficient to 1502 indicate the picture in which the loss occurred. 1504 The reaction to a SLI is not part of this specification. One 1505 typical way of reacting to a SLI is to use intra refresh for the 1506 affected spatial region. 1508 Algorithms were reported that keep track of the regions affected by 1509 motion compensation, in order to allow for a transmission of Intra 1510 macroblocks to all those areas, regardless of the timing of the FB 1511 (see H.263 (2000) Appendix I [13] and [15]). While, when those 1512 algorithms are used, the timing of the FB is less critical then 1513 without, it has to be observed that those algorithms correct large 1514 parts of the picture and, therefore, have to transmit much higher 1515 data volume in case of delayed FBs. 1517 6.3.3 Reference Picture Selection Indication (RPSI) 1519 The RPSI feedback message is identified by PT=PSFB and FMT=3. 1521 6.3.3.1 Semantics 1523 Modern video coding standards such as MPEG-4 visual version 2 [12] 1524 or H.263 version 2 [13] allow to use older reference pictures than 1525 the most recent one for predictive coding. Typically, a first-in- 1526 first-out queue of reference pictures is maintained. If an encoder 1527 has learned about a loss of encoder-decoder synchronicity, a known- 1528 as-correct reference picture can be used. As this reference picture 1529 is temporally further away then usual, the resulting predictively 1530 coded picture will use more bits. 1532 Both MPEG-4 and H.263 define a binary format for the "payload" of 1533 an RPSI message that includes information such as the temporal ID 1534 of the damaged picture and the size of the damaged region. This 1535 bit string is typically small -- a couple of dozen bits --, of 1536 variable length, and self-contained, i.e. contains all information 1537 that is necessary to perform reference picture selection. 1539 Note that both MPEG-4 and H.263 allow the use of RPSI with positive 1540 feedback information as well. That is, pictures (or Slices) are 1541 reported that were decoded without error. Note that any form of 1542 positive feedback MUST NOT be used when in a multicast environment 1543 (reporting positive feedback about individual reference pictures at 1544 RTCP intervals is not expected to be of much use anyway). 1546 6.3.3.2 Format 1548 The FCI for the RPSI message follows the format depicted in figure 1549 7: 1551 0 1 2 3 1552 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 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | PB | Native RPSI bit string defined per codec | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | ... | Padding (0)| 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 Figure 7: Syntax of the Reference Picture Selection Indication 1560 (RPSI) 1562 PB: 8 bits 1563 The number of unused bits required to pad the length of the 1564 RPSI message to a multiple of 32 bits. 1566 Native RPSI bit string: variable length 1567 The RPSI information as natively defined by the video codec. 1569 Padding: #PB bits 1570 A number of bits set to zero to fill up the contents of the 1571 RPSI message to the next 32 bit boundary. The number of 1572 padding bits MUST be indicated by the PB field. 1574 6.3.3.3 Timing Rules 1576 RPS is even more critical to delay then algorithms using SLI. This 1577 is due to the fact that the older the RPS message is, the more bits 1578 the encoder has to spend to re-establish encoder-decoder 1579 synchronicity. See [15] for some information about the overhead of 1580 RPS for certain bit rate/frame rate/loss rate scenarios. 1582 Therefore, RPS messages should typically be sent as soon as 1583 possible, employing the algorithm of section 3. 1585 6.4 Application Layer Feedback Messages 1587 Payload-Specific Feedback Messages are a special case of payload- 1588 specific messages and identified by PT=PSFB and FMT=15. 1590 These messages are used to transport application defined data 1591 directly from the receiver's to the sender's application. The data 1592 that is transported is not identified by the feedback message. 1593 Therefore, the application MUST be able to identify the messages 1594 payload. 1596 Usually, applications define their own set of messages, e.g. 1597 NEWPRED messages in MPEG-4 or feedback messages in H.263/Annex N, 1598 U. These messages do not need any additional information from the 1599 RTCP message. Thus the application message is simply placed into 1600 the FCI field as follows and the length field is set accordingly. 1602 Application Message (FCI): variable length 1603 This field contains the original application message that 1604 should be transported from the receiver to the source. The 1605 format is application dependent. The length of this field is 1606 variable. If the application data is not byte aligned, padding 1607 bits must be added. Identification of padding bits is up to 1608 the application layer and not defined in this specification. 1610 7. Early Feedback and Congestion Control 1612 In the previous sections, the feedback messages were defined as 1613 well as the timing rules according to which to send these messages. 1614 The way to react to the feedback received depends on the 1615 application using the feedback mechanisms and hence is beyond the 1616 scope of this document. 1618 However, across all applications, there is a common requirement for 1619 (TCP-friendly) congestion control on the media stream as defined in 1620 [1] and [2] when operating in a best-effort network environment. 1622 Low delay feedback supports the use of congestion control 1623 algorithms in two ways: 1625 o The potentially more frequent RTCP messages allow the sender to 1626 monitor the network state more closely than with regular RTCP 1627 and therefore enable reacting to upcoming congestion in a more 1628 timely fashion. 1630 o The feedback messages themselves may convey additional 1631 information as input to congestion control algorithms and thus 1632 improve reaction over conventional RTCP. (For example, ACK-based 1633 feedback may even allow to construct closed loop algorithms and 1634 NACK-based systems may provide further information on the packet 1635 loss distribution.) 1637 A congestion control algorithm that shares the available bandwidth 1638 fair with competing TCP connections, e.g. TFRC [16], SHOULD be used 1639 to determine the data rate for the media stream (if the low delay 1640 RTP session is transmitted in a best effort environment). 1642 RTCP feedback messages or RTCP SR/RR packets that indicate recent 1643 packet loss MUST NOT lead to a (mid-term) increase in the 1644 transmission data rate and SHOULD lead to a (short-term) decrease 1645 of the transmission data rate. Such messages SHOULD cause the 1646 sender to adjust the transmission data rate to the order of the 1647 throughput TCP would achieve under similar conditions (e.g. using 1648 TFRC). 1650 RTCP feedback messages or RTCP SR/RR packets that indicate no 1651 recent packet loss MAY cause the sender to increase the 1652 transmission data rate to roughly the throughput TCP would achieve 1653 under similar conditions (e.g. using TFRC). 1655 8. Security Considerations 1657 RTP packets transporting information with the proposed payload 1658 format are subject to the security considerations discussed in the 1659 RTP specification [1] and in the RTP/AVP profile specification [2]. 1660 This profile does not specify any additional security services. 1662 This profile modifies the timing behavior of RTCP and eliminates 1663 the minimum RTCP interval of 5 seconds and allows for earlier 1664 feedback to be provided by receivers. Group members of the 1665 associated RTP session (possibly pretending to represent a large 1666 number of entities) may disturb the operation of RTCP by sending 1667 large numbers of RTCP packets thereby reducing the RTCP bandwidth 1668 available for regular RTCP reporting as well as for early feedback 1669 messages. (Note that an entity need not be member of a multicast 1670 group to cause these effects.) 1672 Feedback information may be suppressed if unknown RTCP feedback 1673 packets are received. This introduces the risk of a malicious 1674 group member reducing early feedback by simply transmitting 1675 payload-specific RTCP feedback packets with random contents that 1676 are neither recognized by any receiver (so they will suppress 1677 feedback) nor by the sender (so no repair actions will be taken). 1679 A malicious group member can also report arbitrary high loss rates 1680 in the feedback information to make the sender throttle the data 1681 transmission and increase the amount of redundancy information or 1682 take other action to deal with the pretended packet loss (e.g. send 1683 fewer frames or decrease audio/video quality). This may result in 1684 a degradation of the quality of the reproduced media stream. 1686 Finally, a malicious group member can act as a large number of 1687 group members and thereby obtain an artificially large share of the 1688 early feedback bandwidth and reduce the reactivity of the other 1689 group members -- possibly even causing them to no longer operate in 1690 immediate or early feedback mode and thus undermining the whole 1691 purpose of this profile. 1693 Senders as well as receivers SHOULD behave conservative when 1694 observing strange reporting behavior. For excessive failure 1695 reporting from one or a few receivers, the sender MAY decide to no 1696 longer consider this feedback when adapting its transmission 1697 behavior for the media stream. In any case, senders and receivers 1698 SHOULD still adhere to the maximum RTCP bandwidth but make sure 1699 that they are capable of transmitting at least regularly scheduled 1700 RTCP packets. Senders SHOULD carefully consider how to adjust 1701 their transmission bandwidth when encountering strange reporting 1702 behavior; they MUST NOT increase their transmission bandwidth even 1703 if ignoring suspicious feedback. 1705 Attacks using false RTCP packets (regular as well as early ones) 1706 can be avoided by authenticating all RTCP messages. This can be 1707 achieved by using the AVPF profile together with the Secure RTP 1708 profile as defined in [17]. 1710 9. IANA Considerations 1712 The feedback profile as an extension to the profile for audio- 1713 visual conferences with minimal control needs to be registered: 1714 "RTP/AVPF". 1716 For the Session Description Protocol, the following "fmtp:" 1717 attribute needs to be registered: "rtcp-fb". 1719 Along with "rtcp-fb", the feedback types "ack" and "nack" need to 1720 be registered. 1722 Along with "nack", the feedback type parameters "sli" and "pli" 1723 need to be registered. 1725 Along with "ack" and "nack", the feedback type parameters "rpsi" 1726 and "app" need to be registered. 1728 Two RTCP Control Packet Types: for the class of transport layer 1729 feedback messages ("RTPFB") and for the class of payload-specific 1730 feedback messages ("PSFB"). Section 6 suggests RTPFB=205 and 1731 PSFB=206 to be added to the RTCP registry. 1733 Within the RTPFB range, three format (FMT) values need to be 1734 registered: 1736 0: forbidden 1737 1: General NACK 1738 2: General ACK 1740 Within the PSFB range, five format (FMT) values need to be 1741 registered: 1743 0: forbidden 1744 1: Picture Loss Indication (PLI) 1745 2: Slice Loss Indication (SLI) 1746 3: Reference Picture Selection Indication (SLI) 1747 15: Application layer feedback (AFB) 1749 10. Acknowledgements 1751 This document is a product of the Audio-Visual Transport (AVT) 1752 Working Group of the IETF. The authors would like to thank Steve 1753 Casner and Colin Perkins for their comments and suggestions as well 1754 as for their responsiveness to numerous questions. 1756 11. Full Copyright Statement 1758 Copyright (C) The Internet Society (2001). All Rights Reserved. 1759 This document and translations of it may be copied and furnished to 1760 others, and derivative works that comment on or otherwise explain 1761 it or assist in its implementation may be prepared, copied, 1762 published and distributed, in whole or in part, without restriction 1763 of any kind, provided that the above copyright notice and this 1764 paragraph are included on all such copies and derivative works. 1766 However, this document itself may not be modified in any way, such 1767 as by removing the copyright notice or references to the Internet 1768 Society or other Internet organizations, except as needed for the 1769 purpose of developing Internet standards in which case the 1770 procedures for copyrights defined in the Internet Standards process 1771 must be followed, or as required to translate it into languages 1772 other than English. 1774 The limited permissions granted above are perpetual and will not be 1775 revoked by the Internet Society or its successors or assigns. 1777 This document and the information contained herein is provided on 1778 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1779 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1780 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1781 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1782 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1784 12. Authors' Addresses 1786 Joerg Ott {sip,mailto}:jo@tzi.org 1787 Uni Bremen TZI 1788 MZH 5180 1789 Bibliothekstr. 1 1790 D-28359 Bremen 1791 Germany 1793 Stephan Wenger stewe@cs.tu-berlin.de 1794 TU Berlin 1795 Sekr. FR 6-3 1796 Franklinstr. 28-29 1797 D-10587 Berlin 1798 Germany 1800 Shigeru Fukunaga 1801 Oki Electric Industry Co., Ltd. 1802 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan 1803 Tel. +81 6 6949 5101 1804 Fax. +81 6 6949 5108 1805 Mail fukunaga444@oki.com 1807 Noriyuki Sato 1808 Oki Electric Industry Co., Ltd. 1809 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan 1810 Tel. +81 6 6949 5101 1811 Fax. +81 6 6949 5108 1812 Mail sato652@oki.com 1814 Koichi Yano 1815 FastForward Networks, 1816 75 Hawthorne St. #601 1817 San Francisco, CA 94105 1818 Tel. +1.415.430.2500 1819 Akihiro Miyazaki 1820 Matsushita Electric Industrial Co., Ltd 1821 1006, Kadoma, Kadoma City, Osaka, Japan 1822 Tel. +81-6-6900-9192 1823 Fax. +81-6-6900-9193 1824 Mail akihiro@isl.mei.co.jp 1826 Koichi Hata 1827 Matsushita Electric Industrial Co., Ltd 1828 1006, Kadoma, Kadoma City, Osaka, Japan 1829 Tel. +81-6-6900-9192 1830 Fax. +81-6-6900-9193 1831 Mail hata@isl.mei.co.jp 1833 Rolf Hakenberg 1834 Panasonic European Laboratories GmbH 1835 Monzastr. 4c, 63225 Langen, Germany 1836 Tel. +49-(0)6103-766-162 1837 Fax. +49-(0)6103-766-166 1838 Mail hakenberg@panasonic.de 1840 Carsten Burmeister 1841 Panasonic European Laboratories GmbH 1842 Monzastr. 4c, 63225 Langen, Germany 1843 Tel. +49-(0)6103-766-263 1844 Fax. +49-(0)6103-766-166 1845 Mail burmeister@panasonic.de 1847 11. Bibliography 1849 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP 1850 - A Transport Protocol for Real-time Applications," Internet 1851 Draft, draft-ietf-avt-rtp-new-11.txt, Work in Progress, 1852 November 2001. 1854 [2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video 1855 Conferences with Minimal Control," Internet Draft draft-ietf- 1856 avt-profile-new-12.txt, November 2001. 1858 [3] M. Handley and V. Jacobson, "SDP: Session Description 1859 Protocol", RFC 2327, April 1998. 1861 [4] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", 1862 Internet Draft draft-ietf-avt-rtcp-bw-05.txt, November 2001. 1864 [5] C. Perkins and O. Hodson, "2354 Options for Repair of 1865 Streaming Media," RFC 2354, June 1998. 1867 [6] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for 1868 Generic Forward Error Correction,", RFC 2733, December 1999. 1870 [7] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, 1871 J.C. Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload 1872 for Redundant Audio Data," RFC 2198, September 1997. 1874 [8] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1875 Levels," RFC 2119, March 1997. 1877 [9] H. Schulzrinne and S. Petrack, "RTP Payload for DTMF Digits, 1878 Telephony Tones and Telephony Signals," RFC 2833, May 2000. 1880 [10] T. Turletti and C. Huitema, "RTP Payload Format for H.261 1881 Video Streams, RFC 2032, October 1996. 1883 [11] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. 1884 Newell, J. Ott, G. Sullivan, S. Wenger, and C. Zhu, "RTP 1885 Payload Format for the 1998 Version of ITU-T Rec. H.263 Video 1886 (H.263+)," RFC 2429, October 1998. 1888 [12] ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - 1889 Coding of audio-visual objects - Part2: Visual", July 2000. 1891 [13] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate 1892 Communication," November 2000. 1894 [14] G. Camarillo, J. Holler, G. Eriksson, H. Schulzrinne, 1895 "Grouping of media lines in SDP," Internet Draft, draft-ietf- 1896 mmusic-fid-05.txt, Work in Progress, September 2001. 1898 [15] B. Girod, N. Faerber, "Feedback-based error control for mobile 1899 video transmission," Proceedings IEEE, Vol. 87, No. 10, pp. 1900 1707 - 1723, October, 1999. 1902 [16] M. Handley, J. Padhye, S. Floyd, J. Widmer, "TCP friendly Rate 1903 Control (TFRC): Protocol Specification," Internet Draft, 1904 draft-ietf-tsvwg-tfrc-03.txt, Work in Progress, July 2001. 1906 [17] M. Baugher, R. Blom, E. Carrarra, D. McGrew, M. Naslund, K. 1907 Norrman, D. Oran, "The Secure Real-Time Transport Protocol," 1908 Internet Draft, draft-ietf-avt-srtp-02.txt, Work in Progress, 1909 November 2001.