GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3556

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3556.txt · Last modified: 2003/07/28 18:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki