Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5760

RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback

Pages: 66
Proposed Standard
Errata
Updated by:  6128
Part 2 of 3 – Pages 13 to 39
First   Prev   Next

Top   ToC   RFC5760 - Page 13   prevText

7. Distribution Source Feedback Summary Model

In the Distribution Source Feedback Summary Model, the Distribution Source is required to summarize the information received from all the Receiver Reports generated by the receivers and place the information into summary reports. The Distribution Source Feedback Summary Model introduces a new report block format, the Receiver Summary Information (RSI) report, and a number of optional sub-report block formats, which are enumerated in Section 7.1. As described in Section 7.3, individual instances of the Feedback Target may provide preliminary summarization to reduce the processing load at the Distribution Source.
Top   ToC   RFC5760 - Page 14
   Sub-reports appended to the RSI report block provide more detailed
   information on the overall session characteristics reported by all
   receivers and can also convey important information such as the
   feedback address and reporting bandwidth.  Which sub-reports are
   mandatory and which ones are optional is defined below.

   From an RTP perspective, the Distribution Source is an RTP receiver,
   generating its own Receiver Reports and sending them to the receiver
   group and to the Media Senders.  In the Distribution Source Feedback
   Summary Model, an RSI report block MUST be appended to all RRs the
   Distribution Source generates.

   In addition, the Distribution Source MUST forward the RTCP SR reports
   and SDES packets of Media Senders without alteration.  If the
   Distribution Source is actually a Media Sender, even if it is the
   only session sender, it MUST generate its own Sender Report (SR)
   packets for its role as a Media Sender and its Receiver Reports in
   its role as the Distribution Source.

   The Distribution Source MUST use its own SSRC value for transmitting
   summarization information and MUST perform proper SSRC collision
   detection and resolution.

   The Distribution Source MUST send at least one Receiver Summary
   Information packet for each reporting interval.  The Distribution
   Source MAY additionally stack sub-report blocks after the RSI packet.
   If it does so, each sub-report block MUST correspond to the RSI
   packet and constitutes an enhancement to the basic summary
   information required by the receivers to calculate their reporting
   time interval.  For this reason, additional sub-report blocks are not
   required but recommended.  The compound RTCP packets containing the
   RSI packet and the optional corresponding sub-report blocks MUST be
   formed according to the rules defined in [1] for receiver-issued
   packets, e.g., they MUST begin with an RR packet, contain at least an
   SDES packet with a CNAME, and MAY contain further RTCP packets and
   SDES items.

   Every RSI packet MUST contain either a Group and Average Packet Size
   sub-report or an RTCP Bandwidth sub-report for bandwidth indications
   to the receivers.

7.1. Packet Formats

All numeric values comprising multiple (usually two or four) octets MUST be encoded in network byte order.
Top   ToC   RFC5760 - Page 15

7.1.1. RSI: Receiver Summary Information Packet

