Network Working Group                                       I. Johansson
Internet-Draft                                             M. Westerlund
Intended status: Standards Track                             Ericsson AB
Expires: November 21, 2008                                  May 20, 2008

     Support for reduced size RTCP, opportunities and consequences

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 21, 2008.


   This memo discusses benefits and issues that arise when allowing RTCP
   packets to be transmitted with reduced size such that mandatory
   report types according to the rules outlined in RFC3550 are removed.
   Based on that analysis this memo proposes changes to the rules to
   allow feedback messages to be sent as reduced size RTCP packets when
   using the RTP AVPF profile (RFC 4585) under certain conditions.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in

Johansson & Westerlund  Expires November 21, 2008               [Page 1]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

Table of Contents

   1.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  RTCP Compound Packets  . . . . . . . . . . . . . . . . . . . .  4
   4.  Benefits with reduced size RTCP  . . . . . . . . . . . . . . .  5
     4.1.  Low birate links . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Higher bitrates  . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  Both high and low bitrate links  . . . . . . . . . . . . .  6
   5.  Use cases for reduced size RTCP  . . . . . . . . . . . . . . .  7
     5.1.  Control plane signaling  . . . . . . . . . . . . . . . . .  7
     5.2.  Codec control signaling  . . . . . . . . . . . . . . . . .  7
     5.3.  Feedback . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.4.  Status reports . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Issues with reduced size RTCP  . . . . . . . . . . . . . . . .  8
     6.1.  Middle boxes . . . . . . . . . . . . . . . . . . . . . . .  8
     6.2.  Packet Validation  . . . . . . . . . . . . . . . . . . . .  8
       6.2.1.  Old RTCP Receivers . . . . . . . . . . . . . . . . . .  9
       6.2.2.  Weakened Packet Validation . . . . . . . . . . . . . .  9
       6.2.3.  Bandwidth considerations . . . . . . . . . . . . . . .  9
       6.2.4.  Computation of avg_rtcp_size . . . . . . . . . . . . . 10
     6.3.  Encryption/authentication  . . . . . . . . . . . . . . . . 10
     6.4.  RTP and RTCP multiplex on the same port  . . . . . . . . . 10
     6.5.  Header compression . . . . . . . . . . . . . . . . . . . . 10
   7.  Rules and guidelines for non-compound packets in AVPF  . . . . 10
     7.1.  Definition of non-compound RTCP  . . . . . . . . . . . . . 11
     7.2.  Algorithm considerations . . . . . . . . . . . . . . . . . 11
       7.2.1.  Verification of delivery . . . . . . . . . . . . . . . 11
       7.2.2.  Single vs multiple RTCP in a reduced size RTCP . . . . 12
       7.2.3.  Enforcing compound RTCP  . . . . . . . . . . . . . . . 12
       7.2.4.  Immediate mode . . . . . . . . . . . . . . . . . . . . 12
     7.3.  SDP Signalling Attribute . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     11.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 17

Johansson & Westerlund  Expires November 21, 2008               [Page 2]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

1.  Glossary

   The naming convention for RTCP is often confusing.  Below a list of
   RTCP terms and what they mean.  See also section 6.1 in [RFC3550] and
   section 3.1 in [RFC4585] for details.

   o  RTCP packet: Can be of different types, contains a fixed header
      part followed by structured elements depending on RTCP packet

   o  Lower layer datagram: Can be interpreted as the UDP payload, it
      may however, depending on the transport be TCP or DCCP payload or
      something else.  Synonymous to "underlying protocol" defined in 3
      in [RFC3550].

   o  Compound RTCP: A collection of two or more RTCP packets.  A
      compound RTCP is transmitted in a lower layer datagram.  It must
      contain at least an RTCP RR or SR packet and a SDES packet with
      the CNAME item.  Often "compound" is left out, the interpretation
      of the word RTCP is therefore dependent on the context.

   o  Minimal compound RTCP: A compound RTCP that contains the RTCP RR
      or SR packets and the SDES packet with the CNAME item with a
      specified ordering.

   o  (Full) compound RTCP: A compound RTCP that conforms to the
      requirements on minimal compound RTCP packets and contains more
      RTCP packets.

   o  Reduced size RTCP: May contain one or more RTCP packets but does
      not follow the minimal compound RTCP rules defined in section 6.1
      in [RFC3550].

2.  Introduction

   In RTP [RFC3550] it is currently mandatory to always use RTCP
   compound packets containing at least Sender Reports or Receiver
   reports, and a SDES packet containing at least the CNAME item.  There
   are good reasons for this as discussed below (see Section 3).
   However this do result in that the minimal RTCP packets are quite
   The RTP profile AVPF [RFC4585] specifies new RTCP packet types for
   feedback messages.  Some of these feedback messages would benefit
   from being transmitted with minimal delay and AVPF do provide some
   mechanism to enable this.
   However for environments with low-bitrate links this still consumes
   quite a large amount of resources and introduces extra delay in the

