SDP RTCP Bandwidth: Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth
Two SDP modifiers, RS and RR, that set how much bandwidth RTCP may use for senders and for receivers.
Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, <https://www.rfc-editor.org/info/rfc3556>.
@misc{rfc3556,
series = {Request for Comments},
number = 3556,
howpublished = {RFC 3556},
publisher = {RFC Editor},
doi = {10.17487/RFC3556},
url = {https://www.rfc-editor.org/info/rfc3556},
author = {S. Casner},
title = {{Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth}},
pagetotal = 8,
year = 2003,
month = jul,
} RFC text
Contents
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.
Abstract
This 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.
1. Introduction
The Real-time Transport Protocol (RTP), RFC 3550 [1], 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) [3] to specify RTCP bandwidth for senders and non-senders
(receivers).
2. SDP Extensions
The Session Description Protocol includes an optional bandwidth
attribute with the following syntax:
b=<modifier>:<bandwidth-value>
where <modifier> is a single alphanumeric word giving the meaning of
the bandwidth 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 [2], which specifies that the default RTCP
interval algorithm defined in the RTP spec [1] 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 [4] to advance to Draft
Standard, and will allow this change in semantics.
3. Default values
If either or both of the RS and RR bandwidth specifiers are omitted,
the default values for these parameters are as specified in the RTP
profile in use for the session in question. For the Audio/Video
Profile, RFC 3551 [2], 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. Precedence
An SDP description consists of a session-level description (details
that apply to the whole session and all media streams) and zero or
more media-level descriptions (details that apply only to a single
media stream). Bandwidth specifiers may be present either at the
session level to specify the total bandwidth shared by all media, or
in the media sections to specify the bandwidth allocated to each
medium, or both. This is true for the two RTCP bandwidth modifiers
defined here as well.
Since the bandwidth allocated to RTCP is a fraction of the session
bandwidth when not specified explicitly using the modifiers defined
here, there is an interaction between the session bandwidth and RTCP
bandwidth specifiers at the session and media levels of the SDP
description. The precedence of these specifiers is as follows, with
(1) being the highest precedence:
1) Explicit RR or RS specifier at media level
2) Explicit RR or RS specifier at session level
3) Default based on session bandwidth specifier at media level
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.
5. Example
An example SDP description is:
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 0
b=AS:64
b=RS:800
b=RR:2400
m=video 51372 RTP/AVP 31
b=AS:256
b=RS:800
b=RR:2400
In this example, the explicit RTCP bandwidths for the audio medium
are equal to the defaults and so could be omitted. However, for the
video medium, the RTCP bandwidths have been set according to a data
bandwidth of 64 kb/s even though the maximum data bandwidth is
specified as 256 kb/s. This is based on the assumption that the
video data bandwidth will automatically adapt to a lower value based
on network conditions.
6. IANA Considerations
RFC 2327 [3] 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
7. Security Considerations
This memo defines bandwidth modifier keywords as an extension to SDP,
so the security considerations listed in the SDP specification apply
to session descriptions containing these modifiers as with any other.
The bandwidth value supplied with one of these modifiers could be
unreasonably large and cause the application to send RTCP packets at
an excessive rate, resulting in a denial of service. This is similar
to the risk that an unreasonable bandwidth could be specified for the
media data, though encoders generally have a limited bandwidth range.
Applications should apply validity checks to all parameters received
in an SDP description, particularly one which is not authenticated.
This memo cannot specify limits because they are dependent on the RTP
profile and application.
8. References
8.1 Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications," RFC 3550, July
2003.
[2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003.
[3] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
8.2 Informative References
[4] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
Description Protocol", Work in Progress.
9. Author's Address
Stephen L. Casner
Packet Design
3400 Hillview Avenue, Building 3
Palo Alto, CA 94304
United States
Phone: +1 650 739-1843
EMail: casner@acm.org
10. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§1Introduction
The Real-time Transport Protocol (RTP) includes a control protocol, RTCP, which provides synchronisation information from data senders and feedback information from data receivers. Normally the bandwidth allocated to RTCP in an RTP session is 5% of the session bandwidth.
For some applications it is right to specify the RTCP bandwidth independently of the session bandwidth. A rate-adaptive application can set an RTCP bandwidth consistent with the typical data bandwidth it expects, which is usually lower than the maximum the session description advertises, and that keeps the RTCP bandwidth under 5% of the data bandwidth once the rate has adapted downwards. Other applications send data at very low rates but need to pass extra RTCP information, such as APP packets, and those need an RTCP bandwidth higher than 5% of the data bandwidth.
The RTP specification also allows a profile to split the RTCP bandwidth into two parameters, one for participants that are active data senders and one for those that are not. Two parameters make it possible to turn RTCP reception reports off for a session by setting the bandwidth for non-data-senders to zero, while keeping the bandwidth for data senders non-zero so that sender reports can still be sent for inter-media synchronisation. The document notes that turning off reception reports is not recommended, because the RTP specification needs them for reception quality feedback and congestion control, but it may be appropriate for systems on unidirectional links, or for sessions that do not need feedback on reception quality or receiver liveness and have other means of avoiding congestion.
An RTP session carries media in one direction and control reports in the other. The control reports normally get 5% of the bandwidth. This RFC lets the application write that share into the session description instead, so it can match the share to what the session is really doing.
§2The RS and RR Bandwidth Modifiers
The Session Description Protocol has an optional bandwidth attribute with the syntax b=<modifier>:<bandwidth-value>, where the modifier is a single alphanumeric word and the default unit of the value is kilobits per second. A typical use is the modifier AS, for Application Specific Maximum, which gives the total bandwidth for a single media stream from one source.
This memo adds two more modifiers: b=RS:<bandwidth-value> for the RTCP bandwidth allocated to active data senders, and b=RR:<bandwidth-value> for the RTCP bandwidth allocated to the other participants in the session, that is the receivers. What the modifiers do in practice depends on the algorithm used to calculate the RTCP reporting interval, and different RTP profiles may specify different algorithms.
For the RTP A/V Profile, which uses the default RTCP interval algorithm from the RTP specification, at least RS/(RS+RR) of the RTCP bandwidth is dedicated to active data senders. If the proportion of senders among the 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, the senders get their proportion of the sum of the two parameters, which means that a sender and a non-sender each get the same allocation. It is therefore not possible to constrain the data senders to use less RTCP bandwidth than is allowed for non-senders.
Three special cases follow from that rule. If RR is zero, the proportion of participants that are senders can never be greater than RS/(RS+RR), so non-senders never get any RTCP bandwidth whatever the number of senders. 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. And if RS and RR are both zero, it would be unwise to attempt the calculation of the fraction RS/(RS+RR).
The session description now has two new lines for RTCP bandwidth. RS is the share for the participants that are sending media, and RR is the share for the ones that are only receiving. The document then works out how that total is divided when the numbers of senders and receivers do not match the values.
- ASApplication Specific Maximum — The total bandwidth for a single media stream from one source.
- RSRTCP bandwidth for senders — The RTCP bandwidth allocated to active data senders, in bits per second.
- RRRTCP bandwidth for receivers — The RTCP bandwidth allocated to the other participants in the RTP session, in bits per second.
§3Default Values
If either or both of the RS and RR specifiers are omitted, their default values come from the RTP profile in use for the session. For the Audio/Video Profile, RFC 3551, the defaults follow the recommendations of the RTP specification. The total RTCP bandwidth is 5% of the session bandwidth. If one of the two 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.
At least RS/(RS+RR) of the RTCP bandwidth is dedicated to active data senders, and when the proportion of senders is greater than RS/(RS+RR) of the participants, the senders get their proportion of the sum of these two parameters.
The memo does not impose limits on the values that may be specified with the RS and RR modifiers, other than that they must be non-negative, although the RTP specification and the relevant RTP profile may specify limits.
Leave the new lines out and you get the usual figures: 5% of the session bandwidth for RTCP in total, split into 1.25% for senders and 3.75% for receivers. If you write only one of the two, the other one takes whatever is left of the 5%, but never less than zero.
§4Precedence Between Specifiers
An SDP description consists of a session-level part, holding details that apply to the whole session and to all media streams, and zero or more media-level parts, each holding details that apply to a single media stream. Bandwidth specifiers may be present at the session level to give the total bandwidth shared by all media, or in the media sections to give the bandwidth allocated to each medium, or both. The same is true of the two RTCP bandwidth modifiers.
Because the RTCP bandwidth is a fraction of the session bandwidth when it is not set explicitly, the session bandwidth and the RTCP bandwidth specifiers interact. The document sets out the precedence, with the first entry having the highest:
- An explicit RR or RS specifier at media level.
- An explicit RR or RS specifier at session level.
- A default based on the session bandwidth specifier at media level.
- A default based on the session bandwidth specifier at session level.
One consequence of that order is that setting the RR bandwidth to zero at session level turns off RTCP transmission for non-data-senders in all media.
A session description can carry bandwidth figures in two places: once for the whole session, and once for each media stream. The document lists which one wins, from the most specific to the least. The practical effect is that a session-level RR of zero switches off control reports from receivers across every media stream.
- 1. Media level, explicitAn explicit RR or RS specifier at media level has the highest precedence.
- 2. Session level, explicitAn explicit RR or RS specifier at session level comes next.
- 3. Media level, defaultA default based on the session bandwidth specifier at media level comes next.
- 4. Session level, defaultA default based on the session bandwidth specifier at session level has the lowest precedence.
§5Example Session Description
The memo gives a complete example: an SDP description for a seminar, with an audio medium and a video medium. The audio medium sets b=AS:64 together with b=RS:800 and b=RR:2400, and the video medium sets b=AS:256 with the same two RTCP values.
In the audio medium the explicit RTCP bandwidths are equal to the defaults, so they could be left out. For the video medium the RTCP bandwidths are set as though the data bandwidth were 64 kb/s, even though the maximum data bandwidth is given as 256 kb/s. That is based on the assumption that the video data bandwidth will automatically adapt to a lower value as network conditions change.
The example is a seminar with an audio stream and a video stream. The video stream advertises a maximum of 256 kb/s but sets its RTCP budget to what it would be for a data rate of 64 kb/s, because the rate is expected to drop when the network gets busy.
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 0
b=AS:64
b=RS:800
b=RR:2400
m=video 51372 RTP/AVP 31
b=AS:256
b=RS:800
b=RR:2400§6IANA Considerations
RFC 2327 requires a new bandwidth modifier to be registered with IANA by reference to a standards-track RFC that specifies the semantics of the modifier precisely, indicates when it should be used, and explains why the existing registered bandwidth specifiers do not suffice. This document is written to satisfy those requirements.
Two new bandwidth modifier names have been registered in the bwtype table of the Session Description Protocol Parameters registry: RS and RR.
The two modifier names, RS and RR, are now recorded in the registry of SDP parameters, so other specifications can refer to them by name.
§7Security Considerations
The memo defines bandwidth modifier keywords as an extension to SDP, so the security considerations listed in the SDP specification apply to session descriptions carrying these modifiers as they do to any others.
It also warns that the bandwidth value supplied with one of the modifiers could be unreasonably large and cause the application to send RTCP packets at an excessive rate, resulting in a denial of service. That is similar to the risk of an unreasonable bandwidth being specified for the media data, though encoders generally have a limited bandwidth range. Applications should apply validity checks to all parameters received in an SDP description, particularly one that is not authenticated. The memo cannot specify limits itself, because they depend on the RTP profile and the application.
A session description can ask for an absurdly large RTCP budget, and an application that simply obeys it would flood the network with control reports. The advice is to check every value that arrives in a session description, especially one that has not been authenticated.