idnits 2.17.1 draft-lennox-avtcore-rtp-multi-stream-01.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3550, but the abstract doesn't seem to mention this, which it should. 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 (October 22, 2012) is 4202 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: 'RFCXXXX' is mentioned on line 481, 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-01 == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-07 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-01 == Outdated reference: A later version (-02) exists of draft-westerlund-avtcore-rtp-topologies-update-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 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: April 25, 2013 October 22, 2012 8 Real-Time Transport Protocol (RTP) Considerations for Endpoints Sending 9 Multiple Media Streams 10 draft-lennox-avtcore-rtp-multi-stream-01 12 Abstract 14 This document expands and clarifies the behavior of the Real-Time 15 Transport Protocol (RTP) endpoints when they are sending multiple 16 media streams in a single RTP session. In particular, issues 17 involving Real-Time Transport Control Protocol (RTCP) messages are 18 described. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 25, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Use Cases For Multi-Stream Endpoints . . . . . . . . . . . . . 3 57 3.1. Multiple-Capturer Endpoints . . . . . . . . . . . . . . . 3 58 3.2. Multi-Media Sessions . . . . . . . . . . . . . . . . . . . 4 59 3.3. Multi-Stream Mixers . . . . . . . . . . . . . . . . . . . 4 60 4. Issue Cases . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Cascaded Multi-party Conference with Source Projecting 62 Mixers . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Multi-Stream Endpoint RTP Media Recommendations . . . . . . . 5 64 6. Multi-Stream Endpoint RTCP Recommendations . . . . . . . . . . 5 65 6.1. RTCP Reporting Requirement . . . . . . . . . . . . . . . . 6 66 6.2. Initial Reporting Interval . . . . . . . . . . . . . . . . 6 67 6.3. Compound RTCP Packets . . . . . . . . . . . . . . . . . . 6 68 7. RTCP Bandwidth Considerations When Sources have 69 Greatly-Differing Bandwidths . . . . . . . . . . . . . . . . . 7 70 8. Grouping of RTCP Reception Statistics and Other Feedback . . . 7 71 8.1. Semantics and Behavior of Reporting Groups . . . . . . . . 8 72 8.2. RTCP Source Description (SDES) item for Reporting 73 Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.3. SDP signaling for Reporting Groups . . . . . . . . . . . . 9 75 8.4. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 9 76 8.5. Consequences of RTCP Reporting Groups . . . . . . . . . . 10 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 83 Appendix A. Changes From Earlier Versions . . . . . . . . . . . . 13 84 A.1. Changes From Draft -00 . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 At the time The Real-Time Tranport Protocol (RTP) [RFC3550] was 90 originally written, and for quite some time after, endpoints in RTP 91 sessions typically only transmitted a single media stream per RTP 92 session, where separate RTP sessions were typically used for each 93 distinct media type. 95 Recently, however, a number of scenarios have emerged (discussed 96 further in Section 3) in which endpoints wish to send multiple RTP 97 media streams, distinguished by distinct RTP synchronization source 98 (SSRC) identifiers, in a single RTP session. Although RTP's initial 99 design did consider such scenarios, the specification was not 100 consistently written with such use cases in mind. The specifications 101 are thus somewhat unclear. 103 The purpose of this document is to expand and clarify [RFC3550]'s 104 language for these use cases. The authors believe this does not 105 result in any major normative changes to the RTP specification, 106 however this document defines how the RTP specification shall be 107 interpreted. In these cases, this document updates RFC3550. 109 The document starts with terminology and some use cases where 110 multiple sources will occur. This is followed by some case studies 111 to try to identify issues that exist and need considerations. This 112 is followed by RTP and RTCP recommendations to resolve issues. Next 113 are security considerations and remaining open issues. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in RFC 120 2119 [RFC2119] and indicate requirement levels for compliant 121 implementations. 123 3. Use Cases For Multi-Stream Endpoints 125 This section discusses several use cases that have motivated the 126 development of endpoints that send multiple streams in a single RTP 127 session. 129 3.1. Multiple-Capturer Endpoints 131 The most straightforward motivation for an endpoint to send multiple 132 media streams in a session is the scenario where an endpoint has 133 multiple capture devices of the same media type and characteristics. 134 For example, telepresence endpoints, of the type described by the 135 CLUE Telepresence Framework [I-D.ietf-clue-framework] is designed, 136 often have multiple cameras or microphones covering various areas of 137 a room. 139 3.2. Multi-Media Sessions 141 Recent work has been done in RTP 142 [I-D.ietf-avtcore-multi-media-rtp-session] and SDP 143 [I-D.ietf-mmusic-sdp-bundle-negotiation] to update RTP's historical 144 assumption that media streams of different media types would always 145 be sent on different RTP sessions. In this work, a single endpoint's 146 audio and video media streams (for example) are instead sent in a 147 single RTP session. 149 3.3. Multi-Stream Mixers 151 There are several RTP topologies which can involve a central box 152 which itself generates multiple media streams in a session. 154 One example is a mixer providing centralized compositing for a multi- 155 capturer scenario like the one described in Section 3.1. In this 156 case, the centralized node is behaving much like a multi-capturer 157 endpoint, generating several similar and related sources. 159 More complicated is the Source Projecting Mixer, see Section 3.6 160 [I-D.westerlund-avtcore-rtp-topologies-update], which is a central 161 box that receives media streams from several endpoints, and then 162 selectively forwards modified versions of some of the streams toward 163 the other endpoints it is connected to. Toward one destination, a 164 separate media source appears in the session for every other source 165 connected to the mixer, "projected" from the original streams, but at 166 any given time many of them may appear to be inactive (and thus 167 receivers, not senders, in RTP). This box is an RTP mixer, not an 168 RTP translator, in that it terminates RTCP reporting about the mixed 169 streams, and it can re-write SSRCs, timestamps, and sequence numbers, 170 as well as the contents of the RTP payloads, and can turn sources on 171 and off at will without appearing to be generating packet loss. Each 172 projected stream will typically preserve its original RTCP source 173 description (SDES) information. 175 4. Issue Cases 177 This section tries to illustrate a few cases that have been 178 determined to cause issues. 180 4.1. Cascaded Multi-party Conference with Source Projecting Mixers 182 This issue case tries to illustrate the effect of having multiple 183 SSRCs sent by an endpoint, by considering the traffic between two 184 source-projecting mixers in a large multi-party conference. 186 For concreteness, consider a 200-person conference, where 16 sources 187 are viewed at any given time. Assuming participants are distributed 188 evenly among the mixers, each mixer would have 100 sources "behind" 189 (projected through) it, of which at any given time eight are active 190 senders. Thus, the RTP session between the mixers consists of two 191 endpoints, but 200 sources. 193 The RTCP bandwidth implications of this scenario are discussed 194 further in Section 8.4. 196 (TBD: Other examples?) 198 5. Multi-Stream Endpoint RTP Media Recommendations 200 While an endpoint MUST (of course) stay within its share of the 201 available session bandwidth, as determined by signalling and 202 congestion control, this need not be applied independently or 203 uniformly to each media stream. In particular, session bandwidth MAY 204 be reallocated among an endpoint's media streams, for example by 205 varying the bandwidth use of a variable-rate codec, or changing the 206 codec used by the media stream, up to the constraints of the 207 session's negotiated (or declared) codecs. This includes enabling or 208 disabling media streams as more or less bandwidth becomes available. 210 6. Multi-Stream Endpoint RTCP Recommendations 212 This section contains a number of different RTCP clarifications or 213 recommendations that enables more efficient and simpler behavior 214 without loss of functionality. 216 The Real-Time Transport Control Protocol (RTCP) is defined in Section 217 6 of [RFC3550], but it is largely documented in terms of 218 "participants". In many cases, the specification's recommendations 219 for "participants" should be interpreted as applying to individual 220 media streams, rather than to endpoints. This section describes 221 several concrete cases where this applies. 223 6.1. RTCP Reporting Requirement 225 For each of an endpoint's media media streams, whether or not it is 226 currently sending media, SR/RR and SDES packets MUST be sent at least 227 once per RTCP report interval. (For discussion of the content of SR 228 or RR packets' reception statistic reports, see Section 8.) 230 6.2. Initial Reporting Interval 232 When a new media stream is added to a unicast session, the sentence 233 in [RFC3550]'s Section 6.2 applies: "For unicast sessions ... the 234 delay before sending the initial compound RTCP packet MAY be zero." 235 This applies to individual media sources as well. Thus, endpoints 236 MAY send an initial RTCP packet for an SSRC immediately upon adding 237 it to a unicast session. 239 This allowance also applies, as written, when initially joining a 240 unicast session. However, in this case some caution should be 241 excersied if the end-point or mixer has a large number of sources 242 (SSRCs) as this can create a significant burst. How big an issue 243 this depends on the number of source to send initial SR or RR and 244 Session Description CNAME items for in relation to the RTCP 245 bandwidth. TBD: Maybe some recommendation here? 247 6.3. Compound RTCP Packets 249 Section 6.1 gives the following advice to RTP translators and mixers: 251 It is RECOMMENDED that translators and mixers combine individual 252 RTCP packets from the multiple sources they are forwarding into 253 one compound packet whenever feasible in order to amortize the 254 packet overhead (see Section 7). An example RTCP compound packet 255 as might be produced by a mixer is shown in Fig. 1. If the 256 overall length of a compound packet would exceed the MTU of the 257 network path, it SHOULD be segmented into multiple shorter 258 compound packets to be transmitted in separate packets of the 259 underlying protocol. This does not impair the RTCP bandwidth 260 estimation because each compound packet represents at least one 261 distinct participant. Note that each of the compound packets MUST 262 begin with an SR or RR packet. 264 Note: To avoid confusion, an RTCP packet is an individual item, such 265 as a Sender Report (SR), Receiver Report (RR), Source Description 266 (SDES), Goodbye (BYE), Application Defined (APP), Feedback [RFC4585] 267 or Extended Report (XR) [RFC3611] packet. A compound packet is the 268 combination of two or more such RTCP packets where the first packet 269 must be an SR or an RR packet, and which contains a SDES packet 270 containing an CNAME item. Thus the above results in compound RTCP 271 packets that contain multiple SR or RR packets from different sources 272 as well as any of the other packet types. There are no restrictions 273 on the order the packets may occur within the compound packet, except 274 the regular compound rule, i.e. starting with an SR or RR. 276 This advice applies to multi-media-stream endpoints as well, with the 277 same restrictions and considerations. (Note, however, that the last 278 sentence does not apply to AVPF [RFC4585] or SAVPF [RFC5124] feedback 279 packets if Reduced-Size RTCP [RFC5506] is in use.) 281 Due to RTCP's randomization of reporting times, there is a fair bit 282 of tolerance in precisely when an endpoint schedules RTCP to be sent. 283 Thus, one potential way of implementing this recommendation would be 284 to randomize all of an endpoint's sources together, with a single 285 randomization schedule, so an MTU's worth of RTCP all comes out 286 simultaneously. 288 TBD: Multiplexing RTCP packets from multiple different sources may 289 require some adjustment to the calculaton of RTCP's avg_rtcp_size, as 290 the RTCP group interval is proportional to avg_rtcp_size times the 291 group size. 293 7. RTCP Bandwidth Considerations When Sources have Greatly-Differing 294 Bandwidths 296 it is possible for an RTP session to carry sources of greatly 297 differing bandwidths. One example is the scenario of 298 [I-D.ietf-avtcore-multi-media-rtp-session], when audio and video are 299 sent in the same session. However, this can occur even within a 300 single media type, for example a video session carrying both 5 fps 301 QCIF and 60 fps 1080p HD video, or an audio session carrying both 302 G.729 and L24/48000/6 audio. 304 TBD: recommend how RTCP bandwidths should be chosen in these 305 scenarios. Likely, these recommendations will be different for 306 sessions using AVPF-based profiles (where the trr-int parameter is 307 available) than for those using AVP. 309 8. Grouping of RTCP Reception Statistics and Other Feedback 311 As required by [RFC3550], an endpoint MUST send reception reports 312 about every active media stream it is receiving, from at least one 313 local source. 315 However, a naive application of the RTP specification's rules could 316 be quite inefficient. In particular, if a session has N media 317 sources (active and inactive), and has S senders in each reporting 318 interval, there will either be N*S report blocks per reporting 319 interval, or (per the round-robinning recommendations of [RFC3550] 320 Section 6.1) reception sources would be unnecessarily round-robinned. 321 In a session where most media sources become senders reasonably 322 frequently, this results in quadratically many reception report 323 blocks in the conference, or reporting delays proportional to the 324 number of session members. 326 Since traffic is received by endpoints, however, rather than by media 327 sources, there is not actually any need for this quadratic expansion. 328 All that is needed is for each endpoint to report all the remote 329 sources it is receiving. 331 Thus, this document defines a new RTCP mechanism, Reporting Groups, 332 to indicate sources which originate from the same endpoint, and which 333 therefore would have identical reecption reports. 335 8.1. Semantics and Behavior of Reporting Groups 337 An RTCP Reporting Group indicates that a set of sources originate 338 from a single entity in an RTP session, and therefore all the sources 339 in the group's view of the network is identical. Typically, a 340 Reporting Group corresponds to a physical entity in the network. 342 If reporting groups are in use, an endpoint MUST NOT send reception 343 reports from one source in a reporting group about another one in the 344 same group ("self-reports"). Similarly, an endpoint MUST NOT send 345 reception reports about a remote media source from more than one 346 sources in a reporting group ("cross-reports"). Instead, it MUST 347 pick one of its local media sources as the "reporting" source for 348 each remote media source, and use it to send reception reports for 349 that remote source; all its other media sources MUST NOT send any 350 reception reports for that remote media source. 352 An endpoint MAY choose different local media sources as the reporting 353 source for different remote media sources (for example, it could 354 choose to send reports about remote audio sources from a local audio 355 source, and reports about remote video sources from a local video 356 source), or it MAY choose a single local source for all its reports. 357 This reporting source MUST also be the source for any AVPF Feedback 358 [RFC4585] or Extended Report (XR) [RFC3611] packets about the 359 corresponding remote sources as well. If a reporting source leaves 360 the session (i.e., if it sends a BYE, or leaves the group without 361 sending BYE under the rules of [RFC3550] section 6.3.7), another 362 reporting source MUST be chosen, if the sources it was reporting on 363 are still in the session. 365 If AVPF feedback is in use, a reporting source MAY send immediate or 366 early feedback at any point when any member of the reporting group 367 could validly do so. 369 An endpoint SHOULD NOT create single-source reporting groups, unless 370 it is anticipated that the group might have additional sources added 371 to it in the future. 373 8.2. RTCP Source Description (SDES) item for Reporting Groups 375 A new Source Description (SDES) item, "RGRP", indicates that a 376 sources is a member of a specified reporting group. Syntactically, 377 its format is the same as the RTCP CNAME [RFC6222], and MUST be 378 chosen with the same global-uniqueness and privacy considerations as 379 CNAME. 381 Every source which belongs to a reporting group MUST include an RGRP 382 SDES item in an SDES packet, alongside its CNAME, in every compound 383 RTCP packet in which it sends an RR or SR packet. (I.e., in every 384 RTCP packet it sends, unless Reduced-Size RTCP [RFC5506] is in use.) 386 8.3. SDP signaling for Reporting Groups 388 TBD 390 8.4. Bandwidth Benefits of RTCP Reporting Groups 392 To understand the benefits of RTCP reporting groups, consider the 393 scenario described in Section 4.1. This scenario describes an 394 environment in which the two endpoints in a session each have a 395 hundred sources, of which eight each are sending within any given 396 reporting interval. 398 For ease of analysis, we can make the simplifying approximation that 399 the duration of the RTCP reporting interval is equal to the total 400 size of the RTCP packets sent during an RTCP interval, divided by the 401 RTCP bandwidth. (This will be approximately true in scenarios where 402 the bandwidth is not so high that the minimum RTCP interval is 403 reached.) For further simplification, we can assume RTCP senders are 404 following the recommendations of Section 6.3; thus, the per-packet 405 transport-layer overhead will be small relative to the RTCP data. 406 Thus, only the actual RTCP data itself need be considered. 408 In a report interval in this scenario, there will, as a baseline, be 409 200 SDES packets, 184 RR packets, and 16 SR packets. This amounts to 410 approximately 6.5 kB of RTCP per report interval, assuming 16-byte 411 CNAMEs and no other SDES information. 413 Using naive everyone-reports-on-every-sender feedback rules, each of 414 the 184 receivers will send 16 report blocks, and each of the 16 415 senders will send 15. This amounts to approximately 76 kB of report 416 block traffic per interval; 92% of RTCP traffic consists of report 417 blocks. 419 If reporting groups are used, however, there is only 0.4 kB of 420 reports per interval, with no loss of useful information. 421 Additionally, there will be (assuming 16-byte RGRPs as well) an 422 additional 3.2 kB per cycle of RGRP SDES items. Put another way, the 423 naive case's reporting interval is approximately 7.5 times longer 424 than if reporting groups are in use. 426 8.5. Consequences of RTCP Reporting Groups 428 The RTCP traffic generated by receivers using RTCP Reporting Groups 429 might appear, to observers unaware of these semantics, to be 430 generated by receivers who are experiencing a network disconnection, 431 as the non-reporting sources appear not to be receiving a given 432 sender at all. 434 This could be a potentially critical problem for such a sender useing 435 RTCP for congestion control, as such a sender might think that it is 436 sending so much traffic that it is causing complete congestion 437 collapse. 439 However, such an interpretation of the session statistics would 440 require a fairly sophisticated RTCP analysis. Any receiver of RTCP 441 statistics which is just interested in information about itself needs 442 to be prepared that any given reception report might not contain 443 information about a specific media source, because reception reports 444 in large conferences can be round-robined. 446 Thus, it is unclear to what extent such backward compatibility issues 447 would actually cause trouble in practice. 449 9. Security Considerations 451 In the secure RTP protocol (SRTP) [RFC3711], the cryptographic 452 context of a compound SRTCP packet is the SSRC of the sender of the 453 first RTCP (sub-)packet. This could matter in some cases, especially 454 for keying mechanisms such as Mikey [RFC3830] which use per-SSRC 455 keying. 457 Other than that, the standard security considerations of RTP apply; 458 sending multiple media streams from a single endpoint does not appear 459 to have different security consequences than sending the same number 460 of streams. 462 10. Open Issues 464 At this stage this document contains a number of open issues. The 465 below list tries to summarize the issues: 466 1. Further clarifications on how to handle the RTCP scheduler when 467 sending multiple sources in one compound packet. 468 2. How should the use of reporting groups be signaled in SDP? 469 3. How should the RTCP avg_rtcp_size be calculated when RTCP packets 470 are routinely multiplexed among multiple RTCP senders? 471 4. Do we need to provide a recommendation for unicast session 472 joiners with many sources to not use 0 initial minimal interval 473 from bit-rate burst perspective? 475 11. IANA Considerations 477 This document adds an additional SDES type to the IANA "RTCP SDES 478 Item Types" Registry, as follows: 480 Value Abbrev Name Reference 481 TBD RGRP Reporting Group [RFCXXXX] 483 Figure 1: Initial Contents of IANA Source Attribute Registry 485 (Note to the RFC-Editor: please replace "TBD" with the IANA-assigned 486 value, and "XXXX" with the number of this document, prior to 487 publication as an RFC.) 489 12. References 491 12.1. Normative References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 497 Jacobson, "RTP: A Transport Protocol for Real-Time 498 Applications", STD 64, RFC 3550, July 2003. 500 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 501 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 502 RFC 3711, March 2004. 504 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 505 "Extended RTP Profile for Real-time Transport Control 506 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 507 July 2006. 509 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 510 Real-time Transport Control Protocol (RTCP)-Based Feedback 511 (RTP/SAVPF)", RFC 5124, February 2008. 513 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 514 Real-Time Transport Control Protocol (RTCP): Opportunities 515 and Consequences", RFC 5506, April 2009. 517 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 518 Choosing RTP Control Protocol (RTCP) Canonical Names 519 (CNAMEs)", RFC 6222, April 2011. 521 12.2. Informative References 523 [I-D.ietf-avtcore-multi-media-rtp-session] 524 Westerlund, M., Perkins, C., and J. Lennox, "Multiple 525 Media Types in an RTP Session", 526 draft-ietf-avtcore-multi-media-rtp-session-01 (work in 527 progress), October 2012. 529 [I-D.ietf-clue-framework] 530 Romanow, A., Duckworth, M., Pepperell, A., and B. Baldino, 531 "Framework for Telepresence Multi-Streams", 532 draft-ietf-clue-framework-07 (work in progress), 533 October 2012. 535 [I-D.ietf-mmusic-sdp-bundle-negotiation] 536 Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation 537 Using Session Description Protocol (SDP) Port Numbers", 538 draft-ietf-mmusic-sdp-bundle-negotiation-01 (work in 539 progress), August 2012. 541 [I-D.westerlund-avtcore-rtp-topologies-update] 542 Westerlund, M. and S. Wenger, "RTP Topologies", 543 draft-westerlund-avtcore-rtp-topologies-update-01 (work in 544 progress), October 2012. 546 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 547 Protocol Extended Reports (RTCP XR)", RFC 3611, 548 November 2003. 550 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 551 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 552 August 2004. 554 Appendix A. Changes From Earlier Versions 556 Note to the RFC-Editor: please remove this section prior to 557 publication as an RFC. 559 A.1. Changes From Draft -00 561 o Added the Reporting Group semantic to explicitly indicate which 562 sources come from a single endpoint, rather than leaving it 563 implicit. 564 o Specified that Reporting Group semantics (as they now are) apply 565 to AVPF and XR, as well as to RR/SR report blocks. 566 o Added a description of the cascaded source-projecting mixer, along 567 with a calculation of its RTCP overhead if reporting groups are 568 not in use. 569 o Gave some guidance on how the flexibility of RTCP randomization 570 allows some freedom in RTCP multiplexing. 571 o Clarified the language of several of the recommendations. 572 o Added an open issue discussing how avg_rtcp_size should be 573 calculated for multiplexed RTCP. 574 o Added an open issue discussing RTCP bandwidths should be chosen 575 for sessions where source bandwidths greatly differ. 577 Authors' Addresses 579 Jonathan Lennox 580 Vidyo, Inc. 581 433 Hackensack Avenue 582 Seventh Floor 583 Hackensack, NJ 07601 584 US 586 Email: jonathan@vidyo.com 588 Magnus Westerlund 589 Ericsson 590 Farogatan 6 591 SE-164 80 Kista 592 Sweden 594 Phone: +46 10 714 82 87 595 Email: magnus.westerlund@ericsson.com