idnits 2.17.1 draft-ietf-avtcore-rtp-multi-stream-11.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 (December 11, 2015) is 3058 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) == Outdated reference: A later version (-13) exists of draft-ietf-avtcore-multi-media-rtp-session-12 == Outdated reference: A later version (-12) exists of draft-ietf-avtcore-rtp-multi-stream-optimisation-09 == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-24 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-23 Summary: 0 errors (**), 0 flaws (~~), 5 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, 4585 (if approved) M. Westerlund 5 Intended status: Standards Track Ericsson 6 Expires: June 13, 2016 Q. Wu 7 Huawei 8 C. Perkins 9 University of Glasgow 10 December 11, 2015 12 Sending Multiple RTP Streams in a Single RTP Session 13 draft-ietf-avtcore-rtp-multi-stream-11 15 Abstract 17 This memo expands and clarifies the behaviour of Real-time Transport 18 Protocol (RTP) endpoints that use multiple synchronization sources 19 (SSRCs). This occurs, for example, when an endpoint sends multiple 20 RTP streams in a single RTP session. This memo updates RFC 3550 with 21 regards to handling multiple SSRCs per endpoint in RTP sessions, with 22 a particular focus on RTCP behaviour. It also updates RFC 4585 to 23 update and clarify the calculation of the timeout of SSRCs and the 24 inclusion of feedback messages. 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 June 13, 2016. 43 Copyright Notice 45 Copyright (c) 2015 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. Endpoints with Multiple Capture Devices . . . . . . . . . 3 64 3.2. Multiple Media Types in a Single RTP Session . . . . . . 4 65 3.3. Multiple Stream Mixers . . . . . . . . . . . . . . . . . 4 66 3.4. Multiple SSRCs for a Single Media Source . . . . . . . . 4 67 4. Use of RTP by endpoints that send multiple media streams . . 5 68 5. Use of RTCP by Endpoints that send multiple media streams . . 5 69 5.1. RTCP Reporting Requirement . . . . . . . . . . . . . . . 5 70 5.2. Initial Reporting Interval . . . . . . . . . . . . . . . 6 71 5.3. Aggregation of Reports into Compound RTCP Packets . . . . 7 72 5.3.1. Maintaining AVG_RTCP_SIZE . . . . . . . . . . . . . . 7 73 5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs . . . 9 74 5.4. Use of RTP/AVPF or RTP/SAVPF Feedback . . . . . . . . . . 11 75 5.4.1. Choice of SSRC for Feedback Packets . . . . . . . . . 11 76 5.4.2. Scheduling an RTCP Feedback Packet . . . . . . . . . 12 77 6. Adding and Removing SSRCs . . . . . . . . . . . . . . . . . . 14 78 6.1. Adding RTP Streams . . . . . . . . . . . . . . . . . . . 14 79 6.2. Removing RTP Streams . . . . . . . . . . . . . . . . . . 15 80 7. RTCP Considerations for Streams with Disparate Rates . . . . 16 81 7.1. Timing out SSRCs . . . . . . . . . . . . . . . . . . . . 17 82 7.1.1. Problems with the RTP/AVPF T_rr_interval Parameter . 18 83 7.1.2. Avoiding Premature Timeout . . . . . . . . . . . . . 19 84 7.1.3. Interoperability Between RTP/AVP and RTP/AVPF . . . . 19 85 7.1.4. Updated SSRC Timeout Rules . . . . . . . . . . . . . 20 86 7.2. Tuning RTCP transmissions . . . . . . . . . . . . . . . . 20 87 7.2.1. RTP/AVP and RTP/SAVP . . . . . . . . . . . . . . . . 21 88 7.2.2. RTP/AVPF and RTP/SAVPF . . . . . . . . . . . . . . . 22 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 91 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 94 11.2. Informative References . . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 97 1. Introduction 99 At the time the Real-Time Transport Protocol (RTP) [RFC3550] was 100 originally designed, and for quite some time after, endpoints in RTP 101 sessions typically only transmitted a single media source, and thus 102 used a single RTP stream and thus synchronization source (SSRC) per 103 RTP session, where separate RTP sessions were typically used for each 104 distinct media type. Recently, however, a number of scenarios have 105 emerged in which endpoints wish to send multiple RTP streams, 106 distinguished by distinct RTP synchronization source (SSRC) 107 identifiers, in a single RTP session. These are outlined in 108 Section 3. Although the initial design of RTP did consider such 109 scenarios, the specification was not consistently written with such 110 use cases in mind. The specification is thus somewhat unclear in 111 places. 113 This memo updates [RFC3550] to clarify behaviour in use cases where 114 endpoints use multiple SSRCs. It also updates [RFC4585] to resolve 115 problems with regards to timeout of inactive SSRCs, and to clarify 116 behaviour around inclusion of feedback messages. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in RFC 123 2119 [RFC2119] and indicate requirement levels for compliant 124 implementations. 126 3. Use Cases For Multi-Stream Endpoints 128 This section discusses several use cases that have motivated the 129 development of endpoints that sends RTP data using multiple SSRCs in 130 a single RTP session. 132 3.1. Endpoints with Multiple Capture Devices 134 The most straightforward motivation for an endpoint to send multiple 135 simultaneous RTP streams in a single RTP session is when an endpoint 136 has multiple capture devices, and hence can generate multiple media 137 sources, of the same media type and characteristics. For example, 138 telepresence systems of the type described by the CLUE Telepresence 139 Framework [I-D.ietf-clue-framework] often have multiple cameras or 140 microphones covering various areas of a room, and hence send several 141 RTP streams of each type within a single RTP session. 143 3.2. Multiple Media Types in a Single RTP Session 145 Recent work has updated RTP 146 [I-D.ietf-avtcore-multi-media-rtp-session] and SDP 147 [I-D.ietf-mmusic-sdp-bundle-negotiation] to remove the historical 148 assumption in RTP that media sources of different media types would 149 always be sent on different RTP sessions. In this work, a single 150 endpoint's audio and video RTP streams (for example) are instead sent 151 in a single RTP session to reduce the number of transport layer flows 152 used. 154 3.3. Multiple Stream Mixers 156 There are several RTP topologies which can involve a central device 157 that itself generates multiple RTP streams in a session. An example 158 is a mixer providing centralized compositing for a multi-capture 159 scenario like that described in Section 3.1. In this case, the 160 centralized node is behaving much like a multi-capturer endpoint, 161 generating several similar and related sources. 163 A more complex example is the selective forwarding middlebox, 164 described in Section 3.7 of [RFC7667]. This is a middlebox that 165 receives RTP streams from several endpoints, and then selectively 166 forwards modified versions of some RTP streams toward the other 167 endpoints to which it is connected. For each connected endpoint, a 168 separate media source appears in the session for every other source 169 connected to the middlebox, "projected" from the original streams, 170 but at any given time many of them can appear to be inactive (and 171 thus are receivers, not senders, in RTP). This sort of device is 172 closer to being an RTP mixer than an RTP translator, in that it 173 terminates RTCP reporting about the mixed streams, and it can re- 174 write SSRCs, timestamps, and sequence numbers, as well as the 175 contents of the RTP payloads, and can turn sources on and off at will 176 without appearing to generate packet loss. Each projected stream 177 will typically preserve its original RTCP source description (SDES) 178 information. 180 3.4. Multiple SSRCs for a Single Media Source 182 There are also several cases where multiple SSRCs can be used to send 183 data from a single media source within a single RTP session. These 184 include, but are not limited to, transport robustness tools, such as 185 the RTP retransmission payload format [RFC4588], that require one 186 SSRC to be used for the media data and another SSRC for the repair 187 data. Similarly, some layered media encoding schemes, for example 188 H.264 SVC [RFC6190], can be used in a configuration where each layer 189 is sent using a different SSRC within a single RTP session. 191 4. Use of RTP by endpoints that send multiple media streams 193 RTP is inherently a group communication protocol. Each endpoint in 194 an RTP session will use one or more SSRCs, as will some types of RTP 195 level middlebox. Accordingly, unless restrictions on the number of 196 SSRCs have been signalled, RTP endpoints can expect to receive RTP 197 data packets sent using a number of different SSRCs, within a single 198 RTP session. This can occur irrespective of whether the RTP session 199 is running over a point-to-point connection or a multicast group, 200 since middleboxes can be used to connect multiple transport 201 connections together into a single RTP session (the RTP session is 202 defined by the shared SSRC space, not by the transport connections). 203 Furthermore, if RTP mixers are used, some SSRCs might only be visible 204 in the contributing source (CSRC) list of an RTP packet and in RTCP, 205 and might not appear directly as the SSRC of an RTP data packet. 207 Every RTP endpoint will have an allocated share of the available 208 session bandwidth, as determined by signalling and congestion 209 control. The endpoint needs to keep its total media sending rate 210 within this share. However, endpoints that send multiple RTP streams 211 do not necessarily need to subdivide their share of the available 212 bandwidth independently or uniformly to each RTP stream and its 213 SSRCs. In particular, an endpoint can vary the bandwidth allocation 214 to different streams depending on their needs, and can dynamically 215 change the bandwidth allocated to different SSRCs (for example, by 216 using a variable rate codec), provided the total sending rate does 217 not exceed its allocated share. This includes enabling or disabling 218 RTP streams, or their redundancy streams, as more or less bandwidth 219 becomes available. 221 5. Use of RTCP by Endpoints that send multiple media streams 223 The RTP Control Protocol (RTCP) is defined in Section 6 of [RFC3550]. 224 The description of the protocol is phrased in terms of the behaviour 225 of "participants" in an RTP session, under the assumption that each 226 endpoint is a participant with a single SSRC. However, for correct 227 operation in cases where endpoints have multiple SSRC values, 228 implementations MUST treat each SSRC as a separate participant in the 229 RTP session, so that an endpoint that has multiple SSRCs counts as 230 multiple participants. 232 5.1. RTCP Reporting Requirement 234 An RTP endpoint that has multiple SSRCs MUST treat each SSRC as a 235 separate participant in the RTP session. Each SSRC will maintain its 236 own RTCP-related state information, and hence will have its own RTCP 237 reporting interval that determines when it sends RTCP reports. If 238 the mechanism in [I-D.ietf-avtcore-rtp-multi-stream-optimisation] is 239 not used, then each SSRC will send RTCP reports for all other SSRCs, 240 including those co-located at the same endpoint. 242 If the endpoint has some SSRCs that are sending data and some that 243 are only receivers, then they will receive different shares of the 244 RTCP bandwidth and calculate different base RTCP reporting intervals. 245 Otherwise, all SSRCs at an endpoint will calculate the same base RTCP 246 reporting interval. The actual reporting intervals for each SSRC are 247 randomised in the usual way, but reports can be aggregated as 248 described in Section 5.3. 250 5.2. Initial Reporting Interval 252 When a participant joins a unicast session, the following text from 253 Section 6.2 of [RFC3550] is relevant: "For unicast sessions... the 254 delay before sending the initial compound RTCP packet MAY be zero." 255 The basic assumption is that this also ought to apply in the case of 256 multiple SSRCs. Caution has to be exercised, however, when an 257 endpoint (or middlebox) with a large number of SSRCs joins a unicast 258 session, since immediate transmission of many RTCP reports can create 259 a significant burst of traffic, leading to transient congestion and 260 packet loss due to queue overflows. 262 To ensure that the initial burst of traffic generated by an RTP 263 endpoint is no larger than would be generated by a TCP connection, an 264 RTP endpoint MUST NOT send more than four compound RTCP packets with 265 zero initial delay when it joins an RTP session, independently of the 266 number of SSRCs used by the endpoint. Each of those initial compound 267 RTCP packets MAY include aggregated reports from multiple SSRCs, 268 provided the total compound RTCP packet size does not exceed the MTU, 269 and the avg_rtcp_size is maintained as in Section 5.3.1. Aggregating 270 reports from several SSRCs in the initial compound RTCP packets 271 allows a substantial number of SSRCs to report immediately. 272 Endpoints SHOULD prioritize reports on SSRCs that are likely to be 273 most immediately useful, e.g., for SSRCs that are initially senders. 275 An endpoint that needs to report on more SSRCs than will fit into the 276 four compound RTCP reports that can be sent immediately MUST send the 277 other reports later, following the usual RTCP timing rules including 278 timer reconsideration. Those reports MAY be aggregated as described 279 in Section 5.3. 281 Note: The above is chosen to match the TCP maximum initial window 282 of 4 packets [RFC3390], not the larger TCP initial windows for 283 which there is an ongoing experiment [RFC6928]. The reason for 284 this is a desire to be conservative, since an RTP endpoint will 285 also in many cases start sending RTP data packets at the same time 286 as these initial RTCP packets are sent. 288 5.3. Aggregation of Reports into Compound RTCP Packets 290 As outlined in Section 5.1, an endpoint with multiple SSRCs has to 291 treat each SSRC as a separate participant when it comes to sending 292 RTCP reports. This will lead to each SSRC sending a compound RTCP 293 packet in each reporting interval. Since these packets are coming 294 from the same endpoint, it might reasonably be expected that they can 295 be aggregated to reduce overheads. Indeed, Section 6.1 of [RFC3550] 296 allows RTP translators and mixers to aggregate packets in similar 297 circumstances: 299 "It is RECOMMENDED that translators and mixers combine individual 300 RTCP packets from the multiple sources they are forwarding into 301 one compound packet whenever feasible in order to amortize the 302 packet overhead (see Section 7). An example RTCP compound packet 303 as might be produced by a mixer is shown in Fig. 1. If the 304 overall length of a compound packet would exceed the MTU of the 305 network path, it SHOULD be segmented into multiple shorter 306 compound packets to be transmitted in separate packets of the 307 underlying protocol. This does not impair the RTCP bandwidth 308 estimation because each compound packet represents at least one 309 distinct participant. Note that each of the compound packets MUST 310 begin with an SR or RR packet." 312 This allows RTP translators and mixers to generate compound RTCP 313 packets that contain multiple SR or RR packets from different SSRCs, 314 as well as any of the other packet types. There are no restrictions 315 on the order in which the RTCP packets can occur within the compound 316 packet, except the regular rule that the compound RTCP packet starts 317 with an SR or RR packet. Due to this rule, correctly implemented RTP 318 endpoints will be able to handle compound RTCP packets that contain 319 RTCP packets relating to multiple SSRCs. 321 Accordingly, endpoints that use multiple SSRCs can aggregate the RTCP 322 packets sent by their different SSRCs into compound RTCP packets, 323 provided 1) the resulting compound RTCP packets begin with an SR or 324 RR packet; 2) they maintain the average RTCP packet size as described 325 in Section 5.3.1; and 3) they schedule packet transmission and manage 326 aggregation as described in Section 5.3.2. 328 5.3.1. Maintaining AVG_RTCP_SIZE 330 The RTCP scheduling algorithm in [RFC3550] works on a per-SSRC basis. 331 Each SSRC sends a single compound RTCP packet in each RTCP reporting 332 interval. When an endpoint uses multiple SSRCs, it is desirable to 333 aggregate the compound RTCP packets sent by its SSRCs, reducing the 334 overhead by forming a larger compound RTCP packet. This aggregation 335 can be done as described in Section 5.3.2, provided the average RTCP 336 packet size calculation is updated as follows. 338 Participants in an RTP session update their estimate of the average 339 RTCP packet size (avg_rtcp_size) each time they send or receive an 340 RTCP packet (see Section 6.3.3 of [RFC3550]). When a compound RTCP 341 packet that contains RTCP packets from several SSRCs is sent or 342 received, the avg_rtcp_size estimate for each SSRC that is reported 343 upon is updated using div_packet_size rather than the actual packet 344 size: 346 avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size 348 where div_packet_size is packet_size divided by the number of SSRCs 349 reporting in that compound packet. The number of SSRCs reporting in 350 a compound packet is determined by counting the number of different 351 SSRCs that are the source of Sender Report (SR) or Receiver Report 352 (RR) RTCP packets within the compound RTCP packet. Non-compound RTCP 353 packets (i.e., RTCP packets that do not contain an SR or RR packet 354 [RFC5506]) are considered to report on a single SSRC. 356 An SSRC that doesn't follow the above rule, and instead uses the full 357 RTCP compound packet size to calculate avg_rtcp_size, will derive an 358 RTCP reporting interval that is overly large by a factor that is 359 proportional to the number of SSRCs aggregated into compound RTCP 360 packets and the size of set of SSRCs being aggregated relative to the 361 total number of participants. This increased RTCP reporting interval 362 can cause premature timeouts if it is more than five times the 363 interval chosen by the SSRCs that understand compound RTCP that 364 aggregate reports from many SSRCs. A 1500 octet MTU can fit five 365 typical size reports into a compound RTCP packet, so this is a real 366 concern if endpoints aggregate RTCP reports from multiple SSRCs. 368 The issue raised in the previous paragraph is mitigated by the 369 modification in timeout behaviour specified in Section 7.1.2 of this 370 memo. This mitigation is in place in those cases where the RTCP 371 bandwidth is sufficiently high that an endpoint, using avg_rtcp_size 372 calculated without taking into account the number of reporting SSRCs, 373 can transmit more frequently than approximately every 5 seconds. 374 Note, however, that the non-updated endpoint's RTCP reporting is 375 still negatively impacted even if the premature timeout of its SSRCs 376 are avoided. If compatibility with non-updated endpoints is a 377 concern, the number of reports from different SSRCs aggregated into a 378 single compound RTCP packet SHOULD either be limited to two reports, 379 or aggregation ought not used at all. This will limit the non- 380 updated endpoint's RTCP reporting interval to be no larger than twice 381 the RTCP reporting interval that would be chosen by an endpoint 382 following this specification. 384 5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs 386 This section revises and extends the behaviour defined in Section 6.3 387 of [RFC3550], and in Section 3.5.3 of [RFC4585] if the RTP/AVPF 388 profile or the RTP/SAVPF profile is used, regarding actions to take 389 when scheduling and sending RTCP packets where multiple reporting 390 SSRCs are aggregating their RTCP packets into the same compound RTCP 391 packet. These changes to the RTCP scheduling rules are needed to 392 maintain important RTCP timing properties, including the inter-packet 393 distribution, and the behaviour during flash joins and other changes 394 in session membership. 396 The variables tn, tp, tc, T, and Td used in the following are defined 397 in Section 6.3 of [RFC3550]. The variables T_rr_interval and 398 T_rr_last are defined in [RFC4585]. 400 Each endpoint MUST schedule RTCP transmission independently for each 401 of its SSRCs using the regular calculation of tn for the RTP profile 402 being used. Each time the timer tn expires for an SSRC, the endpoint 403 MUST perform RTCP timer reconsideration and, if applicable, 404 T_rr_interval based suppression. If the result indicates that a 405 compound RTCP packet is to be sent by that SSRC, and the transmission 406 is not an early RTCP packet [RFC4585], then the endpoint SHOULD try 407 to aggregate RTCP packets of additional SSRCs that are scheduled in 408 the future into the compound RTCP packet before it is sent. The 409 reason to limit or not aggregate at due to backwards compatibility 410 reasons was discussed earlier in Section 5.3.1. 412 Aggregation proceeds as follows. The endpoint selects the SSRC that 413 has the smallest tn value after the current time, tc, and prepares 414 the RTCP packets that SSRC would send if its timer tn expired at tc. 415 If those RTCP packets will fit into the compound RTCP packet that is 416 being generated, taking into account the path MTU and the previously 417 added RTCP packets, then they are added to the compound RTCP packet; 418 otherwise they are discarded. This process is repeated for each 419 SSRC, in order of increasing tn, until the compound RTCP packet is 420 full, or all SSRCs have been aggregated. At that point, the compound 421 RTCP packet is sent. 423 When the compound RTCP packet is sent, the endpoint MUST update tp, 424 tn, and T_rr_last (if applicable) for each SSRC that was included. 425 These variables are updated as follows: 427 a. For the first SSRC that reported in the compound RTCP packet, set 428 the effective transmission time, tt, of that SSRC to tc. 430 b. For each additional SSRC that reported in the compound RTCP 431 packet, calculate the transmission time that SSRC would have had 432 if it had not been aggregated into the compound RTCP packet. 433 This is derived by taking tn for that SSRC, then performing 434 reconsideration and updating tn until tp + T <= tn. Once this is 435 done, set the effective transmission time, tt, for that SSRC to 436 the calculated value of tn. If the RTP/AVPF profile or the RTP/ 437 SAVPF profile is being used, then T_rr_interval based suppression 438 MUST NOT be used in this calculation. 440 c. Calculate average effective transmission time, tt_avg, for the 441 compound RTCP packet based on the tt values for all SSRCs sent in 442 the compound RTCP packet. Set tp for each of the SSRCs sent in 443 the compound RTCP packet to tt_avg. If the RTP/AVPF profile or 444 the RTP/SAVPF profile is being used, set T_tt_last for each SSRC 445 sent in the compound RTCP packet to tt_avg. 447 d. For each of the SSRCs sent in the compound RTCP packet, calculate 448 new tn values based on the updated parameters and the usual RTCP 449 timing rules, and reschedule the timers. 451 When using the RTP/AVPF profile or the RTP/SAVPF profile, the above 452 mechanism only attempts to aggregate RTCP packets when the compound 453 RTCP packet to be sent is not an early RTCP packet, and hence the 454 algorithm in Section 3.5.3 of [RFC4585] will control RTCP scheduling. 455 If T_rr_interval == 0, or if T_rr_interval != 0 and option 1, 2a, or 456 2b of the algorithm are chosen, then the above mechanism updates the 457 necessary variables. However, if the transmission is suppressed per 458 option 2c of the algorithm, then tp is updated to tc as aggregation 459 has not taken place. 461 Reverse reconsideration MUST be performed following Section 6.3.4 of 462 [RFC3550]. In some cases, this can lead to the value of tp after 463 reverse reconsideration being larger than tc. This is not a problem, 464 and has the desired effect of proportionally pulling the tp value 465 towards tc (as well as tn) as the reporting interval shrinks in 466 direct proportion the reduced group size. 468 The above algorithm has been shown in simulations [Sim88][Sim92] to 469 maintain the inter-RTCP packet transmission time distribution for 470 each SSRC, and to consume the same amount of bandwidth as non- 471 aggregated RTCP packets. With this algorithm the actual transmission 472 interval for an SSRC triggering an RTCP compound packet transmission 473 is following the regular transmission rules. The value tp is set to 474 somewhere in the interval [0,1.5/1.21828*Td] ahead of tc. The actual 475 value is average of one instance of tc and the randomized 476 transmission times of the additional SSRCs, thus the lower range of 477 the interval is more probable. This compensates for the bias that is 478 otherwise introduced by picking the shortest tn value out of the N 479 SSRCs included in aggregate. 481 The algorithm also handles the cases where the number of SSRCs that 482 can be included in an aggregated packet varies. An SSRC that 483 previously was aggregated and fails to fit in a packet still has its 484 own transmission scheduled according to normal rules. Thus, it will 485 trigger a transmission in due time, or the SSRC will be included in 486 another aggregate. The algorithm's behaviour under SSRC group size 487 changes is as follows: 489 RTP sessions where the number of SSRC are growing: When the group 490 size is growing, Td grows in proportion to the number of new SSRCs 491 in the group. When reconsideration is performed due to expiry of 492 the tn timer, that SSRC will reconsider the transmission and with 493 a certain probability reschedule the tn timer. This part of the 494 reconsideration algorithm is only impacted by the above algorithm 495 by having tp values that were in the future instead of set to the 496 time of the actual last transmission at the time of updating tp. 498 RTP sessions where the number of SSRC are shrinking: When the group 499 shrinks, reverse reconsideration moves the tp and tn values 500 towards tc proportionally to the number of SSRCs that leave the 501 session compared to the total number of participants when they 502 left. The setting of the tp value forward in time related to the 503 tc could be believed to have negative effect. However, the reason 504 for this setting is to compensate for bias caused by picking the 505 shortest tn out of the N aggregated. This bias remains over a 506 reduction in the number of SSRCs. The reverse reconsideration 507 compensates the reduction independently of aggregation being used 508 or not. The negative effect that can occur on removing an SSRC is 509 that the most favourable tn belonged to the removed SSRC. The 510 impact of this is limited to delaying the transmission, in the 511 worst case, one reporting interval. 513 In conclusion the investigations performed have found no significant 514 negative impact on the scheduling algorithm. 516 5.4. Use of RTP/AVPF or RTP/SAVPF Feedback 518 This section discusses the transmission of RTP/AVPF feedback packets 519 when the transmitting endpoint has multiple SSRCs. The guidelines in 520 this section also apply to endpoints using the RTP/SAVPF profile. 522 5.4.1. Choice of SSRC for Feedback Packets 524 When an RTP/AVPF endpoint has multiple SSRCs, it can choose what SSRC 525 to use as the source for the RTCP feedback packets it sends. Several 526 factors can affect that choice: 528 o RTCP feedback packets relating to a particular media type SHOULD 529 be sent by an SSRC that receives that media type. For example, 530 when audio and video are multiplexed onto a single RTP session, 531 endpoints will use their audio SSRC to send feedback on the audio 532 received from other participants. 534 o RTCP feedback packets and RTCP codec control messages that are 535 notifications or indications regarding RTP data processed by an 536 endpoint MUST be sent from the SSRC used for that RTP data. This 537 includes notifications that relate to a previously received 538 request or command [RFC4585][RFC5104]. 540 o If separate SSRCs are used to send and receive media, then the 541 corresponding SSRC SHOULD be used for feedback, since they have 542 differing RTCP bandwidth fractions. This can also affect the 543 consideration if the SSRC can be used in immediate mode or not. 545 o Some RTCP feedback packet types require consistency in the SSRC 546 used. For example, if a TMMBR limitation [RFC5104] is set by an 547 SSRC, the same SSRC needs to be used to remove the limitation. 549 o If several SSRCs are suitable for sending feedback, it might be 550 desirable to use an SSRC that allows the sending of feedback as an 551 early RTCP packet. 553 When an RTCP feedback packet is sent as part of a compound RTCP 554 packet that aggregates reports from multiple SSRCs, there is no 555 requirement that the compound packet contains an SR or RR packet 556 generated by the sender of the RTCP feedback packet. For reduced- 557 size RTCP packets, aggregation of RTCP feedback packets from multiple 558 sources is not limited further than Section 4.2.2 of [RFC5506]. 560 5.4.2. Scheduling an RTCP Feedback Packet 562 When an SSRC has a need to transmit a feedback packet in early mode 563 it MUST schedule that packet following the algorithm in Section 3.5 564 of [RFC4585] modified as follows: 566 o To determine whether an RTP session is considered to be a point- 567 to-point session or a multiparty session, an endpoint MUST count 568 the number of distinct RTCP SDES CNAME values used by the SSRCs 569 listed in the SSRC field of RTP data packets it receives and in 570 the "SSRC of sender" field of RTCP SR, RR, RTPFB, or PSFB packets 571 it receives. An RTP session is considered to be a multiparty 572 session if more than one CNAME is used by those SSRCs, unless 573 signalling indicates that the session is to be handled as point to 574 point, or RTCP reporting groups 575 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] are used. If 576 RTCP reporting groups are used, an RTP session is considered to be 577 a point-to-point session if the endpoint receives only a single 578 reporting group, and considered to be a multiparty session if 579 multiple reporting groups are received, or if a combination of 580 reporting groups and SSRCs that are not part of a reporting group 581 are received. Endpoints MUST NOT determine whether an RTP session 582 is multiparty or point-to-point based on the type of connection 583 (unicast or multicast) used, or on the number of SSRCs received. 585 o When checking if there is already a scheduled compound RTCP packet 586 containing feedback messages (Step 2 in Section 3.5.2 of 587 [RFC4585]), that check MUST be done considering all local SSRCs. 589 o If an SSRC is not allowed to send an early RTCP packet, then the 590 feedback message MAY be queued for transmission as part of any 591 early or regular scheduled transmission that can occur within the 592 maximum useful lifetime of the feedback message (T_max_fb_delay). 593 This modifies the behaviour in bullet 4a) in Section 3.5.2 of 594 [RFC4585]. 596 The first bullet point above specifies a rule to determine if an RTP 597 session is to be considered a point-to-point session or a multiparty 598 session. This rule is straightforward to implement, but is known to 599 incorrectly classify some sessions as multiparty sessions. The known 600 problems are as follows: 602 Endpoint with multiple synchronization contexts: An endpoint that is 603 part of a point-to-point session can have multiple synchronization 604 contexts, for example due to forwarding an external media source 605 into a interactive real-time conversation. In this case the 606 classification will consider the peer as two endpoints, while the 607 actual RTP/RTCP transmission will be under the control of one 608 endpoint. 610 Selective Forwarding Middlebox: The SFM as defined in Section 3.7 of 611 [RFC7667] has control over the transmission and configurations 612 between itself and each peer endpoint individually. It also fully 613 controls the RTCP packets being forwarded between the individual 614 legs. Thus, this type of middlebox can be compared to the RTP 615 mixer, which uses its own SSRCs to mix or select the media it 616 forwards, that will be classified as a point-to-point RTP session 617 by the above rule. 619 In the above cases it is very reasonable to use RTCP reporting groups 620 [I-D.ietf-avtcore-rtp-multi-stream-optimisation]. If that extension 621 is used, an endpoint can indicate that the multitude of CNAMEs are in 622 fact under a single endpoint or middlebox control by using only a 623 single reporting group. 625 The above rules will also classify some sessions where the endpoint 626 is connected to an RTP mixer as being point to point. For example 627 the mixer could act as gateway to an Any Source Multicast based RTP 628 session for the discussed endpoint. However, this will in most cases 629 be okay, as the RTP mixer provides separation between the two parts 630 of the session. The responsibility falls on the mixer to act 631 accordingly in each domain. 633 Finally, we note that signalling mechanisms could be defined to 634 override the rules when it would result in the wrong classification. 636 6. Adding and Removing SSRCs 638 The set of SSRCs present in a single RTP session can vary over time 639 due to changes in the number of endpoints in the session, or due to 640 changes in the number or type of RTP streams being sent. 642 Every endpoint in an RTP session will have at least one SSRC that it 643 uses for RTCP reporting, and for sending media if desired. It can 644 also have additional SSRCs, for sending extra media sources or for 645 additional RTCP reporting. If the set of media sources being sent 646 changes, then the set of SSRCs being sent will change. Changes in 647 the media format or clock rate might also require changes in the set 648 of SSRCs used. An endpoint can also have more SSRCs than it has 649 active RTP streams, and send RTCP relating to SSRCs that are not 650 currently sending RTP data packets so that its peers are aware of the 651 SSRCs, and have the associated context (e.g., clock synchronisation 652 and an SDES CNAME) in place to be able to play out media as soon as 653 they becomes active. 655 In the following, we describe some considerations around adding and 656 removing RTP streams and their associated SSRCs. 658 6.1. Adding RTP Streams 660 When an endpoint joins an RTP session it can have zero, one, or more 661 RTP streams it will send, or that it is prepared to send. If it has 662 no RTP stream it plans to send, it still needs an SSRC that will be 663 used to send RTCP feedback. If it will send one or more RTP streams, 664 it will need the corresponding number of SSRC values. The SSRCs used 665 by an endpoint are made known to other endpoints in the RTP session 666 by sending RTP and RTCP packets. SSRCs can also be signalled using 667 non-RTP means (e.g., [RFC5576]). Unless restricted by signalling, an 668 endpoint can, at any time, send an additional RTP stream, identified 669 by a new SSRC (this might be associated with a signalling event, but 670 that is outside the scope of this memo). This makes the new SSRC 671 visible to the other endpoints in the session, since they share the 672 single SSRC space inherent in the definition of an RTP session. 674 An endpoint that has never sent an RTP stream will have an SSRC that 675 it uses for RTCP reporting. If that endpoint wants to start sending 676 an RTP stream, it is RECOMMENDED that it use its existing SSRC for 677 that stream, since otherwise the participant count in the RTP session 678 will be unnecessary increased, leading to a longer RTCP reporting 679 interval and larger RTCP reports due to cross reporting. If the 680 endpoint wants to start sending more than one RTP stream, it will 681 need to generate a new SSRC for the second and any subsequent RTP 682 streams. 684 An endpoint that has previously stopped sending an RTP stream, and 685 that wants to start sending a new RTP stream, cannot generally re-use 686 the existing SSRC, and often needs to generate a new SSRC, because an 687 SSRC cannot change media type (e.g., audio to video) or RTP timestamp 688 clock rate [RFC7160], and because the SSRC might be associated with a 689 particular semantic by the application (note: an RTP stream can pause 690 and restart using the same SSRC, provided RTCP is sent for that SSRC 691 during the pause; these rules only apply to new RTP streams reusing 692 an existing SSRC). 694 6.2. Removing RTP Streams 696 An SSRC is removed from an RTP session in one of two ways. When an 697 endpoint stops sending RTP and RTCP packets using an SSRC, then that 698 SSRC will eventually time out as described in Section 6.3.5 of 699 [RFC3550]. Alternatively, an SSRC can be explicitly removed from use 700 by sending an RTCP BYE packet as described in Section 6.3.7 of 701 [RFC3550]. It is RECOMMENDED that SSRCs be removed from use by 702 sending an RTCP BYE packet. Note that [RFC3550] requires that the 703 RTCP BYE SHOULD be the last RTP/RTCP packet sent in the RTP session 704 for an SSRC. If an endpoint needs to restart an RTP stream after 705 sending an RTCP BYE for its SSRC, it needs to generate a new SSRC 706 value for that stream. 708 The finality of sending RTCP BYE, means that endpoints needs to 709 consider if the ceasing of transmission of an RTP stream is temporary 710 or permanent. Temporary suspension of media transmission using a 711 particular RTP stream (SSRC) needs to maintain that SSRC as an active 712 participant, by continuing RTCP transmission for it. That way the 713 media sending can be resume immediately, knowing that the context is 714 in place. Permanent transmission halting needs to send RTCP BYE to 715 allow the other participants to use the RTCP bandwidth resources and 716 clean up their state databases. 718 An endpoint that ceases transmission of all its RTP streams but 719 remains in the RTP session MUST maintain at least one SSRC that is to 720 be used for RTCP reporting and feedback (i.e., it cannot send a BYE 721 for all SSRCs, but needs to retain at least one active SSRC). As 722 some Feedback packets can be bound to media type there might be need 723 to maintain one SSRC per media type within an RTP session. An 724 alternative can be to create a new SSRC to use for RTCP reporting and 725 feedback. However, to avoid the perception that an endpoint drops 726 completely out of an RTP session such a new SSRC ought to be first 727 established before terminating all the existing SSRCs. 729 7. RTCP Considerations for Streams with Disparate Rates 731 An RTP session has a single set of parameters that configure the 732 session bandwidth. These are the RTCP sender and receiver fractions 733 (e.g., the SDP "b=RR:" and "b=RS:" lines [RFC3556]), and the 734 parameters of the RTP/AVPF profile [RFC4585] (e.g., trr-int) if that 735 profile (or its secure extension, RTP/SAVPF [RFC5124]) is used. As a 736 consequence, the base RTCP reporting interval, before randomisation, 737 will be the same for every sending SSRC in an RTP session. 738 Similarly, every receiving SSRC in an RTP session will have the same 739 base reporting interval, although this can differ from the reporting 740 interval chosen by sending SSRCs. This uniform RTCP reporting 741 interval for all SSRCs can result in RTCP reports being sent more 742 often, or too seldom, than is considered desirable for a RTP stream. 744 For example, consider a scenario when an audio flow sending at tens 745 of kilobits per second is multiplexed into an RTP session with a 746 multi-megabit high quality video flow. If the session bandwidth is 747 configured based on the video sending rate, and the default RTCP 748 bandwidth fraction of 5% of the session bandwidth is used, it is 749 likely that the RTCP bandwidth will exceed the audio sending rate. 750 If the reduced minimum RTCP interval described in Section 6.2 of 751 [RFC3550] is then used in the session, as appropriate for video where 752 rapid feedback on damaged I-frames is wanted, the uniform reporting 753 interval for all senders could mean that audio sources are expected 754 to send RTCP packets more often than they send audio data packets. 755 This bandwidth mismatch can be reduced by careful tuning of the RTCP 756 parameters, especially trr_int when the RTP/AVPF profile is used, but 757 cannot be avoided entirely as it is inherent in the design of the 758 RTCP timing rules, and affects all RTP sessions that contain flows 759 with greatly mismatched bandwidth. 761 Different media rates or desired RTCP behaviours can also occur with 762 SSRCs carrying the same media type. A common case in multiparty 763 conferencing is when a small number of video streams are shown in 764 high resolution, while the others are shown as low resolution 765 thumbnails, with the choice of which is shown in high resolution 766 being voice activity controlled. Here the differences are both in 767 actual media rate and in choices for what feedback messages might be 768 needed. Other examples of differences that can exist are due to the 769 intended usage of a media source. A media source carrying the video 770 of the speaker in a conference is different from a document camera. 771 Basic parameters that can differ in this case are frame-rate, 772 acceptable end-to-end delay, and the SNR fidelity of the image. 773 These differences affect not only the needed bit-rates, but also 774 possible transmission behaviours, usable repair mechanisms, what 775 feedback messages the control and repair requires, the transmission 776 requirements on those feedback messages, and monitoring of the RTP 777 stream delivery. Other similar scenarios can also exist. 779 Sending multiple media types in a single RTP session causes that 780 session to contain more SSRCs than if each media type was sent in a 781 separate RTP session. For example, if two participants each send an 782 audio and a video RTP stream in a single RTP session, that session 783 will comprise four SSRCs, but if separate RTP sessions had been used 784 for audio and video, each of those two RTP sessions would comprise 785 only two SSRCs. Sending multiple RTP streams in an RTP session hence 786 increases the amount of cross reporting between the SSRCs, as each 787 SSRC reports on all other SSRCs in the session. This increases the 788 size of the RTCP reports, causing them to be sent less often than 789 would be the case if separate RTP sessions where used for a given 790 RTCP bandwidth. 792 Finally, when an RTP session contains multiple media types, it is 793 important to note that the RTCP reception quality reports, feedback 794 messages, and extended report blocks used might not be applicable to 795 all media types. Endpoints will need to consider the media type of 796 each SSRC only send or process reports and feedback that apply to 797 that particular SSRC and its media type. Signalling solutions might 798 have shortcomings when it comes to indicating that a particular set 799 of RTCP reports or feedback messages only apply to a particular media 800 type within an RTP session. 802 From an RTCP perspective, therefore, it can be seen that there are 803 advantages to using separate RTP sessions for each media source, 804 rather than sending multiple media sources in a single RTP session. 805 However, these are frequently offset by the need to reduce port use, 806 to ease NAT/firewall traversal, achieved by combining media sources 807 into a single RTP session. The following sections consider some of 808 the issues with using RTCP in sessions with multiple media sources in 809 more detail. 811 7.1. Timing out SSRCs 813 Various issues have been identified with timing out SSRC values when 814 sending multiple RTP streams in an RTP session. 816 7.1.1. Problems with the RTP/AVPF T_rr_interval Parameter 818 The RTP/AVPF profile includes a method to prevent regular RTCP 819 reports from being sent too often. This mechanism is described in 820 Section 3.5.3 of [RFC4585], and is controlled by the T_rr_interval 821 parameter. It works as follows. When a regular RTCP report is sent, 822 a new random value, T_rr_current_interval, is generated, drawn evenly 823 in the range 0.5 to 1.5 times T_rr_interval. If a regular RTCP 824 packet is to be sent earlier then T_rr_current_interval seconds after 825 the previous regular RTCP packet, and there are no feedback messages 826 to be sent, then that regular RTCP packet is suppressed, and the next 827 regular RTCP packet is scheduled. The T_rr_current_interval is 828 recalculated each time a regular RTCP packet is sent. The benefit of 829 suppression is that it avoids wasting bandwidth when there is nothing 830 requiring frequent RTCP transmissions, but still allows utilization 831 of the configured bandwidth when feedback is needed. 833 Unfortunately this suppression mechanism skews the distribution of 834 the RTCP sending intervals compared to the regular RTCP reporting 835 intervals. The standard RTCP timing rules, including reconsideration 836 and the compensation factor, result in the intervals between sending 837 RTCP packets having a distribution that is skewed towards the upper 838 end of the range [0.5/1.21828, 1.5/1.21828]*Td, where Td is the 839 deterministic calculated RTCP reporting interval. With Td = 5s this 840 distribution covers the range [2.052s, 6.156s]. In comparison, the 841 RTP/AVPF suppression rules act in an interval that is 0.5 to 1.5 842 times T_rr_interval; for T_rr_interval = 5s this is [2.5s, 7.5s]. 844 The effect of this is that the time between consecutive RTCP packets 845 when using T_rr_interval suppression can become large. The maximum 846 time interval between sending one regular RTCP packet and the next, 847 when T_rr_interval is being used, occurs when T_rr_current_interval 848 takes its maximum value and a regular RTCP packet is suppressed at 849 the end of the suppression period, then the next regular RTCP packet 850 is scheduled after its largest possible reporting interval. Taking 851 the worst case of the two intervals gives a maximum time between two 852 RTCP reports of 1.5*T_rr_interval + 1.5/1.21828*Td. 854 This behaviour can be surprising when Td and T_rr_interval have the 855 same value. That is, when T_rr_interval is configured to match the 856 regular RTCP reporting interval. In this case, one might expect that 857 regular RTCP packets are sent according to their usual schedule, but 858 feedback packets can be sent early. However, the above-mentioned 859 issue results in the RTCP packets actually being sent in the range 860 [0.5*Td, 2.731*Td] with a highly non-uniform distribution, rather 861 than the range [0.41*Td, 1.23*Td]. This is perhaps unexpected, but 862 is not a problem in itself. However, when coupled with packet loss, 863 it raises the issue of premature timeout. 865 7.1.2. Avoiding Premature Timeout 867 In RTP/AVP [RFC3550] the timeout behaviour is simple, and is 5 times 868 Td, where Td is calculated with a Tmin value of 5 seconds. In other 869 words, if the configured RTCP bandwidth allows for an average RTCP 870 reporting interval shorter than 5 seconds, the timeout is 25 seconds 871 of no activity from the SSRC (RTP or RTCP), otherwise the timeout is 872 5 average reporting intervals. 874 RTP/AVPF [RFC4585] introduces different timeout behaviours depending 875 on the value of T_rr_interval. When T_rr_interval is 0, it uses the 876 same timeout calculation as RTP/AVP. However, when T_rr_interval is 877 non-zero, it replaces Tmin in the timeout calculation, most likely to 878 speed up detection of timed out SSRCs. However, using a non-zero 879 T_rr_interval has two consequences for RTP behaviour. 881 First, due to suppression, the number of RTP and RTCP packets sent by 882 an SSRC that is not an active RTP sender can become very low, because 883 of the issue discussed in Section 7.1.1. As the RTCP packet interval 884 can be as long as 2.73*Td, then during a 5*Td time period an endpoint 885 might in fact transmit only a single RTCP packet. The long intervals 886 result in fewer RTCP packets, to a point where a single RTCP packet 887 loss can sometimes result in timing out an SSRC. 889 Second, the RTP/AVPF changes to the timeout rules reduce robustness 890 to misconfiguration. It is common to use RTP/AVPF configured such 891 that RTCP packets can be sent frequently, to allow rapid feedback, 892 however this makes timeouts very sensitive to T_rr_interval. For 893 example, if two SSRCs are configured one with T_rr_interval = 0.1s 894 and the other with T_rr_interval = 0.6s, then this small difference 895 will result in the SSRC with the shorter T_rr_interval timing out the 896 other if it stops sending RTP packets, since the other RTCP reporting 897 interval is more than five times its own. When RTP/AVP is used, or 898 RTP/AVPF with T_rr_interval = 0, this is a non-issue, as the timeout 899 period will be 25s, and differences between configured RTCP bandwidth 900 can only cause premature timeouts when the reporting intervals are 901 greater than 5s and differ by a factor of five. To limit the scope 902 for such problematic misconfiguration, we propose an update to the 903 RTP/AVPF timeout rules in Section 7.1.4. 905 7.1.3. Interoperability Between RTP/AVP and RTP/AVPF 907 If endpoints implementing the RTP/AVP and RTP/AVPF profiles (or their 908 secure variants) are combined within a single RTP session, and the 909 RTP/AVPF endpoints use a non-zero T_rr_interval that is significantly 910 below 5 seconds, there is a risk that the RTP/AVPF endpoints will 911 prematurely timeout the SSRCs of the RTP/AVP endpoints, due to their 912 different RTCP timeout rules. Conversely, if the RTP/AVPF endpoints 913 use a T_rr_interval that is significant larger than 5 seconds, there 914 is a risk that the RTP/AVP endpoints will timeout the SSRCs of the 915 RTP/AVPF endpoints. 917 Mixing endpoints using two different RTP profiles within a single RTP 918 session is NOT RECOMMENDED. However, if mixed RTP profiles are used, 919 and the RTP/AVPF endpoints are not updated to follow Section 7.1.4 of 920 this memo, then the RTP/AVPF session SHOULD be configured to use 921 T_rr_interval = 4 seconds to avoid premature timeouts. 923 The choice of T_rr_interval = 4 seconds for interoperability might 924 appear strange. Intuitively, this value ought to be 5 seconds, to 925 make both the RTP/AVP and RTP/AVPF use the same timeout period. 926 However, the behaviour outlined in Section 7.1.1 shows that actual 927 RTP/AVPF reporting intervals can be longer than expected. Setting 928 T_rr_interval = 4 seconds gives actual RTCP intervals near to those 929 expected by RTP/AVP, ensuring interoperability. 931 7.1.4. Updated SSRC Timeout Rules 933 To ensure interoperability and avoid premature timeouts, all SSRCs in 934 an RTP session MUST use the same timeout behaviour. However, 935 previous specification are inconsistent in this regard. To avoid 936 interoperability issues, this memo updates the timeout rules as 937 follows: 939 o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, the 940 timeout interval SHALL be calculated using a multiplier of five 941 times the deterministic RTCP reporting interval. That is, the 942 timeout interval SHALL be 5*Td. 944 o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, 945 calculation of Td, for the purpose of calculating the participant 946 timeout only, SHALL be done using a Tmin value of 5 seconds and 947 not the reduced minimal interval, even if the reduced minimum 948 interval is used to calculate RTCP packet transmission intervals. 950 This changes the behaviour for the RTP/AVPF or RTP/SAVPF profiles 951 when T_rr_interval != 0. Specifically, the first paragraph of 952 Section 3.5.4 of [RFC4585] is updated to use Tmin instead of 953 T_rr_interval in the timeout calculation for RTP/AVPF entities. 955 7.2. Tuning RTCP transmissions 957 This sub-section discusses what tuning can be done to reduce the 958 downsides of the shared RTCP packet intervals. First, it is 959 considered what possibilities exist for the RTP/AVP [RFC3551] 960 profile, then what additional tools are provided by RTP/AVPF 961 [RFC4585]. 963 7.2.1. RTP/AVP and RTP/SAVP 965 When using the RTP/AVP or RTP/SAVP profiles, the options for tuning 966 the RTCP reporting intervals are limited to the RTCP sender and 967 receiver bandwidth, and whether the minimum RTCP interval is scaled 968 according to the bandwidth. As the scheduling algorithm includes 969 both randomisation and reconsideration, one cannot simply calculate 970 the expected average transmission interval using the formula for Td 971 given in Section 6.3.1 of [RFC3550]. However, by considering the 972 inputs to that expression, and the randomisation and reconsideration 973 rules, we can begin to understand the behaviour of the RTCP 974 transmission interval. 976 Let's start with some basic observations: 978 a. Unless the scaled minimum RTCP interval is used, then Td prior to 979 randomization and reconsideration can never be less than Tmin. 980 The default value of Tmin is 5 seconds. 982 b. If the scaled minimum RTCP interval is used, Td can become as low 983 as 360 divided by RTP Session bandwidth in kilobits per second. 984 In SDP the RTP session bandwidth is signalled using a "b=AS" 985 line. An RTP Session bandwidth of 72kbps results in Tmin being 5 986 seconds. An RTP session bandwidth of 360kbps of course gives a 987 Tmin of 1 second, and to achieve a Tmin equal to once every frame 988 for a 25 frame-per-second video stream requires an RTP session 989 bandwidth of 9Mbps. Use of the RTP/AVPF or RTP/SAVPF profile 990 allows more frequent RTCP reports for the same bandwidth, as 991 discussed below. 993 c. The value of Td scales with the number of SSRCs and the average 994 size of the RTCP reports, to keep the overall RTCP bandwidth 995 constant. 997 d. The actual transmission interval for a Td value is in the range 998 [0.5*Td/1.21828,1.5*Td/1.21828], and the distribution is skewed, 999 due to reconsideration, with the majority of the probability mass 1000 being above Td. This means, for example, that for Td = 5s, the 1001 actual transmission interval will be distributed in the range 1002 [2.052s, 6.156s], and tending towards the upper half of the 1003 interval. Note that Tmin parameter limits the value of Td before 1004 randomisation and reconsideration are applied, so the actual 1005 transmission interval will cover a range extending below Tmin. 1007 Given the above, we can calculate the number of SSRCs, n, that an RTP 1008 session with 5% of the session bandwidth assigned to RTCP can support 1009 while maintaining Td equal to Tmin. This will tell us how many RTP 1010 streams we can report on, keeping the RTCP overhead within acceptable 1011 bounds. We make two assumptions that simplify the calculation: that 1012 all SSRCs are senders, and that they all send compound RTCP packets 1013 comprising an SR packet with n-1 report blocks, followed by an SDES 1014 packet containing a 16 octet CNAME value [RFC7022] (such RTCP packets 1015 will vary in size between 54 and 798 octets depending on n, up to the 1016 maximum of 31 report blocks that can be included in an SR packet). 1017 If we put this packet size, and a 5% RTCP bandwidth fraction into the 1018 RTCP interval calculation in Section 6.3.1 of [RFC3550], and 1019 calculate the value of n needed to give Td = Tmin for the scaled 1020 minimum interval, we find n=9 SSRCs can be supported (irrespective of 1021 the interval, due to the way the reporting interval scales with the 1022 session bandwidth). We see that to support more SSRCs without 1023 changing the scaled minimum interval, we need to increase the RTCP 1024 bandwidth fraction from 5%; changing the session bandwidth to a 1025 higher value would reduce the Tmin. However, if using the default 5% 1026 allocation of RTCP bandwidth, an increase will result in more SSRCs 1027 being supported given a fixed Td target. 1029 Based on the above, when using the RTP/AVP profile or the RTP/SAVP 1030 profile, the key limitation for rapid RTCP reporting in small unicast 1031 sessions is going to be the Tmin value. The RTP session bandwidth 1032 configured in RTCP has to be sufficiently high to reach the reporting 1033 goals the application has following the rules for the scaled minimal 1034 RTCP interval. 1036 7.2.2. RTP/AVPF and RTP/SAVPF 1038 When using RTP/AVPF or RTP/SAVPF, we have a powerful additional tool 1039 for tuning RTCP transmissions: the T_rr_interval parameter. Use of 1040 this parameter allows short RTCP reporting intervals; alternatively 1041 it gives the ability to sent frequent RTCP feedback without sending 1042 frequent regular RTCP reports. 1044 The use of the RTP/AVPF or RTP/SAVPF profile with T_rr_interval set 1045 to a value greater than zero but smaller than Tmin allows more 1046 frequent RTCP feedback than the RTP/AVP or RTP/SAVP profiles, for a 1047 given RTCP bandwidth. This happens because Tmin is set to zero after 1048 the transmission of the initial RTCP report, causing the reporting 1049 interval for later packet to be determined by the usual RTCP 1050 bandwidth-based calculation, with Tmin=0, and the T_rr_interval. 1051 This has the effect that we are no longer restricted by the minimal 1052 interval (whether the default 5 second minimum, or the reduced 1053 minimum interval). Rather, the RTCP bandwidth and the T_rr_interval 1054 are the governing factors, allowing faster feedback. Applications 1055 that care about rapid regular RTCP feedback ought to consider using 1056 the RTP/AVPF or RTP/SAVPF profile, even if they don't use the 1057 feedback features of that profile. 1059 The use of the RTP/AVPF or RTP/SAVPF profile allows RTCP feedback 1060 packets to be sent frequently, without also requiring regular RTCP 1061 reports to be sent frequently, since T_rr_interval limits the rate at 1062 which regular RTCP packets can be sent, while still permitting RTCP 1063 feedback packets to be sent. Applications that can use feedback 1064 packets for some RTP streams, e.g., video streams, but don't want 1065 frequent regular reporting for other RTP streams, can configure the 1066 T_rr_interval to a value so that the regular reporting for both audio 1067 and video is at a level that is considered acceptable for the audio. 1068 They could then use feedback packets, which will include RTCP SR/RR 1069 packets unless reduced size RTCP feedback packets [RFC5506] are used, 1070 for the video reporting. This allows the available RTCP bandwidth to 1071 be devoted on the feedback that provides the most utility for the 1072 application. 1074 Using T_rr_interval still requires one to determine suitable values 1075 for the RTCP bandwidth value. Indeed, it might make this choice even 1076 more important, as this is more likely to affect the RTCP behaviour 1077 and performance than when using the RTP/AVP or RTP/SAVP profile, as 1078 there are fewer limitations affecting the RTCP transmission. 1080 When T_rr_interval is non-zero, there are configurations that need to 1081 be avoided. If the RTCP bandwidth chosen is such that the Td value 1082 is smaller than, but close to, T_rr_interval, then the actual regular 1083 RTCP packet transmission interval can become very large, as discussed 1084 in Section 7.1.1. Therefore, for configuration where one intends to 1085 have Td smaller than T_rr_interval, then Td is RECOMMENDED to be 1086 targeted at values less than 1/4th of T_rr_interval which results in 1087 that the range becomes [0.5*T_rr_interval, 1.81*T_rr_interval]. 1089 With the RTP/AVPF or RTP/SAVPF profiles, using T_rr_interval = 0 has 1090 utility, and results in a behaviour where the RTCP transmission is 1091 only limited by the bandwidth, i.e., no Tmin limitations at all. 1092 This allows more frequent regular RTCP reporting than can be achieved 1093 using the RTP/AVP profile. Many configurations of RTCP will not 1094 consume all the bandwidth that they have been configured to use, but 1095 this configuration will consume what it has been given. Note that 1096 the same behaviour will be achieved as long as T_rr_interval is 1097 smaller than 1/3 of Td as that prevents T_rr_interval from affecting 1098 the transmission. 1100 There exists no method for using different regular RTCP reporting 1101 intervals depending on the media type or individual RTP stream, other 1102 than using a separate RTP session for each type or stream. 1104 8. Security Considerations 1106 When using the secure RTP protocol (RTP/SAVP) [RFC3711], or the 1107 secure variant of the feedback profile (RTP/SAVPF) [RFC5124], the 1108 cryptographic context of a compound secure RTCP packet is the SSRC of 1109 the sender of the first RTCP (sub-)packet. This could matter in some 1110 cases, especially for keying mechanisms such as Mikey [RFC3830] which 1111 allow use of per-SSRC keying. 1113 Otherwise, the standard security considerations of RTP apply; sending 1114 multiple RTP streams from a single endpoint in a single RTP session 1115 does not appear to have different security consequences than sending 1116 the same number of RTP streams spread across different RTP sessions. 1118 9. IANA Considerations 1120 No IANA actions are needed. 1122 10. Acknowledgments 1124 The authors like to thank Harald Alvestrand and everyone else who has 1125 been involved in the development of this document. 1127 11. References 1129 11.1. Normative References 1131 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1132 Requirement Levels", BCP 14, RFC 2119, 1133 DOI 10.17487/RFC2119, March 1997, 1134 . 1136 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1137 Jacobson, "RTP: A Transport Protocol for Real-Time 1138 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1139 July 2003, . 1141 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1142 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1143 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1144 . 1146 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1147 "Extended RTP Profile for Real-time Transport Control 1148 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1149 DOI 10.17487/RFC4585, July 2006, 1150 . 1152 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1153 Real-time Transport Control Protocol (RTCP)-Based Feedback 1154 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 1155 2008, . 1157 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1158 Real-Time Transport Control Protocol (RTCP): Opportunities 1159 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 1160 2009, . 1162 11.2. Informative References 1164 [I-D.ietf-avtcore-multi-media-rtp-session] 1165 Westerlund, M., Perkins, C., and J. Lennox, "Sending 1166 Multiple Types of Media in a Single RTP Session", draft- 1167 ietf-avtcore-multi-media-rtp-session-12 (work in 1168 progress), December 2015. 1170 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] 1171 Lennox, J., Westerlund, M., Wu, W., and C. Perkins, 1172 "Sending Multiple Media Streams in a Single RTP Session: 1173 Grouping RTCP Reception Statistics and Other Feedback", 1174 draft-ietf-avtcore-rtp-multi-stream-optimisation-09 (work 1175 in progress), November 2015. 1177 [I-D.ietf-clue-framework] 1178 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 1179 for Telepresence Multi-Streams", draft-ietf-clue- 1180 framework-24 (work in progress), November 2015. 1182 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1183 Holmberg, C., Alvestrand, H., and C. Jennings, 1184 "Negotiating Media Multiplexing Using the Session 1185 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1186 negotiation-23 (work in progress), July 2015. 1188 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 1189 Initial Window", RFC 3390, DOI 10.17487/RFC3390, October 1190 2002, . 1192 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1193 Video Conferences with Minimal Control", STD 65, RFC 3551, 1194 DOI 10.17487/RFC3551, July 2003, 1195 . 1197 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 1198 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 1199 RFC 3556, DOI 10.17487/RFC3556, July 2003, 1200 . 1202 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1203 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1204 DOI 10.17487/RFC3830, August 2004, 1205 . 1207 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1208 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1209 DOI 10.17487/RFC4588, July 2006, 1210 . 1212 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1213 "Codec Control Messages in the RTP Audio-Visual Profile 1214 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 1215 February 2008, . 1217 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1218 Media Attributes in the Session Description Protocol 1219 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1220 . 1222 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 1223 "RTP Payload Format for Scalable Video Coding", RFC 6190, 1224 DOI 10.17487/RFC6190, May 2011, 1225 . 1227 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1228 "Increasing TCP's Initial Window", RFC 6928, 1229 DOI 10.17487/RFC6928, April 2013, 1230 . 1232 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 1233 "Guidelines for Choosing RTP Control Protocol (RTCP) 1234 Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, 1235 September 2013, . 1237 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 1238 Clock Rates in an RTP Session", RFC 7160, 1239 DOI 10.17487/RFC7160, April 2014, 1240 . 1242 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 1243 DOI 10.17487/RFC7667, November 2015, 1244 . 1246 [Sim88] Westerlund, M., "SIMULATION RESULTS FOR MULTI-STREAM", 1247 IETF Proceedings 1248 https://www.ietf.org/proceedings/92/slides/slides-92- 1249 avtcore-0.pdf, November 2013. 1251 [Sim92] Westerlund, M., "Changes in RTP Multi-stream", IETF 1252 Proceedings 1253 https://www.ietf.org/proceedings/92/slides/slides-92- 1254 avtcore-0.pdf, March 2015. 1256 Authors' Addresses 1258 Jonathan Lennox 1259 Vidyo, Inc. 1260 433 Hackensack Avenue 1261 Seventh Floor 1262 Hackensack, NJ 07601 1263 USA 1265 Email: jonathan@vidyo.com 1267 Magnus Westerlund 1268 Ericsson 1269 Farogatan 2 1270 SE-164 80 Kista 1271 Sweden 1273 Phone: +46 10 714 82 87 1274 Email: magnus.westerlund@ericsson.com 1276 Qin Wu 1277 Huawei 1278 101 Software Avenue, Yuhua District 1279 Nanjing, Jiangsu 210012 1280 China 1282 Email: bill.wu@huawei.com 1284 Colin Perkins 1285 University of Glasgow 1286 School of Computing Science 1287 Glasgow G12 8QQ 1288 United Kingdom 1290 Email: csp@csperkins.org