The RSI report block has a fixed header size followed by a variable length report: 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|reserved | PT=RSI=209 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Summarized SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp (most significant word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp (least significant word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Sub-report blocks : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RSI packet includes the following fields: Length: 16 bits As defined in [1], the length of the RTCP packet in 32-bit words minus one, including the header and any padding. SSRC: 32 bits The SSRC of the Distribution Source. Summarized SSRC: 32 bits The SSRC (of the Media Sender) of which this report contains a summary. Timestamp: 64 bits Indicates the wallclock time when this report was sent. Wallclock time (absolute date and time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900 [1]. The wallclock time MAY (but need not) be NTP-synchronized but it MUST provide a consistent behavior in the advancement of time (similar to NTP). The full-resolution NTP timestamp is used, which is a 64-bit, unsigned, fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. This format is similar to RTCP Sender Reports (Section 6.4.1 of [1]). The timestamp value is used to enable detection of duplicate packets, reordering, and to provide a chronological profile of the feedback reports.
Top   ToC   RFC5760 - Page 16

7.1.2. Sub-Report Block Types

For RSI reports, this document also introduces a sub-report block format specific to the RSI packet. The sub-report blocks are appended to the RSI packet using the following generic format. All sub-report blocks MUST be 32-bit aligned. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRBT-specific data + | | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRBT: 8 bits Sub-Report Block Type. The sub-report block type identifier. The values for the sub-report block types are defined in Section 5. Length: 8 bits The length of the sub-report in 32-bit words. SRBT-specific data: <length * 4 - 2> octets This field may contain type-specific information based upon the SRBT value.

7.1.3. Generic Sub-Report Block Fields

For the sub-report blocks that convey distributions of values (Loss, Jitter, RTT, Cumulative Loss), a flexible 'data bucket'-style report is used. This format divides the data set into variable-size buckets that are interpreted according to the guide fields at the head of the report block. 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 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SRBT | Length | NDB | MF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Distribution Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Distribution Value | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Distribution Buckets | | ... | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Top   ToC   RFC5760 - Page 17
   The SRBT and length fields are calculated as explained in Section
   7.1.2.

   Number of distribution buckets (NDB): 12 bits
      The number of distribution buckets of data.  The size of each
      bucket can be calculated using the formula
      ((length * 4) - 12) * 8 / NDB number of bits.  The calculation is
      based on the length of the whole sub-report block in octets
      (length * 4) minus the header of 12 octets.  Providing 12 bits for
      the NDB field enables bucket sizes as small as 2 bits for a full-
      length packet of MTU 1500 bytes.  The bucket size in bits must
      always be divisible by 2 to ensure proper byte alignment.  A
      bucket size of 2 bits is fairly restrictive, however, and it is
      expected that larger bucket sizes will be more practical for most
      distributions.

   Multiplicative Factor (MF): 4 bits
      2^MF indicates the multiplicative factor to be applied to each
      distribution bucket value.  Possible values of MF are 0 - 15,
      creating a range of values from MF = 1, 2, 4 ... 32768.  Appendix
      B gives an example of the use of the multiplicative factor; it is
      meant to provide more "bits" without having them -- the bucket
      values get scaled up by the MF.

   Length: 8 bits
      The length field tells the receiver the full length of the sub-
      report block in 32-bit words (i.e., length * 4 bytes) and enables
      the receiver to identify the bucket size.  For example, given no
      MTU restrictions, the data portion of a distribution packet may be
      only as large as 1008 bytes (255 * 4 - 12), providing up to 4032
      data buckets of length 2 bits, or 2016 data buckets of length 4
      bits, etc.

   Minimum distribution value (min): 32 bits
      The minimum distribution value, in combination with the maximum
      distribution value, indicates the range covered by the data bucket
      values.

   Maximum distribution value (max): 32 bits
      The maximum distribution value, in combination with the minimum
      distribution value, indicates the range covered by the data bucket
      values.  The significance and range of the distribution values is
      defined in the individual subsections for each distribution type
      (DT).
Top   ToC   RFC5760 - Page 18
   Distribution buckets: each bucket is ((length * 4) - 12) * 8 / NDB
      bits
      The size and number of buckets is calculated as outlined above
      based upon the value of NDB and the length of the packet.  The
      values for distribution buckets are equally distributed; according
      to the following formula, distribution bucket x (with 0 <= x <
      NDB) covers the value range:

      x = 0; [min, min + (max - min) / NDB]
      x > 0; [min + (x) * (max - min) / NDB,
              min + (x + 1) * (max - min) / NDB]

   Interpretation of the minimum, maximum, and distribution values in
   the sub-report block is sub-report-specific and is addressed
   individually in the sections below.  The size of the sub-report block
   is variable, as indicated by the packet length field.

   Note that, for any bucket-based reporting, if the Distribution Source
   and the Feedback Target(s) are disjoint entities, out-of-band
   agreement on the bucket-reporting granularity is recommended to allow
   the Distribution Source to forward accurate information in these
   kinds of reports to the receivers.

7.1.4. Loss Sub-Report Block

The Loss sub-report block allows a receiver to determine how its own reception quality relates to the other recipients. A receiver may use this information, e.g., to drop out of a session (instead of sending lots of error repair feedback) if it finds itself isolated at the lower end of the reception quality scale. The Loss sub-report block indicates the distribution of losses as reported by the receivers to the Distribution Source. Values are expressed as a fixed-point number with the binary point at the left edge of the field similar to the "fraction lost" field in SR and RR packets, as defined in [1]. The Loss sub-report block type (SRBT) is 4. Valid results for the minimum distribution value field are 0 - 254. Similarly, valid results for the maximum distribution value field are 1 - 255. The minimum distribution value MUST always be less than the maximum. For examples on processing summarized loss report sub-blocks, see Appendix B.
Top   ToC   RFC5760 - Page 19

7.1.5. Jitter Sub-Report Block

A Jitter sub-report block indicates the distribution of the estimated statistical variation of the RTP data packet inter-arrival time reported by the receivers to the Distribution Source. This allows receivers both to place their own observed jitter values in context with the rest of the group and to approximate dynamic parameters for playout buffers. See [1] for details on the calculation of the values and the relevance of the jitter results. Jitter values are measured in timestamp units with the rate used by the Media Sender and expressed as unsigned integers. The minimum distribution value MUST always be less than the maximum. The Jitter sub-report block type (SRBT) is 5. Since timestamp units are payload-type specific, the relevance of a jitter value is impacted by any change in the payload type during a session. Therefore, a Distribution Source MUST NOT report jitter distribution values for at least 2 reporting intervals after a payload type change occurs.

7.1.6. Round-Trip Time Sub-Report Block

A Round-Trip Time sub-report indicates the distribution of round-trip times from the Distribution Source to the receivers, providing receivers with a global view of the range of values in the group. The Distribution Source is capable of calculating the round-trip time to any other member since it forwards all the SR packets from the Media Sender(s) to the group. If the Distribution Source is not itself a Media Sender, it can calculate the round-trip time from itself to any of the receivers by maintaining a record of the SR sender timestamp and the current time as measured from its own system clock. The Distribution Source consequently calculates the round- trip time from the Receiver Report by identifying the corresponding SR timestamp and subtracting the RR advertised holding time as reported by the receiver from its own time difference measurement, as calculated by the time the RR packet is received and the recorded time the SR was sent. The Distribution Source has the option of distributing these round- trip time estimations to the whole group, uses of which are described in Section 7.4. The round-trip time is expressed in units of 1/65536 seconds and indicates an absolute value. This is calculated by the Distribution Source, based on the Receiver Report responses declaring the time difference since an original Sender Report and on the holding time at the receiver. The minimum distribution value MUST always be less than the maximum. The Round-Trip Time sub-report block type (SRBT) is 6.
Top   ToC   RFC5760 - Page 20
      Note that if the Distribution Source and the Feedback Target
      functions are disjoint, it is only possible for the Distribution
      Source to determine RTT if all the Feedback Targets forward all
      RTCP reports from the receivers immediately (i.e., do not perform
      any preliminary summarization) and include at least the RR packet.

7.1.7. Cumulative Loss Sub-Report Block

The cumulative loss field in a Receiver Report [1], in contrast to the fraction lost field, is intended to provide some historical perspective on the session performance, i.e., the total number of lost packets since the receiver joined the session. The cumulative loss value provides a longer-term average by summing over a larger sample set (typically the whole session). The Distribution Source MAY record the values as reported by the receiver group and report a distribution of values. Values are expressed as a fixed-point number with the binary point at the left edge of the field, in the same manner as the Loss sub-report block. Since the individual Receiver Reports give the cumulative number of packets lost but not the cumulative number sent, which is required as a denominator to calculate the long-term fraction lost, the Distribution Source MUST maintain a record of the cumulative number lost and extended highest sequence number received, as reported by each receiver at some point in the past. Ideally, the recorded values are from the first report received. Subsequent calculations are then based on (<the new cumulative loss value> - <the recorded value>) / (<new extended highest sequence number> - <recorded sequence number>). Valid results for the minimum distribution value field are 0 - 254. Similarly, valid results for the maximum distribution value field are 1 - 255. The minimum distribution value MUST always be less than the maximum. The Cumulative Loss sub-report block type (SRBT) is 7.

7.1.8. Feedback Target Address Sub-Report Block

The Feedback Target Address block provides a dynamic mechanism for the Distribution Source to signal an alternative unicast RTCP feedback address to the receivers. If a block of this type is included, receivers MUST override any static SDP address information for the session with the Feedback Target address provided in this sub-report block. If a Feedback Target Address sub-report block is used, it MUST be included in every RTCP packet originated by the Distribution Source to ensure that all receivers understand the information. In this manner, receiver behavior should remain consistent even in the face of packet loss or when there are late session arrivals.
Top   ToC   RFC5760 - Page 21
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SRBT={0,1,2}  |     Length    |             Port              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                            Address                            :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   SRBT: 8 bits
      The type of sub-report block that corresponds to the type of
      address is as follows:

         0: IPv4 address
         1: IPv6 address
         2: DNS name

   Length: 8 bits
      The length of the sub-report block in 32-bit words.  For an IPv4
      address, this should be 2 (i.e., total length = 4 + 4 = 2 * 4
      octets).  For an IPv6 address, this should be 5.  For a DNS name,
      the length field indicates the number of 32-bit words making up
      the string plus 1 byte and any additional padding required to
      reach the next word boundary.

   Port: 2 octets
      The port number to which receivers send feedback reports.  A port
      number of 0 is invalid and MUST NOT be used.

   Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name)
      The address to which receivers send feedback reports.  For IPv4
      and IPv6, fixed-length address fields are used.  A DNS name is an
      arbitrary-length string that is padded with null bytes to the next
      32-bit boundary.  The string MAY contain Internationalizing Domain
      Names in Applications (IDNA) domain names and MUST be UTF-8
      encoded [11].

   A Feedback Target Address block for a certain address type (i.e.,
   with a certain SRBT of 0, 1, or 2) MUST NOT occur more than once
   within a packet.  Numerical Feedback Target Address blocks for IPv4
   and IPv6 MAY both be present.  If so, the resulting transport
   addresses MUST point to the same logical entity.

   If a Feedback Target address block with an SRBT indicating a DNS name
   is present, there SHOULD NOT be any other numerical Feedback Target
   Address blocks present.
Top   ToC   RFC5760 - Page 22
   The Feedback Target Address presents a significant security risk if
   accepted from unauthenticated RTCP packets.  See Sections 11.3 and
   11.4 for further discussion.

7.1.9. Collision Sub-Report Block

The Collision SSRC sub-report provides the Distribution Source with a mechanism to report SSRC collisions amongst the group. In the event that a non-unique SSRC is discovered based on the tuple [SSRC, CNAME], the collision is reported in this block and the affected nodes must reselect their respective SSRC identifiers. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT=8 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Collision SSRC : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Collision SSRC: n * 32 bits This field contains a list of SSRCs that are duplicated within the group. Usually this is handled by the hosts upon detection of the same SSRC; however, since receivers in an SSM session using the Distribution Source Feedback Summary Model no longer have a global view of the session, the collision algorithm is handled by the Distribution Source. SSRCs that collide are listed in the packet. Each Collision SSRC is reported only once for each collision detection. If more Collision SSRCs need to be reported than fit into an MTU, the reporting is done in a round robin fashion so that all Collision SSRCs have been reported once before the second round of reporting starts. On receipt of the packet, receiver(s) MUST detect the collision and select another SSRC, if the collision pertains to them. The Collision sub-report block type (SRBT) is 8. Collision detection is only possible at the Distribution Source. If the Distribution Source and Feedback Target functions are disjoint and collision reporting across RTP receiver SSRCs shall be provided, the Feedback Targets(s) MUST forward the RTCP reports from the RTP receivers, including at least the RR and the SDES packets to the Distribution Source.
Top   ToC   RFC5760 - Page 23
   In system settings in which, by explicit configuration or
   implementation, RTP receivers are not going to act as Media Senders
   in a session (e.g., for various types of television broadcasting),
   SSRC collision detection MAY be omitted for RTP receivers.  In system
   settings in which an RTP receiver MAY become a Media Sender (e.g.,
   any conversational application), SSRC collision detection MUST be
   provided for RTP receivers.

      Note: The purpose of SSRC collision reporting is to ensure unique
      identification of RTCP entities.  This is of particular relevance
      for Media Senders so that an RTP receiver can properly associate
      each of the multiple incoming media streams (via the Distribution
      Source) with the correct sender.  Collision resolution for Media
      Senders is not affected by the Distribution Source's collision
      reporting because all SR reports are always forwarded among the
      senders and to all receivers.  Collision resolution for RTP
      receivers is of particular relevance for those receivers capable
      of becoming a Media Sender.  RTP receivers that will, by
      configuration or implementation choice, not act as a sender in a
      particular RTP session, do not necessarily need to be aware of
      collisions as long as the those entities receiving and processing
      RTCP feedback messages from the receivers are capable of
      disambiguating the various RTCP receivers (e.g., by CNAME).

      Note also that RTP receivers should be able to deal with the
      changing SSRCs of a Media Sender (like any RTP receiver has to
      do.) and, if possible, be prepared to continuously render a media
      stream nevertheless.

7.1.10. General Statistics Sub-Report Block

The General Statistics sub-report block is used if specifying buckets is deemed too complex. With the General Statistics sub-report block, only aggregated values are reported back. The rules for the generation of these values are provided in point b of Section 7.2.1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT=10 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MFL | HCNL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Median inter-arrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC5760 - Page 24
   Median fraction lost (MFL): 8 bits
      The median fraction lost indicated by Receiver Reports forwarded
      to this Distribution Source, expressed as a fixed-point number
      with the binary point at the left edge of the field.  A value of
      all '1's indicates that the MFL value is not provided.

   Highest cumulative number of packets lost (HCNL): 24 bits
      Highest 'cumulative number of packets lost' value out of the most
      recent RTCP RR packets from any of the receivers.  A value of all
      '1's indicates that the HCNL value is not provided.

   Median inter-arrival jitter: 32 bits
      Median 'inter-arrival jitter' value out of the most recent RTCP RR
      packets from the receiver set.  A value of all '1's indicates that
      this value is not provided.

   The General Statistics sub-report block type (SRBT) is 10.

   Note that, in case the Distribution Source and the Feedback Target
   functions are disjoint, it is only possible for the Distribution
   Source to determine the median of the inter-arrival jitter if all the
   Feedback Targets forward all RTCP reports from the receivers
   immediately and include at least the RR packet.

7.1.11. RTCP Bandwidth Indication Sub-Report Block

This sub-report block is used to inform the Media Senders and receivers about either the maximum RTCP bandwidth that is supposed to be used by each Media Sender or the maximum bandwidth allowance to be used by each receiver. The value is applied universally to all Media Senders or all receivers. Each receiver MUST base its RTCP transmission interval calculation on the average size of the RTCP packets sent by itself. Conversely, each Media Sender MUST base its RTCP transmission interval calculation on the average size of the RTCP packets sent by itself. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT=11 | Length |S|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTCP Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC5760 - Page 25
   Sender (S): 1 bit
      The contained bandwidth value applies to each Media Sender.

   Receivers (R): 1 bit
      The contained bandwidth value applies to each RTP receiver.

   Reserved: 14 bits
      MUST be set to zero upon transmission and ignored upon reception.

   RTCP Bandwidth: 32 bits
      If the S bit is set to 1, this field indicates the maximum
      bandwidth allocated to each individual Media Sender.  This also
      informs the receivers about the RTCP report frequency to expect
      from the senders.  This is a fixed-point value with the binary
      point in between the second and third bytes.  The value represents
      the bandwidth allocation per receiver in kilobits per second, with
      values in the range 0 <= BW < 65536.

      If the R bit is set to 1, this field indicates the maximum
      bandwidth allocated per receiver for sending RTCP data relating to
      the session.  This is a fixed-point value with the binary point in
      between the second and third bytes.  The value represents the
      bandwidth allocation per receiver in kilobits per second, with
      values in the range 0 <= BW < 65536.  Each receiver MUST use this
      value for its bandwidth allowance.

   This report block SHOULD only be used when the Group and Average
   Packet Size sub-report block is NOT included.  The RTCP Bandwidth
   Indication sub-report block type (SRBT) is 11.

7.1.12. RTCP Group and Average Packet Size Sub-Report Block

This sub-report block is used to inform the Media Senders and receivers about the size of the group (used for calculating feedback bandwidth allocation) and the average packet size of the group. This sub-report MUST always be present, appended to every RSI packet, unless an RTCP Bandwidth Indication sub-report block is included (in which case it MAY, but need not, be present). Note: The RTCP Bandwidth Indication sub-report block allows the Distribution Source to hide the actual group size from the receivers while still avoiding feedback implosion.
Top   ToC   RFC5760 - Page 26
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SRBT=12    |    Length     |     Average Packet Size       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Receiver Group Size                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Group size: 32 bits
      This field provides the Distribution Source's view of the number
      of receivers in a session.  Note that the number of Media Senders
      is not explicitly reported since it can be derived by observing
      the RTCP SR packets forwarded by the Distribution Source.  The
      group size is calculated according to the rules outlined in [1].
      When this sub-report block is included, this field MUST always be
      present.

   Average RTCP packet size: 16 bits
      This field provides the Distribution Source's view of the average
      RTCP packet size as locally calculated, following the rules
      defined in [1].  The value is an unsigned integer, counting
      octets.  When this sub-report block is included, this field MUST
      always be present.

   The Group and Average Packet Size sub-report block type (SRBT) is 12.

7.2. Distribution Source Behavior

In the Distribution Source Feedback Summary Model, the Distribution Source (the unicast Feedback Target) MUST listen for unicast RTCP packets sent to the RTCP port. All RTCP packets received on this port MUST be processed by the Distribution Source, as described below. The processing MUST take place per Media Sender SSRC for which Receiver Reports are received. The Distribution Source acts like a regular RTCP receiver. In particular, it receives an RTP stream from each RTP Media Sender(s) and MUST calculate the proper reception statistics for these RTP streams. It MUST transmit the resulting information as report blocks contained in each RTCP packet it sends (in an RR packet). Note: This information may help to determine the transmission characteristics of the feed path from the RTP sender to the Distribution Source (if these are separate entities). The Distribution Source is responsible for accepting RTCP packets from the receivers and for interpreting and storing per-receiver information, as defined in [1]. The importance of providing these
Top   ToC   RFC5760 - Page 27
   functions is apparent when creating the RSI and sub-report block
   reports since incorrect information can have serious implications.
   Section 11 addresses the security risks in detail.

   As defined in [1], all RTCP reports from the Distribution Source MUST
   start with an RR report, followed by any relevant SDES fields.  Then
   the Distribution Source MUST append an RSI header and sub-reports
   containing any summarization-specific data.  In addition, either the
   Group and Average Packet Size sub-report or the Receiver RTCP
   Bandwidth sub-report block MUST be appended to the RSI header.

   A Distribution Source has the option of masking the group size by
   including only an RTCP Bandwidth sub-report.  If both sub-reports are
   included, the receiver is expected to give precedence to the
   information contained in the Receiver RTCP Bandwidth sub-report.

   The Receiver RTCP Bandwidth sub-report block provides the
   Distribution Source with the capability to control the amount of
   feedback from the receivers, and the bandwidth value MAY be increased
   or decreased based upon the requirements of the Distribution Source.
   Regardless of the value selected by the Distribution Source for the
   Receiver RTCP Bandwidth sub-report block, the Distribution Source
   MUST continue to forward Sender Reports and RSI packets at the rate
   allowed by the total RTCP bandwidth allocation.  See Section 9 for
   further details about the frequency of reports.

   A Distribution Source MAY start out reporting group size and switch
   to Receiver RTCP Bandwidth reporting later on and vice versa.  If the
   Distribution Source does so, it SHOULD ensure that the
   correspondingly indicated values for the Receiver RTCP Bandwidth sub-
   report roughly match, i.e., are at least the same order of magnitude.

   In order to identify SSRC collisions, the Distribution Source is
   responsible for maintaining a record of each SSRC and the
   corresponding CNAME within at least one reporting interval by the
   group, in order to differentiate between clients.  It is RECOMMENDED
   that an updated list of more than one interval be maintained to
   increase accuracy.  This mechanism should prevent the possibility of
   collisions since the combination of SSRC and CNAME should be unique,
   if the CNAME is generated correctly.  If collisions are not detected,
   the Distribution Source will have an inaccurate impression of the
   group size.  Since the statistical probability is very low that
   collisions will both occur and be undetectable, this should not be a
   significant concern.  In particular, the clients would have to
   randomly select the same SSRC and have the same username + IP address
   (e.g., using private address space behind a NAT router).
Top   ToC   RFC5760 - Page 28

7.2.1. Receiver Report Aggregation

The Distribution Source is responsible for aggregating reception- quality information received in RR packets. In doing so, the Distribution Source MUST consider the report blocks received in every RR packet and MUST NOT consider the report blocks of an SR packet. Note: the receivers will get the information contained in the SR packets anyway by packet forwarding, so duplication of this information should be avoided. For the optional sub-report blocks, the Distribution Source MAY decide which are the most significant feedback values to convey and MAY choose not to include any. The packet format provides flexibility in the amount of detail conveyed by the data points. There is a tradeoff between the granularity of the data and the accuracy of the data based on the multiplicative factor (MF), the number of buckets, and the min and max values. In order to focus on a particular region of a distribution, the Distribution Source can adjust the minimum and maximum values and either increase the number of buckets, and possibly the factorization, or decrease the number of buckets and provide more accurate values. See Appendix B for detailed examples on how to convey a summary of RTCP Receiver Reports as RSI sub-report block information. For each value the Distribution Source decides to include in an RSI packet, it MUST adhere to the following measurement rules. a) If the Distribution Source intends to use a sub-report to convey a distribution of values (Sections 7.1.3 to 7.1.7), it MUST keep per-receiver state, i.e., remember the last value V reported by the respective receiver. If a new value is reported by a receiver, the existing value MUST be replaced by the new one. The value MUST be deleted (along with the entire entry) if the receiver is timed out (as per Section 6.3.5 of [1]) or has sent a BYE packet (as per Section 6.3.7 of [1]). All the values collected in this way MUST be included in the creation of the subsequent Distribution sub-report block. The results should correspond as closely as possible to the values received during the interval since the last report. The Distribution Source may stack as many sub-report blocks as required in order to convey different distributions. If the distribution size exceeds the largest packet length (1008 bytes data portion), more packets MAY be stacked with additional information (but in total SHOULD NOT exceed the path MTU).
Top   ToC   RFC5760 - Page 29
       All stacked sub-reports MUST be internally consistent, i.e.,
       generated from the same session data.  Overlapping of
       distributions is therefore allowed, and variation in values
       should only occur as a result of data set granularity, with the
       more accurate bucket sizes taking precedence in the event that
       values differ.  Non-divisible values MUST be rounded up or down
       to the closest bucket value, and the number of data buckets must
       always be an even number, padding where necessary with an
       additional zero bucket value to maintain consistency.

       Note: This intentionally provides persistent full coverage of the
       entire session membership to avoid oscillations due to changing
       membership samples.

       Scheduling the transmission of summarization reports is left to
       the discretion of the Distribution Source.  However, the
       Distribution Source MUST adhere to the bandwidth limitations for
       Receiver Reports as defined for the respective AV profile in use.

   b)  If the Distribution Source intends to report a short summary
       using the General Statistics sub-report block format, defined in
       Section 7.1.10, for EACH of the values included in the report
       (MFL, HCNL, average inter-arrival jitter), it MUST keep a timer
       T_summary as well as a sufficient set of variables to calculate
       the summaries for the last three reporting intervals.  This MAY
       be achieved by keeping per-receiver state (i.e., remember the
       last value V reported by the respective receiver) or by
       maintaining summary variables for each of these intervals.

       The summary values are included here to reflect the current group
       situation.  By recording the last three reporting intervals, the
       Distribution Source incorporates reports from all members while
       allowing for individual RTCP Receiver Report packet losses.  The
       process of collecting these values also aims to avoid resetting
       any of the values and then having to send out an RSI report based
       upon just a few values collected.  If data is available for less
       than three reporting intervals (as will be the case for the first
       two reports sent), only those values available are considered.

       The timer T_summary MUST be initialized as T_summary = 1.5 * Td,
       where Td is the deterministic reporting interval, and MUST be
       updated following timer reconsideration whenever the group size
       or the average RTCP size ("avg_rtcp_size") changes.  This choice
       should allow each receiver to report once per interval.
