AVTCORE                                                        J. Lennox
Internet-Draft                                                     Vidyo
Updates: 3550 (if approved)                                M. Westerlund
Intended status: Standards Track                                Ericsson
Expires: October 24, 2013 January 12, 2014                                          Q. Wu
                                                              C. Perkins
                                                   University of Glasgow
                                                          April 22,
                                                           July 11, 2013

    RTP Considerations for Endpoints

         Sending Multiple Media Streams
                 draft-ietf-avtcore-rtp-multi-stream-00 in a Single RTP Session


   This document expands and clarifies the behavior of the Real-Time
   Transport Protocol (RTP) endpoints when they are sending multiple
   media streams in a single RTP session.  In particular, issues
   involving Real-Time Transport Control Protocol (RTCP) messages are

   This document updates RFC 3550 in regards to handling of multiple
   SSRCs per endpoint in RTP sessions.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 24, 2013. January 12, 2014.

Copyright Notice

   Copyright (c) 2013 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases For Multi-Stream Endpoints  . . . . . . . . . . . .   3
     3.1.  Multiple-Capturer Endpoints . . . . . . . . . . . . . . .   3
     3.2.  Multi-Media Sessions  . . . . . . . . . . . . . . . . . .   4   3
     3.3.  Multi-Stream Mixers . . . . . . . . . . . . . . . . . . .   4
   4.  Issue Cases . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Cascaded Multi-party Conference with Source Projecting
           Mixers  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Multi-Stream Endpoint RTP Media Recommendations . . . . . . .   5
   6.   4
   5.  Multi-Stream Endpoint RTCP Recommendations  . . . . . . . . .   5
     6.1.   4
     5.1.  RTCP Reporting Requirement  . . . . . . . . . . . . . . .   6
     6.2.   5
     5.2.  Initial Reporting Interval  . . . . . . . . . . . . . . .   6
     6.3.   5
     5.3.  Compound RTCP Packets . . . . . . . . . . . . . . . . . .   6
   7.   5
   6.  RTCP Bandwidth Considerations for Sources Streams with Disparate Rates  . . . .   7
     6.1.  Timing out SSRCs  . . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Grouping of RTCP Reception Statistics and Other Feedback  . .   7
     8.1.  Semantics and Behavior of Reporting Groups  . . . . . . .   8
     8.2.  Determine the Report Group  . . . .
     6.2.  Tuning RTCP transmissions . . . . . . . . . . .   9
     8.3.  RTCP Packet Reporting Group's Reporting Sources . . . . .   9
     8.4.  RTCP Source Description (SDES) item for Reporting Groups   11
     8.5.  Middlebox
   7.  Security Considerations . . . . . . . . . . . . . . . .  11
     8.6.  SDP signaling for Reporting Groups . . .  11
   8.  Open Issues . . . . . . . .  11
     8.7.  Bandwidth Benefits of RTCP Reporting Groups . . . . . . .  11
     8.8.  Consequences of RTCP Reporting Groups . . . . . . . . . .  12
   9.  Security  IANA Considerations . . . . . . . . . . . . . . . . . . .  13
   10. Open Issues . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . .  13
   11. IANA Considerations . . . . . . .  12
     10.1.  Normative References . . . . . . . . . . . . . .  13
     11.1.  RTCP SDES Item . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
     11.2.  RTCP Packet Type
   Appendix A.  Changes From Earlier Versions  . . . . . . . . . . .  14
     A.1.  Changes From WG Draft -00 . . . . . . . . .  14
   12. References . . . . . . .  14
     A.2.  Changes From Individual Draft -02 . . . . . . . . . . . .  14
     A.3.  Changes From Individual Draft -01 . . . . . .  14
     12.1.  Normative References . . . . . .  14
     A.4.  Changes From Individual Draft -00 . . . . . . . . . . . .  14
     12.2.  Informative References . . . . .
   Authors' Addresses  . . . . . . . . . . . .  14
   Appendix A.  Changes From Earlier Versions . . . . . . . . . . .  15
     A.1.  Changes From Individual Draft -02 . . . . . . . . . . . .  15
     A.2.  Changes From Draft -01  . . . . . . . . . . . . . . . . .  15
     A.3.  Changes From Draft -00  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   At the time The Real-Time Transport Protocol (RTP) [RFC3550] was
   originally written, and for quite some time after, endpoints in RTP
   sessions typically only transmitted a single media stream per RTP
   session, where separate RTP sessions were typically used for each
   distinct media type.

   Recently, however, a number of scenarios have emerged (discussed
   further in Section 3) in which endpoints wish to send multiple RTP
   media streams, distinguished by distinct RTP synchronization source
   (SSRC) identifiers, in a single RTP session.  Although RTP's initial
   design did consider such scenarios, the specification was not
   consistently written with such use cases in mind.  The specifications
   are thus somewhat unclear.

   The purpose of this document is to expand and clarify [RFC3550]'s
   language for these use cases.  The authors believe this does not
   result in any major normative changes to the RTP specification,
   however this document defines how the RTP specification is to be
   interpreted.  In these cases, this document updates RFC3550.

   The document starts with terminology and some use cases where
   multiple sources will occur.  This is followed by some case studies
   to try to identify issues that exist and need considerations.  This
   is followed by RTP and RTCP recommendations to resolve issues.  Next
   are security considerations and remaining open issues.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119] and indicate requirement levels for compliant

