summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8108.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8108.txt')
-rw-r--r--doc/rfc/rfc8108.txt1627
1 files changed, 1627 insertions, 0 deletions
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,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [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, <http://www.rfc-editor.org/info/rfc3550>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc3711>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc4585>.
+
+ [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, <http://www.rfc-editor.org/info/rfc5124>.
+
+ [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, <http://www.rfc-editor.org/info/rfc5506>.
+
+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, <http://www.rfc-editor.org/info/rfc3390>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc3551>.
+
+ [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
+ Modifiers for RTP Control Protocol (RTCP) Bandwidth",
+ RFC 3556, DOI 10.17487/RFC3556, July 2003,
+ <http://www.rfc-editor.org/info/rfc3556>.
+
+ [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
+ Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
+ DOI 10.17487/RFC3830, August 2004,
+ <http://www.rfc-editor.org/info/rfc3830>.
+
+ [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
+ Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
+ DOI 10.17487/RFC4588, July 2006,
+ <http://www.rfc-editor.org/info/rfc4588>.
+
+ [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, <http://www.rfc-editor.org/info/rfc5104>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc5576>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc6190>.
+
+
+
+
+
+
+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,
+ <http://www.rfc-editor.org/info/rfc6928>.
+
+ [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, <http://www.rfc-editor.org/info/rfc7022>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc7160>.
+
+ [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
+ DOI 10.17487/RFC7667, November 2015,
+ <http://www.rfc-editor.org/info/rfc7667>.
+
+ [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,
+ <https://www.ietf.org/proceedings/88/slides/
+ slides-88-avtcore-0.pdf>.
+
+ [Sim92] Westerlund, M., Lennox, J., Perkins, C., and Q. Wu,
+ "Changes in RTP Multi-stream", IETF 92 Proceedings, March
+ 2015, <https://www.ietf.org/proceedings/92/slides/
+ slides-92-avtcore-0.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+