Top   ToC   RFC5760 - Page 30
            Td
           __^__
        t0/     \   t1        t2        t3        t4        t5
       ---+---------+---------+---------+---------+---------+------->
          \____ ____/         :         :         :         :
          :    V    :         :         :         :         :
          :T_summary:         :         :         :         :
          :=1.5 * Td:         :         :         :         :
          \______________ ______________/         :         :
                    :    V    :                   :         :
                    : 3 * T_summary               :         :
                    :         :                   :         :
                    \______________ ______________/         :
                              :    V                        :
                              : 3 * T_summary               :
                              :                             :
                              \______________ ______________/
                                             V
                                          3 * T_summary

                 Figure 2: Overview of Summarization Reporting

   Figure 2 depicts how the summarization reporting shall be performed.
   At time t3, the RTCP reports collected from t0 through t3 are
   included in the RSI reporting; at time t4, those from t1 through t4;
   and so on.  The RSI summary report sent MUST NOT include any RTCP
   report from more than three reporting intervals ago, e.g., the one
   sent at time t5, must not include reports received at the
   Distribution Source prior to t2.

7.2.2. Handling Other RTCP Packets from RTP Receivers

When following the Feedback Summary Model, the Distribution Source MAY reflect any other RTCP packets of potential relevance to the receivers (such as APP, RTPFB, PSFB) to the receiver group. Also, it MAY decide not to forward other RTCP packets not needed by the receivers such as BYE, RR, SDES (because the Distribution Source performs collision resolution), group size estimation, and RR aggregation. The Distribution Source MUST NOT forward RR packets to the receiver group. If the Distribution Source is able to interpret and aggregate information contained in any RTCP packets other than RR, it MAY include the aggregated information along with the RSI packet in its own compound RTCP packet.
Top   ToC   RFC5760 - Page 31
   Aggregation MAY be a null operation, i.e., the Distribution Source
   MAY simply append one or more RTCP packets from receivers to the
   compound RTCP packet (containing at least RR, SDES, and RSI from the
   Distribution Source).

      Note: This is likely to be useful only for a few cases, e.g., to
      forward aggregated information from RTPFB Generic NACK packets and
      thereby maintain the damping property of [15].

      Note: This entire processing rule implies that the flow of
      information contained in non-RR RTCP packets may terminate at the
      Distribution Source, depending on its capabilities and
      configuration.

   The configuration of the RTCP SSM media session (expressed in SDP)
   MUST specify explicitly which processing the Distribution Source will
   apply to which RTCP packets.  See Section 10.1 for details.