3.  Use Cases For Multi-Stream Endpoints

   This section discusses several use cases that have motivated the
   development of endpoints that send multiple streams in a single RTP

3.1.  Multiple-Capturer Endpoints

   The most straightforward motivation for an endpoint to send multiple
   media streams in a session is the scenario where an endpoint has
   multiple capture devices of the same media type and characteristics.
   For example, telepresence endpoints, of the type described by the
   CLUE Telepresence Framework [I-D.ietf-clue-framework] is designed,
   often have multiple cameras or microphones covering various areas of
   a room.

3.2.  Multi-Media Sessions

   Recent work has been done in RTP
   [I-D.ietf-avtcore-multi-media-rtp-session] and SDP

   [I-D.ietf-mmusic-sdp-bundle-negotiation] to update RTP's historical
   assumption that media streams of different media types would always
   be sent on different RTP sessions.  In this work, a single endpoint's
   audio and video media streams (for example) are instead sent in a
   single RTP session.

3.3.  Multi-Stream Mixers

   There are several RTP topologies which can involve a central device
   that itself generates multiple media streams in a session.

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

   More complicated is the Source Projecting Mixer, see Section 3.6 of
   [I-D.ietf-avtcore-rtp-topologies-update].  This is a central box that
   receives media streams from several endpoints, and then selectively
   forwards modified versions of some of the streams toward the other
   endpoints it is connected to.  Toward one destination, a separate
   media source appears in the session for every other source connected
   to the mixer, "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, in that it terminates RTCP reporting
   about the mixed streams, and it can re-write SSRCs, timestamps, and
   sequence numbers, as well as the contents of the RTP payloads, and
   can turn sources on and off at will without appearing to be
   generating packet loss.  Each projected stream will typically
   preserve its original RTCP source description (SDES) information.

4.  Issue Cases

   This section illustrates some scenarios that have shown areas where
   the RTP specification is unclear.

4.1.  Cascaded Multi-party Conference with Source Projecting Mixers

   This issue case tries to illustrate the effect of having multiple
   SSRCs sent by an endpoint, by considering the traffic between two
   source-projecting mixers in a large multi-party conference.

   For concreteness, consider a 200-person conference, where 16 sources
   are viewed at any given time.  Assuming participants are distributed
   evenly among the mixers, each mixer would have 100 sources "behind"
   (projected through) it, of which at any given time eight are active
   senders.  Thus, the RTP session between the mixers consists of two
   endpoints, but 200 sources.

   The RTCP bandwidth implications of this scenario are discussed
   further in Section 8.7.

   (TBD: Other examples?  Can this section be removed?)

5.  Multi-Stream Endpoint RTP Media Recommendations

   While an endpoint MUST (of course) stay within its share of the
   available session bandwidth, as determined by signalling and
   congestion control, this need not be applied independently or
   uniformly to each media stream.  In particular, session bandwidth MAY
   be reallocated among an endpoint's media streams, for example by
   varying the bandwidth use of a variable-rate codec, or changing the
   codec used by the media stream, up to the constraints of the
   session's negotiated (or declared) codecs.  This includes enabling or
   disabling media streams as more or less bandwidth becomes available.


5.  Multi-Stream Endpoint RTCP Recommendations
   This section contains a number of different RTCP clarifications or
   recommendations that enables more efficient and simpler behavior
   without loss of functionality.

   The RTP Control Protocol (RTCP) is defined in Section 6 of [RFC3550],
   but it is largely documented in terms of "participants".  In many
   cases, the specification's recommendations for "participants" are to
   be interpreted as applying to individual media streams, rather than
   to endpoints.  This section describes several concrete cases where
   this applies.

   (tbd: rather than think in terms of media streams, it might be
   clearer to refer to SSRC values, where a participant with multiple
   active SSRC values counts as multiple participants, once per SSRC)


