From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8108.txt | 1627 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1627 insertions(+) create mode 100644 doc/rfc/rfc8108.txt (limited to 'doc/rfc/rfc8108.txt') diff --git a/doc/rfc/rfc8108.txt b/doc/rfc/rfc8108.txt new file mode 100644 index 0000000..36e68a0 --- /dev/null +++ b/doc/rfc/rfc8108.txt @@ -0,0 +1,1627 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Lennox +Request for Comments: 8108 Vidyo +Updates: 3550, 4585 M. Westerlund +Category: Standards Track Ericsson +ISSN: 2070-1721 Q. Wu + Huawei + C. Perkins + University of Glasgow + March 2017 + + + Sending Multiple RTP Streams in a Single RTP Session + +Abstract + + This memo expands and clarifies the behavior of Real-time Transport + Protocol (RTP) endpoints that use multiple synchronization sources + (SSRCs). This occurs, for example, when an endpoint sends multiple + RTP streams in a single RTP session. This memo updates RFC 3550 with + regard to handling multiple SSRCs per endpoint in RTP sessions, with + a particular focus on RTP Control Protocol (RTCP) behavior. It also + updates RFC 4585 to change and clarify the calculation of the timeout + of SSRCs and the inclusion of feedback messages. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8108. + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 1] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 2] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Terminology .....................................................4 + 3. Use Cases for Multi-Stream Endpoints ............................4 + 3.1. Endpoints with Multiple Capture Devices ....................4 + 3.2. Multiple Media Types in a Single RTP Session ...............5 + 3.3. Multiple Stream Mixers .....................................5 + 3.4. Multiple SSRCs for a Single Media Source ...................5 + 4. Use of RTP by Endpoints That Send Multiple Media Streams ........6 + 5. Use of RTCP by Endpoints That Send Multiple Media Streams .......6 + 5.1. RTCP Reporting Requirement .................................7 + 5.2. Initial Reporting Interval .................................7 + 5.3. Aggregation of Reports into Compound RTCP Packets ..........8 + 5.3.1. Maintaining AVG_RTCP_SIZE ...........................9 + 5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs ....10 + 5.4. Use of RTP/AVPF or RTP/SAVPF Feedback .....................13 + 5.4.1. Choice of SSRC for Feedback Packets ................13 + 5.4.2. Scheduling an RTCP Feedback Packet .................14 + 6. Adding and Removing SSRCs ......................................15 + 6.1. Adding RTP Streams ........................................16 + 6.2. Removing RTP Streams ......................................16 + 7. RTCP Considerations for Streams with Disparate Rates ...........17 + 7.1. Timing Out SSRCs ..........................................19 + 7.1.1. Problems with the RTP/AVPF T_rr_interval + Parameter ..........................................19 + 7.1.2. Avoiding Premature Timeout .........................20 + 7.1.3. Interoperability between RTP/AVP and RTP/AVPF ......21 + 7.1.4. Updated SSRC Timeout Rules .........................22 + 7.2. Tuning RTCP Transmissions .................................22 + 7.2.1. RTP/AVP and RTP/SAVP ...............................22 + 7.2.2. RTP/AVPF and RTP/SAVPF .............................24 + 8. Security Considerations ........................................25 + 9. References .....................................................26 + 9.1. Normative References ......................................26 + 9.2. Informative References ....................................26 + Acknowledgments ...................................................29 + Authors' Addresses ................................................29 + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 3] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +1. Introduction + + At the time the Real-Time Transport Protocol (RTP) [RFC3550] was + originally designed, and for quite some time after, endpoints in RTP + sessions typically only transmitted a single media source and, thus, + used a single RTP stream and synchronization source (SSRC) per RTP + session, where separate RTP sessions were typically used for each + distinct media type. Recently, however, a number of scenarios have + emerged in which endpoints wish to send multiple RTP streams, + distinguished by distinct RTP synchronization source (SSRC) + identifiers, in a single RTP session. These are outlined in + Section 3. Although the initial design of RTP did consider such + scenarios, the specification was not consistently written with such + use cases in mind; thus, the specification is somewhat unclear in + places. + + This memo updates [RFC3550] to clarify behavior in use cases where + endpoints use multiple SSRCs. It also updates [RFC4585] to resolve + problems with regard to timeout of inactive SSRCs and to clarify + behavior around inclusion of feedback messages. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119] and indicate requirement levels for compliant + implementations. + +3. Use Cases for Multi-Stream Endpoints + + This section discusses several use cases that have motivated the + development of endpoints that sends RTP data using multiple SSRCs in + a single RTP session. + +3.1. Endpoints with Multiple Capture Devices + + The most straightforward motivation for an endpoint to send multiple + simultaneous RTP streams in a single RTP session is when an endpoint + has multiple capture devices and, hence, can generate multiple media + sources, of the same media type and characteristics. For example, + telepresence systems of the type described by the CLUE Telepresence + Framework [CLUE-FRAME] often have multiple cameras or microphones + covering various areas of a room and, hence, send several RTP streams + of each type within a single RTP session. + + + + + + +Lennox, et al. Standards Track [Page 4] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +3.2. Multiple Media Types in a Single RTP Session + + Recent work has updated RTP [MULTI-RTP] and Session Description + Protocol (SDP) [SDP-BUNDLE] to remove the historical assumption in + RTP that media sources of different media types would always be sent + on different RTP sessions. In this work, a single endpoint's audio + and video RTP streams (for example) are instead sent in a single RTP + session to reduce the number of transport-layer flows used. + +3.3. Multiple Stream Mixers + + There are several RTP topologies that can involve a central device + that itself generates multiple RTP streams in a session. An example + is a mixer providing centralized compositing for a multi-capture + scenario like that described in Section 3.1. In this case, the + centralized node is behaving much like a multi-capturer endpoint, + generating several similar and related sources. + + A more complex example is the selective forwarding middlebox, + described in Section 3.7 of [RFC7667]. This is a middlebox that + receives RTP streams from several endpoints and then selectively + forwards modified versions of some RTP streams toward the other + endpoints to which it is connected. For each connected endpoint, a + separate media source appears in the session for every other source + connected to the middlebox, "projected" from the original streams, + but at any given time many of them can appear to be inactive (and + thus are receivers, not senders, in RTP). This sort of device is + closer to being an RTP mixer than an RTP translator: it terminates + RTCP reporting about the mixed streams; it can rewrite SSRCs, + timestamps, and sequence numbers, as well as the contents of the RTP + payloads; and it can turn sources on and off at will without + appearing to generate packet loss. Each projected stream will + typically preserve its original RTCP source description (SDES) + information. + +3.4. Multiple SSRCs for a Single Media Source + + There are also several cases where multiple SSRCs can be used to send + data from a single media source within a single RTP session. These + include, but are not limited to, transport robustness tools, such as + the RTP retransmission payload format [RFC4588], that require one + SSRC to be used for the media data and another SSRC for the repair + data. Similarly, some layered media encoding schemes, for example, + H.264 Scalable Video Coding (SVC) [RFC6190], can be used in a + configuration where each layer is sent using a different SSRC within + a single RTP session. + + + + + +Lennox, et al. Standards Track [Page 5] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +4. Use of RTP by Endpoints That Send Multiple Media Streams + + RTP is inherently a group communication protocol. Each endpoint in + an RTP session will use one or more SSRCs, as will some types of RTP- + level middlebox. Accordingly, unless restrictions on the number of + SSRCs have been signaled, RTP endpoints can expect to receive RTP + data packets sent using a number of different SSRCs, within a single + RTP session. This can occur irrespective of whether the RTP session + is running over a point-to-point connection or a multicast group, + since middleboxes can be used to connect multiple transport + connections together into a single RTP session (the RTP session is + defined by the shared SSRC space, not by the transport connections). + Furthermore, if RTP mixers are used, some SSRCs might only be visible + in the contributing source (CSRC) list of an RTP packet and in RTCP, + and might not appear directly as the SSRC of an RTP data packet. + + Every RTP endpoint will have an allocated share of the available + session bandwidth, as determined by signaling and congestion control. + The endpoint needs to keep its total media sending rate within this + share. However, endpoints that send multiple RTP streams do not + necessarily need to subdivide their share of the available bandwidth + independently or uniformly to each RTP stream and its SSRCs. In + particular, an endpoint can vary the bandwidth allocation to + different streams depending on their needs, and it can dynamically + change the bandwidth allocated to different SSRCs (for example, by + using a variable-rate codec), provided the total sending rate does + not exceed its allocated share. This includes enabling or disabling + RTP streams, or their redundancy streams, as more or less bandwidth + becomes available. + +5. Use of RTCP by Endpoints That Send Multiple Media Streams + + RTCP is defined in Section 6 of [RFC3550]. The description of the + protocol is phrased in terms of the behavior of "participants" in an + RTP session, under the assumption that each endpoint is a participant + with a single SSRC. However, for correct operation in cases where + endpoints have multiple SSRC values, implementations MUST treat each + SSRC as a separate participant in the RTP session, so that an + endpoint that has multiple SSRCs counts as multiple participants. + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 6] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +5.1. RTCP Reporting Requirement + + An RTP endpoint that has multiple SSRCs MUST treat each SSRC as a + separate participant in the RTP session. Each SSRC will maintain its + own RTCP-related state information and, hence, will have its own RTCP + reporting interval that determines when it sends RTCP reports. If + the mechanism in [MULTI-STREAM-OPT] is not used, then each SSRC will + send RTCP reports for all other SSRCs, including those co-located at + the same endpoint. + + If the endpoint has some SSRCs that are sending data and some that + are only receivers, then they will receive different shares of the + RTCP bandwidth and calculate different base RTCP reporting intervals. + Otherwise, all SSRCs at an endpoint will calculate the same base RTCP + reporting interval. The actual reporting intervals for each SSRC are + randomized in the usual way, but reports can be aggregated as + described in Section 5.3. + +5.2. Initial Reporting Interval + + When a participant joins a unicast session, the following text from + Section 6.2 of [RFC3550] is relevant: "For unicast sessions... the + delay before sending the initial compound RTCP packet MAY be zero." + The basic assumption is that this also ought to apply in the case of + multiple SSRCs. Caution has to be exercised, however, when an + endpoint (or middlebox) with a large number of SSRCs joins a unicast + session, since immediate transmission of many RTCP reports can create + a significant burst of traffic, leading to transient congestion and + packet loss due to queue overflows. + + To ensure that the initial burst of traffic generated by an RTP + endpoint is no larger than would be generated by a TCP connection, an + RTP endpoint MUST NOT send more than four compound RTCP packets with + zero initial delay when it joins an RTP session, independent of the + number of SSRCs used by the endpoint. Each of those initial compound + RTCP packets MAY include aggregated reports from multiple SSRCs, + provided the total compound RTCP packet size does not exceed the MTU, + and the avg_rtcp_size is maintained as in Section 5.3.1. Aggregating + reports from several SSRCs in the initial compound RTCP packets + allows a substantial number of SSRCs to report immediately. + Endpoints SHOULD prioritize reports on SSRCs that are likely to be + most immediately useful, e.g., for SSRCs that are initially senders. + + An endpoint that needs to report on more SSRCs than will fit into the + four compound RTCP reports that can be sent immediately MUST send the + other reports later, following the usual RTCP timing rules including + timer reconsideration. Those reports MAY be aggregated as described + in Section 5.3. + + + +Lennox, et al. Standards Track [Page 7] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + Note: The above is chosen to match the TCP maximum initial window + of four packets [RFC3390], not the larger TCP initial windows for + which there is an ongoing experiment [RFC6928]. The reason for + this is a desire to be conservative, since an RTP endpoint will + also in many cases start sending RTP data packets at the same time + as these initial RTCP packets are sent. + +5.3. Aggregation of Reports into Compound RTCP Packets + + As outlined in Section 5.1, an endpoint with multiple SSRCs has to + treat each SSRC as a separate participant when it comes to sending + RTCP reports. This will lead to each SSRC sending a compound RTCP + packet in each reporting interval. Since these packets are coming + from the same endpoint, it might reasonably be expected that they can + be aggregated to reduce overheads. Indeed, Section 6.1 of [RFC3550] + allows RTP translators and mixers to aggregate packets in similar + circumstances: + + It is RECOMMENDED that translators and mixers combine individual + RTCP packets from the multiple sources they are forwarding into + one compound packet whenever feasible in order to amortize the + packet overhead (see Section 7). An example RTCP compound packet + as might be produced by a mixer is shown in Fig. 1. If the + overall length of a compound packet would exceed the MTU of the + network path, it SHOULD be segmented into multiple shorter + compound packets to be transmitted in separate packets of the + underlying protocol. This does not impair the RTCP bandwidth + estimation because each compound packet represents at least one + distinct participant. Note that each of the compound packets MUST + begin with an SR or RR packet. + + This allows RTP translators and mixers to generate compound RTCP + packets that contain multiple Sender Report (SR) or Receiver Report + (RR) packets from different SSRCs, as well as any of the other packet + types. There are no restrictions on the order in which the RTCP + packets can occur within the compound packet, except the regular rule + that the compound RTCP packet starts with an SR or RR packet. Due to + this rule, correctly implemented RTP endpoints will be able to handle + compound RTCP packets that contain RTCP packets relating to multiple + SSRCs. + + Accordingly, endpoints that use multiple SSRCs can aggregate the RTCP + packets sent by their different SSRCs into compound RTCP packets, + provided 1) the resulting compound RTCP packets begin with an SR or + RR packet, 2) they maintain the average RTCP packet size as described + in Section 5.3.1, and 3) they schedule packet transmission and manage + aggregation as described in Section 5.3.2. + + + + +Lennox, et al. Standards Track [Page 8] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +5.3.1. Maintaining AVG_RTCP_SIZE + + The RTCP scheduling algorithm in [RFC3550] works on a per-SSRC basis. + Each SSRC sends a single compound RTCP packet in each RTCP reporting + interval. When an endpoint uses multiple SSRCs, it is desirable to + aggregate the compound RTCP packets sent by its SSRCs, reducing the + overhead by forming a larger compound RTCP packet. This aggregation + can be done as described in Section 5.3.2, provided the average RTCP + packet size calculation is updated as follows. + + Participants in an RTP session update their estimate of the average + RTCP packet size (avg_rtcp_size) each time they send or receive an + RTCP packet (see Section 6.3.3 of [RFC3550]). When a compound RTCP + packet that contains RTCP packets from several SSRCs is sent or + received, the avg_rtcp_size estimate for each SSRC that is reported + upon is updated using div_packet_size rather than the actual packet + size: + + avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size + + where div_packet_size is packet_size divided by the number of SSRCs + reporting in that compound packet. The number of SSRCs reporting in + a compound packet is determined by counting the number of different + SSRCs that are the source of SR or RR RTCP packets within the + compound RTCP packet. Non-compound RTCP packets (i.e., RTCP packets + that do not contain an SR or RR packet [RFC5506]) are considered to + report on a single SSRC. + + A participant that doesn't follow the above rule, and instead uses + the full RTCP compound packet size to calculate avg_rtcp_size, will + derive an RTCP reporting interval that is overly large by a factor + that is proportional to the number of SSRCs aggregated into compound + RTCP packets and the size of set of SSRCs being aggregated relative + to the total number of participants. This increased RTCP reporting + interval can cause premature timeouts if it is more than five times + the interval chosen by the SSRCs that understand compound RTCP that + aggregate reports from many SSRCs. A 1500-octet MTU can fit five + typical-size reports into a compound RTCP packet, so this is a real + concern if endpoints aggregate RTCP reports from multiple SSRCs. + + The issue raised in the previous paragraph is mitigated by the + modification in timeout behavior specified in Section 7.1.2 of this + memo. This mitigation is in place in those cases where the RTCP + bandwidth is sufficiently high that an endpoint, using avg_rtcp_size + calculated without taking into account the number of reporting SSRCs, + can transmit more frequently than approximately every 5 seconds. + Note, however, that the non-updated endpoint's RTCP reporting is + still negatively impacted even if the premature timeouts of its SSRCs + + + +Lennox, et al. Standards Track [Page 9] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + are avoided. If compatibility with non-updated endpoints is a + concern, the number of reports from different SSRCs aggregated into a + single compound RTCP packet SHOULD either be limited to two reports + or aggregation ought not be used at all. This will limit the + non-updated endpoint's RTCP reporting interval to be no larger than + twice the RTCP reporting interval that would be chosen by an endpoint + following this specification. + +5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs + + This section revises and extends the behavior defined in Section 6.3 + of [RFC3550], and in Section 3.5.3 of [RFC4585] if the RTP/AVPF + profile or the RTP/SAVPF profile is used, regarding actions to take + when scheduling and sending RTCP packets where multiple reporting + SSRCs are aggregating their RTCP packets into the same compound RTCP + packet. These changes to the RTCP scheduling rules are needed to + maintain important RTCP timing properties, including the inter-packet + distribution, and the behavior during flash joins and other changes + in session membership. + + The variables tn, tp, tc, T, and Td used in the following are defined + in Section 6.3 of [RFC3550]. The variables T_rr_interval and + T_rr_last are defined in [RFC4585]. + + Each endpoint MUST schedule RTCP transmission independently for each + of its SSRCs using the regular calculation of tn for the RTP profile + being used. Each time the timer tn expires for an SSRC, the endpoint + MUST perform RTCP timer reconsideration and, if applicable, + suppression based on T_rr_interval. If the result indicates that a + compound RTCP packet is to be sent by that SSRC, and the transmission + is not an early RTCP packet [RFC4585], then the endpoint SHOULD try + to aggregate RTCP packets of additional SSRCs that are scheduled in + the future into the compound RTCP packet before it is sent. The + reason to limit or not aggregate due to backwards compatibility + reasons is discussed in Section 5.3.1. + + Aggregation proceeds as follows. The endpoint selects the SSRC that + has the smallest tn value after the current time, tc, and prepares + the RTCP packets that SSRC would send if its timer tn expired at tc. + If those RTCP packets will fit into the compound RTCP packet that is + being generated, taking into account the path MTU and the previously + added RTCP packets, then they are added to the compound RTCP packet; + otherwise, they are discarded. This process is repeated for each + SSRC, in order of increasing tn, until the compound RTCP packet is + full or all SSRCs have been aggregated. At that point, the compound + RTCP packet is sent. + + + + + +Lennox, et al. Standards Track [Page 10] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + When the compound RTCP packet is sent, the endpoint MUST update tp, + tn, and T_rr_last (if applicable) for each SSRC that was included. + These variables are updated as follows: + + a. For the first SSRC that reported in the compound RTCP packet, set + the effective transmission time, tt, of that SSRC to tc. + + b. For each additional SSRC that reported in the compound RTCP + packet, calculate the transmission time that SSRC would have had + if it had not been aggregated into the compound RTCP packet. + This is derived by taking tn for that SSRC, then performing + reconsideration and updating tn until tp + T <= tn. Once this is + done, set the effective transmission time, tt, for that SSRC to + the calculated value of tn. If the RTP/AVPF profile or the RTP/ + SAVPF profile is being used, then suppression based on + T_rr_interval MUST NOT be used in this calculation. + + c. Calculate average effective transmission time, tt_avg, for the + compound RTCP packet based on the tt values for all SSRCs sent in + the compound RTCP packet. Set tp for each of the SSRCs sent in + the compound RTCP packet to tt_avg. If the RTP/AVPF profile or + the RTP/SAVPF profile is being used, set T_tt_last for each SSRC + sent in the compound RTCP packet to tt_avg. + + d. For each of the SSRCs sent in the compound RTCP packet, calculate + new tn values based on the updated parameters and the usual RTCP + timing rules and reschedule the timers. + + When using the RTP/AVPF profile or the RTP/SAVPF profile, the above + mechanism only attempts to aggregate RTCP packets when the compound + RTCP packet to be sent is not an early RTCP packet, and hence the + algorithm in Section 3.5.3 of [RFC4585] will control RTCP scheduling. + If T_rr_interval == 0, or if T_rr_interval != 0 and option 1, 2a, or + 2b of the algorithm are chosen, then the above mechanism updates the + necessary variables. However, if the transmission is suppressed per + option 2c of the algorithm, then tp is updated to tc as aggregation + has not taken place. + + Reverse reconsideration MUST be performed following Section 6.3.4 of + [RFC3550]. In some cases, this can lead to the value of tp after + reverse reconsideration being larger than tc. This is not a problem, + and has the desired effect of proportionally pulling the tp value + towards tc (as well as tn) as the reporting interval shrinks in + direct proportion the reduced group size. + + The above algorithm has been shown in simulations [Sim88] [Sim92] to + maintain the inter-RTCP packet transmission time distribution for + each SSRC and to consume the same amount of bandwidth as + + + +Lennox, et al. Standards Track [Page 11] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + non-aggregated RTCP packets. With this algorithm, the actual + transmission interval for an SSRC triggering an RTCP compound packet + transmission is following the regular transmission rules. The value + tp is set to somewhere in the interval [0, 1.5/1.21828*Td] ahead of + tc. The actual value is the average of one instance of tc and the + randomized transmission times of the additional SSRCs; thus, the + lower range of the interval is more probable. This compensates for + the bias that is otherwise introduced by picking the shortest tn + value out of the N SSRCs included in aggregate. + + The algorithm also handles the cases where the number of SSRCs that + can be included in an aggregated packet varies. An SSRC that + previously was aggregated and fails to fit in a packet still has its + own transmission scheduled according to normal rules. Thus, it will + trigger a transmission in due time, or the SSRC will be included in + another aggregate. The algorithm's behavior under SSRC group size + changes is as follows: + + RTP sessions where the number of SSRCs is growing: When the group + size is growing, Td grows in proportion to the number of new SSRCs + in the group. When reconsideration is performed due to expiry of + the tn timer, that SSRC will reconsider the transmission and with + a certain probability reschedule the tn timer. This part of the + reconsideration algorithm is only impacted by the above algorithm + having tp values that were in the future instead of set to the + time of the actual last transmission at the time of updating tp. + + RTP sessions where the number of SSRCs is shrinking: When the group + shrinks, reverse reconsideration moves the tp and tn values + towards tc proportionally to the number of SSRCs that leave the + session compared to the total number of participants when they + left. The setting of the tp value forward in time related to the + tc could be believed to have negative effect. However, the reason + for this setting is to compensate for bias caused by picking the + shortest tn out of the N aggregated. This bias remains over a + reduction in the number of SSRCs. The reverse reconsideration + compensates the reduction independently of whether or not + aggregation is being used. The negative effect that can occur on + removing an SSRC is that the most favorable tn belonged to the + removed SSRC. The impact of this is limited to delaying the + transmission, in the worst case, one reporting interval. + + In conclusion, the investigations performed have found no significant + negative impact on the scheduling algorithm. + + + + + + + +Lennox, et al. Standards Track [Page 12] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +5.4. Use of RTP/AVPF or RTP/SAVPF Feedback + + This section discusses the transmission of RTP/AVPF feedback packets + when the transmitting endpoint has multiple SSRCs. The guidelines in + this section also apply to endpoints using the RTP/SAVPF profile. + +5.4.1. Choice of SSRC for Feedback Packets + + When an RTP/AVPF endpoint has multiple SSRCs, it can choose what SSRC + to use as the source for the RTCP feedback packets it sends. Several + factors can affect that choice: + + o RTCP feedback packets relating to a particular media type SHOULD + be sent by an SSRC that receives that media type. For example, + when audio and video are multiplexed onto a single RTP session, + endpoints will use their audio SSRC to send feedback on the audio + received from other participants. + + o RTCP feedback packets and RTCP codec control messages that are + notifications or indications regarding RTP data processed by an + endpoint MUST be sent from the SSRC used for that RTP data. This + includes notifications that relate to a previously received + request or command [RFC4585][RFC5104]. + + o If separate SSRCs are used to send and receive media, then the + corresponding SSRC SHOULD be used for feedback, since they have + differing RTCP bandwidth fractions. This can also affect the + consideration of whether or not the SSRC can be used in immediate + mode. + + o Some RTCP feedback packet types require consistency in the SSRC + used. For example, if a Temporary Maximum Media Stream Bit Rate + Request (TMMBR) limitation [RFC5104] is set by an SSRC, the same + SSRC needs to be used to remove the limitation. + + o If several SSRCs are suitable for sending feedback, it might be + desirable to use an SSRC that allows the sending of feedback as an + early RTCP packet. + + When an RTCP feedback packet is sent as part of a compound RTCP + packet that aggregates reports from multiple SSRCs, there is no + requirement that the compound packet contain an SR or RR packet + generated by the sender of the RTCP feedback packet. For reduced- + size RTCP packets, aggregation of RTCP feedback packets from multiple + sources is not limited further than Section 4.2.2 of [RFC5506]. + + + + + + +Lennox, et al. Standards Track [Page 13] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +5.4.2. Scheduling an RTCP Feedback Packet + + When an SSRC has a need to transmit a feedback packet in early mode, + it MUST schedule that packet following the algorithm in Section 3.5 + of [RFC4585] modified as follows: + + o To determine whether an RTP session is considered to be a point- + to-point session or a multiparty session, an endpoint MUST count + the number of distinct RTCP SDES CNAME values used by the SSRCs + listed in the SSRC field of RTP data packets it receives and in + the "SSRC of sender" field of RTCP SR, RR, RTPFB, or PSFB packets + it receives. An RTP session is considered to be a multiparty + session if more than one CNAME is used by those SSRCs, unless + signaling indicates that the session is to be handled as point to + point or RTCP reporting groups [MULTI-STREAM-OPT] are used. If + RTCP reporting groups are used, an RTP session is considered to be + a point-to-point session if the endpoint receives only a single + reporting group and is considered to be a multiparty session if + multiple reporting groups are received or a combination of + reporting groups and SSRCs that are not part of a reporting group + are received. Endpoints MUST NOT determine whether an RTP session + is multiparty or point to point based on the type of connection + (unicast or multicast) used, or on the number of SSRCs received. + + o When checking if there is already a scheduled compound RTCP packet + containing feedback messages (Step 2 in Section 3.5.2 of + [RFC4585]), that check MUST be done considering all local SSRCs. + + o If an SSRC is not allowed to send an early RTCP packet, then the + feedback message MAY be queued for transmission as part of any + early or regular scheduled transmission that can occur within the + maximum useful lifetime of the feedback message (T_max_fb_delay). + This modifies the behavior in item 4a in Section 3.5.2 of + [RFC4585]. + + The first bullet point above specifies a rule to determine if an RTP + session is to be considered a point-to-point session or a multiparty + session. This rule is straightforward to implement, but is known to + incorrectly classify some sessions as multiparty sessions. The known + problems are as follows: + + Endpoint with multiple synchronization contexts: An endpoint that is + part of a point-to-point session can have multiple synchronization + contexts, for example, due to forwarding an external media source + into an interactive real-time conversation. In this case, the + classification will consider the peer as two endpoints, while the + actual RTP/RTCP transmission will be under the control of one + endpoint. + + + +Lennox, et al. Standards Track [Page 14] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + Selective Forwarding Middlebox: The Selective Forwarding Middlebox + (SFM) as defined in Section 3.7 of [RFC7667] has control over the + transmission and configurations between itself and each peer + endpoint individually. It also fully controls the RTCP packets + being forwarded between the individual legs. Thus, this type of + middlebox can be compared to the RTP mixer, which uses its own + SSRCs to mix or select the media it forwards, that will be + classified as a point-to-point RTP session by the above rule. + + In the above cases, it is very reasonable to use RTCP reporting + groups [MULTI-STREAM-OPT]. If that extension is used, an endpoint + can indicate that the multitude of CNAMEs are in fact under a single + endpoint or middlebox control by using only a single reporting group. + + The above rules will also classify some sessions where the endpoint + is connected to an RTP mixer as being point to point. For example, + the mixer could act as gateway to an RTP session based on Any Source + Multicast for the discussed endpoint. However, this will, in most + cases, be okay, as the RTP mixer provides separation between the two + parts of the session. The responsibility falls on the mixer to act + accordingly in each domain. + + Finally, we note that signaling mechanisms could be defined to + override the rules when they would result in the wrong + classification. + +6. Adding and Removing SSRCs + + The set of SSRCs present in a single RTP session can vary over time + due to changes in the number of endpoints in the session or due to + changes in the number or type of RTP streams being sent. + + Every endpoint in an RTP session will have at least one SSRC that it + uses for RTCP reporting, and for sending media if desired. It can + also have additional SSRCs, for sending extra media sources or for + additional RTCP reporting. If the set of media sources being sent + changes, then the set of SSRCs being sent will change. Changes in + the media format or clock rate might also require changes in the set + of SSRCs used. An endpoint can also have more SSRCs than it has + active RTP streams, and send RTCP relating to SSRCs that are not + currently sending RTP data packets so that its peers are aware of the + SSRCs, and have the associated context (e.g., clock synchronization + and an SDES CNAME) in place to be able to play out media as soon as + they becomes active. + + In the following, we describe some considerations around adding and + removing RTP streams and their associated SSRCs. + + + + +Lennox, et al. Standards Track [Page 15] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +6.1. Adding RTP Streams + + When an endpoint joins an RTP session, it can have zero, one, or more + RTP streams it will send, or that it is prepared to send. If it has + no RTP stream it plans to send, it still needs an SSRC that will be + used to send RTCP feedback. If it will send one or more RTP streams, + it will need the corresponding number of SSRC values. The SSRCs used + by an endpoint are made known to other endpoints in the RTP session + by sending RTP and RTCP packets. SSRCs can also be signaled using + non-RTP means (e.g., [RFC5576]). Unless restricted by signaling, an + endpoint can, at any time, send an additional RTP stream, identified + by a new SSRC (this might be associated with a signaling event, but + that is outside the scope of this memo). This makes the new SSRC + visible to the other endpoints in the session, since they share the + single SSRC space inherent in the definition of an RTP session. + + An endpoint that has never sent an RTP stream will have an SSRC that + it uses for RTCP reporting. If that endpoint wants to start sending + an RTP stream, it is RECOMMENDED that it use its existing SSRC for + that stream, since otherwise the participant count in the RTP session + will be unnecessarily increased, leading to a longer RTCP reporting + interval and larger RTCP reports due to cross reporting. If the + endpoint wants to start sending more than one RTP stream, it will + need to generate a new SSRC for the second and any subsequent RTP + streams. + + An endpoint that has previously stopped sending an RTP stream, and + that wants to start sending a new RTP stream, cannot generally reuse + the existing SSRC, and often needs to generate a new SSRC, because an + SSRC cannot change media type (e.g., audio to video) or RTP timestamp + clock rate [RFC7160] and because the SSRC might be associated with a + particular semantic by the application (note: an RTP stream can pause + and restart using the same SSRC, provided RTCP is sent for that SSRC + during the pause; these rules only apply to new RTP streams reusing + an existing SSRC). + +6.2. Removing RTP Streams + + An SSRC is removed from an RTP session in one of two ways. When an + endpoint stops sending RTP and RTCP packets using an SSRC, then that + SSRC will eventually time out as described in Section 6.3.5 of + [RFC3550]. Alternatively, an SSRC can be explicitly removed from use + by sending an RTCP BYE packet as described in Section 6.3.7 of + [RFC3550]. It is RECOMMENDED that SSRCs be removed from use by + sending an RTCP BYE packet. Note that [RFC3550] requires that the + RTCP BYE SHOULD be the last RTP/RTCP packet sent in the RTP session + + + + + +Lennox, et al. Standards Track [Page 16] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + for an SSRC. If an endpoint needs to restart an RTP stream after + sending an RTCP BYE for its SSRC, it needs to generate a new SSRC + value for that stream. + + The finality of sending RTCP BYE means that endpoints need to + consider if the ceasing of transmission of an RTP stream is temporary + or permanent. Temporary suspension of media transmission using a + particular RTP stream (SSRC) needs to maintain that SSRC as an active + participant, by continuing RTCP transmission for it. That way the + media sending can be resumed immediately, knowing that the context is + in place. When permanently halting transmission, a participant needs + to send an RTCP BYE to allow the other participants to use the RTCP + bandwidth resources and clean up their state databases. + + An endpoint that ceases transmission of all its RTP streams but + remains in the RTP session MUST maintain at least one SSRC that is to + be used for RTCP reporting and feedback (i.e., it cannot send a BYE + for all SSRCs, but needs to retain at least one active SSRC). As + some Feedback packets can be bound to media type, there might be a + need to maintain one SSRC per media type within an RTP session. An + alternative can be to create a new SSRC to use for RTCP reporting and + feedback. However, to avoid the perception that an endpoint drops + completely out of an RTP session, such a new SSRC ought to be + established first -- before terminating all the existing SSRCs. + +7. RTCP Considerations for Streams with Disparate Rates + + An RTP session has a single set of parameters that configure the + session bandwidth. These are the RTCP sender and receiver fractions + (e.g., the SDP "b=RR:" and "b=RS:" lines [RFC3556]) and the + parameters of the RTP/AVPF profile [RFC4585] (e.g., trr-int) if that + profile (or its secure extension, RTP/SAVPF [RFC5124]) is used. As a + consequence, the base RTCP reporting interval, before randomization, + will be the same for every sending SSRC in an RTP session. + Similarly, every receiving SSRC in an RTP session will have the same + base reporting interval, although this can differ from the reporting + interval chosen by sending SSRCs. This uniform RTCP reporting + interval for all SSRCs can result in RTCP reports being sent more + often, or too seldom, than is considered desirable for an RTP stream. + + For example, consider a scenario in which an audio flow sending at + tens of kilobits per second is multiplexed into an RTP session with a + multi-megabit high-quality video flow. If the session bandwidth is + configured based on the video sending rate, and the default RTCP + bandwidth fraction of 5% of the session bandwidth is used, it is + likely that the RTCP bandwidth will exceed the audio sending rate. + If the reduced minimum RTCP interval described in Section 6.2 of + [RFC3550] is then used in the session, as appropriate for video where + + + +Lennox, et al. Standards Track [Page 17] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + rapid feedback on damaged I-frames is wanted, the uniform reporting + interval for all senders could mean that audio sources are expected + to send RTCP packets more often than they send audio data packets. + This bandwidth mismatch can be reduced by careful tuning of the RTCP + parameters, especially trr_int when the RTP/AVPF profile is used, but + cannot be avoided entirely as it is inherent in the design of the + RTCP timing rules, and affects all RTP sessions that contain flows + with greatly mismatched bandwidth. + + Different media rates or desired RTCP behaviors can also occur with + SSRCs carrying the same media type. A common case in multiparty + conferencing is when a small number of video streams are shown in + high resolution, while the others are shown as low-resolution + thumbnails, with the choice of which is shown in high resolution + being voice-activity controlled. Here the differences are both in + actual media rate and in choices for what feedback messages might be + needed. Other examples of differences that can exist are due to the + intended usage of a media source. A media source carrying the video + of the speaker in a conference is different from a document camera. + Basic parameters that can differ in this case are frame-rate, + acceptable end-to-end delay, and the Signal-to-Noise Ratio (SNR) + fidelity of the image. These differences affect not only the needed + bitrates, but also possible transmission behaviors, usable repair + mechanisms, what feedback messages the control and repair requires, + the transmission requirements on those feedback messages, and + monitoring of the RTP stream delivery. Other similar scenarios can + also exist. + + Sending multiple media types in a single RTP session causes that + session to contain more SSRCs than if each media type was sent in a + separate RTP session. For example, if two participants each send an + audio and a video RTP stream in a single RTP session, that session + will comprise four SSRCs; but if separate RTP sessions had been used + for audio and video, each of those two RTP sessions would comprise + only two SSRCs. Hence, sending multiple RTP streams in an RTP + session increases the amount of cross reporting between the SSRCs, as + each SSRC reports on all other SSRCs in the session. This increases + the size of the RTCP reports, causing them to be sent less often than + would be the case if separate RTP sessions where used for a given + RTCP bandwidth. + + Finally, when an RTP session contains multiple media types, it is + important to note that the RTCP reception quality reports, feedback + messages, and extended report blocks used might not be applicable to + all media types. Endpoints will need to consider the media type of + each SSRC, and only send or process reports and feedback that apply + to that particular SSRC and its media type. Signaling solutions + + + + +Lennox, et al. Standards Track [Page 18] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + might have shortcomings when it comes to indicating that a particular + set of RTCP reports or feedback messages only apply to a particular + media type within an RTP session. + + From an RTCP perspective, therefore, it can be seen that there are + advantages to using separate RTP sessions for each media source, + rather than sending multiple media sources in a single RTP session. + However, these are frequently offset by the need to reduce port use, + to ease NAT/firewall traversal, achieved by combining media sources + into a single RTP session. The following sections consider some of + the issues with using RTCP in sessions with multiple media sources in + more detail. + +7.1. Timing Out SSRCs + + Various issues have been identified with timing out SSRC values when + sending multiple RTP streams in an RTP session. + +7.1.1. Problems with the RTP/AVPF T_rr_interval Parameter + + The RTP/AVPF profile includes a method to prevent regular RTCP + reports from being sent too often. This mechanism is described in + Section 3.5.3 of [RFC4585]; it is controlled by the T_rr_interval + parameter. It works as follows. When a regular RTCP report is sent, + a new random value, T_rr_current_interval, is generated, drawn evenly + in the range 0.5 to 1.5 times T_rr_interval. If a regular RTCP + packet is to be sent earlier than T_rr_current_interval seconds after + the previous regular RTCP packet, and there are no feedback messages + to be sent, then that regular RTCP packet is suppressed and the next + regular RTCP packet is scheduled. The T_rr_current_interval is + recalculated each time a regular RTCP packet is sent. The benefit of + suppression is that it avoids wasting bandwidth when there is nothing + requiring frequent RTCP transmissions, but still allows utilization + of the configured bandwidth when feedback is needed. + + Unfortunately, this suppression mechanism skews the distribution of + the RTCP sending intervals compared to the regular RTCP reporting + intervals. The standard RTCP timing rules, including reconsideration + and the compensation factor, result in the intervals between sending + RTCP packets having a distribution that is skewed towards the upper + end of the range [0.5/1.21828, 1.5/1.21828]*Td, where Td is the + deterministic calculated RTCP reporting interval. With Td = 5 s, + this distribution covers the range [2.052 s, 6.156 s]. In + comparison, the RTP/AVPF suppression rules act in an interval that is + 0.5 to 1.5 times T_rr_interval; for T_rr_interval = 5s, this is + [2.5 s, 7.5 s]. + + + + + +Lennox, et al. Standards Track [Page 19] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + The effect of this is that the time between consecutive RTCP packets + when using T_rr_interval suppression can become large. The maximum + time interval between sending one regular RTCP packet and the next, + when T_rr_interval is being used, occurs when T_rr_current_interval + takes its maximum value and a regular RTCP packet is suppressed at + the end of the suppression period, then the next regular RTCP packet + is scheduled after its largest possible reporting interval. Taking + the worst case of the two intervals gives a maximum time between two + RTCP reports of 1.5*T_rr_interval + 1.5/1.21828*Td. + + This behavior can be surprising when Td and T_rr_interval have the + same value. That is, when T_rr_interval is configured to match the + regular RTCP reporting interval. In this case, one might expect that + regular RTCP packets are sent according to their usual schedule, but + feedback packets can be sent early. However, the above-mentioned + issue results in the RTCP packets actually being sent in the range + [0.5*Td, 2.731*Td] with a highly non-uniform distribution, rather + than the range [0.41*Td, 1.23*Td]. This is perhaps unexpected, but + is not a problem in itself. However, when coupled with packet loss, + it raises the issue of premature timeout. + +7.1.2. Avoiding Premature Timeout + + In RTP/AVP [RFC3550] the timeout behavior is simple; it is 5 times + Td, where Td is calculated with a Tmin value of 5 seconds. In other + words, if the configured RTCP bandwidth allows for an average RTCP + reporting interval shorter than 5 seconds, the timeout is 25 seconds + of no activity from the SSRC (RTP or RTCP); otherwise, the timeout is + 5 average reporting intervals. + + RTP/AVPF [RFC4585] introduces different timeout behaviors depending + on the value of T_rr_interval. When T_rr_interval is 0, it uses the + same timeout calculation as RTP/AVP. However, when T_rr_interval is + non-zero, it replaces Tmin in the timeout calculation, most likely to + speed up detection of timed out SSRCs. However, using a non-zero + T_rr_interval has two consequences for RTP behavior. + + First, due to suppression, the number of RTP and RTCP packets sent by + an SSRC that is not an active RTP sender can become very low, because + of the issue discussed in Section 7.1.1. As the RTCP packet interval + can be as long as 2.73*Td, during a 5*Td time period, an endpoint + might in fact transmit only a single RTCP packet. The long intervals + result in fewer RTCP packets, to a point where a single RTCP packet + loss can sometimes result in timing out an SSRC. + + Second, the RTP/AVPF changes to the timeout rules reduce robustness + to misconfiguration. It is common to use RTP/AVPF configured such + that RTCP packets can be sent frequently to allow rapid feedback; + + + +Lennox, et al. Standards Track [Page 20] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + however, this makes timeouts very sensitive to T_rr_interval. For + example, if two SSRCs are configured, one with T_rr_interval = 0.1 s + and the other with T_rr_interval = 0.6 s, then this small difference + will result in the SSRC with the shorter T_rr_interval timing out the + other if it stops sending RTP packets, since the other RTCP reporting + interval is more than five times its own. When RTP/AVP is used, or + RTP/AVPF with T_rr_interval = 0, this is a non-issue, as the timeout + period will be 25 s, and differences between configured RTCP + bandwidth can only cause premature timeouts when the reporting + intervals are greater than 5 s and differ by a factor of five. To + limit the scope for such problematic misconfiguration, we define an + update to the RTP/AVPF timeout rules in Section 7.1.4. + +7.1.3. Interoperability between RTP/AVP and RTP/AVPF + + If endpoints implementing the RTP/AVP and RTP/AVPF profiles (or their + secure variants) are combined within a single RTP session, and the + RTP/AVPF endpoints use a non-zero T_rr_interval that is significantly + below 5 seconds, there is a risk that the RTP/AVPF endpoints will + prematurely time out the SSRCs of the RTP/AVP endpoints, due to their + different RTCP timeout rules. Conversely, if the RTP/AVPF endpoints + use a T_rr_interval that is significantly larger than 5 seconds, + there is a risk that the RTP/AVP endpoints will time out the SSRCs of + the RTP/AVPF endpoints. + + Mixing endpoints using two different RTP profiles within a single RTP + session is NOT RECOMMENDED. However, if mixed RTP profiles are used, + and the RTP/AVPF endpoints are not updated to follow Section 7.1.4 of + this memo, then the RTP/AVPF session SHOULD be configured to use + T_rr_interval = 4 seconds to avoid premature timeouts. + + The choice of T_rr_interval = 4 seconds for interoperability might + appear strange. Intuitively, this value ought to be 5 seconds, to + make both the RTP/AVP and RTP/AVPF use the same timeout period. + However, the behavior outlined in Section 7.1.1 shows that actual + RTP/AVPF reporting intervals can be longer than expected. Setting + T_rr_interval = 4 seconds gives actual RTCP intervals near to those + expected by RTP/AVP, ensuring interoperability. + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 21] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +7.1.4. Updated SSRC Timeout Rules + + To ensure interoperability and avoid premature timeouts, all SSRCs in + an RTP session MUST use the same timeout behavior. However, previous + specifications are inconsistent in this regard. To avoid + interoperability issues, this memo updates the timeout rules as + follows: + + o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, the + timeout interval SHALL be calculated using a multiplier of five + times the deterministic RTCP reporting interval. That is, the + timeout interval SHALL be 5*Td. + + o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, + calculation of Td, for the purpose of calculating the participant + timeout only, SHALL be done using a Tmin value of 5 seconds and + not the reduced minimal interval, even if the reduced minimum + interval is used to calculate RTCP packet transmission intervals. + + This changes the behavior for the RTP/AVPF or RTP/SAVPF profiles when + T_rr_interval != 0. Specifically, the first paragraph of + Section 3.5.4 of [RFC4585] is updated to use Tmin instead of + T_rr_interval in the timeout calculation for RTP/AVPF entities. + +7.2. Tuning RTCP Transmissions + + This subsection discusses what tuning can be done to reduce the + downsides of the shared RTCP packet intervals. First, what + possibilities exist for the RTP/AVP [RFC3551] profile are listed + followed by what additional tools are provided by RTP/AVPF [RFC4585]. + +7.2.1. RTP/AVP and RTP/SAVP + + When using the RTP/AVP or RTP/SAVP profiles, the options for tuning + the RTCP reporting intervals are limited to the RTCP sender and + receiver bandwidth, and whether the minimum RTCP interval is scaled + according to the bandwidth. As the scheduling algorithm includes + both randomization and reconsideration, one cannot simply calculate + the expected average transmission interval using the formula for Td + given in Section 6.3.1 of [RFC3550]. However, by considering the + inputs to that expression, and the randomization and reconsideration + rules, we can begin to understand the behavior of the RTCP + transmission interval. + + + + + + + + +Lennox, et al. Standards Track [Page 22] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + Let's start with some basic observations: + + a. Unless the scaled minimum RTCP interval is used, Td prior to + randomization and reconsideration can never be less than Tmin. + The default value of Tmin is 5 seconds. + + b. If the scaled minimum RTCP interval is used, Td can become as low + as 360 divided by RTP Session bandwidth in kilobits per second. + In SDP, the RTP session bandwidth is signaled using a "b=AS" + line. An RTP Session bandwidth of 72 kbps results in Tmin being + 5 seconds. An RTP session bandwidth of 360 kbps of course gives + a Tmin of 1 second, and to achieve a Tmin equal to once every + frame for a 25 frame-per-second video stream requires an RTP + session bandwidth of 9 Mbps. Use of the RTP/AVPF or RTP/SAVPF + profile allows more frequent RTCP reports for the same bandwidth, + as discussed below. + + c. The value of Td scales with the number of SSRCs and the average + size of the RTCP reports to keep the overall RTCP bandwidth + constant. + + d. The actual transmission interval for a Td value is in the range + [0.5*Td/1.21828, 1.5*Td/1.21828], and the distribution is skewed, + due to reconsideration, with the majority of the probability mass + being above Td. This means, for example, that for Td = 5 s, the + actual transmission interval will be distributed in the range + [2.052 s, 6.156 s], and tending towards the upper half of the + interval. Note that Tmin parameter limits the value of Td before + randomization and reconsideration are applied, so the actual + transmission interval will cover a range extending below Tmin. + + Given the above, we can calculate the number of SSRCs, n, that an RTP + session with 5% of the session bandwidth assigned to RTCP can support + while maintaining Td equal to Tmin. This will tell us how many RTP + streams we can report on, keeping the RTCP overhead within acceptable + bounds. We make two assumptions that simplify the calculation: that + all SSRCs are senders, and that they all send compound RTCP packets + comprising an SR packet with n-1 report blocks, followed by an SDES + packet containing a 16 octet CNAME value [RFC7022] (such RTCP packets + will vary in size between 54 and 798 octets depending on n, up to the + maximum of 31 report blocks that can be included in an SR packet). + If we put this packet size, and a 5% RTCP bandwidth fraction into the + RTCP interval calculation in Section 6.3.1 of [RFC3550], and + calculate the value of n needed to give Td = Tmin for the scaled + minimum interval, we find n=9 SSRCs can be supported (irrespective of + the interval, due to the way the reporting interval scales with the + session bandwidth). We see that to support more SSRCs without + changing the scaled minimum interval, we need to increase the RTCP + + + +Lennox, et al. Standards Track [Page 23] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + bandwidth fraction from 5%; changing the session bandwidth to a + higher value would reduce the Tmin. However, if using the default 5% + allocation of RTCP bandwidth, an increase will result in more SSRCs + being supported given a fixed Td target. + + Based on the above, when using the RTP/AVP profile or the RTP/SAVP + profile, the key limitation for rapid RTCP reporting in small unicast + sessions is going to be the Tmin value. The RTP session bandwidth + configured in RTCP has to be sufficiently high to reach the reporting + goals the application has following the rules for the scaled minimal + RTCP interval. + +7.2.2. RTP/AVPF and RTP/SAVPF + + When using RTP/AVPF or RTP/SAVPF, we have a powerful additional tool + for tuning RTCP transmissions: the T_rr_interval parameter. Use of + this parameter allows short RTCP reporting intervals; alternatively + it gives the ability to sent frequent RTCP feedback without sending + frequent regular RTCP reports. + + The use of the RTP/AVPF or RTP/SAVPF profile with T_rr_interval set + to a value greater than zero but smaller than Tmin allows more + frequent RTCP feedback than the RTP/AVP or RTP/SAVP profiles, for a + given RTCP bandwidth. This happens because Tmin is set to zero after + the transmission of the initial RTCP report, causing the reporting + interval for later packet to be determined by the usual RTCP + bandwidth-based calculation, with Tmin=0, and the T_rr_interval. + This has the effect that we are no longer restricted by the minimal + interval (whether the default 5-second minimum or the reduced minimum + interval). Rather, the RTCP bandwidth and the T_rr_interval are the + governing factors, allowing faster feedback. Applications that care + about rapid regular RTCP feedback ought to consider using the RTP/ + AVPF or RTP/SAVPF profile, even if they don't use the feedback + features of that profile. + + The use of the RTP/AVPF or RTP/SAVPF profile allows RTCP feedback + packets to be sent frequently, without also requiring regular RTCP + reports to be sent frequently, since T_rr_interval limits the rate at + which regular RTCP packets can be sent, while still permitting RTCP + feedback packets to be sent. Applications that can use feedback + packets for some RTP streams, e.g., video streams, but don't want + frequent regular reporting for other RTP streams, can configure the + T_rr_interval to a value so that the regular reporting for both audio + and video is at a level that is considered acceptable for the audio. + They could then use feedback packets, which will include RTCP SR/RR + packets unless reduced size RTCP feedback packets [RFC5506] are used, + + + + + +Lennox, et al. Standards Track [Page 24] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + for the video reporting. This allows the available RTCP bandwidth to + be devoted on the feedback that provides the most utility for the + application. + + Using T_rr_interval still requires one to determine suitable values + for the RTCP bandwidth value. Indeed, it might make this choice even + more important, as this is more likely to affect the RTCP behavior + and performance than when using the RTP/AVP or RTP/SAVP profile, as + there are fewer limitations affecting the RTCP transmission. + + When T_rr_interval is non-zero, there are configurations that need to + be avoided. If the RTCP bandwidth chosen is such that the Td value + is smaller than, but close to, T_rr_interval, then the actual regular + RTCP packet transmission interval can become very large, as discussed + in Section 7.1.1. Therefore, for configuration where one intends to + have Td smaller than T_rr_interval, then Td is RECOMMENDED to be + targeted at values less than 1/4th of T_rr_interval, which results in + the range becoming [0.5*T_rr_interval, 1.81*T_rr_interval]. + + With the RTP/AVPF or RTP/SAVPF profiles, using T_rr_interval = 0 has + utility and results in a behavior where the RTCP transmission is only + limited by the bandwidth, i.e., no Tmin limitations at all. This + allows more frequent regular RTCP reporting than can be achieved + using the RTP/AVP profile. Many configurations of RTCP will not + consume all the bandwidth that they have been configured to use, but + this configuration will consume what it has been given. Note that + the same behavior will be achieved as long as T_rr_interval is + smaller than 1/3 of Td as that prevents T_rr_interval from affecting + the transmission. + + There exists no method for using different regular RTCP reporting + intervals depending on the media type or individual RTP stream, other + than using a separate RTP session for each type or stream. + +8. Security Considerations + + When using the secure RTP protocol (RTP/SAVP) [RFC3711], or the + secure variant of the feedback profile (RTP/SAVPF) [RFC5124], the + cryptographic context of a compound secure RTCP packet is the SSRC of + the sender of the first RTCP (sub-)packet. This could matter in some + cases, especially for keying mechanisms such as MIKEY [RFC3830] that + allow use of per-SSRC keying. + + Otherwise, the standard security considerations of RTP apply; sending + multiple RTP streams from a single endpoint in a single RTP session + does not appear to have different security consequences than sending + the same number of RTP streams spread across different RTP sessions. + + + + +Lennox, et al. Standards Track [Page 25] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, . + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, DOI 10.17487/RFC3711, March 2004, + . + + [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, + "Extended RTP Profile for Real-time Transport Control + Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, + DOI 10.17487/RFC4585, July 2006, + . + + [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for + Real-time Transport Control Protocol (RTCP)-Based Feedback + (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February + 2008, . + + [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size + Real-Time Transport Control Protocol (RTCP): Opportunities + and Consequences", RFC 5506, DOI 10.17487/RFC5506, April + 2009, . + +9.2. Informative References + + [CLUE-FRAME] + Duckworth, M., Ed., Pepperell, A., and S. Wenger, + "Framework for Telepresence Multi-Streams", Work in + Progress, draft-ietf-clue-framework-25, January 2016. + + [MULTI-RTP] + Westerlund, M., Perkins, C., and J. Lennox, "Sending + Multiple Types of Media in a Single RTP Session", Work in + Progress, draft-ietf-avtcore-multi-media-rtp-session-13, + December 2015. + + + + +Lennox, et al. Standards Track [Page 26] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + [MULTI-STREAM-OPT] + Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, + "Sending Multiple Media Streams in a Single RTP Session: + Grouping RTCP Reception Statistics and Other Feedback", + Work in Progress, draft-ietf-avtcore-rtp-multi- + stream-optimisation-12, March 2016. + + [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's + Initial Window", RFC 3390, DOI 10.17487/RFC3390, October + 2002, . + + [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and + Video Conferences with Minimal Control", STD 65, RFC 3551, + DOI 10.17487/RFC3551, July 2003, + . + + [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth + Modifiers for RTP Control Protocol (RTCP) Bandwidth", + RFC 3556, DOI 10.17487/RFC3556, July 2003, + . + + [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. + Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, + DOI 10.17487/RFC3830, August 2004, + . + + [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. + Hakenberg, "RTP Retransmission Payload Format", RFC 4588, + DOI 10.17487/RFC4588, July 2006, + . + + [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, + "Codec Control Messages in the RTP Audio-Visual Profile + with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, + February 2008, . + + [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific + Media Attributes in the Session Description Protocol + (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, + . + + [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, + "RTP Payload Format for Scalable Video Coding", RFC 6190, + DOI 10.17487/RFC6190, May 2011, + . + + + + + + +Lennox, et al. Standards Track [Page 27] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + + [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, + "Increasing TCP's Initial Window", RFC 6928, + DOI 10.17487/RFC6928, April 2013, + . + + [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, + "Guidelines for Choosing RTP Control Protocol (RTCP) + Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, + September 2013, . + + [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple + Clock Rates in an RTP Session", RFC 7160, + DOI 10.17487/RFC7160, April 2014, + . + + [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, + DOI 10.17487/RFC7667, November 2015, + . + + [SDP-BUNDLE] + Holmberg, C., Alvestrand, H., and C. Jennings, + "Negotiating Media Multiplexing Using the Session + Description Protocol (SDP)", Work in Progress, + draft-ietf-mmusic-sdp-bundle-negotiation-36, October 2016. + + [Sim88] Westerlund, M., "SIMULATION RESULTS FOR MULTI-STREAM", + IETF 88 Proceedings, November 2013, + . + + [Sim92] Westerlund, M., Lennox, J., Perkins, C., and Q. Wu, + "Changes in RTP Multi-stream", IETF 92 Proceedings, March + 2015, . + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 28] + +RFC 8108 Multiple Media Streams in an RTP Session March 2017 + + +Acknowledgments + + The authors like to thank Harald Alvestrand and everyone else who has + been involved in the development of this document. + +Authors' Addresses + + Jonathan Lennox + Vidyo, Inc. + 433 Hackensack Avenue + Seventh Floor + Hackensack, NJ 07601 + United States of America + + Email: jonathan@vidyo.com + + + Magnus Westerlund + Ericsson + Farogatan 2 + SE-164 80 Kista + Sweden + + Phone: +46 10 714 82 87 + Email: magnus.westerlund@ericsson.com + + + Qin Wu + Huawei + 101 Software Avenue, Yuhua District + Nanjing, Jiangsu 210012 + China + + Email: bill.wu@huawei.com + + + Colin Perkins + University of Glasgow + School of Computing Science + Glasgow G12 8QQ + United Kingdom + + Email: csp@csperkins.org + + + + + + + + +Lennox, et al. Standards Track [Page 29] + -- cgit v1.2.3