7.2.3. Receiver Report Forwarding

If the Media Sender(s) are not part of the SSM group for RTCP packet reflection, the Distribution Source MUST explicitly inform the Media Senders of the receiver group. To achieve this, the Distribution Source has two options: 1) it forwards the RTCP RR and SDES packets received from the receivers to the Media Sender(s); or 2) if the Media Senders also support the RTCP RSI packet, the Distribution Source sends the RSI packets not just to the receivers but also to the Media Senders. If the Distribution Source decides to forward RR and SDES packets unchanged, it MAY also forward any other RTCP packets to the senders. If the Distribution Source decides to forward RSI packets to the senders, the considerations of Section 7.2.2 apply.

7.2.4. Handling Sender Reports

The Distribution Source also receives RTCP (including SR) packets from the RTP Media Senders. The Distribution Source MUST forward all RTCP packets from the Media Senders to the RTP receivers. If there is more than one Media Sender and these Media Senders do not communicate via ASM with the Distribution Source and each other, the Distribution Source MUST forward each RTCP packet from any one Media Sender to all other Media Senders.
Top   ToC   RFC5760 - Page 32

7.2.5. RTCP Data Rate Calculation

As noted above, the Distribution Source is a receiver from an RTP perspective. The Distribution Sources MUST calculate its deterministic transmission interval Td as every other receiver; however, it MAY adjust its available data rate depending on the destination transport address and its local operation: 1. For sending its own RTCP reports to the SSM group towards the receivers, the Distribution Source MAY use up to the joint share of all receivers as it is forwarding summaries on behalf of all of them. Thus, the Distribution Source MAY send its reports up to every Td/R time units, with R being the number of receivers. 2. For sending its own RTCP reports to the Media Senders only (i.e., if the Media Senders are not part of the SSM group), the allocated rate depends on the operation of the Distribution Source: a) If the Distribution Source only sends RSI packets along with its own RTCP RR packets, the same rate calculation applies as for #1 above. b) If the Distribution Source forwards RTCP packets from all other receivers to the Media Senders, then it MUST adhere to the same bandwidth share for its own transmissions as all other receivers and use the calculation as per [1].

