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