Johansson & Westerlund  Expires November 21, 2008               [Page 3]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

   time it takes to completely send the compound packet in the network.
   There are also other benefits as discussed in Section 4.

   The use of reduced size RTCP is not without issues.  This is
   discussed in Section 6.  These issues needs to be considered and are
   part of the motivation for this document.

   In addition this document proposes how AVPF could be updated to allow
   the transmission of reduced size RTCP in a way that would not
   substantially affect the mechanisms that compound packets provide.
   The connection to AVPF is motivated by the fact that reduced size
   RTCP is mainly intended for event driven feedback purposes and that
   the AVPF early and immediate modes make this possible.

3.  RTCP Compound Packets

   Section 6.1 in [RFC3550] specifies that an RTCP packet must be sent
   as a compound RTCP consisting of at least two individual RTCP, first
   an 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 (SSRC).  Below is a short
   description what these RTCP packet types are used for.

   1.  The sender and receiver reports (see Section 6.4 of [RFC3550])
       provides the RTP session participant with the Sender Source
       Identifier (SSRC) of all RTCP senders.  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 they quickly can establish
       a good estimate of the group size.  Failure to do this would
       result in RTCP senders consuming too much bandwidth.

   2.  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 analysis to find trends
       between the individual reports.  When used for media transmission
       adaptation the information become more useful the more frequently
       it is received, at least until one report per round-trip time
       (RTT) is achieved.  Therefore there are, in most cases, no reason
       to not include the sender or receiver report in all RTCP packets.

   3.  The CNAME SDES item (See Section 6.5.1 of [RFC3550]) exists to
       allow receivers to determine which media flows that should be
       synchronized with each other between different RTP sessions
       carrying different media types.  Thus it is important to quickly

Johansson & Westerlund  Expires November 21, 2008               [Page 4]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

       receive this for each media sender in the session when joining an
       RTP session.

   4.  Sender Reports (SR) is 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

   Reviewing the above it is obvious that both SR/RR and the CNAME are
   very important for new session participants to be able to utilize any
   received media and to avoid flooding the network with RTCP reports.
   In addition, if not sent regularly the dynamic nature of the
   information provided would make it less and less useful.

4.  Benefits with reduced size RTCP

   As mentioned in the introduction, most advantages of using reduced
   size RTCP packets exists in cases when the available RTCP bitrate is
   limited.  This 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.

   The following benefits exist for reduced size RTCP,

4.1.  Low birate links

   For low bitrate links the benefits are as follows.

   o  For links where the packet loss rate grows with the packet size,
      smaller packets are be less likely to be dropped.  An example of
      such links are radio 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 a 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

Johansson & Westerlund  Expires November 21, 2008               [Page 5]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

      a loss probability of 1-(1-p)^x where x is the number of fragments
      the compound packet will be split on the link layer, i.e. commonly
      into 2 or 3 fragments.

   o  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 an link
      interface capable of 30 kbps takes 32 milliseconds (ms) assuming
      uniform transmission rate.

   In cases when reduced size RTCP carry 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 compared to 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.

4.2.  Higher bitrates

   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 with 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

   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.

4.3.  Both high and low bitrate links

   Independently of the link type there are additional benefits with
   sending feedback in small reduced size RTCP.

Johansson & Westerlund  Expires November 21, 2008               [Page 6]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

   o  Applications that use RTCP AVPF in early or immediate mode to send
      frequent event driven feedback.  Under these circumstances, the
      risk that the RTCP bandwidth becomes too high during periods of
      heavy adaptation feedback signaling is reduced.

   o  In cases when regular feedback is needed, such as the profile
      under development for TCP friendly rate control (TFRC) for RTP
      [I-D.ietf-avt-tfrc-profile], the size of compound RTCP 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.

5.  Use cases for reduced size RTCP

   Below are listed a few use cases for reduced size RTCP.  The current
   use of reduced size RTCP is very application specific.  A general
   definition of the use of it for e.g control plane or codec control
   signaling would probably need to be specified in the IETF.

5.1.  Control plane signaling

   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 GSM GPRS.

5.2.  Codec control signaling

   Examples of codec control usage for reduced size RTCP are found in

   Another example that can be used with reduced size RTCP is e.g TMMBR
   messages as specified in [RFC5104] which signal a request for a
   change in codec bitrate.  The benefit of its use for these messages
   is that in bad channel conditions as they are much more likely to be
   successfully received than larger compound RTCP.  This is critical as
   these messages are likely to occur when channel conditions are poor.

5.3.  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.  Like in the Codec control

Johansson & Westerlund  Expires November 21, 2008               [Page 7]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

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