7.2.6. Collision Resolution

A Distribution Source observing RTP packets from a Media Sender with an SSRC that collides with its own chosen SSRC MUST change its own SSRC following the procedures of [1] and MUST do so immediately after noticing. A Distribution Source MAY use out-of-band information about the Media Sender SSRC(s) used in the media session when available to avoid SSRC collisions with Media Senders. Nevertheless, the Distribution Source MUST monitor Sender Report (SR) packets to detect any changes, observe collisions, and then follow the above collision-resolution procedure. For collision resolution between the Distribution Source and receivers or the Feedback Target(s) (if a separate entity, as described in the next subsection), the Distribution Source and the Feedback Target (if separate) operate similar to ordinary receivers.
Top   ToC   RFC5760 - Page 33

7.3. Disjoint Distribution Source and Feedback Target

If the Distribution Source and the Feedback Target are disjoint, the processing of the Distribution Source is limited by the amount of RTCP feedback information made available by the Feedback Target. The Feedback Target(s) MAY simply forward all RTCP packets incoming from the RTP receivers to the Distribution Source, in which case the Distribution Source will have all the necessary information available to perform all the functions described above. The Feedback Target(s) MAY also perform aggregation of incoming RTCP packets and send only aggregated information to the Distribution Source. In this case, the Feedback Target(s) MUST use correctly formed RTCP packets to communicate with the Distribution Source and they MUST operate in concert with the Distribution Source so that the Distribution Source and the Feedback Target(s) appear to be operating as a single entity. The Feedback Target(s) MUST report their observed receiver group size to the Distribution Source, either explicitly by means of RSI packets or implicitly by forwarding all RR packets. Note: For example, for detailed statistics reporting, the Distribution Source and the Feedback Target(s) may need to agree on a common reporting granularity so that the Distribution Source can aggregate the buckets incoming from various Feedback Targets into a coherent report sent to the receivers. The joint behavior of the Distribution Source and Feedback Target(s) MUST be reflected in the (SDP-based) media session description as per Section 7.2.2. If the Feedback Target performs summarization functions, it MUST also act as a receiver and choose a unique SSRC for its own reporting towards the Distribution Source. The collision-resolution considerations for receivers apply.

