doc: Add RFC documents

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]
+