idnits 2.17.1 draft-ietf-avt-rtcp-feedback-08.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 656 has weird spacing: '...ndwidth used ...' == Line 1542 has weird spacing: '... to the type...' == Line 2010 has weird spacing: '... These messa...' == Line 2365 has weird spacing: '... Mail sato6...' == Line 2368 has weird spacing: '... Mail burme...' == (1 more instance...) -- 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 (July 2004) is 7222 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) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-15 ** Obsolete normative reference: RFC 2032 (ref. '6') (Obsoleted by RFC 4587) ** Obsolete normative reference: RFC 3388 (ref. '7') (Obsoleted by RFC 5888) ** Obsolete normative reference: RFC 3448 (ref. '8') (Obsoleted by RFC 5348) ** Obsolete normative reference: RFC 2434 (ref. '10') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2733 (ref. '12') (Obsoleted by RFC 5109) -- Obsolete informational reference (is this intentional?): RFC 2429 (ref. '14') (Obsoleted by RFC 4629) -- Obsolete informational reference (is this intentional?): RFC 2833 (ref. '18') (Obsoleted by RFC 4733, RFC 4734) == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-05 -- Duplicate reference: RFC3448, mentioned in '20', was also mentioned in '8'. -- Obsolete informational reference (is this intentional?): RFC 3448 (ref. '20') (Obsoleted by RFC 5348) == Outdated reference: A later version (-12) exists of draft-ietf-avt-profile-savpf-00 Summary: 7 errors (**), 0 flaws (~~), 13 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-08.txt Stephan Wenger/TU Berlin 4 Noriyuki Sato/Oki 5 Carsten Burmeister/Matsushita 6 Jose Rey/Matsushita 8 31 January 2004 9 Expires July 2004 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.............................................6 55 2 RTP and RTCP Packet Formats and Protocol Behavior............6 56 2.1 RTP.....................................................6 57 2.2 Underlying Transport Protocols..........................7 58 3 Rules for RTCP Feedback......................................7 59 3.1 Compound RTCP Feedback Packets..........................7 60 3.2 Algorithm Outline.......................................9 61 3.3 Modes of Operation.....................................10 62 3.4 Definitions and Algorithm Overview.....................12 63 3.5 AVPF RTCP Scheduling Algorithm.........................15 64 3.5.1 Initialization...................................15 65 3.5.2 Early Feedback Transmission......................16 66 3.5.3 Regular RTCP Transmission........................18 67 3.5.4 Other Considerations.............................20 68 3.6 Considerations on the Group Size.......................20 69 3.6.1 ACK mode.........................................20 70 3.6.2 NACK mode........................................21 71 3.7 Summary of decision steps..............................22 72 3.7.1 General Hints....................................22 73 3.7.2 Media Session Attributes.........................23 74 4 SDP Definitions.............................................23 75 4.1 Profile identification.................................24 76 4.2 RTCP Feedback Capability Attribute.....................24 77 4.3 RTCP Bandwidth Modifiers...............................27 78 4.4 Examples...............................................28 79 5 Interworking and Co-Existence of AVP and AVPF Entities......30 80 6 Format of RTCP Feedback Messages............................31 81 6.1 Common Packet Format for Feedback Messages.............32 82 6.2 Transport Layer Feedback Messages......................34 83 6.2.1 Generic NACK.....................................34 84 6.2.2 Generic ACK......................................35 85 6.3 Payload Specific Feedback Messages.....................37 86 6.3.1 Picture Loss Indication (PLI)....................37 87 6.3.1.1 Semantics................................38 88 6.3.1.2 Message Format...........................38 89 6.3.1.3 Timing Rules.............................38 90 6.3.1.4 Remarks..................................38 92 6.3.2 Slice Lost Indication (SLI)......................39 93 6.3.2.1 Semantics................................39 94 6.3.2.2 Format...................................39 95 6.3.2.3 Timing Rules.............................40 96 6.3.2.4 Remarks..................................40 97 6.3.3 Reference Picture Selection Indication (RPSI)....41 98 6.3.3.1 Semantics................................41 99 6.3.3.2 Format...................................42 100 6.3.3.3 Timing Rules.............................42 101 6.4 Application Layer Feedback Messages....................43 102 7 Early Feedback and Congestion Control.......................43 103 8 Security Considerations.....................................44 104 9 IANA Considerations.........................................46 105 10 Acknowledgements.............................................50 106 11 Authors' Addresses...........................................50 107 12 Bibliography.................................................51 108 12.1 Normative references...................................51 109 12.2 Informative References.................................52 110 13 IPR Notice...................................................53 111 14 Full Copyright Statement.....................................53 113 1 Introduction 115 Real-time media streams that use RTP are, to some degree, resilient 116 against packet losses. RTP [1] provides all the necessary 117 mechanisms to restore ordering and timing present at the sender to 118 properly reproduce a media stream at a recipient. RTP also 119 provides continuous feedback about the overall reception quality 120 from all receivers -- thereby allowing the sender(s) in the mid- 121 term (in the order of several seconds to minutes) to adapt their 122 coding scheme and transmission behavior to the observed network 123 QoS. However, except for a few payload specific mechanisms [6], 124 RTP makes no provision for timely feedback that would allow a 125 sender to repair the media stream immediately: through 126 retransmissions, retro-active FEC control, or media-specific 127 mechanisms for some video codecs, such as reference picture 128 selection. 130 Current mechanisms available with RTP to improve error resilience 131 include audio redundancy coding [13], video redundancy coding [14], 132 RTP-level FEC [11], and general considerations on more robust media 133 streams transmission [12]. These mechanisms may be applied pro- 134 actively (thereby increasing the bandwidth of a given media 135 stream). Alternatively, in sufficiently small groups with small 136 RTTs, the senders may perform repair on-demand, using the above 137 mechanisms and/or media-encoding-specific approaches. Note that 138 "small group" and "sufficiently small RTT" are both highly 139 application dependent. 141 This document specifies a modified RTP Profile for audio and video 142 conferences with minimal control based upon [1] and [2] by means of 143 two modifications/additions: to achieve timely feedback, the 144 concept of Early RTCP messages as well as algorithms allowing for 145 low delay feedback in small multicast groups (and preventing 146 feedback implosion in large ones) are introduced. Special 147 consideration is given to point-to-point scenarios. A small number 148 of general-purpose feedback messages as well as a format for codec 149 and application-specific feedback information are defined for 150 transmission in the RTCP payloads. 152 1.1 Definitions 154 The definitions from RTP/RTCP [1] and the RTP Profile for Audio and 155 Video Conferences with Minimal Control [2] apply. In addition, the 156 following definitions are used in this document: 158 Early RTCP mode: 159 The mode of operation in which a receiver of a media stream 160 is often (but not always) capable of reporting events of 161 interest back to the sender close to their occurrence. In 162 Early RTCP mode, RTCP packets are transmitted according to 163 the timing rules defined in this document. 165 Early RTCP packet: 166 An Early RTCP packet is a packet which is transmitted 167 earlier than would be allowed if following the scheduling 168 algorithm of [1], the reason being an "event" observed by a 169 receiver. Early RTCP packets may be sent in Immediate 170 Feedback and in Early RTCP mode. Sending an Early RTCP 171 packet is also referred to as sending Early Feedback in 172 this document. 174 Event: 175 An observation made by the receiver of a media stream that 176 is (potentially) of interest to the sender -- such as a 177 packet loss or packet reception, frame loss, etc. -- and 178 thus useful to be reported back to the sender by means of a 179 Feedback message. 181 Feedback (FB) message: 182 An RTCP message as defined in this document is used to 183 convey information about events observed at a receiver -- 184 in addition to long-term receiver status information which 185 is carried in RTCP RRs -- back to the sender of the media 186 stream. For the sake of clarity, feedback message is 187 referred to as FB message throughout this document. 189 Feedback (FB) threshold: 190 The FB threshold indicates the transition between Immediate 191 Feedback and Early RTCP mode. For a multiparty scenario, 192 the FB threshold indicates the maximum group size at which, 193 on average, each receiver is able to report each event back 194 to the sender(s) immediately, i.e. by means of an Early 195 RTCP packet without having to wait for its regularly 196 scheduled RTCP interval. This threshold is highly 197 dependent on the type of feedback to be provided, network 198 QoS (e.g. packet loss probability and distribution), codec 199 and packetization scheme in use, the session bandwidth, and 200 application requirements. Note that the algorithms do not 201 depend on all senders and receivers agreeing on the same 202 value for this threshold. It is merely intended to provide 203 conceptual guidance to application designers and is not 204 used in any calculations. For the sake of clarity, the term 205 feedback threshold is referred to as FB threshold 206 throughout this document. 208 Immediate Feedback mode: 209 A mode of operation in which each receiver of a media 210 stream is, statistically, capable of reporting each event 211 of interest immediately back to the media stream sender. 212 In Immediate Feedback mode, RTCP FB messages are 213 transmitted according to the timing rules defined in this 214 document. 216 Media packet: 217 A media packet is an RTP packet. 219 Regular RTCP mode: 220 Mode of operation in which no preferred transmission of FB 221 messages is allowed. Instead, RTCP messages are sent 222 following the rules of [1]. Nevertheless, such RTCP 223 messages may contain feedback information as defined in 224 this document. 226 Regular RTCP packet: 227 An RTCP packet that is not sent as an Early RTCP packet. 229 RTP sender: 230 An RTP sender is an RTP entity that transmits media packets 231 as well as RTCP packets and receives Regular as well as 232 Early RTCP (i.e. feedback) packets. Note that the RTP 233 sender is a logical role and that the same RTP entity may 234 at the same time act as an RTP receiver. 236 RTP receiver: 237 An RTP receiver is an RTP entity that receives media 238 packets as well as RTCP packets and transmits Regular as 239 well as Early RTCP (i.e. feedback) packets. Note that the 240 RTP receiver is a logical role and that the same RTP entity 241 may at the same time act as an RTP sender. 243 1.2 Terminology 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 246 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 247 in this document are to be interpreted as described in RFC 2119 248 [5]. 250 2 RTP and RTCP Packet Formats and Protocol Behavior 252 2.1 RTP 254 The rules defined in [2] also apply to this profile except for 255 those rules mentioned in the following: 257 RTCP packet types: 258 Two additional RTCP packet types are registered and the 259 corresponding FB messages to convey feedback information 260 are defined in section 6 of this memo. 262 RTCP report intervals: 263 This document describes three modes of operation which 264 influence the RTCP report intervals (see section 3.2 of 265 this memo). In Regular RTCP mode, all rules from [1] apply 266 except for the recommended minimal interval of five seconds 267 between two RTCP reports from the same RTP entity. In both 268 Immediate Feedback and Early RTCP modes, the minimal 269 interval of five seconds between two RTCP reports is 270 dropped and, additionally, the rules specified in section 3 271 of this memo apply if RTCP packets containing FB messages 272 (defined in section 4 of this memo) are to be transmitted. 274 The rules set forth in [1] may be overridden by session 275 descriptions specifying different parameters (e.g. for the 276 bandwidth share assigned to RTCP for senders and receivers, 277 respectively). For sessions defined using the Session 278 Description Protocol (SDP) [3], the rules of [4] apply. 280 Congestion control: 281 The same basic rules as detailed in [2] apply. Beyond 282 this, in section 7, further consideration is given to the 283 impact of feedback and a sender's reaction to FB messages. 285 2.2 Underlying Transport Protocols 287 RTP is intended to be used on top of unreliable transport 288 protocols, including UDP and DCCP. This section briefly describes 289 the specifics beyond plain RTP operation introduced by RTCP 290 feedback as specified in this memo. 291 UDP: UDP provides best effort delivery of datagrams for point- 292 to-point as well as for multicast communications. UDP does 293 not support congestion control or error repair. The RTCP- 294 based feedback defined in this memo is able to provide 295 minimal support for congestion control for RTP-over-UDP 296 traffic as well as for limited error repair. It should be 297 noted, however, that RTCP feedback does not operate on RTT 298 timescales. This memo addresses both unicast and multicast 299 operation. 301 DCCP: DCCP [19] provides for congestion-controlled but unreliable 302 datagram flows for unicast communications. With TFRC-based 303 [20] congestion control (CCID 3), DCCP is particularly 304 suitable for audio and video communications. DCCP's 305 acknowledgement messages may provide detailed feedback 306 reporting about received and missed datagrams (and thus 307 about congestion). RTCP-based feedback using the Generic 308 Feedback messages (section 6.2) may be used to provide 309 similar information, albeit at a much lower rate. 311 When running RTP over DCCP, congestion control is performed 312 at the DCCP layer and no additional mechanisms are required 313 at the RTP layer. Furthermore, an RTCP-feedback capable 314 sender may leverage the more frequent DCCP-based feedback 315 and thus a receiver may abstain from using (additional) 316 Generic Feedback messages where appropriate. 318 3 Rules for RTCP Feedback 320 3.1 Compound RTCP Feedback Packets 322 Two components constitute RTCP-based feedback as described in this 323 document: 325 o Status reports are contained in SR/RR packets and are 326 transmitted at regular intervals as part of compound RTCP 327 packets (which also include SDES and possibly other messages); 328 these status reports provide an overall indication for the 329 recent reception quality of a media stream. 331 o FB messages as defined in this document that indicate loss or 332 reception of particular pieces of a media stream (or provide 333 some other form of rather immediate feedback on the data 334 received). Rules for the transmission of FB messages are newly 335 introduced in this document. 337 RTCP FB messages are just another RTCP packet type (see section 338 4). Therefore, multiple FB messages MAY be combined in a single 339 compound RTCP packet and they MAY also be sent combined with other 340 RTCP packets. 342 Compound RTCP packets containing FB messages as defined in this 343 document MUST contain RTCP packets in the order defined in [1]: 345 o OPTIONAL encryption prefix that MUST be present if the RTCP 346 packet(s) is to be encrypted according to section 9.1 of [1]. 347 o MANDATORY SR or RR. 348 o MANDATORY SDES which MUST contain the CNAME item; all other SDES 349 items are OPTIONAL. 350 o One or more FB messages. 352 The FB message(s) MUST be placed in the compound packet after RR 353 and SDES RTCP packets defined in [1]. The ordering with respect to 354 other RTCP extensions is not defined. 356 Two types of compound RTCP packets carrying feedback packets are 357 used in this document: 359 a) Minimal compound RTCP feedback packet 361 A minimal compound RTCP feedback packet MUST contain only the 362 mandatory information as listed above: encryption prefix if 363 necessary, exactly one RR or SR, exactly one SDES with only the 364 CNAME item present, and the FB message(s). This is to minimize 365 the size of the RTCP packet transmitted to convey feedback and 366 thus to maximize the frequency at which feedback can be 367 provided while still adhering to the RTCP bandwidth 368 limitations. 370 This packet format SHOULD be used whenever an RTCP FB message 371 is sent as part of an Early RTCP packet. This packet type is 372 referred to as minimal compound RTCP packet in this document. 374 b) (Full) compound RTCP feedback packet 375 A (full) compound RTCP feedback packet MAY contain any 376 additional number of RTCP packets (additional RRs, further SDES 377 items, etc.). The above ordering rules MUST be adhered to. 379 This packet format MUST be used whenever an RTCP FB message is 380 sent as part of a Regular RTCP packet or in Regular RTCP mode. 381 It MAY also be used to send RTCP FB messages in Immediate 382 Feedback or Early RTCP mode. This packet type is referred to as 383 full compound RTCP packet in this document. 385 RTCP packets that do not contain FB messages are referred to as 386 non-FB RTCP packets. Such packets MUST follow the format rules in 387 [1]. 389 3.2 Algorithm Outline 391 FB messages are part of the RTCP control streams and thus subject 392 to the RTCP bandwidth constraints. This means, in particular, that 393 it may not be possible to report an event observed at a receiver 394 immediately back to the sender. However, the value of feedback 395 given to a sender typically decreases over time -- in terms of the 396 media quality as perceived by the user at the receiving end and/or 397 the cost required to achieve media stream repair. 399 RTP [1] and the commonly used RTP profile [2] specify rules when 400 compound RTCP packets should be sent. This document modifies those 401 rules in order to allow applications to timely report events (e.g. 402 loss or reception of RTP packets) and to accommodate algorithms 403 that use FB messages. 405 The modified RTCP transmission algorithm can be outlined as 406 follows: As long as no FB messages have to be conveyed, compound 407 RTCP packets are sent following the rules of RTP [1] -- except that 408 the five second minimum interval between RTCP reports is not 409 enforced. Hence, the interval between RTCP reports is only derived 410 from the average RTCP packet size and the RTCP bandwidth share 411 available to the RTP/RTCP entity. Optionally, a minimum interval 412 between Regular RTCP packets may be enforced. 414 If a receiver detects the need to send an FB message, it may do so 415 earlier than the next regular RTCP reporting interval (for which it 416 would be scheduled following the above regular RTCP algorithm). 417 Feedback suppression is used to avoid feedback implosion in 418 multiparty sessions: The receiver waits for a (short) random 419 dithering interval to check whether it sees a corresponding FB 420 message from any other receiver reporting the same event. Note 421 that for point-to-point sessions there is no such delay. If a 422 corresponding FB message from another member is received, this 423 receiver refrains from sending the FB message and continues to 424 follow the Regular RTCP transmission schedule. In case the 425 receiver has not yet seen a corresponding FB message from any other 426 member, it checks whether it is allowed to send Early feedback. If 427 sending Early feedback is permissible , the receiver sends the FB 428 message as part of a minimal compound RTCP packet. The permission 429 to send Early feedback depends on the type of the previous RTCP 430 packet sent by this receiver and the time the previous Early 431 feedback message was sent. 433 FB messages may also be sent as part of full compound RTCP packets 434 which are transmitted as per [1] (except for the five second lower 435 bound) in regular intervals. 437 3.3 Modes of Operation 439 RTCP-based feedback may operate in one of three modes (figure 1) as 440 described below. The mode of operation is just an indication of 441 whether or not the receiver will, on average, be able to report all 442 events to the sender in a timely fashion; the mode does not 443 influence the algorithm used for scheduling the transmission of FB 444 messages. And, depending on the reception quality and the locally 445 monitored state of the RTP session, individual receivers may not 446 (and not have to) agree on a common perception on the current mode 447 of operation. 449 a) Immediate Feedback mode: the group size is below the FB 450 threshold which gives each receiving party sufficient bandwidth 451 to transmit the RTCP feedback packets for the intended purpose. 452 This means that, for each receiver, there is enough bandwidth 453 to report each event by means of a virtually "immediate" RTCP 454 feedback packet. 456 The group size threshold is a function of a number of 457 parameters including (but not necessarily limited to): the type 458 of feedback used (e.g. ACK vs. NACK), bandwidth, packet rate, 459 packet loss probability and distribution, media type, codec, 460 and the (worst case or observed) frequency of events to report 461 (e.g. frame received, packet lost). 463 As a rough estimate, let N be the average number of events to 464 be reported per interval T by a receiver, B the RTCP bandwidth 465 fraction for this particular receiver and R the average RTCP 466 packet size, then the receiver operates in Immediate Feedback 467 mode as long as N<=B*T/R. 469 b) Early RTCP mode: In this mode, the group size and other 470 parameters no longer allow each receiver to react to each event 471 that would be worth (or needed) to report. But feedback can 472 still be given sufficiently often so that it allows the sender 473 to adapt the media stream transmission accordingly and thereby 474 increase the overall media playback quality. 476 Using the above notation, Early RTCP mode can be roughly 477 characterized by N > B*T/R as "lower bound". An estimate for 478 an upper bound is more difficult. Setting N=1, we obtain for a 479 given R and B the interval T = R/B as average interval between 480 events to be reported. This information can be used as a hint 481 to determine whether or not early transmission of RTCP packets 482 is useful. 484 c) Regular RTCP Mode: From some group size upwards, it is no 485 longer useful to provide feedback for individual events from 486 receivers at all -- because of the time scale in which the 487 feedback could be provided and/or because in large groups the 488 sender(s) have no chance to react to individual feedback 489 anymore. 491 No precise group size threshold can be specified at which this 492 mode starts but, obviously, this boundary matches the upper 493 bound of the Early RTCP mode as specified in item b). 495 As the feedback algorithm described in this document scales 496 smoothly, there is no need for an agreement among the participants 497 on the precise values of the respective FB thresholds within the 498 group. Hence the borders between all these modes are soft. 500 ACK 501 feedback 502 V 503 :<- - - - NACK feedback - - - ->// 504 : 505 : Immediate || 506 : Feedback mode ||Early RTCP mode Regular RTCP mode 507 :<=============>||<=============>//<=================> 508 : || 509 -+---------------||---------------//------------------> group size 510 2 || 511 Application-specific FB Threshold 512 = f(data rate, packet loss, codec, ...) 514 Figure 1: Modes of operation 516 As stated before, the respective FB thresholds depend on a number 517 of technical parameters (of the codec, the transport, the type of 518 feedback used, etc.) but also on the respective application 519 scenarios. Section 3.6 provides some useful hints (but no precise 520 calculations) on estimating these thresholds. 522 3.4 Definitions and Algorithm Overview 524 The following pieces of state information need to be maintained per 525 receiver (largely taken from [1]). Note that all variables (except 526 in item h) below) are calculated independently at each receiver. 527 Therefore, their local values may differ at any given point in 528 time. 530 a) Let "senders" be the number of active senders in the RTP 531 session. 533 b) Let "members" be the current estimate of the number of receivers 534 in the RTP session. 536 c) Let tn and tp be the time for the next (last) scheduled 537 RTCP RR transmission calculated prior to reconsideration. 539 d) Let Tmin be the minimal interval between RTCP packets as per 540 [1]. Unlike in [1], the initial Tmin is set to 1 second to 541 allow for some group size sampling before sending the first RTCP 542 packet. After the first RTCP packet is sent, Tmin is set to 0. 544 e) Let T_rr be the interval after which, having just sent a 545 regularly scheduled RTCP packet, a receiver would schedule the 546 transmission of its next Regular RTCP packet. This value is 547 obtained following the rules of [1] but with Tmin as defined in 548 this document: T_rr = T (the "calculated interval" as defined in 549 [1]) with tn = tp + T. T_rr always refers to the last value of 550 T that has been computed (because of reconsideration or to 551 determine tn). T_rr is also referred to as Regular RTCP interval 552 in this document. 554 f) Let t0 be the time at which an event that is to be reported is 555 detected by a receiver. 557 g) Let T_dither_max be the maximum interval for which an RTCP 558 feedback packet MAY be additionally delayed to prevent 559 implosions in multiparty sessions; the value for T_dither_max is 560 dynamically calculated based upon T_rr (or may be derived by 561 means of another mechanism common across all RTP receivers to be 562 specified in the future). For point-to-point sessions (i.e. 563 sessions with exactly two members with no change in the group 564 size expected, e.g. unicast streaming sessions), T_dither_max is 565 set to 0. 567 h) Let T_max_fb_delay be the upper bound within which feedback to 568 an event needs to be reported back to the sender to be useful at 569 all. This value is application-specific; and no values are 570 defined in this document. 572 i) Let te be the time for which a feedback packet is scheduled. 574 j) Let T_fd be the actual (randomized) delay for the transmission 575 of FB message in response to an event at time t0. 577 k) Let allow_early be a Boolean variable that indicates whether the 578 receiver currently may transmit FB messages prior to its next 579 regularly scheduled RTCP interval tn. This variable is used to 580 throttle the feedback sent by a single receiver. allow_early is 581 set to FALSE after Early feedback transmission and is set to 582 TRUE as soon as the next Regular RTCP transmission takes place. 584 l) Let avg_rtcp_size be the moving average on the RTCP packet size 585 as defined in [1]. 587 m) Let T_rr_interval be an OPTIONAL minimal interval to be used 588 between Regular RTCP packets. If T_rr_interval == 0, then this 589 variable does not have any impact on the overall operation of 590 the RTCP feedback algorithm. If T_rr_interval != 0 then the 591 next Regular RTCP packet will not be scheduled T_rr after the 592 last Regular RTCP transmission (i.e. at tp+T_rr). Instead, the 593 next Regular RTCP packet will be delayed until at least 594 T_rr_interval after the last Regular RTCP transmission, i.e. it 595 will be scheduled at or later than tp+T_rr_interval. Note that 596 T_rr_interval does not affect the calculation of T_rr and tp; 597 instead, Regular RTCP packets scheduled for transmission before 598 tp+T_rr_interval will be suppressed if, for example, they do not 599 contain any FB messages. The T_rr_interval does not affect 600 transmission scheduling of Early RTCP packets. 602 NOTE: Providing T_rr_interval as an independent variable is meant 603 to minimize Regular RTCP feedback (and thus bandwidth consumption) 604 as needed by the application while additionally allowing the use of 605 more frequent Early RTCP packets to provide timely feedback. This 606 goal could not be achieved by reducing the overall RTCP bandwidth 607 as RTCP bandwidth reduction would also impact the frequency of 608 Early feedback. 610 n) Let t_rr_last be the point in time at which the last Regular 611 RTCP packet has been scheduled and sent, i.e. has not been 612 suppressed due to T_rr_interval. 614 o) Let T_retention be the time window for which past FB messages 615 are stored by an AVPF entity. This is to ensure that feedback 616 suppression also works for entities that have received FB 617 messages from other entities prior to noticing the feedback 618 event itself. T_retention MUST be set to at least 2 seconds. 620 p) Let M*Td be the timeout value for a receiver to be considered 621 inactive (as defined in [1]). 623 The feedback situation for an event to report at a receiver is 624 depicted in figure 2 below. At time t0, such an event (e.g. a 625 packet loss) is detected at the receiver. The receiver decides -- 626 based upon current bandwidth, group size, and other application- 627 specific parameters -- that a FB message needs to be sent back to 628 the sender. 630 To avoid an implosion of feedback packets in multiparty sessions, 631 the receiver MUST delay the transmission of the RTCP feedback 632 packet by a random amount of time T_fd (with the random number 633 evenly distributed in the interval [0, T_dither_max]). 634 Transmission of the compound RTCP packet MUST then be scheduled for 635 te = t0 + T_fd. 637 The T_dither_max parameter is derived from the Regular RTCP 638 interval, T_rr, which, in turn, is based upon the group size. A 639 future document may also specify other calculations for 640 T_dither_max (e.g. based upon RTT) if it can be assured that all 641 RTP receivers will use the same mechanism for calculating 642 T_dither_max. 644 For a certain application scenario, a receiver may determine an 645 upper bound for the acceptable local delay of FB messages: 646 T_max_fb_delay. If an a priori estimation or the actual 647 calculation of T_dither_max indicates that this upper bound MAY be 648 violated (e.g. because T_dither_max > T_max_fb_delay), the receiver 649 MAY decide not to send any feedback at all because the achievable 650 gain is considered insufficient. 652 If an Early RTCP packet is scheduled, the time slot for the next 653 Regular RTCP packet MUST be updated accordingly to a new tn: 654 tn=tp+2*T_rr and so MUST tp: tp=tp+T_rr afterwards. This is to 655 ensure that the short-term average RTCP bandwidth used with Early 656 feedback does not exceed the bandwidth used without Early 657 feedback. 659 event to 660 report 661 detected 662 | 663 | RTCP feedback range 664 | (T_max_fb_delay) 665 vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) ) 666 |---+--------+-------------+-----+------------| |--------+---> 667 | | | | ( ( | 668 | t0 te | 669 tp tn 670 \_______ ________/ 671 \/ 672 T_dither_max 674 Figure 2: Event report and parameters for Early RTCP scheduling 676 3.5 AVPF RTCP Scheduling Algorithm 678 Let S0 be an active sender (out of S senders) and let N be the 679 number of receivers with R being one of these receivers. 681 Assume that R has verified that using feedback mechanisms is 682 reasonable at the current constellation (which is highly 683 application specific and hence not specified in this document). 685 Assume further that T_rr_interval is 0, if no minimal interval 686 between Regular RTCP packets is to be enforced, or T_rr_interval is 687 set to some meaningful value, as given by the application. This 688 value then denotes the minimal interval between Regular RTCP 689 packets. 691 With this, a receiver R MUST use the following rules for 692 transmitting one or more FB messages as minimal or full compound 693 RTCP packet: 695 3.5.1 Initialization 697 Initially, R MUST set allow_early = TRUE and t_rr_last = NaN (Not- 698 a-Number, i.e. some invalid value that can be distinguished from a 699 valid time). 701 Furthermore, the initialization of the RTCP variables as per [1] 702 applies except that the initial value for Tmin. For a point-to- 703 point session, the initial Tmin is set to 0. For a multiparty 704 session, Tmin is initialized to 1.0 seconds. 706 3.5.2 Early Feedback Transmission 708 Assume that R had scheduled the last Regular RTCP RR packet for 709 transmission at tp (and sent or suppressed this packet at tp) and 710 has scheduled the next transmission (including possible 711 reconsideration as per [1]) for tn = tp + T_rr. Assume also that 712 the last Regular RTCP packet transmission has occurred at 713 t_rr_last. 715 The Early Feedback algorithm then comprises the following steps: 717 1. At time t0, R detects the need to transmit one or more FB 718 messages, e.g. because media "units" need to be ACKed or NACKed, 719 and finds that providing the feedback information is potentially 720 useful for the sender. 722 2. R first checks whether there is already a compound RTCP packet 723 containing one or more FB messages scheduled for transmission 724 (either as Early or as Regular RTCP packet). 726 2.a) If so, the new FB message MUST be included in the 727 scheduled packet; the scheduling of the waiting compound RTCP 728 packet MUST remain unchanged. When doing so, the available 729 feedback information SHOULD be merged to produce as few FB 730 messages as possible. This completes the course of immediate 731 actions to be taken. 733 2.b) If no compound RTCP packet is already scheduled for 734 transmission, a new (minimal or full) compound RTCP packet 735 MUST be created and the minimal interval for T_dither_max MUST 736 be chosen as follows: 738 i) If the session is a point-to-point session then 739 T_dither_max = 0. 741 ii) If the session is a multiparty session then 743 T_dither_max = l * T_rr 745 with l=0.5. 747 The value for T_dither_max MAY be calculated differently (e.g. 748 based upon RTT) which MUST then be specified in a future 749 document. Such a future specification MUST ensure that all 750 RTP receivers use the same mechanism to calculate 751 T_dither_max. 753 The values given above for T_dither_max are minimal values. 754 Application-specific feedback considerations may make it 755 worthwhile to increase T_dither_max beyond this value. This 756 is up to the discretion of the implementer. 758 3. Then, R MUST check whether its next Regular RTCP packet would be 759 within the time bounds for the Early RTCP packet triggered at t0, 760 i.e. if t0 + T_dither_max > tn. 762 3.a) If so, an Early RTCP packet MUST NOT be scheduled; 763 instead the FB message(s) MUST be stored to be included in the 764 Regular RTCP packet scheduled for tn. This completes the 765 course of immediate actions to be taken. 767 3.b) Otherwise, the following steps are carried out. 769 4. R MUST check whether it is allowed to transmit an Early RTCP 770 packet, i.e. allow_early == TRUE, or not. 772 4.a) If allow_early == FALSE then R MUST check the time for the 773 next scheduled Regular RTCP packet: 775 1. If tn - t0 < T_max_fb_delay then the feedback could 776 still be useful for the sender, despite the late 777 reporting. Hence, R MAY create an RTCP FB message to 778 be included in the Regular RTCP packet for 779 transmission at tn. 781 2. Otherwise, R MUST discard the RTCP FB message. 783 This completes the immediate course of actions to be taken. 785 4.b) If allow_early == TRUE then R MUST schedule an Early RTCP 786 packet for te = t0 + RND * T_dither_max with RND being a pseudo 787 random function evenly distributed between 0 and 1. 789 5. R MUST detect overlaps in FB messages received from other 790 members of the RTP session and the FB messages R wants to send. 791 Therefore, while member of the RTP session, R MUST continuously 792 monitor the arrival of (minimal) compound RTCP packets and store 793 each FB message contained in these RTCP packets for at least 794 T_retention. When scheduling the transmission of its own FB 795 message following steps 1. through 4. above, R MUST check each of 796 the stored and newly received FB messages from the RTCP packets 797 received during the interval [t0 - T_retention ; te] and act as 798 follows: 800 5.a) If R understands the received FB message's semantics and 801 the message contents is a superset of the feedback R wanted to 802 send then R MUST discard its own FB message and MUST re- 803 schedule the next Regular RTCP packet transmission for tn (as 804 calculated before). 806 5.b) If R understands the received FB message's semantics and 807 the message contents is not a superset of the feedback R wanted 808 to send then R SHOULD transmit its own FB message as scheduled. 809 If there is an overlap between the feedback information to send 810 and the feedback information received, the amount of feedback 811 transmitted is up to R: R MAY leave its feedback information to 812 be sent unchanged, R MAY as well eliminate any redundancy 813 between its own feedback and the feedback received so far from 814 other session members. 816 5.c) If R does not understand the received FB message's 817 semantics, R MAY keep its own FB message scheduled as an Early 818 RTCP packet, or R MAY re-schedule the next Regular RTCP packet 819 transmission for tn (as calculated before) and MAY append the 820 FB message to the now regularly scheduled RTCP message. 822 Note: With 5.c), receiving unknown FB messages may not lead to 823 feedback suppression at a particular receiver. As a 824 consequence, a given event may cause M different types of FB 825 messages (which are all appropriate but not mutually 826 understood) to be scheduled, so that a "large" receiver group 827 may effectively be partitioned into at most M groups. Among 828 members of each of these M groups, feedback suppression will 829 occur following 5.a and 5.b but no suppression will happen 830 across groups. As a result, O(M) RTCP FB messages may be 831 received by the sender. Hence, there is a chance for a very 832 limited feedback implosion. However, as sender(s) and all 833 receivers make up the same application using the same (set of) 834 codecs in the same RTP session, only little divergence in 835 semantics for FB messages can safely be assumed and, therefore, 836 M is assumed to be small in the general case. Given further 837 that the O(M) FB messages are randomly distributed over a time 838 interval of T_dither_max we find that the resulting limited 839 number of extra compound RTCP packets (a) is assumed not to 840 overwhelm the sender and (b) should be conveyed as all contain 841 complementary pieces of information. 843 6. If R's FB message(s) was not suppressed by other receiver FB 844 messages as per 5., when te is reached, R MUST transmit the 845 (minimal) compound RTCP packet containing its FB message(s). R 846 then MUST set allow_early = FALSE, MUST recalculate tn = tp + 847 2*T_rr, and MUST set tp to the previous tn. As soon as the newly 848 calculated tn is reached, regardless whether R sends its next 849 Regular RTCP packet or suppresses it because of T_rr_interval, it 850 MUST set allow_early = TRUE again. 852 3.5.3 Regular RTCP Transmission 853 Full compound RTCP packets MUST be sent in regular intervals. 854 These packets MAY also contain one or more FB messages. 855 Transmission of Regular RTCP packets is scheduled as follows: 857 If T_rr_interval == 0 then the transmission MUST follow the rules 858 as specified in section 3.2 and 3.4 of this document and MUST 859 adhere to the adjustments of tn specified in section 3.5.2, i.e. 860 skip one regular transmission if an Early RTCP packet transmission 861 has occurred. Timer reconsideration takes place when tn is reached 862 as per [1]. The Regular RTCP packet is transmitted after timer 863 reconsideration. Whenever a Regular RTCP packet is sent or 864 suppressed, allow_early MUST be set to TRUE and tp, tn MUST be 865 updated as per [1]. After the first transmission of a Regular RTCP 866 packet, Tmin MUST be set to 0. 868 If T_rr_interval != 0 then the calculation for the transmission 869 times MUST follow the rules as specified in section 3.2 and 3.4 of 870 this document and MUST adhere to the adjustments of tn specified in 871 section 3.5.2 (i.e. skip one regular transmission if an Early RTCP 872 transmission has occurred). Timer reconsideration takes place when 873 tn is reached as per [1]. After timer reconsideration, the 874 following actions are taken: 876 1. If no Regular RTCP packet has been sent before (i.e. if 877 t_rr_last == NaN) then a Regular RTCP packet MUST be 878 scheduled. Stored FB messages MAY be included in the 879 Regular RTCP packet. After the scheduled packet has been 880 sent, t_rr_last MUST be set to tn. Tmin MUST be set to 0. 882 2. Otherwise, a temporary value T_rr_current_interval is 883 calculated as follows: 885 T_rr_current_interval = RND*T_rr_interval 887 with RND being a pseudo random function evenly distributed 888 between 0.5 and 1.5. This dithered value is used to 889 determine one of the following alternatives: 891 2a) If t_rr_last + T_rr_current_interval <= tn then a 892 Regular RTCP packet MUST be scheduled. Stored RTCP FB 893 messages MAY be included in the Regular RTCP packet. 894 After the scheduled packet has been sent, t_rr_last 895 MUST be set to tn. 897 2b) If t_rr_last + T_rr_current_interval > tn and RTCP FB 898 messages have been stored and are awaiting 899 transmission, an RTCP packet MUST be scheduled for 900 transmission at tn. This RTCP packet MAY be a minimal 901 or a Regular RTCP packet (at the discretion of the 902 implementer) and the compound RTCP packet MUST include 903 the stored RTCP FB message(s). t_rr_last MUST remain 904 unchanged. 906 2c) Otherwise (if t_rr_last + T_rr_current_interval > tn 907 but no stored RTCP FB messages are awaiting 908 transmission), the compound RTCP packet MUST be 909 suppressed (i.e. it MUST NOT be scheduled). t_rr_last 910 MUST remain unchanged. 912 In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST 913 be set to TRUE (possibly after sending the Regular RTCP packet) and 914 tp and tn MUST be updated following the rules of [1] except for the 915 five second minimum. 917 3.5.4 Other Considerations 919 If T_rr_interval != 0 then the timeout calculation for RTP/AVPF 920 entities (section 6.3.5 of [1]) MUST be modified to use 921 T_rr_interval instead of Tmin for computing Td and thus M*Td. 923 Whenever a compound RTCP packet is sent or received -- minimal or 924 full compound, Early or Regular -- the avg_rtcp_size variable MUST 925 be updated accordingly (see [1]) and subsequent computations of tn 926 MUST use the new avg_rtcp_size. 928 3.6 Considerations on the Group Size 930 This section provides some guidelines to the group sizes at which 931 the various feedback modes may be used. 933 3.6.1 ACK mode 935 The RTP session MUST have exactly two members and this group size 936 MUST NOT grow, i.e. it MUST be point-to-point communications. 937 Unicast addresses SHOULD be used in the session description. 939 For unidirectional as well as bi-directional communication between 940 two parties, 2.5% of the RTP session bandwidth is available for 941 RTCP traffic from the receivers including feedback. For a 64 942 kbit/s stream this yields 1,600 bit/s for RTCP. If we assume an 943 average of 96 bytes (=768 bits) per RTCP packet a receiver can 944 report 2 events per second back to the sender. If acknowledgments 945 for 10 events are collected in each FB message then 20 events can 946 be acknowledged per second. At 256 kbit/s 8 events could be 947 reported per second; thus the ACKs may be sent in a finer 948 granularity (e.g. only combining three ACKs per FB message). 950 From 1 Mbit/s upwards, a receiver would be able to acknowledge each 951 individual frame (not packet!) in a 30 fps video stream. 953 ACK strategies MUST be defined to work properly with these 954 bandwidth limitations. An indication whether or not ACKs are 955 allowed for a session and, if so, which ACK strategy should be 956 used, MAY be conveyed by out-of-band mechanisms, e.g. media- 957 specific attributes in a session description using SDP. 959 3.6.2 NACK mode 961 Negative acknowledgements (and other types of feedback exhibiting 962 similar reporting characteristics) MUST be used for all sessions 963 with a group size that may grow larger than two. Of course, NACKs 964 MAY be used for point-to-point communications as well. 966 Whether or not the use of Early RTCP packets should be considered 967 depends upon a number of parameters including session bandwidth, 968 codec, special type of feedback, number of senders and receivers. 970 The most important parameters when determining the mode of 971 operation are the allowed minimal interval between two compound 972 RTCP packets (T_rr) and the average number of events that 973 presumably need reporting per time interval (plus their 974 distribution over time, of course). The minimum interval can be 975 derived from the available RTCP bandwidth and the expected average 976 size of an RTCP packet. The number of events to report e.g. per 977 second may be derived from the packet loss rate and sender's rate 978 of transmitting packets. From these two values, the allowable 979 group size for the Immediate Feedback mode can be calculated. 981 Let N be the average number of events to be reported per 982 interval T by a receiver, B the RTCP bandwidth fraction for 983 this particular receiver and R the average RTCP packet size, 984 then the receiver operates in Immediate Feedback mode as long 985 as N<=B*T/R. 987 The upper bound for the Early RTCP mode then solely depends on the 988 acceptable quality degradation, i.e. how many events per time 989 interval may go unreported. 991 Using the above notation, Early RTCP mode can be roughly 992 characterized by N > B*T/R as "lower bound". An estimate for 993 an upper bound is more difficult. Setting N=1, we obtain for a 994 given R and B the interval T = R/B as average interval between 995 events to be reported. This information can be used as a hint 996 to determine whether or not early transmission of RTCP packets 997 is useful. 999 Example: If a 256kbit/s video with 30 fps is transmitted through a 1000 network with an MTU size of some 1,500 bytes, then, in most cases, 1001 each frame would fit in into one packet leading to a packet rate of 1002 30 packets per second. If 5% packet loss occurs in the network 1003 (equally distributed, no inter-dependence between receivers), then 1004 each receiver will, on average, have to report 3 packets lost each 1005 two seconds. Assuming a single sender and more than three 1006 receivers, this yields 3.75% of the RTCP bandwidth allocated to the 1007 receivers and thus 9.6kbit/s. Assuming further a size of 120 bytes 1008 for the average compound RTCP packet allows 10 RTCP packets to be 1009 sent per second or 20 in two seconds. If every receiver needs to 1010 report three lost packets per two seconds, this yields a maximum 1011 group size of 6-7 receivers if all loss events shall be reported. 1012 The rules for transmission of Early RTCP packets should provide 1013 sufficient flexibility for most of this reporting to occur in a 1014 timely fashion. 1016 Extending this example to determine the upper bound for Early RTCP 1017 mode could lead to the following considerations: assume that the 1018 underlying coding scheme and the application (as well as the 1019 tolerant users) allow on the order of one loss without repair per 1020 two seconds. Thus the number of packets to be reported by each 1021 receiver decreases to two per two seconds second and increases the 1022 group size to 10. Assuming further that some number of packet 1023 losses are correlated, feedback traffic is further reduced and 1024 group sizes of some 12 to 16 (maybe even 20) can be reasonably well 1025 supported using Early RTCP mode. Note that all these 1026 considerations are based upon statistics and will fail to hold in 1027 some cases. 1029 3.7 Summary of decision steps 1031 3.7.1 General Hints 1033 Before even considering whether or not to send RTCP feedback 1034 information an application has to determine whether this mechanism 1035 is applicable: 1037 1) An application has to decide whether -- for the current ratio of 1038 packet rate with the associated (application-specific) maximum 1039 feedback delay and the currently observed round-trip time (if 1040 available) -- feedback mechanisms can be applied at all. 1042 This decision may be based upon (and dynamically revised 1043 following) RTCP reception statistics as well as out-of-band 1044 mechanisms. 1046 2) The application has to decide -- for a certain observed error 1047 rate, assigned bandwidth, frame/packet rate, and group size -- 1048 whether (and which) feedback mechanisms can be applied. 1050 Regular RTCP reception statistics provide valuable input to this 1051 step, too. 1053 3) If the application decides to send feedback, the application has 1054 to follow the rules for transmitting Early RTCP packets or 1055 Regular RTCP packets containing FB messages. 1057 4) The type of RTCP feedback sent should not duplicate information 1058 available to the sender from a lower layer transport protocol. 1059 That is, if the transport protocol provides negative or positive 1060 acknowledgements about packet reception (such as DCCP), the 1061 receiver should avoid repeating the same information at the RTCP 1062 layer (i.e. abstain from sending Generic ACKs or Generic NACKs). 1064 3.7.2 Media Session Attributes 1066 Media sessions are typically described using out-of-band mechanisms 1067 to convey transport addresses, codec information, etc. between 1068 sender(s) and receiver(s). Such a mechanism is two-fold: a format 1069 used to describe a media session and another mechanism for 1070 transporting this description. 1072 In the IETF, the Session Description Protocol (SDP) is currently 1073 used to describe media sessions while protocols such as SIP, SAP, 1074 RTSP, and HTTP (among others) are used to convey the descriptions. 1076 A media session description format MAY include parameters to 1077 indicate that RTCP feedback mechanisms are supported in this 1078 session and which of the feedback mechanisms MAY be applied. 1080 To do so, the profile "AVPF" MUST be indicated instead of "AVP". 1081 Further attributes may be defined to show which type(s) of feedback 1082 are supported. 1084 Section 4 contains the syntax specification to support RTCP 1085 feedback with SDP. Similar specifications for other media session 1086 description formats are outside the scope of this document. 1088 4 SDP Definitions 1090 This section defines a number of additional SDP parameters that are 1091 used to describe a session. All of these are defined as media 1092 level attributes. 1094 4.1 Profile identification 1096 The AV profile defined in [4] is referred to as "AVP" in the 1097 context of e.g. the Session Description Protocol (SDP) [3]. The 1098 profile specified in this document is referred to as "AVPF". 1100 Feedback information following the modified timing rules as 1101 specified in this document MUST NOT be sent for a particular media 1102 session unless the description for this session indicates the use 1103 of the "AVPF" profile (exclusively or jointly with other AV 1104 profiles). 1106 4.2 RTCP Feedback Capability Attribute 1108 A new payload format-specific SDP attribute is defined to indicate 1109 the capability of using RTCP feedback as specified in this 1110 document: "a=rtcp-fb". The "rtcp-fb" attribute MUST only be used 1111 as an SDP media attribute and MUST NOT be provided at the session 1112 level. The "rtcp-fb" attribute MUST only be used in media sessions 1113 for which the "AVPF" is specified. 1115 The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB 1116 messages MAY be used in this media session for the indicated 1117 payload type. A wildcard payload type ("*") MAY be used to 1118 indicate that the RTCP feedback attribute applies to all payload 1119 types. If several types of feedback are supported and/or the same 1120 feedback shall be specified for a subset of the payload types, 1121 several "a=rtcp-fb" lines MUST be used. 1123 If no "rtcp-fb" attribute is specified the RTP receivers MAY send 1124 feedback using other suitable RTCP feedback packets as defined for 1125 the respective media type. The RTP receivers MUST NOT rely on the 1126 RTP senders reacting to any of the FB messages. The RTP sender MAY 1127 choose to ignore some feedback messages. 1129 If one or more "rtcp-fb" attributes are present in a media session 1130 description, the RTCP receivers for the media session(s) containing 1131 the "rtcp-fb" 1133 o MUST ignore all "rtcp-fb" attributes of which they do not fully 1134 understand the semantics (i.e. where they do not understand the 1135 meaning of all values in the "a=rtcp-fb" line); 1137 o SHOULD provide feedback information as specified in this 1138 document using any of the RTCP feedback packets as specified in 1139 one of the "rtcp-fb" attributes for this media session; and 1141 o MUST NOT use other FB messages than those listed in one of the 1142 "rtcp-fb" attribute lines. 1144 When used in conjunction with the offer/answer model [9], the 1145 offerer MAY present a set of these AVPF attributes to its peer. 1146 The answerer MUST remove all attributes it does not understand as 1147 well as those it does not support in general or does not wish to 1148 use in this particular media session. The answerer MUST NOT add 1149 feedback parameters to the media description and MUST NOT alter 1150 values of such parameters. The answer is binding for the media 1151 session and both offerer and answerer MUST only use feedback 1152 mechanisms negotiated in this way. Both offerer and answerer MAY 1153 independently decide to send RTCP FB messages of only a subset of 1154 the negotiated feedback mechanisms; but they SHOULD react properly 1155 to all types of the negotiated FB messages when received. 1157 RTP senders MUST be prepared to receive any kind of RTCP FB 1158 messages and MUST silently discard all those RTCP FB messages that 1159 they do not understand. 1161 The syntax of the "rtcp-fb" attribute is as follows (the feedback 1162 types and optional parameters are all case sensitive): 1164 (In the following ABNF, fmt, SP and CRLF are used as defined in 1165 [3].) 1167 rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF 1169 rtcp-fb-pt = "*" ; wildcard: applies to all formats 1170 / fmt ; as defined in SDP spec 1172 rtcp-fb-val = "ack" rtcp-fb-ack-param 1173 / "nack" rtcp-fb-nack-param 1174 / "trr-int" SP 1*DIGIT 1175 / rtcp-fb-id rtcp-fb-param 1177 rtcp-fb-id = 1*(alpha-numeric / "-" / "_") 1179 rtcp-fb-param = SP "app" [SP byte-string] 1180 / SP token [SP byte-string] 1181 / ; empty 1183 rtcp-fb-ack-param = SP "rpsi" 1184 / SP "app" [SP byte-string] 1185 / SP token [SP byte-string] 1186 / ; empty 1188 rtcp-fb-nack-param = SP "pli" 1189 / SP "sli" 1190 / SP "rpsi" 1191 / SP "app" [SP byte-string] 1192 / SP token [SP byte-string] 1193 / ; empty 1195 The literals of the above grammar have the following semantics: 1197 Feedback type "ack": 1199 This feedback type indicates that positive acknowledgements 1200 for feedback are supported. 1202 The feedback type "ack" MUST only be used if the media session 1203 is allowed to operate in ACK mode as defined in 3.6.1.2. 1205 Parameters MAY be provided to further distinguish different 1206 types of positive acknowledgement feedback. If no parameters 1207 are present, the Generic ACK as specified in section 6.2.2 is 1208 implied. 1210 The parameter "rpsi" indicates the use of Reference Picture 1211 Selection Indication feedback as defined in section 6.3.3. 1213 If the parameter "app" is specified, this indicates the use of 1214 application layer feedback. In this case, additional 1215 parameters following "app" MAY be used to further 1216 differentiate various types of application layer feedback. 1217 This document does not define any parameters specific to 1218 "app". 1220 Further parameters for "ack" MAY be defined in other 1221 documents. 1223 Feedback type "nack": 1225 This feedback type indicates that negative acknowledgements 1226 for feedback are supported. 1228 The feedback type "nack", without parameters, indicates use of 1229 the General NACK feedback format as defined in section 6.2.1. 1231 The following three parameters are defined in this document 1232 for use with "nack" in conjunction with the media type 1233 "video": 1235 o "pli" indicates the use of Picture Loss Indication feedback 1236 as defined in section 6.3.1. 1237 o "sli" indicates the use of Slice Loss Indication feedback 1238 as defined in section 6.3.2. 1240 o "rpsi" indicates the use of Reference Picture Selection 1241 Indication feedback as defined in section 6.3.3. 1243 "app" indicates the use of application layer feedback. 1244 Additional parameters after "app" MAY be provided to 1245 differentiate different types of application layer feedback. 1246 No parameters specific to "app" are defined in this document. 1248 Further parameters for "nack" MAY be defined in other 1249 documents. 1251 Other feedback types : 1253 Other documents MAY define additional types of feedback; to 1254 keep the grammar extensible for those cases, the rtcp-fb-id is 1255 introduced as a placeholder. A new feedback scheme name MUST 1256 to be unique (and thus MUST be registered with IANA). Along 1257 with a new name, its semantics, packet formats (if necessary), 1258 and rules for its operation MUST be specified. 1260 Regular RTCP minimum interval "trr-int": 1262 The attribute "trr-int" is used to specify the minimum 1263 interval T_rr_interval between two Regular (full compound) 1264 RTCP packets in milliseconds for this media session. If "trr- 1265 int" is not specified, a default value of 0 is assumed. 1267 Note that it is assumed that more specific information about 1268 application layer feedback (as defined in section 6.4) will be 1269 conveyed as feedback types and parameters defined elsewhere. 1270 Hence, no further provision for any types and parameters is made in 1271 this document. 1273 Further types of feedback as well as further parameters may be 1274 defined in other documents. 1276 It is up to the recipients whether or not they send feedback 1277 information and up to the sender(s) (how) to make use of feedback 1278 provided. 1280 4.3 RTCP Bandwidth Modifiers 1282 The standard RTCP bandwidth assignments as defined in [1] and [2] 1283 may be overridden by bandwidth modifiers that explicitly define the 1284 maximum RTCP bandwidth. For use with SDP, such modifiers are 1285 specified in [4]: "b=RS:" and "b=RR:" MAY be used to assign 1286 a different bandwidth (measured in bits per second) to RTP senders 1287 and receivers, respectively. The precedence rules of [4] apply to 1288 determine the actual bandwidth to be used by senders and receivers. 1290 Applications operating knowingly over highly asymmetric links (such 1291 as satellite links) SHOULD use this mechanism to reduce the 1292 feedback rate for high bandwidth streams to prevent deterministic 1293 congestion of the feedback path(s). 1295 4.4 Examples 1297 Example 1: The following session description indicates a session 1298 made up from audio and DTMF [18] for point-to-point communication 1299 in which the DTMF stream uses Generic ACKs. This session 1300 description could be contained in a SIP INVITE, 200 OK, or ACK 1301 message to indicate that its sender is capable of and willing to 1302 receive feedback for the DTMF stream it transmits. 1304 v=0 1305 o=alice 3203093520 3203093520 IN IP4 host.example.com 1306 s=Media with feedback 1307 t=0 0 1308 c=IN IP4 host.example.com 1309 m=audio 49170 RTP/AVPF 0 96 1310 a=rtpmap:0 PCMU/8000 1311 a=rtpmap:96 telephone-event/8000 1312 a=fmtp:96 0-16 1313 a=rtcp-fb:96 ack 1315 This allows sender and receiver to provide reliable transmission of 1316 DTMF events in an audio session. Assuming a 64kbit/s audio stream 1317 with one receiver, the receiver has 2.5% RTCP bandwidth available 1318 for the acknowledgment stream, i.e. 250 bytes per second or some 2 1319 RTCP feedback message. Hence, the receiver can individually 1320 confirm receipt of two DTMF digits per seconds. 1322 Example 2: The following session description indicates a multicast 1323 video-only session (using either H.261 or H.263+) with the video 1324 source accepting Generic NACKs for both codecs and Reference 1325 Picture Selection for H.263. Such a description may have been 1326 conveyed using the Session Announcement Protocol (SAP). 1328 v=0 1329 o=alice 3203093520 3203093520 IN IP4 host.example.com 1330 s=Multicast video with feedback 1331 t=3203130148 3203137348 1332 m=audio 49170 RTP/AVP 0 1333 c=IN IP4 224.2.1.183 1334 a=rtpmap:0 PCMU/8000 1335 m=video 51372 RTP/AVPF 98 99 1336 c=IN IP4 224.2.1.184 1337 a=rtpmap:98 H263-1998/90000 1338 a=rtpmap:99 H261/90000 1339 a=rtcp-fb:* nack 1340 a=rtcp-fb:98 nack rpsi 1342 The sender may use an incoming Generic NACK as a hint to send a new 1343 intra-frame as soon as possible (congestion control permitting). 1344 Receipt of an RPSI message allows the sender to avoid sending a 1345 large intra-frame; instead it may continue to send inter-frames, 1346 however, choosing the indicated frame as new encoding reference. 1348 Example 3: The following session description defines the same media 1349 session as example 2 but allows for mixed mode operation of AVP and 1350 AVPF RTP entities (see also next section). Note that both media 1351 descriptions use the same addresses; however, two m= lines are 1352 needed to convey information about both applicable RTP profiles. 1354 v=0 1355 o=alice 3203093520 3203093520 IN IP4 host.example.com 1356 s=Multicast video with feedback 1357 t=3203130148 3203137348 1358 m=audio 49170 RTP/AVP 0 1359 c=IN IP4 224.2.1.183 1360 a=rtpmap:0 PCMU/8000 1361 m=video 51372 RTP/AVP 98 99 1362 c=IN IP4 224.2.1.184 1363 a=rtpmap:98 H263-1998/90000 1364 a=rtpmap:99 H261/90000 1365 m=video 51372 RTP/AVPF 98 99 1366 c=IN IP4 224.2.1.184 1367 a=rtpmap:98 H263-1998/90000 1368 a=rtpmap:99 H261/90000 1369 a=rtcp-fb:* nack 1370 a=rtcp-fb:98 nack rpsi 1372 Note that these two m= lines SHOULD be grouped by some appropriate 1373 mechanism to indicate that both are alternatives actually conveying 1374 the same contents. A sample mechanism by which this can be 1375 achieved is defined in [7]. 1377 In this example, the RTCP feedback-enabled receivers will gain an 1378 occasional advantage to report events earlier back to the sender 1379 (which may benefit the entire group). On average, however, all RTP 1380 receivers will provide the same amount of feedback. The 1381 interworking between AVP and AVPF entities is discussed in depth in 1382 the next section. 1384 5 Interworking and Co-Existence of AVP and AVPF Entities 1386 The AVPF profile defined in this document is an extension of the 1387 AVP profile as defined in [2]. Both profiles follow the same basic 1388 rules (including the upper bandwidth limit for RTCP and the 1389 bandwidth assignments to senders and receivers). Therefore, 1390 senders and receivers of using either of the two profiles can be 1391 mixed in a single session (see e.g. example 3 in section 4.5). 1393 AVP and AVPF are defined in a way that, from a robustness point of 1394 view, the RTP entities do not need to be aware of entities of the 1395 respective other profile: they will not disturb each other's 1396 functioning. However, the quality of the media presented may 1397 suffer. 1399 The following considerations apply to senders and receivers when 1400 used in a combined session. 1402 o AVP entities (senders and receivers) 1404 AVP senders will receive RTCP feedback packets from AVPF 1405 receivers and ignore these packets. They will see occasional 1406 closer spacing of RTCP messages (e.g. violating the five second 1407 rule) by AVPF entities. As the overall bandwidth constraints 1408 are adhered to by both types of entities, they will still get 1409 their share of the RTCP bandwidth. However, while AVP entities 1410 are bound by the five second rule, depending on the group size 1411 and session bandwidth, AVPF entities may provide more frequent 1412 RTCP reports than AVP ones will. Also, the overall reporting 1413 may decrease slightly as AVPF entities may send bigger compound 1414 RTCP packets (due to the extra RTCP packets). 1416 If T_rr_interval is used as lower bound between Regular RTCP 1417 packets, T_rr_interval is sufficiently large (e.g. T_rr_interval 1418 > M*Td as per section 6.3.5 of [1]), and no Early RTCP packets 1419 are sent by AVPF entities, AVP entities may accidentally time 1420 out those AVPF group members and hence under-estimate the group 1421 size. Therefore, if AVP entities may be involved in a media 1422 session, T_rr_interval SHOULD NOT be larger than five seconds. 1424 o AVPF entities (senders and receivers) 1426 If the dynamically calculated T_rr is sufficiently small (e.g. 1427 less than one second), AVPF entities may accidentally time out 1428 AVP group members and hence under-estimate the group size. 1429 Therefore, if AVP entities may be involved in a media session, 1430 T_rr_interval SHOULD be used and SHOULD be set to five seconds. 1432 In conclusion, if AVP entities may be involved in a media 1433 session and T_rr_interval is to be used, T_rr_interval SHOULD be 1434 set to five seconds. 1436 o AVPF senders 1438 AVPF senders will receive feedback information only from AVPF 1439 receivers. If they rely on feedback to provide the target media 1440 quality, the quality achieved for AVP receivers may be sub- 1441 optimal. 1443 o AVPF receivers 1445 AVPF receivers SHOULD send Early RTCP feedback packets only if 1446 all sending entities in the media session support AVPF. AVPF 1447 receivers MAY send feedback information as part of regularly 1448 scheduled compound RTCP packets following the timing rules of 1449 [1] and [2] also in media sessions operating in mixed mode. 1450 However, the receiver providing feedback MUST NOT rely on the 1451 sender reacting to the feedback at all. 1453 6 Format of RTCP Feedback Messages 1455 This section defines the format of the low delay RTCP feedback 1456 messages. These messages are classified into three categories as 1457 follows: 1459 - Transport layer FB messages 1460 - Payload-specific FB messages 1461 - Application layer FB messages 1463 Transport layer FB messages are intended to transmit general 1464 purpose feedback information, i.e. information independent of the 1465 particular codec or the application in use. The information is 1466 expected to be generated and processed at the transport/RTP layer. 1467 Currently, only a general positive acknowledgement (ACK) and a 1468 negative acknowledgement (NACK) message are defined. 1470 Payload-specific FB messages transport information that is specific 1471 to a certain payload type and will be generated and acted upon at 1472 the codec "layer". This document defines a common header to be 1473 used in conjunction with all payload-specific FB messages. The 1474 definition of specific messages is left to either RTP payload 1475 format specifications or to additional feedback format documents. 1477 Application layer FB messages provide a means to transparently 1478 convey feedback from the receiver's to the sender's application. 1479 The information contained in such a message is not expected to be 1480 acted upon at the transport/RTP or the codec layer. The data to be 1481 exchanged between two application instances is usually defined in 1482 the application protocol specification and thus can be identified 1483 by the application so that there is no need for additional external 1484 information. Hence, this document defines only a common header to 1485 be used along with all application layer FB messages. From a 1486 protocol point of view, an application layer FB message is treated 1487 as a special case of a payload-specific FB message. 1489 NOTE: Proper processing of some FB messages at the media 1490 sender side may require the sender to know which payload type 1491 the FB message refers to. Most of the time, this knowledge 1492 can likely be derived from a media stream using only a single 1493 payload type. However, if several codecs are used 1494 simultaneously (e.g. with audio and DTMF) or when codec 1495 changes occur, the payload type information may need to be 1496 conveyed explicitly as part of the FB message. This applies 1497 to all payload-specific as well as application layer FB 1498 messages. It is up to the specification of a FB message to 1499 define how payload type information is transmitted. 1501 This document defines two transport layer and three (video) 1502 payload-specific FB messages as well as a single container for 1503 application layer FB messages. Additional transport layer and 1504 payload specific FB messages MAY be defined in other documents and 1505 MUST be registered through IANA (see section IANA considerations). 1507 The general syntax and semantics for the above RTCP FB message 1508 types are described in the following subsections. 1510 6.1 Common Packet Format for Feedback Messages 1512 All FB messages MUST use a common packet format that is depicted in 1513 figure 3: 1515 0 1 2 3 1516 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 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 |V=2|P| FMT | PT | length | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | SSRC of packet sender | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | SSRC of media source | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 : Feedback Control Information (FCI) : 1525 : : 1527 Figure 3: Common Packet Format for Feedback Messages 1528 The various fields V, P, SSRC and length are defined in the RTP 1529 specification [2], the respective meaning being summarized below: 1531 version (V): 2 bits 1532 This field identifies the RTP version. The current version is 1533 2. 1535 padding (P): 1 bit 1536 If set, the padding bit indicates that the packet contains 1537 additional padding octets at the end which are not part of the 1538 control information but are included in the length field. 1540 Feedback message type (FMT): 5 bits 1541 This field identifies the type of the FB message and is 1542 interpreted relative to the type (transport, payload- 1543 specific, or application layer feedback). The values for each 1544 of the three feedback types are defined in the respective 1545 sections below. 1547 Payload type (PT): 8 bits 1548 This is the RTCP packet type which identifies the packet as 1549 being an RTCP FB message. Two values are defined (TBA. by 1550 IANA): 1552 Name | Value | Brief Description 1553 ----------+-------+------------------------------------ 1554 RTPFB | 205 | Transport layer FB message 1555 PSFB | 206 | Payload-specific FB message 1557 Length: 16 bits 1558 The length of this packet in 32-bit words minus one, including 1559 the header and any padding. This is in line with the 1560 definition of the length field used in RTCP sender and receiver 1561 reports [3]. 1563 SSRC of packet sender: 32 bits 1564 The synchronization source identifier for the originator of 1565 this packet. 1567 SSRC of media source: 32 bits 1568 The synchronization source identifier of the media source that 1569 this piece of feedback information is related to. 1571 Feedback Control Information (FCI): variable length 1572 The following three sections define which additional 1573 information MAY be included in the FB message for each type of 1574 feedback: transport layer, payload-specific or application 1575 layer feedback. Note that further FCI contents MAY be specified 1576 in further documents. 1578 Each RTCP feedback packet MUST contain at least one FB message in 1579 the FCI field. Sections 6.2 and 6.3 define for each FCI type, 1580 whether or not multiple FB messages MAY be compressed into a single 1581 FCI field. If this is the case, they MUST be of the same type, 1582 i.e. same FMT. If multiple types of feedback messages, i.e. 1583 several FMTs, need to be conveyed, then several RTCP FB messages 1584 MUST be generated and SHOULD be concatenated in the same compound 1585 RTCP packet. 1587 6.2 Transport Layer Feedback Messages 1589 Transport Layer FB messages are identified by the value RTPFB as 1590 RTCP message type. 1592 Two general purpose transport layer FB messages are defined so far: 1593 General ACK and General NACK. They are identified by means of the 1594 FMT parameter as follows: 1596 0: unassigned 1597 1: Generic NACK 1598 2: Generic ACK 1599 3-30: unassigned 1600 31: reserved for future expansion of the identifier number 1601 space 1603 The following two subsections define the formats of the FCI field 1604 for these types of FB messages: 1606 6.2.1 Generic NACK 1608 The Generic NACK message is identified by PT=RTPFB and FMT=1. 1610 The FCI field MUST contain at least one and MAY contain more than 1611 one Generic NACK. 1613 The Generic NACK packet is used to indicate the loss of one or more 1614 RTP packets. The lost packet(s) are identified by the means of a 1615 packet identifier and a bit mask. 1617 Generic NACK feedback SHOULD NOT be used if the underlying 1618 transport protocol is capable of providing similar feedback 1619 information to the sender (as may be the case e.g. with DCCP). 1621 The Feedback control information (FCI) field has the following 1622 Syntax (figure 4): 1624 0 1 2 3 1625 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 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | PID | BLP | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 Figure 4: Syntax for the Generic NACK message 1632 Packet ID (PID): 16 bits 1633 The PID field is used to specify a lost packet. The PID field 1634 refers to the RTP sequence number of the lost packet. 1636 bitmask of following lost packets (BLP): 16 bits 1637 The BLP allows for reporting losses of any of the 16 RTP 1638 packets immediately following the RTP packet indicated by the 1639 PID. The BLP's definition is identical to that given in [6]. 1640 Denoting the BLP's least significant bit as bit 1, and its most 1641 significant bit as bit 16, then bit i of the bit mask is set to 1642 1 if the receiver has not received RTP packet number (PID+i) 1643 (modulo 2^16) and indicates this packet is lost; bit i is set 1644 to 0 otherwise. Note that the sender MUST NOT assume that a 1645 receiver has received a packet because its bit mask was set to 1646 0. For example, the least significant bit of the BLP would be 1647 set to 1 if the packet corresponding to the PID and the 1648 following packet have been lost. However, the sender cannot 1649 infer that packets PID+2 through PID+16 have been received 1650 simply because bits 2 through 15 of the BLP are 0; all the 1651 sender knows is that the receiver has not reported them as lost 1652 at this time. 1654 The length of the FB message MUST be set to 2+n, with n being the 1655 number of Generic NACKs contained in the FCI field. 1657 The Generic NACK message implicitly references the payload type 1658 through the sequence number(s). 1660 6.2.2 Generic ACK 1662 The Generic ACK message is identified by PT=RTPFB and FMT=2. 1664 The FCI field MUST contain at least one and MAY contain more than 1665 one Generic ACK. 1667 The Generic ACK packet is used to indicate that one or several RTP 1668 packets were received correctly. The received packet(s) are 1669 identified by the means of a packet identifier and a bit mask. 1670 ACKing of a range of consecutive packets is also possible. 1672 Generic ACK feedback SHOULD NOT be used if the underlying transport 1673 protocol is capable of providing similar feedback information to 1674 the sender (as may be the case e.g. with DCCP). 1676 The Feedback control information (FCI) field has the following 1677 syntax: 1679 0 1 2 3 1680 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 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | PID |R| BLP/#packets | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 Figure 5: Syntax for the Generic ACK message 1687 Packet ID (1st PID): 16 bits 1688 This PID field is used to specify a correctly received packet. 1689 The PID field refers to the RTP sequence number of the lost 1690 packet. 1692 Range of ACKs (R): 1 bit 1693 The R-bit indicates that a range of consecutive packets are 1694 received correctly. If R=1 then the PID field specifies the 1695 first packet of that range and the next field (BLP/#packets) 1696 will carry the number of packets being acknowledged. If R=0 1697 then PID specifies the first packet to be acknowledged and 1698 BLP/#packets provides a bit mask to selectively indicate 1699 individual packets that are acknowledged. 1701 Bit mask of lost packets (BLP)/#packets (PID): 15 bits 1702 The semantics of this field depends on the value of the R-bit. 1704 If R=1, this field is used to identify the number of additional 1705 packets of to be acknowledged: 1707 #packets = - 1709 That is, #packets MUST indicate the number of packet to be 1710 ACKed minus one. In particular, if only a single packet is to 1711 be ACKed and R=1 then #packets MUST be set to 0x0000. 1713 Example: If all packets between and including PIDx = 380 and 1714 PIDy = 422 have been received, the Generic ACK would contain 1715 PID = PIDx = 380 and #packets = PIDy - PID = 42. In case the 1716 PID wraps around, modulo arithmetic is used to calculate the 1717 number of packets. 1719 If R=0, this field carries a bit mask. The BLP allows for 1720 reporting reception of any of the 15 RTP packets immediately 1721 following the RTP packet indicated by the PID. The BLP's 1722 definition is identical to that given in [6] except that, here, 1723 BLP is only 15 bits wide. Denoting the BLP's least significant 1724 bit as bit 1, and its most significant bit as bit 15, then bit 1725 i of the bitmask is set to 1 if the receiver has received RTP 1726 packet number (PID+i) (modulo 2^16) and decides to ACK this 1727 packet; bit i is set to 0 otherwise. If only the packet 1728 indicated by PID is to be ACKed and R=0 then BLP MUST be set to 1729 0x0000. 1731 The length of the FB message MUST be set to 2+n, with n being the 1732 number of Generic ACKs contained in the FCI field. 1734 The Generic ACK message implicitly references the payload type 1735 through the sequence number(s). 1737 6.3 Payload Specific Feedback Messages 1739 Payload-Specific FB messages are identified by the value PT=PSFB as 1740 RTCP message type. 1742 Three payload-specific FB messages are defined so far plus an 1743 application layer FB message. They are identified by means of the 1744 FMT parameter as follows: 1746 0: unassigned 1747 1: Picture Loss Indication (PLI) 1748 2: Slice Lost Indication (SLI) 1749 3: Reference Picture Selection Indication (RPSI) 1750 4-14: unassigned 1751 15: Application layer FB message 1752 16-30: unassigned 1753 31: reserved for future expansion of the sequence number space 1755 The following subsections define the FCI formats for the payload- 1756 specific FB messages, section 6.4 defines FCI format for the 1757 application layer FB message. 1759 6.3.1 Picture Loss Indication (PLI) 1761 The PLI FB message is identified by PT=PSFB and FMT=1. 1763 There MUST be exactly one PLI contained in the FCI field. 1765 6.3.1.1 Semantics 1767 With the Picture Loss Indication message, a decoder informs the 1768 encoder about the loss of an undefined amount of coded video data 1769 belonging to one or more pictures. When used in conjunction with 1770 any video coding scheme that is based on inter-picture prediction, 1771 an encoder that receives a PLI becomes aware that the prediction 1772 chain may be broken. The sender MAY react to a PLI by transmitting 1773 an intra-picture to achieve resynchronization (making effectively 1774 similar to the FIR as defined in [6]); however, the sender MUST 1775 consider congestion control as outlined in section 7 which MAY 1776 restrict its ability to send an intra frame. 1778 Other RTP payload specifications such as RFC 2032 [6] already 1779 define a feedback mechanism for some for certain codecs. An 1780 application supporting both schemes MUST use the feedback mechanism 1781 defined in this specification when sending feedback. For backward 1782 compatibility reasons, such an application SHOULD also be capable 1783 to receive and react to the feedback scheme defined in the 1784 respective RTP payload format, if this is required by that payload 1785 format. 1787 6.3.1.2 Message Format 1789 PLI does not require parameters. Therefore, the length field MUST 1790 be 2, and there MUST NOT be any Feedback Control Information. 1792 The semantics of this FB message is independent of the payload 1793 type. 1795 6.3.1.3 Timing Rules 1797 The timing follows the rules outlined in section 3. In systems 1798 that employ both PLI and other types of feedback it may be 1799 advisable to follow the Regular RTCP RR timing rules for PLI, since 1800 PLI is not as delay critical as other FB types. 1802 6.3.1.4 Remarks 1804 PLI messages typically trigger the sending of full intra pictures. 1805 Intra pictures are several times larger then predicted (inter) 1806 pictures. Their size is independent of the time they are 1807 generated. In most environments, especially when employing 1808 bandwidth-limited links, the use of an intra picture implies an 1809 allowed delay that is a significant multitude of the typical frame 1810 duration. An example: If the sending frame rate is 10 fps, and an 1811 intra picture is assumed to be 10 times as big as an inter picture, 1812 then a full second of latency has to be accepted. In such an 1813 environment there is no need for a particular short delay in 1814 sending the FB message. Hence waiting for the next possible time 1815 slot allowed by RTCP timing rules as per [2] does not have a 1816 negative impact on the system performance. 1818 6.3.2 Slice Lost Indication (SLI) 1820 The SLI FB message is identified by PT=PSFB and FMT=2. 1822 The FCI field MUST contain at least one and MAY contain more than 1823 one SLI. 1825 6.3.2.1 Semantics 1827 With the Slice Lost Indication a decoder can inform an encoder that 1828 it has detected the loss or corruption of one or several 1829 consecutive macroblock(s) in scan order (see below). This FB 1830 message MUST NOT be used for video codecs with non-uniform, 1831 dynamically changeable macroblock sizes such as H.263 with enabled 1832 Annex Q. In such a case, an encoder cannot always identify the 1833 corrupted spatial region. 1835 6.3.2.2 Format 1837 The Slice Lost Indication uses one additional PCI field the 1838 content of which is depicted in figure 6. The length of the FB 1839 message MUST be set to 2+n, with n being the number of SLIs 1840 contained in the FCI field. 1842 0 1 2 3 1843 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 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 | First | Number | PictureID | 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 Figure 6: Syntax of the Slice Lost Indication (SLI) 1850 First: 13 bits 1851 The macroblock (MB) address of the first lost macroblock. The 1852 MB numbering is done such that the macroblock in the upper left 1853 corner of the picture is considered macroblock number 1 and the 1854 number for each macroblock increases from left to right and 1855 then from top to bottom in raster-scan order (such that if 1856 there is a total of N macroblocks in a picture, the bottom 1857 right macroblock is considered macroblock number N). 1859 Number: 13 bits 1860 The number of lost macroblocks, in scan order as discussed 1861 above. 1863 PictureID: 6 bits 1864 The six least significant bits of the a codec-specific 1865 identifier that is used to reference the picture in which the 1866 loss of the macroblock (s) has occurred. For many video 1867 codecs, the PictureID is identical to the Temporal Reference. 1869 The applicability of this FB message is limited to a small set of 1870 video codecs and therefore, no explicit payload type information is 1871 provided. 1873 6.3.2.3 Timing Rules 1875 The efficiency of algorithms using the Slice Lost Indication is 1876 reduced greatly when the Indication is not transmitted in a timely 1877 fashion. Motion compensation propagates corrupted pixels that are 1878 not reported as being corrupted. Therefore, the use of the 1879 algorithm discussed in section 3 is highly recommended. 1881 6.3.2.4 Remarks 1883 The term Slice is defined and used here in the sense of MPEG-1 -- a 1884 consecutive number of macroblocks in scan order. More recent video 1885 coding standards sometimes have a different understanding of the 1886 term Slice. In H.263 (1998), for example, a concept known as 1887 "rectangular Slice" exist. The loss of one Rectangular Slice may 1888 lead to the necessity of sending more than one SLI in order to 1889 precisely identify the region of lost/damaged MBs. 1891 The first field of the FCI defines the first macroblock of a 1892 picture as 1 and not, as one could suspect, as 0. This was done to 1893 align this specification with the comparable mechanism available in 1894 H.245. The maximum number of macroblocks in a picture (2**13 or 1895 8192) corresponds to the maximum picture sizes of most of the ITU-T 1896 and ISO/IEC video codecs. If future video codecs offer larger 1897 picture sizes and/or smaller macroblock sizes, then an additional 1898 FB message has to be defined. The six least significant bits of 1899 the Temporal Reference field are deemed to be sufficient to 1900 indicate the picture in which the loss occurred. 1902 The reaction to a SLI is not part of this specification. One 1903 typical way of reacting to a SLI is to use intra refresh for the 1904 affected spatial region. 1906 Algorithms were reported that keep track of the regions affected by 1907 motion compensation, in order to allow for a transmission of Intra 1908 macroblocks to all those areas, regardless of the timing of the FB 1909 (see H.263 (2000) Appendix I [17] and [15]). While, when those 1910 algorithms are used, the timing of the FB is less critical then 1911 without, it has to be observed that those algorithms correct large 1912 parts of the picture and, therefore, have to transmit much higher 1913 data volume in case of delayed FBs. 1915 6.3.3 Reference Picture Selection Indication (RPSI) 1917 The RPSI FB message is identified by PT=PSFB and FMT=3. 1919 There MUST be exactly one RPSI contained in the FCI field. 1921 6.3.3.1 Semantics 1923 Modern video coding standards such as MPEG-4 visual version 2 [16] 1924 or H.263 version 2 [17] allow to use older reference pictures than 1925 the most recent one for predictive coding. Typically, a first-in- 1926 first-out queue of reference pictures is maintained. If an encoder 1927 has learned about a loss of encoder-decoder synchronicity, a known- 1928 as-correct reference picture can be used. As this reference picture 1929 is temporally further away then usual, the resulting predictively 1930 coded picture will use more bits. 1932 Both MPEG-4 and H.263 define a binary format for the "payload" of 1933 an RPSI message that includes information such as the temporal ID 1934 of the damaged picture and the size of the damaged region. This 1935 bit string is typically small -- a couple of dozen bits --, of 1936 variable length, and self-contained, i.e. contains all information 1937 that is necessary to perform reference picture selection. 1939 Note that both MPEG-4 and H.263 allow the use of RPSI with positive 1940 feedback information as well. That is, pictures (or Slices) are 1941 reported that were decoded without error. Note that any form of 1942 positive feedback MUST NOT be used when in a multiparty session 1943 (reporting positive feedback about individual reference pictures at 1944 RTCP intervals is not expected to be of much use anyway). 1946 6.3.3.2 Format 1948 The FCI for the RPSI message follows the format depicted in figure 1949 7: 1951 0 1 2 3 1952 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 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 | PB |0| Payload Type| Native RPSI bit string | 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 | defined per codec ... | Padding (0)| 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 Figure 7: Syntax of the Reference Picture Selection Indication 1960 (RPSI) 1962 PB: 8 bits 1963 The number of unused bits required to pad the length of the 1964 RPSI message to a multiple of 32 bits. 1966 0: 1 bit 1967 MUST be set to zero upon transmission and ignored upon 1968 reception. 1970 Payload Type: 8 bits 1971 Indicates the RTP payload type in the context of which the 1972 native RPSI bit string MUST be interpreted. 1974 Native RPSI bit string: variable length 1975 The RPSI information as natively defined by the video codec. 1977 Padding: #PB bits 1978 A number of bits set to zero to fill up the contents of the 1979 RPSI message to the next 32 bit boundary. The number of 1980 padding bits MUST be indicated by the PB field. 1982 6.3.3.3 Timing Rules 1984 RPS is even more critical to delay then algorithms using SLI. This 1985 is due to the fact that the older the RPS message is, the more bits 1986 the encoder has to spend to re-establish encoder-decoder 1987 synchronicity. See [15] for some information about the overhead of 1988 RPS for certain bit rate/frame rate/loss rate scenarios. 1990 Therefore, RPS messages should typically be sent as soon as 1991 possible, employing the algorithm of section 3. 1993 6.4 Application Layer Feedback Messages 1995 Application Layer FB messages are a special case of payload- 1996 specific messages and identified by PT=PSFB and FMT=15. 1997 There MUST be exactly one Application Layer FB message contained in 1998 the FCI field, unless the Application Layer FB message structure 1999 itself allows for stacking (e.g. by means of a fixed size or 2000 explicit length indicator). 2002 These messages are used to transport application defined data 2003 directly from the receiver's to the sender's application. The data 2004 that is transported is not identified by the FB message. 2005 Therefore, the application MUST be able to identify the messages 2006 payload. 2008 Usually, applications define their own set of messages, e.g. 2009 NEWPRED messages in MPEG-4 [16] or FB messages in H.263/Annex N, U 2010 [17]. These messages do not need any additional information from 2011 the RTCP message. Thus the application message is simply placed 2012 into the FCI field as follows and the length field is set 2013 accordingly. 2015 Application Message (FCI): variable length 2016 This field contains the original application message that 2017 should be transported from the receiver to the source. The 2018 format is application dependent. The length of this field is 2019 variable. If the application data is not 32-bit-aligned, 2020 padding bits and bytes must be added. Identification of 2021 padding is up to the application layer and not defined in this 2022 specification. 2024 The application layer FB message specification MUST define whether 2025 or not the message needs to be interpreted specifically in the 2026 context of a certain codec (identified by the RTP payload type). 2027 If a reference to the payload type is required for proper 2028 processing, the application layer FB message specification MUST 2029 define a way to communicate the payload type information as part of 2030 the application layer FB message itself. 2032 7 Early Feedback and Congestion Control 2034 In the previous sections, the FB messages were defined as well as 2035 the timing rules according to which to send these messages. The 2036 way to react to the feedback received depends on the application 2037 using the feedback mechanisms and hence is beyond the scope of this 2038 document. 2040 However, across all applications, there is a common requirement for 2041 (TCP-friendly) congestion control on the media stream as defined in 2042 [1] and [2] when operating in a best-effort network environment. 2044 Low delay feedback supports the use of congestion control 2045 algorithms in two ways: 2047 o The potentially more frequent RTCP packets allow the sender to 2048 monitor the network state more closely than with Regular RTCP 2049 packets and therefore enable a more timely reaction to upcoming 2050 congestion. 2052 o The FB messages themselves may convey additional information as 2053 input to congestion control algorithms and thus improve reaction 2054 over conventional RTCP. (For example, ACK-based feedback may 2055 even allow to construct closed loop algorithms and NACK-based 2056 systems may provide further information on the packet loss 2057 distribution.) 2059 It should be noted, however, that RTCP feedback may operate at much 2060 slower timescales than other transport layer feedback mechanisms 2061 (that usually operate in the order of RTT). Therefore, any rate 2062 adaptation may occur slower than TCP. 2064 A congestion control algorithm that shares the available bandwidth 2065 reasonably fairly with competing TCP connections, e.g. TFRC [8], 2066 MUST be used to determine the data rate for the media stream within 2067 the bounds of the RTP sender's and the media session's capabilities 2068 if the RTP/AVPF session is transmitted in a best effort 2069 environment. 2071 That is, RTCP FB messages or RTCP SR/RR packets that indicate 2072 recent packet loss SHOULD cause the sender to adjust the 2073 transmission data rate to the order of the throughput TCP would 2074 achieve under similar conditions (e.g. using TFRC). RTCP FB 2075 messages or RTCP SR/RR packets that indicate no recent packet loss 2076 MAY cause the sender to increase the transmission data rate to 2077 roughly the throughput TCP would achieve under similar conditions 2078 (e.g. using TFRC). Such messages MUST NOT cause a larger increase 2079 in the sender's transmission rate than a comparable TCP flow would 2080 achieve. The procedural details MUST be specified by the document 2081 defining the sender behavior for a certain codec and/or 2082 application. 2084 8 Security Considerations 2086 RTP packets transporting information with the proposed payload 2087 format are subject to the security considerations discussed in the 2088 RTP specification [1] and in the RTP/AVP profile specification [2]. 2089 This profile does not specify any additional security services. 2091 This profile modifies the timing behavior of RTCP and eliminates 2092 the minimum RTCP interval of five seconds and allows for earlier 2093 feedback to be provided by receivers. Group members of the 2094 associated RTP session (possibly pretending to represent a large 2095 number of entities) may disturb the operation of RTCP by sending 2096 large numbers of RTCP packets thereby reducing the RTCP bandwidth 2097 available for Regular RTCP reporting as well as for Early FB 2098 messages. (Note that an entity need not be member of a multicast 2099 group to cause these effects.) Similarly, malicious members may 2100 send very large RTCP messages, thereby increasing the avg_rtcp_size 2101 variable and reducing the effectively available RTCP bandwidth. 2103 Feedback information may be suppressed if unknown RTCP feedback 2104 packets are received. This introduces the risk of a malicious 2105 group member reducing Early feedback by simply transmitting 2106 payload-specific RTCP feedback packets with random contents that 2107 are neither recognized by any receiver (so they will suppress 2108 feedback) nor by the sender (so no repair actions will be taken). 2110 A malicious group member can also report arbitrary high loss rates 2111 in the feedback information to make the sender throttle the data 2112 transmission and increase the amount of redundancy information or 2113 take other action to deal with the pretended packet loss (e.g. send 2114 fewer frames or decrease audio/video quality). This may result in 2115 a degradation of the quality of the reproduced media stream. 2117 Finally, a malicious group member can act as a large number of 2118 group members and thereby obtain an artificially large share of the 2119 Early feedback bandwidth and reduce the reactivity of the other 2120 group members -- possibly even causing them to no longer operate in 2121 Immediate or Early feedback mode and thus undermining the whole 2122 purpose of this profile. 2124 Senders as well as receivers SHOULD behave conservatively when 2125 observing strange reporting behavior. For excessive failure 2126 reporting from one or a few receivers, the sender MAY decide to no 2127 longer consider this feedback when adapting its transmission 2128 behavior for the media stream. In any case, senders and receivers 2129 SHOULD still adhere to the maximum RTCP bandwidth but make sure 2130 that they are capable of transmitting at least regularly scheduled 2131 RTCP packets. Senders SHOULD carefully consider how to adjust 2132 their transmission bandwidth when encountering strange reporting 2133 behavior; they MUST NOT increase their transmission bandwidth even 2134 if ignoring suspicious feedback. 2136 Attacks using false RTCP packets (Regular as well as Early ones) 2137 can be avoided by authenticating all RTCP messages. This can be 2138 achieved by using the AVPF profile together with the Secure RTP 2139 profile as defined in [22]; as a prerequisite, an appropriate 2140 combination of those two profiles (an "SAVPF") is being specified 2141 [21]. 2143 9 IANA Considerations 2145 The following contact information shall be used for all 2146 registrations included here: 2148 Contact: Joerg Ott 2149 mailto:jo@acm.org 2150 tel:+49-421-201-7028 2152 The feedback profile as an extension to the profile for audio- 2153 visual conferences with minimal control needs to be registered for 2154 the Session Description Protocol (specifically the type "proto"): 2155 "RTP/AVPF". 2157 SDP Protocol ("proto"): 2159 Name: RTP/AVPF 2160 Long form: Extended RTP Profile with RTCP-based Feedback 2161 Type of name: proto 2162 Type of attribute: Media level only 2163 Purpose: RFC XXXX 2164 Reference: RFC XXXX 2166 SDP Attribute ("att-field"): 2168 Attribute name: rtcp-fb 2169 Long form: RTCP Feedback parameter 2170 Type of name: att-field 2171 Type of attribute: Media level only 2172 Subject to charset: No 2173 Purpose: RFC XXXX 2174 Reference: RFC XXXX 2175 Values: See this document and registrations below 2177 A new registry needs to be set up for the "rtcp-fb" attribute, with 2178 the following registrations created initially: "ack", "nack", "trr- 2179 int", and "app" as defined in this document. 2181 Initial value registration for the attribute "rtcp-fb" 2183 Value name: ack 2184 Long name: Positive acknowledgement 2185 Reference: RFC XXXX. 2187 Value name: nack 2188 Long name: Negative Acknowledgement 2189 Reference: RFC XXXX. 2191 Value name: trr-int 2192 Long name: Minimal receiver report interval 2193 Reference: RFC XXXX. 2195 Value name: app 2196 Long name: Application-defined paramater 2197 Reference: RFC XXXX. 2199 Further entries may be registered on a first-come first-serve 2200 basis. Each new registration needs to indicate the parameter name 2201 and the syntax of possible additional arguments. For each new 2202 registration, it is mandatory that a permanent, stable, and 2203 publicly accessible document exists that specifies the semantics of 2204 the registered parameter, the syntax and semantics of its 2205 parameters as well as corresponding feedback packet formats (if 2206 needed). The general registration procedures of [3] apply. 2208 For use with both "ack" and "nack", a joint sub-registry needs to 2209 be set up that initially registers the following values: 2211 Initial value registration for the attribute values "ack" and 2212 "nack": 2214 Value name: sli 2215 Long name: Slice Loss Indication 2216 Usable with: nack 2217 Reference: RFC XXXX. 2219 Value name: pli 2220 Long name: Picture Loss Indication 2221 Usable with: nack 2222 Reference: RFC XXXX. 2224 Value name: rpsi 2225 Long name: Reference Picture Selection Indication 2226 Usable with: ack, nack 2227 Reference: RFC XXXX. 2229 Value name: app 2230 Long name: Application layer feedback 2231 Usable with: ack, nack 2232 Reference: RFC XXXX. 2234 Further entries may be registered on a first-come first-serve 2235 basis. Each registrations needs to indicate the parameter name, 2236 the syntax of possible additional arguments, and whether the 2237 parameter is applicable to "ack" or "nack" feedback or both or some 2238 different "rtcp-fb" attribute parameter. For each new 2239 registration, it is mandatory that a permanent, stable, and 2240 publicly accessible document exists that specifies the semantics of 2241 the registered parameter, the syntax and semantics of its 2242 parameters as well as corresponding feedback packet formats (if 2243 needed). The general registration procedures of [3] apply. 2245 Two RTCP Control Packet Types: for the class of transport layer FB 2246 messages ("RTPFB") and for the class of payload-specific FB 2247 messages ("PSFB"). Section 6 suggests RTPFB=205 and PSFB=206 to be 2248 added to the RTCP registry. 2250 RTP RTCP Control Packet types (PT): 2252 Name: RTPFB 2253 Long name: Generic RTP Feedback 2254 Value: 205 2255 Reference: RFC XXXX. 2257 Name: PSFB 2258 Long name: Payload-specific 2259 Value: 206 2260 Reference: RFC XXXX. 2262 As AVPF defines additional RTCP payload types, the corresponding 2263 "reserved" RTP payload type space (72--76, as defined in [2]), 2264 needs to be expanded accordingly. 2266 A new sub-registry needs to be set up for the FMT values for both 2267 the RTPFB payload type and the PSFB payload type, with the 2268 following registrations created initially: 2270 Within the RTPFB range, the following three format (FMT) values are 2271 initially registered: 2273 Name: Generic NACK 2274 Long name: Generic negative acknowledgement 2275 Value: 1 2276 Reference: RFC XXXX. 2278 Name: Generic ACK 2279 Long name: Generic positive acknowledgement 2280 Value: 2 2281 Reference: RFC XXXX. 2283 Name: Extension 2284 Long name: Reserved for future extensions 2285 Value: 31 2286 Reference: RFC XXXX. 2288 Within the PSFB range, the following five format (FMT) values are 2289 initially registered: 2291 Name: PLI 2292 Long name: Picture Loss Indication 2293 Value: 1 2294 Reference: RFC XXXX. 2296 Name: SLI 2297 Long name: Slice Loss Indication 2298 Value: 2 2299 Reference: RFC XXXX. 2301 Name: RPSI 2302 Long name: Reference Picture Selection Indication 2303 Value: 3 2304 Reference: RFC XXXX. 2306 Name: AFB 2307 Long name: Application Layer Feedback 2308 Value: 15 2309 Reference: RFC XXXX. 2311 Name: Extension 2312 Long name: Reserved for future extensions. 2313 Value: 31 2314 Reference: RFC XXXX. 2316 Further entries may be registered following the "Specification 2317 Required" rules as defined in RFC 2434 [10]. Each registration 2318 needs to indicate the FMT value, if there is a specific FB message 2319 to go into the FCI field, and whether or not multiple FB messages 2320 may be stacked in a single FCI field. For each new registration, 2321 it is mandatory that a permanent, stable, and publicly accessible 2322 document exists that specifies the semantics of the registered 2323 parameter as well as the syntax and semantics of the associated FB 2324 message (if any). The general registration procedures of [3] 2325 apply. 2327 NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by 2328 the RFC number assigned to this document. 2330 10 Acknowledgements 2332 This document is a product of the Audio-Visual Transport (AVT) 2333 Working Group of the IETF. The authors would like to thank Steve 2334 Casner and Colin Perkins for their comments and suggestions as well 2335 as for their responsiveness to numerous questions. The authors 2336 would also like to particularly thank Magnus Westerlund for his 2337 review and his valuable suggestions, Shigeru Fukunaga for the 2338 contributions on for FB message formats and semantics. 2340 We would also like to thank Andreas Buesching and people at 2341 Panasonic for their simulations and the first independent 2342 implementations of the feedback profile. 2344 11 Authors' Addresses 2346 Joerg Ott {sip,mailto}:jo@tzi.org 2347 Uni Bremen TZI 2348 MZH 5180 2349 Bibliothekstr. 1 2350 D-28359 Bremen 2351 Germany 2353 Stephan Wenger stewe@cs.tu-berlin.de 2354 TU Berlin 2355 Sekr. FR 6-3 2356 Franklinstr. 28-29 2357 D-10587 Berlin 2358 Germany 2360 Noriyuki Sato 2361 Oki Electric Industry Co., Ltd. 2362 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan 2363 Tel. +81 6 6949 5101 2364 Fax. +81 6 6949 5108 2365 Mail sato652@oki.com 2366 Carsten Burmeister 2367 Panasonic European Laboratories GmbH 2368 Mail burmeister@panasonic.de 2370 Jose Rey 2371 Panasonic European Laboratories GmbH 2372 Monzastr. 4c, 63225 Langen, Germany 2373 Tel. +49-(0)6103-766-134 2374 Fax. +49-(0)6103-766-166 2375 Mail rey@panasonic.de 2377 12 Bibliography 2379 12.1 Normative references 2381 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP 2382 - A Transport Protocol for Real-time Applications," RFC 3550, 2383 July 2003. 2385 [2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video 2386 Conferences with Minimal Control," RFC 3551, July 2003. 2388 [3] M. Handley, V. Jacobson, and Colin Perkins, "SDP: Session 2389 Description Protocol", Internet Draft draft-ietf-mmusic-sdp- 2390 new-15.txt, October 2003. 2392 [4] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", RFC 2393 3556, July 2003. 2395 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 2396 Levels," RFC 2119, March 1997. 2398 [6] T. Turletti and C. Huitema, "RTP Payload Format for H.261 2399 Video Streams, RFC 2032, October 1996. 2401 [7] G. Camarillo, J. Holler, G. Eriksson, H. Schulzrinne, 2402 "Grouping of media lines in SDP," RFC 3388, December 2002. 2404 [8] M. Handley, J. Padhye, S. Floyd, J. Widmer, "TCP friendly Rate 2405 Control (TFRC): Protocol Specification," RFC 3448, January 2406 2003. 2408 [9] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 2409 SDP," RFC 3264, June 2002. 2411 [10] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 2412 Considerations Section in RFCs," RFC 2434, October 1998. 2414 12.2 Informative References 2416 [11] C. Perkins and O. Hodson, "Options for Repair of 2417 Streaming Media," RFC 2354, June 1998. 2419 [12] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for 2420 Generic Forward Error Correction,", RFC 2733, December 1999. 2422 [13] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, 2423 J.C. Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload 2424 for Redundant Audio Data," RFC 2198, September 1997. 2426 [14] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. 2427 Newell, J. Ott, G. Sullivan, S. Wenger, and C. Zhu, "RTP 2428 Payload Format for the 1998 Version of ITU-T Rec. H.263 Video 2429 (H.263+)," RFC 2429, October 1998. 2431 [15] B. Girod, N. Faerber, "Feedback-based error control for mobile 2432 video transmission," Proceedings IEEE, Vol. 87, No. 10, pp. 2433 1707 - 1723, October, 1999. 2435 [16] ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology - 2436 Coding of audio-visual objects - Part2: Visual", 2001. 2438 [17] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate 2439 Communication," November 2000. 2441 [18] H. Schulzrinne and S. Petrack, "RTP Payload for DTMF Digits, 2442 Telephony Tones and Telephony Signals," RFC 2833, May 2000. 2444 [19] E. Kohler, M. Handley, S. Floyd, and J. Padhye, "Datagram 2445 Congestion Control Protocol (DCCP)," Internet Draft draft- 2446 ietf-dccp-spec-05.txt, Work in Progress, October 2003. 2448 [20] M. Handley, S. Floyd, J. Padhye, and J. Widmer, "TCP Friendly 2449 Rate Control (TFRC): Protocol Specification," RFC 3448, 2450 January 2003. 2452 [21] J. Ott and E. Carrara, "Extended Secure RTP Profile for RTCP- 2453 based Feedback (RTP/SAVPF)," Internet Draft draft-ietf-avt- 2454 profile-savpf-00.txt, Work in Progress, October 2003. 2456 [22] M. Baugher, R. Blom, E. Carrarra, D. McGrew, M. Naslund, K. 2457 Norrman, D. Oran, "The Secure Real-Time Transport Protocol," 2458 Internet Draft, draft-ietf-avt-srtp-09.txt, Work in Progress, 2459 June 2003. 2461 13 IPR Notice 2463 The IETF takes no position regarding the validity or scope of any 2464 intellectual property or other rights that might be claimed to 2465 pertain to the implementation or use of the technology described in 2466 this document or the extent to which any license under such rights 2467 might or might not be available; neither does it represent that it 2468 has made any effort to identify any such rights. Information on 2469 the IETF's procedures with respect to rights in standards-track and 2470 standards-related documentation can be found in BCP-11. Copies of 2471 claims of rights made available for publication and any assurances 2472 of licenses to be made available, or the result of an attempt made 2473 to obtain a general license or permission for the use of such 2474 proprietary rights by implementors or users of this specification 2475 can be obtained from the IETF Secretariat. 2477 The IETF invites any interested party to bring to its attention any 2478 copyrights, patents or patent applications, or other proprietary 2479 rights which may cover technology that may be required to practice 2480 this standard. Please address the information to the IETF 2481 Executive Director. 2483 14 Full Copyright Statement 2485 Copyright (C) The Internet Society (2003). All Rights Reserved. 2486 This document and translations of it may be copied and furnished to 2487 others, and derivative works that comment on or otherwise explain 2488 it or assist in its implementation may be prepared, copied, 2489 published and distributed, in whole or in part, without restriction 2490 of any kind, provided that the above copyright notice and this 2491 paragraph are included on all such copies and derivative works. 2493 However, this document itself may not be modified in any way, such 2494 as by removing the copyright notice or references to the Internet 2495 Society or other Internet organizations, except as needed for the 2496 purpose of developing Internet standards in which case the 2497 procedures for copyrights defined in the Internet Standards process 2498 must be followed, or as required to translate it into languages 2499 other than English. 2501 The limited permissions granted above are perpetual and will not be 2502 revoked by the Internet Society or its successors or assigns. 2504 This document and the information contained herein is provided on 2505 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 2506 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 2507 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2508 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2509 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."