7.4. Receiver Behavior

An RTP receiver MUST process RSI packets and adapt session parameters, such as the RTCP bandwidth, based on the information received. The receiver no longer has a global view of the session and will therefore be unable to receive information from individual receivers aside from itself. However, the information conveyed by the Distribution Source can be extremely detailed, providing the receiver with an accurate view of the session quality overall, without the processing overhead associated with listening to and analyzing all Receiver Reports.
Top   ToC   RFC5760 - Page 34
   The RTP receiver MUST process the report blocks contained in any RTP
   SR and RR packets to complete its view of the RTP session.

   The SSRC collision list MUST be checked against the SSRC selected by
   the receiver to ensure there are no collisions as MUST be incoming
   RTP packets from the Media Senders.  A receiver observing RTP packets
   from a Media Sender with an SSRC that collides with its own chosen
   SSRC MUST change its own SSRC following the procedures of [1].  The
   receiver MUST do so immediately after noticing and before sending any
   (further) RTCP feedback messages.

   A Group and Average Packet Size sub-report block is most likely to be
   appended to the RSI header (either a Group Size sub-report or an RTCP
   Bandwidth sub-report MUST be included).  The group size n allows a
   receiver to calculate its share of the RTCP bandwidth, r.  Given R,
   the total available RTCP bandwidth share for receivers (in the SSM
   RTP session) r = R/(n).  For the group size calculation, the RTP
   receiver MUST NOT include the Distribution Source, i.e., the only RTP
   receiver sending RSI packets.

   The receiver RTCP bandwidth field MAY override this value.  If the
   receiver RTCP bandwidth field is present, the receiver MUST use this
   value as its own RTCP reporting bandwidth r.

   If the RTCP bandwidth field was used by the Distribution Source in an
   RTCP session but this field was not included in the last five RTCP
   RSI reports, the receiver MUST revert to calculating its bandwidth
   share based upon the group size information.

   If the receiver has not received any RTCP RSI packets from the
   Distribution Source for a period of five times the sender reporting
   interval, it MUST cease transmitting RTCP Receiver Reports until the
   next RTCP RSI packet is received.

   The receiver can use the summarized data as desired.  This data is
   most useful in providing the receiver with a more global view of the
   conditions experienced by other receivers and enables the client to
   place itself within the distribution and establish the extent to
   which its reported conditions correspond to the group reports as a
   whole.  Appendix B provides further information and examples of data
   processing at the receiver.

   The receiver SHOULD assume that any sub-report blocks in the same
   packet correspond to the same data set received by the Distribution
   Source during the last reporting time interval.  This applies to
   packets with multiple blocks, where each block conveys a different
   range of values.
