Network Working Group S. Casner
Request for Comments: 3556 Packet Design
Category: Standards Track July 2003
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
RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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.
本文档定义了会话描述协议（SDP）的扩展，以为带宽属性指定两个附加修饰符。这些修饰符可用于指定实时传输协议（RTP）会话中RTP控制协议（RTCP）数据包允许的带宽。
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.
实时传输协议（RTP）RFC 3550[1]包括一个控制协议RTCP，该协议提供来自数据发送方的同步信息和来自数据接收方的反馈信息。
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.
通常，RTP会话中分配给RTCP的带宽量为会话带宽的5%。对于某些应用程序，可以独立于会话带宽指定RTCP带宽。使用单独的参数允许速率自适应应用程序设置RTCP带宽，该带宽与低于会话带宽参数指定的最大带宽的“典型”数据带宽一致。当速率向下调整时，允许RTCP带宽保持在数据带宽的5%以下。
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.
另一方面，可能有一些应用程序以非常低的速率发送数据，但需要传输额外的RTCP信息，例如应用程序数据包。这些应用程序可能需要指定高于数据带宽5%的RTCP带宽。
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.
RTP规范允许配置文件指定RTCP带宽可分为两个单独的会话参数，用于活动数据发送方和非活动数据发送方的参与者。通过使用两个参数，可以将非数据发送方的RTCP带宽设置为零，同时将数据发送方的RTCP带宽保持为非零，从而完全关闭特定会话的RTCP接收报告，以便仍然可以发送发送方报告进行媒体间同步。不建议关闭RTCP接收报告，因为RTP规范中列出的功能需要这些报告，特别是接收质量反馈和拥塞控制。然而，这样做可能适用于在单向链路上运行的系统，或者适用于不需要对接收质量或接收器的活跃度进行反馈并且具有其他方法来避免拥塞的会话。
This memo defines an extension to the Session Description Protocol (SDP) [3] to specify RTCP bandwidth for senders and non-senders (receivers).
此备忘录定义了会话描述协议（SDP）[3]的扩展，以指定发送方和非发送方（接收方）的RTCP带宽。
The Session Description Protocol includes an optional bandwidth attribute with the following syntax:
会话描述协议包括具有以下语法的可选带宽属性：
b=<modifier>:<bandwidth-value>
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.
其中，<modifier>是给出带宽数字含义的单个字母数字单词，<bandwidth value>的默认单位为千位每秒。此属性指定会话或媒体要使用的建议带宽。
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).
典型的用法是使用修饰符“AS”（用于特定于应用程序的最大值），该修饰符可用于指定来自一个站点（源）的单个媒体流的总带宽。
This memo defines two additional bandwidth modifiers:
此备忘录定义了两个额外的带宽修饰符：
b=RS:<bandwidth-value>
b=RS:<bandwidth-value>
b=RR:<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.
其中，“RS”表示分配给活动数据发送方（由RTP规范定义）的RTCP带宽，“RR”表示分配给RTP会话中其他参与者（即接收器）的RTCP带宽。指定这些带宽修饰符所导致的确切行为取决于用于计算RTCP报告间隔的算法。不同的RTP配置文件可以指定不同的算法。
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:
对于指定使用RTP规范[1]中定义的默认RTCP间隔算法的RTP A/V配置文件[2]，至少有RS/（RS+RR）的RTCP带宽专用于活动数据发送器。如果发送者占参与者总数的比例小于或等于RS/（RS+RR），则每个发送者将得到RS除以发送者数量。当发送方的比例大于RS/（RS+RR）时，发送方获得这些参数之和的比例，这意味着发送方和非发送方各自获得相同的分配。因此，不可能限制数据发送方使用少于非发送方所允许的RTCP带宽。有几个特殊情况值得注意：
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 如果RR为零，则作为发送方的参与者的比例永远不能大于RS/（RS+RR），因此非发送方永远不会获得与发送方数量无关的任何RTCP带宽。
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 将RS设置为零并不意味着不允许数据发送方发送RTCP数据包，它只意味着它们被视为与非发送方相同。如果RR为非零，则发送方的比例（如果有）将始终大于RS/（RS+RR）。
o If RS and RR are both zero, it would be unwise to attempt calculation of the fraction RS/(RS+RR).
o 若RS和RR都为零，那个么尝试计算分数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.
RS和RR修饰符指定的带宽分配适用于所有RTCP数据包类型消耗的总带宽，包括SR、RR、SDES、BYE、APP和将来定义的任何新类型。这些修饰符的<bandwidth 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.
注：本规范与RFC 2327中的初始SDP规范相冲突，该规范规定所有带宽修饰符的<带宽值>应为每秒千位的整数。这种差异是由于所需RTCP带宽设置可能小于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.
在明尼阿波利斯举行的第44届IETF会议上，考虑了两种解决方案：允许分数值，或指定这些特定修饰符的单位为比特/秒。第二种选择是首选的，这样就不会改变语法。SDP规范正在修改[4]，以推进标准草案，并将允许语义上的这种变化。
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:
如果省略了RS和RR带宽说明符中的一个或两个，则这些参数的默认值将在有关会话使用的RTP配置文件中指定。对于音频/视频配置文件RFC 3551[2]，默认值遵循RTP规范的建议：
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 RTCP总带宽为会话带宽的5%。如果省略其中一个RTCP带宽说明符，其值为5%减去另一个的值，但不小于零。如果两者都省略，则发送方和接收方RTCP带宽分别为会话带宽的1.25%和3.75%。
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.
o 至少有RS/（RS+RR）的RTCP带宽专用于活动数据发送器。当发送者的比例大于参与者的RS/（RS+RR）时，发送者得到这些参数之和的比例。
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.
本备忘录不会对RR和RS修饰符指定的值施加限制，除非它们必须为非负值。然而，RTP规范和适当的RTP配置文件可能会规定限制。
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.
SDP描述包括会话级描述（适用于整个会话和所有媒体流的详细信息）和零个或多个媒体级描述（仅适用于单个媒体流的详细信息）。带宽说明符可以存在于会话级别以指定所有媒体共享的总带宽，或者存在于媒体部分以指定分配给每个媒体的带宽，或者两者都存在。这里定义的两个RTCP带宽修饰符也是如此。
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:
由于未使用此处定义的修饰符明确指定时，分配给RTCP的带宽是会话带宽的一小部分，因此会话带宽和SDP描述的会话和媒体级别的RTCP带宽说明符之间存在交互作用。这些说明符的优先级如下，（1）为最高优先级：
1) Explicit RR or RS specifier at media level
1) 媒体级别的显式RR或RS说明符
2) Explicit RR or RS specifier at session level
2) 会话级别的显式RR或RS说明符
3) Default based on session bandwidth specifier at media level
3) 基于媒体级会话带宽说明符的默认值
4) Default based on session bandwidth specifier at session level
4) 基于会话级别的会话带宽说明符的默认值
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.
具体而言，（2）和（3）的关系意味着，如果在会话级别将RR带宽指定为零，则关闭所有媒体中非数据发送方的RTCP传输。
An example SDP description is:
SDP描述示例如下：
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
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.
在本例中，音频介质的显式RTCP带宽等于默认值，因此可以省略。然而，对于视频介质，已根据64 kb/s的数据带宽设置RTCP带宽，即使最大数据带宽被指定为256 kb/s。这是基于视频数据带宽将根据网络条件自动适应较低值的假设。
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.
RFC 2327[3]要求通过引用标准跟踪RFC向IANA注册新的带宽修饰符，精确指定带宽修饰符的语义，指出何时应使用带宽修饰符，以及现有注册带宽修饰符不够的原因。
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:
在会话描述协议（SDP）参数注册表的“bwtype”表中，注册了以下两个新的带宽修饰符名称：
RS RR
RS RR
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.
此备忘录将带宽修饰符关键字定义为SDP的扩展，因此SDP规范中列出的安全注意事项适用于包含这些修饰符的会话描述，与其他任何会话描述一样。
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.
其中一个修饰符提供的带宽值可能过大，导致应用程序以过高的速率发送RTCP数据包，从而导致拒绝服务。这类似于为媒体数据指定不合理带宽的风险，尽管编码器通常具有有限的带宽范围。应用程序应将有效性检查应用于SDP描述中接收的所有参数，尤其是未经身份验证的参数。此备忘录无法指定限制，因为它们取决于RTP配置文件和应用程序。
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications," RFC 3550, July 2003.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC3550，2003年7月。
[2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[2] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 3551，2003年7月。
[3] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[3] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[4] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", Work in Progress.
[4] Handley，M.，Jacobson，V.和C.Perkins，“SDP：会话描述协议”，正在进行的工作。
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
Stephen L.Casner Packet Design美国加利福尼亚州帕洛阿尔托市Hillview大道3400号3号楼，邮编94304
Phone: +1 650 739-1843
EMail: casner@acm.org
Phone: +1 650 739-1843
EMail: casner@acm.org
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。