idnits 2.17.1 draft-ietf-avt-rtcp-feedback-06.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? == 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 600 has weird spacing: '...ndwidth used ...' == Line 1038 has weird spacing: '...tribute is de...' == Line 1452 has weird spacing: '... to the type...' == Line 1910 has weird spacing: '... These messa...' == Line 2256 has weird spacing: '... Mail sato6...' == (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 (November 2003) is 7468 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) -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-12 ** 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) == Outdated reference: A later version (-09) exists of draft-ietf-avt-srtp-05 -- 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) Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 8 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-06.txt Stephan Wenger/TU Berlin 4 Noriyuki Sato/Oki 5 Carsten Burmeister/Matsushita 6 Jose Rey/Matsushita 8 2 May 2003 9 Expires November 2003 11 Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), 18 its areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 "Copyright (C) The Internet Society (date). All Rights Reserved. 35 Abstract 37 Real-time media streams that use RTP are, to some degree, resilient 38 against packet losses. Receivers may use the base mechanisms of 39 RTCP to report packet reception statistics and thus allow a sender 40 to adapt its transmission behavior in the mid-term as sole means 41 for feedback and feedback-based error repair (besides a few codec- 42 specific mechanisms). This document defines an extension to the 43 Audio-visual Profile (AVP) that enables receivers to provide, 44 statistically, more immediate feedback to the senders and thus 45 allow for short-term adaptation and efficient feedback-based repair 46 mechanisms to be implemented. This early feedback profile (AVPF) 47 maintains the AVP bandwidth constraints for RTCP and preserves 48 scalability to large groups. 50 Table of Contents 52 1 Introduction..................................................3 53 1.1 Definitions.............................................4 54 1.2 Terminology.............................................5 55 2 RTP and RTCP Packet Formats and Protocol Behavior.............6 56 3 Rules for RTCP Feedback.......................................6 57 3.1 Compound RTCP Feedback Packets..........................6 58 3.2 Algorithm Outline.......................................8 59 3.3 Modes of Operation......................................9 60 3.4 Definitions and Algorithm Overview.....................11 61 3.5 AVPF RTCP Scheduling Algorithm.........................14 62 3.5.1 Initialization........................................14 63 3.5.2 Early Feedback Transmission...........................14 64 3.5.3 Regular RTCP Transmission.............................17 65 3.5.4 Other Considerations..................................18 66 3.6 Considerations on the Group Size.......................19 67 3.6.1 ACK mode..............................................19 68 3.6.2 NACK mode.............................................19 69 3.7 Summary of decision steps..............................21 70 3.7.1 General Hints.........................................21 71 3.7.2 Media Session Attributes..............................21 72 4 SDP Definitions..............................................22 73 4.1 Profile identification.................................22 74 4.2 RTCP Feedback Capability Attribute.....................22 75 4.3 RTCP Bandwidth Modifiers...............................26 76 4.4 Examples...............................................26 77 5 Interworking and Co-Existence of AVP and AVPF Entities.......28 78 6 Format of RTCP Feedback Messages.............................29 79 6.1 Common Packet Format for Feedback Messages.............30 80 6.2 Transport Layer Feedback Messages......................32 81 6.2.1 Generic NACK..........................................32 82 6.2.2 Generic ACK...........................................33 83 6.3 Payload Specific Feedback Messages.....................35 84 6.3.1 Picture Loss Indication (PLI).........................35 85 6.3.1.1 Semantics..........................................35 86 6.3.1.2 Message Format.....................................36 87 6.3.1.3 Timing Rules.......................................36 88 6.3.1.4 Remarks............................................36 89 6.3.2 Slice Lost Indication (SLI)...........................37 90 6.3.2.1 Semantics..........................................37 91 6.3.2.2 Format.............................................37 92 6.3.2.3 Timing Rules.......................................38 93 6.3.2.4 Remarks............................................38 95 6.3.3 Reference Picture Selection Indication (RPSI).........39 96 6.3.3.1 Semantics..........................................39 97 6.3.3.2 Format.............................................40 98 6.3.3.3 Timing Rules.......................................40 99 6.4 Application Layer Feedback Messages....................41 100 7 Early Feedback and Congestion Control........................41 101 8 Security Considerations......................................42 102 9 IANA Considerations..........................................43 103 10 Acknowledgements.............................................47 104 11 Authors' Addresses...........................................48 105 12 Bibliography.................................................48 106 12.1 Normative references...................................48 107 12.2 Informative References.................................49 108 13 IPR Notice...................................................50 109 14 Full Copyright Statement.....................................50 111 1 Introduction 113 Real-time media streams that use RTP are, to some degree, resilient 114 against packet losses. RTP [1] provides all the necessary 115 mechanisms to restore ordering and timing present at the sender to 116 properly reproduce a media stream at a recipient. RTP also 117 provides continuous feedback about the overall reception quality 118 from all receivers -- thereby allowing the sender(s) in the mid- 119 term (in the order of several seconds to minutes) to adapt their 120 coding scheme and transmission behavior to the observed network 121 QoS. However, except for a few payload specific mechanisms [6], 122 RTP makes no provision for timely feedback that would allow a 123 sender to repair the media stream immediately: through 124 retransmissions, retro-active FEC control, or media-specific 125 mechanisms for some video codecs, such as reference picture 126 selection. 128 Current mechanisms available with RTP to improve error resilience 129 include audio redundancy coding [13], video redundancy coding [14], 130 RTP-level FEC [11], and general considerations on more robust media 131 streams transmission [12]. These mechanisms may be applied pro- 132 actively (thereby increasing the bandwidth of a given media 133 stream). Alternatively, in sufficiently small groups with small 134 RTTs, the senders may perform repair on-demand, using the above 135 mechanisms and/or media-encoding-specific approaches. Note that 136 "small group" and "sufficiently small RTT" are both highly 137 application dependent. 139 This document specifies a modified RTP Profile for audio and video 140 conferences with minimal control based upon [1] and [2] by means of 141 two modifications/additions: to achieve timely feedback, the 142 concept of Early RTCP messages as well as algorithms allowing for 143 low delay feedback in small multicast groups (and preventing 144 feedback implosion in large ones) are introduced. Special 145 consideration is given to point-to-point scenarios. A small number 146 of general-purpose feedback messages as well as a format for codec 147 and application-specific feedback information are defined for 148 transmission in the RTCP payloads. 150 1.1 Definitions 152 The definitions from RTP/RTCP [1] and the RTP Profile for Audio and 153 Video Conferences with Minimal Control [2] apply. In addition, the 154 following definitions are used in this document: 156 Early RTCP mode: 157 The mode of operation in which a receiver of a media stream 158 is often (but not always) capable of reporting events of 159 interest back to the sender close to their occurrence. In 160 Early RTCP mode, RTCP packets are transmitted according to 161 the timing rules defined in this document. 163 Early RTCP packet: 164 An Early RTCP packet is a packet which is transmitted 165 earlier than would be allowed if following the scheduling 166 algorithm of [1], the reason being an "event" observed by a 167 receiver. Early RTCP packets may be sent in Immediate 168 Feedback and in Early RTCP mode. Sending an Early RTCP 169 packet is also referred to as sending Early Feedback in 170 this document. 172 Event: 173 An observation made by the receiver of a media stream that 174 is (potentially) of interest to the sender -- such as a 175 packet loss or packet reception, frame loss, etc. -- and 176 thus useful to be reported back to the sender by means of a 177 Feedback message. 179 Feedback (FB) message: 180 An RTCP message as defined in this document is used to 181 convey information about events observed at a receiver -- 182 in addition to long-term receiver status information which 183 is carried in RTCP RRs -- back to the sender of the media 184 stream. For the sake of clarity, feedback message is 185 referred to as FB message throughout this document. 187 Feedback (FB) threshold: 188 The FB threshold indicates the transition between Immediate 189 Feedback and Early RTCP mode. For a multiparty scenario, 190 the FB threshold indicates the maximum group size at which, 191 on average, each receiver is able to report each event back 192 to the sender(s) immediately, i.e. by means of an Early 193 RTCP packet without having to wait for its regularly 194 scheduled RTCP interval. This threshold is highly 195 dependent on the type of feedback to be provided, network 196 QoS (e.g. packet loss probability and distribution), codec 197 and packetization scheme in use, the session bandwidth, and 198 application requirements. Note that the algorithms do not 199 depend on all senders and receivers agreeing on the same 200 value for this threshold. It is merely intended to provide 201 conceptual guidance to application designers and is not 202 used in any calculations. For the sake of clarity, the term 203 feedback threshold is referred to as FB threshold 204 throughout this document. 206 Immediate Feedback mode: 207 A mode of operation in which each receiver of a media 208 stream is, statistically, capable of reporting each event 209 of interest immediately back to the media stream sender. 210 In Immediate Feedback mode, RTCP FB messages are 211 transmitted according to the timing rules defined in this 212 document. 214 Media packet: 215 A media packet is an RTP packet. 217 Regular RTCP mode: 218 Mode of operation in which no preferred transmission of FB 219 messages is allowed. Instead, RTCP messages are sent 220 following the rules of [1]. Nevertheless, such RTCP 221 messages may contain feedback information as defined in 222 this document. 224 Regular RTCP packet: 225 An RTCP packet that is not sent as an Early RTCP packet. 227 1.2 Terminology 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 230 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 231 in this document are to be interpreted as described in RFC 2119 232 [5]. 234 2 RTP and RTCP Packet Formats and Protocol Behavior 236 The rules defined in [2] also apply to this profile except for 237 those rules mentioned in the following: 239 RTCP packet types: 240 Two additional RTCP packet types are registered and the 241 corresponding FB messages to convey feedback information 242 are defined in section 6 of this memo. 244 RTCP report intervals: 245 This document describes three modes of operation which 246 influence the RTCP report intervals (see section 3.2 of 247 this memo). In Regular RTCP mode, all rules from [1] apply 248 except for the minimal interval of five seconds between two 249 RTCP reports from the same RTP entity. In both Immediate 250 Feedback and Early RTCP modes, the minimal interval of five 251 seconds between two RTCP reports is dropped and, 252 additionally, the rules specified in section 3 of this memo 253 apply if RTCP packets containing FB messages (defined in 254 section 4 of this memo) are to be transmitted. 256 The rules set forth in [1] may be overridden by session 257 descriptions specifying different parameters (e.g. for the 258 bandwidth share assigned to RTCP for senders and receivers, 259 respectively). For sessions defined using the Session 260 Description Protocol (SDP) [3], the rules of [4] apply. 262 Congestion control: 263 The same basic rules as detailed in [2] apply. Beyond 264 this, in section 5, further consideration is given to the 265 impact of feedback and a sender's reaction to FB messages. 267 3 Rules for RTCP Feedback 269 3.1 Compound RTCP Feedback Packets 271 Two components constitute RTCP-based feedback as described in this 272 document: 274 o Status reports are contained in SR/RR packets and are 275 transmitted at regular intervals as part of compound RTCP 276 packets (which also include SDES and possibly other messages); 277 these status reports provide an overall indication for the 278 recent reception quality of a media stream. 280 o FB messages as defined in this document that indicate loss or 281 reception of particular pieces of a media stream (or provide 282 some other form of rather immediate feedback on the data 283 received). Rules for the transmission of FB messages are newly 284 introduced in this document. 286 RTCP FB messages are just another RTCP packet type (see section 287 4). Therefore, multiple FB messages MAY be combined in a single 288 compound RTCP packet and they MAY also be sent combined with other 289 RTCP packets. 291 Compound RTCP packets containing FB messages as defined in this 292 document MUST contain RTCP packets in the order defined in [1]: 294 o OPTIONAL encryption prefix that MUST be present if the RTCP 295 packet(s) is to be encrypted. 296 o MANDATORY SR or RR. 297 o MANDATORY SDES which MUST contain the CNAME item; all other SDES 298 items are OPTIONAL. 299 o One or more FB messages. 301 The FB message(s) MUST be placed in the compound packet after RR 302 and SDES RTCP packets defined in [1]. The ordering with respect to 303 other RTCP extensions is not defined. 305 Two types of compound RTCP packets carrying feedback packets are 306 used in this document: 308 a) Minimal compound RTCP feedback packet 310 A minimal compound RTCP feedback packet MUST contain only the 311 mandatory information as listed above: encryption prefix if 312 necessary, exactly one RR or SR, exactly one SDES with only the 313 CNAME item present, and the FB message(s). This is to minimize 314 the size of the RTCP packet transmitted to convey feedback and 315 thus to maximize the frequency at which feedback can be 316 provided while still adhering to the RTCP bandwidth 317 limitations. 319 This packet format SHOULD be used whenever an RTCP FB message 320 is sent as part of an Early RTCP packet. This packet type is 321 referred to as minimal compound RTCP packet in this document. 323 b) (Full) compound RTCP feedback packet 325 A (full) compound RTCP feedback packet MAY contain any 326 additional number of RTCP packets (additional RRs, further SDES 327 items, etc.). The above ordering rules MUST be adhered to. 329 This packet format MUST be used whenever an RTCP FB message is 330 sent as part of a Regular RTCP packet or in Regular RTCP mode. 331 It MAY also be used to send RTCP FB messages in Immediate 332 Feedback or Early RTCP mode. This packet type is referred to as 333 full compound RTCP packet in this document. 335 RTCP packets that do not contain FB messages are referred to as 336 non-FB RTCP packets. Such packets MUST follow the format rules in 337 [1]. 339 3.2 Algorithm Outline 341 FB messages are part of the RTCP control streams and thus subject 342 to the RTCP bandwidth constraints. This means, in particular, that 343 it may not be possible to report an event observed at a receiver 344 immediately back to the sender. However, the value of feedback 345 given to a sender typically decreases over time -- in terms of the 346 media quality as perceived by the user at the receiving end and/or 347 the cost required to achieve media stream repair. 349 RTP [1] and the commonly used RTP profile [2] specify rules when 350 compound RTCP packets should be sent. This document modifies those 351 rules in order to allow applications to timely report events (e.g. 352 loss or reception of RTP packets) and to accommodate algorithms 353 that use FB messages. 355 The modified RTCP transmission algorithm can be outlined as 356 follows: As long as no FB messages have to be conveyed, compound 357 RTCP packets are sent following the rules of RTP [1] -- except that 358 the five second minimum interval between RTCP reports is not 359 enforced. Hence, the interval between RTCP reports is only derived 360 from the average RTCP packet size and the RTCP bandwidth share 361 available to the RTP/RTCP entity. Optionally, a minimum interval 362 between Regular RTCP packets may be enforced. 364 If a receiver detects the need to send an FB message, it may do so 365 earlier than the next regular RTCP reporting interval (for which it 366 would be scheduled following the above regular RTCP algorithm). 367 Feedback suppression is used to avoid feedback implosion in 368 multiparty sessions: The receiver waits for a (short) random 369 dithering interval to check whether it sees a corresponding FB 370 message from any other receiver reporting the same event. Note 371 that for point-to-point sessions there is no such delay. If a 372 corresponding FB message from another member is received, this 373 receiver refrains from sending the FB message and continues to 374 follow the Regular RTCP transmission schedule. In case the 375 receiver has not yet seen a corresponding FB message from any other 376 member, it checks whether it is allowed to send Early feedback. If 377 sending Early feedback is permissible , the receiver sends the FB 378 message as part of a minimal compound RTCP packet. The permission 379 to send Early feedback depends on the type of the previous RTCP 380 packet sent by this receiver and the time the previous Early 381 feedback message was sent. 383 FB messages may also be sent as part of full compound RTCP packets 384 which are transmitted as per [1] (except for the five second lower 385 bound) in regular intervals. 387 3.3 Modes of Operation 389 RTCP-based feedback may operate in one of three modes (figure 1) as 390 described below. The mode of operation is just an indication of 391 whether or not the receiver will, on average, be able to report all 392 events to the sender in a timely fashion; the mode does not 393 influence the algorithm used for scheduling the transmission of FB 394 messages. And, depending on the reception quality and the locally 395 monitored state of the RTP session, individual receivers may not 396 (and not have to) agree on a common perception on the current mode 397 of operation. 399 a) Immediate Feedback mode: the group size is below the FB 400 threshold which gives each receiving party sufficient bandwidth 401 to transmit the RTCP feedback packets for the intended purpose. 402 This means that, for each receiver, there is enough bandwidth 403 to report each event by means of a virtually "immediate" RTCP 404 feedback packet. 406 The group size threshold is a function of a number of 407 parameters including (but not necessarily limited to): the type 408 of feedback used (e.g. ACK vs. NACK), bandwidth, packet rate, 409 packet loss probability and distribution, media type, codec, 410 and the (worst case or observed) frequency of events to report 411 (e.g. frame received, packet lost). 413 As a rough estimate, let N be the average number of events to 414 be reported per interval T by a receiver, B the RTCP bandwidth 415 fraction for this particular receiver and R the average RTCP 416 packet size, then the receiver operates in Immediate Feedback 417 mode as long as N<=B*T/R. 419 b) Early RTCP mode: In this mode, the group size and other 420 parameters no longer allow each receiver to react to each event 421 that would be worth (or needed) to report. But feedback can 422 still be given sufficiently often so that it allows the sender 423 to adapt the media stream transmission accordingly and thereby 424 increase the overall media playback quality. 426 Using the above notation, Early RTCP mode can be roughly 427 characterized by N > B*T/R as "lower bound". An estimate for 428 an upper bound is more difficult. Setting N=1, we obtain for a 429 given R and B the interval T = R/B as average interval between 430 events to be reported. This information can be used as a hint 431 to determine whether or not early transmission of RTCP packets 432 is useful. 434 c) Regular RTCP Mode: From some group size upwards, it is no 435 longer useful to provide feedback for individual events from 436 receivers at all -- because of the time scale in which the 437 feedback could be provided and/or because in large groups the 438 sender(s) have no chance to react to individual feedback 439 anymore. 441 No precise group size threshold can be specified at which this 442 mode starts but, obviously, this boundary matches the upper 443 bound of the Early RTCP mode as specified in item b). 445 As the feedback algorithm described in this document scales 446 smoothly, there is no need for an agreement among the participants 447 on the precise values of the respective FB thresholds within the 448 group. Hence the borders between all these modes are soft. 450 ACK 451 feedback 452 V 453 :<- - - - NACK feedback - - - ->// 454 : 455 : Immediate || 456 : Feedback mode ||Early RTCP mode Regular RTCP mode 457 :<=============>||<=============>//<=================> 458 : || 459 -+---------------||---------------//------------------> group size 460 2 || 461 Application-specific FB Threshold 462 = f(data rate, packet loss, codec, ...) 464 Figure 1: Modes of operation 466 As stated before, the respective FB thresholds depend on a number 467 of technical parameters (of the codec, the transport, the type of 468 feedback used, etc.) but also on the respective application 469 scenarios. Section 3.6 provides some useful hints (but no precise 470 calculations) on estimating these thresholds. 472 3.4 Definitions and Algorithm Overview 474 The following pieces of state information need to be maintained per 475 receiver (largely taken from [1]). Note that all variables (except 476 in item g) below) are calculated independently at each receiver. 477 Therefore, their local values may differ at any given point in 478 time. 480 a) Let "senders" be the number of active senders in the RTP 481 session. 483 b) Let "members" be the current estimate of the number of receivers 484 in the RTP session. 486 c) Let tn and tp be the time for the next (last) scheduled 487 RTCP RR transmission calculated prior to reconsideration. 489 d) Let Tmin be the minimal interval between RTCP packets as per 490 [1]. Unlike in [1], the initial Tmin is set to 1 second to 491 allow for some group size sampling before sending the first RTCP 492 packet. After the first RTCP packet is sent, Tmin is set to 0. 494 e) Let T_rr be the interval after which, having just sent a 495 regularly scheduled RTCP packet, a receiver would schedule the 496 transmission of its next Regular RTCP packet. This value is 497 obtained following the rules of [1] but with Tmin as defined in 498 this document: T_rr = T (the "calculated interval" as defined in 499 [1]) with tn = tp + T. T_rr always refers to the last value of 500 T that has been computed (because of reconsideration or to 501 determine tn). T_rr is also referred to as Regular RTCP interval 502 in this document. 504 f) Let t0 be the time at which an event that is to be reported is 505 detected by a receiver. 507 g) Let T_dither_max be the maximum interval for which an RTCP 508 feedback packet MAY be additionally delayed to prevent 509 implosions in multiparty sessions; the value for T_dither_max is 510 dynamically calculated based upon T_rr. For point-to-point 511 sessions (i.e. sessions with exactly two members with no change 512 in the group size expected, e.g. unicast streaming sessions), 513 T_dither_max is set to 0. 515 h) Let T_max_fb_delay be the upper bound within which feedback to 516 an event needs to be reported back to the sender to be useful at 517 all. This value is application-specific; and no values are 518 defined in this document. 520 i) Let te be the time for which a feedback packet is scheduled. 522 j) Let T_fd be the actual (randomized) delay for the transmission 523 of FB message in response to an event at time t0. 525 k) Let allow_early be a Boolean variable that indicates whether the 526 receiver currently may transmit FB messages prior to its next 527 regularly scheduled RTCP interval tn. This variable is used to 528 throttle the feedback sent by a single receiver. allow_early is 529 set to FALSE after Early feedback transmission and is set to 530 TRUE as soon as the next Regular RTCP transmission takes place. 532 l) Let avg_rtcp_size be the moving average on the RTCP packet size 533 as defined in [1]. 535 m) Let T_rr_interval be an OPTIONAL minimal interval to be used 536 between Regular RTCP packets. If T_rr_interval == 0, then this 537 variable does not have any impact on the overall operation of 538 the RTCP feedback algorithm. If T_rr_interval != 0 then the 539 next Regular RTCP packet will not be scheduled T_rr after the 540 last Regular RTCP transmission (i.e. at tp+T_rr). Instead, the 541 next Regular RTCP packet will be delayed until at least 542 T_rr_interval after the last Regular RTCP transmission, i.e. it 543 will be scheduled at or later than tp+T_rr_interval. Note that 544 T_rr_interval does not affect the calculation of T_rr and tp; 545 instead, Regular RTCP packets scheduled for transmission before 546 tp+T_rr_interval will be suppressed if, for example, they do not 547 contain any FB messages. The T_rr_interval does not affect 548 transmission scheduling of Early RTCP packets. 550 NOTE: Providing T_rr_interval as an independent variable is 551 meant to minimize Regular RTCP feedback (and thus bandwidth 552 consumption) as needed by the application while additionally 553 allowing the use of more frequent Early RTCP packets to provide 554 timely feedback. This goal could not be achieved by reducing 555 the overall RTCP bandwidth as RTCP bandwidth reduction would 556 also impact the frequency of Early feedback. 558 n) Let t_rr_last be the point in time at which the last Regular 559 RTCP packet has been scheduled and sent, i.e. has not been 560 suppressed due to T_rr_interval. 562 o) Let T_retention be the time window for which past FB messages 563 are stored by an AVPF entity. This is to ensure that feedback 564 suppression also works for entities that have received FB 565 messages from other entities prior to noticing the feedback 566 event itself. T_retention MUST be set to at least 2 seconds. 568 p) Let M*Td be the timeout value for a receiver to be considered 569 inactive (as defined in [1]). 571 The feedback situation for an event to report at a receiver is 572 depicted in figure 2 below. At time t0, such an event (e.g. a 573 packet loss) is detected at the receiver. The receiver decides -- 574 based upon current bandwidth, group size, and other application- 575 specific parameters -- that a FB message needs to be sent back to 576 the sender. 578 To avoid an implosion of feedback packets in multiparty sessions, 579 the receiver MUST delay the transmission of the RTCP feedback 580 packet by a random amount of time T_fd (with the random number 581 evenly distributed in the interval [0, T_dither_max]). 582 Transmission of the compound RTCP packet MUST then be scheduled for 583 te = t0 + T_fd. 585 The T_dither_max parameter is derived from the Regular RTCP 586 interval, T_rr, which, in turn, is based upon the group size. 588 For a certain application scenario, a receiver may determine an 589 upper bound for the acceptable local delay of FB messages: 590 T_max_fb_delay. If an a priori estimation or the actual 591 calculation of T_dither_max indicates that this upper bound MAY be 592 violated (e.g. because T_dither_max > T_max_fb_delay), the receiver 593 MAY decide not to send any feedback at all because the achievable 594 gain is considered insufficient. 596 If an Early RTCP packet is scheduled, the time slot for the next 597 Regular RTCP packet MUST be updated accordingly to a new tn: 598 tn=tp+2*T_rr and so MUST tp: tp=tp+T_rr afterwards. This is to 599 ensure that the short-term average RTCP bandwidth used with Early 600 feedback does not exceed the bandwidth used without Early 601 feedback. 603 event to 604 report 605 detected 606 | 607 | RTCP feedback range 608 | (T_max_fb_delay) 609 vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) ) 610 |---+--------+-------------+-----+------------| |--------+---> 611 | | | | ( ( | 612 | t0 te | 613 tp tn 614 \_______ ________/ 615 \/ 616 T_dither_max 618 Figure 2: Event report and parameters for Early RTCP scheduling 619 3.5 AVPF RTCP Scheduling Algorithm 621 Let S0 be an active sender (out of S senders) and let N be the 622 number of receivers with R being one of these receivers. 624 Assume that R has verified that using feedback mechanisms is 625 reasonable at the current constellation (which is highly 626 application specific and hence not specified in this document). 628 Assume further that T_rr_interval is 0, if no minimal interval 629 between Regular RTCP packets is to be enforced, or T_rr_interval is 630 set to some meaningful value, as given by the application. This 631 value then denotes the minimal interval between Regular RTCP 632 packets. 634 With this, a receiver R MUST use the following rules for 635 transmitting one or more FB messages as minimal or full compound 636 RTCP packet: 638 3.5.1 Initialization 640 Initially, R MUST set allow_early = TRUE and t_rr_last = NaN (Not- 641 a-Number, i.e. some invalid value that can be distinguished from a 642 valid time). 644 Furthermore, the initialization of the RTCP variables as per [1] 645 applies except that the initial value for Tmin. For a point-to- 646 point session, the initial Tmin is set to 0. For a multiparty 647 session, Tmin is initialized to 1.0 seconds. 649 3.5.2 Early Feedback Transmission 651 Assume that R had scheduled the last Regular RTCP RR packet for 652 transmission at tp (and sent or suppressed this packet at tp) and 653 has scheduled the next transmission (including possible 654 reconsideration as per [1]) for tn = tp + T_rr. Assume also that 655 the last Regular RTCP packet transmission has occurred at 656 t_rr_last. 658 The Early Feedback algorithm then comprises the following steps: 660 1. At time t0, R detects the need to transmit one or more FB 661 messages, e.g. because media "units" need to be ACKed or NACKed, 662 and finds that providing the feedback information is potentially 663 useful for the sender. 665 2. R first checks whether there is already a compound RTCP packet 666 containing one or more FB messages scheduled for transmission 667 (either as Early or as Regular RTCP packet). 669 2.a) If so, the new FB message MUST be included in the 670 scheduled packet; the scheduling of the waiting compound RTCP 671 packet MUST remain unchanged. When doing so, the available 672 feedback information SHOULD be merged to produce as few FB 673 messages as possible. This completes the course of immediate 674 actions to be taken. 676 2.b) If no compound RTCP packet is already scheduled for 677 transmission, a new (minimal or full) compound RTCP packet 678 MUST be created and the minimal interval for T_dither_max MUST 679 be chosen as follows: 681 i) If the session is a point-to-point session then 682 T_dither_max = 0. 684 ii) If the session is a multiparty session then 686 T_dither_max = l * T_rr 688 with l=0.5. 690 The values given above for T_dither_max are minimal values. 691 Application-specific feedback considerations may make it 692 worthwhile to increase T_dither_max beyond this value. This 693 is up to the discretion of the implementer. 695 3. Then, R MUST check whether its next Regular RTCP packet would be 696 within the time bounds for the Early RTCP packet triggered at t0, 697 i.e. if t0 + T_dither_max > tn. 699 3.a) If so, an Early RTCP packet MUST NOT be scheduled; 700 instead the FB message(s) MUST be stored to be included in the 701 Regular RTCP packet scheduled for tn. This completes the 702 course of immediate actions to be taken. 704 3.b) Otherwise, the following steps are carried out. 706 4. R MUST check whether it is allowed to transmit an Early RTCP 707 packet, i.e. allow_early == TRUE, or not. 709 4.a) If allow_early == FALSE then R MUST check the time for the 710 next scheduled Regular RTCP packet: 712 1. If tn - t0 < T_max_fb_delay then the feedback could 713 still be useful for the sender, despite the late 714 reporting. Hence, R MAY create an RTCP FB message to 715 be included in the Regular RTCP packet for 716 transmission at tn. 718 2. Otherwise, R MUST discard the RTCP FB message. 720 This completes the immediate course of actions to be taken. 722 4.b) If allow_early == TRUE then R MUST schedule an Early RTCP 723 packet for te = t0 + RND * T_dither_max with RND being a pseudo 724 random function evenly distributed between 0 and 1. 726 5. R MUST detect overlaps in FB messages received from other 727 members of the RTP session and the FB messages R wants to send. 728 Therefore, while member of the RTP session, R MUST continuously 729 monitor the arrival of (minimal) compound RTCP packets and store 730 each FB message contained in these RTCP packets for at least 731 T_retention. When scheduling the transmission of its own FB 732 message following steps 1. through 4. above, R MUST check each of 733 the stored and newly received FB messages from the RTCP packets 734 received during the interval [t0 - T_retention ; te] and act as 735 follows: 737 5.a) If R understands the received FB message's semantics and 738 the message contents is a superset of the feedback R wanted to 739 send then R MUST discard its own FB message and MUST re- 740 schedule the next Regular RTCP packet transmission for tn (as 741 calculated before). 743 5.b) If R understands the received FB message's semantics and 744 the message contents is not a superset of the feedback R wanted 745 to send then R SHOULD transmit its own FB message as scheduled. 746 If there is an overlap between the feedback information to send 747 and the feedback information received, the amount of feedback 748 transmitted is up to R: R MAY leave its feedback information to 749 be sent unchanged, R MAY as well eliminate any redundancy 750 between its own feedback and the feedback received so far from 751 other session members. 753 5.c) If R does not understand the received FB message's 754 semantics, R MAY keep its own FB message scheduled as an Early 755 RTCP packet, or R MAY re-schedule the next Regular RTCP packet 756 transmission for tn (as calculated before) and MAY append the 757 FB message to the now regularly scheduled RTCP message. 759 Note: With 5.c), receiving unknown FB messages may not lead to 760 feedback suppression at a particular receiver. As a 761 consequence, a given event may cause M different types of FB 762 messages (which are all appropriate but not mutually 763 understood) to be scheduled, so that a "large" receiver group 764 may effectively be partitioned into at most M groups. Among 765 members of each of these M groups, feedback suppression will 766 occur following 5.a and 5.b but no suppression will happen 767 across groups. As a result, O(M) RTCP FB messages may be 768 received by the sender. Hence, there is a chance for a very 769 limited feedback implosion. However, as sender(s) and all 770 receivers make up the same application using the same (set of) 771 codecs in the same RTP session, only little divergence in 772 semantics for FB messages can safely be assumed and, therefore, 773 M is assumed to be small in the general case. Given further 774 that the O(M) FB messages are randomly distributed over a time 775 interval of T_dither_max we find that the resulting limited 776 number of extra compound RTCP packets (a) is assumed not to 777 overwhelm the sender and (b) should be conveyed as all contain 778 complementary pieces of information. 780 6. If R's FB message(s) was not suppressed by other receiver FB 781 messages as per 5., when te is reached, R MUST transmit the 782 (minimal) compound RTCP packet containing its FB message(s). R 783 then MUST set allow_early = FALSE, MUST recalculate tn = tp + 784 2*T_rr, and MUST set tp to the previous tn. As soon as the newly 785 calculated tn is reached, regardless whether R sends its next 786 Regular RTCP packet or suppresses it because of T_rr_interval, it 787 MUST set allow_early = TRUE again. 789 3.5.3 Regular RTCP Transmission 791 Full compound RTCP packets MUST be sent in regular intervals. 792 These packets MAY also contain one or more FB messages. 793 Transmission of Regular RTCP packets is scheduled as follows: 795 If T_rr_interval == 0 then the transmission MUST follow the rules 796 as specified in section 3.2 and 3.4 of this document and MUST 797 adhere to the adjustments of tn specified in section 3.5.2, i.e. 798 skip one regular transmission if an Early RTCP packet transmission 799 has occurred. Timer reconsideration takes place when tn is reached 800 as per [1]. The Regular RTCP packet is transmitted after timer 801 reconsideration. Whenever a Regular RTCP packet is sent or 802 suppressed, allow_early MUST be set to TRUE and tp, tn MUST be 803 updated as per [1]. After the first transmission of a Regular RTCP 804 packet, Tmin MUST be set to 0. 806 If T_rr_interval != 0 then the calculation for the transmission 807 times MUST follow the rules as specified in section 3.2 and 3.4 of 808 this document and MUST adhere to the adjustments of tn specified in 809 section 3.5.2 (i.e. skip one regular transmission if an Early RTCP 810 transmission has occurred). Timer reconsideration takes place when 811 tn is reached as per [1]. After timer reconsideration, the 812 following actions are taken: 814 1. If no Regular RTCP packet has been sent before (i.e. if 815 t_rr_last == NaN) then a Regular RTCP packet MUST be 816 scheduled. Stored FB messages MAY be included in the 817 Regular RTCP packet. After the scheduled packet has been 818 sent, t_rr_last MUST be set to tn. Tmin MUST be set to 0. 820 2. Otherwise, a temporary value T_rr_current_interval is 821 calculated as follows: 823 T_rr_current_interval = RND*T_rr_interval 825 with RND being a pseudo random function evenly distributed 826 between 0.5 and 1.5. This dithered value is used to 827 determine one of the following alternatives: 829 2a) If t_rr_last + T_rr_current_interval <= tn then a 830 Regular RTCP packet MUST be scheduled. Stored RTCP FB 831 messages MAY be included in the Regular RTCP packet. 832 After the scheduled packet has been sent, t_rr_last 833 MUST be set to tn. 835 2b) If t_rr_last + T_rr_current_interval > tn and RTCP FB 836 messages have been stored and are awaiting 837 transmission, an RTCP packet MUST be scheduled for 838 transmission at tn. This RTCP packet MAY be a minimal 839 or a Regular RTCP packet (at the discretion of the 840 implementer) and the compound RTCP packet MUST include 841 the stored RTCP FB message(s). t_rr_last MUST remain 842 unchanged. 844 2c) Otherwise (if t_rr_last + T_rr_current_interval > tn 845 but no stored RTCP FB messages are awaiting 846 transmission), the compound RTCP packet MUST NOT be 847 scheduled. t_rr_last MUST remain unchanged. 849 In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST 850 be set to TRUE (possibly after sending the Regular RTCP packet) and 851 tp and tn MUST be updated following the rules of [1] except for the 852 five second minimum. 854 3.5.4 Other Considerations 856 If T_rr_interval != 0 then the timeout calculation for RTP/AVPF 857 entities (section 6.3.5 of [1]) MUST be modified to use 858 T_rr_interval instead of Tmin for computing Td and thus M*Td. 860 Whenever a compound RTCP packet is sent or received -- minimal or 861 full compound, Early or Regular -- the avg_rtcp_size variable MUST 862 be updated accordingly (see [1]) and subsequent computations of tn 863 MUST use the new avg_rtcp_size. 865 3.6 Considerations on the Group Size 867 This section provides some guidelines to the group sizes at which 868 the various feedback modes may be used. 870 3.6.1 ACK mode 872 The RTP session MUST have exactly two members and this group size 873 MUST NOT grow, i.e. it MUST be point-to-point communications. 874 Unicast addresses SHOULD be used in the session description. 876 For unidirectional as well as bi-directional communication between 877 two parties, 2.5% of the RTP session bandwidth is available for 878 RTCP traffic from the receivers including feedback. For a 64 879 kbit/s stream this yields 1,600 bit/s for RTCP. If we assume an 880 average of 96 bytes (=768 bits) per RTCP packet a receiver can 881 report 2 events per second back to the sender. If acknowledgments 882 for 10 events are collected in each FB message then 20 events can 883 be acknowledged per second. At 256 kbit/s 8 events could be 884 reported per second; thus the ACKs may be sent in a finer 885 granularity (e.g. only combining three ACKs per FB message). 887 From 1 Mbit/s upwards, a receiver would be able to acknowledge each 888 individual frame (not packet!) in a 30 fps video stream. 890 ACK strategies MUST be defined to work properly with these 891 bandwidth limitations. An indication whether or not ACKs are 892 allowed for a session and, if so, which ACK strategy should be 893 used, MAY be conveyed by out-of-band mechanisms, e.g. media- 894 specific attributes in a session description using SDP. 896 3.6.2 NACK mode 898 Negative acknowledgements (and other types of feedback exhibiting 899 similar reporting characteristics) MUST be used for all sessions 900 with a group size that may grow larger than two. Of course, NACKs 901 MAY be used for point-to-point communications as well. 903 Whether or not the use of Early RTCP packets should be considered 904 depends upon a number of parameters including session bandwidth, 905 codec, special type of feedback, number of senders and receivers. 907 The most important parameters when determining the mode of 908 operation are the allowed minimal interval between two compound 909 RTCP packets (T_rr) and the average number of events that 910 presumably need reporting per time interval (plus their 911 distribution over time, of course). The minimum interval can be 912 derived from the available RTCP bandwidth and the expected average 913 size of an RTCP packet. The number of events to report e.g. per 914 second may be derived from the packet loss rate and sender's rate 915 of transmitting packets. From these two values, the allowable 916 group size for the Immediate Feedback mode can be calculated. 918 Let N be the average number of events to be reported per 919 interval T by a receiver, B the RTCP bandwidth fraction for 920 this particular receiver and R the average RTCP packet size, 921 then the receiver operates in Immediate Feedback mode as long 922 as N<=B*T/R. 924 The upper bound for the Early RTCP mode then solely depends on the 925 acceptable quality degradation, i.e. how many events per time 926 interval may go unreported. 928 Using the above notation, Early RTCP mode can be roughly 929 characterized by N > B*T/R as "lower bound". An estimate for 930 an upper bound is more difficult. Setting N=1, we obtain for a 931 given R and B the interval T = R/B as average interval between 932 events to be reported. This information can be used as a hint 933 to determine whether or not early transmission of RTCP packets 934 is useful. 936 Example: If a 256kbit/s video with 30 fps is transmitted through a 937 network with an MTU size of some 1,500 bytes, then, in most cases, 938 each frame would fit in into one packet leading to a packet rate of 939 30 packets per second. If 5% packet loss occurs in the network 940 (equally distributed, no inter-dependence between receivers), then 941 each receiver will, on average, have to report 3 packets lost each 942 two seconds. Assuming a single sender and more than three 943 receivers, this yields 3.75% of the RTCP bandwidth allocated to the 944 receivers and thus 9.6kbit/s. Assuming further a size of 120 bytes 945 for the average compound RTCP packet allows 10 RTCP packets to be 946 sent per second or 20 in two seconds. If every receiver needs to 947 report three lost packets per two seconds, this yields a maximum 948 group size of 6-7 receivers if all loss events shall be reported. 949 The rules for transmission of Early RTCP packets should provide 950 sufficient flexibility for most of this reporting to occur in a 951 timely fashion. 953 Extending this example to determine the upper bound for Early RTCP 954 mode could lead to the following considerations: assume that the 955 underlying coding scheme and the application (as well as the 956 tolerant users) allow on the order of one loss without repair per 957 two seconds. Thus the number of packets to be reported by each 958 receiver decreases to two per two seconds second and increases the 959 group size to 10. Assuming further that some number of packet 960 losses are correlated, feedback traffic is further reduced and 961 group sizes of some 12 to 16 (maybe even 20) can be reasonably well 962 supported using Early RTCP mode. Note that all these 963 considerations are based upon statistics and will fail to hold in 964 some cases. 966 3.7 Summary of decision steps 968 3.7.1 General Hints 970 Before even considering whether or not to send RTCP feedback 971 information an application has to determine whether this mechanism 972 is applicable: 974 1) An application has to decide whether -- for the current ratio of 975 packet rate with the associated (application-specific) maximum 976 feedback delay and the currently observed round-trip time (if 977 available) -- feedback mechanisms can be applied at all. 979 This decision may be based upon (and dynamically revised 980 following) RTCP reception statistics as well as out-of-band 981 mechanisms. 983 2) The application has to decide -- for a certain observed error 984 rate, assigned bandwidth, frame/packet rate, and group size -- 985 whether (and which) feedback mechanisms can be applied. 987 Regular RTCP reception statistics provide valuable input to this 988 step, too. 990 3) If the application decides to send feedback, the application has 991 to follow the rules for transmitting Early RTCP packets or 992 Regular RTCP packets containing FB messages. 994 3.7.2 Media Session Attributes 996 Media sessions are typically described using out-of-band mechanisms 997 to convey transport addresses, codec information, etc. between 998 sender(s) and receiver(s). Such a mechanism is two-fold: a format 999 used to describe a media session and another mechanism for 1000 transporting this description. 1002 In the IETF, the Session Description Protocol (SDP) is currently 1003 used to describe media sessions while protocols such as SIP, SAP, 1004 RTSP, and HTTP (among others) are used to convey the descriptions. 1006 A media session description format MAY include parameters to 1007 indicate that RTCP feedback mechanisms are supported in this 1008 session and which of the feedback mechanisms MAY be applied. 1010 To do so, the profile "AVPF" MUST be indicated instead of "AVP". 1011 Further attributes may be defined to show which type(s) of feedback 1012 are supported. 1014 Section 4 contains the syntax specification to support RTCP 1015 feedback with SDP. Similar specifications for other media session 1016 description formats are outside the scope of this document. 1018 4 SDP Definitions 1020 This section defines a number of additional SDP parameters that are 1021 used to describe a session. All of these are defined as media 1022 level attributes. 1024 4.1 Profile identification 1026 The AV profile defined in [4] is referred to as "AVP" in the 1027 context of e.g. the Session Description Protocol (SDP) [3]. The 1028 profile specified in this document is referred to as "AVPF". 1030 Feedback information following the modified timing rules as 1031 specified in this document MUST NOT be sent for a particular media 1032 session unless the description for this session indicates the use 1033 of the "AVPF" profile (exclusively or jointly with other AV 1034 profiles). 1036 4.2 RTCP Feedback Capability Attribute 1038 A new payload format-specific SDP attribute is defined to indicate 1039 the capability of using RTCP feedback as specified in this 1040 document: "a=rtcp-fb". The "rtcp-fb" attribute MUST only be used 1041 as an SDP media attribute and MUST NOT be provided at the session 1042 level. The "rtcp-fb" attribute MUST only be used in media sessions 1043 for which the "AVPF" is specified. 1045 The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB 1046 messages MAY be used in this media session for the indicated 1047 payload type. A wildcard payload type ("*") MAY be used to 1048 indicate that the RTCP feedback attribute applies to all payload 1049 types. If several types of feedback are supported and/or the same 1050 feedback shall be specified for a subset of the payload types, 1051 several "a=rtcp-fb" lines MUST be used. 1053 If no "rtcp-fb" attribute is specified the RTP receivers SHOULD 1054 assume that the RTP senders only support generic NACKs. In 1055 addition, the RTP receivers MAY send feedback using other suitable 1056 RTCP feedback packets as defined for the respective media type. 1057 The RTP receivers MUST NOT rely on the RTP senders reacting to any 1058 of the FB messages. 1060 If one or more "rtcp-fb" attributes are present in a media session 1061 description, the RTCP receivers for the media session(s) containing 1062 the "rtcp-fb" 1064 o MUST ignore all "rtcp-fb" attributes of which they do not fully 1065 understand the semantics (i.e. where they do not understand the 1066 meaning of all values in the "a=rtcp-fb" line); 1068 o SHOULD provide feedback information as specified in this 1069 document using any of the RTCP feedback packets as specified in 1070 one of the "rtcp-fb" attributes for this media session; and 1072 o MUST NOT use other FB messages than those listed in one of the 1073 "rtcp-fb" attribute lines. 1075 When used in conjunction with the offer/answer model [9], the 1076 offerer MAY present a set of these AVPF attributes to its peer. 1077 The answerer MUST remove all attributes it does not understand as 1078 well as those it does not support in general or does not wish to 1079 use in this particular media session. The answerer MUST NOT add 1080 feedback parameters to the media description and MUST NOT alter 1081 values of such parameters. The answer is binding for the media 1082 session and both offerer and answerer MUST only use feedback 1083 mechanisms negotiated in this way. Both offerer and answerer MAY 1084 independently decide to send RTCP FB messages of only a subset of 1085 the negotiated feedback mechanisms; but they SHOULD react properly 1086 to all types of the negotiated FB messages when received. 1088 RTP senders MUST be prepared to receive any kind of RTCP FB 1089 messages and MUST silently discard all those RTCP FB messages that 1090 they do not understand. 1092 The syntax of the "rtcp-fb" attribute is as follows (the feedback 1093 types and optional parameters are all case sensitive): 1095 (In the following ABNF, fmt, SP and CRLF are used as defined in 1096 [3].) 1098 rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF 1099 rtcp-fb-pt = "*" ; wildcard: applies to all formats 1100 / fmt ; as defined in SDP spec 1102 rtcp-fb-val = "ack" rtcp-fb-ack-param 1103 / "nack" rtcp-fb-nack-param 1104 / "trr-int" SP 1*DIGIT 1105 / rtcp-fb-id rtcp-fb-param 1107 rtcp-fb-id = 1*(alpha-numeric | "-" | "_") 1109 rtcp-fb-param = SP "app" [SP byte-string] 1110 / SP token [SP byte-string] 1111 / ; empty 1113 rtcp-fb-ack-param = SP "rpsi" 1114 / SP "app" [SP byte-string] 1115 / SP token [SP byte-string] 1116 / ; empty 1118 rtcp-fb-nack-param = SP "pli" 1119 / SP "sli" 1120 / SP "rpsi" 1121 / SP "app" [SP byte-string] 1122 / SP token [SP byte-string] 1123 / ; empty 1125 The literals of the above grammar have the following semantics: 1127 Feedback type "ack": 1129 This feedback type indicates that positive acknowledgements 1130 for feedback are supported. 1132 The feedback type "ack" MUST only be used if the media session 1133 is allowed to operate in ACK mode as defined in 3.6.1.2. 1135 Parameters MAY be provided to further distinguish different 1136 types of positive acknowledgement feedback. If no parameters 1137 are present, the Generic ACK as specified in section 6.2.2 is 1138 implied. 1140 The parameter "rpsi" indicates the use of Reference Picture 1141 Selection Indication feedback as defined in section 6.3.3. 1143 If the parameter "app" is specified, this indicates the use of 1144 application layer feedback. In this case, additional 1145 parameters following "app" MAY be used to further 1146 differentiate various types of application layer feedback. 1148 This document does not define any parameters specific to 1149 "app". 1151 Further parameters for "ack" MAY be defined in other 1152 documents. 1154 Feedback type "nack": 1156 This feedback type indicates that negative acknowledgements 1157 for feedback are supported. 1159 The feedback type "nack", without parameters, indicates use of 1160 the General NACK feedback format as defined in section 6.2.1. 1162 The following three parameters are defined in this document 1163 for use with "nack" in conjunction with the media type 1164 "video": 1166 o "pli" indicates the use of Picture Loss Indication feedback 1167 as defined in section 6.3.1. 1168 o "sli" indicates the use of Slice Loss Indication feedback 1169 as defined in section 6.3.2. 1170 o "rpsi" indicates the use of Reference Picture Selection 1171 Indication feedback as defined in section 6.3.3. 1173 "app" indicates the use of application layer feedback. 1174 Additional parameters after "app" MAY be provided to 1175 differentiate different types of application layer feedback. 1176 No parameters specific to "app" are defined in this document. 1178 Further parameters for "nack" MAY be defined in other 1179 documents. 1181 Other feedback types : 1183 Other documents MAY define additional types of feedback; to 1184 keep the grammar extensible for those cases, the rtcp-fb-id is 1185 introduced as a placeholder. A new feedback scheme name MUST 1186 to be unique (and thus MUST be registered with IANA). Along 1187 with a new name, its semantics, packet formats (if necessary), 1188 and rules for its operation MUST be specified. 1190 Regular RTCP minimum interval "trr-int": 1192 The attribute "trr-int" is used to specify the minimum 1193 interval T_rr_interval between two Regular (full compound) 1194 RTCP packets in milliseconds for this media session. If "trr- 1195 int" is not specified, a default value of 0 is assumed. 1197 Note that it is assumed that more specific information about 1198 application layer feedback (as defined in section 6.4) will be 1199 conveyed as feedback types and parameters defined elsewhere. 1200 Hence, no further provision for any types and parameters is made in 1201 this document. 1203 Further types of feedback as well as further parameters may be 1204 defined in other documents. 1206 It is up to the recipients whether or not they send feedback 1207 information and up to the sender(s) (how) to make use of feedback 1208 provided. 1210 4.3 RTCP Bandwidth Modifiers 1212 The standard RTCP bandwidth assignments as defined in [1] and [2] 1213 may be overridden by bandwidth modifiers that explicitly define the 1214 maximum RTCP bandwidth. For use with SDP, such modifiers are 1215 specified in [4]: "b=RS:" and "b=RR:" MAY be used to assign 1216 a different bandwidth (measured in bits per second) to RTP senders 1217 and receivers, respectively. The precedence rules of [4] apply to 1218 determine the actual bandwidth to be used by senders and receivers. 1220 Applications operating knowingly over highly asymmetric links (such 1221 as satellite links) SHOULD use this mechanism to reduce the 1222 feedback rate for high bandwidth streams to prevent deterministic 1223 congestion of the feedback path(s). 1225 4.4 Examples 1227 Example 1: The following session description indicates a session 1228 made up from audio and DTMF [18] for point-to-point communication 1229 in which the DTMF stream uses Generic ACKs. This session 1230 description could be contained in a SIP INVITE, 200 OK, or ACK 1231 message to indicate that its sender is capable of and willing to 1232 receive feedback for the DTMF stream it transmits. 1234 v=0 1235 o=alice 3203093520 3203093520 IN IP4 host.example.com 1236 s=Media with feedback 1237 t=0 0 1238 c=IN IP4 host.example.com 1239 m=audio 49170 RTP/AVPF 0 96 1240 a=rtpmap:0 PCMU/8000 1241 a=rtpmap:96 telephone-event/8000 1242 a=fmtp:96 0-16 1243 a=rtcp-fb:96 ack 1245 Example 2: The following session description indicates a multicast 1246 video-only session (using either H.261 or H.263+) with the video 1247 source accepting Generic NACKs for both codecs and Reference 1248 Picture Selection for H.263. Such a description may have been 1249 conveyed using the Session Announcement Protocol (SAP). 1251 v=0 1252 o=alice 3203093520 3203093520 IN IP4 host.example.com 1253 s=Multicast video with feedback 1254 t=3203130148 3203137348 1255 m=audio 49170 RTP/AVP 0 1256 c=IN IP4 224.2.1.183 1257 a=rtpmap:0 PCMU/8000 1258 m=video 51372 RTP/AVPF 98 99 1259 c=IN IP4 224.2.1.184 1260 a=rtpmap:98 H263-1998/90000 1261 a=rtpmap:99 H261/90000 1262 a=rtcp-fb:* nack 1263 a=rtcp-fb:98 nack rpsi 1265 Example 3: The following session description defines the same media 1266 session as example 2 but allows for mixed mode operation of AVP and 1267 AVPF RTP entities (see also next section). Note that both media 1268 descriptions use the same addresses; however, two m= lines are 1269 needed to convey information about both applicable RTP profiles. 1271 v=0 1272 o=alice 3203093520 3203093520 IN IP4 host.example.com 1273 s=Multicast video with feedback 1274 t=3203130148 3203137348 1275 m=audio 49170 RTP/AVP 0 1276 c=IN IP4 224.2.1.183 1277 a=rtpmap:0 PCMU/8000 1278 m=video 51372 RTP/AVP 98 99 1279 c=IN IP4 224.2.1.184 1280 a=rtpmap:98 H263-1998/90000 1281 a=rtpmap:99 H261/90000 1282 m=video 51372 RTP/AVPF 98 99 1283 c=IN IP4 224.2.1.184 1284 a=rtpmap:98 H263-1998/90000 1285 a=rtpmap:99 H261/90000 1286 a=rtcp-fb:* nack 1287 a=rtcp-fb:98 nack rpsi 1289 Note that these two m= lines SHOULD be grouped by some appropriate 1290 mechanism to indicate that both are alternatives actually conveying 1291 the same contents. A sample mechanism by which this can be 1292 achieved is defined in [7]. 1294 5 Interworking and Co-Existence of AVP and AVPF Entities 1296 The AVPF profile defined in this document is an extension of the 1297 AVP profile as defined in [2]. Both profiles follow the same basic 1298 rules (including the upper bandwidth limit for RTCP and the 1299 bandwidth assignments to senders and receivers). Therefore, 1300 senders and receivers of using either of the two profiles can be 1301 mixed in a single session (see e.g. example 3 in section 4.5). 1303 AVP and AVPF are defined in a way that, from a robustness point of 1304 view, the RTP entities do not need to be aware of entities of the 1305 respective other profile: they will not disturb each other's 1306 functioning. However, the quality of the media presented may 1307 suffer. 1309 The following considerations apply to senders and receivers when 1310 used in a combined session. 1312 o AVP entities (senders and receivers) 1314 AVP senders will receive RTCP feedback packets from AVPF 1315 receivers and ignore these packets. They will see occasional 1316 closer spacing of RTCP messages (e.g. violating the five second 1317 rule) by AVPF entities. As the overall bandwidth constraints 1318 are adhered to by both types of entities, they will still get 1319 their share of the RTCP bandwidth. However, while AVP entities 1320 are bound by the five second rule, depending on the group size 1321 and session bandwidth, AVPF entities may provide more frequent 1322 RTCP reports than AVP ones will. Also, the overall reporting 1323 may decrease slightly as AVPF entities may send bigger compound 1324 RTCP packets (due to the extra RTCP packets). 1326 If T_rr_interval is used as lower bound between Regular RTCP 1327 packets, T_rr_interval is sufficiently large (e.g. T_rr_interval 1328 > M*Td as per section 6.3.5 of [1]), and no Early RTCP packets 1329 are sent by AVPF entities, AVP entities may accidentally time 1330 out those AVPF group members and hence under-estimate the group 1331 size. Therefore, if AVP entities may be involved in a media 1332 session, T_rr_interval SHOULD NOT be larger than five seconds. 1334 o AVPF entities (senders and receivers) 1336 If the dynamically calculated T_rr is sufficiently small (e.g. 1337 less than one second), AVPF entities may accidentally time out 1338 AVP group members and hence under-estimate the group size. 1339 Therefore, if AVP entities may be involved in a media session, 1340 T_rr_interval SHOULD be used and SHOULD be set to five seconds. 1342 In conclusion, if AVP entities may be involved in a media 1343 session and T_rr_interval is to be used, T_rr_interval SHOULD be 1344 set to five seconds. 1346 o AVPF senders 1348 AVPF senders will receive feedback information only from AVPF 1349 receivers. If they rely on feedback to provide the target media 1350 quality, the quality achieved for AVP receivers may be sub- 1351 optimal. 1353 o AVPF receivers 1355 AVPF receivers SHOULD send Early RTCP feedback packets only if 1356 all sending entities in the media session support AVPF. AVPF 1357 receivers MAY send feedback information as part of regularly 1358 scheduled compound RTCP packets following the timing rules of 1359 [1] and [2] also in media sessions operating in mixed mode. 1360 However, the receiver providing feedback MUST NOT rely on the 1361 sender reacting to the feedback at all. 1363 6 Format of RTCP Feedback Messages 1365 This section defines the format of the low delay RTCP feedback 1366 messages. These messages are classified into three categories as 1367 follows: 1369 - Transport layer FB messages 1370 - Payload-specific FB messages 1371 - Application layer FB messages 1373 Transport layer FB messages are intended to transmit general 1374 purpose feedback information, i.e. information independent of the 1375 particular codec or the application in use. The information is 1376 expected to be generated and processed at the transport/RTP layer. 1377 Currently, only a general positive acknowledgement (ACK) and a 1378 negative acknowledgement (NACK) message are defined. 1380 Payload-specific FB messages transport information that is specific 1381 to a certain payload type and will be generated and acted upon at 1382 the codec "layer". This document defines a common header to be 1383 used in conjunction with all payload-specific FB messages. The 1384 definition of specific messages is left to either RTP payload 1385 format specifications or to additional feedback format documents. 1387 Application layer FB messages provide a means to transparently 1388 convey feedback from the receiver's to the sender's application. 1389 The information contained in such a message is not expected to be 1390 acted upon at the transport/RTP or the codec layer. The data to be 1391 exchanged between two application instances is usually defined in 1392 the application protocol specification and thus can be identified 1393 by the application so that there is no need for additional external 1394 information. Hence, this document defines only a common header to 1395 be used along with all application layer FB messages. From a 1396 protocol point of view, an application layer FB message is treated 1397 as a special case of a payload-specific FB message. 1399 NOTE: Proper processing of some FB messages at the media 1400 sender side may require the sender to know which payload type 1401 the FB message refers to. Most of the time, this knowledge 1402 can likely be derived from a media stream using only a single 1403 payload type. However, if several codecs are used 1404 simultaneously (e.g. with audio and DTMF) or when codec 1405 changes occur, the payload type information may need to be 1406 conveyed explicitly as part of the FB message. This applies 1407 to all payload-specific as well as application layer FB 1408 messages. It is up to the specification of a FB message to 1409 define how payload type information is transmitted. 1411 This document defines two transport layer and three (video) 1412 payload-specific FB messages as well as a single container for 1413 application layer FB messages. Additional transport layer and 1414 payload specific FB messages MAY be defined in other documents and 1415 MUST be registered through IANA (see section IANA considerations). 1417 The general syntax and semantics for the above RTCP FB message 1418 types are described in the following subsections. 1420 6.1 Common Packet Format for Feedback Messages 1422 All FB messages MUST use a common packet format that is depicted in 1423 figure 3: 1425 0 1 2 3 1426 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 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 |V=2|P| FMT | PT | length | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | SSRC of packet sender | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | SSRC of media source | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 : Feedback Control Information (FCI) : 1435 : : 1437 Figure 3: Common Packet Format for Feedback Messages 1438 The various fields V, P, SSRC and length are defined in the RTP 1439 specification [2], the respective meaning being summarized below: 1441 version (V): 2 bits 1442 This field identifies the RTP version. The current version is 1443 2. 1445 padding (P): 1 bit 1446 If set, the padding bit indicates that the packet contains 1447 additional padding octets at the end which are not part of the 1448 control information but are included in the length field. 1450 Feedback message type (FMT): 5 bits 1451 This field identifies the type of the FB message and is 1452 interpreted relative to the type (transport, payload- 1453 specific, or application layer feedback). The values for each 1454 of the three feedback types are defined in the respective 1455 sections below. 1457 Payload type (PT): 8 bits 1458 This is the RTCP packet type which identifies the packet as 1459 being an RTCP FB message. Two values are defined (TBA. by 1460 IANA): 1462 Name | Value | Brief Description 1463 ----------+-------+------------------------------------ 1464 RTPFB | 205 | Transport layer FB message 1465 PSFB | 206 | Payload-specific FB message 1467 Length: 16 bits 1468 The length of this packet in 32-bit words minus one, including 1469 the header and any padding. This is in line with the 1470 definition of the length field used in RTCP sender and receiver 1471 reports [3]. 1473 SSRC of packet sender: 32 bits 1474 The synchronization source identifier for the originator of 1475 this packet. 1477 SSRC of media source: 32 bits 1478 The synchronization source identifier of the media source that 1479 this piece of feedback information is related to. 1481 Feedback Control Information (FCI): variable length 1482 The following three sections define which additional 1483 information MAY be included in the FB message for each type of 1484 feedback: transport layer, payload-specific or application 1485 layer feedback. Note that further FCI contents MAY be specified 1486 in further documents. 1488 Each RTCP feedback packet MUST contain at least one FB message in 1489 the FCI field. Sections 6.2 and 6.3 define for each FCI type, 1490 whether or not multiple FB messages MAY be compressed into a single 1491 FCI field. If this is the case, they MUST be of the same type, 1492 i.e. same FMT. If multiple types of feedback messages, i.e. 1493 several FMTs, need to be conveyed, then several RTCP FB messages 1494 MUST be generated and SHOULD be concatenated in the same compound 1495 RTCP packet. 1497 6.2 Transport Layer Feedback Messages 1499 Transport Layer FB messages are identified by the value RTPFB as 1500 RTCP message type. 1502 Two general purpose transport layer FB messages are defined so far: 1503 General ACK and General NACK. They are identified by means of the 1504 FMT parameter as follows: 1506 0: unassigned 1507 1: Generic NACK 1508 2: Generic ACK 1509 3-30: unassigned 1510 31: reserved for future expansion of the identifier number 1511 space 1513 The following two subsections define the formats of the FCI field 1514 for these types of FB messages: 1516 6.2.1 Generic NACK 1518 The Generic NACK message is identified by PT=RTPFB and FMT=1. 1520 The FCI field MUST contain at least one and MAY contain more than 1521 one Generic NACK. 1523 The Generic NACK packet is used to indicate the loss of one or more 1524 RTP packets. The lost packet(s) are identified by the means of a 1525 packet identifier and a bit mask. 1527 The Feedback control information (FCI) field has the following 1528 Syntax (figure 4): 1530 0 1 2 3 1531 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 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | PID | BLP | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 Figure 4: Syntax for the Generic NACK message 1538 Packet ID (PID): 16 bits 1539 The PID field is used to specify a lost packet. The PID field 1540 refers to the RTP sequence number of the lost packet. 1542 bitmask of following lost packets (BLP): 16 bits 1543 The BLP allows for reporting losses of any of the 16 RTP 1544 packets immediately following the RTP packet indicated by the 1545 PID. The BLP's definition is identical to that given in [6]. 1546 Denoting the BLP's least significant bit as bit 1, and its most 1547 significant bit as bit 16, then bit i of the bit mask is set to 1548 1 if the receiver has not received RTP packet number (PID+i) 1549 (modulo 2^16) and indicates this packet is lost; bit i is set 1550 to 0 otherwise. Note that the sender MUST NOT assume that a 1551 receiver has received a packet because its bit mask was set to 1552 0. For example, the least significant bit of the BLP would be 1553 set to 1 if the packet corresponding to the PID and the 1554 following packet have been lost. However, the sender cannot 1555 infer that packets PID+2 through PID+16 have been received 1556 simply because bits 2 through 15 of the BLP are 0; all the 1557 sender knows is that the receiver has not reported them as lost 1558 at this time. 1560 The length of the FB message MUST be set to 2+n, with n being the 1561 number of Generic NACKs contained in the FCI field. 1563 The Generic NACK message implicitly references the payload type 1564 through the sequence number(s). 1566 6.2.2 Generic ACK 1568 The Generic ACK message is identified by PT=RTPFB and FMT=2. 1570 The FCI field MUST contain at least one and MAY contain more than 1571 one Generic ACK. 1573 The Generic ACK packet is used to indicate that one or several RTP 1574 packets were received correctly. The received packet(s) are 1575 identified by the means of a packet identifier and a bit mask. 1576 ACKing of a range of consecutive packets is also possible. 1578 The Feedback control information (FCI) field has the following 1579 syntax: 1581 0 1 2 3 1582 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 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | PID |R| BLP/#packets | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 Figure 5: Syntax for the Generic ACK message 1589 Packet ID (1st PID): 16 bits 1590 This PID field is used to specify a correctly received packet. 1591 The PID field refers to the RTP sequence number of the lost 1592 packet. 1594 Range of ACKs (R): 1 bit 1595 The R-bit indicates that a range of consecutive packets are 1596 received correctly. If R=1 then the PID field specifies the 1597 first packet of that range and the next field (BLP/#packets) 1598 will carry the number of packets being acknowledged. If R=0 1599 then PID specifies the first packet to be acknowledged and 1600 BLP/#packets provides a bit mask to selectively indicate 1601 individual packets that are acknowledged. 1603 Bit mask of lost packets (BLP)/#packets (PID): 15 bits 1604 The semantics of this field depends on the value of the R-bit. 1606 If R=1, this field is used to identify the number of additional 1607 packets of to be acknowledged: 1609 #packets = - 1611 That is, #packets MUST indicate the number of packet to be 1612 ACKed minus one. In particular, if only a single packet is to 1613 be ACKed and R=1 then #packets MUST be set to 0x0000. 1615 Example: If all packets between and including PIDx = 380 and 1616 PIDy = 422 have been received, the Generic ACK would contain 1617 PID = PIDx = 380 and #packets = PIDy - PID = 42. In case the 1618 PID wraps around, modulo arithmetic is used to calculate the 1619 number of packets. 1621 If R=0, this field carries a bit mask. The BLP allows for 1622 reporting reception of any of the 15 RTP packets immediately 1623 following the RTP packet indicated by the PID. The BLP's 1624 definition is identical to that given in [6] except that, here, 1625 BLP is only 15 bits wide. Denoting the BLP's least significant 1626 bit as bit 1, and its most significant bit as bit 15, then bit 1627 i of the bitmask is set to 1 if the receiver has received RTP 1628 packet number (PID+i) (modulo 2^16) and decides to ACK this 1629 packet; bit i is set to 0 otherwise. If only the packet 1630 indicated by PID is to be ACKed and R=0 then BLP MUST be set to 1631 0x0000. 1633 The length of the FB message MUST be set to 2+n, with n being the 1634 number of Generic ACKs contained in the FCI field. 1636 The Generic ACK message implicitly references the payload type 1637 through the sequence number(s). 1639 6.3 Payload Specific Feedback Messages 1641 Payload-Specific FB messages are identified by the value PT=PSFB as 1642 RTCP message type. 1644 Three payload-specific FB messages are defined so far plus an 1645 application layer FB message. They are identified by means of the 1646 FMT parameter as follows: 1648 0: unassigned 1649 1: Picture Loss Indication (PLI) 1650 2: Slice Lost Indication (SLI) 1651 3: Reference Picture Selection Indication (RPSI) 1652 4-14: unassigned 1653 15: Application layer FB message 1654 16-30: unassigned 1655 31: reserved for future expansion of the sequence number space 1657 The following subsections define the FCI formats for the payload- 1658 specific FB messages, section 6.4 defines FCI format for the 1659 application layer FB message. 1661 6.3.1 Picture Loss Indication (PLI) 1663 The PLI FB message is identified by PT=PSFB and FMT=1. 1665 There MUST be exactly one PLI contained in the FCI field. 1667 6.3.1.1 Semantics 1669 With the Picture Loss Indication message, a decoder informs the 1670 encoder about the loss of an undefined amount of coded video data 1671 belonging to one or more pictures. When used in conjunction with 1672 any video coding scheme that is based on inter-picture prediction, 1673 an encoder that receives a PLI becomes aware that the prediction 1674 chain may be broken. The sender MAY react to a PLI by transmitting 1675 an intra-picture to achieve resynchronization (making effectively 1676 similar to the FIR as defined in [6]); however, the sender MUST 1677 consider congestion control as outlined in section 7 which MAY 1678 restrict its ability to send an intra frame. 1680 Other RTP payload specifications such as RFC 2032 [6] already 1681 define a feedback mechanism for some for certain codecs. An 1682 application supporting both schemes MUST use the feedback mechanism 1683 defined in this specification when sending feedback. For backward 1684 compatibility reasons, such an application SHOULD also be capable 1685 to receive and react to the feedback scheme defined in the 1686 respective RTP payload format, if this is required by that payload 1687 format. 1689 6.3.1.2 Message Format 1691 PLI does not require parameters. Therefore, the length field MUST 1692 be 2, and there MUST NOT be any Feedback Control Information. 1694 The semantics of this FB message is independent of the payload 1695 type. 1697 6.3.1.3 Timing Rules 1699 The timing follows the rules outlined in section 3. In systems 1700 that employ both PLI and other types of feedback it may be 1701 advisable to follow the Regular RTCP RR timing rules for PLI, since 1702 PLI is not as delay critical as other FB types. 1704 6.3.1.4 Remarks 1706 PLI messages typically trigger the sending of full intra pictures. 1707 Intra pictures are several times larger then predicted (inter) 1708 pictures. Their size is independent of the time they are 1709 generated. In most environments, especially when employing 1710 bandwidth-limited links, the use of an intra picture implies an 1711 allowed delay that is a significant multitude of the typical frame 1712 duration. An example: If the sending frame rate is 10 fps, and an 1713 intra picture is assumed to be 10 times as big as an inter picture, 1714 then a full second of latency has to be accepted. In such an 1715 environment there is no need for a particular short delay in 1716 sending the FB message. Hence waiting for the next possible time 1717 slot allowed by RTCP timing rules as per [2] does not have a 1718 negative impact on the system performance. 1720 6.3.2 Slice Lost Indication (SLI) 1722 The SLI FB message is identified by PT=PSFB and FMT=2. 1724 The FCI field MUST contain at least one and MAY contain more than 1725 one SLI. 1727 6.3.2.1 Semantics 1729 With the Slice Lost Indication a decoder can inform an encoder that 1730 it has detected the loss or corruption of one or several 1731 consecutive macroblock(s) in scan order (see below). This FB 1732 message MUST NOT be used for video codecs with non-uniform, 1733 dynamically changeable macroblock sizes such as H.263 with enabled 1734 Annex Q. In such a case, an encoder cannot always identify the 1735 corrupted spatial region. 1737 6.3.2.2 Format 1739 The Slice Lost Indication uses one additional PCI field the 1740 content of which is depicted in figure 6. The length of the FB 1741 message MUST be set to 2+n, with n being the number of SLIs 1742 contained in the FCI field. 1744 0 1 2 3 1745 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 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 | First | Number | PictureID | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 Figure 6: Syntax of the Slice Lost Indication (SLI) 1752 First: 13 bits 1753 The macroblock (MB) address of the first lost macroblock. The 1754 MB numbering is done such that the macroblock in the upper left 1755 corner of the picture is considered macroblock number 1 and the 1756 number for each macroblock increases from left to right and 1757 then from top to bottom in raster-scan order (such that if 1758 there is a total of N macroblocks in a picture, the bottom 1759 right macroblock is considered macroblock number N). 1761 Number: 13 bits 1762 The number of lost macroblocks, in scan order as discussed 1763 above. 1765 PictureID: 6 bits 1766 The six least significant bits of the a codec-specific 1767 identifier that is used to reference the picture in which the 1768 loss of the macroblock (s) has occurred. For many video 1769 codecs, the PictureID is identical to the Temporal Reference. 1771 The applicability of this FB message is limited to a small set of 1772 video codecs and therefore, no explicit payload type information is 1773 provided. 1775 6.3.2.3 Timing Rules 1777 The efficiency of algorithms using the Slice Lost Indication is 1778 reduced greatly when the Indication is not transmitted in a timely 1779 fashion. Motion compensation propagates corrupted pixels that are 1780 not reported as being corrupted. Therefore, the use of the 1781 algorithm discussed in section 3 is highly recommended. 1783 6.3.2.4 Remarks 1785 The term Slice is defined and used here in the sense of MPEG-1 -- a 1786 consecutive number of macroblocks in scan order. More recent video 1787 coding standards sometimes have a different understanding of the 1788 term Slice. In H.263 (1998), for example, a concept known as 1789 "rectangular Slice" exist. The loss of one Rectangular Slice may 1790 lead to the necessity of sending more than one SLI in order to 1791 precisely identify the region of lost/damaged MBs. 1793 The first field of the FCI defines the first macroblock of a 1794 picture as 1 and not, as one could suspect, as 0. This was done to 1795 align this specification with the comparable mechanism available in 1796 H.245. The maximum number of macroblocks in a picture (2**13 or 1797 8192) corresponds to the maximum picture sizes of most of the ITU-T 1798 and ISO/IEC video codecs. If future video codecs offer larger 1799 picture sizes and/or smaller macroblock sizes, then an additional 1800 FB message has to be defined. The six least significant bits of 1801 the Temporal Reference field are deemed to be sufficient to 1802 indicate the picture in which the loss occurred. 1804 The reaction to a SLI is not part of this specification. One 1805 typical way of reacting to a SLI is to use intra refresh for the 1806 affected spatial region. 1808 Algorithms were reported that keep track of the regions affected by 1809 motion compensation, in order to allow for a transmission of Intra 1810 macroblocks to all those areas, regardless of the timing of the FB 1811 (see H.263 (2000) Appendix I [17] and [15]). While, when those 1812 algorithms are used, the timing of the FB is less critical then 1813 without, it has to be observed that those algorithms correct large 1814 parts of the picture and, therefore, have to transmit much higher 1815 data volume in case of delayed FBs. 1817 6.3.3 Reference Picture Selection Indication (RPSI) 1819 The RPSI FB message is identified by PT=PSFB and FMT=3. 1821 There MUST be exactly one RPSI contained in the FCI field. 1823 6.3.3.1 Semantics 1825 Modern video coding standards such as MPEG-4 visual version 2 [16] 1826 or H.263 version 2 [17] allow to use older reference pictures than 1827 the most recent one for predictive coding. Typically, a first-in- 1828 first-out queue of reference pictures is maintained. If an encoder 1829 has learned about a loss of encoder-decoder synchronicity, a known- 1830 as-correct reference picture can be used. As this reference picture 1831 is temporally further away then usual, the resulting predictively 1832 coded picture will use more bits. 1834 Both MPEG-4 and H.263 define a binary format for the "payload" of 1835 an RPSI message that includes information such as the temporal ID 1836 of the damaged picture and the size of the damaged region. This 1837 bit string is typically small -- a couple of dozen bits --, of 1838 variable length, and self-contained, i.e. contains all information 1839 that is necessary to perform reference picture selection. 1841 Note that both MPEG-4 and H.263 allow the use of RPSI with positive 1842 feedback information as well. That is, pictures (or Slices) are 1843 reported that were decoded without error. Note that any form of 1844 positive feedback MUST NOT be used when in a multiparty session 1845 (reporting positive feedback about individual reference pictures at 1846 RTCP intervals is not expected to be of much use anyway). 1848 6.3.3.2 Format 1850 The FCI for the RPSI message follows the format depicted in figure 1851 7: 1853 0 1 2 3 1854 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 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | PB |0| Payload Type| Native RPSI bit string | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | defined per codec ... | Padding (0)| 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 Figure 7: Syntax of the Reference Picture Selection Indication 1862 (RPSI) 1864 PB: 8 bits 1865 The number of unused bits required to pad the length of the 1866 RPSI message to a multiple of 32 bits. 1868 0: 1 bit 1869 MUST be set to zero upon transmission and ignored upon 1870 reception. 1872 Payload Type: 8 bits 1873 Indicates the RTP payload type in the context of which the 1874 native RPSI bit string MUST be interpreted. 1876 Native RPSI bit string: variable length 1877 The RPSI information as natively defined by the video codec. 1879 Padding: #PB bits 1880 A number of bits set to zero to fill up the contents of the 1881 RPSI message to the next 32 bit boundary. The number of 1882 padding bits MUST be indicated by the PB field. 1884 6.3.3.3 Timing Rules 1886 RPS is even more critical to delay then algorithms using SLI. This 1887 is due to the fact that the older the RPS message is, the more bits 1888 the encoder has to spend to re-establish encoder-decoder 1889 synchronicity. See [15] for some information about the overhead of 1890 RPS for certain bit rate/frame rate/loss rate scenarios. 1892 Therefore, RPS messages should typically be sent as soon as 1893 possible, employing the algorithm of section 3. 1895 6.4 Application Layer Feedback Messages 1897 Application Layer FB messages are a special case of payload- 1898 specific messages and identified by PT=PSFB and FMT=15. 1899 There MUST be exactly one Application Layer FB message contained in 1900 the FCI field. 1902 These messages are used to transport application defined data 1903 directly from the receiver's to the sender's application. The data 1904 that is transported is not identified by the FB message. 1905 Therefore, the application MUST be able to identify the messages 1906 payload. 1908 Usually, applications define their own set of messages, e.g. 1909 NEWPRED messages in MPEG-4 [16] or FB messages in H.263/Annex N, U 1910 [17]. These messages do not need any additional information from 1911 the RTCP message. Thus the application message is simply placed 1912 into the FCI field as follows and the length field is set 1913 accordingly. 1915 Application Message (FCI): variable length 1916 This field contains the original application message that 1917 should be transported from the receiver to the source. The 1918 format is application dependent. The length of this field is 1919 variable. If the application data is not 32-bit-aligned, 1920 padding bits and bytes must be added. Identification of 1921 padding is up to the application layer and not defined in this 1922 specification. 1924 The application layer FB message specification MUST define whether 1925 or not the message needs to be interpreted specifically in the 1926 context of a certain codec (identified by the RTP payload type). 1927 If a reference to the payload type is required for proper 1928 processing, the application layer FB message specification MUST 1929 define a way to communicate the payload type information as part of 1930 the application layer FB message itself. 1932 7 Early Feedback and Congestion Control 1934 In the previous sections, the FB messages were defined as well as 1935 the timing rules according to which to send these messages. The 1936 way to react to the feedback received depends on the application 1937 using the feedback mechanisms and hence is beyond the scope of this 1938 document. 1940 However, across all applications, there is a common requirement for 1941 (TCP-friendly) congestion control on the media stream as defined in 1942 [1] and [2] when operating in a best-effort network environment. 1944 Low delay feedback supports the use of congestion control 1945 algorithms in two ways: 1947 o The potentially more frequent RTCP packets allow the sender to 1948 monitor the network state more closely than with Regular RTCP 1949 packets and therefore enable reacting to upcoming congestion in 1950 a more timely fashion. 1952 o The FB messages themselves may convey additional information as 1953 input to congestion control algorithms and thus improve reaction 1954 over conventional RTCP. (For example, ACK-based feedback may 1955 even allow to construct closed loop algorithms and NACK-based 1956 systems may provide further information on the packet loss 1957 distribution.) 1959 A congestion control algorithm that shares the available bandwidth 1960 fairly with competing TCP connections, e.g. TFRC [8], SHOULD be 1961 used to determine the data rate for the media stream (if the low 1962 delay RTP session is transmitted in a best effort environment). 1964 RTCP FB messages or RTCP SR/RR packets that indicate recent packet 1965 loss MUST NOT lead to a (mid-term) increase in the transmission 1966 data rate and SHOULD lead to a (short-term) decrease of the 1967 transmission data rate. Such messages SHOULD cause the sender to 1968 adjust the transmission data rate to the order of the throughput 1969 TCP would achieve under similar conditions (e.g. using TFRC). 1971 RTCP FB messages or RTCP SR/RR packets that indicate no recent 1972 packet loss MAY cause the sender to increase the transmission data 1973 rate to roughly the throughput TCP would achieve under similar 1974 conditions (e.g. using TFRC). 1976 8 Security Considerations 1978 RTP packets transporting information with the proposed payload 1979 format are subject to the security considerations discussed in the 1980 RTP specification [1] and in the RTP/AVP profile specification [2]. 1981 This profile does not specify any additional security services. 1983 This profile modifies the timing behavior of RTCP and eliminates 1984 the minimum RTCP interval of five seconds and allows for earlier 1985 feedback to be provided by receivers. Group members of the 1986 associated RTP session (possibly pretending to represent a large 1987 number of entities) may disturb the operation of RTCP by sending 1988 large numbers of RTCP packets thereby reducing the RTCP bandwidth 1989 available for Regular RTCP reporting as well as for Early FB 1990 messages. (Note that an entity need not be member of a multicast 1991 group to cause these effects.) Similarly, malicious members may 1992 send very large RTCP messages, thereby increasing the avg_rtcp_size 1993 variable and reducing the effectively available RTCP bandwidth. 1995 Feedback information may be suppressed if unknown RTCP feedback 1996 packets are received. This introduces the risk of a malicious 1997 group member reducing Early feedback by simply transmitting 1998 payload-specific RTCP feedback packets with random contents that 1999 are neither recognized by any receiver (so they will suppress 2000 feedback) nor by the sender (so no repair actions will be taken). 2002 A malicious group member can also report arbitrary high loss rates 2003 in the feedback information to make the sender throttle the data 2004 transmission and increase the amount of redundancy information or 2005 take other action to deal with the pretended packet loss (e.g. send 2006 fewer frames or decrease audio/video quality). This may result in 2007 a degradation of the quality of the reproduced media stream. 2009 Finally, a malicious group member can act as a large number of 2010 group members and thereby obtain an artificially large share of the 2011 Early feedback bandwidth and reduce the reactivity of the other 2012 group members -- possibly even causing them to no longer operate in 2013 Immediate or Early feedback mode and thus undermining the whole 2014 purpose of this profile. 2016 Senders as well as receivers SHOULD behave conservative when 2017 observing strange reporting behavior. For excessive failure 2018 reporting from one or a few receivers, the sender MAY decide to no 2019 longer consider this feedback when adapting its transmission 2020 behavior for the media stream. In any case, senders and receivers 2021 SHOULD still adhere to the maximum RTCP bandwidth but make sure 2022 that they are capable of transmitting at least regularly scheduled 2023 RTCP packets. Senders SHOULD carefully consider how to adjust 2024 their transmission bandwidth when encountering strange reporting 2025 behavior; they MUST NOT increase their transmission bandwidth even 2026 if ignoring suspicious feedback. 2028 Attacks using false RTCP packets (Regular as well as Early ones) 2029 can be avoided by authenticating all RTCP messages. This can be 2030 achieved by using the AVPF profile together with the Secure RTP 2031 profile as defined in [10]; as a prerequisite, an appropriate 2032 combination of those two profiles (an "SAVPF") needs to be 2033 specified. 2035 9 IANA Considerations 2037 The following contact information shall be used for all 2038 registrations included here: 2040 Contact: Joerg Ott 2041 mailto:jo@acm.org 2042 tel:+49-421-201-7028 2044 The feedback profile as an extension to the profile for audio- 2045 visual conferences with minimal control needs to be registered for 2046 the Session Description Protocol (specifically the type "proto"): 2047 "RTP/AVPF". 2049 SDP Protocol ("proto"): 2051 Name: RTP/AVPF 2052 Long form: Extended RTP Profile with RTCP-based Feedback 2053 Type of name: proto 2054 Type of attribute: Media level only 2055 Purpose: RFC XXXX 2056 Reference: RFC XXXX 2058 SDP Attribute ("att-field"): 2060 Attribute name: rtcp-fb 2061 Long form: RTCP Feedback parameter 2062 Type of name: att-field 2063 Type of attribute: Media level only 2064 Subject to charset: No 2065 Purpose: RFC XXXX 2066 Reference: RFC XXXX 2067 Values: See this document and registrations below 2069 A new registry needs to be set up for the "rtcp-fb" attribute, with 2070 the following registrations created initially: "ack", "nack", "trr- 2071 int", and "app" as defined in this document. 2073 Initial value registration for the attribute "rtcp-fb" 2075 Value name: ack 2076 Long name: Positive acknowledgement 2077 Reference: RFC XXXX. 2079 Value name: nack 2080 Long name: Negative Acknowledgement 2081 Reference: RFC XXXX. 2083 Value name: trr-int 2084 Long name: Minimal receiver report interval 2085 Reference: RFC XXXX. 2087 Value name: app 2088 Long name: Application-defined paramater 2089 Reference: RFC XXXX. 2091 Further entries may be registered on a first-come first-serve 2092 basis. Each new registration needs to indicate the parameter name 2093 and the syntax of possible additional arguments. For each new 2094 registration, it is mandatory that a permanent, stable, and 2095 publicly accessible document exists that specifies the semantics of 2096 the registered parameter, the syntax and semantics of its 2097 parameters as well as corresponding feedback packet formats (if 2098 needed). The general registration procedures of [3] apply. 2100 For use with both "ack" and "nack", a joint sub-registry needs to 2101 be set up that initially registers the following values: 2103 Initial value registration for the attribute values "ack" and 2104 "nack": 2106 Value name: sli 2107 Long name: Slice Loss Indication 2108 Usable with: nack 2109 Reference: RFC XXXX. 2111 Value name: pli 2112 Long name: Picture Loss Indication 2113 Usable with: nack 2114 Reference: RFC XXXX. 2116 Value name: rpsi 2117 Long name: Reference Picture Selection Indication 2118 Usable with: ack, nack 2119 Reference: RFC XXXX. 2121 Value name: app 2122 Long name: Application layer feedback 2123 Usable with: ack, nack 2124 Reference: RFC XXXX. 2126 Further entries may be registered on a first-come first-serve 2127 basis. Each registrations needs to indicate the parameter name, 2128 the syntax of possible additional arguments, and whether the 2129 parameter is applicable to "ack" or "nack" feedback or both or some 2130 different "rtcp-fb" attribute parameter. For each new 2131 registration, it is mandatory that a permanent, stable, and 2132 publicly accessible document exists that specifies the semantics of 2133 the registered parameter, the syntax and semantics of its 2134 parameters as well as corresponding feedback packet formats (if 2135 needed). The general registration procedures of [3] apply. 2137 Two RTCP Control Packet Types: for the class of transport layer FB 2138 messages ("RTPFB") and for the class of payload-specific FB 2139 messages ("PSFB"). Section 6 suggests RTPFB=205 and PSFB=206 to be 2140 added to the RTCP registry. 2142 RTP RTCP Control Packet types (PT): 2144 Name: RTPFB 2145 Long name: Generic RTP Feedback 2146 Value: 205 2147 Reference: RFC XXXX. 2149 Name: PSFB 2150 Long name: Payload-specific 2151 Value: 206 2152 Reference: RFC XXXX. 2154 As AVPF defines additional RTCP payload types, the corresponding 2155 "reserved" RTP payload type space (72--76, as defined in [2]), 2156 needs to be expanded accordingly. 2158 A new sub-registry needs to be set up for the FMT values for both 2159 the RTPFB payload type and the PSFB payload type, with the 2160 following registrations created initially: 2162 Within the RTPFB range, the following three format (FMT) values are 2163 initially registered: 2165 Name: Generic NACK 2166 Long name: Generic negative acknowledgement 2167 Value: 1 2168 Reference: RFC XXXX. 2170 Name: Generic ACK 2171 Long name: Generic positive acknowledgement 2172 Value: 2 2173 Reference: RFC XXXX. 2175 Name: Extension 2176 Long name: Reserved for future extensions 2177 Value: 31 2178 Reference: RFC XXXX. 2180 Within the PSFB range, the following five format (FMT) values are 2181 initially registered: 2183 Name: PLI 2184 Long name: Picture Loss Indication 2185 Value: 1 2186 Reference: RFC XXXX. 2188 Name: SLI 2189 Long name: Slice Loss Indication 2190 Value: 2 2191 Reference: RFC XXXX. 2193 Name: RPSI 2194 Long name: Reference Picture Selection Indication 2195 Value: 3 2196 Reference: RFC XXXX. 2198 Name: AFB 2199 Long name: Application Layer Feedback 2200 Value: 15 2201 Reference: RFC XXXX. 2203 Name: Extension 2204 Long name: Reserved for future extensions. 2205 Value: 31 2206 Reference: RFC XXXX. 2208 Further entries may be registered on a first-come first-serve 2209 basis. Each registration needs to indicate the FMT value, if there 2210 is a specific FB message to go into the FCI field, and whether or 2211 not multiple FB messages may be stacked in a single FCI field. For 2212 each new registration, it is mandatory that a permanent, stable, 2213 and publicly accessible document exists that specifies the 2214 semantics of the registered parameter as well as the syntax and 2215 semantics of the associated FB message (if any). The general 2216 registration procedures of [3] apply. 2218 NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by 2219 the RFC number assigned to this document. 2221 10 Acknowledgements 2223 This document is a product of the Audio-Visual Transport (AVT) 2224 Working Group of the IETF. The authors would like to thank Steve 2225 Casner and Colin Perkins for their comments and suggestions as well 2226 as for their responsiveness to numerous questions. The authors 2227 would also like to particularly thank Magnus Westerlund for his 2228 review and his valuable suggestions, Shigeru Fukunaga for the 2229 contributions on for FB message formats and semantics. 2231 We would also like to thank Andreas Buesching and people at 2232 Panasonic for their simulations and the first independent 2233 implementations of the feedback profile. 2235 11 Authors' Addresses 2237 Joerg Ott {sip,mailto}:jo@tzi.org 2238 Uni Bremen TZI 2239 MZH 5180 2240 Bibliothekstr. 1 2241 D-28359 Bremen 2242 Germany 2244 Stephan Wenger stewe@cs.tu-berlin.de 2245 TU Berlin 2246 Sekr. FR 6-3 2247 Franklinstr. 28-29 2248 D-10587 Berlin 2249 Germany 2251 Noriyuki Sato 2252 Oki Electric Industry Co., Ltd. 2253 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan 2254 Tel. +81 6 6949 5101 2255 Fax. +81 6 6949 5108 2256 Mail sato652@oki.com 2258 Carsten Burmeister 2259 Panasonic European Laboratories GmbH 2260 Monzastr. 4c, 63225 Langen, Germany 2261 Tel. +49-(0)6103-766-263 2262 Fax. +49-(0)6103-766-166 2263 Mail burmeister@panasonic.de 2265 Jose Rey 2266 Panasonic European Laboratories GmbH 2267 Monzastr. 4c, 63225 Langen, Germany 2268 Tel. +49-(0)6103-766-134 2269 Fax. +49-(0)6103-766-166 2270 Mail rey@panasonic.de 2272 12 Bibliography 2274 12.1 Normative references 2276 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP 2277 - A Transport Protocol for Real-time Applications," Internet 2278 Draft, draft-ietf-avt-rtp-new-12.txt, Work in Progress, March 2279 2003. 2281 [2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video 2282 Conferences with Minimal Control," Internet Draft draft-ietf- 2283 avt-profile-new-13.txt, March 2003. 2285 [3] M. Handley, V. Jacobson, and Colin Perkins, "SDP: Session 2286 Description Protocol", Internet Draft draft-ietf-mmusic-sdp- 2287 new-12.txt, March 2003. 2289 [4] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", 2290 Internet Draft draft-ietf-avt-rtcp-bw-05.txt, November 2001. 2292 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 2293 Levels," RFC 2119, March 1997. 2295 [6] T. Turletti and C. Huitema, "RTP Payload Format for H.261 2296 Video Streams, RFC 2032, October 1996. 2298 [7] G. Camarillo, J. Holler, G. Eriksson, H. Schulzrinne, 2299 "Grouping of media lines in SDP," RFC 3388, December 2002. 2301 [8] M. Handley, J. Padhye, S. Floyd, J. Widmer, "TCP friendly Rate 2302 Control (TFRC): Protocol Specification," RFC 3448, January 2303 2003. 2305 [9] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 2306 SDP," RFC 3264, June 2002. 2308 12.2 Informative References 2310 [10] M. Baugher, R. Blom, E. Carrarra, D. McGrew, M. Naslund, K. 2311 Norrman, D. Oran, "The Secure Real-Time Transport Protocol," 2312 Internet Draft, draft-ietf-avt-srtp-05.txt, Work in Progress, 2313 June 2002. 2315 [11] C. Perkins and O. Hodson, "Options for Repair of Streaming 2316 Media," RFC 2354, June 1998. 2318 [12] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for 2319 Generic Forward Error Correction,", RFC 2733, December 1999. 2321 [13] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, 2322 J.C. Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload 2323 for Redundant Audio Data," RFC 2198, September 1997. 2325 [14] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. 2326 Newell, J. Ott, G. Sullivan, S. Wenger, and C. Zhu, "RTP 2327 Payload Format for the 1998 Version of ITU-T Rec. H.263 Video 2328 (H.263+)," RFC 2429, October 1998. 2330 [15] B. Girod, N. Faerber, "Feedback-based error control for mobile 2331 video transmission," Proceedings IEEE, Vol. 87, No. 10, pp. 2332 1707 - 1723, October, 1999. 2334 [16] ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology - 2335 Coding of audio-visual objects - Part2: Visual", 2001. 2337 [17] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate 2338 Communication," November 2000. 2340 [18] H. Schulzrinne and S. Petrack, "RTP Payload for DTMF Digits, 2341 Telephony Tones and Telephony Signals," RFC 2833, May 2000. 2343 13 IPR Notice 2345 The IETF takes no position regarding the validity or scope of any 2346 intellectual property or other rights that might be claimed to 2347 pertain to the implementation or use of the technology described in 2348 this document or the extent to which any license under such rights 2349 might or might not be available; neither does it represent that it 2350 has made any effort to identify any such rights. Information on 2351 the IETF's procedures with respect to rights in standards-track and 2352 standards-related documentation can be found in BCP-11. Copies of 2353 claims of rights made available for publication and any assurances 2354 of licenses to be made available, or the result of an attempt made 2355 to obtain a general license or permission for the use of such 2356 proprietary rights by implementors or users of this specification 2357 can be obtained from the IETF Secretariat. 2359 The IETF invites any interested party to bring to its attention any 2360 copyrights, patents or patent applications, or other proprietary 2361 rights which may cover technology that may be required to practice 2362 this standard. Please address the information to the IETF 2363 Executive Director. 2365 14 Full Copyright Statement 2367 Copyright (C) The Internet Society (2003). All Rights Reserved. 2368 This document and translations of it may be copied and furnished to 2369 others, and derivative works that comment on or otherwise explain 2370 it or assist in its implementation may be prepared, copied, 2371 published and distributed, in whole or in part, without restriction 2372 of any kind, provided that the above copyright notice and this 2373 paragraph are included on all such copies and derivative works. 2375 However, this document itself may not be modified in any way, such 2376 as by removing the copyright notice or references to the Internet 2377 Society or other Internet organizations, except as needed for the 2378 purpose of developing Internet standards in which case the 2379 procedures for copyrights defined in the Internet Standards process 2380 must be followed, or as required to translate it into languages 2381 other than English. 2383 The limited permissions granted above are perpetual and will not be 2384 revoked by the Internet Society or its successors or assigns. 2386 This document and the information contained herein is provided on 2387 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 2388 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 2389 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2390 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2391 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."