Top   ToC   RFC5760 - Page 35
   A receiver MUST NOT rely on all of the RTCP packets it sends reaching
   the Media Senders or any other receiver.  While RR statistics will be
   aggregated, BYE packets will be processed, and SSRC collisions will
   usually be announced, processing and/or forwarding of further RTCP
   packets is up to the discretion of the Distribution Source and will
   be performed as specified in the session description.

   If a receiver has out-of-band information available about the Media
   Sender SSRC(s) used in the media session, it MUST NOT use the same
   SSRC for itself.  The receiver MUST be aware that such out-of-band
   information may be outdated (i.e., that the sender SSRC(s) may have
   changed) and MUST follow the above collision-resolution procedure if
   necessary.

   A receiver MAY use such Media Sender SSRC information when available
   but MUST beware of potential changes to the SSRC (which can only be
   learned from Sender Report (SR) packets).

7.5. Media Sender Behavior

Media Senders listen on a unicast or multicast transport address for RTCP reports sent by the receivers (and forwarded by the Distribution Source) or other Media Senders (optionally forwarded by the Distribution Source). Unlike in the case of the simple forwarding model, Media Senders MUST be able to process RSI packets from the Distribution Source to determine the group size and their own RTCP bandwidth share. Media Senders MUST also be capable of determining the group size (and their corresponding RTCP bandwidth share) from listening to (forwarded) RTCP RR and SR packets (as mandated in [1]). As long as they send RTP packets, they MUST also send RTCP SRs, as defined in [1]. A Media Sender that observes an SSRC collision with another entity that is not also a Media Sender MAY delay its own collision- resolution actions, as per [1], by 5 * 1.5 * Td, with Td being the deterministic calculated reporting interval, for receivers to see whether the conflict still exists. SSRC collisions with other Media Senders MUST be acted upon immediately. Note: This gives precedence to Media Senders and places the burden of collision resolution on RTP receivers. Sender SSRC information MAY be communicated out-of-band, e.g., by means of SDP media descriptions. Therefore, senders SHOULD NOT change their own SSRC eagerly or unnecessarily.
Top   ToC   RFC5760 - Page 36

8. Mixer/Translator Issues

The original RTP specification allows a session to use mixers and translators to help connect heterogeneous networks into one session. There are a number of issues, however, which are raised by the unicast feedback model proposed in this document. The term 'mixer' refers to devices that provide data stream multiplexing where multiple sources are combined into one stream. Conversely, a translator does not multiplex streams but simply acts as a bridge between two distribution mechanisms, e.g., a unicast-to-multicast network translator. Since the issues raised by this document apply equally to either a mixer or translator, the latter are referred to from this point onwards as mixer-translator devices. A mixer-translator between distribution networks in a session must ensure that all members in the session receive all the relevant traffic to enable the usual operation by the clients. A typical use may be to connect an older implementation of an RTP client with an SSM distribution network, where the client is not capable of unicasting feedback to the source. In this instance, the mixer- translator must join the session on behalf of the client and send and receive traffic from the session to the client. Certain hybrid scenarios may have different requirements.

8.1. Use of a Mixer-Translator

