idnits 2.17.1 draft-ietf-avtcore-rtp-multi-stream-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3550, updated by this document, for RFC5378 checks: 1998-04-07) -- 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 (April 22, 2013) is 4015 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBA' is mentioned on line 456, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 628, but not defined ** Obsolete normative reference: RFC 6222 (Obsoleted by RFC 7022) == Outdated reference: A later version (-13) exists of draft-ietf-avtcore-multi-media-rtp-session-02 == Outdated reference: A later version (-10) exists of draft-ietf-avtcore-rtp-topologies-update-00 == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-09 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-03 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE J. Lennox 3 Internet-Draft Vidyo 4 Updates: 3550 (if approved) M. Westerlund 5 Intended status: Standards Track Ericsson 6 Expires: October 24, 2013 Q. Wu 7 Huawei 8 C. Perkins 9 University of Glasgow 10 April 22, 2013 12 RTP Considerations for Endpoints Sending Multiple Media Streams 13 draft-ietf-avtcore-rtp-multi-stream-00 15 Abstract 17 This document expands and clarifies the behavior of the Real-Time 18 Transport Protocol (RTP) endpoints when they are sending multiple 19 media streams in a single RTP session. In particular, issues 20 involving Real-Time Transport Control Protocol (RTCP) messages are 21 described. 23 This document updates RFC 3550 in regards to handling of multiple 24 SSRCs per endpoint in RTP sessions. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 24, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Use Cases For Multi-Stream Endpoints . . . . . . . . . . . . 3 63 3.1. Multiple-Capturer Endpoints . . . . . . . . . . . . . . . 3 64 3.2. Multi-Media Sessions . . . . . . . . . . . . . . . . . . 4 65 3.3. Multi-Stream Mixers . . . . . . . . . . . . . . . . . . . 4 66 4. Issue Cases . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Cascaded Multi-party Conference with Source Projecting 68 Mixers . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5. Multi-Stream Endpoint RTP Media Recommendations . . . . . . . 5 70 6. Multi-Stream Endpoint RTCP Recommendations . . . . . . . . . 5 71 6.1. RTCP Reporting Requirement . . . . . . . . . . . . . . . 6 72 6.2. Initial Reporting Interval . . . . . . . . . . . . . . . 6 73 6.3. Compound RTCP Packets . . . . . . . . . . . . . . . . . . 6 74 7. RTCP Bandwidth Considerations for Sources with Disparate 75 Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 8. Grouping of RTCP Reception Statistics and Other Feedback . . 7 77 8.1. Semantics and Behavior of Reporting Groups . . . . . . . 8 78 8.2. Determine the Report Group . . . . . . . . . . . . . . . 9 79 8.3. RTCP Packet Reporting Group's Reporting Sources . . . . . 9 80 8.4. RTCP Source Description (SDES) item for Reporting Groups 11 81 8.5. Middlebox Considerations . . . . . . . . . . . . . . . . 11 82 8.6. SDP signaling for Reporting Groups . . . . . . . . . . . 11 83 8.7. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 11 84 8.8. Consequences of RTCP Reporting Groups . . . . . . . . . . 12 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 11.1. RTCP SDES Item . . . . . . . . . . . . . . . . . . . . . 13 89 11.2. RTCP Packet Type . . . . . . . . . . . . . . . . . . . . 14 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 12.2. Informative References . . . . . . . . . . . . . . . . . 14 93 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 15 94 A.1. Changes From Individual Draft -02 . . . . . . . . . . . . 15 95 A.2. Changes From Draft -01 . . . . . . . . . . . . . . . . . 15 96 A.3. Changes From Draft -00 . . . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 99 1. Introduction 101 At the time The Real-Time Transport Protocol (RTP) [RFC3550] was 102 originally written, and for quite some time after, endpoints in RTP 103 sessions typically only transmitted a single media stream per RTP 104 session, where separate RTP sessions were typically used for each 105 distinct media type. 107 Recently, however, a number of scenarios have emerged (discussed 108 further in Section 3) in which endpoints wish to send multiple RTP 109 media streams, distinguished by distinct RTP synchronization source 110 (SSRC) identifiers, in a single RTP session. Although RTP's initial 111 design did consider such scenarios, the specification was not 112 consistently written with such use cases in mind. The specifications 113 are thus somewhat unclear. 115 The purpose of this document is to expand and clarify [RFC3550]'s 116 language for these use cases. The authors believe this does not 117 result in any major normative changes to the RTP specification, 118 however this document defines how the RTP specification is to be 119 interpreted. In these cases, this document updates RFC3550. 121 The document starts with terminology and some use cases where 122 multiple sources will occur. This is followed by some case studies 123 to try to identify issues that exist and need considerations. This 124 is followed by RTP and RTCP recommendations to resolve issues. Next 125 are security considerations and remaining open issues. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in RFC 132 2119 [RFC2119] and indicate requirement levels for compliant 133 implementations. 135 3. Use Cases For Multi-Stream Endpoints 137 This section discusses several use cases that have motivated the 138 development of endpoints that send multiple streams in a single RTP 139 session. 141 3.1. Multiple-Capturer Endpoints 142 The most straightforward motivation for an endpoint to send multiple 143 media streams in a session is the scenario where an endpoint has 144 multiple capture devices of the same media type and characteristics. 145 For example, telepresence endpoints, of the type described by the 146 CLUE Telepresence Framework [I-D.ietf-clue-framework] is designed, 147 often have multiple cameras or microphones covering various areas of 148 a room. 150 3.2. Multi-Media Sessions 152 Recent work has been done in RTP 153 [I-D.ietf-avtcore-multi-media-rtp-session] and SDP 154 [I-D.ietf-mmusic-sdp-bundle-negotiation] to update RTP's historical 155 assumption that media streams of different media types would always 156 be sent on different RTP sessions. In this work, a single endpoint's 157 audio and video media streams (for example) are instead sent in a 158 single RTP session. 160 3.3. Multi-Stream Mixers 162 There are several RTP topologies which can involve a central device 163 that itself generates multiple media streams in a session. 165 One example is a mixer providing centralized compositing for a multi- 166 capture scenario like that described in Section 3.1. In this case, 167 the centralized node is behaving much like a multi-capturer endpoint, 168 generating several similar and related sources. 170 More complicated is the Source Projecting Mixer, see Section 3.6 of 171 [I-D.ietf-avtcore-rtp-topologies-update]. This is a central box that 172 receives media streams from several endpoints, and then selectively 173 forwards modified versions of some of the streams toward the other 174 endpoints it is connected to. Toward one destination, a separate 175 media source appears in the session for every other source connected 176 to the mixer, "projected" from the original streams, but at any given 177 time many of them can appear to be inactive (and thus are receivers, 178 not senders, in RTP). This sort of device is closer to being an RTP 179 mixer than an RTP translator, in that it terminates RTCP reporting 180 about the mixed streams, and it can re-write SSRCs, timestamps, and 181 sequence numbers, as well as the contents of the RTP payloads, and 182 can turn sources on and off at will without appearing to be 183 generating packet loss. Each projected stream will typically 184 preserve its original RTCP source description (SDES) information. 186 4. Issue Cases 188 This section illustrates some scenarios that have shown areas where 189 the RTP specification is unclear. 191 4.1. Cascaded Multi-party Conference with Source Projecting Mixers 193 This issue case tries to illustrate the effect of having multiple 194 SSRCs sent by an endpoint, by considering the traffic between two 195 source-projecting mixers in a large multi-party conference. 197 For concreteness, consider a 200-person conference, where 16 sources 198 are viewed at any given time. Assuming participants are distributed 199 evenly among the mixers, each mixer would have 100 sources "behind" 200 (projected through) it, of which at any given time eight are active 201 senders. Thus, the RTP session between the mixers consists of two 202 endpoints, but 200 sources. 204 The RTCP bandwidth implications of this scenario are discussed 205 further in Section 8.7. 207 (TBD: Other examples? Can this section be removed?) 209 5. Multi-Stream Endpoint RTP Media Recommendations 211 While an endpoint MUST (of course) stay within its share of the 212 available session bandwidth, as determined by signalling and 213 congestion control, this need not be applied independently or 214 uniformly to each media stream. In particular, session bandwidth MAY 215 be reallocated among an endpoint's media streams, for example by 216 varying the bandwidth use of a variable-rate codec, or changing the 217 codec used by the media stream, up to the constraints of the 218 session's negotiated (or declared) codecs. This includes enabling or 219 disabling media streams as more or less bandwidth becomes available. 221 6. Multi-Stream Endpoint RTCP Recommendations 223 This section contains a number of different RTCP clarifications or 224 recommendations that enables more efficient and simpler behavior 225 without loss of functionality. 227 The RTP Control Protocol (RTCP) is defined in Section 6 of [RFC3550], 228 but it is largely documented in terms of "participants". In many 229 cases, the specification's recommendations for "participants" are to 230 be interpreted as applying to individual media streams, rather than 231 to endpoints. This section describes several concrete cases where 232 this applies. 234 (tbd: rather than think in terms of media streams, it might be 235 clearer to refer to SSRC values, where a participant with multiple 236 active SSRC values counts as multiple participants, once per SSRC) 238 6.1. RTCP Reporting Requirement 240 For each of an endpoint's media streams, whether or not it is 241 currently sending media, SR/RR and SDES packets MUST be sent at least 242 once per RTCP report interval. (For discussion of the content of SR 243 or RR packets' reception statistic reports, see Section 8.) 245 6.2. Initial Reporting Interval 247 When a new media stream is added to a unicast session, the sentence 248 in [RFC3550]'s Section 6.2 applies: "For unicast sessions ... the 249 delay before sending the initial compound RTCP packet MAY be zero." 250 This applies to individual media sources as well. Thus, endpoints 251 MAY send an initial RTCP packet for an SSRC immediately upon adding 252 it to a unicast session. 254 This allowance also applies, as written, when initially joining a 255 unicast session. However, in this case some caution needs to be 256 exercised if the end-point or mixer has a large number of sources 257 (SSRCs) as this can create a significant burst. How big an issue 258 this depends on the number of source to send initial SR or RR and 259 Session Description CNAME items for in relation to the RTCP 260 bandwidth. 262 (tbd: Maybe some recommendation here? The aim in restricting this to 263 unicast sessions was to avoid this burst of traffic, which the usual 264 RTCP timing and reconsideration rules will prevent) 266 6.3. Compound RTCP Packets 268 Section 6.1 gives the following advice to RTP translators and mixers: 270 It is RECOMMENDED that translators and mixers combine individual 271 RTCP packets from the multiple sources they are forwarding into 272 one compound packet whenever feasible in order to amortize the 273 packet overhead (see Section 7). An example RTCP compound packet 274 as might be produced by a mixer is shown in Fig. 1. If the 275 overall length of a compound packet would exceed the MTU of the 276 network path, it SHOULD be segmented into multiple shorter 277 compound packets to be transmitted in separate packets of the 278 underlying protocol. This does not impair the RTCP bandwidth 279 estimation because each compound packet represents at least one 280 distinct participant. Note that each of the compound packets MUST 281 begin with an SR or RR packet. 283 Note: To avoid confusion, an RTCP packet is an individual item, such 284 as a Sender Report (SR), Receiver Report (RR), Source Description 285 (SDES), Goodbye (BYE), Application Defined (APP), Feedback [RFC4585] 286 or Extended Report (XR) [RFC3611] packet. A compound packet is the 287 combination of two or more such RTCP packets where the first packet 288 has to be an SR or an RR packet, and which contains a SDES packet 289 containing an CNAME item. Thus the above results in compound RTCP 290 packets that contain multiple SR or RR packets from different sources 291 as well as any of the other packet types. There are no restrictions 292 on the order in which the packets can occur within the compound 293 packet, except the regular compound rule, i.e., starting with an SR 294 or RR. 296 This advice applies to multi-media-stream endpoints as well, with the 297 same restrictions and considerations. (Note, however, that the last 298 sentence does not apply to AVPF [RFC4585] or SAVPF [RFC5124] feedback 299 packets if Reduced-Size RTCP [RFC5506] is in use.) 301 Due to RTCP's randomization of reporting times, there is a fair bit 302 of tolerance in precisely when an endpoint schedules RTCP to be sent. 303 Thus, one potential way of implementing this recommendation would be 304 to randomize all of an endpoint's sources together, with a single 305 randomization schedule, so an MTU's worth of RTCP all comes out 306 simultaneously. 308 (tbd: Multiplexing RTCP packets from multiple different sources might 309 require some adjustment to the calculation of RTCP's avg_rtcp_size, 310 as the RTCP group interval is proportional to avg_rtcp_size times the 311 group size). 313 7. RTCP Bandwidth Considerations for Sources with Disparate Rates 315 It is possible for an RTP session to carry sources of greatly 316 differing bandwidths. One example is the scenario of 317 [I-D.ietf-avtcore-multi-media-rtp-session], when audio and video are 318 sent in the same session. However, this can occur even within a 319 single media type, for example a video session carrying both 5 fps 320 QCIF and 60 fps 1080p HD video, or an audio session carrying both 321 G.729 and L24/48000/6 audio. 323 (tbd: recommend how RTCP bandwidths are to be chosen in these 324 scenarios. Likely, these recommendations will be different for 325 sessions using AVPF-based profiles (where the trr-int parameter is 326 available) than for those using AVP.) 328 8. Grouping of RTCP Reception Statistics and Other Feedback 330 As specified by [RFC3550], an endpoint MUST send reception reports 331 about every active media stream it is receiving, from at least one 332 local source. 334 However, a naive application of the RTP specification's rules could 335 be quite inefficient. In particular, if a session has N SSRCs 336 (active and inactive, i.e., participant SSRCs), and the session has S 337 active senders in each reporting interval, there will either be N*S 338 report blocks per reporting interval, or (per the round-robin 339 recommendations of [RFC3550] Section 6.1) reception sources would be 340 unnecessarily round-robinned. In a session where most media sources 341 become senders reasonably frequently, this results in quadratically 342 many reception report blocks in the conference, or reporting delays 343 proportional to the number of session members. 345 Since traffic is received by endpoints, however, rather than by media 346 sources, there is not actually any need for this quadratic expansion. 347 All that is needed is for each endpoint to report all the remote 348 sources it is receiving. 350 Thus, this document defines a new RTCP mechanism, Reporting Groups, 351 to indicate sources which originate from the same endpoint, and which 352 therefore would have identical recption reports. 354 8.1. Semantics and Behavior of Reporting Groups 356 An RTCP Reporting Group indicates that a set of sources (SSRCs) that 357 originate from a single entity (endpoint or middlebox) in an RTP 358 session, and therefore all the sources in the group's view of the 359 network is identical. If reporting groups are in use, two sources 360 SHOULD be put into the same reporting group if their view of the 361 network is identical; i.e., if they report on traffic received at the 362 same interface of an RTP endpoint. Sources with different views of 363 the network MUST NOT be put into the same reporting group. 365 If reporting groups are in use, an endpoint MUST NOT send reception 366 reports from one source in a reporting group about another one in the 367 same group ("self-reports"). Similarly, an endpoint MUST NOT send 368 reception reports about a remote media source from more than one 369 source in a reporting group ("cross-reports"). Instead, it MUST pick 370 one of its local media sources as the "reporting" source for each 371 remote media source, and use it to send reception reports about that 372 remote source; all the other media sources in the reporting group 373 MUST NOT send any reception reports about that remote media source. 375 This reporting source MUST also be the source for any RTP/AVPF 376 Feedback [RFC4585] or Extended Report (XR) [RFC3611] packets about 377 the corresponding remote sources as well. If a reporting source 378 leaves the session (i.e., if it sends a BYE, or leaves the group 379 without sending BYE under the rules of [RFC3550] section 6.3.7), 380 another reporting source MUST be chosen if any members of the group 381 still exist. 383 An endpoint or middlebox MAY use multiple sources as reporting 384 sources; however, each reporting source MUST have non-overlapping 385 sets of remote SSRCs it reports on. This is primarily to be done 386 when the reporting source's number of reception report blocks is so 387 large that it would be forced to round robin around the sources. 388 Thus, by splitting the reports among several reporting SSRCs more 389 consistent reporting can be achieved. 391 If RTP/AVPF feedback is in use, a reporting source MAY send immediate 392 or early feedback at any point when any member of the reporting group 393 could validly do so. 395 An endpoint SHOULD NOT create single-source reporting groups, unless 396 it is anticipated that the group might have additional sources added 397 to it in the future. 399 8.2. Determine the Report Group 401 A remote RTP entity, such as an endpoint or a middlebox needs to be 402 able to determine the report group used by another RTP entity. To 403 achieve this goal two RTCP extensions has been defined. For the 404 SSRCs that are reporting on behalf of the reporting group an SDES 405 item RGRP has been defined for providing the report group with an 406 identifier. For SSRCs that aren't reporting on any peer SSRC a new 407 RTCP packet type is defined. This RTCP packet type "Reporting 408 Sources", lists the SSRC that are reporting on this SSRC's behalf. 410 This divided approach has been selected for the following reasons: 412 1. Enable an explicit indication of who reports on this SSRC's 413 behalf. Being explicit prevents the remote entity from detecting 414 that is missing the reports if there issues with the reporting 415 SSRC's RTCP packets. 417 2. Enable explicit identification of the SSRCs that are actively 418 reporting as one entity. 420 8.3. RTCP Packet Reporting Group's Reporting Sources 422 This section defines a new RTCP packet type called "Reporting Group's 423 Reporting Sources" (RGRS). It identifies the SSRC(s) that report on 424 behalf of the SSRC that is the sender of the RGRS packet. 426 This packet consists of the fixed RTCP packet header which indicates 427 the packet type, the number of reporting sources included and the 428 SSRC which behalf the reporting SSRCs report on. This is followed by 429 the list of reporting SSRCs. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 |V=2|P| SC | PT=RGRS(TBA) | length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | SSRC of packet sender | 437 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 438 : SSRC for Reporting Source : 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 The RTCP Packets field has the following definition. 443 version (V): This field identifies the RTP version. The current 444 version is 2. 446 padding (P): 1 bit If set, the padding bit indicates that the packet 447 contains additional padding octets at the end that are not part of 448 the control information but are included in the length field. See 449 [RFC3550]. 451 Source Count (SC): 5 bits Indicating the number of reporting SSRCs 452 (1-31) that are include in this RTCP packet type. 454 Payload type (PT): 8 bits This is the RTCP packet type that 455 identifies the packet as being an RTCP FB message. The RGRS RTCP 456 packet has the value [TBA]. 458 Length: 16 bits The length of this packet in 32-bit words minus one, 459 including the header and any padding. This is in line with the 460 definition of the length field used in RTCP sender and receiver 461 reports [RFC3550]. 463 SSRC of packet sender: 32 bits. The SSRC of the sender of this 464 packet which indicates which SSRCs that reports on its behalf, 465 instead of reporting itself. 467 SSRC for Reporting Source: A variable number (as indicated by Source 468 Count) of 32-bit SSRC values. Each SSRC is an reporting SSRC 469 belonging to the same Report Group. 471 Each RGRS packet MUST contain at least one reporting SSRC. In case 472 the reporting SSRC field is insufficient to list all the SSRCs that 473 is reporting in this report group, the SSRC SHALL round robin around 474 the reporting sources. 476 Any RTP mixer or translator which forwards SR or RR packets from 477 members of a reporting group MUST forward the corresponding RGRS RTCP 478 packet as well. 480 8.4. RTCP Source Description (SDES) item for Reporting Groups 482 A new RTCP Source Description (SDES) item is defined for the purpose 483 of identifying reporting groups. 485 The Source Description (SDES) item "RGRP" is sent by a reporting 486 group's reporting SSRC. Syntactically, its format is the same as the 487 RTCP SDES CNAME item [RFC6222], and MUST be chosen with the same 488 global-uniqueness and privacy considerations as CNAME. This name 489 MUST be stable across the lifetime of the reporting group, even if 490 the SSRC of a reporting source changes. 492 Every source which belongs to a reporting group MUST either include 493 an RGRP SDES item in an SDES packet (if it is a reporting source), or 494 an RGRS packet (if it is not), in every compound RTCP packet in which 495 it sends an RR or SR packet (i.e., in every RTCP packet it sends, 496 unless Reduced-Size RTCP [RFC5506] is in use). 498 Any RTP mixer or translator which forwards SR or RR packets from 499 members of a reporting group MUST forward the corresponding RGRP SDES 500 items as well, even if it otherwise strips SDES items other than 501 CNAME. 503 8.5. Middlebox Considerations 505 This section discusses middlebox considerations for Reporting groups. 507 To be expanded. 509 8.6. SDP signaling for Reporting Groups 511 TBD 513 8.7. Bandwidth Benefits of RTCP Reporting Groups 515 To understand the benefits of RTCP reporting groups, consider the 516 scenario described in Section 4.1. This scenario describes an 517 environment in which the two endpoints in a session each have a 518 hundred sources, of which eight each are sending within any given 519 reporting interval. 521 For ease of analysis, we can make the simplifying approximation that 522 the duration of the RTCP reporting interval is equal to the total 523 size of the RTCP packets sent during an RTCP interval, divided by the 524 RTCP bandwidth. (This will be approximately true in scenarios where 525 the bandwidth is not so high that the minimum RTCP interval is 526 reached.) For further simplification, we can assume RTCP senders are 527 following the recommendations of Section 6.3; thus, the per-packet 528 transport-layer overhead will be small relative to the RTCP data. 529 Thus, only the actual RTCP data itself need be considered. 531 In a report interval in this scenario, there will, as a baseline, be 532 200 SDES packets, 184 RR packets, and 16 SR packets. This amounts to 533 approximately 6.5 kB of RTCP per report interval, assuming 16-byte 534 CNAMEs and no other SDES information. 536 Using the original [RFC3550] everyone-reports-on-every-sender 537 feedback rules, each of the 184 receivers will send 16 report blocks, 538 and each of the 16 senders will send 15. This amounts to 539 approximately 76 kB of report block traffic per interval; 92% of RTCP 540 traffic consists of report blocks. 542 If reporting groups are used, however, there is only 0.4 kB of 543 reports per interval, with no loss of useful information. 544 Additionally, there will be (assuming 16-byte RGRPs, and a single 545 reporting source per reporting group) an additional 2.4 kB per cycle 546 of RGRP SDES items and RGRS packets. Put another way, the unmodified 547 [RFC3550] reporting interval is approximately 8.9 times longer than 548 if reporting groups are in use. 550 8.8. Consequences of RTCP Reporting Groups 552 The RTCP traffic generated by receivers using RTCP Reporting Groups 553 might appear, to observers unaware of these semantics, to be 554 generated by receivers who are experiencing a network disconnection, 555 as the non-reporting sources appear not to be receiving a given 556 sender at all. 558 This could be a potentially critical problem for such a sender using 559 RTCP for congestion control, as such a sender might think that it is 560 sending so much traffic that it is causing complete congestion 561 collapse. 563 However, such an interpretation of the session statistics would 564 require a fairly sophisticated RTCP analysis. Any receiver of RTCP 565 statistics which is just interested in information about itself needs 566 to be prepared that any given reception report might not contain 567 information about a specific media source, because reception reports 568 in large conferences can be round-robined. 570 Thus, it is unclear to what extent such backward compatibility issues 571 would actually cause trouble in practice. 573 9. Security Considerations 575 In the secure RTP protocol (SRTP) [RFC3711], the cryptographic 576 context of a compound SRTCP packet is the SSRC of the sender of the 577 first RTCP (sub-)packet. This could matter in some cases, especially 578 for keying mechanisms such as Mikey [RFC3830] which use per-SSRC 579 keying. 581 Other than that, the standard security considerations of RTP apply; 582 sending multiple media streams from a single endpoint does not appear 583 to have different security consequences than sending the same number 584 of streams. 586 10. Open Issues 588 At this stage this document contains a number of open issues. The 589 below list tries to summarize the issues: 591 1. Further clarifications on how to handle the RTCP scheduler when 592 sending multiple sources in one compound packet. 594 2. How is the use of reporting groups be signaled in SDP? 596 3. How is the RTCP avg_rtcp_size be calculated when RTCP packets are 597 routinely multiplexed among multiple RTCP senders? 599 4. Do we need to provide a recommendation for unicast session 600 joiners with many sources to not use 0 initial minimal interval 601 from bit-rate burst perspective? 603 11. IANA Considerations 605 This document make several requests to IANA for registering new RTP/ 606 RTCP identifiers. 608 (Note to the RFC-Editor: please replace "TBA" with the IANA-assigned 609 value, and "XXXX" with the number of this document, prior to 610 publication as an RFC.) 612 11.1. RTCP SDES Item 614 This document adds an additional SDES types to the IANA "RTCP SDES 615 Item Types" Registry, as follows: 617 Value Abbrev Name Reference 618 TBA RGRP Reporting Group [RFCXXXX] 620 Figure 1: Item for the IANA Source Attribute Registry 622 11.2. RTCP Packet Type 624 This document defines one new RTCP Control Packet types (PT) to be 625 registered as follows: 627 Value Abbrev Name Reference 628 TBA RGRR Reporting Group Reporting Sources [RFCXXXX] 630 Figure 2: Item for the IANA RTCP Control Packet Types (PT) Registry 632 12. References 634 12.1. Normative References 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997. 639 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 640 Jacobson, "RTP: A Transport Protocol for Real-Time 641 Applications", STD 64, RFC 3550, July 2003. 643 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 644 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 645 RFC 3711, March 2004. 647 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 648 "Extended RTP Profile for Real-time Transport Control 649 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 650 2006. 652 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 653 Real-time Transport Control Protocol (RTCP)-Based Feedback 654 (RTP/SAVPF)", RFC 5124, February 2008. 656 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 657 Real-Time Transport Control Protocol (RTCP): Opportunities 658 and Consequences", RFC 5506, April 2009. 660 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 661 Choosing RTP Control Protocol (RTCP) Canonical Names 662 (CNAMEs)", RFC 6222, April 2011. 664 12.2. Informative References 666 [I-D.ietf-avtcore-multi-media-rtp-session] 667 Westerlund, M., Perkins, C., and J. Lennox, "Multiple 668 Media Types in an RTP Session", draft-ietf-avtcore-multi- 669 media-rtp-session-02 (work in progress), February 2013. 671 [I-D.ietf-avtcore-rtp-topologies-update] 672 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 673 ietf-avtcore-rtp-topologies-update-00 (work in progress), 674 April 2013. 676 [I-D.ietf-clue-framework] 677 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 678 for Telepresence Multi-Streams", draft-ietf-clue- 679 framework-09 (work in progress), February 2013. 681 [I-D.ietf-mmusic-sdp-bundle-negotiation] 682 Holmberg, C., Alvestrand, H., and C. Jennings, 683 "Multiplexing Negotiation Using Session Description 684 Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- 685 bundle-negotiation-03 (work in progress), February 2013. 687 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 688 Protocol Extended Reports (RTCP XR)", RFC 3611, November 689 2003. 691 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 692 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 693 August 2004. 695 Appendix A. Changes From Earlier Versions 697 Note to the RFC-Editor: please remove this section prior to 698 publication as an RFC. 700 A.1. Changes From Individual Draft -02 702 o Resubmitted as working group draft. 704 o Updated references. 706 A.2. Changes From Draft -01 708 o Merged with draft-wu-avtcore-multisrc-endpoint-adver. 710 o Changed how Reporting Groups are indicated in RTCP, to make it 711 clear which source(s) is the group's reporting sources. 713 o Clarified the rules for when sources can be placed in the same 714 reporting group. 716 o Clarified that mixers and translators need to pass reporting group 717 SDES information if they are forwarding RR and SR traffic from 718 members of a reporting group. 720 A.3. Changes From Draft -00 722 o Added the Reporting Group semantic to explicitly indicate which 723 sources come from a single endpoint, rather than leaving it 724 implicit. 726 o Specified that Reporting Group semantics (as they now are) apply 727 to AVPF and XR, as well as to RR/SR report blocks. 729 o Added a description of the cascaded source-projecting mixer, along 730 with a calculation of its RTCP overhead if reporting groups are 731 not in use. 733 o Gave some guidance on how the flexibility of RTCP randomization 734 allows some freedom in RTCP multiplexing. 736 o Clarified the language of several of the recommendations. 738 o Added an open issue discussing how avg_rtcp_size ought to be 739 calculated for multiplexed RTCP. 741 o Added an open issue discussing how RTCP bandwidths are to be 742 chosen for sessions where source bandwidths greatly differ. 744 Authors' Addresses 746 Jonathan Lennox 747 Vidyo, Inc. 748 433 Hackensack Avenue 749 Seventh Floor 750 Hackensack, NJ 07601 751 US 753 Email: jonathan@vidyo.com 755 Magnus Westerlund 756 Ericsson 757 Farogatan 6 758 SE-164 80 Kista 759 Sweden 761 Phone: +46 10 714 82 87 762 Email: magnus.westerlund@ericsson.com 763 Qin Wu 764 Huawei 765 101 Software Avenue, Yuhua District 766 Nanjing, Jiangsu 210012 767 China 769 Email: sunseawq@huawei.com 771 Colin Perkins 772 University of Glasgow 773 School of Computing Science 774 Glasgow G12 8QQ 775 United Kingdom 777 Email: csp@csperkins.org