Network Working Group S. Casner Request for Comments: 3556 Packet Design Category: Standards Track July 2003 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth 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) The Internet Society (2003). All Rights Reserved.
AbstractThis document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. RFC 3550 , includes a control protocol RTCP which provides synchronization information from data senders and feedback information from data receivers. Normally, the amount of bandwidth allocated to RTCP in an RTP session is 5% of the session bandwidth. For some applications, it may be appropriate to specify the RTCP bandwidth independently of the session bandwidth. Using a separate parameter allows rate-adaptive applications to set an RTCP bandwidth consistent with a "typical" data bandwidth that is lower than the maximum bandwidth specified by the session bandwidth parameter. That allows the RTCP bandwidth to be kept under 5% of the data bandwidth when the rate has been adapted downward. On the other hand, there may be applications that send data at very low rates but need to communicate extra RTCP information, such as APP packets. These applications may need to specify RTCP bandwidth that is higher than 5% of the data bandwidth.
The RTP specification allows a profile to specify that the RTCP bandwidth may be divided into two separate session parameters for those participants which are active data senders and those which are not. Using two parameters allows RTCP reception reports to be turned off entirely for a particular session by setting the RTCP bandwidth for non-data-senders to zero while keeping the RTCP bandwidth for data senders non-zero so that sender reports can still be sent for inter-media synchronization. Turning off RTCP reception reports is not recommended because they are needed for the functions listed in the RTP specification, particularly reception quality feedback and congestion control. However, doing so may be appropriate for systems operating on unidirectional links or for sessions that do not require feedback on the quality of reception or liveness of receivers and that have other means to avoid congestion. This memo defines an extension to the Session Description Protocol (SDP)  to specify RTCP bandwidth for senders and non-senders (receivers). figure, and where the default units for <bandwidth- value> are kilobits per second. This attribute specifies the proposed bandwidth to be used by the session or media. A typical use is with the modifier "AS" (for Application Specific Maximum) which may be used to specify the total bandwidth for a single media stream from one site (source). This memo defines two additional bandwidth modifiers: b=RS:<bandwidth-value> b=RR:<bandwidth-value> where "RS" indicates the RTCP bandwidth allocated to active data senders (as defined by the RTP spec) and "RR" indicates the RTCP bandwidth allocated to other participants in the RTP session (i.e., receivers). The exact behavior induced by specifying these bandwidth modifiers depends upon the algorithm used to calculate the RTCP reporting interval. Different algorithms may be specified by different RTP profiles.
For the RTP A/V Profile , which specifies that the default RTCP interval algorithm defined in the RTP spec  is to be used, at least RS/(RS+RR) of the RTCP bandwidth is dedicated to active data senders. If the proportion of senders to total participants is less than or equal to RS/(RS+RR), each sender gets RS divided by the number of senders. When the proportion of senders is greater than RS/(RS+RR), the senders get their proportion of the sum of these parameters, which means that a sender and a non-sender each get the same allocation. Therefore, it is not possible to constrain the data senders to use less RTCP bandwidth than is allowed for non-senders. A few special cases are worth noting: o If RR is zero, then the proportion of participants that are senders can never be greater than RS/(RS+RR), and therefore non-senders never get any RTCP bandwidth independent of the number of senders. o Setting RS to zero does not mean that data senders are not allowed to send RTCP packets, it only means that they are treated the same as non-senders. The proportion of senders (if there are any) would always be greater than RS/(RS+RR) if RR is non-zero. o If RS and RR are both zero, it would be unwise to attempt calculation of the fraction RS/(RS+RR). The bandwidth allocation specified by the RS and RR modifiers applies to the total bandwidth consumed by all RTCP packet types, including SR, RR, SDES, BYE, APP and any new types defined in the future. The <bandwidth-value> for these modifiers is in units of bits per second with an integer value. NOTE: This specification was in conflict with the initial SDP spec in RFC 2327 which prescribes that the <bandwidth-value> for all bandwidth modifiers should be an integer number of kilobits per second. This discrepancy was forced by the fact that the desired RTCP bandwidth setting may be less than 1 kb/s. At the 44th IETF meeting in Minneapolis, two solutions were considered: allow fractional values, or specify that the units for these particular modifiers would be in bits per second. The second choice was preferred so that the syntax would not be changed. The SDP spec is being modified  to advance to Draft Standard, and will allow this change in semantics.
RFC 3551 , the defaults follow the recommendations of the RTP spec: o The total RTCP bandwidth is 5% of the session bandwidth. If one of these RTCP bandwidth specifiers is omitted, its value is 5% minus the value of the other one, but not less than zero. If both are omitted, the sender and receiver RTCP bandwidths are 1.25% and 3.75% of the session bandwidth, respectively. o At least RS/(RS+RR) of of the RTCP bandwidth is dedicated to active data senders. When the proportion of senders is greater than RS/(RS+RR) of the participants, the senders get their proportion of the sum of these parameters. This memo does not impose limits on the values that may be specified with the RR and RS modifiers, other than that they must be non- negative. However, the RTP specification and the appropriate RTP profile may specify limits.
4) Default based on session bandwidth specifier at session level In particular, the relationship of (2) and (3) means that if the RR bandwidth is specified as zero at the session level, that turns off RTCP transmission for non-data-senders in all media.
RFC 2327  requires that new bandwidth modifiers be registered with IANA by reference to a standards-track RFC specifying the semantics of the bandwidth modifier precisely, indicating when it should be used, and why the existing registered bandwidth specifiers do not suffice. This document is intended to satisfy those requirements. In the "bwtype" table of the Session Description Protocol (SDP) Parameters registry, the following two new bandwidth modifier names have been registered: RS RR  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications," RFC 3550, July 2003.  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.  Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.