5.4.  Status reports

   One proposed idea is to transmit small measurement or status reports
   in reduced size RTCP, and to be able 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 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 that they report

   Another benefit is that it is, with reduced size RTCP, possible to
   allow e.g anonymous status reporting to be transmitted unencrypted.
   Something that may be beneficial for e.g network monitoring purposes.

6.  Issues with reduced size RTCP

   This section describes the known issues with reduced size RTCP and
   also a brief analysis.

6.1.  Middle boxes

   Middle boxes in the network may discard RTCP that do not follow the
   rules outlined in section 6.1 of RFC3550.  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 7.2.1.

6.2.  Packet Validation

   A reduced size RTCP will be discarded by the packet validation code
   in Appendix A of [RFC3550].  This has several impacts as described in
   the following sub sections.

Johansson & Westerlund  Expires November 21, 2008               [Page 8]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

6.2.1.  Old RTCP Receivers

   Any RTCP receiver without 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
   use a reduced size NACK message (see Section 6.2.1 of [RFC4585]) to
   non updated media sender in a session using the retransmission scheme
   defined by [RFC4588].

   This type of discarding would also effect the feedback suppression
   defined in AVPF.  The result would be a partitioning of the receivers
   within the session between old ones only seeing the compound RTCP
   feedback messages and the newer ones seeing both.  Where the old ones
   may send feedback messages for events already reported on in reduced
   size RTCP.

6.2.2.  Weakened Packet Validation

   The packet validation code needs to be rewritten to accept reduced
   size RTCP.  This in particular 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 done
   to ensure the best possible validation is available.  For example
   restricting reduced size RTCP to contain only some specific RTCP
   packet types, that is preferably signalled on a session basis.

6.2.3.  Bandwidth considerations

   The discarding of reduced size RTCP would effect the RTCP
   transmission calculation in the following way: 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 may result in that the updated receivers time out non-updated
   senders prematurely.  A solution to this is presented in Section 7.2.

Johansson & Westerlund  Expires November 21, 2008               [Page 9]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

6.2.4.  Computation of avg_rtcp_size

   Long intervals between compound RTCP and many reduced size RTCP in
   between may lead to a computation of a value for avg_rtcp_size that
   varies greatly over time.  This is discussed more in Section 7.2.

6.3.  Encryption/authentication

   SRTP presents a problem for reduced size RTCP.  Section 3.4 in
   [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".

   However the same text also states that the encryption prefix that is
   present in the receiver and sender reports should not be used by
   SRTP.  The conclusion is therefore that it is possible to use reduced
   size RTCP with SRTP.

6.4.  RTP and RTCP multiplex on the same port

   In applications which multiplex RTP and RTCP on the same port, as
   defined in [I-D.ietf-avt-rtp-and-rtcp-mux], care must be taken to
   ensure that the de-multiplexing is done properly even though RTCP are
   reduced size.

6.5.  Header compression

   Two issues are related to header compression:

   o  Payload type number identification: The RoHC header compression
      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.

7.  Rules and guidelines for non-compound packets in AVPF

   Based on the above analysis it seems feasible to allow transmission
   of reduced size RTCP under some restrictions.

   First of all it is important that compound RTCP are transmitted at

Johansson & Westerlund  Expires November 21, 2008              [Page 10]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

   regular intervals to ensure that the feedback reporting works.  The
   tracking of session size and number of participants is also important
   as this ensures that the RTCP bandwidth remain bounded independent of
   the number of session participants.

   As the compound RTCP 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).

   In summary the regular usage of compound RTCP must be maintained
   throughout the complete session.  Thus reduced size RTCP should be
   restricted to be used as extra RTCP (e.g feedback) sent in cases when
   a regular compound RTCP would not have been sent.

   The usage of reduced size RTCP SHALL only be done in RTP sessions
   operating in AVPF [RFC4585] Early or Immediate mode.  Reduced size
   RTCP SHALL NOT be sent until at least one compound RTCP has been
   sent.  In Immediate mode all feedback messages MAY be sent as reduced
   size RTCP.  In early mode a feedback message scheduled for
   transmission as an 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 (full) compound RTCP as indicated by
   AVPF [RFC4585].

7.1.  Definition of non-compound RTCP

   A reduced size RTCP deviates from the rules regarding (minimal)
   compound RTCP given in RFC3550/4585 in the aspect that they don't
   contain both the mandatory elements SR/RR and SDES-CNAME.  The
   definition does not make any distinction based on size.  This means
   that it is possible to transmit multiple RTCP in one lower layer

7.2.  Algorithm considerations

7.2.1.  Verification of delivery

   If an application is to use reduced size RTCP it is important to
   verify that they actually reach the session participants.  As
   outlined above in Section 6.1 and Section 6.2 packets may be
   discarded along the path or in the end-point.

   The end-points can be resolved by introducing signaling that informs
   if all session participants are capable of reduced size RTCP.

   The middle box issue is more difficult and here one will be required
   to use heuristics to determine if the reduced size RTCP are delivered
   or not.  However in many cases the feedback messages sent using

