Network Working Group M. Westerlund
Request for Comments: 3890 Ericsson
Category: Standards Track September 2004
Network Working Group M. Westerlund
Request for Comments: 3890 Ericsson
Category: Standards Track September 2004
A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)
会话描述协议（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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document defines a Session Description Protocol (SDP) Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used.
本文档定义了一个会话描述协议（SDP）传输独立的应用程序特定最大（TIAS）带宽修饰符，该修饰符不包括传输开销；而是定义了一个附加的数据包速率属性。然后，可以使用与传输无关的比特率值以及最大分组速率来计算实际使用的传输上的实际比特率。
The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), and the Real-Time Streaming Protocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear.
现有SDP带宽修饰符及其值包括传输层和IP层所需的带宽。当将SDP与诸如会话公告协议（SAP）、会话发起协议（SIP）和实时流协议（RTSP）等协议一起使用时，以及当涉及的主机具有不同的传输开销（例如由于不同的IP版本）时，对包括哪些较低层带宽的解释并不清楚。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Bandwidth Attribute. . . . . . . . . . . . . . . . . 3
1.1.1. Conference Total . . . . . . . . . . . . . . . . 3
1.1.2. Application Specific Maximum . . . . . . . . . . 3
1.1.3. RTCP Report Bandwidth. . . . . . . . . . . . . . 4
1.2. IPv6 and IPv4. . . . . . . . . . . . . . . . . . . . . . 4
1.3. Further Mechanisms that Change the Bandwidth
Utilization. . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. IPsec. . . . . . . . . . . . . . . . . . . . . . 5
1.3.2. Header Compression . . . . . . . . . . . . . . . 5
2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 6
3. The Bandwidth Signaling Problems . . . . . . . . . . . . . . . 6
3.1. What IP Version is Used. . . . . . . . . . . . . . . . . 6
3.2. Taking Other Mechanisms into Account . . . . . . . . . . 7
3.3. Converting Bandwidth Values. . . . . . . . . . . . . . . 8
3.4. RTCP Problems. . . . . . . . . . . . . . . . . . . . . . 8
3.5. Future Development . . . . . . . . . . . . . . . . . . . 9
3.6. Problem Conclusion . . . . . . . . . . . . . . . . . . . 9
4. Problem Scope. . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 11
6.2. The TIAS Bandwidth Modifier. . . . . . . . . . . . . . . 11
6.2.1. Usage. . . . . . . . . . . . . . . . . . . . . . 11
6.2.2. Definition . . . . . . . . . . . . . . . . . . . 12
6.2.3. Usage Rules. . . . . . . . . . . . . . . . . . . 13
6.3. Packet Rate Parameter. . . . . . . . . . . . . . . . . . 13
6.4. Converting to Transport-Dependent Values . . . . . . . . 14
6.5. Deriving RTCP bandwidth. . . . . . . . . . . . . . . . . 15
6.5.1. Motivation for this Solution. . . . . . . . . . . 15
6.6. ABNF Definitions . . . . . . . . . . . . . . . . . . . . 16
6.7. Example. . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Protocol Interaction . . . . . . . . . . . . . . . . . . . . . 17
7.1. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. SAP. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 19
12. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Bandwidth Attribute. . . . . . . . . . . . . . . . . 3
1.1.1. Conference Total . . . . . . . . . . . . . . . . 3
1.1.2. Application Specific Maximum . . . . . . . . . . 3
1.1.3. RTCP Report Bandwidth. . . . . . . . . . . . . . 4
1.2. IPv6 and IPv4. . . . . . . . . . . . . . . . . . . . . . 4
1.3. Further Mechanisms that Change the Bandwidth
Utilization. . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. IPsec. . . . . . . . . . . . . . . . . . . . . . 5
1.3.2. Header Compression . . . . . . . . . . . . . . . 5
2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 6
3. The Bandwidth Signaling Problems . . . . . . . . . . . . . . . 6
3.1. What IP Version is Used. . . . . . . . . . . . . . . . . 6
3.2. Taking Other Mechanisms into Account . . . . . . . . . . 7
3.3. Converting Bandwidth Values. . . . . . . . . . . . . . . 8
3.4. RTCP Problems. . . . . . . . . . . . . . . . . . . . . . 8
3.5. Future Development . . . . . . . . . . . . . . . . . . . 9
3.6. Problem Conclusion . . . . . . . . . . . . . . . . . . . 9
4. Problem Scope. . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 11
6.2. The TIAS Bandwidth Modifier. . . . . . . . . . . . . . . 11
6.2.1. Usage. . . . . . . . . . . . . . . . . . . . . . 11
6.2.2. Definition . . . . . . . . . . . . . . . . . . . 12
6.2.3. Usage Rules. . . . . . . . . . . . . . . . . . . 13
6.3. Packet Rate Parameter. . . . . . . . . . . . . . . . . . 13
6.4. Converting to Transport-Dependent Values . . . . . . . . 14
6.5. Deriving RTCP bandwidth. . . . . . . . . . . . . . . . . 15
6.5.1. Motivation for this Solution. . . . . . . . . . . 15
6.6. ABNF Definitions . . . . . . . . . . . . . . . . . . . . 16
6.7. Example. . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Protocol Interaction . . . . . . . . . . . . . . . . . . . . . 17
7.1. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. SAP. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 19
12. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
This specification is structured in the following way: In this section, some information regarding SDP bandwidth modifiers, and different mechanisms that affect transport overhead are asserted. In section 3, the problems found are described, including problems that are not solved by this specification. In section 4 the scope of the problems this specification solves is presented. Section 5 contains the requirements applicable to the problem scope. Section 6 defines the solution, which is a new bandwidth modifier, and a new maximum packet rate attribute. Section 7 looks at the protocol interaction for SIP, RTSP, and SAP. The security considerations are discussed in section 8. The remaining sections are the necessary IANA considerations, acknowledgements, reference list, author's address, and copyright and IPR notices.
本规范的结构如下：在本节中，声明了有关SDP带宽修饰符和影响传输开销的不同机制的一些信息。第3节描述了发现的问题，包括本规范未解决的问题。第4节介绍了本规范所解决问题的范围。第5节包含适用于问题范围的要求。第6节定义了解决方案，它是一个新的带宽修饰符和一个新的最大分组速率属性。第7节介绍SIP、RTSP和SAP的协议交互。第8节讨论了安全注意事项。其余部分是IANA的必要注意事项、确认、参考列表、作者地址以及版权和知识产权声明。
Today the Session Description Protocol (SDP) [1] is used in several types of applications. The original application is session information and configuration for multicast sessions announced with Session Announcement Protocol (SAP) [5]. SDP is also a vital component in media negotiation for the Session Initiation Protocol (SIP) [6] by using the offer answer model [7]. The Real-Time Streaming Protocol (RTSP) [8] also makes use of SDP to declare to the client what media and codec(s) comprise a multi-media presentation.
今天，会话描述协议（SDP）[1]被用于几种类型的应用程序中。原始应用程序是会话信息和使用会话公告协议（SAP）宣布的多播会话的配置[5]。SDP也是会话发起协议（SIP）[6]的媒体协商中的一个重要组件，它使用提供-应答模型[7]。实时流协议（RTSP）[8]还利用SDP向客户端声明构成多媒体表示的媒体和编解码器。
In SDP [1] there exists a bandwidth attribute, which has a modifier used to specify what type of bit-rate the value refers to. The attribute has the following form:
在SDP[1]中存在一个带宽属性，该属性具有一个修饰符，用于指定该值所指的比特率类型。该属性具有以下形式：
b=<modifier>:<value>
b=<modifier>:<value>
Today there are four defined modifiers used for different purposes.
今天，有四个定义的修饰符用于不同的目的。
The Conference Total is indicated by giving the modifier "CT". Conference total gives a maximum bandwidth that a conference session will use. Its purpose is to decide if this session can co-exist with any other sessions, defined in RFC 2327 [1].
会议总数用修饰符“CT”表示。Conference total提供会议会话将使用的最大带宽。其目的是确定此会话是否可以与RFC 2327[1]中定义的任何其他会话共存。
The Application Specific maximum bandwidth is indicated by the modifier "AS". The interpretation of this attribute is dependent on the application's notion of maximum bandwidth. For an RTP application, this attribute is the RTP session bandwidth as defined
应用程序特定的最大带宽由修饰符“AS”表示。此属性的解释取决于应用程序的最大带宽概念。对于RTP应用程序，此属性是定义的RTP会话带宽
in RFC 3550 [4]. The session bandwidth includes the bandwidth that the RTP data traffic will consume, including the lower layers, down to the IP layer. Therefore, the bandwidth is in most cases calculated over RTP payload, RTP header, UDP, and IP, defined in RFC 2327 [1].
在RFC 3550[4]中。会话带宽包括RTP数据通信将消耗的带宽，包括较低层，直至IP层。因此，在大多数情况下，带宽是通过RFC 2327[1]中定义的RTP有效负载、RTP报头、UDP和IP计算的。
In RFC 3556 [9], two bandwidth modifiers are defined. These modifiers, "RS" and "RR", define the amount of bandwidth that is assigned for RTCP reports by active data senders and RTCP reports by other participants (receivers), respectively.
在RFC 3556[9]中，定义了两个带宽修饰符。这些修饰符“RS”和“RR”分别定义活动数据发送方为RTCP报告分配的带宽量和其他参与者（接收方）为RTCP报告分配的带宽量。
Today there are two IP versions, 4 [14] and 6 [13], used in parallel on the Internet, creating problems. However, there exist a number of possible transition mechanisms.
今天，有两个IP版本，4[14]和6[13]，在互联网上并行使用，造成了问题。然而，存在一些可能的过渡机制。
- The nodes which wish to communicate must share the IP version; typically this is done by deploying dual-stack nodes. For example, an IPv4 only host cannot communicate with an IPv6 only host.
- 希望通信的节点必须共享IP版本；通常，这是通过部署双堆栈节点来完成的。例如，仅IPv4主机无法与仅IPv6主机通信。
- If communication between nodes which do not share a protocol version is required, use of a translation or proxying mechanism would be required. Work is underway to specify such a mechanism for this purpose.
- 如果需要在不共享协议版本的节点之间进行通信，则需要使用转换或代理机制。目前正在为此目的制定这样一个机制。
------------------ ----------------------
| IPv4 domain | | IPv6 Domain |
| | ------------- | |
| ---------- |-|Translator |-| ---------- |
| |Server A| | | or proxy | | |Client B| |
| ---------- | ------------- | ---------- |
------------------ ----------------------
------------------ ----------------------
| IPv4 domain | | IPv6 Domain |
| | ------------- | |
| ---------- |-|Translator |-| ---------- |
| |Server A| | | or proxy | | |Client B| |
| ---------- | ------------- | ---------- |
------------------ ----------------------
Figure 1. Translation or proxying between IPv6 and IPv4 addresses.
图1。IPv6和IPv4地址之间的转换或代理。
- IPv6 nodes belonging to different domains running IPv6, but lacking IPv6 connectivity between them, solve this by tunneling over the IPv4 net, see Figure 2. Basically, the IPv6 packets are sent as payload in IPv4 packets between the tunneling end-points at the edge of each IPv6 domain. The bandwidth required over the IPv4 domain will be different from IPv6 domains. However, as the tunneling is normally not performed by the application end-point, this scenario can not usually be taken into consideration.
- 属于不同域的IPv6节点运行IPv6，但它们之间缺乏IPv6连接，请通过IPv4网络上的隧道解决此问题，见图2。基本上，IPv6数据包作为IPv4数据包中的有效负载在每个IPv6域边缘的隧道端点之间发送。IPv4域上所需的带宽将不同于IPv6域。但是，由于隧道通常不是由应用程序端点执行的，因此通常不能考虑这种情况。
--------------- --------------- ---------------
| IPv6 domain | | IPv4 domain | | IPv6 Domain |
| | |-------------| | |
| ---------- |--||Tunnel ||--| ---------- |
| |Server A| | |-------------| | |Client B| |
| ---------- | | | | ---------- |
--------------- --------------- --------------|
--------------- --------------- ---------------
| IPv6 domain | | IPv4 domain | | IPv6 Domain |
| | |-------------| | |
| ---------- |--||Tunnel ||--| ---------- |
| |Server A| | |-------------| | |Client B| |
| ---------- | | | | ---------- |
--------------- --------------- --------------|
Figure 2. Tunneling through a IPv4 domain
图2。通过IPv4域的隧道
IPv4 has a minimum header size of 20 bytes, while the fixed part of the IPv6 header is 40 bytes.
IPv4的最小标头大小为20字节，而IPv6标头的固定部分为40字节。
The difference in header sizes means that the bit-rate required for the two IP versions is different. The significance of the difference depends on the packet rate and payload size of each packet.
报头大小的差异意味着两个IP版本所需的比特率不同。差异的重要性取决于每个数据包的数据包速率和有效负载大小。
There exist a number of other mechanisms that also may change the overhead at layers below media transport. We will briefly cover a few of these here.
还有许多其他机制也可能会改变媒体传输层下面的开销。我们将在这里简要介绍其中的一些。
IPsec [19] can be used between end points to provide confidentiality through the application of the IP Encapsulating Security Payload (ESP) [21] or integrity protection using the IP Authentication Header (AH) [20] of the media stream. The addition of the ESP and AH headers increases each packet's size.
IPsec[19]可在端点之间使用，以通过应用IP封装安全有效负载（ESP）[21]或使用媒体流的IP认证头（AH）[20]提供完整性保护来提供机密性。ESP和AH报头的添加增加了每个数据包的大小。
To provide virtual private networks, complete IP packets may be encapsulated between an end node and the private networks security gateway, thus providing a secure tunnel that ensures confidentiality, integrity, and authentication of the packet stream. In this case, the extra IP and ESP header will significantly increase the packet size.
为了提供虚拟专用网络，可以在终端节点和专用网络安全网关之间封装完整的IP分组，从而提供确保分组流的机密性、完整性和认证的安全隧道。在这种情况下，额外的IP和ESP报头将显著增加数据包大小。
Another mechanism that alters the actual overhead over links is header compression. Header compression uses the fact that most network protocol headers have either static or predictable values in their fields within a packet stream. Compression is normally only done on a per hop basis, i.e., on a single link. The normal reason for doing header compression is that the link has fairly limited bandwidth and significant gain in throughput is achieved.
另一种改变链路实际开销的机制是报头压缩。报头压缩利用了一个事实，即大多数网络协议报头在数据包流中的字段中都有静态值或可预测值。压缩通常仅在每跳的基础上进行，即在单个链路上。进行报头压缩的正常原因是，链路的带宽相当有限，吞吐量显著提高。
There exist several different header compression standards. For compressing IP headers only, there is RFC 2507 [10]. For compressing packets with IP/UDP/RTP headers, CRTP [11] was created at the same time. More recently, the Robust Header Compression (ROHC) working group has been developing a framework and profiles [12] for compressing certain combinations of protocols, like IP/UDP, and IP/UDP/RTP.
存在几种不同的报头压缩标准。对于仅压缩IP头，有RFC 2507[10]。为了压缩带有IP/UDP/RTP报头的数据包，同时创建了CRTP[11]。最近，ROHC工作组开发了一个框架和概要文件[12]，用于压缩某些协议组合，如IP/UDP和IP/UDP/RTP。
ALG - Application Level Gateway. bps - bits per second. RTSP - Real-Time Streaming Protocol, see [8]. SDP - Session Description Protocol, see [1]. SAP - Session Announcement Protocol, see [5]. SIP - Session Initiation Protocol, see [6]. TIAS - Transport Independent Application Specific maximum, a bandwidth modifier.
ALG-应用程序级网关。bps-位/秒。RTSP-实时流协议，见[8]。SDP-会话描述协议，请参见[1]。SAP-会话公告协议，请参见[5]。SIP-会话启动协议，参见[6]。TIAS-传输独立的应用程序特定的最大值，带宽修饰符。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[3]中的说明进行解释。
When an application wants to use SDP to signal the bandwidth required for this application, some problems become evident due to the inclusion of the lower layers in the bandwidth values.
当应用程序希望使用SDP来表示该应用程序所需的带宽时，由于在带宽值中包含较低的层，一些问题变得很明显。
If one signals the bandwidth in SDP, for example, using "b=AS:" as an RTP based application, one cannot know if the overhead is calculated for IPv4 or IPv6. An indication of which protocol has been used when calculating the bandwidth values is given by the "c=" connection address line. This line contains either a multicast group address or a unicast address of the data source or sink. The "c=" line's address type may be assumed to be of the same type as the one used in the bandwidth calculation, although no document specifying this point seems to exist.
例如，如果使用“b=AS:”作为基于RTP的应用程序，在SDP中发送带宽信号，则无法知道开销是针对IPv4还是IPv6计算的。“c=”连接地址行给出了计算带宽值时使用的协议的指示。此行包含数据源或接收器的多播组地址或单播地址。“c=”行的地址类型可以假定与带宽计算中使用的地址类型相同，尽管似乎不存在指定此点的文档。
In cases of SDP transported by RTSP, this is even less clear. The normal usage for a unicast on-demand streaming session is to set the connection data address to a null address. This null address does
对于RTSP传输的SDP，这一点更不清楚。单播按需流会话的正常用法是将连接数据地址设置为空地址。这个空地址不存在
have an address type, which could be used as an indication. However, this is also not clarified anywhere.
具有地址类型，可以用作指示。然而，这一点在任何地方都没有得到澄清。
Figure 1, illustrates a connection scenario between a streaming server A and a client B over a translator. When B receives the SDP from A over RTSP, it will be very difficult for B to know what the bandwidth values in the SDP represent. The following possibilities exist:
图1演示了流式服务器a和客户端B之间通过转换器的连接场景。当B通过RTSP从A接收SDP时，B很难知道SDP中的带宽值代表什么。存在以下可能性：
1. The SDP is unchanged and the "c=" null address is of type IPv4. The bandwidth value represents the bandwidth needed in an IPv4 network.
1. SDP保持不变，“c=”null地址的类型为IPv4。带宽值表示IPv4网络中所需的带宽。
2. The SDP has been changed by an Application Level Gateway (ALG). The "c=" address is changed to an IPv6 type. The bandwidth value is unchanged.
2. SDP已由应用程序级网关（ALG）更改。“c=”地址已更改为IPv6类型。带宽值不变。
3. The SDP is changed and both "c=" address type and bandwidth value is converted. Unfortunately, this can seldom be done, see 3.3.
3. SDP被更改，并且“c=”地址类型和带宽值都被转换。不幸的是，这很少能做到，见3.3。
In case 1, the client can understand that the server is located in an IPv4 network and that it uses IPv4 overhead when calculating the bandwidth value. The client can almost never convert the bandwidth value, see section 3.3.
在案例1中，客户端可以理解服务器位于IPv4网络中，并且在计算带宽值时使用IPv4开销。客户端几乎无法转换带宽值，请参见第3.3节。
In case 2, the client does not know that the server is in an IPv4 network and that the bandwidth value is not calculated with IPv6 overhead. In cases where a client uses this value to determine if its end of the network has sufficient resources the client will underestimate the required bit-rate, potentially resulting in bad application performance.
在案例2中，客户机不知道服务器位于IPv4网络中，并且带宽值不是使用IPv6开销计算的。在客户端使用此值确定其网络端是否有足够资源的情况下，客户端将低估所需的比特率，从而可能导致应用程序性能下降。
In case 3, everything works correctly. However, this case will be very rare. If one tries to convert the bandwidth value without further information about the packet rate, significant errors may be introduced into the value.
在案例3中，一切正常。然而，这种情况将非常罕见。如果试图转换带宽值而没有关于分组速率的进一步信息，则可能会在该值中引入重大错误。
Section 1.2 and 1.3 lists a number of reasons, like header compression and tunnels, that would change lower layer header sizes. For these mechanisms there exist different possibilities to take them into account.
第1.2节和第1.3节列出了许多原因，如割台压缩和隧道，这些原因会改变较低层割台的尺寸。对于这些机制，存在不同的可能性来考虑它们。
Using IPsec directly between end-points should definitely be known to the application, thus enabling it to take the extra headers into account. However the same problem also exists with the current SDP bandwidth modifiers where a receiver is not able to convert these values taking the IPsec headers into account.
应用程序肯定知道在端点之间直接使用IPsec，从而使其能够考虑额外的头。但是，当前的SDP带宽修饰符也存在同样的问题，其中接收器无法在考虑IPsec头的情况下转换这些值。
It is less likely that an application would be aware of the existence of a virtual private network. Thus the generality of the mechanism to tunnel all traffic may prevent the application from even considering whether it would be possible to convert the values.
应用程序不太可能知道虚拟专用网络的存在。因此，隧道所有流量的机制的通用性可能会阻止应用程序甚至考虑是否可能转换这些值。
When using header compression, the actual overhead will be less deterministic, but in most cases an average overhead can be determined for a certain application. If a network node knows that some type of header compression is employed, this can be taken into consideration. For RSVP [15], there exists an extension, RFC 3006 [16], that allows the data sender to inform network nodes about the compressibility of the data flow. To be able to do this with any accuracy, the compression factor and packet rate or size is needed, as RFC 3006 provides.
当使用报头压缩时，实际开销将不太确定，但在大多数情况下，可以确定某个应用程序的平均开销。如果网络节点知道采用了某种类型的报头压缩，则可以考虑这一点。对于RSVP[15]，存在一个扩展RFC 3006[16]，它允许数据发送方通知网络节点数据流的可压缩性。为了能够以任何精度做到这一点，需要压缩因子和分组速率或大小，如RFC 3006所提供的那样。
If one would like to convert a bandwidth value calculated using IPv4 overhead to IPv6 overhead, the packet rate is required. The new bandwidth value for IPv6 is normally "IPv4 bandwidth" + "packet rate" * 20 bytes, where 20 bytes is the usual difference between IPv6 and IPv4 headers. The overhead difference may be some other value in cases when IPv4 options [14] or IPv6 extension headers [13] are used.
如果要将使用IPv4开销计算的带宽值转换为IPv6开销，则需要数据包速率。IPv6的新带宽值通常为“IPv4带宽”+“数据包速率”*20字节，其中20字节是IPv6和IPv4报头之间的通常差异。在使用IPv4选项[14]或IPv6扩展头[13]的情况下，开销差异可能是其他一些值。
As converting requires the packet rate of the stream, this is not possible in the general case. Many codecs have either multiple possible packet/frame rates or can perform payload format aggregation, resulting in many possible rates. Therefore, some extra information in the SDP will be required. The "a=ptime:" parameter may be a possible candidate. However, this parameter is normally only used for audio codecs. Its definition [1] is that it is only a recommendation, which the sender may disregard. A better parameter is needed.
由于转换需要流的分组速率，因此在一般情况下这是不可能的。许多编解码器要么具有多个可能的数据包/帧速率，要么可以执行有效负载格式聚合，从而产生许多可能的速率。因此，SDP中需要一些额外的信息。“a=ptime:”参数可能是一个候选参数。但是，此参数通常仅用于音频编解码器。它的定义[1]是，它只是一个建议，发送者可以忽略它。需要一个更好的参数。
When RTCP is used between hosts in IPv4 and IPv6 networks over translator, similar problems exist. The RTCP traffic going from the IPv4 domain will result in a higher RTCP bit-rate than intended in the IPv6 domain due to the larger headers. This may result in up to a 25% increase in required bandwidth for the RTCP traffic. The largest increase will be for small RTCP packets when the number of
当通过转换器在IPv4和IPv6网络中的主机之间使用RTCP时，也存在类似的问题。由于报头较大，来自IPv4域的RTCP流量将导致比IPv6域中预期的更高的RTCP比特率。这可能导致RTCP流量所需带宽最多增加25%。最大的增加将是小RTCP数据包，当
IPv4 hosts is much larger than the number of IPv6 hosts. Fortunately, as RTCP has a limited bandwidth compared to RTP, it will only result in a maximum of 1.75% increase of the total session bandwidth when RTCP bandwidth is 5% of RTP bandwidth. The RTCP randomization may easily result in short term effects of the same magnitude, so this increase may be considered tolerable. The increase in bandwidth will in most cases be less.
IPv4主机的数量远大于IPv6主机的数量。幸运的是，与RTP相比，RTCP的带宽有限，当RTCP带宽为RTP带宽的5%时，它只会导致总会话带宽最多增加1.75%。RTCP随机化可能很容易导致相同程度的短期效应，因此这种增加可能被认为是可以容忍的。在大多数情况下，带宽的增加会更少。
At the same time, this results in unfairness in the reporting between an IPv4 and IPv6 node. In the worst case scenario, the IPv6 node may report with 25% longer intervals.
同时，这导致IPv4和IPv6节点之间的报告不公平。在最坏的情况下，IPv6节点的报告间隔可能会延长25%。
These problems have been considered insignificant enough to not be worth any complex solutions. Therefore, only a simple algorithm for deriving RTCP bandwidth is defined in this specification.
这些问题被认为微不足道，不值得任何复杂的解决方案。因此，本规范中仅定义了推导RTCP带宽的简单算法。
Today there is work in the IETF to design a new datagram transport protocol suitable for real-time media. This protocol is called the Datagram Congestion Control Protocol (DCCP). It will most probably have a different header size than UDP, which is the protocol most often used for real-time media today. This results in even more possible transport combinations. This may become a problem if one has the possibility of using different protocols, which will not be determined prior to actual protocol SETUP. Thus, pre-calculating this value will not be possible, which is one further motivation why a transport independent bandwidth modifier is needed.
目前，IETF正在设计一种适用于实时媒体的新数据报传输协议。该协议称为数据报拥塞控制协议（DCCP）。它的报头大小很可能与UDP不同，UDP是当今实时媒体最常用的协议。这将导致更可能的传输组合。如果有可能使用不同的协议，这可能会成为一个问题，在实际协议设置之前不会确定。因此，不可能预先计算该值，这是需要传输无关带宽修饰符的另一个动机。
DCCP's congestion control algorithms will control how much bandwidth can really be utilized. This may require further work with specifying SDP bandwidth modifiers to declare the dynamic possibilities of an application's media stream. For example, min and max media bandwidth the application is capable of producing at all, or for media codecs only capable of producing certain bit-rates, enumerating possible rates. However, this is for future study and outside the scope of the present solution.
DCCP的拥塞控制算法将控制带宽的实际利用率。这可能需要进一步指定SDP带宽修饰符来声明应用程序媒体流的动态可能性。例如，应用程序能够产生的最小和最大媒体带宽，或者对于只能产生特定比特率的媒体编解码器，列举可能的速率。但是，这是为了将来的研究，不在当前解决方案的范围内。
A shortcoming of the current SDP bandwidth modifiers is that they also include the bandwidth needed for lower layers. It is in many cases difficult to determine which lower layers and their versions were included in the calculation, especially in the presence of translation or proxying between different domains. This prevents a receiver from determining if given bandwidth needs to be converted based on the actual lower layers being used.
当前SDP带宽修改器的一个缺点是，它们还包括较低层所需的带宽。在许多情况下，很难确定计算中包括哪些较低层及其版本，特别是在不同域之间存在转换或代理的情况下。这防止接收器根据实际使用的较低层确定是否需要转换给定带宽。
Secondly, an attribute to give the receiver an explicit determination of the maximum packet rate that will be used does not exist. This value is necessary for accurate conversion of any bandwidth values if the difference in overhead is known.
第二，不存在一个属性，该属性为接收方提供将要使用的最大数据包速率的明确确定。如果已知开销的差异，则该值对于任何带宽值的精确转换是必需的。
The problems described in section 3 are common and effect application level signaling using SDP, other signaling protocols, and also resource reservation protocols. However, this document targets the specific problem of signaling the bit-rate in SDP. The problems need to be considered in other affected protocols and in new protocols being designed. In the MMUSIC WG there is work on a replacement of SDP called SDP-NG. It is recommended that the problems outlined in this document be considered when designing solutions for specifying bandwidth in the SDP-NG [17].
第3节中描述的问题是使用SDP、其他信令协议以及资源预留协议的常见和有效的应用级信令。然而，本文档针对SDP中发送比特率信号的特定问题。需要在其他受影响的协议和正在设计的新协议中考虑这些问题。MMUSIC工作组正在研究SDP的替代品，称为SDP-NG。建议在设计SDP-NG中指定带宽的解决方案时考虑本文件中概述的问题[17]。
As this specification only targets carrying the bit-rate information within SDP, it will have a limited applicability. As SDP information is normally transported end-to-end by an application protocol, nodes between the end-points will not have access to the bit-rate information. It will normally only be the end points that are able to take this information into account. An interior node will need to receive the information through a means other than SDP, and that is outside the scope of this specification.
由于本规范仅针对SDP中的比特率信息，因此其适用性有限。由于SDP信息通常通过应用协议端到端传输，因此端点之间的节点将无法访问比特率信息。通常情况下，只有端点能够考虑这些信息。内部节点需要通过SDP以外的方式接收信息，这超出了本规范的范围。
Nevertheless, the bit-rate information provided in this specification is sufficient for cases such as first-hop resource reservation and admission control. It also provide information about the maximum codec rate, which is independent of lower-level protocols.
然而，本规范中提供的比特率信息对于诸如第一跳资源预留和接纳控制的情况是足够的。它还提供有关最大编解码器速率的信息，该速率独立于较低级别的协议。
This specification does NOT try to solve the problem of detecting NATs or other middleboxes.
本规范并不试图解决检测NAT或其他中间盒的问题。
The problems outlined in the preceding sections and with the above applicability, should meet the following requirements:
上述章节中概述的问题以及上述适用性应满足以下要求：
- The bandwidth value SHALL be given in a way such that it can be calculated for all possible combinations of transport overhead.
- 带宽值的给出方式应确保能够针对所有可能的传输开销组合进行计算。
This chapter describes a solution for the problems outlined in this document for the Application Specific (AS) bandwidth modifier, thus enabling the derivation of the required bit-rate for an application, or RTP session's data and RTCP traffic. The solution is based upon the definition of a new Transport Independent Application Specific (TIAS) bandwidth modifier and a new SDP attribute for the maximum packet rate (maxprate).
本章介绍了本文档中针对应用程序特定（AS）带宽修改器概述的问题的解决方案，从而能够推导应用程序或RTP会话的数据和RTCP流量所需的比特率。该解决方案基于新的传输独立应用程序特定（TIAS）带宽修饰符和最大分组速率（maxprate）的新SDP属性的定义。
The CT is a session level modifier and cannot easily be dealt with. To address the problems with different overhead, it is RECOMMENDED that the CT value be calculated using reasonable worst case overhead. An example of how to calculate a reasonable worst case overhead is: Take the overhead of the largest transport protocol (using average size if variable), add that to the largest IP overhead that is expected for use, plus the data traffic rate. Do this for every individual media stream used in the conference and add them together.
CT是会话级别的修改器，不容易处理。为了解决不同开销的问题，建议使用合理的最坏情况开销计算CT值。如何计算合理的最坏情况开销的一个示例是：取最大传输协议的开销（如果可变，则使用平均大小），将其添加到预期使用的最大IP开销，再加上数据通信速率。对会议中使用的每个媒体流执行此操作，并将它们添加到一起。
The RR and RS modifiers [9] will be used as defined and include transport overhead. The small unfairness between hosts is deemed acceptable.
RR和RS修饰符[9]将按定义使用，并包括传输开销。主机之间的小不公平被认为是可以接受的。
A new bandwidth modifier is defined to be used for the following purposes:
定义了一个新的带宽修改器，用于以下目的：
- Resource reservation. A single bit-rate can be enough for use as a resource reservation. Some characteristics can be derived from the stream, codec type, etc. In cases where more information is needed, another SDP parameter will be required.
- 资源保留。单比特率足以用作资源预留。某些特征可以从流、编解码器类型等派生。在需要更多信息的情况下，将需要另一个SDP参数。
- Maximum media codec rate. With the definition below of "TIAS", the given bit-rate will mostly be from the media codec. Therefore, it gives a good indication of the maximum codec bit-rate required to be supported by the decoder.
- 最大媒体编解码器速率。根据以下“TIA”的定义，给定的比特率将主要来自媒体编解码器。因此，它很好地指示了解码器需要支持的最大编解码器比特率。
- Communication bit-rate required for the stream. The "TIAS" value together with "maxprate" can be used to determine the maximum communication bit-rate the stream will require. Using session level values or by adding all maximum bit-rates from the streams in a session together, a receiver can determine if its communication resources are sufficient to handle the stream. For
- 流所需的通信比特率。“TIAS”值和“maxprate”可用于确定流所需的最大通信比特率。使用会话级别值或通过将会话中的流的所有最大比特率相加，接收机可以确定其通信资源是否足以处理该流。对于
example, a modem user can determine if the session fits his modem's capabilities and the established connection.
例如，调制解调器用户可以确定会话是否符合其调制解调器的功能和已建立的连接。
- Determine the RTP session bandwidth and derive the RTCP bandwidth. The derived transport dependent attribute will be the RTP session bandwidth in case of RTP based transport. The TIAS value can also be used to determine the RTCP bandwidth to use when using implicit allocation. RTP [4] specifies that if not explicitly stated, additional bandwidth, equal to 5% of the RTP session bandwidth, shall be used by RTCP. The RTCP bandwidth can be explicitly allocated by using the RR and RS modifiers defined in [9].
- 确定RTP会话带宽并导出RTCP带宽。在基于RTP的传输的情况下，派生的传输相关属性将是RTP会话带宽。TIAS值还可用于确定使用隐式分配时要使用的RTCP带宽。RTP[4]规定，如果未明确说明，RTCP应使用额外带宽，等于RTP会话带宽的5%。可以使用[9]中定义的RR和RS修饰符显式分配RTCP带宽。
A new session and media level bandwidth modifier is defined:
定义了一个新的会话和媒体级带宽修改器：
b=TIAS:<bandwidth-value> ; see section 6.6 for ABNF definition.
b=TIAS:<bandwidth value>；ABNF定义见第6.6节。
The Transport Independent Application Specific Maximum (TIAS) bandwidth modifier has an integer bit-rate value in bits per second. A fractional bandwidth value SHALL always be rounded up to the next integer. The bandwidth value is the maximum needed by the application (SDP session level) or media stream (SDP media level) without counting IP or other transport layers like TCP or UDP.
传输无关应用程序特定最大（TIAS）带宽修饰符具有整数比特率值，单位为每秒比特数。分数带宽值应始终向上舍入到下一个整数。带宽值是应用程序（SDP会话级别）或媒体流（SDP媒体级别）所需的最大值，不计算IP或其他传输层（如TCP或UDP）。
At the SDP session level, the TIAS value is the maximal amount of bandwidth needed when all declared media streams are used. This MAY be less than the sum of all the individual media streams values. This is due to the possibility that not all streams have their maximum at the same point in time. This can normally only be verified for stored media streams.
在SDP会话级别，TIAS值是使用所有声明的媒体流时所需的最大带宽量。这可能小于所有单个媒体流值的总和。这是因为并非所有流在同一时间点都有其最大值。这通常只能针对存储的媒体流进行验证。
For RTP transported media streams, TIAS at the SDP media level can be used to derive the RTP "session bandwidth", defined in section 6.2 of [4]. In the context of RTP transport, the TIAS value is defined as:
对于RTP传输的媒体流，SDP媒体级别的TIA可用于推导[4]第6.2节中定义的RTP“会话带宽”。在RTP传输的上下文中，TIAS值定义为：
Only the RTP payload as defined in [4] SHALL be used in the calculation of the bit-rate, i.e., excluding the lower layers (IP/UDP) and RTP headers including RTP header, RTP header extensions, CSRC list, and other RTP profile specific fields. Note that the RTP payload includes both the payload format header and the data. This may allow one to use the same value for RTP-based media transport, non-RTP transport, and stored media.
只有[4]中定义的RTP有效载荷才能用于比特率的计算，即不包括较低层（IP/UDP）和RTP报头，包括RTP报头、RTP报头扩展、CSC列表和其他RTP配置文件特定字段。注意，RTP有效负载包括有效负载格式报头和数据。这可能允许对基于RTP的媒体传输、非RTP传输和存储媒体使用相同的值。
Note 1: The usage of bps is not in accordance with RFC 2327 [1]. This change has no implications on the parser, only the interpreter of the value must be aware. The change is done to allow for better resolution, and has also been used for the RR and RS bandwidth modifiers, see [9].
注1：bps的使用不符合RFC 2327[1]。此更改对解析器没有影响，只有值的解释器必须知道。这种改变是为了提高分辨率，并且也用于RR和RS带宽修饰符，请参见[9]。
Note 2: RTCP bandwidth is not included in the bandwidth value. In applications using RTCP, the bandwidth used by RTCP is either 5% of the RTP session bandwidth including lower layers or as specified by the RR and RS modifiers [9]. A specification of how to derive the RTCP bit-rate when using TIAS is presented in chapter 6.5.
注2：带宽值中不包括RTCP带宽。在使用RTCP的应用程序中，RTCP使用的带宽为RTP会话带宽的5%，包括较低的层，或者按照RR和RS修饰符的规定[9]。第6.5章介绍了使用TIA时如何推导RTCP比特率的规范。
"TIAS" is primarily intended to be used at the SDP media level. The "TIAS" bandwidth attribute MAY be present at the session level in SDP, if all media streams use the same transport. In cases where the sum of the media level values for all media streams is larger than the actual maximum bandwidth need for all streams, it SHOULD be included at session level. However, if present at the session level it SHOULD be present also at the media level. "TIAS" SHALL NOT be present at the session level unless the same transport protocols is used for all media streams. The same transport is used as long as the same combination of protocols is used, like IPv6/UDP/RTP.
“TIA”主要用于SDP媒体级别。如果所有媒体流使用相同的传输，“TIAS”带宽属性可能出现在SDP中的会话级别。如果所有媒体流的媒体级别值之和大于所有流的实际最大带宽需求，则应将其包括在会话级别。但是，如果存在于会话级别，则它也应存在于媒体级别。除非所有媒体流使用相同的传输协议，否则“TIA”不得出现在会话级别。只要使用相同的协议组合（如IPv6/UDP/RTP），就可以使用相同的传输。
To allow for backwards compatibility with applications of SDP that do not implement "TIAS", it is RECOMMENDED to also include the "AS" modifier when using "TIAS". The presence of a value including lower-layer overhead, even with its problems, is better than none. However, an SDP application implementing TIAS SHOULD ignore the "AS" value and use "TIAS" instead when both are present.
为了与未实现“TIA”的SDP应用程序向后兼容，建议在使用“TIA”时也包括“AS”修饰符。存在一个包含较低层开销的值，即使存在问题，也比没有好。但是，实现TIA的SDP应用程序应该忽略“AS”值，并在两者都存在时使用“TIA”。
When using TIAS for an RTP-transported stream, the "maxprate" attribute, if possible to calculate, defined next, SHALL be included at the corresponding SDP level.
当对RTP传输流使用TIA时，应在相应的SDP级别包括下一步定义的“maxprate”属性（如果可能计算）。
To be able to calculate the bandwidth value including the lower layers actually used, a packet rate attribute is also defined.
为了能够计算包括实际使用的较低层的带宽值，还定义了分组速率属性。
The SDP session and media level maximum packet rate attribute is defined as:
SDP会话和媒体级最大数据包速率属性定义为：
a=maxprate:<packet-rate> ; see section 6.6 for ABNF definition.
a=maxprate:<packetrate>；ABNF定义见第6.6节。
The <packet-rate> is a floating-point value for the stream's maximum packet rate in packets per second. If the number of packets is variable, the given value SHALL be the maximum the application can produce in case of a live stream, or for stored on-demand streams, has produced. The packet rate is calculated by adding the number of packets sent within a 1 second window. The maxprate is the largest value produced when the window slides over the entire media stream. In cases that this can't be calculated, i.e., a live stream, a estimated value of the maximum packet rate the codec can produce for the given configuration and content SHALL be used.
<packet rate>是流的最大分组速率的浮点值，单位为每秒分组数。如果数据包的数量是可变的，则给定值应为应用程序在实时流或存储的按需流中产生的最大值。通过将1秒窗口内发送的数据包数量相加来计算数据包速率。maxprate是窗口在整个媒体流上滑动时产生的最大值。在无法计算的情况下，即实时流，应使用编解码器针对给定配置和内容可产生的最大分组速率的估计值。
Note: The sliding window calculation will always yield an integer number. However the attributes field is a floating-point value because the estimated or known maximum packet rate per second may be fractional.
注意：滑动窗口计算将始终产生一个整数。然而，属性字段是浮点值，因为估计的或已知的每秒最大分组速率可能是分数。
At the SDP session level, the "maxprate" value is the maximum packet rate calculated over all the declared media streams. If this can't be measured (stored media) or estimated (live), the sum of all media level values provides a ceiling value. Note: the value at session level can be less then the sum of the individual media streams due to temporal distribution of media stream's maximums. The "maxprate" attribute MUST NOT be present at the session level if the media streams use different transport. The attribute MAY be present if the media streams use the same transport. If the attribute is present at the session level, it SHOULD also be present at the media level for all media streams.
在SDP会话级别，“maxprate”值是在所有声明的媒体流上计算的最大分组速率。如果无法测量（存储媒体）或估计（实时），则所有媒体级别值的总和将提供一个上限值。注意：由于媒体流最大值的时间分布，会话级别的值可以小于各个媒体流的总和。如果媒体流使用不同的传输，则“maxprate”属性不得出现在会话级别。如果媒体流使用相同的传输，则该属性可能存在。如果该属性存在于会话级别，则它也应存在于所有媒体流的媒体级别。
"maxprate" SHALL be included for all transports where a packet rate can be derived and TIAS is included. For example, if you use TIAS and a transport like IP/UDP/RTP, for which the max packet rate (actual or estimated) can be derived, then "maxprate" SHALL be included. However, if either (a) the packet rate for the transport cannot be derived, or (b) TIAS is not included, then, "maxprate" is not required to be included.
“maxprate”应包含在所有传输中，其中可导出数据包速率并包含TIA。例如，如果您使用TIA和类似IP/UDP/RTP的传输，可以导出最大数据包速率（实际或估计），则应包括“maxprate”。然而，如果（a）不能导出传输的分组速率，或者（b）不包括tia，则不需要包括“maxprate”。
When converting the transport-independent bandwidth value (bw-value) into a transport-dependent value including the lower layers, the following MUST be done:
将传输无关带宽值（bw值）转换为包括较低层的传输相关值时，必须执行以下操作：
1. Determine which lower layers will be used and calculate the sum of the sizes of the headers in bits (h-size). In cases of variable header sizes, the average size SHALL be used. For RTP-transported media, the lower layers SHALL include the RTP header with header extensions, if used, the CSRC list, and any profile-specific extensions.
1. 确定将使用哪些较低的层，并以位（h-size）为单位计算头的大小之和。如果割台尺寸可变，则应使用平均尺寸。对于RTP传输介质，较低层应包括带有标头扩展的RTP标头（如果使用）、CSC列表和任何特定于配置文件的扩展。
2. Retrieve the maximum packet rate from the SDP (prate = maxprate).
2. 从SDP检索最大数据包速率（prate=maxprate）。
3. Calculate the transport overhead by multiplying the header sizes by the packet rate (t-over = h-size * prate).
3. 通过将报头大小乘以数据包速率（t-over=h-size*prate）来计算传输开销。
4. Round the transport overhead up to nearest integer in bits (t-over = CEIL(t-over)).
4. 将传输开销舍入到最接近的整数位（t-over=CEIL（t-over））。
5. Add the transport overhead to the transport independent bandwidth value (total bit-rate = bw-value + t-over)
5. 将传输开销添加到与传输无关的带宽值（总比特率=bw值+t-over）
When the above calculation is performed using the "maxprate", the bit-rate value will be the absolute maximum the media stream may use over the transport assumed in the calculations.
当使用“maxprate”执行上述计算时，比特率值将是媒体流在计算中假定的传输上可以使用的绝对最大值。
This chapter does not solve the fairness and possible bit-rate change introduced by IPv4 to IPv6 translation. These differences are considered small enough, and known solutions introduce code changes to the RTP/RTCP implementation. This section provides a consistent way of calculating the bit-rate to assign to RTCP, if not explicitly given.
本章并未解决IPv4到IPv6转换带来的公平性和可能的比特率变化。这些差异被认为足够小，并且已知的解决方案将代码更改引入RTP/RTCP实现。本节提供了一种一致的方法来计算分配给RTCP的比特率（如果没有明确给出）。
First the transport-dependent RTP session bit-rate is calculated, in accordance with section 6.4, using the actual transport layers used at the end point where the calculation is done. The RTCP bit-rate is then derived as usual based on the RTP session bandwidth, i.e., normally equal to 5% of the calculated value.
首先，根据第6.4节，使用在计算结束点使用的实际传输层计算传输相关RTP会话比特率。然后根据RTP会话带宽（即，通常等于计算值的5%）照常导出RTCP比特率。
Giving the exact same RTCP bit-rate value to both the IPv4 and IPv6 hosts will result in the IPv4 host having a higher RTCP sending rate. The sending rate represents the number of RTCP packets sent during a given time interval. The sending of RTCP is limited according to rules defined in the RTP specification [4]. For a 100-byte RTCP packet (including UDP/IPv4), the IPv4 sender has an approximately 20% higher sending rate. This rate falls with larger RTCP packets. For example, 300-byte packets will only give the IPv4 host a 7% higher sending rate.
为IPv4和IPv6主机提供完全相同的RTCP比特率值将导致IPv4主机具有更高的RTCP发送速率。发送速率表示在给定时间间隔内发送的RTCP数据包数。RTCP的发送受RTP规范[4]中定义的规则限制。对于100字节RTCP数据包（包括UDP/IPv4），IPv4发送方的发送速率大约高出20%。此速率随RTCP数据包的增大而降低。例如，300字节的数据包只会使IPv4主机的发送速率提高7%。
The above rule for deriving RTCP bandwidth gives the same behavior as fixed assignment when the RTP session has traffic parameters giving a large TIAS/maxprate ratio. The two hosts will be fair when the TIAS/maxprate ratio is approximately 40 bytes/packet, given 100-byte RTCP packets. For a TIAS/maxprate ratio of 5 bytes/packet, the IPv6 host will be allowed to send approximately 15-20% more RTCP packets.
当RTP会话具有提供大TIAS/maxprate比率的流量参数时，用于推导RTCP带宽的上述规则给出了与固定分配相同的行为。给定100字节RTCP数据包，当TIAS/maxprate比率约为40字节/数据包时，这两台主机将是公平的。对于5字节/数据包的TIAS/maxprate比率，IPv6主机将允许多发送约15-20%的RTCP数据包。
The larger the RTCP packets become, the more it will favor the IPv6 host in its sending rate.
RTCP数据包越大，其发送速率越有利于IPv6主机。
The conclusions is that, within the normal useful combination of transport-independent bit rates and packet rates, the difference in fairness between hosts on different IP versions with different overhead is acceptable. For the 20-byte difference in overhead between IPv4 and IPv6 headers, the RTCP bandwidth actually used in a unicast connection case will not be larger than approximately 1% of the total session bandwidth.
结论是，在与传输无关的比特率和分组率的正常有用组合内，不同IP版本上具有不同开销的主机之间的公平性差异是可以接受的。对于IPv4和IPv6报头之间的20字节开销差异，在单播连接情况下实际使用的RTCP带宽将不大于总会话带宽的约1%。
This chapter defines in ABNF from RFC 2234 [2] the bandwidth modifier and the packet rate attribute.
本章在RFC 2234[2]的ABNF中定义了带宽修饰符和分组速率属性。
The bandwidth modifier:
带宽修改器：
TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF
TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF
bandwidth-value = 1*DIGIT
bandwidth-value = 1*DIGIT
The maximum packet rate attribute:
最大数据包速率属性：
max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF
max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF
packet-rate = 1*DIGIT ["." 1*DIGIT]
packet-rate = 1*DIGIT ["." 1*DIGIT]
v=0
o=Example_SERVER 3413526809 0 IN IP4 server.example.com
s=Example of TIAS and maxprate in use
c=IN IP4 0.0.0.0
b=AS:60
b=TIAS:50780
t=0 0
a=control:rtsp://server.example.com/media.3gp
a=range:npt=0-150.0
a=maxprate:28.0
m=audio 0 RTP/AVP 97
b=AS:12
b=TIAS:8480
a=maxprate:10.0
a=rtpmap:97 AMR/8000
a=fmtp:97 octet-align;
a=control:rtsp://server.example.com/media.3gp/trackID=1
m=video 0 RTP/AVP 99
v=0
o=Example_SERVER 3413526809 0 IN IP4 server.example.com
s=Example of TIAS and maxprate in use
c=IN IP4 0.0.0.0
b=AS:60
b=TIAS:50780
t=0 0
a=control:rtsp://server.example.com/media.3gp
a=range:npt=0-150.0
a=maxprate:28.0
m=audio 0 RTP/AVP 97
b=AS:12
b=TIAS:8480
a=maxprate:10.0
a=rtpmap:97 AMR/8000
a=fmtp:97 octet-align;
a=control:rtsp://server.example.com/media.3gp/trackID=1
m=video 0 RTP/AVP 99
b=AS:48
b=TIAS:42300
a=maxprate:18.0
a=rtpmap:99 MP4V-ES/90000
a=fmtp:99 profile-level-id=8;
config=000001B008000001B509000001010000012000884006682C2090A21F
a=control:rtsp://server.example.com/media.3gp/trackID=3
b=AS:48
b=TIAS:42300
a=maxprate:18.0
a=rtpmap:99 MP4V-ES/90000
a=fmtp:99 profile-level-id=8;
config=000001B008000001B509000001010000012000884006682C2090A21F
a=control:rtsp://server.example.com/media.3gp/trackID=3
In this SDP example of a streaming session's SDP, there are two media streams, one audio stream encoded with AMR and one video stream encoded with the MPEG-4 Video encoder. AMR is used here to produce a constant rate media stream and uses a packetization resulting in 10 packets per second. This results in a TIAS bandwidth rate of 8480 bits per second, and the claimed 10 packets per second. The video stream is more variable. However, it has a measured maximum payload rate of 42,300 bits per second. The video stream also has a variable packet rate, despite the fact that the video is 15 frames per second, where at least one instance in a second long window contains 18 packets.
在流会话的SDP的这个SDP示例中，有两个媒体流，一个用AMR编码的音频流和一个用MPEG-4视频编码器编码的视频流。AMR在这里用于产生恒定速率的媒体流，并使用分组化，每秒产生10个分组。这导致TIAS带宽速率为8480位/秒，并且声称的带宽速率为10个数据包/秒。视频流的变化更大。然而，它测量到的最大有效负载速率为每秒42300位。视频流还具有可变分组速率，尽管视频是每秒15帧，其中第二长窗口中的至少一个实例包含18个分组。
The "TIAS" and "maxprate" parameters can be used with RTSP as currently specified. To be able to calculate the transport dependent bandwidth, some of the transport header parameters will be required. There should be no problem for a client to calculate the required bandwidth(s) prior to an RTSP SETUP. The reason is that a client supports a limited number of transport setups. The one actually offered to a server in a SETUP request will be dependent on the contents of the SDP description. The "m=" line(s) will signal the desired transport profile(s) to the client.
“TIAS”和“maxprate”参数可与当前指定的RTSP一起使用。为了能够计算与传输相关的带宽，需要一些传输报头参数。在RTSP设置之前，客户端计算所需带宽应该没有问题。原因是客户端支持的传输设置数量有限。在设置请求中实际提供给服务器的设置将取决于SDP描述的内容。“m=”行将向客户发送所需传输配置文件的信号。
The usage of "TIAS" together with "maxprate" should not be different from the handling of the "AS" modifier currently in use. The needed transport parameters will be available in the transport field in the "m=" line. The address class can be determined from the "c=" field and the client's connectivity.
“TIAS”与“maxprate”的用法不应与当前使用的“AS”修饰符的处理方式不同。所需的传输参数将在“m=”行的传输字段中提供。地址类别可以通过“c=”字段和客户端的连接来确定。
In the case of SAP, all available information to calculate the transport dependent bit-rate should be present in the SDP. The "c=" information gives the address family used for the multicast. The transport layer, e.g., RTP/UDP, for each media is evident in the media line ("m=") and its transport field.
在SAP的情况下，SDP中应包含计算传输相关比特率的所有可用信息。“c=”信息给出了用于多播的地址族。每个媒体的传输层（例如RTP/UDP）在媒体行（“m=”）及其传输字段中很明显。
The bandwidth value that is supplied by the parameters defined here can be altered, if not integrity protected. By altering the bandwidth value, one can fool a receiver into reserving either more or less bandwidth than actually needed. Reserving too much may result in unwanted expenses on behalf of the user, while also blocking resources that other parties could have used. If too little bandwidth is reserved, the receiving user's quality may be effected. Trusting a too-large TIAS value may also result in the receiver rejecting the session due to insufficient communication and decoding resources.
此处定义的参数提供的带宽值可以更改（如果不受完整性保护）。通过改变带宽值，可以愚弄接收器，使其保留比实际需要更多或更少的带宽。预留太多可能会导致代表用户的不必要费用，同时还会阻塞其他方可能使用的资源。如果保留的带宽太少，则接收用户的质量可能会受到影响。信任过大的TIAS值也可能导致接收机由于通信和解码资源不足而拒绝会话。
Due to these security risks, it is strongly RECOMMENDED that the SDP be integrity protected and source authenticated so tampering can not be performed, and the source can be trusted. It is also RECOMMENDED that any receiver of the SDP perform an analysis of the received bandwidth values to verify that they are reasonable expected values for the application. For example, a single channel AMR-encoded voice stream claiming to use 1000 kbps is not reasonable.
由于存在这些安全风险，强烈建议对SDP进行完整性保护，并对源进行身份验证，这样就不能进行篡改，并且源是可信的。还建议SDP的任何接收器对接收到的带宽值进行分析，以验证它们是应用的合理预期值。例如，声称使用1000 kbps的单通道AMR编码语音流是不合理的。
Please note that some of the above security requirements are in conflict with that required to make signaling protocols using SDP work through a middlebox, as discussed in the security considerations of RFC 3303 [18].
请注意，如RFC 3303[18]的安全注意事项所述，上述一些安全要求与使用SDP的信令协议通过中间箱工作所需的安全要求相冲突。
This document registers one new SDP session and media level attribute "maxprate", see section 6.3.
本文件注册了一个新的SDP会话和媒体级属性“maxprate”，见第6.3节。
A new SDP [1] bandwidth modifier (bwtype) "TIAS" is also registered in accordance with the rules requiring a standards-track RFC. The modifier is defined in section 6.2.
新的SDP[1]带宽修改器（bwtype）“TIA”也根据要求标准轨道RFC的规则进行注册。修改器在第6.2节中定义。
The author would like to thank Gonzalo Camarillo and Hesham Soliman for their work reviewing this document. A very big thanks goes to Stephen Casner for reviewing and helping fix the language, and identifying some errors in the previous versions. Further thanks for suggestion to improvements go to Colin Perkins, Geetha Srikantan, and Emre Aksu.
作者要感谢Gonzalo Camarillo和Hesham Soliman审查本文件的工作。非常感谢Stephen Casner审阅并帮助修复该语言，以及在以前的版本中发现一些错误。进一步感谢Colin Perkins、Geetha Srikantan和Emre Aksu提出的改进建议。
The author would also like to thank all persons on the MMUSIC working group's mailing list that have commented on this specification.
作者还要感谢MMUSIC工作组邮件列表中对本规范发表评论的所有人员。
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[1] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[4] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[5] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[5] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[6] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[7] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[8] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[8] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[9] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[9] Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，2003年7月。
[10] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[10] Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[11] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[11] Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[12] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed ", RFC 3095, July 2001.
[12] Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[13] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[14] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[14] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[15] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[15] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[16] Davie, B., Iturralde, C., Oran, D., Casner, S., and J. Wroclawski, "Integrated Services in the Presence of Compressible Flows", RFC 3006, November 2000.
[16] Davie，B.，Iturralde，C.，Oran，D.，Casner，S.，和J.Wroclawski，“存在可压缩流时的综合服务”，RFC 3006，2000年11月。
[17] Kutscher, Ott, Bormann, "Session Description and Capability Negotiation," Work in Progress, March 2003.
[17] Kutscher，Ott，Bormann，“会话描述和能力协商”，正在进行的工作，2003年3月。
[18] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[18] Srisuresh，P.，Kuthan，J.，Rosenberg，J.，Molitor，A.，和A.Rayhan，“中间箱通信架构和框架”，RFC3303，2002年8月。
[19] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[19] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[20] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[20] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[21] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
Magnus Westerlund Ericsson Research Ericsson AB Torshamnsgatan 23 SE-164 80 Stockholm, SWEDEN
Magnus Westerlund Ericsson Research Ericsson AB Torshamnsgatan 23 SE-164 80瑞典斯德哥尔摩
Phone: +46 8 7190000
EMail: Magnus.Westerlund@ericsson.com
Phone: +46 8 7190000
EMail: Magnus.Westerlund@ericsson.com
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。