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