The mixer-translator MUST adhere to the SDP description [5] for the single-source session (Section 11) and use the feedback mechanism indicated. Implementers of receivers SHOULD be aware that when a mixer-translator is present in the session, more than one Media Sender may be active, since the mixer-translator may be forwarding traffic to the SSM receivers either from multiple unicast sources or from an ASM session. Receivers SHOULD still forward unicast RTCP reports in the usual manner to their assigned Feedback Target/Distribution Source, which in this case -- by assumption -- would be the mixer-translator itself. It is RECOMMENDED that the simple packet-reflection mechanism be used under these circumstances, since attempting to coordinate RSI + summarization reporting between more than one source may be complicated unless the mixer-translator is capable of summarization.

8.2. Encryption and Authentication Issues

Encryption and security issues are discussed in detail in Section 11. A mixer-translator MUST be able to follow the same security policy as the client in order to unicast RTCP feedback to the source, and it therefore MUST be able to apply the same authentication and/or encryption policy required for the session. Transparent bridging and
Top   ToC   RFC5760 - Page 37
   subsequent unicast feedback to the source, where the mixer-translator
   is not acting as the Distribution Source, is only allowed if the
   mixer-translator can conduct the same source authentication as
   required by the receivers.  A translator MAY forward unicast packets
   on behalf of a client but SHOULD NOT translate between multicast-to-
   unicast flows towards the source without authenticating the source of
   the feedback address information.

9. Transmission Interval Calculation

The Control Traffic Bandwidth referred to in [1] is an arbitrary amount that is intended to be supplied by a session-management application (e.g., SDR [21]) or decided based upon the bandwidth of a single sender in a session. The RTCP transmission interval calculation either remains the same as in the original RTP specification [1] or uses the algorithm in [10] when bandwidth modifiers have been specified for the session.

9.1. Receiver RTCP Transmission

If the Distribution Source is operating in Simple Feedback Model (which may be indicated in the corresponding session description for the media session but which the receiver also notices from the absence of RTCP RSI packets), a receiver MUST calculate the number of other members in a session based upon its own SSRC count, derived from the forwarded Sender and Receiver Reports it receives. The receiver MUST calculate the average RTCP packet size from all the RTCP packets it receives. If the Distribution Source is operating in Distribution Source Feedback Summary Model, the receiver MUST use either the group size field and the average RTCP packet size field or the Receiver Bandwidth field from the respective sub-report blocks appended to the RSI packet. A receiver uses these values as input to the calculation of the deterministic calculated interval as per [1] and [10].

9.2. Distribution Source RTCP Transmission

If operating in Simple Feedback Model, the Distribution Source MUST calculate the transmission interval for its Receiver Reports and associated RTCP packets, based upon the above control traffic bandwidth, and MUST count itself as RTP receiver. Receiver Reports will be forwarded as they arrive without further consideration. The Distribution Source MAY choose to validate that all or selected receivers roughly adhere to the calculated bandwidth constraints and
Top   ToC   RFC5760 - Page 38
   MAY choose to drop excess packets for receivers that do not.  In all
   cases, the average RTCP packet size is determined from the forwarded
   Media Senders' and receivers' RTCP packets and from those originated
   by the Distribution Source.

   If operating in Distribution Source Feedback Summary Model, the
   Distribution Source does not share the forward RTCP bandwidth with
   any of the receivers.  Therefore, the Distribution Source SHOULD use
   the full RTCP bandwidth for its Receiver Reports and associated RTCP
   packets, as well as RTCP RSI packets.  In this case, the average RTCP
   packet size is only determined from the RTCP packets originated by
   the Distribution Source.

   The Distribution Source uses these values as input to the calculation
   of the deterministic calculated interval as per [1] and [10].

9.3. Media Senders RTCP Transmission

In Simple Feedback Model, the Media Senders obtain all RTCP SRs and RRs as they would in an ASM session, except that the packets are forwarded by the Distribution Source. They MUST perform their RTCP group size estimate and calculation of the deterministic transmission interval as per [1] and [10]. In Distribution Source Feedback Summary Model, the Media Senders obtain all RTCP SRs as they would in an ASM session. They receive either RTCP RR reports as in ASM (in case these packets are forwarded by the Distribution Source) or RSI packets containing summaries. In the former case, they MUST perform their RTCP group size estimate and calculation of the deterministic transmission interval as per [1] and [10]. In the latter case, they MUST combine the information obtained from the Sender Reports and the RSI packets to create a complete view of the group size and the average RTCP packet size and perform the calculation of the deterministic transmission interval, as per [1] and [10], based upon these input values.

9.4. Operation in Conjunction with AVPF and SAVPF

If the RTP session is an AVPF session [15] or an SAVPF session [28] (as opposed to a regular AVP [6] session), the receivers MAY modify their RTCP report scheduling, as defined in [15]. Use of AVPF or SAVPF does not affect the Distribution Source's RTCP transmission or forwarding behavior. It is RECOMMENDED that a Distribution Source and possible separate Feedback Target(s) be configured to forward AVPF/SAVPF-specific RTCP packets in order to not counteract the damping mechanism built into AVPF; optionally, they MAY aggregate the feedback information from
Top   ToC   RFC5760 - Page 39
   the receivers as per Section 7.2.2.  If only generic feedback packets
   that are understood by the Distribution Source and that can easily be
   aggregated are in use, the Distribution MAY combine several incoming
   RTCP feedback packets and forward the aggregate along with its next
   RTCP RR/RSI packet.  In any case, the Distribution Source and
   Feedback Target(s) SHOULD minimize the extra delay when forwarding
   feedback information, but the Distribution Source MUST stay within
   its RTCP bandwidth constraints.

   In the event that specific APP packets without a format and
   summarization mechanism understood by the Feedback Target(s) and/or
   the Distribution Source are to be used, it is RECOMMENDED that such
   packets are forwarded with minimal delay.  Otherwise, the capability
   of the receiver to send timely feedback messages is likely to be
   affected.



(page 39 continued on part 3)

Next Section