doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc5506.txt b/doc/rfc/rfc5506.txt
new file mode 100644
index 0000000..6e9d84e
--- /dev/null
+++ b/doc/rfc/rfc5506.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                       I. Johansson
+Request for Comments: 5506                                 M. Westerlund
+Updates: 3550, 3711, 4585                                    Ericsson AB
+Category: Standards Track                                     April 2009
+
+
+ Support for Reduced-Size Real-Time Transport Control Protocol (RTCP):
+                     Opportunities and Consequences
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 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 in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson & Westerlund      Standards Track                     [Page 1]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+Abstract
+
+   This memo discusses benefits and issues that arise when allowing
+   Real-time Transport Protocol (RTCP) packets to be transmitted with
+   reduced size.  The size can be reduced if the rules on how to create
+   compound packets outlined in RFC 3550 are removed or changed.  Based
+   on that analysis, this memo defines certain changes to the rules to
+   allow feedback messages to be sent as Reduced-Size RTCP packets under
+   certain conditions when using the RTP/AVPF (Real-time Transport
+   Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585).
+   This document updates RFC 3550, RFC 3711, and RFC 4585.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................3
+   3. Use Cases and Design Rationale ..................................4
+      3.1. RTCP Compound Packets (Background) .........................4
+      3.2. Use Cases for Reduced-Size RTCP ............................6
+      3.3. Benefits of Reduced-Size RTCP ..............................7
+      3.4. Issues with Reduced-Size RTCP ..............................8
+           3.4.1. Middle Boxes ........................................9
+           3.4.2. Packet Validation ...................................9
+           3.4.3. Encryption/Authentication ..........................10
+           3.4.4. RTP and RTCP Multiplex on the Same Port ............10
+           3.4.5. Header Compression .................................11
+   4. Use of Reduced-Size RTCP with AVPF .............................11
+      4.1. Definition of Reduced-Size RTCP ...........................12
+      4.2. Algorithm Considerations ..................................12
+           4.2.1. Verification of Delivery ...........................12
+           4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP .....13
+           4.2.3. Enforcing Compound RTCP ............................13
+           4.2.4. Immediate Feedback Mode ............................14
+   5. Signaling ......................................................14
+   6. Security Considerations ........................................14
+   7. IANA Considerations ............................................14
+   8. Acknowledgements ...............................................15
+   9. References .....................................................15
+      9.1. Normative References ......................................15
+      9.2. Informative References ....................................16
+
+
+
+
+
+
+
+
+
+
+
+Johansson & Westerlund      Standards Track                     [Page 2]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+1.  Introduction
+
+   In RTP [RFC3550] it is currently mandatory to send RTP Control
+   Protocol (RTCP) packets as compound packets containing at least a
+   sender report (SR) or receiver report (RR), followed by a source
+   description (SDES) packet containing at least the CNAME item.  There
+   are good reasons for this, as discussed below (see Section 3.1);
+   however, it does result in the minimal RTCP packets being quite
+   large.
+
+   The RTP/AVPF profile [RFC4585] specifies new RTCP packet types for
+   feedback messages.  Some of these feedback messages would benefit
+   from being transmitted with minimal delay.  AVPF provides some
+   mechanisms to support this; however, for environments with low-
+   bitrate links, these messages can still consume a large amount of
+   resources and can introduce extra delay in the time it takes to
+   completely send the compound packet in the network.  It is therefore
+   desirable to send just the feedback, without the other parts of a
+   compound RTCP packet.  This memo proposes such a mechanism for this
+   and other use cases, as discussed in Section 3.2.
+
+   There are a number of benefits with Reduced-Size RTCP; these are
+   discussed in Section 3.3.
+
+   The use of Reduced-Size RTCP is not without issues.  This is
+   discussed in Section 3.4.  These issues need to be considered and are
+   part of the motivation for this document.
+
+   Finally, this document defines how AVPF is updated to allow for the
+   transmission of Reduced-Size RTCP in a way that would not
+   substantially affect the mechanisms that compound packets provide;
+   see Section 4 for more details.  The connection to AVPF (or SAVPF
+   [RFC5124]) is motivated by the fact that Reduced-Size RTCP is mainly
+   beneficial for event-driven feedback purposes and that the AVPF Early
+   RTCP and Immediate Feedback modes make this possible.
+
+   This document updates [RFC3550], [RFC3711], and [RFC4585].
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   The naming convention for RTCP is often confusing.  Below is a list
+   of RTCP terms and what they mean.  See also Section 6.1 in [RFC3550]
+   and Section 3.1 in [RFC4585] for details.
+
+
+
+
+Johansson & Westerlund      Standards Track                     [Page 3]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+   RTCP packet:  Can be of different types, contains a fixed header part
+      followed by structured elements depending on RTCP packet type.
+
+   Lower layer datagram:  Can be interpreted as the UDP payload.  It may
+      however, depending on the transport, be a TCP or Datagram
+      Congestion Control Protocol (DCCP) payload or something else.
+      Synonymous to the "underlying protocol" defined in Section 3 in
+      [RFC3550].
+
+   Compound RTCP packet:  A collection of two or more RTCP packets.  A
+      compound RTCP packet is transmitted in a lower-layer datagram.  It
+      must contain at least an RTCP RR or SR packet and an SDES packet
+      with the CNAME item.  Often "compound" is left out, the
+      interpretation of RTCP packet is therefore dependent on the
+      context.
+
+   Minimal compound RTCP packet:  A compound RTCP packet that contains
+      the RTCP RR or SR packet and the SDES packet with the CNAME item
+      with a specified ordering.
+
+   (Full) compound RTCP packet:  A compound RTCP packet that conforms to
+      the requirements on minimal compound RTCP packets and contains
+      more RTCP packets.
+
+   Reduced-Size RTCP packet:  May contain one or more RTCP packets but
+      does not follow the compound RTCP rules defined in Section 6.1 in
+      [RFC3550] and is thus neither a minimal nor a full compound RTCP.
+      See Section 4.1 for a full definition.
+
+3.  Use Cases and Design Rationale
+
+3.1.  RTCP Compound Packets (Background)
+
+   Section 6.1 in [RFC3550] specifies that an RTCP packet must be sent
+   as a compound RTCP packet consisting of at least two individual RTCP
+   packets, first a sender report (SR) or receiver report (RR), followed
+   by additional packets including a mandatory SDES packet containing a
+   CNAME item for the transmitting source identifier.  Below is a short
+   description of what these RTCP packet types are used for.
+
+   1.  The sender and receiver reports (see Section 6.4 of [RFC3550])
+       provide the RTP session participant with the synchronization
+       source (SSRC) identifier of all RTP session participants.  Having
+       all participants send these packets periodically allows everyone
+       to determine the current number of participants.  This
+       information is used in the transmission scheduling algorithm.
+       Thus, this is particularly important for new participants so that
+
+
+
+
+Johansson & Westerlund      Standards Track                     [Page 4]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+       they can quickly establish a good estimate of the group size.
+       Failure to do this would result in RTCP senders consuming too
+       much bandwidth.
+
+   2.  Before a new session participant has sent any RTP or RTCP packet,
+       it can also avoid SSRC collisions with all the SSRCs it sees
+       prior to that transmission.  So the possibility to see a
+       substantial proportion of the participating sources minimizes the
+       risk of any collision when selecting SSRC.
+
+   3.  The sender and receiver reports contain some basic statistics
+       usable for monitoring of the transport and thus enable
+       adaptation.  These reports become more useful if sent regularly,
+       as the receiver of a report can perform analyses to find trends
+       between the individual reports.  When used for media transmission
+       adaptation, the information becomes more useful the more
+       frequently it is received, at least until one report per round-
+       trip time (RTT) is achieved.  Therefore, there is, in most cases,
+       no reason not to include the sender or receiver report in all
+       RTCP packets.
+
+   4.  The CNAME SDES item (see Section 6.5.1 of [RFC3550]) exists to
+       allow receivers to determine which media flows should be
+       synchronized with each other, both within an RTP session and
+       between different RTP sessions carrying different media types.
+       Thus, it is important to quickly receive this for each media
+       sender in the session when joining an RTP session.
+
+   5.  Sender reports (SR) are used in combination with the above SDES
+       CNAME mechanism to synchronize multiple RTP streams, such as
+       audio and video.  After having determined which media streams
+       should be synchronized using the CNAME field, the receiver uses
+       the sender report's NTP and RTP timestamp fields to establish
+       synchronization.
+
+   6.  The CNAME SDES item also allows a session participant to detect
+       SSRC collisions and separate them from routing loops.  The 32-
+       bit, randomly selected SSRC has some probability of collision.
+       The CNAME is used as the longer canonical identifier of a
+       particular endpoint instance that is bound to an SSRC.  If that
+       binding isn't received and kept current, the receiver may not
+       detect an SSRC collision, i.e., two different CNAMEs using the
+       same SSRC.  It also can't detect an RTP-level routing loop, with
+       the result that the same SSRC and CNAME arrive from multiple
+       lower-layer source addresses.
+
+
+
+
+
+
+Johansson & Westerlund      Standards Track                     [Page 5]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+   Reviewing the above, it is obvious that both SR/RR and the CNAME are
+   very important in order for new session participants to be able to
+   utilize any received media and to avoid flooding the network with
+   RTCP reports.  In addition, the dynamic nature of the information
+   provided would make it less useful if not sent regularly.
+
+   The following sections will describe the cases when Reduced-Size RTCP
+   is beneficial and will also show the possible issues that must be
+   considered.
+
+3.2.  Use Cases for Reduced-Size RTCP
+
+   Below are listed a few use cases for Reduced-Size RTCP.
+
+   Control Plane Signaling:  The Open Mobile Alliance (OMA) Push-to-talk
+      over Cellular (PoC) [OMA-PoC] makes use of Reduced-Size RTCP when
+      transmitting certain events.  The OMA PoC service is primarily
+      used over cellular links capable of IP transport, such as the
+      Global System for Mobile Connections (GSM) General Packet Radio
+      Service (GPRS).
+
+   Codec Control Signaling:  An example that can be used with Reduced-
+      Size RTCP is, e.g., Temporary Maximum Media Stream Bitrate Request
+      (TMMBR) messages as specified in [RFC5104], which signal a request
+      for a change in codec bitrate.  These messages benefit from the
+      usage of Reduced-Size RTCP in bad channel conditions, as Reduced-
+      Size RTCP are much more likely to be successfully transmitted than
+      larger compound RTCP.  This is critical, as these messages are
+      likely to occur when channel conditions are poor.  Other examples
+      of codec control usage for Reduced-Size RTCP are found in
+      [MTSI-3GPP].
+
+   Feedback:  An example of a feedback scenario that would benefit from
+      Reduced-Size RTCP is Video streams with generic NACK.  In cases
+      where the RTT is shorter than the receiver buffer depth, generic
+      NACK can be used to request retransmission of missing packets,
+      thus improving playout quality considerably.  If the generic NACK
+      packets are transmitted as Reduced-Size RTCP, the bandwidth
+      requirement for RTCP will be minimal, enabling more frequent
+      feedback.  As in the codec control case, it is important that
+      these packets can be transmitted with as little delay as possible.
+      Another interesting use for Reduced-Size RTCP is in cases when
+      regular feedback is needed, as described in Section 3.3.
+
+   Status Reports:  One proposed idea is to transmit small measurement
+      or status reports in Reduced-Size RTCP, and to split the minimal
+      compound RTCP and transmit the individual RTCP separately.  The
+      status reports can be used either by the endpoints or by other
+
+
+
+Johansson & Westerlund      Standards Track                     [Page 6]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+      network monitoring boxes in the network.  The benefit is that,
+      with some radio access technologies, small packets are more robust
+      to poor radio conditions than large packets.  Additionally, with
+      small (report) packets, there is a smaller risk that the report
+      packets will affect the channel upon which they report.  Another
+      benefit is that it is possible, with Reduced-Size RTCP, to allow,
+      for example, anonymous status reporting to be transmitted
+      unencrypted.  This is something that may be beneficial, for
+      instance, for network monitoring purposes.
+
+3.3.  Benefits of Reduced-Size RTCP
+
+   As mentioned in the introduction, most advantages of using Reduced-
+   Size RTCP packets exist in cases when the available RTCP bitrate is
+   limited.  This is because they can become substantially smaller than
+   compound packets.  A compound packet is forced to contain both an RR
+   or an SR and the CNAME SDES item.  The RR containing a report block
+   for a single source is 32 bytes, an SR is 52 bytes.  Both may be
+   larger if they contain report blocks for multiple sources.  The SDES
+   packet containing a CNAME item will be 10 bytes plus the CNAME string
+   length.  Here, it is reasonable that the CNAME string is at least 10
+   bytes to get a decent collision resistance.  If the recommended form
+   of user@host is used, then most strings will be longer than 20
+   characters.  Thus, a Reduced-Size RTCP can become at least 70-80
+   bytes smaller than the compound packet.
+
+   For low bitrate links, the benefits of this reduction in size are as
+   follows:
+
+   o  For links where the packet-loss rate grows with the packet size,
+      smaller packets are less likely to be dropped.  Radio links are an
+      example of such links.  In the cellular world, there exist links
+      that are optimized to handle RTP packets sized for carrying
+      compressed speech.  This increases the capacity and coverage for
+      voice services in a given wireless network.  Minimal compound RTCP
+      packets are commonly 2-3 times the size of an RTP packet carrying
+      compressed speech.  If the speech packet over such a bearer has a
+      packet-loss probability of p, then the RTCP packet will experience
+      a loss probability of 1-(1-p)^x, where x is the number of
+      fragments the compound packet will be split into on the link
+      layer, i.e., commonly into 2 or 3 fragments.
+
+   o  There is a shorter serialization time, i.e., the time it takes the
+      link to transmit the packet.  For slower links, this time can be
+      substantial.  For example, transmitting 120 bytes over a link
+      interface capable of 30 kbps takes 32 milliseconds (ms), assuming
+      uniform transmission rate.
+
+
+
+
+Johansson & Westerlund      Standards Track                     [Page 7]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+   In cases when Reduced-Size RTCP carries important and time-sensitive
+   feedback, both shorter serialization time and the lower loss
+   probability are important to enable the best possible functionality.
+   Having a packet-loss rate that is much higher for the feedback
+   packets than the media packets hurts when trying to perform media
+   adaptation to, for example, handle the changed performance present at
+   the cell border in a cellular system.
+
+   For high-bitrate applications, there is usually no problem to supply
+   RTCP with sufficient bitrates.  When using AVPF, one can use the
+   "trr-int" parameter to restrict the regular reporting interval to
+   approximately once per RTT or less often.  As in most cases, there is
+   little reason to provide regular reports of higher density than this;
+   any additional bandwidth can then be used for feedback messages.  The
+   benefit of Reduced-Size RTCP in this case is limited, but exists.
+   One typical example is video using generic NACK in cases where the
+   RTT is low.  Using Reduced-Size RTCP would reduce the total amount of
+   bits used for RTCP.  This is primarily applicable if the number of
+   reports is large.  This would also result in lower processing delay
+   and less complexity for the feedback packets, as they do not need to
+   query the RTCP database to construct the right messages.
+
+   As message size is generally a smaller issue at higher bitrates, it
+   is also possible to transmit multiple RTCP in each lower-layer
+   datagram in these cases.  The motivation behind Reduced-Size RTCP in
+   this case is not size, rather it is to avoid the extra overhead
+   caused by inclusion of the SR/RR and SDES CNAME items in each
+   transmitted RTCP.
+
+   Independently of the link type, there are additional benefits with
+   sending feedback in small Reduced-Size RTCP.  Applications that use
+   RTCP AVPF in Early RTCP or Immediate Feedback mode need to send
+   frequent event-driven feedback.  Under these circumstances, the risk
+   is reduced that the RTCP bandwidth becomes too high during periods of
+   heavy feedback signaling.
+
+   In cases when regular feedback is needed, such as the profile under
+   development for TCP friendly rate control (TFRC) for RTP
+   [TCP-FRIEND], the size of compound RTCPs can result in very high
+   bandwidth requirements if the round-trip time is short.  For this
+   particular application, Reduced-Size RTCP gives a very substantial
+   improvement.
+
+3.4.  Issues with Reduced-Size RTCP
+
+   This section describes the known issues with Reduced-Size RTCP and
+   also provides a brief analysis of their effects and mitigation.
+
+
+
+
+Johansson & Westerlund      Standards Track                     [Page 8]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+3.4.1.  Middle Boxes
+
+   Middle boxes in the network may discard RTCP that do not follow the
+   rules outlined in Section 6.1 of RFC 3550.  Newer report types may be
+   interpreted as unknown by the middle box.  For instance, if the
+   payload type number is 207 instead of 200 or 201, it may be treated
+   as unknown.  The effect of this might, for instance, be that compound
+   RTCP would get through while the Reduced-Size RTCP would be lost.
+
+   Verification of the delivery of Reduced-Size RTCP is discussed in
+   Section 4.2.1.
+
+3.4.2.  Packet Validation
+
+   A Reduced-Size RTCP packet will be discarded by the packet validation
+   code in Appendix A of [RFC3550].  This has several impacts:
+
+   Weakened Packet Validation:  The packet validation code needs to be
+      rewritten to accept Reduced-Size RTCP.  In particular, this
+      affects Section 9.1 in [RFC3550] in the sense that the header
+      verification must take into account that the payload type numbers
+      for the (first) RTCP in the lower-layer datagram may differ from
+      200 or 201 (SR or RR).  One potential effect of this change is
+      much weaker validation that received packets actually are RTCP and
+      not packets of some other type being wrongly delivered.  Thus,
+      some consideration should be given to ensure the best possible
+      validation is available, for example, restricting Reduced-Size
+      RTCP to contain only some specific RTCP packet types that are
+      preferably signalled on a per-session basis.  However, the
+      application of a security mechanism for source authentication on
+      the packets will provide much stronger protection.
+
+   Old RTP Receivers:  Any RTCP receiver without an updated packet
+      validation code will discard the Reduced-Size RTCP, which means
+      that the receiver will not see e.g., the contained feedback
+      messages.  The effect of this depends on the type of feedback
+      message and the role of the receiver.  For example, this may cause
+      complete function loss in the case of attempting to send a
+      Reduced-Size NACK message (see Section 6.2.1 of [RFC4585]) to a
+      non-updated media sender in a session using the retransmission
+      scheme defined by [RFC4588].  This type of discarding would also
+      affect the feedback suppression defined in AVPF.  The result would
+      be a partitioning of the receivers within the session, with the
+      old receivers only seeing the compound RTCP feedback messages and
+      the newer ones seeing both.  In this case, the old receivers may
+      send feedback messages for events already reported on in Reduced-
+      Size RTCP.
+
+
+
+
+Johansson & Westerlund      Standards Track                     [Page 9]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+   Bandwidth Considerations:  The discarding of Reduced-Size RTCP would
+      affect the RTCP transmission calculation in that the avg_rtcp_size
+      value would become larger than for RTP receivers that exclude the
+      Reduced-Size RTCP in this calculation (assuming that Reduced-Size
+      RTCP are smaller than compound ones).  Therefore, these senders
+      would under-utilize the available bitrate and send with a longer
+      interval than updated receivers.  For most sessions, this should
+      not be an issue.  However, for sessions with a large portion of
+      Reduced-Size RTCP, the updated receivers may time out non-updated
+      senders prematurely.  This is, however, not likely to occur, as
+      the time between compound RTCP transmissions needs to become 5
+      times that used by the Reduced-Size RTCP senders for it to happen.
+
+   Computation of avg_rtcp_size:  Long intervals between compound RTCP
+      with many Reduced-Size RTCP in between may lead to a computation
+      of a value for avg_rtcp_size that varies greatly over time.
+      Investigation shows that although it varies, this is not enough of
+      a problem to warrant further changes or complexities to the RTCP
+      scheduling algorithm.
+
+3.4.3.  Encryption/Authentication
+
+   The Secure Real-time Transport Protocol (SRTP) presents a problem for
+   Reduced-Size RTCP.  Section 3.4 of [RFC3711] states, "SRTCP MUST be
+   given packets according to that requirement in the sense that the
+   first part MUST be a sender report or a receiver report".
+
+   Upon examination of how SRTP processes packets, it becomes obvious
+   that SRTP has no real dependency on whether the first packet is an SR
+   or an RR packet.  What is needed is the common RTCP packet header,
+   which is present in all the packet types, with a source SSRC.  The
+   conclusion is therefore that it is possible to use Reduced-Size RTCP
+   with SRTP.  Nevertheless, as this implies a change to the rules in
+   [RFC3711], changes in SRTP implementations MAY become necessary.
+
+3.4.4.  RTP and RTCP Multiplex on the Same Port
+
+   In applications in which multiplex RTP and RTCP are on the same port,
+   as defined in [MULTI-RTP], care must be taken to ensure that de-
+   multiplexing is done properly even though the RTCP packets are
+   reduced size.  The downside of Reduced-Size RTCP is that more values
+   representing RTCP packets exist, reducing the available RTP payload
+   type space.  However, Section 4 in [MULTI-RTP] already requires the
+   corresponding RTP payload type range not be used when performing this
+   multiplexing.
+
+
+
+
+
+
+Johansson & Westerlund      Standards Track                    [Page 10]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+3.4.5.  Header Compression
+
+   Two issues are related to header compression.  Possible changes are
+   left for future work:
+
+   o  Payload type number identification: The Robust Header Compression
+      (RoHC) algorithm [RFC3095] needs to create different compression
+      contexts for RTP and RTCP for optimum performance.  If RTP and
+      RTCP are multiplexed on the same port, the classification may be
+      based on payload type numbers.  The classification algorithm must
+      here acknowledge the fact that the payload type number for (the
+      first) RTCP may differ from 200 or 201.
+
+   o  Compression of RTCP: No IETF-defined header compression method
+      compress RTCP; however, if such methods are developed in the
+      future, these methods must take Reduced-Size RTCP in account.
+
+4.  Use of Reduced-Size RTCP with AVPF
+
+   Based on the above analysis, it seems feasible to allow transmission
+   of Reduced-Size RTCP under some restrictions:
+
+   o  First of all, it is important that compound RTCPs are transmitted
+      at regular intervals to ensure that the mechanisms maintained by
+      the compound packets, like feedback reporting, work.  The tracking
+      of session size and number of participants warrants mentioning
+      again, as this ensures that the RTCP bandwidth remains bounded
+      independent of the number of session participants.
+
+   o  Second, as the compound RTCP packets are also used to establish
+      and maintain synchronization between media, any newly joining
+      participant in a session would need to receive compound RTCP from
+      the media sender(s).
+
+   This implies that the regular transmission of compound RTCP MUST be
+   maintained throughout an RTP session.  Reduced-Size RTCP SHOULD be
+   restricted to be used as extra RTCP (e.g., feedback), sent in cases
+   when a regular compound RTCP packet would not otherwise have been
+   sent.
+
+   The usage of Reduced-Size RTCP SHALL only be done in RTP sessions
+   operating in AVPF [RFC4585] or SAVPF [RFC5124] Early RTCP or
+   Immediate Feedback mode.  Reduced-Size RTCP SHALL NOT be sent until
+   at least one compound RTCP has been sent.  In Immediate Feedback
+   mode, all feedback messages MAY be sent as Reduced-Size RTCP.  In
+   Early RTCP mode, a feedback message scheduled for transmission as an
+
+
+
+
+
+Johansson & Westerlund      Standards Track                    [Page 11]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+   Early RTCP, i.e., not a Regular RTCP, MAY be sent as Reduced-Size
+   RTCP.  All RTCP that are scheduled for transmission as Regular RTCP
+   SHALL be sent as compound RTCP as indicated by AVPF [RFC4585].
+
+4.1.  Definition of Reduced-Size RTCP
+
+   A Reduced-Size RTCP packet is an RTCP packet with the following
+   properties that make it deviate from the compound RTCP packet
+   definition given in Section 6.1 in [RFC3550]:
+
+   o  contains one or more RTCP packet(s)
+
+   o  allows any RTCP packet type; however, see Section 4.2.1
+
+   o  MUST NOT be used for Regular (scheduled) RTCP report purposes
+
+   o  MUST NOT be used with the RTP/AVP profile [RFC3551] or the
+      RTP/SAVP profile [RFC3711]
+
+4.2.  Algorithm Considerations
+
+4.2.1.  Verification of Delivery
+
+   If an application is to use Reduced-Size RTCP, it is important to
+   verify that the Reduced-Size RTCP packets actually reach the session
+   participants.  As outlined above in Section 3.4.1 and Section 3.4.2,
+   packets may be discarded along the path or in the endpoint.
+
+   A few verification rules are RECOMMENDED to ensure robust RTCP
+   transmission and reception and to solve the identified issues when
+   Reduced-Size RTCP is used:
+
+   o  The endpoint issue can be solved by introducing signaling that
+      informs if all session participants are capable of Reduced-Size
+      RTCP.  See Section 5.
+
+   o  The middle box issue is more difficult, and here one will be
+      required to use heuristics to determine whether or not the
+      Reduced-Size RTCP packets are delivered.  The method used to
+      detect successful delivery of Reduced-Size RTCP packets depends on
+      the packet type.  The RTCP packet types for which successful
+      delivery can be detected are:
+
+      *  Sender reports (SR): Successful transmission of a sender report
+         can be verified by inspection of the echoed timestamp in the
+         received receiver report (RR).  This can also be used as a
+         method to verify if Reduced-Size RTCP can be used at all.
+
+
+
+
+Johansson & Westerlund      Standards Track                    [Page 12]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+      *  Feedback RTCP packets: In many cases, the feedback messages
+         sent using Reduced-Size RTCP will result in either explicit or
+         implicit indications that they have been received.  An example
+         of this is the RTP retransmission [RFC4588] that results from a
+         NACK message [RFC4585].  Another example is the Temporary
+         Maximum Media Stream Bitrate Notification (TMMBN) message
+         resulting from a Temporary Maximum Media Stream Bitrate Request
+         (TMMBR) [RFC5104].  A third example is the presence of a
+         decoder refresh point [RFC5104] in the video media stream
+         resulting from the Full Intra Request that was sent.
+
+      RTCP packet types for which it is not possible to detect
+      successful delivery SHOULD NOT be transmitted as Reduced-Size RTCP
+      packets unless they are transmitted in the same lower-layer
+      datagram as another RTCP packet type for which successful delivery
+      can be detected.
+
+   o  An algorithm to detect consistent failure of delivery of Reduced-
+      Size RTCP MUST be used by any application using Reduced-Size RTCP.
+      The details of this algorithm are application dependent and
+      therefore outside the scope of this document.
+
+   If the verification fails, it is strongly RECOMMENDED that only
+   compound RTCP, according to the rules outlined in RFC 3550, is
+   transmitted.
+
+4.2.2.  Single vs Multiple RTCP in a Reduced-Size RTCP
+
+   The result of the definition in Section 4.1 may be that the resulting
+   size of Reduced-Size RTCP can become larger than a regularly
+   scheduled compound RTCP packet.  For applications that use access
+   types that are sensitive to packet size (see Paragraph 2 in
+   Section 3.3), it is strongly RECOMMENDED that the use of Reduced-Size
+   RTCP is limited to the transmission of a single RTCP packet in each
+   lower-layer datagram.  The method to determine the need for this is
+   outside the scope of this document.
+
+   In general, as the benefit with large Reduced-Size RTCP packets is
+   very limited, it is strongly RECOMMENDED to transmit large Reduced-
+   Size RTCP packets as compound RTCP packets instead.
+
+4.2.3.  Enforcing Compound RTCP
+
+   As discussed earlier, it is important that the transmission of
+   compound RTCP occurs at regular intervals.  However, this will occur
+   as long as the RTCP senders follow the AVPF scheduling algorithm
+
+
+
+
+
+Johansson & Westerlund      Standards Track                    [Page 13]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+   defined in Section 3.5 of [RFC4585].  This follows as all Regular
+   RTCP MUST be full compound RTCP.  Note that there is also a
+   requirement on sending Regular RTCP in Immediate Feedback mode.
+
+4.2.4.  Immediate Feedback Mode
+
+   Section 3.3 of [RFC4585] gives the option to use AVPF Immediate
+   Feedback mode as long as the group size is below a certain limit.  As
+   transmissions using Reduced-Size RTCP may reduce the bandwidth
+   demand, such transmissions also open up the possibility of a more
+   liberal use of Immediate Feedback mode.
+
+5.  Signaling
+
+   This document defines the "a=rtcp-rsize" Session Description Protocol
+   (SDP) [RFC4566] attribute to indicate if the session participant is
+   capable of supporting Reduced-Size RTCP for applications that use SDP
+   for configuration of RTP sessions.  It is REQUIRED that a participant
+   that proposes the use of Reduced-Size RTCP shall itself support the
+   reception of Reduced-Size RTCP.
+
+   An offering client that wishes to use Reduced-Size RTCP MUST include
+   the attribute "a=rtcp-rsize" in the SDP offer.  If "a=rtcp-rsize" is
+   present in the offer SDP, the answerer that supports Reduced-Size
+   RTCP and wishes to use it SHALL include the "a=rtcp-rsize" attribute
+   in the answer.
+
+   In declarative usage of SDP, such as the Real Time Streaming Protocol
+   (RTSP) [RFC2326] and the Session Announcement Protocol (SAP)
+   [RFC2974], the presence of the attribute indicates that the session
+   participant MAY use Reduced-Size RTCP packets in its RTCP
+   transmissions.
+
+6.  Security Considerations
+
+   The security considerations of RTP [RFC3550] and AVPF [RFC4585] will
+   apply also to Reduced-Size RTCP.  The reduction in validation
+   strength for received packets on the RTCP port may result in a higher
+   degree of acceptance of spurious data as real RTCP.  This
+   vulnerability can mostly be addressed by usage of any security
+   mechanism that provides authentication; one such mechanism is SRTP
+   [RFC3711].
+
+7.  IANA Considerations
+
+   Following the guidelines in [RFC4566], the IANA has registered a new
+   SDP attribute:
+
+
+
+
+Johansson & Westerlund      Standards Track                    [Page 14]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+   o  Contact name, email address, and telephone number: Authors of RFC
+      5506
+
+   o  Attribute-name: rtcp-rsize
+
+   o  Long-form attribute name: Reduced-Size RTCP
+
+   o  Type of attribute: media-level
+
+   o  Subject to charset: no
+
+   This attribute defines the support for Reduced-Size RTCP, i.e., the
+   possibility to transmit RTCP that does not conform to the rules for
+   compound RTCP defined in RFC 3550.  It is a property attribute, which
+   does not take a value.
+
+8.  Acknowledgements
+
+   The authors would like to thank all the people who gave feedback on
+   this document.  Special thanks go to Colin Perkins.
+
+   This document also contains some text copied from [RFC3550],
+   [RFC4585], and [RFC3711].  We take this opportunity to thank the
+   authors of said documents.
+
+9.  References
+
+9.1.  Normative References
+
+   [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.
+
+   [RFC3551]     Schulzrinne, H. and S. Casner, "RTP Profile for Audio
+                 and Video Conferences with Minimal Control", STD 65,
+                 RFC 3551, July 2003.
+
+   [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 2006.
+
+   [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.
+
+
+
+Johansson & Westerlund      Standards Track                    [Page 15]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+9.2.  Informative References
+
+   [MTSI-3GPP]   3GPP, "Specification : 3GPP TS 26.114 (v8.2.0 or
+                 later), http://www.3gpp.org/ftp/Specs/html-info/
+                 26-series.htm", March 2007.
+
+   [MULTI-RTP]   Perkins, C. and M. Westerlund, "Multiplexing RTP Data
+                 and Control Packets on a Single Port", Work
+                 in Progress, August 2007.
+
+   [OMA-PoC]     Open Mobile Alliance, "Specification : Push to talk
+                 Over Cellular User Plane, http://
+                 member.openmobilealliance.org/ftp/public_documents/poc/
+                 Permanent_documents/
+                 OMA-TS-PoC_UserPlane-V2_0-20080507-C.zip",
+                 November 2006.
+
+   [RFC2326]     Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
+                 Streaming Protocol (RTSP)", RFC 2326, April 1998.
+
+   [RFC2974]     Handley, M., Perkins, C., and E. Whelan, "Session
+                 Announcement Protocol", RFC 2974, October 2000.
+
+   [RFC3095]     Bormann, C., Burmeister, C., Degermark, M., Fukushima,
+                 H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,
+                 Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
+                 K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust
+                 Header Compression (ROHC): Framework and four profiles:
+                 RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
+
+   [RFC3711]     Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
+                 K. Norrman, "The Secure Real-time Transport Protocol
+                 (SRTP)", RFC 3711, March 2004.
+
+   [RFC4566]     Handley, M., Jacobson, V., and C. Perkins, "SDP:
+                 Session Description Protocol", RFC 4566, July 2006.
+
+   [RFC4588]     Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
+                 Hakenberg, "RTP Retransmission Payload Format",
+                 RFC 4588, July 2006.
+
+   [RFC5104]     Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
+                 "Codec Control Messages in the RTP Audio-Visual Profile
+                 with Feedback (AVPF)", RFC 5104, February 2008.
+
+   [TCP-FRIEND]  Gharai, L., "RTP with TCP Friendly Rate Control", Work
+                 in Progress, July 2007.
+
+
+
+
+Johansson & Westerlund      Standards Track                    [Page 16]
+
+RFC 5506            Reduced-Size RTCP in RTP Profile          April 2009
+
+
+Authors' Addresses
+
+   Ingemar Johansson
+   Ericsson AB
+   Laboratoriegrand 11
+   SE-971 28 Lulea
+   SWEDEN
+
+   Phone: +46 73 0783289
+   EMail: ingemar.s.johansson@ericsson.com
+
+
+   Magnus Westerlund
+   Ericsson AB
+   Faeroegatan 6
+   SE-164 80 Stockholm
+   SWEDEN
+
+   Phone: +46 10 7148287
+   EMail: magnus.westerlund@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson & Westerlund      Standards Track                    [Page 17]
+