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.

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

   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

   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

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

   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;

   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.

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.

   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

   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,

   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.

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.

   [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>.

   [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>.

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