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