summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3556.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3556.txt')
-rw-r--r--doc/rfc/rfc3556.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3556.txt b/doc/rfc/rfc3556.txt
new file mode 100644
index 0000000..9c3ca31
--- /dev/null
+++ b/doc/rfc/rfc3556.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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.
+
+
+
+Casner Standards Track [Page 1]
+
+RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003
+
+
+ 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.
+
+
+
+Casner Standards Track [Page 2]
+
+RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003
+
+
+ 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.
+
+
+
+
+
+
+
+Casner Standards Track [Page 3]
+
+RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003
+
+
+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
+
+
+
+
+Casner Standards Track [Page 4]
+
+RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Casner Standards Track [Page 5]
+
+RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003
+
+
+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.
+
+
+
+
+
+Casner Standards Track [Page 6]
+
+RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Casner Standards Track [Page 7]
+
+RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Casner Standards Track [Page 8]
+