idnits 2.17.1 draft-ietf-avt-rtcpssm-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2802. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2817. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 74: '...The keywords MUST, MUST NOT, REQUIRED,...' RFC 2119 keyword, line 75: '...NOT, RECOMMENDED, MAY, and OPTIONAL, w...' RFC 2119 keyword, line 186: '...tribution Source MUST be able to commu...' RFC 2119 keyword, line 202: '...own in figure 1) MAY be inserted betwe...' RFC 2119 keyword, line 213: '...he Media Senders MAY send RTP and RTCP...' (198 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (6 March 2006) is 6624 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 931 -- Looks like a reference, but probably isn't: 'CNAME' on line 931 -- Looks like a reference, but probably isn't: 'NDB' on line 2562 == Unused Reference: '3' is defined on line 2267, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2284, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2290, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 2352, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-25 == Outdated reference: A later version (-09) exists of draft-ietf-mboned-ssm232-08 -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '13') (Obsoleted by RFC 7826) -- No information found for draft-ietf-ietf-avt-rtcp-feedback - is the name correct? == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-11 -- Obsolete informational reference (is this intentional?): RFC 2858 (ref. '19') (Obsoleted by RFC 4760) -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. '23') (Obsoleted by RFC 6407) Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 J. Chesterfield 3 University of Cambridge 4 J. Ott 5 Internet Draft Tellitec GmbH 6 Document: draft-ietf-avt-rtcpssm-11 E. Schooler 7 Intel 8 Expires: September 2006 6 March 2006 10 RTCP Extensions for Single-Source Multicast Sessions 11 with Unicast Feedback 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as work in progress. 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document specifies an extension to the Real-time Transport 39 Control Protocol (RTCP) to use unicast feedback to a multicast 40 sender. The proposed extension is useful for single-source multicast 41 sessions such as Source-Specific Multicast (SSM) communication where 42 the traditional model of many-to-many group communication is either 43 not available or not desired. In addition, it can be applied to any 44 group that might benefit from a sender-controlled summarized 45 reporting mechanism. 47 RTCP with Unicast Feedback 49 Table of Contents 51 1. Conventions and Acronyms........................................2 52 2. Introduction....................................................2 53 3. Basic Operation.................................................4 54 4. Definitions.....................................................7 55 5. Packet types....................................................8 56 6. Simple Feedback Model...........................................9 57 7. Distribution Source Feedback Summary Model.....................11 58 8. Mixer/Translator issues........................................29 59 9. Transmission interval calculation..............................30 60 10. SDP Extensions................................................32 61 11. Security Considerations.......................................34 62 12. Backwards Compatibility.......................................41 63 13. IANA Considerations...........................................41 64 14. Bibliography..................................................43 65 15. Appendix A: Examples for Sender Side Configurations...........46 66 16. Appendix B: Distribution Report processing at the receiver....50 67 18. ACKNOWLEDGEMENTS..............................................54 68 19. AUTHORS ADDRESSES.............................................54 69 18. IPR Notice....................................................54 70 20. FULL COPYRIGHT STATEMENT......................................55 72 1. Conventions and Acronyms 74 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 75 NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, 76 are to be interpreted as described in RFC 2119. 78 2. Introduction 80 The Real-time Transport Protocol (RTP) [1] provides a real-time 81 transport mechanism suitable for unicast or multicast communication 82 between multimedia applications. Typical uses of RTP are for real- 83 time or near real-time group communication of audio and video data 84 streams. An important component of the RTP protocol is the control 85 channel, defined as the Real-Time Control Protocol (RTCP). RTCP 86 involves the periodic transmission of control packets between group 87 members, enabling group size estimation and the distribution and 88 calculation of session-specific information such as packet loss and 89 round trip time to other hosts. An additional advantage of providing 90 a control channel for a session is that a third-party session 91 monitor can listen to the traffic to establish network conditions 92 and to diagnose faults based on receiver locations. 94 RTP was designed to operate in either a unicast or multicast mode. 95 In multicast mode, it assumes an Any Source Multicast (ASM) group 96 model, where both one-to-many and many-to-many communication are 97 supported via a common group address in the range 224.0.0.0 through 98 RTCP with Unicast Feedback 100 239.255.255.255. To enable internet-wide multicast communication, 101 intra-domain routing protocols (those that operate only within a 102 single administrative domain, e.g., DVMRP [16], PIM [17][18]) are 103 used in combination with an Inter-domain routing protocol (those 104 that operate across administrative domain borders, e.g., MBGP [19], 105 MSDP [20]). Such routing protocols enable a host to join a single 106 multicast group address and to send to or to receive data from all 107 members in the group with no prior knowledge of the membership. 108 However, there is a great deal of complexity involved at the routing 109 level to support such a multicast service in the network. 111 In addition, many-to-many communication is not always available, nor 112 desired by all group applications. For example, with Source-Specific 113 Multicast (SSM) and satellite communication, the multicast 114 distribution channel only supports source-to-receiver traffic. In 115 other cases, such as large ASM groups with a single active data 116 source and many passive receivers, it is sub-optimal to create a 117 full routing-level mesh of multicast sources just for the 118 distribution of RTCP control packets. Thus, an alternative solution 119 is preferable. 121 Although a one-to-many multicast topology may simplify routing and 122 may be a closer approximation of the requirements of certain RTP 123 applications, unidirectional communication makes it impossible for 124 receivers in the group to share RTCP feedback information amongst 125 all other group members. Therefore, in this document, we specify a 126 solution to this problem. We introduce unicast feedback as a new 127 method to distribute RTCP control information amongst all session 128 members. It is designed to operate under any group communication 129 model, ASM or SSM. The RTP data stream protocol itself is unaltered. 131 Scenarios under which the unicast feedback method could provide 132 benefit include but are not limited to: 134 a) SSM groups with a single sender. 136 The proposed extensions allow SSM groups that do not have many- 137 to-many communication capability to still receive RTP data 138 streams and to continue to participate in the RTP control 139 protocol, RTCP, by using multicast in the source-to-receiver 140 direction and using unicast to send receiver feedback to the 141 source on the standard RTCP port. 143 b) One-to-many broadcast networks. 145 Unicast feedback may also be beneficial to one-to-many broadcast 146 networks, such as a satellite network with a terrestrial low- 147 bandwidth return channel or a broadband cable link. Unlike the 148 SSM network, these networks may have the ability for a receiver 149 to multicast return data to the group. However, a unicast 150 feedback mechanism may be preferable for routing simplicity. 152 RTCP with Unicast Feedback 154 c) ASM with a single sender. 156 A unicast feedback approach may be used by an ASM application 157 with a single sender, as it would help to prevent overtaxing 158 multicast routing infrastructure that does not scale as 159 efficiently. Because it is not more efficient than a standard 160 multicast group RTP communication scenario, it is not expected to 161 replace the traditional mechanism. 163 The modifications proposed in this document are intended to 164 supplement the existing RTCP feedback mechanisms described in [1], 165 Section 6. 167 3. Basic Operation 169 This document proposes two new methods to enable unicast receiver 170 feedback: the Simple Feedback Model and the Distribution Source 171 Feedback Summary Model. Each involves unicasting RTCP packets to a 172 Distribution Source whose job it is to effect re-distribution of 173 the information to the members of the group. In the Simple Feedback 174 model the original RTCP reports (possibly re-packetized) are re- 175 distributed to the members by the Distribution Source. In the 176 Summary Feedback Model the node or nodes performing feedback compute 177 summary information which is distributed to the members by the 178 Distribution Source. In either model, the RTCP packets from members 179 of the group are unicast, either directly to the Distribution 180 Source, or to a Feedback Target node identified for such purpose by 181 the RTP session description. The Feedback Target, if different from 182 the Distribution Source, either relays the RTCP packets to the 183 Distribution source, or summarizes the reports and forwards an RTCP 184 summary report to the Distributions Source. 186 The Distribution Source MUST be able to communicate with all group 187 members in order for either mechanism to work. The general 188 architecture is displayed below in Figure 1. There may be a single 189 media sender or multiple media senders, Sender i, 1<=i<=N, on whose 190 behalf the Distribution Source disseminates RTP and RTCP packets. 191 The base case, which is expected to be the most common case, is that 192 the Distribution Source is one and the same as a particular sender. 193 A basic assumption is that communication is multicast (either SSM or 194 ASM) in the direction from the Distribution Source to receivers, 195 R(i), 1<=i<=N, and unicast in the direction from receivers to the 196 Distribution Source. 198 The Distribution Source is responsible for relaying RTCP information 199 between media sender(s) and receivers in both directions. In 200 addition, it is responsible for forwarding RTP packets from the 201 media sender(s) to the receivers. One or more feedback targets (not 202 shown in figure 1) MAY be inserted between the receivers and the 203 Distribution Source and accept feedback packets from the receivers 204 and relay or summarize this information towards the Distribution 205 Source. 207 RTCP with Unicast Feedback 209 Communication between Media Senders and the Distribution Source (or 210 the Feedback Target if it is separate from the Distribution Source) 211 may be performed in numerous ways: 213 i. Unicast only: The Media Senders MAY send RTP and RTCP via 214 unicast to the Distribution Source and receive RTCP via 215 unicast. 217 ii. Any Source Multicast (ASM): the Media Senders and the 218 Distribution Source MAY be in the same ASM group and RTP and 219 RTCP packets are exchanged via multicast. 221 iii. Source-Specific Multicast (SSM): The Media Senders and the 222 Distribution Source MAY be in an SSM group with the source 223 being the Distribution Source. RTP and RTCP packets from the 224 Media Senders are sent via unicast to the Distribution Source 225 while RTCP packets from the Distribution Source are sent via 226 multicast to the Media Senders. 228 Note that this SSM group MAY be identical to the SSM group used 229 for RTP/RTCP delivery from the Distribution Source to the 230 receivers or MAY be a different one. 232 The precise setup and configuration of the media senders and their 233 interaction with the Distribution Source is beyond the scope of this 234 document (appropriate SDP descriptions MAY be used for this purpose) 235 that only specifies how the various components interact within an 236 RTP session. Informative examples for different configurations of 237 the Media Sources and the Distribution Source are given in Appendix 238 A. 240 Source-specific 241 +--------+ +-----+ Multicast 242 |Media | | | +----------------> R(1) 243 |Sender 1|<----->| D S | | | 244 +--------+ | I O | +--+ | 245 | S U | | | | 246 +--------+ | T R | | +-----------> R(2) | 247 |Media |<----->| R C |->+----- : | | 248 |Sender 2| | I E | | +------> R(n-1) | | 249 +--------+ | B | | | | | | 250 : | U | +--+--> R(n) | | | 251 : | T +-| | | | | 252 | I | |<---------+ | | | 253 +--------+ | O |F|<---------------+ | | 254 |Media | | N |T|<--------------------+ | 255 |Sender N|<----->| | |<-------------------------+ 256 +--------+ +-----+ Unicast 258 FT = Feedback Target 259 RTCP with Unicast Feedback 261 Figure 1. System Architecture. 263 The first method proposed to support unicast RTCP feedback, the 264 'Simple Feedback Model', is a basic reflection mechanism whereby all 265 Receiver RTCP packets are unicast to the Distribution Source and 266 subsequently forwarded by the Distribution Source to all receivers 267 on the multicast RTCP channel. The advantage of using this method 268 is that an existing receiver implementation requires little 269 modification in order to use it. Instead of sending reports to a 270 multicast address, a receiver uses a unicast address to send reports 271 to the Distribution Source, yet still receives forwarded RTCP 272 traffic on the multicast control data channel. This method also has 273 the advantage of being backwards compatible with standard RTP/RTCP 274 implementations. 276 The second method, the 'Distribution Source Feedback Summary Model', 277 is a summarized reporting scheme that provides savings in bandwidth 278 by consolidating Receiver Reports at the Distribution Source into 279 one summary packet that is then distributed to all the receivers. 280 The advantage of this scheme is apparent for large group sessions 281 where the basic reflection mechanism outlined above generates a 282 large amount of packet forwarding when it replicates all the 283 information to all the receivers. The basic operation of the scheme 284 is similar to the first method in that receivers send feedback via 285 unicast to the Feedback Target, a logical function that may be part 286 of the Distribution Source. In the second scheme, however, the 287 Distribution Source distributes summaries of the feedback over the 288 multicast channel. Thus, this technique requires that all session 289 members understand the new summarized packet format outlined in 290 Section 7.1. Additionally, the summarized scheme provides an 291 optional mechanism to send distribution information or histograms 292 about the feedback data reported by the whole group. Potential uses 293 for the compilation of distribution information are addressed in 294 Section 7.4. 296 To differentiate between the two reporting methods, a new SDP 297 identifier is created and discussed in Section 10. The reporting 298 method MUST be decided prior to the start of the session. A 299 Distribution Source MUST NOT change the method during a session. 301 In a session using SSM, the network SHOULD prevent any multicast 302 data from the receiver being distributed further than the first hop 303 router. Additionally, any data heard from a non-unicast capable 304 receiver by other hosts on the same subnet SHOULD be filtered out by 305 the host IP stack and therefore should not cause problems with 306 respect to the calculation of the Receiver RTCP bandwidth share. 308 RTCP with Unicast Feedback 310 4. Definitions 312 Distribution Source: 313 In an SSM context, only one entity distributes RTP data and 314 redistributes RTCP information to all receivers. This entity 315 is called the Distribution Source. A logical function of the 316 Distribution Source is the Feedback Target to which the RTCP 317 unicast feedback is sent. In order for unicast feedback to 318 work, there MUST be only one Feedback Target for any subset of 319 receivers to which RTCP feedback is directed. Note that 320 heterogeneous networks consisting of ASM multiple-sender 321 groups, unicast-only clients and/or SSM single-sender receiver 322 groups MAY be connected via translators or mixers to create a 323 single-source group (see Section 8 for details). 325 Media Sender: 326 A Media Sender is an entity that originates RTP packets for a 327 particular media session. In RFC 3550, a Media Sender is simply 328 called a source. However, as the RTCP SSM system architecture 329 includes a Distribution Source, to avoid confusion, in this 330 document a media source is commonly referred to as a Media 331 Sender. There may often be a single media sender that is co- 332 located with the Distribution Source. But although there MUST 333 be only one Distribution Source, there MAY be multiple Media 334 Senders on whose behalf the Distribution Source forwards RTP 335 and RTCP packets. 337 RTP and RTCP Channels: 338 The data distributed from the source to the receivers is 339 referred to as the RTP channel and the control information the 340 RTCP channel. With standard RTP/RTCP, these channels typically 341 share the same multicast address but are differentiated via 342 port numbers as specified in [1]. In an SSM context, the RTP 343 channel is multicast, whereas the RTCP or feedback channel is 344 actually the collection of unicast channels between each 345 receiver and the source. 347 (Unicast RTCP) Feedback Target: 348 The Feedback Target is a logical function to which RTCP unicast 349 feedback traffic is addressed. In many cases, the function of 350 the Feedback Target and the Distribution Source will be 351 integrated in the same entity. In this case, for a session 352 defined as having a Distribution Source A, on ports n for the 353 RTP channel and k for the RTCP channel, the unicast RTCP 354 feedback target is the IP address of Source A on port k unless 355 otherwise stated in the session description. See Section 10 356 for details on how the address is specified. The Feedback 357 Target MAY be an entity different from the Distribution Source 358 and different RTP receivers MAY use different Feedback Targets, 359 e.g., for aggregation purposes. In this case, the Feedback 360 Targets MUST convey feedback from the RTP receivers to the 361 Distribution Source using the RTCP mechanisms specified in this 362 document. If disjoint, Feedback Target(s) and Distribution 363 Source MUST share, e.g., through configuration, enough 364 RTCP with Unicast Feedback 366 information to be able to provide coherent RTCP information to 367 the RTP receivers based upon the RTCP feedback collected by the 368 Distribution Source and/or the Feedback Target(s) -- as would 369 be done if both functions were part of the same entity. 371 SSRC: 372 Synchronization source. A 32-bit value that uniquely 373 identifies each member in a session. See [1] for further 374 information. 376 Report blocks: 377 Report block is the standard terminology for an RTCP reception 378 report. RTCP [1] encourages the stacking of multiple report 379 blocks in Sender Report (SR) and Receiver Report (RR) packets. 380 As a result, a variable size feedback packet may be created by 381 one source that reports on multiple other sources in the group. 382 The summarized reporting scheme builds upon this model through 383 the inclusion of multiple summary report blocks in one packet. 384 However, stacking of reports from multiple receivers is not 385 permitted in the simple feedback scheme. 387 5. Packet types 389 The RTCP packet types defined in [1], [26], and [15] are: 391 Type Description Payload number 392 ------------------------------------------------------- 393 SR Sender Report 200 394 RR Receiver Report 201 395 SDES Source Description 202 396 BYE Goodbye 203 397 APP Application-Defined 204 398 RTPFB Generic RTP feedback 205 399 PSFB Payload-specific feedback 206 400 XR RTCP Extension 207 402 This document defines one further RTCP packet format: 404 Type Description Payload number 405 --------------------------------------------------------- 406 RSI Receiver Summary Information 208 408 Within the Receiver Summary Information packet, there are various 409 types of information that may be reported and encapsulated in 410 optional sub-report blocks: 412 RTCP with Unicast Feedback 414 Sub-Report Block Type Description Identifier number 415 ------------------------------------------------------------------ 416 IPv4 Address IPv4 Unicast Feedback address 0 417 IPv6 Address IPv6 Unicast Feedback address 1 418 DNS name DNS name for Unicast Feedback 2 419 - - reserved - 3 420 Loss Loss distribution 4 421 Jitter Jitter distribution 5 422 RTT Round trip time distribution 6 423 Cumulative loss Cumulative loss distribution 7 424 Collisions SSRC collision list 8 425 - - reserved - 9 426 Stats General statistics 10 427 Receiver BW RTCP Receiver Bandwidth 11 428 Group Info RTCP Group and Avg Packet Size 12 429 - - reserved - 13 - 255 431 As with standard RTP/RTCP, the various reports MAY be combined into 432 a single RTCP packet, which SHOULD NOT exceed the path MTU. Packets 433 continue to be sent at a rate that is inversely proportional to the 434 group size in order to scale the amount of traffic generated. 436 6. Simple Feedback Model 438 6.1 Packet Formats 440 The Simple Feedback Model uses the same packet types as traditional 441 RTCP feedback described in [1]. Receivers still generate Receiver 442 Reports with information on the quality of the stream received from 443 the Distribution Source. The Distribution Source still must create 444 Sender Reports that include timestamp information for stream 445 synchronization and round trip time calculation. Both senders and 446 receivers are required to send SDES packets as outlined in [1]. The 447 rules for generating BYE and APP packets as outlined in [1] also 448 apply. 450 6.2 Distribution Source behavior 452 For the simple feedback model, the Distribution Source MUST provide 453 a basic packet reflection mechanism. It is the default behavior for 454 any Distribution Source and is the minimum requirement for acting as 455 a Distribution Source to a group of receivers using unicast RTCP 456 feedback. In case the Feedback Target function is disjoint from the 457 Distribution Source, the Feedback Target(s) MUST forward all RTCP 458 packets from the receivers -- directly or indirectly -- to the 459 Distribution Source for reflection. 461 The Distribution Source (unicast feedback target) MUST listen for 462 unicast RTCP data sent to the RTCP port. All unicast RTCP packets 463 received on this port MUST be forwarded by the Distribution Source 464 to the group on the multicast RTCP channel. The Distribution Source 465 SHOULD NOT stack report blocks received from different receivers 466 into one packet for retransmission to the group. Every RTCP packet 467 from each receiver MUST be reflected individually. 469 RTCP with Unicast Feedback 471 If the Media Sender(s) are not part of the SSM group for RTCP packet 472 reflection, the Distribution Source MUST also forward the RTCP 473 packets received from the receivers to the Media Sender(s). If 474 there is more than one Media Sender and these Media Senders do not 475 communicate via ASM with the Distribution Source and each other, the 476 Distribution Source MUST forward each RTCP packet originated by one 477 Media Sender to all other Media Senders. 479 The Distribution Source MUST forward RTCP packets originating from 480 the Media Senders to the receivers. 482 The reflected or forwarded RTCP traffic SHOULD NOT be counted as its 483 own traffic in the transmission interval calculation by the 484 Distribution Source. In other words, the Distribution Source SHOULD 485 NOT consider reflected packets as part of its own control data 486 bandwidth allowance. However, reflected packets MUST be processed 487 by the Distribution Source and the average RTCP packet size, RTCP 488 transmission rate, and RTCP statistics MUST be calculated. The 489 algorithm for computing the allowance is explained in Section 9. 491 6.3 Disjoint Distribution Source and Feedback Target(s) 493 If the Distribution Source and the Feedback Target(s) are disjoint 494 entities, the Feedback Target(s) MUST forward all RTCP packets from 495 the RTP receivers to the Distribution Source. 497 6.4 Receiver behavior 499 Receivers MUST listen on the RTP channel for data and the RTCP 500 channel for control. Each receiver MUST calculate its share of the 501 control bandwidth R/n, based on the standard rule that a fraction of 502 the RTCP bandwidth, R, allocated to receivers is divided equally 503 between the number of unique receiver SSRCs in the session, n. See 504 Section 9 for further information on the calculation of the 505 bandwidth allowance. When a receiver is eligible to transmit, it 506 MUST send a unicast Receiver Report packet to the Feedback target 507 following the rules defined in section 9. 509 A receiver observing RTP packets from a Media Sender with an SSRC 510 that collides with its own chosen SSRC SHOULD change its own SSRC 511 following the procedures of [1]. The receiver SHOULD do so 512 immediately after noticing and before sending any (further) RTCP 513 feedback messages. 515 6.5 Media Sender behavior 517 Media Senders listen on a unicast or multicast transport address for 518 RTCP reports sent by the receivers (and forwarded by the 519 Distribution Source) or other Media Senders (optionally forwarded by 520 the Distribution Source). Processing and general operation follows 521 [1]. 523 RTCP with Unicast Feedback 525 A Media Sender that observes an SSRC collision with another entity 526 that is not also a Media Sender MAY delay its own collision 527 resolution actions as per [1] by 5*1.5*Td with Td being the 528 deterministic calculated reporting interval for receivers to see 529 whether the conflict still exists. SSRC collisions with other Media 530 Senders MUST be acted upon immediately. 532 Note: This gives precedence to Media Senders and places the 533 burden of collision resolution on RTP receivers. 535 7. Distribution Source Feedback Summary Model 537 In the Distribution Source Feedback Summary Model, the Distribution 538 Source is required to summarize the information received from all 539 the Receiver Reports generated by the receivers and place the 540 information into summary reports. The Distribution Source Feedback 541 Summary Model introduces a new report block format, the Receiver 542 Summary Information Report (RSI), and a number of optional sub- 543 report block formats, which are enumerated in Section 7.1. 545 Sub-report types appended to the RSI report block provide more 546 detailed information on the overall session characteristics reported 547 by all receivers and also convey important information such as the 548 feedback address and reporting bandwidth. Which sub-reports are 549 mandatory and which ones are optional is defined below. 551 From an RTP perspective, the Distribution Source acts like an RTP 552 receiver, generating its own Receiver Reports and sending them to 553 the receiver group and to the Media Senders. However, the 554 Distribution Source is not counted in the receiver bandwidth 555 allocation, as it summarizes information provided by the other 556 receivers. Nevertheless, the Distribution Source's transmission 557 rate MUST adhere to RTCP bandwidth limitations for receivers. In 558 the Distribution Source Feedback Summary Model, an RSI report block 559 MUST be appended to all RRs the Distribution Source generates. 561 In addition, the Distribution Source MUST forward the RTCP SR 562 reports and SDES packets of Media Senders without alteration. If 563 the Distribution Source is actually a Media Sender, even if it is 564 the only session sender, it MUST generate its own Sender Report (SR) 565 packets for its role as a Media Sender and its Receiver Reports in 566 its role as the Distribution Source. 568 The Distribution Source MUST use an SSRC value for transmitting 569 summarization information and MUST perform proper SSRC collision 570 detection and resolution. 572 Note: Here, one could have optimized for the presumably common 573 case (Distribution Source == sender) and reduce the number of 574 RTCP packets sent by the Distribution Source. However, the 575 generalized way always requiring the Distribution Source to be 576 a receiver with its own SSRC is much cleaner, albeit this comes 577 at the cost of some extra bits. 579 RTCP with Unicast Feedback 581 The Distribution Source MUST send at least one Receiver Summary 582 Information packet for each reporting interval. The Distribution 583 Source MAY additionally stack sub-report blocks after the RSI 584 packet. If it does so, each sub-report block MUST correspond to the 585 initial RSI packet and constitutes an enhancement to the basic 586 summary information required by the receivers to calculate their 587 reporting time interval. For this reason, additional sub-report 588 blocks are not required but recommended. The compound RTCP packets 589 containing the RSI packet and the optional corresponding sub-report 590 blocks MUST be formed according to the rules defined in [1] for 591 receiver-issued packets, i.e., the MUST begin with an RR packet and 592 also contain at an SDES packet with a CNAME; they MAY contain 593 further RTCP packets and SDES items. 595 Every RSI packet MUST contain either a Group and Average Packet size 596 sub-report or an RTCP Bandwidth sub-report for bandwidth indications 597 to the receivers. 599 7.1 Packet Formats 601 7.1.1 RSI: Receiver Summary Information Packet 603 The RSI report block has a fixed header size followed by a variable 604 length report: 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 |V=2|P|reserved | PT=RSI=208 | length | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | SSRC/CSRC | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | | 614 + Timestamp + 615 | | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 : optional report blocks : 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 The RSI packet includes the following fields: 622 length: 16 bits 623 As defined in [1], the length of the RTCP packet in 32-bit words 624 minus one, including the header and any padding. 626 SSRC: 32 bits 627 The SSRC of the Distribution Source. 629 Timestamp: 64 bits 630 Indicates the wallclock time when this report was sent. 631 Wallclock time (absolute date and time) is represented using the 632 RTCP with Unicast Feedback 634 timestamp format of the Network Time Protocol (NTP), which is in 635 seconds relative to 0h UTC on 1 January 1900 [4]. The full 636 resolution NTP timestamp is used which is a 64-bit unsigned 637 fixed-point number with the integer part in the first 32 bits and 638 the fractional part in the last 32 bits. This value is used to 639 enable detection of duplicate packets, reordering and to provide 640 a chronological profile of the feedback reports. 642 7.1.2 Optional Sub-Report Block Types 644 For RSI reports, this document also introduces a sub-report block 645 format specific to the RSI packet. The sub-report blocks are 646 appended to the RSI packet using the following generic format. All 647 sub-report blocks MUST be 32-bit aligned. 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | SRBT | Length | | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRBT-specific data + 653 | | 654 : : 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 SRBT: 8 bits 658 Sub-Report Block Type. The sub-report block type identifier. The 659 values for the sub-report block types are defined in section 5. 661 Length: 8 bits 662 The length of the sub-report in 32-bit words. 664 SRBT-specific data: octets 665 This field may contain type-specific information based upon the 666 SRBT value. 668 7.1.3 Generic Sub-Report Block Fields 670 For the sub-report blocks that convey distributions of values (Loss, 671 Jitter, RTT, Cumulative Loss), a flexible 'data bucket' style report 672 is used. This format divides the data set into variable size buckets 673 that are interpreted according to the guide fields at the head of 674 the report block. 676 RTCP with Unicast Feedback 678 0 1 2 3 679 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 680 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 681 | SRBT | Length | NDB | MF | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Minimum Distribution Value | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Maximum Distribution Value | 686 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 687 | Distribution Buckets | 688 | ... | 689 | ... | 690 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 692 The SRBT and Length fields are calculated as explained in section 693 7.1.2. 695 Number of distribution buckets (NDB): 12 bits 696 The number of distribution buckets of data. The size of each 697 bucket can be calculated using the formula ((length * 4) - 698 12)*8/NDB number of bits. The calculation is based on the length 699 of the whole sub-report block in octets (length field * 4) minus 700 the header of 12 octets. Providing 12 bits for the NDB field 701 enables bucket sizes as small as 2 bits for a full length packet 702 of MTU 1500 bytes. The bucket size in bits must always be 703 divisible by 2 to ensure proper byte alignment. A bucket size of 704 2 bits is fairly restrictive, however, and it is expected that 705 larger bucket sizes will be more practical for most 706 distributions. 708 Multiplicative Factor (MF): 4 bits 709 2^MF indicates the multiplicative factor to be applied to each 710 distribution bucket value. Possible values are 0 - 15, creating 711 a range of values from MF = 1, 2, 4 ... 32768. 713 Length: 8 bits 714 The length field tells the receiver the full length of the sub- 715 report block in 32-bit words (i.e., length * 4 bytes), and 716 enables the receiver to identify the bucket size. For example, 717 given no MTU restrictions, the data portion of a distribution 718 packet may be only as large as 1008 bytes (255 * 4 - 12), 719 providing up to 4032 data buckets of length 2 bits, or 2016 data 720 buckets of length 4 bits, etc. 722 Minimum distribution value (min): 32 bits 723 The minimum distribution value, in combination with the maximum 724 distribution value, indicates the range covered by the data 725 bucket values. 727 Maximum distribution value (max): 32 bits 728 The maximum distribution value, in combination with the minimum 729 distribution value, indicates the range covered by the data 730 bucket values. The significance and range of the distribution 731 RTCP with Unicast Feedback 733 values is defined in the individual profiles for each 734 distribution type (DT). 736 Distribution buckets: each bucket is ((length * 4) - 12)*8/NDB bits 737 The size and number of buckets is calculated as outlined above 738 based upon the value of NDB and the length of the packet. The 739 values for distribution buckets are equally distributed; 740 according to the following formula, distribution bucket x 741 (with 0 <= x < NDB) covering the value range: 743 x=0; [min, min+(max-min)/NDB] 744 x>0; [min+(x)*(max-min)/NDB, min+(x+1)*(max-min)/NDB] 746 Interpretation of the minimum, maximum, and distribution values in 747 the sub-report block is profile-specific and is addressed 748 individually in the sections below. The size of the sub-report 749 block is variable, as indicated by the packet length field. 751 Note that, for any bucket-based reporting, if the Distribution 752 Source and the Feedback Target(s) are disjoint entities, out-of-band 753 agreement on the bucket reporting granularity is required to allow 754 the Distribution Source to forward accurate information in these 755 kinds of reports to the receivers. 757 7.1.4 Loss sub-report block 759 The loss sub-report block allows a receiver to determine how its own 760 reception quality relates to the other recipients. A receiver may 761 use this information, e.g., to drop out of a session (instead of 762 sending lots of error repair feedback) if it finds itself isolated 763 at the lower end of the reception quality scale. 765 The loss sub-report block indicates the distribution of losses as 766 reported by the receivers to the Distribution Source. Values are 767 expressed as a fixed-point number with the binary point at the left 768 edge of the field similar to the "fraction lost" field in SR and RR 769 packets as defined in [1]. The Loss sub-report block type (SRBT) is 770 4. 772 Valid results for the minimum distribution value field are 0 - 254. 773 Similarly, valid results for the maximum distribution value field 774 are 1 - 255. The minimum distribution value MUST always be less 775 than the maximum. 777 For examples on processing summarized loss report sub-blocks, see 778 Appendix B. 780 7.1.5 Jitter sub-report block 782 A jitter sub-report block indicates the distribution of the 783 estimated statistical variation of the RTP data packet inter-arrival 784 time reported by the receivers to the Distribution Source. This 785 RTCP with Unicast Feedback 787 allows receivers both to place their own observed jitter values in 788 context with the rest of the group, and to approximate dynamic 789 parameters for playout buffers. See [1] for details on the 790 calculation of the values and the relevance of the jitter results. 791 Jitter values are measured in timestamp units and expressed as 792 unsigned integers. The minimum distribution value MUST always be 793 less than the maximum. The Jitter sub-report block type (SRBT) is 794 5. 796 Since timestamp units are payload-type specific, the relevance of a 797 jitter value would be impacted by any change in the payload type 798 during a session. Therefore, a Distribution Source MUST NOT report 799 jitter distribution values for at least 2 reporting intervals after 800 a payload type change occurs. 802 7.1.6 Round Trip Time sub-report block 804 A round trip time sub-report indicates the distribution of round 805 trip times from the Distribution Source to the receivers, providing 806 receivers with a global view of the range of values in the group. 807 The Distribution Source is capable of calculating the round trip 808 time to any other members since it forwards all the SR packets from 809 the Media Sender(s) to the group. If the Distribution Source is not 810 itself a Media Sender, it can calculate the round trip time from 811 itself to any of the receivers by maintaining a record of the SR 812 sender timestamp, and the current time as measured from its own 813 system clock. The Distribution Source consequently calculates the 814 round trip time from the receiver report by identifying the 815 corresponding SR timestamp, and subtracting the RR advertised 816 holding time as reported by the receiver, from its own time 817 difference measurement, as calculated by the time the RR packet is 818 received and the recorded time the SR was sent. 820 The Distribution Source has the option of distributing to the whole 821 group these round trip time estimations, uses of which are described 822 in Section 7.4. The round trip time is expressed in units of 823 1/65536 seconds and indicates an absolute value. This is calculated 824 by the Distribution Source based on the Receiver Report responses 825 declaring the time difference since an original Sender Report, and 826 the holding time at the receiver. The minimum distribution value 827 MUST always be less than the maximum. The Round Trip Time sub-report 828 block type (SRBT) is 6. 830 7.1.7 Cumulative Loss sub-report block 832 The cumulative loss field in a Receiver Report [1], in contrast to 833 the Average Fraction Lost field, is intended to provide some 834 historical perspective on the session performance, i.e. the total 835 number of lost packets since the receiver joined the session. The 836 cumulative loss value presents a smoothed average by summing over a 837 larger sample set (typically the whole session). The Distribution 838 Source MAY record the values as reported by the receiver group and 839 RTCP with Unicast Feedback 841 report a distribution of values. Values are expressed as a fixed- 842 point number with the binary point at the left edge of the field, in 843 the same manner as the Loss sub-report block. The sender must 844 maintain a record of the Cumulative number lost and Extended Highest 845 Sequence number received as reported by each receiver. Ideally the 846 recorded values are from the first report received. Future 847 calculations are then based on ( - 848 ) / ( - 849 ). 851 Valid results for the minimum distribution value field are 0 - 254. 852 Similarly, valid results for the maximum distribution value field 853 are 1 - 255. The minimum distribution value MUST always be less 854 than the maximum. The Cumulative loss sub-report block type (SRBT) 855 is 7. 857 Note that in case the Distribution Source and the Feedback Target 858 functions are disjoint, it is only possible for the Distribution 859 Source to determine RTT if all the Feedback Targets forward all RTCP 860 reports from the receivers immediately and include at least the RR 861 packet. 863 7.1.8 Feedback Address Target sub-report block 865 The feedback address target block provides a dynamic mechanism for 866 the Distribution Source to signal an alternative unicast RTCP 867 feedback address to the receivers. If this field is included, it 868 MUST override any static SDP address information for the session. 870 If this sub-report block is used, it MUST be included in every RTCP 871 packet originated by the Distribution Source to ensure that all 872 receivers understand the information. In this manner, receiver 873 behavior should remain consistent even in the face of packet loss or 874 for late session arrivals. 876 0 1 2 3 877 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 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | SRBT={0,1,2} | Length | Port | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | | 882 : Address : 883 | | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 Length: 8 bits 887 The length of the sub-report block in 32-bit words. For an IPv4 888 address this should be 2 (e.g., Total length = 4 + 4 = 2*4 889 octets). For an IPv6 address this should be 5. For a DNS name, 890 the length field indicates the number of 32-bit words making up 891 the string plus 1 byte and any additional padding required to 892 reach the next word boundary. 894 RTCP with Unicast Feedback 896 Port: 2 octets (optional) 897 The port number to which receivers send feedback reports. A port 898 number of 0 is invalid and MUST NOT be used. 900 Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name) 901 The address to which receivers send feedback reports. For IPv4 902 and IPv6 fixed-length address fields are used. A DNS name is an 903 arbitrary length string that is padded with null bytes to the 904 next 32 bit boundary. The string MUST be UTF-8 encoded [11]. 905 For IPv4, SRBT=0. For IPv6, SRBT=1. For usage of the DNS name, 906 SRBT=2. 908 The feedback target address sub-report block types (SRBT) are 0 for 909 numeric IPv4 addresses, 1 for numeric IPv6 addresses, and 2 for DNS 910 names. 912 A feedback target address block for a certain address type (i.e., 913 with a certain SRBT of 0, 1, or 2) MUST NOT occur more than once 914 within a packet. Numerical feedback target address blocks for IPv4 915 and IPv6 MAY both be present. If so, the resulting transport 916 addresses MUST point to the same logical entity. 918 If a feedback target address block with an SRBT indicating a DNS 919 name is present, there SHOULD NOT be any other numerical feedback 920 target address blocks present. 922 The feedback target address presents a significant security risk if 923 accepted from unauthenticated RTCP packets. See section 11.3.a and 924 11.4.a. 926 7.1.9 Collisions sub-report block 928 The collision SSRC sub-report provides the Distribution Source with 929 a mechanism to report SSRC collisions amongst the group. In the 930 event that a non-unique SSRC is discovered based on the tuple 931 [SSRC,CNAME], the collision is reported in this block and the 932 affected nodes must reselect their respective SSRC identifiers. 934 0 1 2 3 935 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 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | SRBT=8 | Length | Reserved | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | | 940 : Collision SSRC : 941 | | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Collision SSRC: n x 32 bits 945 This field contains a list of SSRCs that are duplicated within 946 the group. Usually this is handled by the hosts upon detection 947 RTCP with Unicast Feedback 949 of the same SSRC; however, since receivers in an SSM session 950 using the Distribution Source Feedback Summary Model no longer 951 have a global view of the session, the collision algorithm is 952 handled by the Distribution Source. SSRCs that collide are 953 listed in the packet. Each Collision SSRC is reported only once 954 for each collision detection. If more Collision SSRCs need to be 955 reported than fit into an MTU, the reporting is done in a round 956 robin fashion so that all Collision SSRCs have been reported once 957 before the second round of reporting starts. On receipt of the 958 packet, receiver(s) MUST detect the collision and select another 959 SSRC, if the collision pertains to them. 961 The Collisions sub-report block type (SRBT) is 8. 963 Collision detection is only possible at the Distribution Source. If 964 the Distribution Source and Feedback Target Functions are disjoint 965 and collision reporting across RTP receiver SSRCs shall be provided, 966 the Feedback Targets(s) MUST forward the RTCP reports from the RTP 967 receivers including at least the RR and the SDES packets to the 968 Distribution Source. 970 Therefore, in system settings in which, by explicit configuration or 971 implementation, RTP receivers are not going to act as Media Senders 972 in a session (e.g. for various types of television broadcasting), 973 SSRC collision detection MAY be omitted for RTP receivers. In 974 system settings in which an RTP receiver MAY become a Media Sender 975 (e.g., any conversational application), SSRC collision detection 976 MUST be provided for RTP receivers. 978 Note: The purpose of SSRC collision reporting is to ensure 979 unique identification of RTCP entities. This is of particular 980 relevance for Media Senders so that an RTP receiver can 981 associate each of multiple incoming media streams (via the 982 Distribution Source) properly with the correct sender. 983 Collision resolution for Media Senders is not affected by the 984 Distribution Source's collision reporting because all SR 985 reports are always forwarded among the senders and to all 986 receivers. Collision resolution for RTP receivers is of 987 particular relevance for those receivers capable of becoming a 988 Media Sender. RTP receivers that will, by configuration or 989 implementation choice, not act as a sender in a particular RTP 990 session, do not necessarily need to be aware of collisions as 991 long as the those entities receiving and processing RTCP 992 feedback messages from the receivers are capable of 993 disambiguating the various RTCP receivers (e.g., by CNAME). 995 Note also that RTP receivers should be able to deal with 996 changing SSRCs of a Media Sender (like any RTP receiver has to 997 do.) and, if possible, be prepared to render a media stream 998 continuously nevertheless. 1000 7.1.10 General Statistics sub-report block 1001 RTCP with Unicast Feedback 1003 The general statistics sub-report block is used if specifying 1004 buckets is deemed too complex. With the general statistics sub- 1005 report block only aggregated values are reported back. The rules 1006 for the generation of these values are provided in section 7.2.1.b. 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | SRBT=10 | Length | Reserved | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | MFL | HCNL | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Median interarrival jitter | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 Median fraction lost (MFL): 8 bits 1019 The median fraction lost indicated by Receiver Reports forwarded 1020 to this Distribution Source, expressed as a fixed point number 1021 with the binary point at the left edge of the field. A value of 1022 all '1's indicates that the MFL value is not provided. 1024 Highest cumulative number of packets lost (HCNL): 24 bits 1025 Highest 'cumulative number of packets lost' value out of the most 1026 recent RTCP RR packets from any of the receivers. A value of all 1027 '1's indicates that the HCNL value is not provided. 1029 Median inter-arrival jitter: 32 bits 1030 Median 'inter-arrival jitter' value out of the most recent RTCP 1031 RR packets from the receiver set. A value of all '1's indicates 1032 that this value is not provided. 1034 The General Statistics sub-report block type (SRBT) is 10. 1036 Note that in case the Distribution Source and the Feedback Target 1037 functions are disjoint, it is only possible for the Distribution 1038 Source to determine the median of the inter-arrival jitter if all 1039 the Feedback Targets forward all RTCP reports from the receivers 1040 immediately and include at least the RR packet. 1042 7.1.11 RTCP Bandwidth Indication sub-report block 1044 This sub-report block is used to inform the Media Senders and 1045 receivers about the maximum RTCP bandwidth that is supposed to be 1046 used by each Media Sender or about the maximum bandwidth allowance 1047 to be used by each receiver. The value is applied universally to 1048 all Media Senders or all receivers. Each receiver MUST base its 1049 RTCP transmission interval calculation on the average size of the 1050 RTCP packets sent by itself. Conversely, each Media Sender MUST base 1051 its RTCP transmission interval calculation on the average size of 1052 the RTCP packets sent by the Distribution Source to the receivers. 1054 RTCP with Unicast Feedback 1056 0 1 2 3 1057 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 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | SRBT=11 | Length |S|R| Reserved | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | RTCP Bandwidth | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 Sender (S): 1 bit 1065 The contained bandwidth value applies to each Media Sender. 1067 Receivers (R): 1 bit 1068 The contained bandwidth value applies to each RTP receiver. 1070 Reserved: 14 bits 1071 MUST be set to zero upon transmission and ignored upon reception. 1073 RTCP Bandwidth: 32 bits 1074 If the S bit is set to 1, this field indicates the maximum 1075 bandwidth allocated to each individual sender. This also informs 1076 the receivers about the RTCP report frequency to expect from the 1077 senders. This is a fixed point value with the binary point in 1078 between the second and third bytes. The value represents the 1079 bandwidth allocation per-receiver in kilobits per second with 1080 values in the range 0 <= BW < 65536. 1082 If the R bit is set to 1, this field indicates the maximum 1083 bandwidth allocated per receiver for sending RTCP data relating 1084 to the session. This is a fixed point value with the binary 1085 point in between the second and third bytes. The value 1086 represents the bandwidth allocation per-receiver in kilobits per 1087 second with values in the range 0 <= BW < 65536. Each receiver 1088 MUST use this value for its bandwidth allowance. 1090 This report block SHOULD only be used when the Group and Average 1091 Packet Size sub-report block is NOT included. The RTCP Bandwidth 1092 Indication sub-report block type (SRBT) is 11. 1094 7.1.12 RTCP Group and Average Packet Size Sub-report Block 1096 This sub-report block is used to inform the Media Senders and 1097 receivers about the size of the group (used for calculating feedback 1098 bandwidth allocation) and the average packet size of the group. 1099 This sub-report MUST always be present, appended to every RSI 1100 packet, unless an RTCP Bandwidth indication sub-report block is 1101 included (in which case it MAY but need not be present). 1103 RTCP with Unicast Feedback 1105 0 1 2 3 1106 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 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | SRBT=12 | Length | Average Packet Size | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Receiver Group Size | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 Group size: 32 bits 1114 This field provides the Distribution Source's view of the number 1115 of receivers in a session. Note that the number of Media Senders 1116 is not explicitly reported since it can be derived by observing 1117 the RTCP SR packets forwarded by the Distribution Source. The 1118 group size is calculated according to the rules outlined in [1]. 1119 When this sub-report block is included, this field MUST always be 1120 present. 1122 Average RTCP packet size: 16 bits 1123 This field provides the Distribution Source's view of the average 1124 RTCP packet size as locally calculated following the rules 1125 defined in [1]. The value is an unsigned integer counting 1126 octets. When this sub-report block is included, this field MUST 1127 always be present. 1129 The Group and Average Packet Size sub-report block type (SRBT) is 1130 12. 1132 7.2 Distribution Source behavior 1134 In the Distribution Source Feedback Summary Model, the Distribution 1135 Source (the unicast feedback target) MUST listen for unicast RTCP 1136 packets sent to the RTCP port. All RTCP packets received on this 1137 port MUST be processed by the Distribution Source as described 1138 below. 1140 The Distribution Source acts like a regular RTCP receiver. In 1141 particular, it receives an RTP stream from each RTP Media Sender(s) 1142 and MUST calculate the proper reception statistics for these RTP 1143 streams. It MUST transmit the resulting information as report 1144 blocks contained in each RTCP packet it sends (in an RR packet). 1146 Note: This information may help to determine the transmission 1147 characteristics of the feed path from the RTP sender to the 1148 Distribution Source (if these are separate entities). 1150 The Distribution Source is responsible for accepting RTCP packets 1151 from the receivers, and interpreting and storing per-receiver 1152 information as defined in [1]. The importance of providing these 1153 functions is apparent when creating the RSI and sub-report block 1154 reports, since incorrect information can have serious implications. 1155 Section 11 addresses the security risks in detail. 1157 RTCP with Unicast Feedback 1159 As defined in [1], all RTCP reports from the Distribution Source 1160 MUST start with an RR report followed by any relevant SDES fields. 1161 Then, the Distribution Source MUST append any summarization specific 1162 data to an RR report since it always generates RR data. In 1163 addition, either the Group and Average Packet size sub-report or the 1164 Receiver RTCP Bandwidth sub-report block MUST be appended to the RSI 1165 header. 1167 A Distribution Source has the option of masking the Group size by 1168 including only an RTCP bandwidth sub-report. If both sub-reports 1169 are included, the information contained in the Receiver RTCP 1170 Bandwidth sub-report block MUST take precedence. 1172 The Receiver RTCP Bandwidth sub-report block provides the 1173 Distribution Source with the capability to control the amount of 1174 feedback from the receivers and MAY be increased or decreased based 1175 upon the requirements of the Distribution Source. Regardless of the 1176 value selected by the Distribution Source for the Receiver RTCP 1177 Bandwidth sub-report block, the Distribution Source MUST continue to 1178 forward Sender Reports and RSI packets at the rate allowed by the 1179 total RTCP bandwidth allocation. See Section 9 for further details 1180 about the frequency of reports. 1182 A Distribution Source MAY start out reporting Group size and switch 1183 to Receiver RTCP Bandwidth reporting later on and vice versa. If 1184 the Distribution Source does so, it SHOULD ensure that the 1185 correspondingly indicated values for the Receiver RTCP Bandwidth 1186 roughly match, i.e., are at least the same order of magnitude. 1188 In order to identify SSRC collisions, the Distribution Source is 1189 responsible for maintaining a record of each SSRC and the 1190 corresponding CNAME within at least one reporting interval by the 1191 group in order to differentiate between clients. It is RECOMMENDED 1192 that an updated list of more than one interval be maintained to 1193 increase accuracy. This mechanism should prevent the possibility of 1194 collisions since the combination of SSRC and CNAME should be unique, 1195 if the CNAME is generated correctly. If collisions are not 1196 detected, the Distribution Source will have an inaccurate impression 1197 of the group size. Since the statistical probability is very low 1198 that collisions will both occur and be undetectable, this should not 1199 be a significant concern. In particular, the clients would have to 1200 randomly select the same SSRC and have the same username + IP 1201 address (e.g., using private address space behind a NAT router). 1203 7.2.1 Receiver Report Aggregation 1205 The Distribution Source is responsible for aggregating reception 1206 quality information received in RR packets. In doing so, the 1207 Distribution Source MUST consider the report blocks received in 1208 every RR packet and MUST NOT consider the report blocks of an SR 1209 packet. 1211 RTCP with Unicast Feedback 1213 Note: the receivers will get the information contained in the SR 1214 packets anyway by packet forwarding so that duplication of this 1215 information should be avoided. 1217 For the optional sub-report blocks, the Distribution Source MAY 1218 decide which are the most significant feedback values to convey and 1219 MAY choose not to include any. The packet format provides 1220 flexibility in the amount of detail conveyed by the data points. 1221 There is a tradeoff between the granularity of the data and the 1222 accuracy of the data based on the multiplicative factor (MF), the 1223 number of buckets, and the min and max values. In order to focus on 1224 a particular region of a distribution, the Distribution Source can 1225 adjust the minimum and maximum values, and either increase the 1226 number of buckets and possibly the factorization, or decrease the 1227 number of buckets and provide more accurate values. See Appendix B 1228 for detailed examples on how to convey a summary of RTCP Receiver 1229 Reports as RSI sub-report block information. 1231 For each value the Distribution Source decides to include in an RSI 1232 packet, it MUST adhere to the following measurement rules. 1234 a) If the Distribution Source intends to use a sub-report to convey 1235 a distribution of values (sections 7.1.3 to 7.1.7), it MUST keep 1236 per receiver state, i.e., remember the last value V reported by 1237 the respective receiver. If a new value is reported by a 1238 receiver, the existing value MUST be replaced by the new one. 1239 The value MUST be deleted (along with the entire entry) if the 1240 receiver is timed out (as per section 6.3.5 of [1]) or has sent 1241 a BYE packet (as per section 6.3.7 of [1]). 1243 All the values collected in this way MUST be included in the 1244 creation of the subsequent distribution sub-report block. 1246 The results should correspond as closely as possible to the 1247 values received during the interval since the last report. The 1248 Distribution Source may stack as many sub-report blocks as 1249 required in order to convey different distributions. If the 1250 distribution size exceeds the largest packet length (1008 bytes 1251 data portion), more packets MAY be stacked with additional 1252 information (but in total SHOULD NOT exceed the path MTU). 1254 All stacked sub-reports MUST be internally consistent, i.e., 1255 generated from the same session data. Overlapping of 1256 distributions is therefore allowed, and variation in values 1257 should only occur as a result of data set granularity, with the 1258 more accurate bucket sizes taking precedence in the event that 1259 values differ. Non-divisible values MUST be rounded up or down 1260 to the closest bucket value, and the number of data buckets must 1261 always be an even number, padding where necessary with an 1262 additional zero bucket value to maintain consistency. 1264 Note: This intentionally provides persistent full coverage of 1265 the entire session membership to avoid oscillations due to 1266 changing membership samples. 1268 RTCP with Unicast Feedback 1270 b) If the Distribution Source intends to report a short summary 1271 using the General Statistics sub-report block format defined in 1272 section 7.1.10, for EACH of the values included in the report 1273 (AFL, HCNL, average interarrival jitter), it MUST keep a timer 1274 T_summary as well as a sufficient set of variables to calculate 1275 the summaries for the last three reporting intervals. 1277 The summary values are included here to reflect the current 1278 group situation. By recording the last three reporting intervals 1279 the Distribution Source incorporates reports from all members 1280 while allowing for individual RTCP receiver report packet 1281 losses. The process of collecting these values also aims to 1282 avoid resetting any of the values and then having to send out an 1283 RSI report based upon just a few values collected. 1285 The timer T_summary MUST be initialized as T_summary = 1.5*Td, 1286 where Td is the reporting interval, and MUST be updated 1287 following timer reconsideration whenever the group size or the 1288 average RTCP size ("avg_rtcp_size") changes. This choice should 1289 allow each receiver to report once per interval. 1291 Td 1292 __^__ 1293 t0/ \ t1 t2 t3 t4 t5 1294 ---+---------+---------+---------+---------+---------+-------> 1295 \____ ____/ : : : : 1296 : V : : : : : 1297 :T_summary: : : : : 1298 : =1.5*Td : : : : : 1299 \______________ ______________/ : : 1300 : V : : : 1301 : 3*T_summary : : 1302 : : : : 1303 \______________ ______________/ : 1304 : V : 1305 : 3*T_summary : 1306 : : 1307 \______________ ______________/ 1308 V 1309 3*T_summary 1311 Figure 2: Overview of summarization reporting 1313 Figure 2 depicts how the summarization reporting shall be 1314 performed. At time t3, the RTCP reports collected from t0 1315 through t3 are included in the RSI reporting, at time t4, those 1316 from t1 through t4, and so on. The RSI summary report sent MUST 1317 NOT include any RTCP report from more than three reporting 1318 intervals ago; e.g., the one sent at time t5, must not include 1319 reports received at the Distribution Source prior to t2. 1321 RTCP with Unicast Feedback 1323 7.2.2 Handling Other RTCP Packets from RTP receivers 1325 When following the Feedback Summary Model the Distribution Source 1326 MAY reflect any other RTCP packets of potential relevance to the 1327 receivers (such as APP, RTPFB, PSFB) to the receiver group and MAY 1328 decide not to forward other RTCP packets not needed as such by the 1329 receivers (such as BYE, RR, SDES because the Distribution Source 1330 performs collision resolution, group size estimation, and RR 1331 aggregation). The Distribution Source MUST NOT forward RR packets 1332 to the receiver group. 1334 If the Distribution Source is able to interpret and aggregate 1335 information contained in any RTCP packets other than RR, it MAY 1336 include the aggregated information along with the RSI packet in its 1337 own compound RTCP packet. 1339 Aggregation MAY be a null operation, i.e., the Distribution Source 1340 MAY simply append one or more RTCP packets from receivers to the 1341 compound RTCP packet (containing at least RR, SDES and RSI from the 1342 Distribution Source). 1344 Note: This is likely to be useful only for a few cases, e.g., 1345 to forward aggregated information from RTPFB Generic NACK 1346 packets and thereby maintain the damping property of [15]. 1348 Note: This entire processing rule implies that the flow of 1349 information contained in non-RR RTCP packets may terminate at 1350 the Distribution Source depending on its capabilities and 1351 configuration. 1353 The configuration of the RTCP SSM media session (expressed in SDP) 1354 MUST specify explicitly which processing the Distribution Source 1355 will apply to which RTCP packets. 1357 7.2.3 Receiver Report Forwarding 1359 If the Media Sender(s) are not part of the SSM group for RTCP packet 1360 reflection, the Distribution Source MUST either forward the RTCP RR 1361 and SDES packets received from the receivers to the Media Sender(s) 1362 or also send the RSI packets to the senders (if it knows that the 1363 Media Senders understand RTCP RSI packets). 1365 If the Distribution Source decides to forward RR and SDES packets 1366 unchanged, it MAY also forward any other RTCP packets to the 1367 senders. 1369 If the Distribution Source decides to forward RSI packets to the 1370 senders, the considerations of 7.2.2 apply. 1372 7.2.4 Handling Sender Reports 1373 RTCP with Unicast Feedback 1375 The Distribution Source also receives RTCP (including SR) packets 1376 from the RTP Media Senders. 1378 The Distribution Source MUST forward all RTCP packets from the Media 1379 Senders to the RTP receivers. 1381 If there is more than one Media Sender and these Media Senders do 1382 not communicate via ASM with the Distribution Source and each other, 1383 the Distribution Source MUST forward each RTCP packet from any one 1384 Media Sender to all other Media Senders. 1386 7.3 Disjoint Distribution Source and Feedback Target 1388 If the Distribution Source and the Feedback Target are Disjoint, the 1389 processing of the Distribution Source is limited by the amount of 1390 RTCP feedback information made available by the Feedback Target. 1392 The Feedback Target(s) MAY simply forward all RTCP packets incoming 1393 from the RTP receivers to the Distribution Source in which case the 1394 Distribution Source will have all the information available 1395 necessary to perform all the functions described above. 1397 The Feedback Target(s) MAY also perform aggregation of incoming RTCP 1398 packets and send only aggregated information to the Distribution 1399 Source. In this case, the Feedback Target(s) MUST use correctly 1400 formed RTCP packets to communicate with the Distribution Source and 1401 they MUT operate in concert with the Distribution Source so that the 1402 Distribution Source and the Feedback Target(s) appear operating as a 1403 single entity. The Feedback Target(s) MUST report their observed 1404 receiver group size to the Distribution Source, either explicitly by 1405 means of RSI packets or implicitly by forwarding all RR packets. 1407 Note: For example, for detailed statistics reporting, the 1408 Distribution Source and the Feedback Target(s) have to agree on 1409 a common reporting granularity so that the Distribution Source 1410 can aggregate the buckets incoming from various Feedback 1411 Targets into a coherent report sent to the receivers. 1413 The joint behavior or Distribution Source and Feedback Target(s) 1414 MUST be reflected in the (SDP-based) media session description as 1415 per 7.2.2. 1417 7.4 Receiver behavior 1419 An RTP receiver MUST process RSI packets and adapt session 1420 parameters such as the RTCP bandwidth based on the information 1421 received. The receiver no longer has a global view of the session, 1422 and will therefore be unable to receive information from individual 1423 receivers aside from itself. However, the information conveyed by 1424 the Distribution Source can be extremely detailed, providing the 1425 receiver with an accurate view of the session quality overall, 1426 without the processing overhead associated with listening to and 1427 analyzing all Receiver Reports. 1429 RTCP with Unicast Feedback 1431 The RTP receiver MUST process the report blocks contained in any RTP 1432 SR and RR packets to complete its view of the RTP session. 1434 The SSRC collision list MUST be checked against the SSRC selected by 1435 the receiver to ensure there are no collisions as MUST be incoming 1436 RTP packets from the Media Senders. A receiver observing RTP 1437 packets from a Media Sender with an SSRC that collides with its own 1438 chosen SSRC SHOULD change its own SSRC following the procedures of 1439 [1]. The receiver SHOULD do so immediately after noticing and 1440 before sending any (further) RTCP feedback messages. 1442 A Group and Average Packet size sub-report block is most likely to 1443 be appended to the RSI header (either a Group size sub-report or an 1444 RTCP Bandwidth sub-report MUST be included). The Group size n 1445 allows a receiver to calculate its share of the RTCP bandwidth, r. 1446 Given R, the total available RTCP bandwidth share for receivers (in 1447 the SSM RTP session) r = R/(n). For the group size calculation, the 1448 RTP receiver MUST NOT include the Distribution Source, i.e. the only 1449 RTP receiver sending RSI packets. 1451 The Receiver RTCP Bandwidth field MAY override this value. If the 1452 Receiver RTCP Bandwidth field is present, the receiver MUST use this 1453 value as its own RTCP reporting bandwidth r. 1455 If the RTCP Bandwidth field was used by the Distribution Source in 1456 an RTCP session but this field was not included in the last five 1457 RTCP RSI reports, the receiver MUST revert to calculating its 1458 bandwidth share based upon the Group size information. 1460 If the receiver has not obtained any RTCP RSI packets from the 1461 Distribution Source for a period of five times the sender reporting 1462 interval, it MUST cease transmitting RTCP receiver reports until the 1463 next RTCP RSI packet is received. 1465 The receiver can use the summarized data as desired. This data is 1466 most useful in providing the receiver with a more global view of the 1467 conditions experienced by other receivers, and enables the client to 1468 place itself within the distribution and establish the extent to 1469 which its reported conditions correspond to the group reports as a 1470 whole. The appendix B (section 16) provides further information and 1471 examples of data processing at the receiver. 1473 The receiver SHOULD assume that any sub-report blocks in the same 1474 packet correspond to the same data set received by the Distribution 1475 Source during the last reporting time interval. This applies to 1476 packets with multiple blocks, where each block conveys a different 1477 range of values. 1479 A receiver MUST NOT rely on all of the RTCP packets it sends 1480 reaching the Media Senders or any other receiver. While RR 1481 statistics will be aggregated, BYE packets processed, and SSRC 1482 collisions usually be announced, processing and/or forwarding of 1483 further RTCP packets is up to the discretion of the Distribution 1484 RTCP with Unicast Feedback 1486 Source and will be performed as specified in the session 1487 description. 1489 7.5 Media Sender Behavior 1491 Media Senders listen on a unicast or multicast transport address for 1492 RTCP reports sent by the receivers (and forwarded by the 1493 Distribution Source) or other Media Senders (optionally forwarded by 1494 the Distribution Source). 1496 Unlike in the case of the simple forwarding model, Media Senders 1497 MUST be able to process RSI packets from the Distribution Source to 1498 determine the group size and their own RTCP bandwidth share. Media 1499 Senders MUST also be capable of determining the group size (and 1500 their corresponding RTCP bandwidth share) from listening to 1501 (forwarded) RTCP RR and SR packets (as mandated in [1]). 1503 As long as they send RTP packets they MUST also send RTCP SRs as 1504 defined in [1]. 1506 A Media Sender that observes an SSRC collision with another entity 1507 that is not also a Media Sender MAY delay its own collision 1508 resolution actions as per [1] by 5*1.5*Td with Td being the 1509 deterministic calculated reporting interval for receivers to see 1510 whether the conflict still exists. SSRC collisions with other Media 1511 Senders MUST be acted upon immediately. 1513 Note: This gives precedence to Media Senders and places the 1514 burden of collision resolution on RTP receivers. 1516 8. Mixer/Translator issues 1518 The original RTP specification allows a session to use mixers and 1519 translators which help to connect heterogeneous networks into one 1520 session. There are a number of issues, however, which are raised by 1521 the unicast feedback model proposed in this document. The term 1522 'mixer' refers to devices that provide data stream multiplexing 1523 where multiple sources are combined into one stream. Conversely, a 1524 translator does not multiplex streams, but simply acts as a bridge 1525 between two distribution mechanisms, e.g., a unicast-to-multicast 1526 network translator. Since the issues raised by this document apply 1527 equally to either a mixer or translator, they are referred to from 1528 this point onwards as mixer-translator devices. 1530 A mixer-translator between distribution networks in a session must 1531 ensure that all members in the session receive all the relevant 1532 traffic to enable the usual operation by the clients. A typical use 1533 may be to connect an older implementation of an RTP client with an 1534 SSM distribution network, where the client is not capable of 1535 unicasting feedback to the source. In this instance the mixer- 1536 translator must join the session on behalf of the client and send 1537 RTCP with Unicast Feedback 1539 and receive traffic from the session to the client. Certain hybrid 1540 scenarios may have different requirements. 1542 8.1 Use of a mixer-translator 1544 The mixer-translator MUST adhere to the SDP description [5] for the 1545 single source session (Section 11) and use the feedback mechanism 1546 indicated. Receivers SHOULD be aware that by introducing a mixer- 1547 translator into the session, more than one Media Sender may be 1548 active in a session since the mixer-translator may be forwarding 1549 traffic from either multiple unicast sources or from an ASM session 1550 to the SSM receivers. Receivers SHOULD still forward unicast RTCP 1551 reports in the usual manner to the Distribution Source, which in 1552 this case would be the mixer-translator itself. It is RECOMMENDED 1553 that the simple packet reflection mechanism be used under these 1554 circumstances since attempting to coordinate RSI + summarization 1555 reporting between more than one source may be complicated unless the 1556 mixer-translator is capable of summarization. 1558 8.2 Encryption and Authentication issues 1560 Encryption and security issues are discussed in detail in Section 1561 11. A mixer-translator MUST be able to follow the same security 1562 policy as the client in order to unicast RTCP feedback to the 1563 source, and it therefore MUST be able to apply the same 1564 authentication and/or encryption policy required for the session. 1565 Transparent bridging, where the mixer-translator is not acting as 1566 the Distribution Source, and subsequent unicast feedback to the 1567 source is only allowed if the mixer-translator can conduct the same 1568 source authentication as required by the receivers. A translator may 1569 forward unicast packets on behalf of a client, but SHOULD NOT 1570 translate between multicast-to-unicast flows towards the source 1571 without authenticating the source of the feedback address 1572 information. 1574 9. Transmission interval calculation 1576 The Control Traffic Bandwidth referred to in [1] is an arbitrary 1577 amount that is intended to be supplied by a session management 1578 application (e.g., sdr [21]) or decided based upon the bandwidth of 1579 a single sender in a session. 1581 The RTCP transmission interval calculation remains the same as in 1582 the original RTP specification [1] or uses the algorithm in [10] 1583 when bandwidth modifiers have been specified for the session. 1585 9.1 Receiver RTCP Transmission 1587 If the Distribution Source is operating in Simple Feedback mode 1588 (which may be indicated in the corresponding session description for 1589 RTCP with Unicast Feedback 1591 the media session but which the receiver also notices from the 1592 absence of RTCP RSI packets), a receiver MUST calculate the number 1593 of other members in a session based upon its own SSRC count derived 1594 from the forwarded Sender and Receiver Reports it receives. The 1595 receiver MUST calculate the average RTCP packet size from all the 1596 RTCP packets it receives. 1598 If the Distribution Source is operating in Distribution Source 1599 Feedback Summary mode, the receiver MUST use either the Group size 1600 field and the average RTCP packet size field, or the Receiver 1601 Bandwidth Field from the respective sub-report blocks appended to 1602 the RSI packet. 1604 A receiver uses these values as input to the calculation of the 1605 deterministic calculated interval as per [1] and [10]. 1607 9.2 Distribution Source RTCP Transmission 1609 If operating in Simple Feedback mode, the Distribution Source MUST 1610 calculate the transmission interval for its Receiver Reports and 1611 associated RTCP packets based upon the above control traffic 1612 bandwidth and MUST count itself as RTP receiver. Receiver Reports 1613 will be forwarded as they arrive without further consideration. The 1614 Distribution Source MAY choose to validate that all or selected 1615 receivers roughly adhere to the calculated bandwidth constraints and 1616 MAY choose to drop excess packets for receivers that do not. In all 1617 cases, the average RTCP packet size is determined from the Media 1618 Senders' and receivers' RTCP packets forwarded and those originated 1619 by the Distribution Source. 1621 If operating in Distribution Source Feedback Summary mode, the 1622 Distribution Source does not share the forward RTCP bandwidth with 1623 any of the receivers. Therefore, the Distribution Source SHOULD use 1624 the full RTCP bandwidth for its receiver reports and associated RTCP 1625 packets, as well as RTCP RSI packets. In this case, the average 1626 RTCP packet size is only determined from the RTCP packets originated 1627 by the Distribution Source. 1629 The Distribution Source uses these values as input to the 1630 calculation of the deterministic calculated interval as per [1] and 1631 [10]. 1633 9.3 Media Senders RTCP Transmission 1635 In Simple Feedback Mode, the Media Senders obtain all RTCP SRs and 1636 RRs as they would in an ASM session, except that the packets are 1637 forwarded by the Distribution Source. They MUST perform their RTCP 1638 group size estimate and calculation of the deterministic 1639 transmission interval as per [1] and [10]. 1641 In Distribution Source Feedback Summary Mode, the Media Senders 1642 obtain all RTCP SRs as they would in an ASM session. They receive 1643 either RTCP RR reports as in ASM (in case these packets are 1644 RTCP with Unicast Feedback 1646 forwarded by the Distribution Source) or RSI packets containing 1647 summaries. In the former case, they MUST perform their RTCP group 1648 size estimate and calculation of the deterministic transmission 1649 interval as per [1] and [10]. In the latter case, they MUST combine 1650 the information obtained from the Sender Reports and the RSI packets 1651 to create a complete view of the group size and the average RTCP 1652 packet size and perform the calculation of the deterministic 1653 transmission interval as per [1] and [10] based upon these input 1654 values. 1656 9.4 Operation in conjunction with AVPF 1658 If the RTP session is an AVPF session [15] (as opposed to a regular 1659 AVP [6] session the receivers MAY modify their RTCP report 1660 scheduling as defined in [15]. Use of AVPF does not affect the 1661 Distribution Source's RTCP transmission or forwarding behavior. 1663 It is RECOMMENDED that a Distribution Source and possible separate 1664 Feedback Target(s) be configured to forward AVPF-specific RTCP 1665 packets in order not to counteract the damping mechanism built into 1666 AVPF; optionally, they MAY aggregate the feedback information from 1667 the receivers as per section 7.2.2. If only generic feedback 1668 packets are in use that are understood by the Distribution Source 1669 and that can easily be aggregated, the Distribution MAY combine 1670 several incoming RTCP feedback packets and forward the aggregate 1671 along with its next RTCP RR/RSI packet. In any case, the 1672 Distribution Source and Feedback Target(s) SHOULD minimize the extra 1673 delay when forwarding feedback information but the Distribution 1674 Source MUST stay within its RTCP bandwidth constraints. 1676 In the event that specific APP packets without a format and 1677 summarization mechanism understood by the Distribution Source are to 1678 be used, it is RECOMMENDED that such packets are forwarded. 1679 Otherwise, the capability of receiver to send timely feedback 1680 messages is likely to be affected. 1682 10. SDP Extensions 1684 The Session Description Protocol (SDP) [5] is used as a means to 1685 describe media sessions in terms of their transport addresses, 1686 codecs, and other attributes. Providing RTCP feedback via unicast as 1687 specified in this document constitutes another session parameter 1688 needed in the session description. Similarly, other single-source 1689 multicast RTCP feedback parameters need to be provided, such as the 1690 summarisation mode at the sender and the target unicast address to 1691 which to send feedback information. This section defines the SDP 1692 parameters that are needed by the proposed mechanisms in this 1693 document (and that also need to be registered with IANA). 1695 10.1 SSM RTCP Session Identification 1696 RTCP with Unicast Feedback 1698 A new session level attributes MUST be used to indicate the use of 1699 unicast instead of multicast feedback: "rtcp-unicast". 1701 This attribute uses one parameter to specify the mode of operation. 1702 An optional set of parameters specifies the behavior for RTCP packet 1703 types (and subtypes). 1705 rtcp-unicast:reflection 1707 This attribute MUST be used to indicate the "Simple Feedback" 1708 mode of operation where packet reflection is used by the RTCP 1709 target (without further processing). 1711 If no RTCP payload types are given, the default 1713 rtcp-unicast:rsi [:]* 1715 This attribute MUST be used to indicate the "Distribution 1716 Source Feedback Summary" mode of operation. In this mode, a 1717 list or parameters may be used to explicitly specify how which 1718 RTCP packets originated by receivers are handled. Options for 1719 handling are: 1721 aggr: The Distribution Source has means for aggregating the 1722 contents of the RTCP packets and will do so. 1724 forward: The Distribution Source will forward the RTCP packet 1725 unchanged. 1727 term: The Distribution Source will terminate the RTCP 1728 packet. 1730 The default rules applying if no parameters are specified are as 1731 follows: 1733 RR and SDES packets MUST be aggregated and MUST lead to RSI 1734 packets being generated. All other RTP packets MUST be 1735 terminated at the Distribution Source (or Feedback Target(s). 1737 The SDP description needs only specify deviations from the 1738 default rules. Aggregation of RR packets and forwarding of SR 1739 packet MUST NOT be changed. 1741 The token for the new SDP attribute is "rtcp-unicast" and the formal 1742 SDP ABNF syntax for the new attribute value is as follows: 1744 att-value = "reflection" 1745 / "rsi" [rsi-rule] 1747 rsi-rule = processing ":" rtcp-type SP rsi-rule 1748 / processing ":" rtcp-type 1750 processing = "aggr" / "forward" / "term" / token ;keep it extensible 1751 RTCP with Unicast Feedback 1753 rtcp-type = 3*3DIGIT ; the RTCP type (192, 193, 202--208) 1755 10.2 SSM Source Specification 1757 In addition, in a Source-Specific Multicast RTCP session, the 1758 Distribution Source needs to be indicated for both source-specific 1759 joins to the multicast group, as well as for addressing unicast RTCP 1760 packets on the backchannel from receivers to the Distribution 1761 Source. 1763 This is achieved by following the proposal for SDP source filters 1764 documented in [4]. According to the specification, for SSM RTCP only 1765 the inclusion mode ("a=source-filter:incl") MUST be used. 1767 There SHOULD be exactly one "a=source-filter:incl" attribute listing 1768 the address of the sender. The RTCP port MUST be derived from the 1769 m= line of the media description. 1771 An alternative Distribution Source feedback address and port MAY be 1772 supplied using the SDP RTCP attribute [7], e.g., a=rtcp: IN 1773 IP4 192.168.1.1. 1775 Two "source-filter" attributes MAY be present to indicate an IPv4 1776 and an IPv6 representation of the Distribution Source address. 1778 11. Security Considerations 1780 The level of security provided by the current RTP/RTCP model MUST 1781 NOT be diminished by the introduction of unicast feedback to the 1782 source. This section identifies the security weaknesses introduced 1783 by the feedback mechanism, potential threats, and level of 1784 protection that MUST be adopted. Any suggestions on increasing the 1785 level of security provided to RTP sessions above the current 1786 standard are RECOMMENDED but OPTIONAL. The final section outlines 1787 some security frameworks that are suitable to conform to this 1788 specification. 1790 11.1 Assumptions 1792 RTP/RTCP is a protocol that carries real-time multimedia traffic, 1793 and therefore a main requirement is for any security framework to 1794 maintain as low overhead as possible. This includes the overhead of 1795 different applications and types of cryptographic operations, as 1796 well as the overhead to deploy or to create security infrastructure 1797 for large groups. 1799 Although the distribution of session parameters, typically encoded 1800 as SDP objects, through SAP [22], e-mail, or the web, is beyond the 1801 scope of this document, it is RECOMMENDED that the distribution 1802 method employs adequate security measures to ensure the integrity 1803 and authenticity of the information. Suitable solutions that meet 1804 RTCP with Unicast Feedback 1806 the security requirements outlined here are included at the end of 1807 this section. 1809 In practice, the multicast and group distribution mechanism, e.g., 1810 the SSM routing tree, is not immune to source IP address spoofing or 1811 traffic snooping, however such concerns are not discussed here. In 1812 all the following discussions, security weaknesses are addressed 1813 from the transport level or above. 1815 11.2 Security threats 1817 Attacks on media distribution and the feedback architecture proposed 1818 in this document may take a variety of forms. An outline of the 1819 types of attacks in detail: 1821 a) Denial of Service (DoS) 1823 DoS is a major area of concern. Due to the nature of the 1824 communication architecture a DoS can be generated in a number of 1825 ways by using the unicast feedback channel to the attackers 1826 advantage. 1828 b) Packet Forgery 1830 Another potential area for attack is packet forgery. In 1831 particular, it is essential to protect the integrity of certain 1832 influential packets since compromise could directly affect the 1833 transmission characteristics of the whole group. 1835 c) Session Replay 1837 The potential for session recording and subsequent replay is an 1838 additional concern. An attacker may not actually need to 1839 understand packet content, but simply have the ability to record 1840 the data stream and, at a later time, replay it to any receivers 1841 that are listening. 1843 d) Eavesdropping on a session 1845 The consequences of an attacker eavesdropping on a session 1846 already constitutes a security weakness; in addition, it might 1847 benefit other types of attack, and is therefore considered a 1848 potential threat. For example, an attacker might be able to use 1849 the eavesdropped information to perform an intelligent DoS 1850 attack. 1852 11.3 Architectural Contexts 1854 To better understand the requirements of the solution, the threats 1855 outlined above are addressed for each of the two communication 1856 contexts: 1858 RTCP with Unicast Feedback 1860 a) Source-to-Receiver communication 1862 The downstream communication channel, from the source to the 1863 receivers, is critical to protect as it controls the behavior of 1864 the group; it conveys the bandwidth allocation for each receiver 1865 and hence the rate at which the RTCP traffic is unicast directly 1866 back to the source. All traffic that is distributed over the 1867 downstream channel is generated by a single source. Both the RTP 1868 data stream and the RTCP control data from the source are 1869 included in this context, with the RTCP data generated by the 1870 source being indirectly influenced by the group feedback. 1872 The downstream channel is vulnerable to four types of attacks. A 1873 denial of service attack is possible, but less of a concern. The 1874 worst case effect would be the transmission of large volumes of 1875 traffic over the distribution channel with the potential to reach 1876 every receiver, but only on a one-to-one basis. Consequently, 1877 this threat is no more pronounced than the current multicast ASM 1878 model. The real danger of denial of service attacks in this 1879 context comes indirectly via compromise of the source RTCP 1880 traffic. If receivers are provided with an incorrect group size 1881 estimate or bandwidth allowance, the return traffic to the source 1882 may create a distributed DoS effect on the source. Similarly, an 1883 incorrect feedback address whether as a result of a malicious 1884 attack or by mistake, e.g., an IP address configuration (e.g., 1885 typing) error, could directly create a denial of service attack 1886 on another host. 1888 An additional concern relating to Denial of Service attacks would 1889 come indirectly through the generation of fake BYE packets 1890 causing the source to adjust the advertised group size. A 1891 Distribution Source MUST follow the correct rules for timing out 1892 members in a session prior to reporting a change in the group 1893 size, which allows the authentic SSRC sufficient time to continue 1894 to report and consequently cancel the fake BYE report. 1896 The danger of Packet Forgery in the worst case may be to 1897 maliciously instigate a denial of service attack, e.g., if an 1898 attacker were capable of spoofing the source address and 1899 injecting incorrect packets into the data stream or intercepting 1900 the source RTCP traffic and modifying the fields. 1902 The Replay of a Session would have the effect of recreating the 1903 receiver feedback to the source address at a time when the source 1904 is not expecting additional traffic from a potentially large 1905 group. The consequence of this type of attack may be less 1906 effective on its own, but in combination with other attacks might 1907 be serious. 1909 Eavesdropping on the session would provide an attacker with 1910 information on the characteristics of the source-to-receiver 1911 traffic such as the frequency of RTCP traffic. If RTCP traffic is 1912 unencrypted, this might also provide valuable information on 1913 RTCP with Unicast Feedback 1915 characteristics such as group size and transmission 1916 characteristics of the receivers back to the source. 1918 b) Receiver-to-Distribution-Source communication 1920 The second context is the return traffic from the group to the 1921 Distribution Source. This traffic should only consist of RTCP 1922 packets, and should include receiver reports, SDES information, 1923 BYE reports, extended reports (XR), feedback messages (RTPFB, 1924 PSFB) and possibly Application specific packets. The effects of 1925 compromise on a single or subset of receivers is not likely to 1926 have as great an impact as the context (a), however much of the 1927 responsibility for detecting compromise of the source data stream 1928 relies on the receivers. 1930 The effects of compromise of critical Distribution Source control 1931 information would be amplified most seriously in this context. A 1932 large group of receivers may unwittingly generate a distributed 1933 DoS attack on the Distribution Source in the event that the 1934 integrity of the source RTCP channel has been compromised and is 1935 not detected by the individual receivers. 1937 An attacker capable of instigating a Packet Forgery attack could 1938 introduce false RTCP traffic and create fake SSRC identifiers. 1939 Such attacks might slow down the overall control channel data 1940 rate, since an incorrect perception of the group size may be 1941 created. Similarly, the creation of fake BYE reports by an 1942 attacker would cause some group size instability, but should not 1943 be effective as long as the correct timeout rules are applied by 1944 the source in removing SSRC entries from its database. 1946 A replay attack on receiver return data to the source would have 1947 the same implications as the generation of false SSRC identifiers 1948 and RTCP traffic to the source. Therefore, ensuring authenticity 1949 and freshness of the data source is important. 1951 Eavesdropping in this context potentially provides an attacker 1952 with a great deal of potentially personal information about a 1953 large group of receivers available from SDES packets. It would 1954 also provide an attacker with information on group traffic 1955 generation characteristics and parameters for calculating 1956 individual receiver bandwidth allowances. 1958 11.4 Requirements in each context 1960 To address these threats, this section presents the security 1961 requirements for each context. 1963 a) The main threat in the source-to-receiver context concerns denial 1964 of service attacks through possible packet forgery. The forgery 1965 may take the form of interception and modification of packets 1966 from the source, or simply injecting false packets into the 1967 distribution channel. To combat these attacks, data integrity and 1968 RTCP with Unicast Feedback 1970 source authenticity MUST be applied to source traffic. Since the 1971 consequences of eavesdropping do not affect the operation of the 1972 protocol, confidentiality is not a requirement in this context. 1973 However without confidentiality, access to personal and group 1974 characteristics information would be unrestricted to an external 1975 listener. Therefore confidentiality is RECOMMENDED. 1977 b) The threats in the receiver-to-source context also concern the 1978 same kinds of attacks but are considered less important than the 1979 downstream traffic compromise. All the security weaknesses are 1980 also applicable to the current RTP/RTCP security model and 1981 therefore only recommendations are made towards protection from 1982 compromise. Data integrity is RECOMMENDED to ensure that 1983 interception and modification of an individual receiver's RTCP 1984 traffic can be detected. This would protect against the false 1985 influence of group control information and the potentially more 1986 serious compromise of future services provided by the 1987 distribution functionality. In order to ensure security, data 1988 integrity and authenticity of receiver traffic is therefore also 1989 RECOMMENDED. The same situation applies as in the first context 1990 with respect to data confidentiality, and it is RECOMMENDED that 1991 precautions should be taken to protect the privacy of the data. 1993 An additional security consideration that is not a component of this 1994 specification but has a direct influence upon the general security 1995 is the origin of the session initiation data. This involves the SDP 1996 parameters that are communicated to the members prior to the start 1997 of the session via channels such as an HTTP server, email, SAP, or 1998 other means. It is beyond the scope of this document to place any 1999 strict requirements on the external communication of such 2000 information, however suitably secure SDP communication approaches 2001 are outlined in section 11.7. 2003 11.5 Discussion of trust models 2005 As identified in the previous sections, source authenticity is a 2006 fundamental requirement of the protocol. However, it is important to 2007 also clarify the model of trust that would be acceptable to achieve 2008 this requirement. There are two fundamental models that apply in 2009 this instance: 2011 a) The shared key model where all authorized group members share the 2012 same key and can equally encrypt/decrypt the data. This method 2013 assumes that an out-of-band method is applied to the distribution 2014 of the shared group key ensuring that every key-holder is 2015 individually authorized to receive the key, and in the event of 2016 member departures from the group, a re-keying exercise can occur. 2017 The advantage of this model is that the costly processing 2018 associated with one-way key authentication techniques is avoided, 2019 as well as the need to execute additional cipher operations with 2020 alternative key sets on the same data set, e.g., in the event 2021 that data confidentiality is also applied. The disadvantage is 2022 that, for very large groups where the receiver set becomes 2023 RTCP with Unicast Feedback 2025 effectively untrusted, a shared key does not offer much 2026 protection. 2028 b) The public-key authentication model, using cryptosystems such as 2029 RSA-based or PGP authentication, provides a more secure method of 2030 source authentication at the expense of generating higher 2031 processing overhead. This is typically not recommended for Real- 2032 time data streams, but in the case of RTCP reports which are 2033 distributed with a minimum interval of 5 seconds, this may be a 2034 viable option (the processing overhead might still be too great 2035 for small, low-powered devices and should therefore be considered 2036 with caution). Wherever possible, however, the use of public key 2037 source authentication is preferable to the shared key model 2038 identified above. 2040 As concerns requirements for protocol acceptability, either model is 2041 acceptable, although it is RECOMMENDED that the more secure public- 2042 key based options should be applied wherever possible. 2044 11.6 Recommended security solutions 2046 This section presents some existing security mechanisms that are 2047 RECOMMENDED to suitably address the requirements outlined in section 2048 11.5. This is only intended as a guideline and it is acknowledged 2049 that there are other solutions that would also be suitable to be 2050 compliant with the specification. 2052 11.6.1 Secure Distribution of SDP Parameters 2054 a) SAP, HTTPS, Email -- Initial distribution of the SDP parameters 2055 for the session SHOULD use a secure mechanism such as the SAP 2056 authentication framework which allows an authentication 2057 certificate to be attached to the session announcements. Other 2058 methods might involve HTTPS or signed email content from a 2059 trusted source. However, some more commonly used techniques for 2060 distributing session information and starting media streams are 2061 RTSP [13] and SIP [14]. 2063 b) RTSP -- RTSP provides a client or server initiated stream control 2064 mechanism for real-time multimedia streams. The session 2065 parameters are conveyed using SDP syntax and may adopt standard 2066 HTTP authentication mechanisms in combination with suitable 2067 network (e.g. IPSEC) or transport (e.g. TLS) level security. 2069 c) SIP -- A typical use of SIP involving a unicast feedback 2070 identifier might be a client wishing to dynamically join a multi- 2071 party call on a multicast address using unicast RTCP feedback. 2072 The client would be required to authenticate the SDP session 2073 descriptor information returned by the SIP server. The 2074 recommended method for this, as outlined in the SIP specification 2075 [14], is to use an S/MIME message body containing the session 2076 parameters signed with an acceptable certificate. 2078 RTCP with Unicast Feedback 2080 For the purposes of this profile, it is acceptable to use any 2081 suitably secure authentication mechanism which establishes the 2082 identity and integrity of the information provided to the client. 2084 11.6.2 Suitable Security Solutions for RTP Sessions with Unicast 2085 Feedback 2087 a) SRTP -- SRTP is the recommended AVT security framework for RTP 2088 sessions. It specifies the general packet formats and cipher 2089 operations that are used, and provides the flexibility to select 2090 different stream ciphers based on preference/requirements. It can 2091 provide confidentiality of the RTP and RTCP packets as well as 2092 protection against integrity compromise and replay attacks. It 2093 provides authentication of the data stream using the shared key 2094 trust model. Any suitable key-distribution mechanism can be used in 2095 parallel to the SRTP streams. 2097 b) IPSEC -- A more general group security profile which might be 2098 used is the Group Domain of Interpretation [23], which defines the 2099 process of applying IPSec mechanisms to multicast groups. This 2100 requires the use of ESP in tunnel mode as the framework and it 2101 provides the capability to authenticate either using a shared key or 2102 individually through public-key mechanisms. It should be noted that 2103 using IPSec would break the 'transport independent' condition of RTP 2104 and would therefore not be useable for anything other than IP based 2105 communication. 2107 c) TESLA - TESLA [24] is a scheme that provides a more flexible 2108 approach to data authentication using time-based key disclosure. The 2109 authentication uses one-way pseudo-random key functions based on key 2110 chain hashes that have a short period of authenticity based on the 2111 key disclosure intervals from the source. As long as the receiver 2112 can ensure that the encrypted packet is received prior to the key 2113 disclosure by the source, this requires loose time synchronization 2114 between source and receivers, it can prove the authenticity of the 2115 packet. The scheme does introduce a delay into the packet 2116 distribution/decryption phase due to the key disclosure delay 2117 however the processing overhead is much lower than other standard 2118 public-key mechanisms and therefore may be more suited to small or 2119 energy-restricted devices. 2121 11.6.3 Secure Key Distribution Mechanisms 2123 a) MIKEY -- MIKEY [12] is the preferred solution for SRTP sessions 2124 providing a shared group key distribution mechanism and intra- 2125 session rekeying facilities. If a partly protected communication 2126 channel exists, keys may also be conveyed using SDP as per [27]. 2128 b) GSAKMP -- GSAKMP is the general solution favored for Multicast 2129 Secure group key distribution. It is the recommended key 2130 distribution solution for GDOI sessions. 2132 RTCP with Unicast Feedback 2134 12. Backwards Compatibility 2136 The use of unicast feedback to the source should not present any 2137 serious backwards compatibility issues. The RTP data streams should 2138 remain unaffected, as are the RTCP packets from the media source(s) 2139 that continue to enable inter-stream synchronization in the case of 2140 multiple streams. The unicast transmission of RTCP data to a source 2141 that does not have the ability to redistribute the traffic either by 2142 simple reflection or through summaries could have serious security 2143 implications as outlined in Section 11, but would not actually break 2144 the operation of RTP. For RTP-compliant receivers that do not 2145 understand the unicast mechanisms, the RTCP traffic may still reach 2146 the group, in the event that an ASM distribution network is used, in 2147 which case there may be some duplication of traffic due to the 2148 reflection channel, but this should be ignored. It is anticipated, 2149 however, that typically the distribution network will not enable the 2150 receiver to multicast RTCP traffic, in which case the data will be 2151 lost, and the RTCP calculations will not include those receivers. It 2152 is RECOMMENDED that any session that may involve non-unicast capable 2153 clients should always use the simple packet reflection mechanism to 2154 ensure that the packets received can be understood by all clients. 2156 13. IANA Considerations 2158 The following contact information shall be used for all 2159 registrations included here: 2161 Contact: Joerg Ott 2162 mailto:jo@acm.org 2163 tel:+358-9-451-2460 2165 Based on the guidelines suggested in [2], this document proposes 1 2166 new RTCP packet format to be registered with the RTCP Control Packet 2167 type (PT) Registry: 2169 Name: RSI 2170 Long name: Receiver Summary Information 2171 Value: 208 2172 Reference: This document. 2174 This document defines a substructure for RTCP RSI packets. A new 2175 sub-registry needs to be set up for the sub-report block type (SRBT) 2176 values for the RSI packet, with the following registrations created 2177 initially: 2179 Name: IPv4 Address 2180 Long name: IPv4 Feedback Target Address 2181 Value: 0 2182 Reference: This document. 2184 RTCP with Unicast Feedback 2186 Name: IPv6 Address 2187 Long name: IPv6 Feedback Target Address 2188 Value: 1 2189 Reference: This document. 2191 Name: DNS Name 2192 Long name: DNS Name indicating Feedback Target Address 2193 Value: 2 2194 Reference: This document. 2196 Name: Loss 2197 Long name: Loss distribution 2198 Value: 4 2199 Reference: This document. 2201 Name: Jitter 2202 Long name: Jitter Distribution 2203 Value: 5 2204 Reference: This document. 2206 Name: RTT 2207 Long name: Round-trip time distribution 2208 Value: 6 2209 Reference: This document. 2211 Name: Cumulative loss 2212 Long name: Cumulative loss distribution 2213 Value: 7 2214 Reference: This document. 2216 Name: Collisions 2217 Long name: SSRC Collision list 2218 Value: 8 2219 Reference: This document. 2221 Name: Stats 2222 Long name: General statistics 2223 Value: 10 2224 Reference: This document. 2226 Name: RTCP BW 2227 Long name: RTCP Bandwidth indication 2228 Value: 11 2229 Reference: This document. 2231 Name: Group Info 2232 Long name: RTCP Group and Average Packet size 2233 Value: 12 2234 Reference: This document. 2236 RTCP with Unicast Feedback 2238 The value 3 shall be reserved for a further way of specifying a 2239 feedback target address. The value 3 MUST only be allocated for a 2240 use defined in an IETF Standards Track document. 2242 Further values may be registered on a first-come first-serve 2243 basis. For each new registration, it is mandatory that a 2244 permanent, stable, and publicly accessible document exists that 2245 specifies the semantics of the registered parameter as well as the 2246 syntax and semantics of the associated sub-report block. The 2247 general registration procedures of [5] apply. 2249 In the registry for SDP parameters, the attribute name "unicast- 2250 rtcp" needs to be registered: 2252 Name: unicast-rtcp 2253 Long name: RTCP Unicast feedback address 2254 Reference: This document. 2256 14. Bibliography 2258 14.1 Normative References 2260 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP - 2261 A Transport Protocol for Real-time Applications," RFC 3550 (STD 2262 64), July 2003. 2264 [2] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 2265 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 2267 [3] M. Baugher, D. McGrew, D. Oran, R. Blom, E. Carrara, M. Naslund, 2268 and K. Norrman, "The Secure Real Time Transport Protocol", RFC 2269 3711, March 2004. 2271 [4] B. Quinn, R. Finlayson, "SDP Source-Filters", Internet Draft 2272 draft-ietf-mmusic-sdp-srcfilter-10.txt, Work in Progress, 2273 September 2005. 2275 [5] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session 2276 Description Protocol", Internet Draft draft-ietf-mmusic-sdp-new- 2277 25.txt, Work in Progress, July 2005. 2279 [6] H. Schulzrinne, S. Casner, "RTP Profile for Audio and Video 2280 Conferences with Minimal Control", RFC 3551 (STD 65), July 2003. 2282 [7] C. Huitema, "RTCP Attribute in SDP", RFC 3605, October 2003. 2284 [8] D. Meyer, R. Rockell, G. Shepherd, "Source-Specific Protocol 2285 Independent Multicast in 232/8", Internet Draft draft-ietf- 2286 mboned-ssm232-08.txt, Work in Progress, March 2004. 2288 RTCP with Unicast Feedback 2290 [9] H. Holbrook, B. Cain, B. Haberman, "Using IGMPv3 For Source- 2291 Specific Multicast", Internet Draft draft-holbrook-idmr-igmpv3- 2292 ssm-08.txt, Work in Progress, October 2004. 2294 [10] S. Casner, "Session Description Protocol (SDP) Bandwidth 2295 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 2296 July 2003. 2298 [11] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2299 3629, November 2003. 2301 14.2 Informative References 2303 [12] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman, 2304 "MIKEY: Multimedia Internet Keying", RFC 3830, August 2004. 2306 [13] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming 2307 Protocol (RTSP)", RFC 2326, April 1998. 2309 [14] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 2310 Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session 2311 Initiation Protocol", RFC 3261, June 2002. 2313 [15] J. Ott, S. Wenger, N. Sato, C. Burmeister, and J. Rey, " 2314 Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 2315 Internet Draft draft-ietf-ietf-avt-rtcp-feedback-11.txt, August 2316 2004. 2318 [16] Pusateri, T, "Distance Vector Multicast Routing Protocol", 2319 Internet Draft draft-ietf-idmr-dvmrp-v3-11.txt, Work in 2320 Progress, October 2003. 2322 [17] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 2323 Independent Multicast - Sparse Mode (PIM-SM): Protocol 2324 Specification (Revised)", Internet Draft, draft-ietf-pim-sm-v2- 2325 new-11.txt, Work in Progress, October 2004. 2327 [18] Adams, A, Nicholas, J, Siadak, W, "Protocol Independent 2328 Multicast- Dense Mode (PIM-DM)", RFC 3973, January 2005. 2330 [19] Bates, T, Rekhter, Y, Chandra, R, Katz, D, "Multiprotocol 2331 Extension fo BGP-4", RFC 2858, June 2000. 2333 [20] D. Meyer, B. Fenner, "Multicast Source Discovery Protocol 2334 (MSDP)", Experimental RFC 3618, October 2003. 2336 [21] Session Directory Rendez-vous (SDR), developed at University 2337 College London by Mark Handley and the Multimedia Research 2338 Group, http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/. 2340 [22] M. Handley, C. Perkins, E. Whelan, "Session Announcement 2341 Protocol (SAP)", RFC 2974, October 2000. 2343 RTCP with Unicast Feedback 2345 [23] M. Baugher, T. Hardjono, H. Harney, and B. Weis, "The Group 2346 Domain of Interpretation", RFC 3547, July 2003. 2348 [24] A. Perrig, D. Song, R. Canetti, D. Tygar, B. Briscoe, "TELSA: 2349 Multicast Source Authentication Transform Introduction", RFC 2350 4082, June 2005. 2352 [25] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", 2353 Netscape Communications Corp., Nov 18, 1996. 2355 [26] T. Friedman, R. Caceres, and A. Clark (eds), "RTCP Reporting 2356 Extensions", RFC 3611, November 2003. 2358 [27] F. Andreasen, M. Baugher, and D. Wing, "Session Description 2359 Protocol Security Descriptions for Media Streams", Internet 2360 Draft draft-ietf-mmusic-sdescriptions-12.txt, September 2005. 2362 RTCP with Unicast Feedback 2364 15. Appendix A: Examples for Sender Side Configurations 2366 This appendix describes a few common setups focusing on the 2367 contribution side, i.e., the communications between the Media 2368 Sender(s) and the Distribution Source. In all cases, the same 2369 session description may be used for the distribution side as defined 2370 in the main part of this document. This is because this 2371 specification defines only the media stream setup between the 2372 Distribution Source and the receivers. 2374 15.1 One Media Sender identical to the Distribution Source 2376 In the simplest case, the Distribution Source is identical to the 2377 Media Sender as depicted in figure 2. Obviously, no further 2378 configuration for the interaction between the Media Sender and the 2379 Distribution Source is necessary. 2381 Source-specific 2382 +--------+ Multicast 2383 | | +----------------> R(1) 2384 |M D S | | | 2385 |E I O | +--+ | 2386 |D S U | | | | 2387 |I T R | | +-----------> R(2) | 2388 |A R C |->+----- : | | 2389 | = I E | | +------> R(n-1) | | 2390 |S B | | | | | | 2391 |E U | +--+--> R(n) | | | 2392 |N T | | | | | 2393 |D I |<---------+ | | | 2394 |E O |<---------------+ | | 2395 |R N |<--------------------+ | 2396 | |<-------------------------+ 2397 +--------+ Unicast 2399 Figure 2: Media Source == Distribution Source 2401 15.2 One Media Sender 2403 In a slightly more complex scenario, the Media Sender and the 2404 Distribution Source are separate entities running on the same or 2405 different machines. Hence, the Media Sender needs to deliver the 2406 media stream(s) to the Distribution Source. This can be done 2407 either via unicasting the RTP stream or via ASM multicast. In 2408 this case, the Distribution Source is responsible for forwarding 2409 the RTP packets comprising the media stream and the RTCP sender 2410 reports towards the receivers and conveying feedback from the 2411 receivers, as well as from itself, to the Media Sender. 2413 This scenario is depicted in figure 3. The communication setup 2414 between the Media Sender and the Distribution Source may be 2415 statically configured or SDP may be used in conjunction with some 2416 signaling protocol to convey the session parameters. Note that it 2417 RTCP with Unicast Feedback 2419 is a local configuration matter of the Distribution Source how to 2420 associate a session between the Media Sender and itself (the 2421 Contribution session) with the corresponding session between 2422 itself and the receivers (the Distribution session). 2424 Source-specific 2425 +-----+ Multicast 2426 | | +----------------> R(1) 2427 | D S | | | 2428 | I O | +--+ | 2429 | S U | | | | 2430 +--------+ | T R | | +-----------> R(2) | 2431 | Media |<---->| R C |->+----- : | | 2432 | Sender | | I E | | +------> R(n-1) | | 2433 +--------+ | B | | | | | | 2434 | U | +--+--> R(n) | | | 2435 | T | | | | | 2436 | I |<---------+ | | | 2437 | O |<---------------+ | | 2438 | N |<--------------------+ | 2439 | |<-------------------------+ 2440 +-----+ Unicast 2442 Contribution Distribution 2443 Session Session 2444 (unicast or ASM) (SSM) 2446 Figure 3: One Media Sender Separate from Distribution Source 2448 15.3 Three Media Senders, Unicast Contribution 2450 Similar considerations apply if three media senders transmit to an 2451 SSM multicast group via the Distribution Source and individually 2452 sent their media stream RTP packets via unicast to the Distribution 2453 Source. 2455 In this case, the responsibilities of the Distribution Source are a 2456 superset to the previous case: the Distribution Source also needs to 2457 relay media traffic from each Media Sender to the receivers and to 2458 forward (aggregated) feedback from the receivers to the Media 2459 Senders. In addition, the Distribution Source relays RTCP packets 2460 (SRs) from each Media Sender to the other two. 2462 The configuration of the Media Senders is identical to the previous 2463 case. It is just the Distribution Source that must be aware that 2464 there are multiple senders and then perform the necessary relaying. 2465 The transport address for the RTP session at the Distribution Source 2466 may be identical for all Media Senders (which may make correlation 2467 easier) or different addresses may be used. 2469 This setup is depicted in figure 4. 2471 RTCP with Unicast Feedback 2473 Source-specific 2474 +-----+ Multicast 2475 +--------+ | | +----------------> R(1) 2476 | Media |<---->| D S | | | 2477 |Sender 1| | I O | +--+ | 2478 +--------+ | S U | | | | 2479 | T R | | +-----------> R(2) | 2480 +--------+ | R C |->+----- : | | 2481 | Media |<---->| I E | | +------> R(n-1) | | 2482 |Sender 2| | B | | | | | | 2483 +--------+ | U | +--+--> R(n) | | | 2484 | T | | | | | 2485 +--------+ | I |<---------+ | | | 2486 | Media |<---->| O |<---------------+ | | 2487 |Sender 3| | N |<--------------------+ | 2488 +--------+ | |<-------------------------+ 2489 +-----+ Unicast 2491 Contribution Distribution 2492 Session Session 2493 (unicast) (SSM) 2495 Figure 4: Three Media Senders, unicast contribution 2497 15.4 Three Media Senders, ASM Contribution Group 2499 In this final example, the individual unicast contribution 2500 sessions between the Media Senders and the Distribution Source are 2501 replaced by a single ASM contribution group (i.e., a single common 2502 RTP session). Consequently, all Media Senders receive each 2503 other's traffic by means of IP-layer multicast and the 2504 Distribution Source no longer needs to perform explicit forwarding 2505 between the Media Senders. Of course, the Distribution Source 2506 still forwards feedback information received from the receivers 2507 (optionally as summaries) to the ASM contribution group. 2509 The ASM contribution group may be statically configured or the 2510 necessary information can be communicated using a standard SDP 2511 session description for a multicast session. Again, it is up to 2512 the implementation of the Distribution Source to properly 2513 associate the ASM contribution session and the SSM distribution 2514 sessions. 2516 Figure 5 shows this scenario. 2518 RTCP with Unicast Feedback 2520 _ Source-specific 2521 / \ +-----+ Multicast 2522 +--------+ | | | | +----------------> R(1) 2523 | Media |<->| A | | D S | | | 2524 |Sender 1| | S | | I O | +--+ | 2525 +--------+ | M | | S U | | | | 2526 | | | T R | | +-----------> R(2) | 2527 +--------+ | G | | R C |->+----- : | | 2528 | Media |<->| r |<->| I E | | +------> R(n-1) | | 2529 |Sender 2| | o | | B | | | | | | 2530 +--------+ | u | | U | +--+--> R(n) | | | 2531 | p | | T | | | | | 2532 +--------+ | | | I |<---------+ | | | 2533 | Media |<->| | | O |<---------------+ | | 2534 |Sender 3| \_/ | N |<--------------------+ | 2535 +--------+ | |<-------------------------+ 2536 +-----+ Unicast 2538 Contribution Distribution 2539 Session Session 2540 (ASM) (SSM) 2542 Figure 5: Three Media Sender in ASM Group 2543 RTCP with Unicast Feedback 2545 16. Appendix B: Distribution Report processing at the receiver 2547 16.1 Algorithm 2549 Example processing of Loss Distribution Values 2550 X values represent the loss percentage. 2551 Y values represent the number of receivers. 2553 Number of x values is the NDB value 2554 xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV) 2555 First data point = MnDV,first ydata 2556 then 2557 Foreach ydata => xdata += (MnDV + (xrange / NDB)) 2559 16.2 Pseudo-code 2561 Packet Variables -> factor,NDB,MnDVL,MaDV 2562 Code variables -> xrange, ydata[NDB],x,y 2564 xrange = MaDV - MnDV 2565 x = MnDV; 2567 for(i=0;i 20 Bytes) 2703 Minimum Data Value: 0 2704 RTCP with Unicast Feedback 2706 Maximum Data Value: 39 2707 Data Bucket values: (each value is 16-bits) 2709 Results, 4-bit buckets: 2711 X - 0 - 2.5 | 2.5 - 5 | 5 - 7.5 | 7.5 - 10 2712 (Y - 1803 | 4403 | 5970 | 853 ) ACTUAL 2713 Y - 4 | 9 | 12 | 2 2715 X - 10 - 12.5 | 12.5 - 15 | 15 - 17.5 | 17.5 - 20 2716 (Y - 110 | 140 | 89.5 | 12.5) ACTUAL 2717 Y - 0 | 0 | 0 | 0 2719 X - 20 - 22.5 | 22.5 - 25 | 25 - 27.5 | 27.5 - 20 2720 (Y - 447 | 3897 | 609.5 | 506.5) ACTUAL 2721 Y - 1 | 8 | 1 | 1 2723 X - 30 - 32.5 | 32.5 - 35 | 35 - 37.5 | 37.5 - 40 2724 (Y - 388.5 | 221.5 | 159.5 | 85.5) ACTUAL 2725 Y - 1 | 0 | 0 | 0 2727 Example: 2nd Method 2729 Description 2730 This demonstrates the most accurate method for representing the data 2731 set. This method doesn't attempt to optimise any values. 2733 Algorithm 2734 Identify the highest value and select buckets large enough to convey 2735 the exact values, i.e. no multiplicative factor. 2737 The highest value is 3120. This requires 12 bits (closest 2 bit 2738 boundary) to represent, therefore it will use 60 bytes to represent 2739 the entire distribution. This is within the max packet size, 2740 therefore all data will fit within one sub-report block. The 2741 multiplicative value will be 1. 2743 The packet fields will contain the values: 2745 Header Distribution Block 2746 Distribution Type: 1 2747 Number of Data Buckets: 40 2748 Multiplicative Factor: 0 2749 Packet Length field: 18 (18 * 4 => 72 Bytes) 2750 Minimum Loss Value: 0 2751 Maximum Loss Value: 39 2753 Bucket values are the same as initial data set. 2755 RTCP with Unicast Feedback 2757 Result 2758 The selection of which of the three methods outlined above might be 2759 determined by a congestion parameter, or a user preference. The 2760 overhead associated with processing the packets is likely to differ 2761 very little between the techniques. The savings in bandwidth are 2762 apparent however, using 20, 52 and 72 octets respectively. These 2763 values would vary more widely for a larger data set with less 2764 correlation between results. 2766 18. ACKNOWLEDGEMENTS 2768 The authors would like to thank Magnus Westerlund and Dave Oran for 2769 detailed reviews and valuable comments. 2771 19. AUTHORS' ADDRESSES 2773 Julian Chesterfield 2774 University of Cambridge 2775 Computer Laboratory, 2776 JJ Thompson Avenue, 2777 Cambridge, CB3 0FD, UK 2778 Julian.chesterfield@cl.cam.ac.uk 2780 Joerg Ott 2781 Tellitec Engineering GmbH 2782 Berliner Str. 26 2783 D-13507 Berlin 2784 GERMANY 2785 jo@acm.org 2787 Eve Schooler 2788 Intel Research / CTL 2789 2200 Mission College Blvd., SC12-303 2790 Santa Clara, CA, USA 95054-1537 2791 eve_(underscore) schooler (at) acm.org 2793 18. IPR Notice 2795 The IETF takes no position regarding the validity or scope of any 2796 Intellectual Property Rights or other rights that might be claimed 2797 to pertain to the implementation or use of the technology described 2798 in this document or the extent to which any license under such 2799 rights might or might not be available; nor does it represent that 2800 it has made any independent effort to identify any such rights. 2801 Information on the procedures with respect to rights in RFC 2802 documents can be found in BCP 78 and BCP 79. 2804 Copies of IPR disclosures made to the IETF Secretariat and any 2805 assurances of licenses to be made available, or the result of an 2806 attempt made to obtain a general license or permission for the use 2807 RTCP with Unicast Feedback 2809 of such proprietary rights by implementers or users of this 2810 specification can be obtained from the IETF on-line IPR repository 2811 at http://www.ietf.org/ipr. 2813 The IETF invites any interested party to bring to its attention any 2814 copyrights, patents or patent applications, or other proprietary 2815 rights that may cover technology that may be required to implement 2816 this standard. Please address the information to the IETF at 2817 ietf-ipr@ietf.org. 2819 20. FULL COPYRIGHT STATEMENT 2821 Copyright (C) The Internet Society (2006). This document is subject 2822 to the rights, licenses and restrictions contained in BCP 78, and 2823 except as set forth therein, the authors retain all their rights. 2825 This document and the information contained herein are provided on 2826 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2827 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2828 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2829 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2830 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2831 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.