idnits 2.17.1 draft-ietf-avt-rtcpssm-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance 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 IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (9 November 2009) is 5282 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) -- Looks like a reference, but probably isn't: 'SSRC' on line 1025 -- Looks like a reference, but probably isn't: 'CNAME' on line 1025 -- Looks like a reference, but probably isn't: 'NDB' on line 2876 ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4566 (ref. '5') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. '17') (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. '23') (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '25') (Obsoleted by RFC 7826) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Ott 3 draft-ietf-avt-rtcpssm-19 Helsinki University of Technology 4 AVT Working Group J. Chesterfield 5 Intended Status: Proposed Standard University of Cambridge 6 E. Schooler 7 Intel 8 Expires: April 2010 9 November 2009 10 RTCP Extensions for Single-Source Multicast Sessions 11 with Unicast Feedback 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 9, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your 45 rights and restrictions with respect to this document. 47 RTCP with Unicast Feedback 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Abstract 63 This document specifies an extension to the Real-time Transport 64 Control Protocol (RTCP) to use unicast feedback to a multicast 65 sender. The proposed extension is useful for single-source multicast 66 sessions such as Source-Specific Multicast (SSM) communication where 67 the traditional model of many-to-many group communication is either 68 not available or not desired. In addition, it can be applied to any 69 group that might benefit from a sender-controlled summarized 70 reporting mechanism. 72 Table of Contents 74 1. Conventions and Acronyms .................................... 2 75 2. Introduction................................................. 3 76 3. Definitions.................................................. 4 77 4. Basic Operation.............................................. 6 78 5. Packet types................................................. 9 79 6. Simple Feedback Model....................................... 10 80 7. Distribution Source Feedback Summary Model.................. 12 81 8. Mixer/Translator issues..................................... 32 82 9. Transmission interval calculation........................... 33 83 10. SDP Extensions............................................. 35 84 11. Security Considerations ................................... 38 85 12. Backwards Compatibility ................................... 46 86 13. IANA Considerations........................................ 46 87 14. Bibliography............................................... 48 88 15. Appendix A: Examples for Sender Side Configurations........ 51 89 16. Appendix B: Distribution Report processing at the receiver. 55 90 18. ACKNOWLEDGEMENTS........................................... 59 91 19. AUTHORS' ADDRESSES......................................... 59 92 20. IPR Notice................................................. 59 93 21. FULL COPYRIGHT STATEMENT................................... 59 95 1. Conventions and Acronyms 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [13]. 101 RTCP with Unicast Feedback 103 The following acronyms are used throughout this document: 105 ASM Any Source Multicast; 106 SSM Source-Specific Multicast. 108 2. Introduction 110 The Real-time Transport Protocol (RTP) [1] provides a real-time 111 transport mechanism suitable for unicast or multicast communication 112 between multimedia applications. Typical uses of RTP are for real- 113 time or near real-time group communication of audio and video data 114 streams. An important component of the RTP protocol is the control 115 channel, defined as the RTP Control Protocol (RTCP). RTCP involves 116 the periodic transmission of control packets between group members, 117 enabling group size estimation and the distribution and calculation 118 of session-specific information such as packet loss and round trip 119 time to other hosts. An additional advantage of providing a control 120 channel for a session is that a third-party session monitor can 121 listen to the traffic to establish network conditions and to 122 diagnose faults based on receiver locations. 124 RTP was designed to operate in either a unicast or multicast mode. 125 In multicast mode, it assumes an Any Source Multicast (ASM) group 126 model, where both one-to-many and many-to-many communication are 127 supported via a common group address in the range 224.0.0.0 through 128 239.255.255.255. To enable Internet-wide multicast communication, 129 intra-domain routing protocols (those that operate only within a 130 single administrative domain, e.g., DVMRP [16], PIM [17][18]) are 131 used in combination with inter-domain routing protocols (those that 132 operate across administrative domain borders, e.g., MBGP [19], MSDP 133 [20]). Such routing protocols enable a host to join a single 134 multicast group address and to send to or to receive data from all 135 members in the group with no prior knowledge of the membership. 136 However, there is a great deal of complexity involved at the routing 137 level to support such a multicast service in the network. 139 Many-to-many communication is not always available, nor desired by 140 all group applications. For example, with Source-Specific Multicast 141 (SSM) [8][9] and satellite communication, the multicast distribution 142 channel only supports source-to-receiver traffic. In other cases, 143 such as large ASM groups with a single active data source and many 144 passive receivers, it is sub-optimal to create a full routing-level 145 mesh of multicast sources just for the distribution of RTCP control 146 packets. Thus, an alternative solution is preferable. 148 Although a one-to-many multicast topology may simplify routing and 149 may be a closer approximation to the requirements of certain RTP 150 applications, unidirectional communication makes it impossible for 151 receivers in the group to share RTCP feedback information with other 152 group members. In this document, we specify a solution to that 153 problem. We introduce unicast feedback as a new method to 154 distribute RTCP control information amongst all session members. 155 This method is designed to operate under any group communication 156 model, ASM or SSM. The RTP data stream protocol itself is unaltered. 158 RTCP with Unicast Feedback 160 Scenarios under which the unicast feedback method can provide 161 benefit include but are not limited to: 163 a) SSM groups with a single sender. 165 The proposed extensions allow SSM groups that do not have many- 166 to-many communication capability to receive RTP data streams and 167 to continue to participate in the RTP control protocol, RTCP, by 168 using multicast in the source-to-receiver direction and unicast 169 to send receiver feedback to the source on the standard RTCP 170 port. 172 b) One-to-many broadcast networks. 174 Unicast feedback may also be beneficial to one-to-many broadcast 175 networks, such as a satellite network with a terrestrial low- 176 bandwidth return channel or a broadband cable link. Unlike the 177 SSM network, these networks may have the ability for a receiver 178 to multicast return data to the group. However, a unicast 179 feedback mechanism may be preferable for routing simplicity. 181 c) ASM with a single sender. 183 A unicast feedback approach can be used by an ASM application 184 with a single sender to reduce the load on the multicast routing 185 infrastructure that does not scale as efficiently as unicast 186 routing does. Because this is no more efficient than a standard 187 multicast group RTP communication scenario, it is not expected to 188 replace the traditional mechanism. 190 The modifications proposed in this document are intended to 191 supplement the existing RTCP feedback mechanisms described in [1], 192 Section 6. 194 3. Definitions 196 Distribution Source: 197 In an SSM context, only one entity distributes RTP data and 198 redistributes RTCP information to all receivers. This entity 199 is called the Distribution Source. It is also responsible for 200 forwarding RTCP feedback to the Media Senders and thus creates 201 a virtual multicast environment in which RTP and RTCP can be 202 applied. 204 Note that heterogeneous networks consisting of ASM multiple- 205 sender groups, unicast-only clients and/or SSM single-sender 206 receiver groups MAY be connected via translators or mixers to 207 create a single-source group (see Section 8 for details). 209 Media Sender: 210 A Media Sender is an entity that originates RTP packets for a 211 particular media session. In RFC 3550, a Media Sender is simply 212 RTCP with Unicast Feedback 214 called a source. However, as the RTCP SSM system architecture 215 includes a Distribution Source, to avoid confusion, in this 216 document a media source is commonly referred to as a Media 217 Sender. There may often be a single Media Sender that is co- 218 located with the Distribution Source. But although there MUST 219 be only one Distribution Source, there MAY be multiple Media 220 Senders on whose behalf the Distribution Source forwards RTP 221 and RTCP packets. 223 RTP and RTCP Channels: 224 The data distributed from the source to the receivers is 225 referred to as the RTP channel and the control information as 226 the RTCP channel. With standard RTP/RTCP, these channels 227 typically share the same multicast address but are 228 differentiated via port numbers as specified in [1]. In an SSM 229 context, the RTP channel is multicast from the Distribution 230 Source to the receivers. In contrast, the RTCP or feedback 231 channel is actually the collection of unicast channels between 232 the receivers and the Distribution Source via the Feedback 233 Target(s). Thus bi-directional communication is accomplished by 234 using SSM in the direction from Distribution Source to the 235 receivers and using the unicast feedback channel in the 236 direction from receivers to Distribution Source. As discussed 237 in the next section, the nature of the channels between the 238 Distribution Source and the Media Sender(s) may vary. 240 (Unicast RTCP) Feedback Target: 241 The Feedback Target is a logical function to which RTCP unicast 242 feedback traffic is addressed. The functions of the Feedback 243 Target and the Distribution Source MAY be co-located or 244 integrated in the same entity. In this case, for a session 245 defined as having a Distribution Source A, on ports n for the 246 RTP channel and k for the RTCP channel, the unicast RTCP 247 Feedback Target is identified by an IP address of Distribution 248 Source A on port k unless otherwise stated in the session 249 description. See Section 10 for details on how the address is 250 specified. The Feedback Target MAY also be implemented in one 251 or more entities different from the Distribution Source, and 252 different RTP receivers MAY use different Feedback Target 253 instances, e.g., for aggregation purposes. In this case, the 254 Feedback Target instances(s) MUST convey the feedback received 255 from the RTP receivers to the Distribution Source using the 256 RTCP mechanisms specified in this document. If disjoint, the 257 Feedback Target instances MAY be organized in arbitrary 258 topological structures: in parallel, hierarchical, or chained. 259 But the Feedback Target instance(s) and Distribution Source 260 MUST share, e.g., through configuration, enough information to 261 be able to provide coherent RTCP information to the RTP 262 receivers based upon the RTCP feedback collected by the 263 Feedback Target instance(s) -- as would be done if both 264 functions were part of the same entity. 266 RTCP with Unicast Feedback 268 In order for unicast feedback to work, each receiver MUST 269 direct its RTCP reports to a single specific Feedback Target 270 instance. 272 SSRC: 273 Synchronization source as defined in [1]. This 32-bit value 274 uniquely identifies each member in a session. 276 Report blocks: 277 Report block is the standard terminology for an RTCP reception 278 report. RTCP [1] encourages the stacking of multiple report 279 blocks in Sender Report (SR) and Receiver Report (RR) packets. 280 As a result, a variable size feedback packet may be created by 281 one source that reports on multiple other sources in the group. 282 The summarized reporting scheme builds upon this model through 283 the inclusion of multiple summary report blocks in one packet. 284 However, stacking of reports from multiple receivers is not 285 permitted in the Simple Feedback Model (see Section 6). 287 4. Basic Operation 289 As indicated by the definitions of the preceding section, one or 290 more Media Senders send RTP packets to the Distribution Source. The 291 Distribution Source relays the RTP packets to the receivers using a 292 source-specific multicast arrangement. In the reverse direction, 293 the receivers transmit RTCP packets via unicast to one or more 294 instances of the Feedback Target. The Feedback Target sends either 295 the original RTCP reports (the Simple Feedback Model) or summaries 296 of these reports (the Summary Feedback model) to the Distribution 297 Source. The Distribution Source in turn relays the RTCP reports 298 and/or summaries to the Media Senders. The Distribution Source also 299 transmits the RTCP sender reports and receiver reports or summaries 300 back to the receivers, using source-specific multicast. 302 When the Feedback Target(s) is/are co-located (or integrated) with 303 the Distribution Source, re-distribution of original or summarized 304 RTCP reports is trivial. When the Feedback Target(s) is/are 305 physically and/or topologically distinct from the Distribution 306 Source, each Feedback Target either relays the RTCP packets to the 307 Distribution source, or summarizes the reports and forwards an RTCP 308 summary report to the Distribution Source. Coordination between 309 multiple Feedback Targets is beyond the scope of this specification. 311 The Distribution Source MUST be able to communicate with all group 312 members in order for either mechanism to work. The general 313 architecture is displayed below in Figure 1. There may be a single 314 Media Sender or multiple Media Senders, Media Sender i, 1<=i<=M, on 315 whose behalf the Distribution Source disseminates RTP and RTCP 316 packets. The base case, which is expected to be the most common 317 case, is that the Distribution Source is co-located with a 318 particular Media Sender. A basic assumption is that communication is 319 multicast (either SSM or ASM) in the direction of the Distribution 320 RTCP with Unicast Feedback 322 Source to the receivers, R(j), 1<=j<=N, and unicast in the direction 323 of the receivers to the Distribution Source. 325 Communication between Media Sender(s) and the Distribution Source 326 may be performed in numerous ways: 328 i. Unicast only: The Media Sender(s) MAY send RTP and RTCP via 329 unicast to the Distribution Source and receive RTCP via 330 unicast. 332 ii. Any Source Multicast (ASM): the Media Sender(s) and the 333 Distribution Source MAY be in the same ASM group and RTP and 334 RTCP packets are exchanged via multicast. 336 iii. Source-Specific Multicast (SSM): The Media Sender(s) and the 337 Distribution Source MAY be in an SSM group with the source 338 being the Distribution Source. RTP and RTCP packets from the 339 Media Senders are sent via unicast to the Distribution Source 340 while RTCP packets from the Distribution Source are sent via 341 multicast to the Media Senders. 343 Note that this SSM group MAY be identical to the SSM group used 344 for RTP/RTCP delivery from the Distribution Source to the 345 receivers or MAY be a different one. 347 Note that figure 1 below shows a logical diagram and, therefore, no 348 details about the above options for the communication between Media 349 Sender(s), Distribution Source, Feedback Target(s), and receivers 350 are provided. 352 Configuration information needs to be supplied so that (among 353 others) 355 . Media Sender(s) know the transport address of the Distribution 356 Source or the transport address of the (ASM or SSM) multicast 357 group used for the contribution link; 358 . the Distribution Source knows either the unicast transport 359 address(es) or the (ASM or SSM) multicast transport address(es) 360 to reach the Media Sender(s); 361 . receivers know the addresses of their respectively responsible 362 Feedback Target, and 363 . the Feedback Target(s) know the transport address of the 364 Distribution Source. 366 The precise setup and configuration of the Media Senders and their 367 interaction with the Distribution Source is beyond the scope of this 368 document (appropriate SDP descriptions MAY be used for this purpose) 369 that only specifies how the various components interact within an 370 RTP session. Informative examples for different configurations of 371 the Media Sources and the Distribution Source are given in Appendix 372 A. 374 Future specifications may be defined to address these aspects. 376 RTCP with Unicast Feedback 378 Source-specific 379 +--------+ +-----+ Multicast 380 |Media | | | +----------------> R(1) 381 |Sender 1|<----->| D S | | | 382 +--------+ | I O | +--+ | 383 | S U | | | | 384 +--------+ | T R | | +-----------> R(2) | 385 |Media |<----->| R C |->+ +---- : | | 386 |Sender 2| | I E | | +------> R(n-1) | | 387 +--------+ | B | | | | | | 388 : | U | +--+--> R(n) | | | 389 : | T +-| | | | | 390 | I | |<---------+ | | | 391 +--------+ | O |F|<---------------+ | | 392 |Media | | N |T|<--------------------+ | 393 |Sender M|<----->| | |<-------------------------+ 394 +--------+ +-----+ Unicast 396 FT = Feedback Target 397 Transport from the Feedback Target to the Distribution 398 Source is via unicast or multicast RTCP if they are not 399 co=located. 401 Figure 1. System Architecture. 403 The first method proposed to support unicast RTCP feedback, the 404 'Simple Feedback Model', is a basic reflection mechanism whereby all 405 Receiver RTCP packets are unicast to the Feedback Target which 406 relays them unmodified to the Distribution Source. Subsequently, 407 these packets are forwarded by the Distribution Source to all 408 receivers on the multicast RTCP channel. The advantage of using 409 this method is that an existing receiver implementation requires 410 little modification in order to use it. Instead of sending reports 411 to a multicast address, a receiver uses a unicast address, yet still 412 receives forwarded RTCP traffic on the multicast control channel. 413 This method also has the advantage of being backwards compatible 414 with standard RTP/RTCP implementations. The Simple Feedback Model 415 is specified in section 6. 417 The second method, the 'Distribution Source Feedback Summary Model', 418 is a summarized reporting scheme that provides savings in bandwidth 419 by consolidating Receiver Reports at the Distribution Source, 420 optionally with help from the Feedback Target(s), into summary 421 packets that are then distributed to all the receivers. The 422 Distribution Source Feedback Summary Model is specified in section 423 7. 425 The advantage of the latter scheme is apparent for large group 426 sessions where the basic reflection mechanism outlined above 427 generates a large amount of packet forwarding when it replicates all 428 RTCP with Unicast Feedback 430 the information to all the receivers. Clearly, this technique 431 requires that all session members understand the new summarized 432 packet format outlined in Section 7.1. Additionally, the summarized 433 scheme provides an optional mechanism to send distribution 434 information or histograms about the feedback data reported by the 435 whole group. Potential uses for the compilation of distribution 436 information are addressed in Section 7.4. 438 To differentiate between the two reporting methods, a new SDP 439 identifier is created and discussed in Section 10. The reporting 440 method MUST be decided prior to the start of the session. A 441 Distribution Source MUST NOT change the method during a session. 443 In a session using SSM, the network SHOULD prevent any multicast 444 data from the receiver being distributed further than the first hop 445 router. Additionally, any data heard from a non-unicast capable 446 receiver by other hosts on the same subnet SHOULD be filtered out by 447 the host IP stack so that it does not cause problems with respect to 448 the calculation of the Receiver RTCP bandwidth share. 450 5. Packet types 452 The RTCP packet types defined in [1], [26], and [15] are: 454 Type Description Payload number 455 ------------------------------------------------------- 456 SR Sender Report 200 457 RR Receiver Report 201 458 SDES Source Description 202 459 BYE Goodbye 203 460 APP Application-Defined 204 461 RTPFB Generic RTP feedback 205 462 PSFB Payload-specific feedback 206 463 XR RTCP Extension 207 465 This document defines one further RTCP packet format: 467 Type Description Payload number 468 --------------------------------------------------------- 469 RSI Receiver Summary Information 208 471 Within the Receiver Summary Information packet, there are various 472 types of information that may be reported and encapsulated in 473 optional sub-report blocks: 475 RTCP with Unicast Feedback 477 Sub-Report Block Type Description Identifier number 478 ------------------------------------------------------------------ 479 IPv4 Address IPv4 Unicast Feedback address 0 480 IPv6 Address IPv6 Unicast Feedback address 1 481 DNS name DNS name for Unicast Feedback 2 482 - - reserved - 3 483 Loss Loss distribution 4 484 Jitter Jitter distribution 5 485 RTT Round trip time distribution 6 486 Cumulative loss Cumulative loss distribution 7 487 Collisions SSRC collision list 8 488 - - reserved - 9 489 Stats General statistics 10 490 Receiver BW RTCP Receiver Bandwidth 11 491 Group Info RTCP Group and Avg Packet Size 12 492 - - reserved - 13 - 255 494 As with standard RTP/RTCP, the various reports MAY be combined into 495 a single RTCP packet, which SHOULD NOT exceed the path MTU. Packets 496 continue to be sent at a rate that is inversely proportional to the 497 group size in order to scale the amount of traffic generated. 499 6. Simple Feedback Model 501 6.1 Packet Formats 503 The Simple Feedback Model uses the same packet types as traditional 504 RTCP feedback described in [1]. Receivers still generate Receiver 505 Reports with information on the quality of the stream received from 506 the Distribution Source. The Distribution Source still MUST create 507 Sender Reports that include timestamp information for stream 508 synchronization and round trip time calculation. Both Media Senders 509 and receivers are required to send SDES packets as outlined in [1]. 510 The rules for generating BYE and APP packets as outlined in [1] also 511 apply. 513 6.2 Distribution Source behavior 515 For the Simple Feedback Model, the Distribution Source MUST provide 516 a basic packet reflection mechanism. It is the default behavior for 517 any Distribution Source and is the minimum requirement for acting as 518 a Distribution Source to a group of receivers using unicast RTCP 519 feedback. 521 The Distribution Source (unicast Feedback Target) MUST listen for 522 unicast RTCP data sent to the RTCP port. All valid unicast RTCP 523 packets received on this port MUST be forwarded by the Distribution 524 Source to the group on the multicast RTCP channel. The Distribution 525 Source MUST NOT stack report blocks received from different 526 receivers into one packet for retransmission to the group. Every 527 RTCP packet from each receiver MUST be reflected individually. 529 RTCP with Unicast Feedback 531 If the Media Sender(s) are not part of the SSM group for RTCP packet 532 reflection, the Distribution Source MUST also forward the RTCP 533 packets received from the receivers to the Media Sender(s). If 534 there is more than one Media Sender and these Media Senders do not 535 communicate via ASM with the Distribution Source and each other, the 536 Distribution Source MUST forward each RTCP packet originated by one 537 Media Sender to all other Media Senders. 539 The Distribution Source MUST forward RTCP packets originating from 540 the Media Sender(s) to the receivers. 542 The reflected or forwarded RTCP traffic SHOULD NOT be counted as its 543 own traffic in the transmission interval calculation by the 544 Distribution Source. In other words, the Distribution Source SHOULD 545 NOT consider reflected packets as part of its own control data 546 bandwidth allowance. However, reflected packets MUST be processed 547 by the Distribution Source and the average RTCP packet size, RTCP 548 transmission rate, and RTCP statistics MUST be calculated. The 549 algorithm for computing the allowance is explained in Section 9. 551 6.3 Disjoint Distribution Source and Feedback Target(s) 553 If the Feedback Target function is disjoint from the Distribution 554 Source, the Feedback Target(s) MUST forward all RTCP packets from 555 the receivers or another Feedback Target -- directly or indirectly - 556 - to the Distribution Source. 558 6.4 Receiver behavior 560 Receivers MUST listen on the RTP channel for data and the RTCP 561 channel for control. Each receiver MUST calculate its share of the 562 control bandwidth R/n, in accordance with the profile in use, so 563 that a fraction of the RTCP bandwidth, R, allocated to receivers is 564 divided equally between the number of unique receiver SSRCs in the 565 session, n. R may be rtcp_bw*0.75 or rtcp_bw*0.5 (depending on the 566 ratio of senders to receivers as per [1]) or may be set explicitly 567 by means of an SDP attribute [10]. See Section 9 for further 568 information on the calculation of the bandwidth allowance. When a 569 receiver is eligible to transmit, it MUST send a unicast Receiver 570 Report packet to the Feedback Target following the rules defined in 571 section 9. 573 When a receiver observes either RTP packets or RTCP Sender Reports 574 from a Media Sender with an SSRC that collides with its own chosen 575 SSRC, it MUST change its own SSRC following the procedures of [1]. 576 The receiver MUST do so immediately after noticing and before 577 sending any (further) RTCP feedback messages. 579 If a receiver has out-of-band information available about the Media 580 Sender SSRC(s) used in the media session, it MUST NOT use the same 581 SSRC for itself. Even if such out-of-band information is available 582 a receiver MUST obey the above collision resolution mechanisms. 584 RTCP with Unicast Feedback 586 Further mechanisms defined in [1] apply for resolving SSRC 587 collisions between receivers. 589 6.5 Media Sender behavior 591 Media Senders listen on a unicast or multicast transport address for 592 RTCP reports sent by the receivers (and forwarded by the 593 Distribution Source) or other Media Senders (forwarded by the 594 Distribution Source if needed). Processing and general operation 595 follows [1]. 597 A Media Sender that observes an SSRC collision with another entity 598 that is not also a Media Sender MAY delay its own collision 599 resolution actions as per [1] by 5*1.5*Td with Td being the 600 deterministic calculated reporting interval for receivers to see 601 whether the conflict still exists. SSRC collisions with other Media 602 Senders MUST be acted upon immediately. 604 Note: This gives precedence to Media Senders and places the 605 burden of collision resolution on the RTP receivers. 607 Sender SSRC information MAY be communicated out-of-band, e.g., by 608 means of SDP media descriptions. Therefore, senders SHOULD NOT 609 change their own SSRC aggressively or unnecessarily. 611 7. Distribution Source Feedback Summary Model 613 In the Distribution Source Feedback Summary Model, the Distribution 614 Source is required to summarize the information received from all 615 the Receiver Reports generated by the receivers and place the 616 information into summary reports. The Distribution Source Feedback 617 Summary Model introduces a new report block format, the Receiver 618 Summary Information Report (RSI), and a number of optional sub- 619 report block formats, which are enumerated in Section 7.1. As 620 described in section 7.3, individual instances of the Feedback 621 Target may provide preliminary summarization to reduce the 622 processing load at the Distribution Source. 624 Sub-reports appended to the RSI report block provide more detailed 625 information on the overall session characteristics reported by all 626 receivers and can also convey important information such as the 627 feedback address and reporting bandwidth. Which sub-reports are 628 mandatory and which ones are optional is defined below. 630 From an RTP perspective, the Distribution Source is an RTP receiver, 631 generating its own Receiver Reports and sending them to the receiver 632 group and to the Media Senders. In the Distribution Source Feedback 633 Summary Model, an RSI report block MUST be appended to all RRs the 634 Distribution Source generates. 636 In addition, the Distribution Source MUST forward the RTCP SR 637 reports and SDES packets of Media Senders without alteration. If 638 the Distribution Source is actually a Media Sender, even if it is 639 RTCP with Unicast Feedback 641 the only session sender, it MUST generate its own Sender Report (SR) 642 packets for its role as a Media Sender and its Receiver Reports in 643 its role as the Distribution Source. 645 The Distribution Source MUST use its own SSRC value for transmitting 646 summarization information and MUST perform proper SSRC collision 647 detection and resolution. 649 The Distribution Source MUST send at least one Receiver Summary 650 Information packet for each reporting interval. The Distribution 651 Source MAY additionally stack sub-report blocks after the RSI 652 packet. If it does so, each sub-report block MUST correspond to the 653 RSI packet and constitutes an enhancement to the basic summary 654 information required by the receivers to calculate their reporting 655 time interval. For this reason, additional sub-report blocks are 656 not required but recommended. The compound RTCP packets containing 657 the RSI packet and the optional corresponding sub-report blocks MUST 658 be formed according to the rules defined in [1] for receiver-issued 659 packets, e.g., they MUST begin with an RR packet, contain at least 660 an SDES packet with a CNAME, and MAY contain further RTCP packets 661 and SDES items. 663 Every RSI packet MUST contain either a Group and Average Packet size 664 sub-report or an RTCP Bandwidth sub-report for bandwidth indications 665 to the receivers. 667 7.1 Packet Formats 669 All numeric values comprising multiple (usually two or four) octets 670 MUST be encoded in network byte order. 672 7.1.1 RSI: Receiver Summary Information Packet 674 The RSI report block has a fixed header size followed by a variable 675 length report: 677 0 1 2 3 678 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 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 |V=2|P|reserved | PT=RSI=208 | length | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | SSRC | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Summarized SSRC | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | NTP Timestamp (most significant word) | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | NTP Timestamp (least significant word) | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 : Sub-report blocks : 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 RTCP with Unicast Feedback 694 The RSI packet includes the following fields: 696 length: 16 bits 697 As defined in [1], the length of the RTCP packet in 32-bit words 698 minus one, including the header and any padding. 700 SSRC: 32 bits 701 The SSRC of the Distribution Source. 703 Summarized SSRC: 32 bits 704 The SSRC (of the Media Sender) of which this report contains a 705 summary. 707 Timestamp: 64 bits 708 Indicates the wallclock time when this report was sent. 709 Wallclock time (absolute date and time) is represented using the 710 timestamp format of the Network Time Protocol (NTP), which is in 711 seconds relative to 0h UTC on 1 January 1900 [1]. The 712 wallclock time MAY (but need not) be NTP-synchronized but it MUST 713 provide a consistent behavior in the advancement if time (similar 714 to NTP). The full resolution NTP timestamp is used which is a 715 64-bit unsigned fixed-point number with the integer part in the 716 first 32 bits and the fractional part in the last 32 bits. This 717 format is similar to RTCP sender reports (section 6.4.1 of [1]). 718 The timestamp value is used to enable detection of duplicate 719 packets, reordering and to provide a chronological profile of the 720 feedback reports. 722 7.1.2 Sub-Report Block Types 724 For RSI reports, this document also introduces a sub-report block 725 format specific to the RSI packet. The sub-report blocks are 726 appended to the RSI packet using the following generic format. All 727 sub-report blocks MUST be 32-bit aligned. 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | SRBT | Length | | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRBT-specific data + 733 | | 734 : : 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 SRBT: 8 bits 738 Sub-Report Block Type. The sub-report block type identifier. The 739 values for the sub-report block types are defined in section 5. 741 Length: 8 bits 742 The length of the sub-report in 32-bit words. 744 SRBT-specific data: octets 745 RTCP with Unicast Feedback 747 This field may contain type-specific information based upon the 748 SRBT value. 750 7.1.3 Generic Sub-Report Block Fields 752 For the sub-report blocks that convey distributions of values (Loss, 753 Jitter, RTT, Cumulative Loss), a flexible 'data bucket' style report 754 is used. This format divides the data set into variable size buckets 755 that are interpreted according to the guide fields at the head of 756 the report block. 758 0 1 2 3 759 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 760 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 761 | SRBT | Length | NDB | MF | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Minimum Distribution Value | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Maximum Distribution Value | 766 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 767 | Distribution Buckets | 768 | ... | 769 | ... | 770 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 772 The SRBT and Length fields are calculated as explained in section 773 7.1.2. 775 Number of distribution buckets (NDB): 12 bits 776 The number of distribution buckets of data. The size of each 777 bucket can be calculated using the formula ((length * 4) - 778 12)*8/NDB number of bits. The calculation is based on the length 779 of the whole sub-report block in octets (length field * 4) minus 780 the header of 12 octets. Providing 12 bits for the NDB field 781 enables bucket sizes as small as 2 bits for a full length packet 782 of MTU 1500 bytes. The bucket size in bits must always be 783 divisible by 2 to ensure proper byte alignment. A bucket size of 784 2 bits is fairly restrictive, however, and it is expected that 785 larger bucket sizes will be more practical for most 786 distributions. 788 Multiplicative Factor (MF): 4 bits 789 2^MF indicates the multiplicative factor to be applied to each 790 distribution bucket value. Possible values of MF are 0 - 15, 791 creating a range of values from MF = 1, 2, 4 ... 32768. Appendix 792 B gives an example of the use of the multiplicative factor; it is 793 meant to provide more "bits" without having them -- the bucket 794 values get scaled up by the MF. 796 Length: 8 bits 797 The length field tells the receiver the full length of the sub- 798 report block in 32-bit words (i.e., length * 4 bytes), and 799 RTCP with Unicast Feedback 801 enables the receiver to identify the bucket size. For example, 802 given no MTU restrictions, the data portion of a distribution 803 packet may be only as large as 1008 bytes (255 * 4 - 12), 804 providing up to 4032 data buckets of length 2 bits, or 2016 data 805 buckets of length 4 bits, etc. 807 Minimum distribution value (min): 32 bits 808 The minimum distribution value, in combination with the maximum 809 distribution value, indicates the range covered by the data 810 bucket values. 812 Maximum distribution value (max): 32 bits 813 The maximum distribution value, in combination with the minimum 814 distribution value, indicates the range covered by the data 815 bucket values. The significance and range of the distribution 816 values is defined in the individual subsections for each 817 distribution type (DT). 819 Distribution buckets: each bucket is ((length * 4) - 12)*8/NDB bits 820 The size and number of buckets is calculated as outlined above 821 based upon the value of NDB and the length of the packet. The 822 values for distribution buckets are equally distributed; 823 according to the following formula, distribution bucket x 824 (with 0 <= x < NDB) covering the value range: 826 x=0; [min, min+(max-min)/NDB] 827 x>0; [min+(x)*(max-min)/NDB, min+(x+1)*(max-min)/NDB] 829 Interpretation of the minimum, maximum, and distribution values in 830 the sub-report block is sub-report-specific and is addressed 831 individually in the sections below. The size of the sub-report 832 block is variable, as indicated by the packet length field. 834 Note that, for any bucket-based reporting, if the Distribution 835 Source and the Feedback Target(s) are disjoint entities, out-of-band 836 agreement on the bucket reporting granularity is recommended to 837 allow the Distribution Source to forward accurate information in 838 these kinds of reports to the receivers. 840 7.1.4 Loss sub-report block 842 The loss sub-report block allows a receiver to determine how its own 843 reception quality relates to the other recipients. A receiver may 844 use this information, e.g., to drop out of a session (instead of 845 sending lots of error repair feedback) if it finds itself isolated 846 at the lower end of the reception quality scale. 848 The loss sub-report block indicates the distribution of losses as 849 reported by the receivers to the Distribution Source. Values are 850 expressed as a fixed-point number with the binary point at the left 851 edge of the field similar to the "fraction lost" field in SR and RR 852 packets as defined in [1]. The Loss sub-report block type (SRBT) is 853 4. 855 RTCP with Unicast Feedback 857 Valid results for the minimum distribution value field are 0 - 254. 858 Similarly, valid results for the maximum distribution value field 859 are 1 - 255. The minimum distribution value MUST always be less 860 than the maximum. 862 For examples on processing summarized loss report sub-blocks, see 863 Appendix B. 865 7.1.5 Jitter sub-report block 867 A jitter sub-report block indicates the distribution of the 868 estimated statistical variation of the RTP data packet inter-arrival 869 time reported by the receivers to the Distribution Source. This 870 allows receivers both to place their own observed jitter values in 871 context with the rest of the group, and to approximate dynamic 872 parameters for playout buffers. See [1] for details on the 873 calculation of the values and the relevance of the jitter results. 874 Jitter values are measured in timestamp units with the rate used by 875 the Media Sender and expressed as unsigned integers. The minimum 876 distribution value MUST always be less than the maximum. The Jitter 877 sub-report block type (SRBT) is 5. 879 Since timestamp units are payload-type specific, the relevance of a 880 jitter value is impacted by any change in the payload type during a 881 session. Therefore, a Distribution Source MUST NOT report jitter 882 distribution values for at least 2 reporting intervals after a 883 payload type change occurs. 885 7.1.6 Round Trip Time sub-report block 887 A round trip time sub-report indicates the distribution of round 888 trip times from the Distribution Source to the receivers, providing 889 receivers with a global view of the range of values in the group. 890 The Distribution Source is capable of calculating the round trip 891 time to any other members since it forwards all the SR packets from 892 the Media Sender(s) to the group. If the Distribution Source is not 893 itself a Media Sender, it can calculate the round trip time from 894 itself to any of the receivers by maintaining a record of the SR 895 sender timestamp, and the current time as measured from its own 896 system clock. The Distribution Source consequently calculates the 897 round trip time from the receiver report by identifying the 898 corresponding SR timestamp and subtracting the RR advertised holding 899 time as reported by the receiver from its own time difference 900 measurement, as calculated by the time the RR packet is received and 901 the recorded time the SR was sent. 903 The Distribution Source has the option of distributing these round 904 trip time estimations to the whole group, uses of which are 905 described in Section 7.4. The round trip time is expressed in units 906 of 1/65536 seconds and indicates an absolute value. This is 907 calculated by the Distribution Source based on the Receiver Report 908 RTCP with Unicast Feedback 910 responses declaring the time difference since an original Sender 911 Report, and the holding time at the receiver. The minimum 912 distribution value MUST always be less than the maximum. The Round 913 Trip Time sub-report block type (SRBT) is 6. 915 Note that if the Distribution Source and the Feedback Target 916 functions are disjoint, it is only possible for the Distribution 917 Source to determine RTT if all the Feedback Targets forward all 918 RTCP reports from the receivers immediately (i.e., do not perform 919 any preliminary summarization) and include at least the RR 920 packet. 922 7.1.7 Cumulative Loss sub-report block 924 The cumulative loss field in a Receiver Report [1], in contrast to 925 the fraction lost field, is intended to provide some historical 926 perspective on the session performance, i.e., the total number of 927 lost packets since the receiver joined the session. The cumulative 928 loss value provides a longer-term average by summing over a larger 929 sample set (typically the whole session). The Distribution Source 930 MAY record the values as reported by the receiver group and report a 931 distribution of values. Values are expressed as a fixed-point 932 number with the binary point at the left edge of the field, in the 933 same manner as the Loss sub-report block. Since the individual 934 Receiver Reports give the cumulative number of packets lost but not 935 the cumulative number sent, which is required as a denominator to 936 calculate the long-term fraction lost, the Distribution Source MUST 937 maintain a record of the cumulative number lost and extended highest 938 sequence number received as reported by each receiver at some point 939 in the past. Ideally the recorded values are from the first report 940 received. Subsequent calculations are then based on ( - ) / ( - ). 944 Valid results for the minimum distribution value field are 0 - 254. 945 Similarly, valid results for the maximum distribution value field 946 are 1 - 255. The minimum distribution value MUST always be less 947 than the maximum. The Cumulative loss sub-report block type (SRBT) 948 is 7. 950 7.1.8 Feedback Target Address sub-report block 952 The Feedback Target Address block provides a dynamic mechanism for 953 the Distribution Source to signal an alternative unicast RTCP 954 feedback address to the receivers. If a block of this type is 955 included, receivers MUST override any static SDP address information 956 for the session with the Feedback Target address provided in this 957 sub-report block. 959 If a Feedback Target Address sub-report block is used, it MUST be 960 included in every RTCP packet originated by the Distribution Source 961 RTCP with Unicast Feedback 963 to ensure that all receivers understand the information. In this 964 manner, receiver behavior should remain consistent even in the face 965 of packet loss or when there are late session arrivals. 967 0 1 2 3 968 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 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | SRBT={0,1,2} | Length | Port | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | | 973 : Address : 974 | | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 SRBT: 8 bits 978 The type of sub-report block that corresponds to the type of 979 address is as follows: 981 0: IPv4 address 982 1: IPv6 address 983 2: DNS name 985 Length: 8 bits 986 The length of the sub-report block in 32-bit words. For an IPv4 987 address this should be 2 (i.e., Total length = 4 + 4 = 2*4 988 octets). For an IPv6 address this should be 5. For a DNS name, 989 the length field indicates the number of 32-bit words making up 990 the string plus 1 byte and any additional padding required to 991 reach the next word boundary. 993 Port: 2 octets 994 The port number to which receivers send feedback reports. A port 995 number of 0 is invalid and MUST NOT be used. 997 Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name) 998 The address to which receivers send feedback reports. For IPv4 999 and IPv6 fixed-length address fields are used. A DNS name is an 1000 arbitrary length string that is padded with null bytes to the 1001 next 32 bit boundary. The string MAY contain IDNA domain names 1002 and MUST be UTF-8 encoded [11]. 1004 A feedback target address block for a certain address type (i.e., 1005 with a certain SRBT of 0, 1, or 2) MUST NOT occur more than once 1006 within a packet. Numerical feedback target address blocks for IPv4 1007 and IPv6 MAY both be present. If so, the resulting transport 1008 addresses MUST point to the same logical entity. 1010 If a feedback target address block with an SRBT indicating a DNS 1011 name is present, there SHOULD NOT be any other numerical Feedback 1012 Target Address blocks present. 1014 RTCP with Unicast Feedback 1016 The Feedback Target Address presents a significant security risk if 1017 accepted from unauthenticated RTCP packets. See section 11.3 and 1018 11.4 for further discussion. 1020 7.1.9 Collisions sub-report block 1022 The collision SSRC sub-report provides the Distribution Source with 1023 a mechanism to report SSRC collisions amongst the group. In the 1024 event that a non-unique SSRC is discovered based on the tuple 1025 [SSRC,CNAME], the collision is reported in this block and the 1026 affected nodes must reselect their respective SSRC identifiers. 1028 0 1 2 3 1029 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 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | SRBT=8 | Length | Reserved | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | | 1034 : Collision SSRC : 1035 | | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 Collision SSRC: n x 32 bits 1039 This field contains a list of SSRCs that are duplicated within 1040 the group. Usually this is handled by the hosts upon detection 1041 of the same SSRC; however, since receivers in an SSM session 1042 using the Distribution Source Feedback Summary Model no longer 1043 have a global view of the session, the collision algorithm is 1044 handled by the Distribution Source. SSRCs that collide are 1045 listed in the packet. Each Collision SSRC is reported only once 1046 for each collision detection. If more Collision SSRCs need to be 1047 reported than fit into an MTU, the reporting is done in a round 1048 robin fashion so that all Collision SSRCs have been reported once 1049 before the second round of reporting starts. On receipt of the 1050 packet, receiver(s) MUST detect the collision and select another 1051 SSRC, if the collision pertains to them. 1053 The Collisions sub-report block type (SRBT) is 8. 1055 Collision detection is only possible at the Distribution Source. If 1056 the Distribution Source and Feedback Target Functions are disjoint 1057 and collision reporting across RTP receiver SSRCs shall be provided, 1058 the Feedback Targets(s) MUST forward the RTCP reports from the RTP 1059 receivers including at least the RR and the SDES packets to the 1060 Distribution Source. 1062 In system settings in which, by explicit configuration or 1063 implementation, RTP receivers are not going to act as Media Senders 1064 in a session (e.g. for various types of television broadcasting), 1065 SSRC collision detection MAY be omitted for RTP receivers. In 1066 system settings in which an RTP receiver MAY become a Media Sender 1067 RTCP with Unicast Feedback 1069 (e.g., any conversational application), SSRC collision detection 1070 MUST be provided for RTP receivers. 1072 Note: The purpose of SSRC collision reporting is to ensure 1073 unique identification of RTCP entities. This is of particular 1074 relevance for Media Senders so that an RTP receiver can 1075 associate each of multiple incoming media streams (via the 1076 Distribution Source) properly with the correct sender. 1077 Collision resolution for Media Senders is not affected by the 1078 Distribution Source's collision reporting because all SR 1079 reports are always forwarded among the senders and to all 1080 receivers. Collision resolution for RTP receivers is of 1081 particular relevance for those receivers capable of becoming a 1082 Media Sender. RTP receivers that will, by configuration or 1083 implementation choice, not act as a sender in a particular RTP 1084 session, do not necessarily need to be aware of collisions as 1085 long as the those entities receiving and processing RTCP 1086 feedback messages from the receivers are capable of 1087 disambiguating the various RTCP receivers (e.g., by CNAME). 1089 Note also that RTP receivers should be able to deal with 1090 changing SSRCs of a Media Sender (like any RTP receiver has to 1091 do.) and, if possible, be prepared to render a media stream 1092 continuously nevertheless. 1094 7.1.10 General Statistics sub-report block 1096 The general statistics sub-report block is used if specifying 1097 buckets is deemed too complex. With the general statistics sub- 1098 report block only aggregated values are reported back. The rules 1099 for the generation of these values are provided in section 7.2.1.b. 1101 0 1 2 3 1102 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 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | SRBT=10 | Length | Reserved | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | MFL | HCNL | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | Median interarrival jitter | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 Median fraction lost (MFL): 8 bits 1112 The median fraction lost indicated by Receiver Reports forwarded 1113 to this Distribution Source, expressed as a fixed point number 1114 with the binary point at the left edge of the field. A value of 1115 all '1's indicates that the MFL value is not provided. 1117 Highest cumulative number of packets lost (HCNL): 24 bits 1118 Highest 'cumulative number of packets lost' value out of the most 1119 recent RTCP RR packets from any of the receivers. A value of all 1120 '1's indicates that the HCNL value is not provided. 1122 RTCP with Unicast Feedback 1124 Median inter-arrival jitter: 32 bits 1125 Median 'inter-arrival jitter' value out of the most recent RTCP 1126 RR packets from the receiver set. A value of all '1's indicates 1127 that this value is not provided. 1129 The General Statistics sub-report block type (SRBT) is 10. 1131 Note that, in case the Distribution Source and the Feedback Target 1132 functions are disjoint, it is only possible for the Distribution 1133 Source to determine the median of the inter-arrival jitter if all 1134 the Feedback Targets forward all RTCP reports from the receivers 1135 immediately and include at least the RR packet. 1137 7.1.11 RTCP Bandwidth Indication sub-report block 1139 This sub-report block is used to inform the Media Senders and 1140 receivers about the maximum RTCP bandwidth that is supposed to be 1141 used by each Media Sender or about the maximum bandwidth allowance 1142 to be used by each receiver. The value is applied universally to 1143 all Media Senders or all receivers. Each receiver MUST base its 1144 RTCP transmission interval calculation on the average size of the 1145 RTCP packets sent by itself. Conversely, each Media Sender MUST base 1146 its RTCP transmission interval calculation on the average size of 1147 the RTCP packets sent by itself. 1149 0 1 2 3 1150 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 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | SRBT=11 | Length |S|R| Reserved | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | RTCP Bandwidth | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 Sender (S): 1 bit 1158 The contained bandwidth value applies to each Media Sender. 1160 Receivers (R): 1 bit 1161 The contained bandwidth value applies to each RTP receiver. 1163 Reserved: 14 bits 1164 MUST be set to zero upon transmission and ignored upon reception. 1166 RTCP Bandwidth: 32 bits 1167 If the S bit is set to 1, this field indicates the maximum 1168 bandwidth allocated to each individual Media Sender. This also 1169 informs the receivers about the RTCP report frequency to expect 1170 from the senders. This is a fixed point value with the binary 1171 point in between the second and third bytes. The value represents 1172 the bandwidth allocation per-receiver in kilobits per second with 1173 values in the range 0 <= BW < 65536. 1175 RTCP with Unicast Feedback 1177 If the R bit is set to 1, this field indicates the maximum 1178 bandwidth allocated per receiver for sending RTCP data relating 1179 to the session. This is a fixed point value with the binary 1180 point in between the second and third bytes. The value 1181 represents the bandwidth allocation per-receiver in kilobits per 1182 second with values in the range 0 <= BW < 65536. Each receiver 1183 MUST use this value for its bandwidth allowance. 1185 This report block SHOULD only be used when the Group and Average 1186 Packet Size sub-report block is NOT included. The RTCP Bandwidth 1187 Indication sub-report block type (SRBT) is 11. 1189 7.1.12 RTCP Group and Average Packet Size Sub-report Block 1191 This sub-report block is used to inform the Media Senders and 1192 receivers about the size of the group (used for calculating feedback 1193 bandwidth allocation) and the average packet size of the group. 1194 This sub-report MUST always be present, appended to every RSI 1195 packet, unless an RTCP Bandwidth indication sub-report block is 1196 included (in which case it MAY but need not be present). 1198 Note: The RTCP Bandwidth Indication sub-report block allows the 1199 Distribution Source to hide the actual group size from the 1200 receivers while still avoiding feedback implosion. 1202 0 1 2 3 1203 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 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | SRBT=12 | Length | Average Packet Size | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Receiver Group Size | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 Group size: 32 bits 1211 This field provides the Distribution Source's view of the number 1212 of receivers in a session. Note that the number of Media Senders 1213 is not explicitly reported since it can be derived by observing 1214 the RTCP SR packets forwarded by the Distribution Source. The 1215 group size is calculated according to the rules outlined in [1]. 1216 When this sub-report block is included, this field MUST always be 1217 present. 1219 Average RTCP packet size: 16 bits 1220 This field provides the Distribution Source's view of the average 1221 RTCP packet size as locally calculated following the rules 1222 defined in [1]. The value is an unsigned integer counting 1223 octets. When this sub-report block is included, this field MUST 1224 always be present. 1226 The Group and Average Packet Size sub-report block type (SRBT) is 1227 12. 1229 RTCP with Unicast Feedback 1231 7.2 Distribution Source behavior 1233 In the Distribution Source Feedback Summary Model, the Distribution 1234 Source (the unicast Feedback Target) MUST listen for unicast RTCP 1235 packets sent to the RTCP port. All RTCP packets received on this 1236 port MUST be processed by the Distribution Source as described 1237 below. The processing MUST take place per Media Sender SSRC about 1238 which receiver reports are received. 1240 The Distribution Source acts like a regular RTCP receiver. In 1241 particular, it receives an RTP stream from each RTP Media Sender(s) 1242 and MUST calculate the proper reception statistics for these RTP 1243 streams. It MUST transmit the resulting information as report 1244 blocks contained in each RTCP packet it sends (in an RR packet). 1246 Note: This information may help to determine the transmission 1247 characteristics of the feed path from the RTP sender to the 1248 Distribution Source (if these are separate entities). 1250 The Distribution Source is responsible for accepting RTCP packets 1251 from the receivers, and interpreting and storing per-receiver 1252 information as defined in [1]. The importance of providing these 1253 functions is apparent when creating the RSI and sub-report block 1254 reports, since incorrect information can have serious implications. 1255 Section 11 addresses the security risks in detail. 1257 As defined in [1], all RTCP reports from the Distribution Source 1258 MUST start with an RR report followed by any relevant SDES fields. 1259 Then, the Distribution Source MUST append an RSI header and sub- 1260 reports containing any summarization specific data. In addition, 1261 either the Group and Average Packet size sub-report or the Receiver 1262 RTCP Bandwidth sub-report block MUST be appended to the RSI header. 1264 A Distribution Source has the option of masking the Group size by 1265 including only an RTCP bandwidth sub-report. If both sub-reports 1266 are included, the receiver is expected to give precedence to the 1267 information contained in the Receiver RTCP Bandwidth sub-report. 1269 The Receiver RTCP Bandwidth sub-report block provides the 1270 Distribution Source with the capability to control the amount of 1271 feedback from the receivers and the bandwidth value MAY be increased 1272 or decreased based upon the requirements of the Distribution Source. 1273 Regardless of the value selected by the Distribution Source for the 1274 Receiver RTCP Bandwidth sub-report block, the Distribution Source 1275 MUST continue to forward Sender Reports and RSI packets at the rate 1276 allowed by the total RTCP bandwidth allocation. See Section 9 for 1277 further details about the frequency of reports. 1279 A Distribution Source MAY start out reporting Group size and switch 1280 to Receiver RTCP Bandwidth reporting later on and vice versa. If 1281 the Distribution Source does so, it SHOULD ensure that the 1282 RTCP with Unicast Feedback 1284 correspondingly indicated values for the Receiver RTCP Bandwidth 1285 roughly match, i.e., are at least the same order of magnitude. 1287 In order to identify SSRC collisions, the Distribution Source is 1288 responsible for maintaining a record of each SSRC and the 1289 corresponding CNAME within at least one reporting interval by the 1290 group in order to differentiate between clients. It is RECOMMENDED 1291 that an updated list of more than one interval be maintained to 1292 increase accuracy. This mechanism should prevent the possibility of 1293 collisions since the combination of SSRC and CNAME should be unique, 1294 if the CNAME is generated correctly. If collisions are not 1295 detected, the Distribution Source will have an inaccurate impression 1296 of the group size. Since the statistical probability is very low 1297 that collisions will both occur and be undetectable, this should not 1298 be a significant concern. In particular, the clients would have to 1299 randomly select the same SSRC and have the same username + IP 1300 address (e.g., using private address space behind a NAT router). 1302 7.2.1 Receiver Report Aggregation 1304 The Distribution Source is responsible for aggregating reception 1305 quality information received in RR packets. In doing so, the 1306 Distribution Source MUST consider the report blocks received in 1307 every RR packet and MUST NOT consider the report blocks of an SR 1308 packet. 1310 Note: the receivers will get the information contained in the SR 1311 packets anyway by packet forwarding so that duplication of this 1312 information should be avoided. 1314 For the optional sub-report blocks, the Distribution Source MAY 1315 decide which are the most significant feedback values to convey and 1316 MAY choose not to include any. The packet format provides 1317 flexibility in the amount of detail conveyed by the data points. 1318 There is a tradeoff between the granularity of the data and the 1319 accuracy of the data based on the multiplicative factor (MF), the 1320 number of buckets, and the min and max values. In order to focus on 1321 a particular region of a distribution, the Distribution Source can 1322 adjust the minimum and maximum values, and either increase the 1323 number of buckets and possibly the factorization, or decrease the 1324 number of buckets and provide more accurate values. See Appendix B 1325 for detailed examples on how to convey a summary of RTCP Receiver 1326 Reports as RSI sub-report block information. 1328 For each value the Distribution Source decides to include in an RSI 1329 packet, it MUST adhere to the following measurement rules. 1331 a) If the Distribution Source intends to use a sub-report to convey 1332 a distribution of values (sections 7.1.3 to 7.1.7), it MUST keep 1333 per receiver state, i.e., remember the last value V reported by 1334 the respective receiver. If a new value is reported by a 1335 receiver, the existing value MUST be replaced by the new one. 1336 The value MUST be deleted (along with the entire entry) if the 1337 RTCP with Unicast Feedback 1339 receiver is timed out (as per section 6.3.5 of [1]) or has sent 1340 a BYE packet (as per section 6.3.7 of [1]). 1342 All the values collected in this way MUST be included in the 1343 creation of the subsequent distribution sub-report block. 1345 The results should correspond as closely as possible to the 1346 values received during the interval since the last report. The 1347 Distribution Source may stack as many sub-report blocks as 1348 required in order to convey different distributions. If the 1349 distribution size exceeds the largest packet length (1008 bytes 1350 data portion), more packets MAY be stacked with additional 1351 information (but in total SHOULD NOT exceed the path MTU). 1353 All stacked sub-reports MUST be internally consistent, i.e., 1354 generated from the same session data. Overlapping of 1355 distributions is therefore allowed, and variation in values 1356 should only occur as a result of data set granularity, with the 1357 more accurate bucket sizes taking precedence in the event that 1358 values differ. Non-divisible values MUST be rounded up or down 1359 to the closest bucket value, and the number of data buckets must 1360 always be an even number, padding where necessary with an 1361 additional zero bucket value to maintain consistency. 1363 Note: This intentionally provides persistent full coverage of 1364 the entire session membership to avoid oscillations due to 1365 changing membership samples. 1367 Scheduling the transmission of summarization reports is left to 1368 the discretion of the Distribution Source. However, the 1369 Distribution Source MUST adhere to the bandwidth limitations for 1370 receiver reports as defined for the respective AV profile in 1371 use. 1373 b) If the Distribution Source intends to report a short summary 1374 using the General Statistics sub-report block format defined in 1375 section 7.1.10, for EACH of the values included in the report 1376 (AFL, HCNL, average interarrival jitter), it MUST keep a timer 1377 T_summary as well as a sufficient set of variables to calculate 1378 the summaries for the last three reporting intervals. This MAY 1379 be achieved by keeping per-receiver state, i.e., remember the 1380 last value V reported by the respective receiver, or by 1381 maintaining summary variables for each of these intervals. 1383 The summary values are included here to reflect the current 1384 group situation. By recording the last three reporting intervals 1385 the Distribution Source incorporates reports from all members 1386 while allowing for individual RTCP receiver report packet 1387 losses. The process of collecting these values also aims to 1388 avoid resetting any of the values and then having to send out an 1389 RSI report based upon just a few values collected. If data is 1390 available for less than three reporting intervals (as will be 1391 the case for the first two reports sent), only those values 1392 available are considered. 1394 RTCP with Unicast Feedback 1396 The timer T_summary MUST be initialized as T_summary = 1.5*Td, 1397 where Td is the deterministic reporting interval, and MUST be 1398 updated following timer reconsideration whenever the group size 1399 or the average RTCP size ("avg_rtcp_size") changes. This choice 1400 should allow each receiver to report once per interval. 1402 Td 1403 __^__ 1404 t0/ \ t1 t2 t3 t4 t5 1405 ---+---------+---------+---------+---------+---------+-------> 1406 \____ ____/ : : : : 1407 : V : : : : : 1408 :T_summary: : : : : 1409 : =1.5*Td : : : : : 1410 \______________ ______________/ : : 1411 : V : : : 1412 : 3*T_summary : : 1413 : : : : 1414 \______________ ______________/ : 1415 : V : 1416 : 3*T_summary : 1417 : : 1418 \______________ ______________/ 1419 V 1420 3*T_summary 1422 Figure 2: Overview of summarization reporting 1424 Figure 2 depicts how the summarization reporting shall be 1425 performed. At time t3, the RTCP reports collected from t0 1426 through t3 are included in the RSI reporting, at time t4, those 1427 from t1 through t4, and so on. The RSI summary report sent MUST 1428 NOT include any RTCP report from more than three reporting 1429 intervals ago; e.g., the one sent at time t5, must not include 1430 reports received at the Distribution Source prior to t2. 1432 7.2.2 Handling Other RTCP Packets from RTP receivers 1434 When following the Feedback Summary Model the Distribution Source 1435 MAY reflect any other RTCP packets of potential relevance to the 1436 receivers (such as APP, RTPFB, PSFB) to the receiver group and MAY 1437 decide not to forward other RTCP packets not needed as such by the 1438 receivers (such as BYE, RR, SDES because the Distribution Source 1439 performs collision resolution, group size estimation, and RR 1440 aggregation). The Distribution Source MUST NOT forward RR packets 1441 to the receiver group. 1443 If the Distribution Source is able to interpret and aggregate 1444 information contained in any RTCP packets other than RR, it MAY 1445 include the aggregated information along with the RSI packet in its 1446 own compound RTCP packet. 1448 RTCP with Unicast Feedback 1450 Aggregation MAY be a null operation, i.e., the Distribution Source 1451 MAY simply append one or more RTCP packets from receivers to the 1452 compound RTCP packet (containing at least RR, SDES and RSI from the 1453 Distribution Source). 1455 Note: This is likely to be useful only for a few cases, e.g., 1456 to forward aggregated information from RTPFB Generic NACK 1457 packets and thereby maintain the damping property of [15]. 1459 Note: This entire processing rule implies that the flow of 1460 information contained in non-RR RTCP packets may terminate at 1461 the Distribution Source depending on its capabilities and 1462 configuration. 1464 The configuration of the RTCP SSM media session (expressed in SDP) 1465 MUST specify explicitly which processing the Distribution Source 1466 will apply to which RTCP packets. See section 10.1 for details. 1468 7.2.3 Receiver Report Forwarding 1470 If the Media Sender(s) are not part of the SSM group for RTCP packet 1471 reflection, the Distribution Source MUST explicitly inform the Media 1472 Senders of the receiver group. To achieve this, the Distribution 1473 Source has two options: Either it forwards the RTCP RR and SDES 1474 packets received from the receivers to the Media Sender(s). Or, if 1475 the Media Senders also support the RTCP RSI packet, the Distribution 1476 Source sends the RSI packets not just to the receivers but also to 1477 the Media Senders. 1479 If the Distribution Source decides to forward RR and SDES packets 1480 unchanged, it MAY also forward any other RTCP packets to the 1481 senders. 1483 If the Distribution Source decides to forward RSI packets to the 1484 senders, the considerations of 7.2.2 apply. 1486 7.2.4 Handling Sender Reports 1488 The Distribution Source also receives RTCP (including SR) packets 1489 from the RTP Media Senders. 1491 The Distribution Source MUST forward all RTCP packets from the Media 1492 Senders to the RTP receivers. 1494 If there is more than one Media Sender and these Media Senders do 1495 not communicate via ASM with the Distribution Source and each other, 1496 the Distribution Source MUST forward each RTCP packet from any one 1497 Media Sender to all other Media Senders. 1499 7.2.5 RTCP Data Rate Calculation 1500 RTCP with Unicast Feedback 1502 As noted above, the Distribution Source is a receiver from an RTP 1503 perspective. The Distribution Sources MUST calculate its 1504 deterministic transmission interval Td as every other receiver, 1505 however, it MAY adjust its available data rate depending on the 1506 destination transport address and its local operation: 1508 1. For sending its own RTCP reports to the SSM group towards the 1509 receivers, the Distribution Source MAY use up to the joint share 1510 of all receivers as it is forwarding summaries on behalf of all 1511 of them. Thus, the Distribution Source MAY send its reports up 1512 to every Td/R time units, with R being the number of receivers. 1514 2. For sending its own RTCP reports to the Media Senders only (i.e., 1515 if the Media Senders are not part of the SSM group), the 1516 allocated rate depends on the operation of the Distribution 1517 Source: 1519 a) If the Distribution Source only sends RSI packets along with its 1520 own RTCP RR packets, the same rate calculation applies as for 1 1521 above. 1523 b) If the Distribution Source forwards RTCP packets from all other 1524 receivers to the Media Senders, then it MUST adhere to the same 1525 bandwidth share for its own transmissions as all other receivers 1526 and use the calculation as per [1]. 1528 7.2.6 Collision Resolution 1530 A Distribution Source observing RTP packets from a Media Sender with 1531 an SSRC that collides with its own chosen SSRC MUST change its own 1532 SSRC following the procedures of [1] and MUST do so immediately 1533 after noticing. 1535 A Distribution Source MAY use out-of-band information about the 1536 Media Sender SSRC(s) used in the media session when available to 1537 avoid SSRC collisions with Media Senders. Nevertheless, the 1538 Distribution Source MUST monitor Sender Report (SR) packets to 1539 detect any changes, observe collisions, and then follow the above 1540 collision resolution procedure. 1542 For collision resolution between the Distribution Source and 1543 receivers or the Feedback Target(s) (if a separate entity as 1544 described in the next subsection), the Distribution Source and the 1545 Feedback Target (if separate) operate similar to ordinary receivers. 1547 7.3 Disjoint Distribution Source and Feedback Target 1549 If the Distribution Source and the Feedback Target are disjoint, the 1550 processing of the Distribution Source is limited by the amount of 1551 RTCP feedback information made available by the Feedback Target. 1553 RTCP with Unicast Feedback 1555 The Feedback Target(s) MAY simply forward all RTCP packets incoming 1556 from the RTP receivers to the Distribution Source in which case the 1557 Distribution Source will have all the information available 1558 necessary to perform all the functions described above. 1560 The Feedback Target(s) MAY also perform aggregation of incoming RTCP 1561 packets and send only aggregated information to the Distribution 1562 Source. In this case, the Feedback Target(s) MUST use correctly 1563 formed RTCP packets to communicate with the Distribution Source and 1564 they MUST operate in concert with the Distribution Source so that 1565 the Distribution Source and the Feedback Target(s) appear operating 1566 as a single entity. The Feedback Target(s) MUST report their 1567 observed receiver group size to the Distribution Source, either 1568 explicitly by means of RSI packets or implicitly by forwarding all 1569 RR packets. 1571 Note: For example, for detailed statistics reporting, the 1572 Distribution Source and the Feedback Target(s) may need to 1573 agree on a common reporting granularity so that the 1574 Distribution Source can aggregate the buckets incoming from 1575 various Feedback Targets into a coherent report sent to the 1576 receivers. 1578 The joint behavior or Distribution Source and Feedback Target(s) 1579 MUST be reflected in the (SDP-based) media session description as 1580 per 7.2.2. 1582 If the Feedback Target performs summarization functions, it MUST 1583 also act as a receiver and choose a unique SSRC for its own 1584 reporting towards the Distribution Source. The collision resolution 1585 considerations for receivers apply. 1587 7.4 Receiver behavior 1589 An RTP receiver MUST process RSI packets and adapt session 1590 parameters such as the RTCP bandwidth based on the information 1591 received. The receiver no longer has a global view of the session, 1592 and will therefore be unable to receive information from individual 1593 receivers aside from itself. However, the information conveyed by 1594 the Distribution Source can be extremely detailed, providing the 1595 receiver with an accurate view of the session quality overall, 1596 without the processing overhead associated with listening to and 1597 analyzing all Receiver Reports. 1599 The RTP receiver MUST process the report blocks contained in any RTP 1600 SR and RR packets to complete its view of the RTP session. 1602 The SSRC collision list MUST be checked against the SSRC selected by 1603 the receiver to ensure there are no collisions as MUST be incoming 1604 RTP packets from the Media Senders. A receiver observing RTP 1605 packets from a Media Sender with an SSRC that collides with its own 1606 chosen SSRC MUST change its own SSRC following the procedures of 1607 RTCP with Unicast Feedback 1609 [1]. The receiver MUST do so immediately after noticing and before 1610 sending any (further) RTCP feedback messages. 1612 A Group and Average Packet size sub-report block is most likely to 1613 be appended to the RSI header (either a Group size sub-report or an 1614 RTCP Bandwidth sub-report MUST be included). The Group size n 1615 allows a receiver to calculate its share of the RTCP bandwidth, r. 1616 Given R, the total available RTCP bandwidth share for receivers (in 1617 the SSM RTP session) r = R/(n). For the group size calculation, the 1618 RTP receiver MUST NOT include the Distribution Source, i.e. the only 1619 RTP receiver sending RSI packets. 1621 The Receiver RTCP Bandwidth field MAY override this value. If the 1622 Receiver RTCP Bandwidth field is present, the receiver MUST use this 1623 value as its own RTCP reporting bandwidth r. 1625 If the RTCP Bandwidth field was used by the Distribution Source in 1626 an RTCP session but this field was not included in the last five 1627 RTCP RSI reports, the receiver MUST revert to calculating its 1628 bandwidth share based upon the Group size information. 1630 If the receiver has not received any RTCP RSI packets from the 1631 Distribution Source for a period of five times the sender reporting 1632 interval, it MUST cease transmitting RTCP receiver reports until the 1633 next RTCP RSI packet is received. 1635 The receiver can use the summarized data as desired. This data is 1636 most useful in providing the receiver with a more global view of the 1637 conditions experienced by other receivers, and enables the client to 1638 place itself within the distribution and establish the extent to 1639 which its reported conditions correspond to the group reports as a 1640 whole. The appendix B (section 16) provides further information and 1641 examples of data processing at the receiver. 1643 The receiver SHOULD assume that any sub-report blocks in the same 1644 packet correspond to the same data set received by the Distribution 1645 Source during the last reporting time interval. This applies to 1646 packets with multiple blocks, where each block conveys a different 1647 range of values. 1649 A receiver MUST NOT rely on all of the RTCP packets it sends 1650 reaching the Media Senders or any other receiver. While RR 1651 statistics will be aggregated, BYE packets processed, and SSRC 1652 collisions usually be announced, processing and/or forwarding of 1653 further RTCP packets is up to the discretion of the Distribution 1654 Source and will be performed as specified in the session 1655 description. 1657 If a receiver has out-of-band information available about the Media 1658 Sender SSRC(s) used in the media session, it MUST NOT use the same 1659 SSRC for itself. The receiver MUST be aware that such out-of-band 1660 information may be outdated (i.e., that the sender SSRC(s) have 1661 changed, and MUST follow the above collision resolution procedure if 1662 necessary. 1664 RTCP with Unicast Feedback 1666 A receiver MAY use such Media Sender SSRC information when available 1667 but MUST beware of potential changes to the SSRC (which can only be 1668 learned from Sender Report (SR) packets). 1670 7.5 Media Sender Behavior 1672 Media Senders listen on a unicast or multicast transport address for 1673 RTCP reports sent by the receivers (and forwarded by the 1674 Distribution Source) or other Media Senders (optionally forwarded by 1675 the Distribution Source). 1677 Unlike in the case of the simple forwarding model, Media Senders 1678 MUST be able to process RSI packets from the Distribution Source to 1679 determine the group size and their own RTCP bandwidth share. Media 1680 Senders MUST also be capable of determining the group size (and 1681 their corresponding RTCP bandwidth share) from listening to 1682 (forwarded) RTCP RR and SR packets (as mandated in [1]). 1684 As long as they send RTP packets they MUST also send RTCP SRs as 1685 defined in [1]. 1687 A Media Sender that observes an SSRC collision with another entity 1688 that is not also a Media Sender MAY delay its own collision 1689 resolution actions as per [1] by 5*1.5*Td with Td being the 1690 deterministic calculated reporting interval for receivers to see 1691 whether the conflict still exists. SSRC collisions with other Media 1692 Senders MUST be acted upon immediately. 1694 Note: This gives precedence to Media Senders and places the 1695 burden of collision resolution on RTP receivers. 1697 Sender SSRC information MAY be communicated out-of-band, e.g., by 1698 means of SDP media descriptions. Therefore, senders SHOULD NOT 1699 eagerly change their own SSRC eagerly or unnecessarily. 1701 8. Mixer/Translator issues 1703 The original RTP specification allows a session to use mixers and 1704 translators to help connect heterogeneous networks into one session. 1705 There are a number of issues, however, which are raised by the 1706 unicast feedback model proposed in this document. The term 'mixer' 1707 refers to devices that provide data stream multiplexing where 1708 multiple sources are combined into one stream. Conversely, a 1709 translator does not multiplex streams, but simply acts as a bridge 1710 between two distribution mechanisms, e.g., a unicast-to-multicast 1711 network translator. Since the issues raised by this document apply 1712 equally to either a mixer or translator, the latter are referred to 1713 from this point onwards as mixer-translator devices. 1715 A mixer-translator between distribution networks in a session must 1716 ensure that all members in the session receive all the relevant 1717 RTCP with Unicast Feedback 1719 traffic to enable the usual operation by the clients. A typical use 1720 may be to connect an older implementation of an RTP client with an 1721 SSM distribution network, where the client is not capable of 1722 unicasting feedback to the source. In this instance the mixer- 1723 translator must join the session on behalf of the client and send 1724 and receive traffic from the session to the client. Certain hybrid 1725 scenarios may have different requirements. 1727 8.1 Use of a mixer-translator 1729 The mixer-translator MUST adhere to the SDP description [5] for the 1730 single source session (Section 11) and use the feedback mechanism 1731 indicated. Implementers of receivers SHOULD be aware, when a mixer- 1732 translator is present in the session, more than one Media Sender may 1733 be active since the mixer-translator may be forwarding traffic to 1734 the SSM receivers from either multiple unicast sources or from an 1735 ASM session. Receivers SHOULD still forward unicast RTCP reports in 1736 the usual manner to their assigned Feedback Target/Distribution 1737 Source, which -- by assumption -- in this case would be the mixer- 1738 translator itself. It is RECOMMENDED that the simple packet 1739 reflection mechanism be used under these circumstances since 1740 attempting to coordinate RSI + summarization reporting between more 1741 than one source may be complicated unless the mixer-translator is 1742 capable of summarization. 1744 8.2 Encryption and Authentication issues 1746 Encryption and security issues are discussed in detail in Section 1747 11. A mixer-translator MUST be able to follow the same security 1748 policy as the client in order to unicast RTCP feedback to the 1749 source, and it therefore MUST be able to apply the same 1750 authentication and/or encryption policy required for the session. 1751 Transparent bridging and subsequent unicast feedback to the source, 1752 where the mixer-translator is not acting as the Distribution Source, 1753 is only allowed if the mixer-translator can conduct the same source 1754 authentication as required by the receivers. A translator MAY 1755 forward unicast packets on behalf of a client, but SHOULD NOT 1756 translate between multicast-to-unicast flows towards the source 1757 without authenticating the source of the feedback address 1758 information. 1760 9. Transmission interval calculation 1762 The Control Traffic Bandwidth referred to in [1] is an arbitrary 1763 amount that is intended to be supplied by a session management 1764 application (e.g., sdr [21]) or decided based upon the bandwidth of 1765 a single sender in a session. 1767 The RTCP transmission interval calculation remains the same as in 1768 the original RTP specification [1] or uses the algorithm in [10] 1769 when bandwidth modifiers have been specified for the session. 1771 RTCP with Unicast Feedback 1773 9.1 Receiver RTCP Transmission 1775 If the Distribution Source is operating in Simple Feedback mode 1776 (which may be indicated in the corresponding session description for 1777 the media session but which the receiver also notices from the 1778 absence of RTCP RSI packets), a receiver MUST calculate the number 1779 of other members in a session based upon its own SSRC count derived 1780 from the forwarded Sender and Receiver Reports it receives. The 1781 receiver MUST calculate the average RTCP packet size from all the 1782 RTCP packets it receives. 1784 If the Distribution Source is operating in Distribution Source 1785 Feedback Summary mode, the receiver MUST use either the Group size 1786 field and the average RTCP packet size field, or the Receiver 1787 Bandwidth Field from the respective sub-report blocks appended to 1788 the RSI packet. 1790 A receiver uses these values as input to the calculation of the 1791 deterministic calculated interval as per [1] and [10]. 1793 9.2 Distribution Source RTCP Transmission 1795 If operating in Simple Feedback mode, the Distribution Source MUST 1796 calculate the transmission interval for its Receiver Reports and 1797 associated RTCP packets based upon the above control traffic 1798 bandwidth and MUST count itself as RTP receiver. Receiver Reports 1799 will be forwarded as they arrive without further consideration. The 1800 Distribution Source MAY choose to validate that all or selected 1801 receivers roughly adhere to the calculated bandwidth constraints and 1802 MAY choose to drop excess packets for receivers that do not. In all 1803 cases, the average RTCP packet size is determined from the Media 1804 Senders' and receivers' RTCP packets forwarded and those originated 1805 by the Distribution Source. 1807 If operating in Distribution Source Feedback Summary mode, the 1808 Distribution Source does not share the forward RTCP bandwidth with 1809 any of the receivers. Therefore, the Distribution Source SHOULD use 1810 the full RTCP bandwidth for its receiver reports and associated RTCP 1811 packets, as well as RTCP RSI packets. In this case, the average 1812 RTCP packet size is only determined from the RTCP packets originated 1813 by the Distribution Source. 1815 The Distribution Source uses these values as input to the 1816 calculation of the deterministic calculated interval as per [1] and 1817 [10]. 1819 9.3 Media Senders RTCP Transmission 1821 In Simple Feedback Mode, the Media Senders obtain all RTCP SRs and 1822 RRs as they would in an ASM session, except that the packets are 1823 RTCP with Unicast Feedback 1825 forwarded by the Distribution Source. They MUST perform their RTCP 1826 group size estimate and calculation of the deterministic 1827 transmission interval as per [1] and [10]. 1829 In Distribution Source Feedback Summary Mode, the Media Senders 1830 obtain all RTCP SRs as they would in an ASM session. They receive 1831 either RTCP RR reports as in ASM (in case these packets are 1832 forwarded by the Distribution Source) or RSI packets containing 1833 summaries. In the former case, they MUST perform their RTCP group 1834 size estimate and calculation of the deterministic transmission 1835 interval as per [1] and [10]. In the latter case, they MUST combine 1836 the information obtained from the Sender Reports and the RSI packets 1837 to create a complete view of the group size and the average RTCP 1838 packet size and perform the calculation of the deterministic 1839 transmission interval as per [1] and [10] based upon these input 1840 values. 1842 9.4 Operation in conjunction with AVPF and SAVPF 1844 If the RTP session is an AVPF session [15] or an SAVPF session [28] 1845 (as opposed to a regular AVP [6] session) the receivers MAY modify 1846 their RTCP report scheduling as defined in [15]. Use of AVPF or 1847 SAVPF does not affect the Distribution Source's RTCP transmission or 1848 forwarding behavior. 1850 It is RECOMMENDED that a Distribution Source and possible separate 1851 Feedback Target(s) be configured to forward AVPF/SAVPF-specific RTCP 1852 packets in order not to counteract the damping mechanism built into 1853 AVPF; optionally, they MAY aggregate the feedback information from 1854 the receivers as per section 7.2.2. If only generic feedback 1855 packets are in use that are understood by the Distribution Source 1856 and that can easily be aggregated, the Distribution MAY combine 1857 several incoming RTCP feedback packets and forward the aggregate 1858 along with its next RTCP RR/RSI packet. In any case, the 1859 Distribution Source and Feedback Target(s) SHOULD minimize the extra 1860 delay when forwarding feedback information but the Distribution 1861 Source MUST stay within its RTCP bandwidth constraints. 1863 In the event that specific APP packets without a format and 1864 summarization mechanism understood by the Feedback Target(s) and/or 1865 the Distribution Source are to be used, it is RECOMMENDED that such 1866 packets are forwarded with minimal delay. Otherwise, the capability 1867 of receiver to send timely feedback messages is likely to be 1868 affected. 1870 10. SDP Extensions 1872 The Session Description Protocol (SDP) [5] is used as a means to 1873 describe media sessions in terms of their transport addresses, 1874 codecs, and other attributes. Signaling that RTCP feedback will be 1875 provided via unicast as specified in this document requires another 1876 session parameter in the session description. Similarly, other SSM 1877 RTCP with Unicast Feedback 1879 RTCP feedback parameters need to be provided, such as the 1880 summarization mode at the sender and the target unicast address to 1881 which to send feedback information. This section defines the SDP 1882 parameters that are needed by the proposed mechanisms in this 1883 document (and that also need to be registered with IANA). 1885 10.1 SSM RTCP Session Identification 1887 A new session level attribute MUST be used to indicate the use of 1888 unicast instead of multicast feedback: "rtcp-unicast". 1890 This attribute uses one parameter to specify the mode of operation. 1891 An optional set of parameters specifies the behavior for RTCP packet 1892 types (and subtypes). 1894 rtcp-unicast:reflection 1896 This attribute MUST be used to indicate the "Simple Feedback" 1897 mode of operation where packet reflection is used by the 1898 Distribution Source (without further processing). 1900 rtcp-unicast:rsi *(SP :]) 1902 This attribute MUST be used to indicate the "Distribution 1903 Source Feedback Summary" mode of operation. In this mode, a 1904 list or parameters may be used to explicitly specify how RTCP 1905 packets originated by receivers are handled. Options for 1906 processing a given RTCP packet type are: 1908 aggr: The Distribution Source has means for aggregating the 1909 contents of the RTCP packets and will do so. 1911 forward: The Distribution Source will forward the RTCP packet 1912 unchanged. 1914 term: The Distribution Source will terminate the RTCP 1915 packet. 1917 The default rules applying if no parameters are specified are as 1918 follows: 1920 RR and SDES packets MUST be aggregated and MUST lead to RSI 1921 packets being generated. All other RTP packets MUST be 1922 terminated at the Distribution Source (or Feedback Target(s)). 1924 The SDP description needs only specify deviations from the 1925 default rules. Aggregation of RR packets and forwarding of SR 1926 packet MUST NOT be changed. 1928 The token for the new SDP attribute is "rtcp-unicast" and the formal 1929 SDP ABNF syntax for the new attribute value is as follows: 1931 att-value = "reflection" 1932 RTCP with Unicast Feedback 1934 / "rsi" *(SP rsi-rule) 1936 rsi-rule = processing ":" rtcp-type 1938 processing = "aggr" / "forward" / "term" / token ;keep it extensible 1940 rtcp-type = 3*3DIGIT ;the RTCP type (192, 193, 202--208) 1942 10.2 SSM Source Specification 1944 In a Source-Specific Multicast RTCP session, the address of the 1945 Distribution Source needs to be indicated both for source-specific 1946 joins to the multicast group, and for addressing unicast RTCP 1947 packets on the backchannel from receivers to the Distribution 1948 Source. 1950 This is achieved by following the proposal for SDP source filters 1951 documented in [4]. According to the specification, for SSM RTCP only 1952 the inclusion mode ("a=source-filter:incl") MUST be used. 1954 There SHOULD be exactly one "a=source-filter:incl" attribute listing 1955 the address of the Distribution Source. The RTCP port MUST be 1956 derived from the m= line of the media description. 1958 An alternative Feedback Target address and port MAY be supplied 1959 using the SDP RTCP attribute [7], e.g., a=rtcp: IN IP4 1960 192.0.2.1. This attribute only defines the transport address of the 1961 Feedback Target and does not affect the SSM group specification for 1962 media stream reception. 1964 Two "source-filter" attributes MAY be present to indicate an IPv4 1965 and an IPv6 representation of the same Distribution Source. 1967 10.3 RTP Source Identification 1969 The SSRC information for the Media Sender(s) MAY be communicated 1970 explicitly out of band (i.e., outside the RTP session). One option 1971 for doing so is the Session Description Protocol (SDP) [5]. If such 1972 an indication is desired, the "ssrc" attribute [12] MUST be used for 1973 this purpose. As per [12], the "cname" Source Attribute MUST be 1974 present. Further Source Attributes MAY be specified as needed. 1976 If used in an SDP session description of an RTCP-SSM session, the 1977 ssrc MUST contain the SSRC intended to be used by the respective 1978 Media Sender and the cname MUST equal the CNAME for the Media 1979 Sender. If present, the role SHOULD indicate the function of the 1980 RTP entity identified by this line for which presently only the 1981 "media-sender" is defined. 1983 Example: 1985 a=ssrc:314159 cname:iptv-sender@example.com 1986 RTCP with Unicast Feedback 1988 In the above example, the Media Sender is identified to use the SSRC 1989 identifier 314159 and the CNAME iptv-sender@example.com. 1991 11. Security Considerations 1993 The level of security provided by the current RTP/RTCP model MUST 1994 NOT be diminished by the introduction of unicast feedback to the 1995 source. This section identifies the security weaknesses introduced 1996 by the feedback mechanism, potential threats, and level of 1997 protection that MUST be adopted. Any suggestions on increasing the 1998 level of security provided to RTP sessions above the current 1999 standard are RECOMMENDED but OPTIONAL. The final section outlines 2000 some security frameworks that are suitable to conform to this 2001 specification. 2003 11.1 Assumptions 2005 RTP/RTCP is a protocol that carries real-time multimedia traffic, 2006 and therefore a main requirement is for any security framework to 2007 maintain as low overhead as possible. This includes the overhead of 2008 different applications and types of cryptographic operations, as 2009 well as the overhead to deploy or to create security infrastructure 2010 for large groups. 2012 Although the distribution of session parameters, typically encoded 2013 as SDP objects, through SAP [22], e-mail, or the web, is beyond the 2014 scope of this document, it is RECOMMENDED that the distribution 2015 method employs adequate security measures to ensure the integrity 2016 and authenticity of the information. Suitable solutions that meet 2017 the security requirements outlined here are included at the end of 2018 this section. 2020 In practice, the multicast and group distribution mechanism, e.g., 2021 the SSM routing tree, is not immune to source IP address spoofing or 2022 traffic snooping, however such concerns are not discussed here. In 2023 all the following discussions, security weaknesses are addressed 2024 from the transport level or above. 2026 11.2 Security threats 2028 Attacks on media distribution and the feedback architecture proposed 2029 in this document may take a variety of forms. An outline of the 2030 types of attacks in detail: 2032 a) Denial of Service (DoS) 2034 DoS is a major area of concern. Due to the nature of the 2035 communication architecture a DoS can be generated in a number of 2036 ways by using the unicast feedback channel to the attacker's 2037 advantage. 2039 RTCP with Unicast Feedback 2041 b) Packet Forgery 2043 Another potential area for attack is packet forgery. In 2044 particular, it is essential to protect the integrity of certain 2045 influential packets since compromise could directly affect the 2046 transmission characteristics of the whole group. 2048 c) Session Replay 2050 The potential for session recording and subsequent replay is an 2051 additional concern. An attacker may not actually need to 2052 understand packet content, but simply have the ability to record 2053 the data stream and, at a later time, replay it to any receivers 2054 that are listening. 2056 d) Eavesdropping on a session 2058 The consequences of an attacker eavesdropping on a session 2059 already constitutes a security weakness; in addition, 2060 eavesdropping might facilitate other types of attacks, and is 2061 therefore considered a potential threat. For example, an attacker 2062 might be able to use the eavesdropped information to perform an 2063 intelligent DoS attack. 2065 11.3 Architectural Contexts 2067 To better understand the requirements of the solution, the threats 2068 outlined above are addressed for each of the three communication 2069 contexts: 2071 a) Source-to-Receiver communication 2073 The downstream communication channel, from the source to the 2074 receivers, is critical to protect as it controls the behavior of 2075 the group; it conveys the bandwidth allocation for each receiver 2076 and hence the rate at which the RTCP traffic is unicast directly 2077 back to the source. All traffic that is distributed over the 2078 downstream channel is generated by a single source. Both the RTP 2079 data stream and the RTCP control data from the source are 2080 included in this context, with the RTCP data generated by the 2081 source being indirectly influenced by the group feedback. 2083 The downstream channel is vulnerable to four types of attacks. A 2084 denial of service attack is possible, but less of a concern. The 2085 worst case effect would be the transmission of large volumes of 2086 traffic over the distribution channel with the potential to reach 2087 every receiver, but only on a one-to-one basis. Consequently, 2088 this threat is no more pronounced than the current multicast ASM 2089 model. The real danger of denial of service attacks in this 2090 context comes indirectly via compromise of the source RTCP 2091 traffic. If receivers are provided with an incorrect group size 2092 estimate or bandwidth allowance, the return traffic to the source 2093 RTCP with Unicast Feedback 2095 may create a distributed DoS effect on the source. Similarly, an 2096 incorrect feedback address whether as a result of a malicious 2097 attack or by mistake, e.g., an IP address configuration (e.g., 2098 typing) error, could directly create a denial of service attack 2099 on another host. 2101 An additional concern relating to Denial of Service attacks would 2102 come indirectly through the generation of fake BYE packets 2103 causing the source to adjust the advertised group size. A 2104 Distribution Source MUST follow the correct rules for timing out 2105 members in a session prior to reporting a change in the group 2106 size, which allows the authentic SSRC sufficient time to continue 2107 to report and consequently cancel the fake BYE report. 2109 The danger of Packet Forgery in the worst case may be to 2110 maliciously instigate a denial of service attack, e.g., if an 2111 attacker were capable of spoofing the source address and 2112 injecting incorrect packets into the data stream or intercepting 2113 the source RTCP traffic and modifying the fields. 2115 The Replay of a Session would have the effect of recreating the 2116 receiver feedback to the source address at a time when the source 2117 is not expecting additional traffic from a potentially large 2118 group. The consequence of this type of attack may be less 2119 effective on its own, but in combination with other attacks might 2120 be serious. 2122 Eavesdropping on the session would provide an attacker with 2123 information on the characteristics of the source-to-receiver 2124 traffic such as the frequency of RTCP traffic. If RTCP traffic is 2125 unencrypted, this might also provide valuable information on 2126 characteristics such as group size, Media Source SSRC(s) and 2127 transmission characteristics of the receivers back to the source. 2129 b) Receiver-to-Distribution-Source communication 2131 The second context is the return traffic from the group to the 2132 Distribution Source. This traffic should only consist of RTCP 2133 packets, and should include receiver reports, SDES information, 2134 BYE reports, extended reports (XR), feedback messages (RTPFB, 2135 PSFB) and possibly Application specific packets. The effects of 2136 compromise on a single or subset of receivers are not likely to 2137 have as great an impact as in context (a), however much of the 2138 responsibility for detecting compromise of the source data stream 2139 relies on the receivers. 2141 The effects of compromise of critical Distribution Source control 2142 information can be seriously amplified in the present context. A 2143 large group of receivers may unwittingly generate a distributed 2144 DoS attack on the Distribution Source in the event that the 2145 integrity of the source RTCP channel has been compromised and the 2146 compromise is not detected by the individual receivers. 2148 RTCP with Unicast Feedback 2150 An attacker capable of instigating a Packet Forgery attack could 2151 introduce false RTCP traffic and create fake SSRC identifiers. 2152 Such attacks might slow down the overall control channel data 2153 rate, since an incorrect perception of the group size may be 2154 created. Similarly, the creation of fake BYE reports by an 2155 attacker would cause some group size instability, but should not 2156 be effective as long as the correct timeout rules are applied by 2157 the source in removing SSRC entries from its database. 2159 A replay attack on receiver return data to the source would have 2160 the same implications as the generation of false SSRC identifiers 2161 and RTCP traffic to the source. Therefore, ensuring authenticity 2162 and freshness of the data source is important. 2164 Eavesdropping in this context potentially provides an attacker 2165 with a great deal of potentially personal information about a 2166 large group of receivers available from SDES packets. It would 2167 also provide an attacker with information on group traffic 2168 generation characteristics and parameters for calculating 2169 individual receiver bandwidth allowances. 2171 c) Receiver-to-Feedback-Target communication 2173 The third context is the return traffic from the group to the 2174 Feedback Target. It suffers from the same threats as the 2175 receiver-to-source context, with the difference being that now a 2176 large group of receivers may unwittingly generate a distributed 2177 DoS attack (DDos) on the Feedback Target, where it is impossible 2178 to discern if the DDoS is deliberate or due merely to a 2179 misconfiguation of the feedback target address. While deliberate 2180 attacks can be mitigated by properly authenticating messages 2181 communicating the feedback target address -- i.e., the SDP 2182 session description and the Feedback Target Address sub-report 2183 block carried in RTCP --, a misconfigured address will originate 2184 from an authenticated source and hence cannot be prevented using 2185 security mechanisms. 2187 Furthermore, the Feedback Target is unable to communicate its 2188 predicament with either the session Source nor the session 2189 receivers. From the feedback packets received, the Feedback 2190 Target cannot tell the SSM multicast group the feedback belongs 2191 to nor the Distribution Source, making further analysis and 2192 suppression difficult. The Feedback Target may not even support 2193 RTCP or listen on the port number in question. 2195 Note that because the DDoS occurs inside of the RTCP session, and 2196 because the unicast receivers adhere to transmission interval 2197 calculations [1][10], the bandwidth misdirected toward the 2198 Feedback Target in the misconfigured case will be limited to a 2199 percentage of the session bandwidth, i.e., the Control Traffic 2200 Bandwidth established for the session. 2202 11.4 Requirements in each context 2203 RTCP with Unicast Feedback 2205 To address these threats, this section presents the security 2206 requirements for each context. 2208 a) The main threat in the source-to-receiver context concerns denial 2209 of service attacks through possible packet forgery. The forgery 2210 may take the form of interception and modification of packets 2211 from the source, or simply injecting false packets into the 2212 distribution channel. To combat these attacks, data integrity and 2213 source authenticity MUST be applied to source traffic. Since the 2214 consequences of eavesdropping do not affect the operation of the 2215 protocol, confidentiality is not a requirement in this context. 2216 However without confidentiality, access to personal and group 2217 characteristics information would be unrestricted to an external 2218 listener. Therefore confidentiality is RECOMMENDED. 2220 b) The threats in the receiver-to-source context also concern the 2221 same kinds of attacks but are considered less important than the 2222 downstream traffic compromise. All the security weaknesses are 2223 also applicable to the current RTP/RTCP security model and 2224 therefore only recommendations are made towards protection from 2225 compromise. Data integrity is RECOMMENDED to ensure that 2226 interception and modification of an individual receiver's RTCP 2227 traffic can be detected. This would protect against the false 2228 influence of group control information and the potentially more 2229 serious compromise of future services provided by the 2230 distribution functionality. In order to ensure security, data 2231 integrity and authenticity of receiver traffic is therefore also 2232 RECOMMENDED. The same situation applies as in the first context 2233 with respect to data confidentiality, and it is RECOMMENDED that 2234 precautions should be taken to protect the privacy of the data. 2236 c) The threats to the receiver-to-feedback-target context are 2237 similar to those in the receiver-to-source context, and thus the 2238 recommendations to protect against them are similar. 2240 However there are a couple situations with broader issues to 2241 solve, which are beyond the scope of this document. 2243 1. An endpoint experiencing DDoS or the side-effects of a 2244 misconfigured RTCP session may not even be a participant in 2245 the session, i.e., may not be listening on the respective port 2246 number and may even support RTCP, so it will be unable to 2247 react within RTCP. Determining that there is a problem will be 2248 up to network administrators and possibly anti-malware 2249 software that can perform correlation across receiver nodes. 2251 2. With misconfiguration, unfortunately the normally desirable 2252 usage of SRTP and SRTCP becomes undesirable. Because the 2253 packet content is encrypted, neither the misconfigured 2254 Feedback Target nor the network administrator have the ability 2255 to determine the root cause of the traffic. 2257 In the case where the misconfigured Feedback Target happens to be 2258 a node participating in the session or is an RTCP-enabled node, 2259 RTCP with Unicast Feedback 2261 the Feedback Target Address block provides a dynamic mechanism 2262 for the Distribution Source to signal an alternative unicast RTCP 2263 feedback address to the receivers. As this type of packet MUST be 2264 included in every RTCP packet originated by the Distribution 2265 Source, all receivers would be able to obtain the corrected 2266 Feedback Target information. In this manner, receiver behavior 2267 should remain consistent even in the face of packet loss or when 2268 there are late session arrivals. The only caveat is that the 2269 misconfigured Feedback Target is largely uninvolved in the repair 2270 of this situation, and thus relies on others for the detection of 2271 the problem. 2273 An additional security consideration that is not a component of this 2274 specification but has a direct influence upon the general security 2275 is the origin of the session initiation data. This involves the SDP 2276 parameters that are communicated to the members prior to the start 2277 of the session via channels such as an HTTP server, email, SAP, or 2278 other means. It is beyond the scope of this document to place any 2279 strict requirements on the external communication of such 2280 information, however suitably secure SDP communication approaches 2281 are outlined in section 11.7. 2283 11.5 Discussion of trust models 2285 As identified in the previous sections, source authenticity is a 2286 fundamental requirement of the protocol. However, it is important to 2287 also clarify the model of trust that would be acceptable to achieve 2288 this requirement. There are two fundamental models that apply in 2289 this instance: 2291 a) The shared- key model where all authorized group members share 2292 the same key and can equally encrypt/decrypt the data. This 2293 method assumes that an out-of-band method is applied to the 2294 distribution of the shared group key ensuring that every key- 2295 holder is individually authorized to receive the key, and in the 2296 event of member departures from the group, a re-keying exercise 2297 can occur. The advantage of this model is that the costly 2298 processing associated with one-way key authentication techniques 2299 is avoided, as well as the need to execute additional cipher 2300 operations with alternative key sets on the same data set, e.g., 2301 in the event that data confidentiality is also applied. The 2302 disadvantage is that, for very large groups where the receiver 2303 set becomes effectively untrusted, a shared key does not offer 2304 much protection. 2306 b) The public-key authentication model, using cryptosystems such as 2307 RSA-based or PGP authentication, provides a more secure method of 2308 source authentication at the expense of generating higher 2309 processing overhead. This is typically not recommended for Real- 2310 time data streams, but in the case of RTCP reports which are 2311 distributed with a minimum interval of 5 seconds, this may be a 2312 viable option (the processing overhead might still be too great 2313 for small, low-powered devices and should therefore be considered 2314 RTCP with Unicast Feedback 2316 with caution). Wherever possible, however, the use of public key 2317 source authentication is preferable to the shared key model 2318 identified above. 2320 As concerns requirements for protocol acceptability, either model is 2321 acceptable, although it is RECOMMENDED that the more secure public- 2322 key based options should be applied wherever possible. 2324 11.6 Recommended security solutions 2326 This section presents some existing security mechanisms that are 2327 RECOMMENDED to suitably address the requirements outlined in section 2328 11.5. This is only intended as a guideline and it is acknowledged 2329 that there are other solutions that would also be suitable to be 2330 compliant with the specification. 2332 11.6.1 Secure Distribution of SDP Parameters 2334 a) SAP, HTTPS, Email -- Initial distribution of the SDP parameters 2335 for the session SHOULD use a secure mechanism such as the SAP 2336 authentication framework which allows an authentication 2337 certificate to be attached to the session announcements. Other 2338 methods might involve HTTPS or signed email content from a 2339 trusted source. However, some more commonly used techniques for 2340 distributing session information and starting media streams are 2341 RTSP [25] and SIP [14]. 2343 b) RTSP -- RTSP provides a client or server initiated stream control 2344 mechanism for real-time multimedia streams. The session 2345 parameters are conveyed using SDP syntax and may adopt standard 2346 HTTP authentication mechanisms in combination with suitable 2347 network (e.g. IPsec) or transport (e.g. TLS) level security. 2349 c) SIP -- A typical use of SIP involving a unicast feedback 2350 identifier might be a client wishing to dynamically join a multi- 2351 party call on a multicast address using unicast RTCP feedback. 2352 The client would be required to authenticate the SDP session 2353 descriptor information returned by the SIP server. The 2354 recommended method for this, as outlined in the SIP specification 2355 [14], is to use an S/MIME message body containing the session 2356 parameters signed with an acceptable certificate. 2358 For the purposes of this profile, it is acceptable to use any 2359 suitably secure authentication mechanism which establishes the 2360 identity and integrity of the information provided to the client. 2362 11.6.2 Suitable Security Solutions for RTP Sessions with Unicast 2363 Feedback 2365 a) SRTP -- SRTP [3] is the recommended AVT security framework for 2366 RTP sessions. It specifies the general packet formats and cipher 2367 RTCP with Unicast Feedback 2369 operations that are used, and provides the flexibility to select 2370 different stream ciphers based on preference/requirements. It can 2371 provide confidentiality of the RTP and RTCP packets as well as 2372 protection against integrity compromise and replay attacks. It 2373 provides authentication of the data stream using the shared- key 2374 trust model. Any suitable key-distribution mechanism can be used in 2375 parallel to the SRTP streams. 2377 b) IPSEC -- A more general group security profile which might be 2378 used is the Group Domain of Interpretation [23], which defines the 2379 process of applying IPSec mechanisms to multicast groups. This 2380 requires the use of ESP in tunnel mode as the framework and it 2381 provides the capability to authenticate either using a shared key or 2382 individually through public-key mechanisms. It should be noted that 2383 using IPSec would break the 'transport independent' condition of RTP 2384 and would therefore not be useable for anything other than IP based 2385 communication. 2387 c) TESLA - TESLA [24] is a scheme that provides a more flexible 2388 approach to data authentication using time-based key disclosure. The 2389 authentication uses one-way pseudo-random key functions based on key 2390 chain hashes that have a short period of authenticity based on the 2391 key disclosure intervals from the source. As long as the receiver 2392 can ensure that the encrypted packet is received prior to the key 2393 disclosure by the source, this requires loose time synchronization 2394 between source and receivers, it can prove the authenticity of the 2395 packet. The scheme does introduce a delay into the packet 2396 distribution/decryption phase due to the key disclosure delay 2397 however the processing overhead is much lower than other standard 2398 public-key mechanisms and therefore may be more suited to small or 2399 energy-restricted devices. 2401 11.6.3 Secure Key Distribution Mechanisms 2403 a) MIKEY -- MIKEY [29] is the preferred solution for SRTP sessions 2404 providing a shared group key distribution mechanism and intra- 2405 session rekeying facilities. If a partly protected communication 2406 channel exists, keys may also be conveyed using SDP as per [27]. 2408 b) GSAKMP -- GSAKMP is the general solution favored for Multicast 2409 Secure group key distribution. It is the recommended key 2410 distribution solution for GDOI sessions. 2412 11.7 Troubleshooting Misconfiguration 2414 As noted above, the security mechanisms in place will not help in 2415 case an authorized source spreads properly authenticated and integer 2416 yet incorrect information about the Feedback Target. In this case, 2417 the accidentally communicated Feedback Target will receive a RTCP 2418 packets from a potentially large group of receiver, the RTCP rate 2419 fortunately limited by the RTCP timing rules. 2421 RTCP with Unicast Feedback 2423 Yet, the RTCP packets do not provide much context information and, 2424 if encrypted, do not provide any context making it difficult for the 2425 entity running the (network with) the Feedback Target to debug and 2426 correct this problem, e.g., by tracking down and informing the 2427 origin of the misconfiguration. 2429 One suitable approach may be to provide explicit context information 2430 in RTCP packets that would allow determining the source. While such 2431 an RTCP packet could be defined in this specification, it would be 2432 of no use when using SRTP/SRTCP and encryption of RTCP reports. 2433 Therefore, and because the extensions in this document may not be 2434 the only case that may face such a problem, it is desirable find a 2435 solution that is applicable to RTP at large. Such mechanisms are 2436 for further study in the AVT WG. 2438 12. Backwards Compatibility 2440 The use of unicast feedback to the source should not present any 2441 serious backwards compatibility issues. The RTP data streams should 2442 remain unaffected, as are the RTCP packets from the Media Sender(s) 2443 that continue to enable inter-stream synchronization in the case of 2444 multiple streams. The unicast transmission of RTCP data to a source 2445 that does not have the ability to redistribute the traffic either by 2446 simple reflection or through summaries could have serious security 2447 implications as outlined in Section 11, but would not actually break 2448 the operation of RTP. For RTP-compliant receivers that do not 2449 understand the unicast mechanisms, the RTCP traffic may still reach 2450 the group, in the event that an ASM distribution network is used, in 2451 which case there may be some duplication of traffic due to the 2452 reflection channel, but this should be ignored. It is anticipated, 2453 however, that typically the distribution network will not enable the 2454 receiver to multicast RTCP traffic, in which case the data will be 2455 lost, and the RTCP calculations will not include those receivers. It 2456 is RECOMMENDED that any session that may involve non-unicast capable 2457 clients should always use the simple packet reflection mechanism to 2458 ensure that the packets received can be understood by all clients. 2460 13. IANA Considerations 2462 The following contact information shall be used for all 2463 registrations included here: 2465 Contact: Joerg Ott 2466 mailto:jo@acm.org 2467 tel:+358-9-451-2460 2469 Based on the guidelines suggested in [2], this document proposes 1 2470 new RTCP packet format to be registered with the RTCP Control Packet 2471 type (PT) Registry: 2473 RTCP with Unicast Feedback 2475 Name: RSI 2476 Long name: Receiver Summary Information 2477 Value: 208 2478 Reference: This document. 2480 This document defines a substructure for RTCP RSI packets. A new 2481 sub-registry needs to be set up for the sub-report block type (SRBT) 2482 values for the RSI packet, with the following registrations created 2483 initially: 2485 Name: IPv4 Address 2486 Long name: IPv4 Feedback Target Address 2487 Value: 0 2488 Reference: This document. 2490 Name: IPv6 Address 2491 Long name: IPv6 Feedback Target Address 2492 Value: 1 2493 Reference: This document. 2495 Name: DNS Name 2496 Long name: DNS Name indicating Feedback Target Address 2497 Value: 2 2498 Reference: This document. 2500 Name: Loss 2501 Long name: Loss distribution 2502 Value: 4 2503 Reference: This document. 2505 Name: Jitter 2506 Long name: Jitter Distribution 2507 Value: 5 2508 Reference: This document. 2510 Name: RTT 2511 Long name: Round-trip time distribution 2512 Value: 6 2513 Reference: This document. 2515 Name: Cumulative loss 2516 Long name: Cumulative loss distribution 2517 Value: 7 2518 Reference: This document. 2520 Name: Collisions 2521 Long name: SSRC Collision list 2522 Value: 8 2523 Reference: This document. 2525 RTCP with Unicast Feedback 2527 Name: Stats 2528 Long name: General statistics 2529 Value: 10 2530 Reference: This document. 2532 Name: RTCP BW 2533 Long name: RTCP Bandwidth indication 2534 Value: 11 2535 Reference: This document. 2537 Name: Group Info 2538 Long name: RTCP Group and Average Packet size 2539 Value: 12 2540 Reference: This document. 2542 The value 3 shall be reserved for a further way of specifying a 2543 feedback target address. The value 3 MUST only be allocated for a 2544 use defined in an IETF Standards Track document. 2546 Further values may be registered on a first-come first-serve 2547 basis. For each new registration, it is mandatory that a 2548 permanent, stable, and publicly accessible document exists that 2549 specifies the semantics of the registered parameter as well as the 2550 syntax and semantics of the associated sub-report block. The 2551 general registration procedures of [5] apply. 2553 In the registry for SDP parameters, the attribute names "unicast- 2554 rtcp" need to be registered as follows: 2556 SDP Attribute ("att-field"): 2558 Attribute Name: unicast-rtcp 2559 Long form: RTCP Unicast feedback address 2560 Type of name: att-field 2561 Type of attribute: Media level only 2562 Subject to charset: No 2563 Purpose: RFC XXXX 2564 Reference: RFC XXXX 2565 Values: See this document. 2567 14. Bibliography 2569 14.1 Normative References 2571 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP - 2572 A Transport Protocol for Real-time Applications," RFC 3550 (STD 2573 64), July 2003. 2575 [2] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 2576 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 2578 RTCP with Unicast Feedback 2580 [3] M. Baugher, D. McGrew, D. Oran, R. Blom, E. Carrara, M. Naslund, 2581 and K. Norrman, "The Secure Real Time Transport Protocol", RFC 2582 3711, March 2004. 2584 [4] B. Quinn, R. Finlayson, "SDP Source-Filters", RFC 4570, July 2585 2006. 2587 [5] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session 2588 Description Protocol", RFC 4566, July 2006. 2590 [6] H. Schulzrinne, S. Casner, "RTP Profile for Audio and Video 2591 Conferences with Minimal Control", RFC 3551 (STD 65), July 2003. 2593 [7] C. Huitema, "RTCP Attribute in SDP", RFC 3605, October 2003. 2595 [8] D. Meyer, R. Rockell, G. Shepherd, "Source-Specific Protocol 2596 Independent Multicast in 232/8", RFC 4608, August 2006. 2598 [9] H. Holbrook, B. Cain, B. Haberman, "Using Internet Group 2599 Management Protocol Version 3 (IGMPv3) and Multicast Listener 2600 Discovery Protocol Version 2 (MLDv2) for Source-Specific 2601 Multicast", RFC 4604, August 2006. 2603 [10] S. Casner, "Session Description Protocol (SDP) Bandwidth 2604 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 2605 July 2003. 2607 [11] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2608 3629, November 2003. 2610 [12] J. Lennox, J. Ott, and T, Schierl, "Source-specific Media 2611 Attributes in the Session Description Protocol (SDP)," RFC 5576, 2612 June 2009. 2614 [13] Bradner, S, "Key words for use in RFCs to Indicate Requirement 2615 Levels," RFC 2119, March 1997. 2617 14.2 Informative References 2619 [14] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 2620 Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session 2621 Initiation Protocol", RFC 3261, June 2002. 2623 [15] J. Ott, S. Wenger, N. Sato, C. Burmeister, and J. Rey, " 2624 Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", RFC 2625 4585, July 2006. 2627 [16] Pusateri, T, "Distance Vector Multicast Routing Protocol", 2628 Internet Draft draft-ietf-idmr-dvmrp-v3-11.txt, Work in 2629 Progress, October 2003. 2631 [17] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 2632 Independent Multicast - Sparse Mode (PIM-SM): Protocol 2633 Specification (Revised)", RFC 4601, August 2006. 2635 RTCP with Unicast Feedback 2637 [18] Adams, A, Nicholas, J, Siadak, W, "Protocol Independent 2638 Multicast- Dense Mode (PIM-DM)", RFC 3973, January 2005. 2640 [19] Bates, T, Chandra, R, Katz, D, Rekhter, Y, "Multiprotocol 2641 Extension of BGP-4", RFC 4760, January 2007. 2643 [20] D. Meyer, B. Fenner, "Multicast Source Discovery Protocol 2644 (MSDP)", Experimental RFC 3618, October 2003. 2646 [21] Session Directory Rendez-vous (SDR), developed at University 2647 College London by Mark Handley and the Multimedia Research 2648 Group, http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/. 2650 [22] M. Handley, C. Perkins, E. Whelan, "Session Announcement 2651 Protocol (SAP)", RFC 2974, October 2000. 2653 [23] M. Baugher, T. Hardjono, H. Harney, and B. Weis, "The Group 2654 Domain of Interpretation", RFC 3547, July 2003. 2656 [24] A. Perrig, D. Song, R. Canetti, D. Tygar, B. Briscoe, "TESLA: 2657 Multicast Source Authentication Transform Introduction", RFC 2658 4082, June 2005. 2660 [25] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming 2661 Protocol (RTSP)", RFC 2326, April 1998. 2663 [26] T. Friedman, R. Caceres, and A. Clark (eds), "RTCP Reporting 2664 Extensions", RFC 3611, November 2003. 2666 [27] F. Andreasen, M. Baugher, and D. Wing, "Session Description 2667 Protocol Security Descriptions for Media Streams", RFC 4568, 2668 July 2006. 2670 [28] J. Ott and E. Cararra, "Extended Secure RTP Profile for RTCP- 2671 based Feedback (RTP/SAVPF)", RFC 5124, February 2008. 2673 [29] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman, 2674 "MIKEY: Multimedia Internet Keying", RFC 3830, August 2004. 2676 RTCP with Unicast Feedback 2678 15. Appendix A: Examples for Sender Side Configurations 2680 This appendix describes a few common setups focusing on the 2681 contribution side, i.e., the communications between the Media 2682 Sender(s) and the Distribution Source. In all cases, the same 2683 session description may be used for the distribution side as defined 2684 in the main part of this document. This is because this 2685 specification defines only the media stream setup between the 2686 Distribution Source and the receivers. 2688 15.1 One Media Sender identical to the Distribution Source 2690 In the simplest case, the Distribution Source is identical to the 2691 Media Sender as depicted in figure 2. Obviously, no further 2692 configuration for the interaction between the Media Sender and the 2693 Distribution Source is necessary. 2695 Source-specific 2696 +--------+ Multicast 2697 | | +----------------> R(1) 2698 |M D S | | | 2699 |E I O | +--+ | 2700 |D S U | | | | 2701 |I T R | | +-----------> R(2) | 2702 |A R C |->+----- : | | 2703 | = I E | | +------> R(n-1) | | 2704 |S B | | | | | | 2705 |E U | +--+--> R(n) | | | 2706 |N T | | | | | 2707 |D I |<---------+ | | | 2708 |E O |<---------------+ | | 2709 |R N |<--------------------+ | 2710 | |<-------------------------+ 2711 +--------+ Unicast 2713 Figure 2: Media Source == Distribution Source 2715 15.2 One Media Sender 2717 In a slightly more complex scenario, the Media Sender and the 2718 Distribution Source are separate entities running on the same or 2719 different machines. Hence, the Media Sender needs to deliver the 2720 media stream(s) to the Distribution Source. This can be done 2721 either via unicasting the RTP stream, via ASM multicast, or via 2722 SSM. In this case, the Distribution Source is responsible for 2723 forwarding the RTP packets comprising the media stream and the 2724 RTCP sender reports towards the receivers and conveying feedback 2725 from the receivers, as well as from itself, to the Media Sender. 2727 This scenario is depicted in figure 3. The communication setup 2728 between the Media Sender and the Distribution Source may be 2729 statically configured or SDP may be used in conjunction with some 2730 signaling protocol to convey the session parameters. Note that it 2731 RTCP with Unicast Feedback 2733 is a local configuration matter of the Distribution Source how to 2734 associate a session between the Media Sender and itself (the 2735 Contribution session) with the corresponding session between 2736 itself and the receivers (the Distribution session). 2738 Source-specific 2739 +-----+ Multicast 2740 | | +----------------> R(1) 2741 | D S | | | 2742 | I O | +--+ | 2743 | S U | | | | 2744 +--------+ | T R | | +-----------> R(2) | 2745 | Media |<---->| R C |->+----- : | | 2746 | Sender | | I E | | +------> R(n-1) | | 2747 +--------+ | B | | | | | | 2748 | U | +--+--> R(n) | | | 2749 | T | | | | | 2750 | I |<---------+ | | | 2751 | O |<---------------+ | | 2752 | N |<--------------------+ | 2753 | |<-------------------------+ 2754 +-----+ Unicast 2756 Contribution Distribution 2757 Session Session 2758 (unicast or ASM) (SSM) 2760 Figure 3: One Media Sender Separate from Distribution Source 2762 15.3 Three Media Senders, Unicast Contribution 2764 Similar considerations apply if three Media Senders transmit to an 2765 SSM multicast group via the Distribution Source and individually 2766 send their media stream RTP packets via unicast to the Distribution 2767 Source. 2769 In this case, the responsibilities of the Distribution Source are a 2770 superset to the previous case: the Distribution Source also needs to 2771 relay media traffic from each Media Sender to the receivers and to 2772 forward (aggregated) feedback from the receivers to the Media 2773 Senders. In addition, the Distribution Source relays RTCP packets 2774 (SRs) from each Media Sender to the other two. 2776 The configuration of the Media Senders is identical to the previous 2777 case. It is just the Distribution Source that must be aware that 2778 there are multiple senders and then perform the necessary relaying. 2779 The transport address for the RTP session at the Distribution Source 2780 may be identical for all Media Senders (which may make correlation 2781 easier) or different addresses may be used. 2783 This setup is depicted in figure 4. 2785 RTCP with Unicast Feedback 2787 Source-specific 2788 +-----+ Multicast 2789 +--------+ | | +----------------> R(1) 2790 | Media |<---->| D S | | | 2791 |Sender 1| | I O | +--+ | 2792 +--------+ | S U | | | | 2793 | T R | | +-----------> R(2) | 2794 +--------+ | R C |->+----- : | | 2795 | Media |<---->| I E | | +------> R(n-1) | | 2796 |Sender 2| | B | | | | | | 2797 +--------+ | U | +--+--> R(n) | | | 2798 | T | | | | | 2799 +--------+ | I |<---------+ | | | 2800 | Media |<---->| O |<---------------+ | | 2801 |Sender 3| | N |<--------------------+ | 2802 +--------+ | |<-------------------------+ 2803 +-----+ Unicast 2805 Contribution Distribution 2806 Session Session 2807 (unicast) (SSM) 2809 Figure 4: Three Media Senders, unicast contribution 2811 15.4 Three Media Senders, ASM Contribution Group 2813 In this final example, the individual unicast contribution 2814 sessions between the Media Senders and the Distribution Source are 2815 replaced by a single ASM contribution group (i.e., a single common 2816 RTP session). Consequently, all Media Senders receive each 2817 other's traffic by means of IP-layer multicast and the 2818 Distribution Source no longer needs to perform explicit forwarding 2819 between the Media Senders. Of course, the Distribution Source 2820 still forwards feedback information received from the receivers 2821 (optionally as summaries) to the ASM contribution group. 2823 The ASM contribution group may be statically configured or the 2824 necessary information can be communicated using a standard SDP 2825 session description for a multicast session. Again, it is up to 2826 the implementation of the Distribution Source to properly 2827 associate the ASM contribution session and the SSM distribution 2828 sessions. 2830 Figure 5 shows this scenario. 2832 RTCP with Unicast Feedback 2834 _ Source-specific 2835 / \ +-----+ Multicast 2836 +--------+ | | | | +----------------> R(1) 2837 | Media |<->| A | | D S | | | 2838 |Sender 1| | S | | I O | +--+ | 2839 +--------+ | M | | S U | | | | 2840 | | | T R | | +-----------> R(2) | 2841 +--------+ | G | | R C |->+----- : | | 2842 | Media |<->| r |<->| I E | | +------> R(n-1) | | 2843 |Sender 2| | o | | B | | | | | | 2844 +--------+ | u | | U | +--+--> R(n) | | | 2845 | p | | T | | | | | 2846 +--------+ | | | I |<---------+ | | | 2847 | Media |<->| | | O |<---------------+ | | 2848 |Sender 3| \_/ | N |<--------------------+ | 2849 +--------+ | |<-------------------------+ 2850 +-----+ Unicast 2852 Contribution Distribution 2853 Session Session 2854 (ASM) (SSM) 2856 Figure 5: Three Media Sender in ASM Group 2857 RTCP with Unicast Feedback 2859 16. Appendix B: Distribution Report processing at the receiver 2861 16.1 Algorithm 2863 Example processing of Loss Distribution Values 2864 X values represent the loss percentage. 2865 Y values represent the number of receivers. 2867 Number of x values is the NDB value 2868 xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV) 2869 First data point = MnDV,first ydata 2870 then 2871 For each ydata => xdata += (MnDV + (xrange / NDB)) 2873 16.2 Pseudo-code 2875 Packet Variables -> factor,NDB,MnDVL,MaDV 2876 Code variables -> xrange, ydata[NDB],x,y 2878 xrange = MaDV - MnDV 2879 x = MnDV; 2881 for(i=0;i 20 Bytes) 3017 Minimum Data Value: 0 3018 RTCP with Unicast Feedback 3020 Maximum Data Value: 39 3021 Data Bucket values: (each value is 16-bits) 3023 Results, 4-bit buckets: 3025 X - 0 - 2.5 | 2.5 - 5 | 5 - 7.5 | 7.5 - 10 3026 (Y - 1803 | 4403 | 5970 | 853 ) ACTUAL 3027 Y - 4 | 9 | 12 | 2 3029 X - 10 - 12.5 | 12.5 - 15 | 15 - 17.5 | 17.5 - 20 3030 (Y - 110 | 140 | 89.5 | 12.5) ACTUAL 3031 Y - 0 | 0 | 0 | 0 3033 X - 20 - 22.5 | 22.5 - 25 | 25 - 27.5 | 27.5 - 30 3034 (Y - 447 | 3897 | 609.5 | 506.5) ACTUAL 3035 Y - 1 | 8 | 1 | 1 3037 X - 30 - 32.5 | 32.5 - 35 | 35 - 37.5 | 37.5 - 40 3038 (Y - 388.5 | 221.5 | 159.5 | 85.5) ACTUAL 3039 Y - 1 | 0 | 0 | 0 3041 Example: 2nd Method 3043 Description 3044 This demonstrates the most accurate method for representing the data 3045 set. This method doesn't attempt to optimise any values. 3047 Algorithm 3048 Identify the highest value and select buckets large enough to convey 3049 the exact values, i.e. no multiplicative factor. 3051 The highest value is 3120. This requires 12 bits (closest 2 bit 3052 boundary) to represent, therefore it will use 60 bytes to represent 3053 the entire distribution. This is within the max packet size, 3054 therefore all data will fit within one sub-report block. The 3055 multiplicative value will be 1. 3057 The packet fields will contain the values: 3059 Header Distribution Block 3060 Distribution Type: 1 3061 Number of Data Buckets: 40 3062 Multiplicative Factor: 0 3063 Packet Length field: 18 (18 * 4 => 72 Bytes) 3064 Minimum Loss Value: 0 3065 Maximum Loss Value: 39 3067 Bucket values are the same as initial data set. 3069 RTCP with Unicast Feedback 3071 Result 3072 The selection of which of the three methods outlined above might be 3073 determined by a congestion parameter, or a user preference. The 3074 overhead associated with processing the packets is likely to differ 3075 very little between the techniques. The savings in bandwidth are 3076 apparent however, using 20, 52 and 72 octets respectively. These 3077 values would vary more widely for a larger data set with less 3078 correlation between results. 3080 18. ACKNOWLEDGEMENTS 3082 The authors would like to thank Magnus Westerlund, Dave Oran, Tom 3083 Taylor and Colin Perkins for detailed reviews and valuable comments. 3085 19. AUTHORS' ADDRESSES 3087 Joerg Ott 3088 Helsinki University of Technology 3089 Department of Communications and Networking 3090 PO Box 3000 3091 FIN-02015 TKK 3092 jo@acm.org 3094 Julian Chesterfield 3095 University of Cambridge 3096 Computer Laboratory, 3097 15 JJ Thompson Avenue 3098 Cambridge 3099 CB3 0FD 3100 UK 3101 Julian.chesterfield@cl.cam.ac.uk 3103 Eve Schooler 3104 Intel Research / CTL 3105 MS RNB6-61 3106 2200 Mission College Blvd. 3107 Santa Clara, CA, USA 95054-1537 3108 eve_(underscore) schooler (at) acm.org