Johansson & Westerlund  Expires November 21, 2008              [Page 11]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

   reduced size RTCP will result in either explicit or implicit
   indications that they have been received.  Example of such are the
   RTP retransmission [RFC4588] that result from a NACK message
   [RFC4585], the Temporary Maximum Media Bitrate Notification message
   resulting from a Temporary Maximum Media Bitrate Request [RFC5104],
   or the presence of a Decoder Refresh Point [RFC5104] in the video
   media stream resulting from the Full Intra Request sent.

   An algorithm to detect consistent failure of delivery of reduced size
   RTCP must be used by any application using it.  The details of this
   algorithm is application dependent and therefore outside the scope of
   this document.

   A method to detect if reduced size RTCP are discarded is to send a
   single SR packet in a lower layer datagram, then check that the
   timestamp is echoed back in the corresponding RR packet.  This
   verification method is not completely safe however as it SR is still
   one of the expected packet types.

   If the verification fails it is strongly RECOMMENDED that only
   compound RTCP according to the rules outlined in RFC3550 is

7.2.2.  Single vs multiple RTCP in a reduced size RTCP

   The result of the definition in Section 7.1 may be that the resulting
   size of reduced size RTCP can become larger than a normal compound
   RTCP.  For applications that use access types that are sensitive to
   packet size (see Section 4.1) it is strongly RECOMMENDED that the use
   of reduced size RTCP is limited to the transmission of single RTCP in
   each lower layer datagram.

   The methods to determine the need for this is outside the scope of
   this draft.

7.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
   defined in Section 3.5 in [RFC4585].  This as all regular RTCP must
   be full compound RTCP.  Note that also in immediate mode is there a
   requirement on sending regular RTCP.

7.2.4.  Immediate mode

   Section 3.3 in RFC4585 gives the option to use AVPF Immediate mode as
   long as the groupsize is below a certain limit.  As transmission

Johansson & Westerlund  Expires November 21, 2008              [Page 12]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

   using reduced size RTCP may become reduce the bandwidth demand it
   opens up for a more liberal use of immediate mode.

7.3.  SDP Signalling Attribute

   We request to define the "a=rtcp-rsize" [RFC4566] attribute to
   indicate if the session participant is capable of supporting reduced
   size RTCP.  It is a required that a participant that proposes the use
   of reduced size RTCP itself supports the reception of reduced size

   An offering client that wish 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 wish to use it SHALL include the "a=rtcp-rsize" attribute in
   the answer.

8.  IANA Considerations

   Following the guidelines in [RFC4566], the IANA is requested to
   register one new SDP attribute:

   o  Contact name, email address and telephone number: Authors of

   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
   compund RTCP defined in RFC3550.  It is a property attribute, which
   does not take a value.

   Note to RFC Editor: please replace "RFC XXXX" above with the RFC
   number of this memo, and remove this note.

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

Johansson & Westerlund  Expires November 21, 2008              [Page 13]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

   degree of acceptance of spurious data as real RTCP.  This
   vulnerability can mostly be addressed by usage of any security
   mechanism that provide authentication, one example such mechanism is
   SRTP [RFC3711].

10.  Acknowledgements

   The authors would like to thank all the people who gave feedback on
   this document.

   This document also contain some text copied from [RFC3550],
   [RFC4585]and [RFC3711].  We take the opportunity to thank the authors
   of said documents.

11.  References

11.1.  Normative References

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, 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.

11.2.  Informative References

              3GPP, "Specification : 3GPP TS 26.114 (v7.4.0), http://
    ", March 2007.

              Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port",
              draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
              August 2007.

              Gharai, L., "RTP with TCP Friendly Rate Control",
              draft-ietf-avt-tfrc-profile-10 (work in progress),
              July 2007.

   [OMA-PoC]  Open Mobile Alliance, "Specification : Push to talk Over

Johansson & Westerlund  Expires November 21, 2008              [Page 14]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

              Cellular User Plane,
              November 2006.

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

Authors' Addresses

   Ingemar Johansson
   Ericsson AB
   Laboratoriegrand 11
   SE-971 28 Lulea

   Phone: +46 73 0783289

Johansson & Westerlund  Expires November 21, 2008              [Page 15]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

   Magnus Westerlund
   Ericsson AB
   Torshamnsgatan 21-23
   SE-164 83 Stockholm

   Phone: +46 8 7190000
   Email: magnus.westerlund (AT)

Johansson & Westerlund  Expires November 21, 2008              [Page 16]

Internet-Draft      Reduced size RTCP in RTP profile            May 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Johansson & Westerlund  Expires November 21, 2008              [Page 17]