5.1.  RTCP Reporting Requirement

   For each of an endpoint's media streams, whether or not it is
   currently sending media, SR/RR and SDES packets MUST be sent at least
   once per RTCP report interval.  (For discussion of the content of SR
   or RR packets' reception statistic reports, see Section 8.)


5.2.  Initial Reporting Interval

   When a new media stream is added to a unicast session, the sentence
   in [RFC3550]'s Section 6.2 applies: "For unicast sessions ... the
   delay before sending the initial compound RTCP packet MAY be zero."
   This applies to individual media sources as well.  Thus, endpoints
   MAY send an initial RTCP packet for an SSRC immediately upon adding
   it to a unicast session.

   This allowance also applies, as written, when initially joining a
   unicast session.  However, in this case some caution needs to be
   exercised if the end-point or mixer has a large number of sources
   (SSRCs) as this can create a significant burst.  How big an issue
   this depends on the number of source to send initial SR or RR and
   Session Description CNAME items for in relation to the RTCP

   (tbd: Maybe some recommendation here?  The aim in restricting this to
   unicast sessions was to avoid this burst of traffic, which the usual
   RTCP timing and reconsideration rules will prevent)


5.3.  Compound RTCP Packets

   Section 6.1 gives the following advice to RTP translators and mixers:

      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.

   Note: To avoid confusion, an RTCP packet is an individual item, such
   as a Sender Report (SR), Receiver Report (RR), Source Description
   (SDES), Goodbye (BYE), Application Defined (APP), Feedback [RFC4585]
   or Extended Report (XR) [RFC3611] packet.  A compound packet is the
   combination of two or more such RTCP packets where the first packet
   has to be an SR or an RR packet, and which contains a SDES packet
   containing an CNAME item.  Thus the above results in compound RTCP
   packets that contain multiple SR or RR packets from different sources
   as well as any of the other packet types.  There are no restrictions
   on the order in which the packets can occur within the compound
   packet, except the regular compound rule, i.e., starting with an SR
   or RR.

   This advice applies to multi-media-stream endpoints as well, with the
   same restrictions and considerations.  (Note, however, that the last
   sentence does not apply to AVPF [RFC4585] or SAVPF [RFC5124] feedback
   packets if Reduced-Size RTCP [RFC5506] is in use.)

   Due to RTCP's randomization of reporting times, there is a fair bit
   of tolerance in precisely when an endpoint schedules RTCP to be sent.
   Thus, one potential way of implementing this recommendation would be
   to randomize all of an endpoint's sources together, with a single
   randomization schedule, so an MTU's worth of RTCP all comes out

   (tbd: Multiplexing RTCP packets from multiple different sources might
   require some adjustment to the calculation of RTCP's avg_rtcp_size,
   as the RTCP group interval is proportional to avg_rtcp_size times the
   group size).


6.  RTCP Bandwidth Considerations for Sources Streams with Disparate Rates

   It is possible for an a single RTP session to carry sources streams of greatly
   differing bandwidths.  One example bandwidth.  There are two scenarios where this can occur.
   The first is when a single RTP session carries multiple flows of the scenario
   same media type, but with very different quality; for example a video
   switching multi-point conference unit might send a full rate high-
   definition video stream of
   [I-D.ietf-avtcore-multi-media-rtp-session], the active speaker but only thumbnails for
   the other participants, all sent in a single RTP session.  The second
   scenarios occurs when audio and video flows are sent in the same session.  However, this can occur even within a single media type, for example RTP
   session, as discussed in [I-D.ietf-avtcore-multi-media-rtp-session].

   An RTP session has a video single set of parameters that configure the
   session carrying both 5 fps
   QCIF bandwidth, the RTCP sender and 60 fps 1080p HD video, or an audio session carrying both
   G.729 receiver fractions (e.g., via
   the SDP "b=RR:" and L24/48000/6 audio.

   (tbd: recommend how "b=RS:" lines), 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 RTCP bandwidths are to be chosen in these
   scenarios.  Likely, these recommendations
   reporting interval will be different for
   sessions using AVPF-based profiles (where the trr-int parameter is
   available) than same for those using AVP.)

8.  Grouping of RTCP Reception Statistics and Other Feedback

   As specified by [RFC3550], every SSRC in an endpoint MUST send reception RTP session.
   This uniform RTCP reporting interval can result in RTCP reports
   about every active media stream it being
   sent more often than is receiving, from at least one
   local source.

   However, considered desirable for a naive application of the RTP specification's rules could
   be quite inefficient.  In particular, particular media
   type.  For example, if an audio flow is multiplexed with a session has N SSRCs
   (active and inactive, i.e., participant SSRCs), and high
   quality video flow where the session has S
   active senders in each reporting interval, there will either be N*S
   report blocks per reporting interval, or (per bandwidth is configured to match
   the round-robin
   recommendations of [RFC3550] Section 6.1) reception sources would be
   unnecessarily round-robinned.  In a session where most media sources
   become senders reasonably frequently, video bandwidth, this results in quadratically
   many reception report blocks can result in the conference, or reporting delays
   proportional to RTCP packets having a
   greater bandwidth allocation than the number audio data rate.  If the
   reduced minimum RTCP interval described in Section 6.2 of session members.

   Since traffic is received by endpoints, however, rather than by media
   sources, there [RFC3550]
   is not actually any need used in the session, which might be appropriate for this quadratic expansion.
   All that is needed video where
   rapid feedback is for each endpoint to report all wanted, the remote audio sources it is receiving.

   Thus, this document defines a new RTCP mechanism, Reporting Groups, could be expected to indicate sources which originate from the same endpoint, and which
   therefore would have identical recption reports.

8.1.  Semantics and Behavior of Reporting Groups

   An send
   RTCP Reporting Group indicates that a set of sources (SSRCs) that
   originate from a single entity (endpoint or middlebox) in an RTP
   session, packets more often than they send audio data packets.  This is
   most likely undesirable, and therefore all the sources in while the group's view mismatch can be reduced
   through careful tuning of the
   network RTCP parameters, particularly trr_int
   in RTP/AVPF sessions, it is identical.  If reporting groups are inherent in use, two sources
   SHOULD be put into the same reporting group if their view design of the
   network is identical; i.e., if they report on traffic received at the
   same interface of an RTCP timing
   rules, and affects all RTP endpoint.  Sources sessions containing flows with different views of
   the network MUST NOT be put into the same reporting group.

   If reporting groups are mismatched

   Having multiple media types in use, an endpoint MUST NOT send reception
   reports from one source RTP session also results in a reporting group about another one more
   SSRCs being present in this RTP session.  This increasing the
   same group ("self-reports").  Similarly, amount
   of cross reporting between the SSRCs.  From an endpoint MUST NOT send
   reception reports about a remote media source from more than one
   source RTCP perspective, two
   RTP sessions with half the number of SSRCs in a reporting group ("cross-reports").  Instead, it MUST pick
   one each will be slightly
   more efficient.  If someone needs either the higher efficiency due to
   the lesser number of its local media sources as SSRCs or the "reporting" source for each
   remote fact that one can't tailor RTCP
   usage per media source, and type, they need to use independent RTP sessions.

   When it comes to send reception reports about that
   remote source; all the other media sources in configuring RTCP the need for regular periodic
   reporting group
   MUST NOT send any reception reports about that remote media source.

   This reporting source MUST also needs to be the source for weighted against any feedback or control
   messages being sent.  Applications using RTP/AVPF
   Feedback [RFC4585] or Extended Report (XR) [RFC3611] packets about
   the corresponding remote sources as well.  If a reporting source
   leaves RTP/SAVPF are
   RECOMMENDED to consider setting the session (i.e., if it sends trr-int parameter to a BYE, or leaves value
   suitable for the group
   without sending BYE under application's needs, thus potentially reducing the rules of [RFC3550] section 6.3.7),
   need for regular reporting source MUST be chosen if any members of the group
   still exist.

   An endpoint or middlebox MAY and thus releasing more bandwidth for use multiple sources as reporting
   sources; however, each reporting source MUST have non-overlapping
   sets of remote SSRCs it reports on.  This is primarily to be done
   when the reporting source's number
   for feedback or control.

   Another aspect of reception report blocks an RTP session with multiple media types is so
   large that it would
   the RTCP packets, RTCP Feedback Messages, or RTCP XR metrics used
   might not be forced applicable to all media types.  Instead, all RTP/RTCP
   endpoints need to round robin around correlate the sources.
   Thus, by splitting media type of the reports among several reporting SSRCs more
   consistent reporting can be achieved.

   If RTP/AVPF feedback is SSRC being
   referenced in use, a reporting source MAY send immediate message or early feedback at any point when any member of the reporting group
   could validly do so.

   An endpoint SHOULD NOT create single-source reporting groups, unless
   it is anticipated packet and only use those that the group apply to
   that particular SSRC and its media type.  Signalling solutions might
   have additional sources added
   to 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.

6.1.  Timing out SSRCs

   All SSRCs used in an RTP session MUST use the future.

8.2.  Determine same timeout behaviour
   to avoid premature timeouts.  This will depend on the Report Group

   A remote RTP entity, such as an endpoint or a middlebox needs to be
   able to determine profile and
   its configuration.  The RTP specification provides several options
   that can influence the report group values used by another RTP entity. when calculating the time
   interval.  To
   achieve avoid interoperability issues when using this goal two RTCP extensions has been defined.
   specification, this document makes several clarifications to the

   For RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF with T_rr_interval =
   0, the
   SSRCs that are reporting on behalf timeout interval SHALL be calculated using a multiplier of 5,
   i.e.  the reporting group an SDES
   item RGRP has been defined for providing the report group with an
   identifier.  For SSRCs that aren't reporting on any peer SSRC timeout interval becomes 5*Td.  The Td calculation SHALL be
   done using a new
   RTCP packet type is defined.  This Tmin value of 5 seconds, not the reduced minimal
   interval even if used to calculate RTCP packet type "Reporting
   Sources", lists transmission
   intervals.  If using either the SSRC that are reporting on this SSRC's behalf.

   This divided approach has been selected for RTP/AVPF or RTP/SAVPF profiles with
   T_rr_interval != 0 then the following reasons:

   1.  Enable an explicit indication calculation as specified in Section 3.5.4
   of who reports on this SSRC's
       behalf.  Being explicit prevents RFC 4585 SHALL be used with a multiplier of 5, i.e.  Tmin in the remote entity from detecting
   Td calculation is missing the reports if there issues with T_rr_interval.

   Note: If endpoints implementing the reporting
       SSRC's RTCP packets.

   2.  Enable explicit identification of RTP/AVP and RTP/AVPF profiles (or
   their secure variants) are combined in a single RTP session, and the SSRCs
   RTP/AVPF endpoints use a non-zero T_rr_interval that are actively
       reporting as one entity.

8.3.  RTCP Packet Reporting Group's Reporting Sources

   This section defines is significantly
   lower than 5 seconds, then there is a new risk that the RTP/AVP endpoints
   will prematurely timeout the RTP/AVPF endpoints due to their
   different RTCP packet type called "Reporting Group's
   Reporting Sources" (RGRS).  It identifies timeout intervals.  Since an RTP session can only use
   a single RTP profile, this issue ought never occur.  If such mixed
   RTP profiles are used, however, the SSRC(s) RTP/AVPF session MUST NOT use a
   non-zero T_rr_interval that report on
   behalf of the SSRC is smaller than 5 seconds.

   (tbd: it has been suggested that a minimum non-zero T_rr_interval of
   4 seconds is more appropriate, due to the sender nature of the RGRS packet. timing

6.2.  Tuning RTCP transmissions

   This packet consists sub-section discusses what tuning can be done to reduce the
   downsides of the fixed shared RTCP packet header which indicates intervals.

   When using the packet type, RTP/AVP or RTP/SAVP profiles the number of reporting sources included and the
   SSRC which behalf the reporting SSRCs report on.  This tuning one can do is followed by
   the list of reporting SSRCs.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |V=2|P|    SC   | PT=RGRS(TBA)  |             length            |
   |                     SSRC of packet sender                     |
   :                     SSRC for Reporting Source                 :
   very limited.  The RTCP Packets field controls one has are limited to the following definition.

   version (V):  This field identifies RTCP bandwidth
   values and whether the RTP version.  The current
      version minimum RTCP interval is 2.

   padding (P):  1 bit If set, scaled according to
   the padding bit indicates that bandwidth.  As the packet
      contains additional padding octets at scheduling algorithm includes both random
   factors and reconsideration, one can't simply calculate the expected
   average transmission interval using the end that are not part of formula for Td.  But it does
   indicate the control information but are included in important factors affecting the length field.  See

   Source Count (SC):  5 bits Indicating transmission interval,
   namely the number of reporting SSRCs
      (1-31) that are include in this RTCP packet type.

   Payload type (PT):  8 bits This is bandwidth available for the RTCP packet type that
      identifies role (Active Sender or
   Participant), the packet as being an RTCP FB message.  The RGRS average RTCP packet has the value [TBA].

   Length:  16 bits The length of this packet in 32-bit words minus one,
      including the header size, and any padding.  This is in line with the
      definition number of the length field used SSRCs
   classified in RTCP sender and receiver
      reports [RFC3550].

   SSRC of packet sender:  32 bits.  The SSRC of the sender of this
      packet which indicates which SSRCs relevant role.  Note that reports on its behalf,
      instead if the ratio of reporting itself.

   SSRC for Reporting Source:  A variable senders
   to total number (as indicated by Source
      Count) of 32-bit SSRC values.  Each SSRC session participants is an reporting SSRC
      belonging larger than the ratio of
   RTCP bandwidth for senders in relation to the same Report Group.

   Each RGRS packet MUST contain at least one reporting SSRC.  In case total RTCP bandwidth,
   then senders and receivers are treated together.

   Let's start with some basic observations:

   a.  Unless the reporting SSRC field scaled minimum RTCP interval is insufficient used, then Td prior to list all
       randomization and reconsideration can never be less than 5
       seconds (assuming default Tmin of 5 seconds).

   b.  If the SSRCs that scaled minimum RTCP interval is reporting used, Td can become as low
       as 360 divided by RTP Session bandwidth in this report group, the SSRC SHALL round robin around kilobits.  In SDP the reporting sources.

       RTP mixer or translator which forwards SR or RR packets from
   members of a reporting group MUST forward the corresponding RGRS RTCP
   packet as well.

8.4.  RTCP Source Description (SDES) item for Reporting Groups

   A new RTCP Source Description (SDES) item session bandwidth is defined for the purpose signalled using b=AS.  An RTP Session
       bandwidth of identifying reporting groups.

   The Source Description (SDES) item "RGRP" is sent by 72 kbps results in Tmin being 5 seconds.  An RTP
       session bandwidth of 360 kbps of course gives a reporting
   group's reporting SSRC.  Syntactically, its format is the same as the
   RTCP SDES CNAME item [RFC6222], Tmin of 1 second,
       and MUST be chosen with to achieve a Tmin equal to once every frame for a 25 Hz video
       stream requires an RTP session bandwidth of 9 Mbps!  (The use of
       the same
   global-uniqueness RTP/AVPF or RTP/SAVPF profile allows a smaller Tmin, and privacy considerations
       hence more frequent RTCP reports, as CNAME.  This name
   MUST be stable across discussed below).

   c.  Let's calculate the lifetime number (n) of SSRCs in the reporting group, even if RTP session that
       5% of the session bandwidth can support to yield a Td value equal
       to Tmin with minimal scaling.  For this calculation we have to
       make two assumptions.  The first is that we will consider most or
       all SSRC being senders, resulting in everyone sharing the
       available bandwidth.  Secondly we will select an average RTCP
       packet size.  This packet will consist of a reporting source changes.

   Every source which belongs an SR, containing (n-1)
       report blocks up to a reporting group MUST either include 31 report blocks, and an RGRP SDES item in an SDES packet (if it is with at
       least a reporting source), or
   an RGRS packet (if it is not), CNAME (17 bytes in every compound RTCP packet size) in which
   it sends an RR or SR it.  Such a basic packet (i.e., in every RTCP packet it sends,
   unless Reduced-Size RTCP [RFC5506] is in use).

   Any RTP mixer or translator which forwards SR or RR packets from
   members of a reporting group MUST forward the corresponding RGRP SDES
   items as well, even if it otherwise strips SDES items other than

8.5.  Middlebox Considerations

   This section discusses middlebox considerations for Reporting groups.

   To will
       be expanded.

8.6.  SDP signaling 800 bytes for Reporting Groups


8.7.  Bandwidth Benefits of RTCP Reporting Groups

   To understand n>=32.  With these parameters, and as the benefits of RTCP reporting groups, consider
       bandwidth goes up the
   scenario described in Section 4.1.  This scenario describes an
   environment in which time interval is proportionally decreased
       (due to minimal scaling), thus all the two endpoints in a session each have example bandwidths 72
       kbps, 360 kbps and 9 Mbps all support 9 SSRCs.

   d.  The actual transmission interval for a
   hundred sources, of Td value is [0.5*Td/
       1.21828,1.5*Td/1.21828], which eight each are sending within any given
   reporting interval.

   For ease of analysis, we can make the simplifying approximation means that for Td = 5 seconds, the duration of the RTCP reporting
       interval is equal to actually [2.052,6.156] and the total
   size of distribution is not
       uniform, but rather exponentially-increasing.  The probability
       for sending at time X, given it is within the RTCP packets sent during an RTCP interval, divided by the
   RTCP bandwidth.  (This will be approximately true is
       probability of picking X in scenarios where the bandwidth is not so high interval times the probability to
       randomly picking a number that is <=X within the minimum RTCP interval is
   reached.)  For further simplification, we can assume RTCP senders are
   following with an
       uniform probability distribution.  This results in that the recommendations
       majority of Section 6.3; thus, the per-packet
   transport-layer overhead will be probability mass is above the Td value.

   To conclude, with RTP/AVP and RTP/SAVP the key limitation for small relative
   unicast sessions is going to be the RTCP data.
   Thus, only Tmin value.  Thus the actual RTCP data itself need be considered.

   In a report interval RTP session
   bandwidth configured in this scenario, there will, as a baseline, RTCP has to be
   200 SDES packets, 184 RR packets, and 16 SR packets.  This amounts sufficiently high to
   approximately 6.5 kB of RTCP per report interval, assuming 16-byte
   CNAMEs and no other SDES information.

   Using reach the original [RFC3550] everyone-reports-on-every-sender
   feedback rules, each of
   reporting goals the 184 receivers will send 16 report blocks,
   and each of application has following the 16 senders will send 15.  This amounts to
   approximately 76 kB of report block traffic per interval; 92% of rules for the
   scaled minimal RTCP
   traffic consists of report blocks.

   If reporting groups are used, however, there is only 0.4 kB of
   reports per interval, with no loss of useful information.
   Additionally, there will be (assuming 16-byte RGRPs, and interval.

   When using RTP/AVPF or RTP/SAVPF we get a single
   reporting source per reporting group) an quite powerful additional 2.4 kB per cycle
   tool, the setting of RGRP SDES items and RGRS packets.  Put another way, the unmodified
   [RFC3550] T_rr_interval which has several effects on
   the RTCP reporting.  First of all as Tmin is set to 0 after the
   initial transmission, the regular reporting interval is approximately 8.9 times instead
   determined by the regular bandwidth based calculation and the
   T_rr_interval.  This has the effect that we are no longer than
   if reporting groups restricted
   by the minimal interval or even the scaling rule for the minimal
   rule.  Instead the RTCP bandwidth and the T_rr_interval are in use.

8.8.  Consequences of the
   governing factors.  Now it also becomes important to separate between
   the application's need for regular reports and RTCP Reporting Groups

   The feedback packet
   types.  In both regular RTCP traffic generated by receivers using mode, as in Early RTCP Reporting Groups
   might appear, to observers unaware Mode, the usage
   of these semantics, the T_rr_interval prevents regular RTCP packets, i.e.  packets
   without any Feedback packets, to be
   generated by receivers who are experiencing sent more often than
   T_rr_interval.  This value is a network disconnection, hard as the non-reporting sources appear not to no regular RTCP packet can be receiving
   sent less than T_rr_interval after the previous regular packet

   So applications that have a given
   sender at all.

   This use for feedback packets for some media
   streams, for example video streams, but don't want frequent regular
   reporting for audio, could be configure the T_rr_interval to a potentially critical problem value so
   that the regular reporting for such both audio and video is at a sender using 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, and can
   include other report information in addition to the feedback packet
   that needs to be sent.  That way the available RTCP bandwidth can be
   focused for congestion control, as such a sender the use which provides the most utility for the

   Using T_rr_interval still requires one to determine suitable values
   for the RTCP bandwidth value, in fact it might think that make it even more
   important, as this is
   sending so much traffic that more likely to affect the RTCP behaviour and
   performance than when using RTP/AVP, as there are fewer limitations
   affecting the RTCP transmission.

   When using T_rr_interval, i.e.  having it be non zero, there are
   configurations that have to be avoided.  If the resulting Td value is causing complete congestion

   However, such an interpretation
   smaller but close to T_rr_interval then the interval in which the
   actual regular RTCP packet transmission falls into becomes very
   large, from 0.5 times T_rr_interval up to 2.73 times the
   T_rr_interval.  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 that the session statistics would
   range becomes [0.5*T_rr_interval, 1.81*T_rr_interval].

   With RTP/AVPF, using a fairly sophisticated RTCP analysis.  Any receiver T_rr_interval of 0 or with another low value
   significantly lower than Td still has utility, and different
   behaviour compared to RTP/AVP.  This avoids the Tmin limitations of
   RTP/AVP, thus allowing more frequent regular RTCP
   statistics which is just interested in information about itself needs
   to be prepared reporting.  In fact
   this will result that any given reception report might not contain
   information about the RTCP traffic becomes as high as the
   configured values.

   (tbd: a specific media source, because reception reports
   in large conferences can be round-robined.

   Thus, it is unclear future version of this memo will include examples of how to what extent such backward compatibility issues
   would actually cause trouble in practice.

   choose RTCP parameters for common scenarios)

   There exists no method within the specification for using different
   regular RTCP reporting intervals depending on the media type or
   individual media stream.

7.  Security Considerations
   In the secure RTP protocol (SRTP) [RFC3711], the cryptographic
   context of a compound SRTCP 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] which use per-SSRC

   Other than that, the standard security considerations of RTP apply;
   sending multiple media streams from a single endpoint does not appear
   to have different security consequences than sending the same number
   of streams.


8.  Open Issues

   At this stage this document contains a number of open issues.  The
   below list tries to summarize the issues:

   1.  Further clarifications on how to handle the RTCP scheduler when
       sending multiple sources in one compound packet.

   2.  How is the use of reporting groups be signaled in SDP?

   3.  How is the RTCP avg_rtcp_size be calculated when RTCP packets are
       routinely multiplexed among multiple RTCP senders?


   3.  Do we need to provide a recommendation for unicast session
       joiners with many sources to not use 0 initial minimal interval
       from bit-rate burst perspective?


9.  IANA Considerations

   This document make several requests to IANA for registering new RTP/
   RTCP identifiers.

   (Note to the RFC-Editor: please replace "TBA" with the IANA-assigned
   value, and "XXXX" with the number of this document, prior to
   publication as an RFC.)

11.1.  RTCP SDES Item

   This document adds an additional SDES types to the IANA "RTCP SDES
   Item Types" Registry, as follows:

   Value    Abbrev      Name              Reference
   TBA      RGRP        Reporting Group   [RFCXXXX]

           Figure 1: Item for the IANA Source Attribute Registry

11.2.  RTCP Packet Type

   This document defines one new RTCP Control Packet types (PT) to be
   registered as follows:

   Value    Abbrev      Name                                Reference
   TBA      RGRR        Reporting Group Reporting Sources   [RFCXXXX]

    Figure 2: Item for the

   No IANA RTCP Control Packet Types (PT) Registry

12. actions needed.

10.  References


10.1.  Normative References

              Begen, A., Perkins, C., Wing, D., and E. Rescorla,
              "Guidelines for Choosing RTP Control Protocol (RTCP)
              Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-04
              (work in progress), June 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July

   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
              Real-time Transport Control Protocol (RTCP)-Based Feedback
              (RTP/SAVPF)", RFC 5124, February 2008.

   [RFC5506]  Johansson, I. and M. Westerlund, "Support for Reduced-Size
              Real-Time Transport Control Protocol (RTCP): Opportunities
              and Consequences", RFC 5506, April 2009.

   [RFC6222]  Begen, A., Perkins, C., and D. Wing, "Guidelines for
              Choosing RTP Control Protocol (RTCP) Canonical Names
              (CNAMEs)", RFC 6222, April 2011.


10.2.  Informative References

              Westerlund, M., Perkins, C., and J. Lennox, "Multiple
              Media Types in an RTP Session", draft-ietf-avtcore-multi-
              media-rtp-session-02 (work in progress), February 2013.

              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 ",
              draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work
              in progress), July 2013.

              Westerlund, M. and S. Wenger, "RTP Topologies", draft-
              ietf-avtcore-rtp-topologies-update-00 (work in progress),
              April 2013.

              Duckworth, M., Pepperell, A., and S. Wenger, "Framework
              for Telepresence Multi-Streams", draft-ietf-clue-
              framework-10 (work in progress), February May 2013.

              Holmberg, C., Alvestrand, H., and C. Jennings,
              "Multiplexing Negotiation Using Session Description
              Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
              bundle-negotiation-04 (work in progress), February June 2013.

   [RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
              Protocol Extended Reports (RTCP XR)", RFC 3611, November

   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
              August 2004.

Appendix A.  Changes From Earlier Versions

   Note to the RFC-Editor: please remove this section prior to
   publication as an RFC.

A.1.  Changes From WG Draft -00

   o  Split the Reporting Group Extension from this draft into draft-

   o  Added RTCP tuning considerations from draft-ietf-avtcore-multi-

A.2.  Changes From Individual Draft -02

   o  Resubmitted as working group draft.

   o  Updated references.


A.3.  Changes From Individual Draft -01

   o  Merged with draft-wu-avtcore-multisrc-endpoint-adver.

   o  Changed how Reporting Groups are indicated in RTCP, to make it
      clear which source(s) is the group's reporting sources.

   o  Clarified the rules for when sources can be placed in the same
      reporting group.

   o  Clarified that mixers and translators need to pass reporting group
      SDES information if they are forwarding RR and SR traffic from
      members of a reporting group.


A.4.  Changes From Individual Draft -00

   o  Added the Reporting Group semantic to explicitly indicate which
      sources come from a single endpoint, rather than leaving it

   o  Specified that Reporting Group semantics (as they now are) apply
      to AVPF and XR, as well as to RR/SR report blocks.

   o  Added a description of the cascaded source-projecting mixer, along
      with a calculation of its RTCP overhead if reporting groups are
      not in use.

   o  Gave some guidance on how the flexibility of RTCP randomization
      allows some freedom in RTCP multiplexing.

   o  Clarified the language of several of the recommendations.

   o  Added an open issue discussing how avg_rtcp_size ought to be
      calculated for multiplexed RTCP.

   o  Added an open issue discussing how RTCP bandwidths are to be
      chosen for sessions where source bandwidths greatly differ.

Authors' Addresses

   Jonathan Lennox
   Vidyo, Inc.
   433 Hackensack Avenue
   Seventh Floor
   Hackensack, NJ  07601

   Email: jonathan@vidyo.com

   Magnus Westerlund
   Farogatan 6
   SE-164 80 Kista

   Phone: +46 10 714 82 87
   Email: magnus.westerlund@ericsson.com

   Qin Wu
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu 210012

   Email: sunseawq@huawei.com
   Colin Perkins
   University of Glasgow
   School of Computing Science
   Glasgow  G12 8QQ
   United Kingdom

   Email: csp@csperkins.org