Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 5762 University of Glasgow
Category: Standards Track April 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 5762 University of Glasgow
Category: Standards Track April 2010
ISSN: 2070-1721
RTP and the Datagram Congestion Control Protocol (DCCP)
RTP和数据报拥塞控制协议（DCCP）
Abstract
摘要
The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real-time applications can make use of the services provided by DCCP.
实时传输协议（RTP）是IP网络上广泛使用的实时多媒体传输协议。数据报拥塞控制协议（DCCP）是一种为实时应用提供理想服务的传输协议。此备忘录指定了RTP到DCCP的映射以及相关的信令，以便实时应用程序可以使用DCCP提供的服务。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5762.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5762.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Rationale .......................................................3
3. Conventions Used in This Memo ...................................4
4. RTP over DCCP: Framing ..........................................4
4.1. RTP Data Packets ...........................................4
4.2. RTP Control Packets ........................................5
4.3. Multiplexing Data and Control ..............................7
4.4. RTP Sessions and DCCP Connections ..........................7
4.5. RTP Profiles ...............................................8
5. RTP over DCCP: Signalling using SDP .............................8
5.1. Protocol Identification ....................................8
5.2. Service Codes .............................................10
5.3. Connection Management .....................................11
5.4. Multiplexing Data and Control .............................11
5.5. Example ...................................................11
6. Security Considerations ........................................12
7. IANA Considerations ............................................13
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
1. Introduction ....................................................3
2. Rationale .......................................................3
3. Conventions Used in This Memo ...................................4
4. RTP over DCCP: Framing ..........................................4
4.1. RTP Data Packets ...........................................4
4.2. RTP Control Packets ........................................5
4.3. Multiplexing Data and Control ..............................7
4.4. RTP Sessions and DCCP Connections ..........................7
4.5. RTP Profiles ...............................................8
5. RTP over DCCP: Signalling using SDP .............................8
5.1. Protocol Identification ....................................8
5.2. Service Codes .............................................10
5.3. Connection Management .....................................11
5.4. Multiplexing Data and Control .............................11
5.5. Example ...................................................11
6. Security Considerations ........................................12
7. IANA Considerations ............................................13
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
The Real-time Transport Protocol (RTP) [1] is widely used in video streaming, telephony, and other real-time networked applications. RTP can run over a range of lower-layer transport protocols, and the performance of an application using RTP is heavily influenced by the choice of lower-layer transport. The Datagram Congestion Control Protocol (DCCP) [2] is a transport protocol that provides desirable properties for real-time applications running on unmanaged best-effort IP networks. This memo describes how RTP can be framed for transport using DCCP, and discusses some of the implications of such a framing. It also describes how the Session Description Protocol (SDP) [3] can be used to signal such sessions.
实时传输协议（RTP）[1]广泛应用于视频流、电话和其他实时网络应用中。RTP可以运行在一系列低层传输协议上，而使用RTP的应用程序的性能很大程度上受低层传输选择的影响。数据报拥塞控制协议（DCCP）[2]是一种传输协议，它为在非托管尽力而为IP网络上运行的实时应用程序提供理想的属性。本备忘录描述了如何使用DCCP对RTP进行帧化以进行传输，并讨论了这种帧化的一些含义。它还描述了如何使用会话描述协议（SDP）[3]来向此类会话发送信号。
The remainder of this memo is structured as follows: it begins with a rationale for the work in Section 2, describing why a mapping of RTP onto DCCP is needed. Following a description of the conventions used in this memo in Section 3, the specification begins in Section 4 with the definition of how RTP packets are framed within DCCP. Associated signalling is described in Section 5. Security considerations are discussed in Section 6, and IANA considerations in Section 7.
本备忘录的其余部分结构如下：它从第2节中工作的基本原理开始，描述了为什么需要将RTP映射到DCCP。在第3节对本备忘录中使用的约定进行了描述之后，本规范从第4节开始，定义了如何在DCCP中对RTP数据包进行帧化。第5节描述了相关信号。第6节讨论了安全注意事项，第7节讨论了IANA注意事项。
With the widespread adoption of RTP have come concerns that many real-time applications do not implement congestion control, leading to the potential for congestion collapse of the network [15]. The designers of RTP recognised this issue, stating in RFC 3551 that [4]:
随着RTP的广泛采用，人们担心许多实时应用程序无法实现拥塞控制，从而导致网络拥塞崩溃的可能性[15]。RTP的设计者认识到了这个问题，在RFC 3551中指出[4]：
If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
如果正在使用尽力而为服务，RTP接收器应监控数据包丢失，以确保数据包丢失率在可接受的参数范围内。如果通过相同网络路径并经历相同网络条件的TCP流能够达到在合理时间尺度上测量的平均吞吐量，即不小于RTP流所达到的平均吞吐量，则认为丢包是可接受的。可以通过实现拥塞控制机制来适应传输速率（或分层多播会话订阅的层数），或者如果丢失率高得令人无法接受，则通过安排接收机离开会话来满足该条件。
While the goals are clear, the development of TCP friendly congestion control that can be used with RTP and real-time media applications is an open research question with many proposals for new algorithms, but little deployment experience.
虽然目标很明确，但开发可用于RTP和实时媒体应用程序的TCP友好拥塞控制是一个开放的研究问题，有许多新算法的建议，但部署经验很少。
Two approaches have been used to provide congestion control for RTP: 1) develop RTP extensions that incorporate congestion control; and 2) provide mechanisms for running RTP over congestion-controlled transport protocols. An example of the first approach can be found in [16], extending RTP to incorporate feedback information such that TCP Friendly Rate Control (TFRC) [17] can be implemented at the application level. This will allow congestion control to be added to existing applications without operating system or network support, and it offers the flexibility to experiment with new congestion control algorithms as they are developed. Unfortunately, it also passes the complexity of implementing congestion control onto application authors, a burden which many would prefer to avoid.
有两种方法被用来为RTP提供拥塞控制：1）开发包含拥塞控制的RTP扩展；2）提供通过拥塞控制传输协议运行RTP的机制。在[16]中可以找到第一种方法的示例，扩展RTP以包含反馈信息，从而可以在应用程序级别实现TCP友好速率控制（TFRC）[17]。这将允许在没有操作系统或网络支持的情况下将拥塞控制添加到现有的应用程序中，并提供了在开发新的拥塞控制算法时进行实验的灵活性。不幸的是，它还将实现拥塞控制的复杂性传递给了应用程序作者，这是许多人希望避免的负担。
The second approach is to run RTP on a lower-layer transport protocol that provides congestion control. One possibility is to run RTP over TCP, as defined in [5], but the reliable nature of TCP and the dynamics of its congestion control algorithm make this inappropriate for most interactive real-time applications (the Stream Control Transmission Protocol (SCTP) is inappropriate for similar reasons). A better fit for such applications may be to run RTP over DCCP, since DCCP offers unreliable packet delivery and a choice of congestion control. This gives applications the ability to tailor the transport to their needs, taking advantage of better congestion control algorithms as they come available, while passing the complexity of implementation to the operating system. If DCCP should come to be widely available, it is believed these will be compelling advantages. Accordingly, this memo defines a mapping of RTP onto DCCP.
第二种方法是在提供拥塞控制的较低层传输协议上运行RTP。一种可能性是在TCP上运行RTP，如[5]中所定义，但TCP的可靠性及其拥塞控制算法的动态性使其不适用于大多数交互式实时应用程序（流控制传输协议（SCTP）因类似原因不适用）。更适合此类应用程序的可能是在DCCP上运行RTP，因为DCCP提供了不可靠的数据包传递和拥塞控制选择。这使应用程序能够根据需要定制传输，利用可用的更好的拥塞控制算法，同时将实现的复杂性传递给操作系统。如果DCCP能够被广泛使用，相信这些将是引人注目的优势。因此，本备忘录定义了RTP到DCCP的映射。
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 RFC 2119 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[6]中所述进行解释。
The following section defines how RTP and RTP Control Protocol (RTCP) packets can be framed for transport using DCCP. It also describes the differences between RTP sessions and DCCP connections, and the impact these have on the design of applications.
下一节定义如何使用DCCP对RTP和RTP控制协议（RTCP）数据包进行帧传输。它还描述了RTP会话和DCCP连接之间的区别，以及它们对应用程序设计的影响。
Each RTP data packet MUST be conveyed in a single DCCP datagram. Fields in the RTP header MUST be interpreted according to the RTP specification, and any applicable RTP Profile and Payload Format. Header processing is not affected by DCCP framing (in particular,
每个RTP数据包必须在单个DCCP数据报中传输。RTP头中的字段必须根据RTP规范以及任何适用的RTP配置文件和有效负载格式进行解释。头处理不受DCCP帧的影响（特别是，
note that the semantics of the RTP sequence number and the DCCP sequence number are not compatible, and the value of one cannot be inferred from the other).
请注意，RTP序列号和DCCP序列号的语义不兼容，不能从另一个序列号推断其中一个序列号的值）。
A DCCP connection is opened when an end system joins an RTP session, and it remains open for the duration of the session. To ensure NAT bindings are kept open, an end system SHOULD send a zero-length DCCP-Data packet once every 15 seconds during periods when it has no other data to send. This removes the need for RTP no-op packets [18], and similar application-level keepalives, when using RTP over DCCP. This application-level keepalive does not need to be sent if it is known that the DCCP CCID in use provides a transport-level keepalive, or if the application can determine that there are no NAT devices on the path.
当终端系统加入RTP会话时，DCCP连接打开，并且在会话期间保持打开状态。为了确保NAT绑定保持打开状态，终端系统应该在没有其他数据要发送的期间每隔15秒发送一次零长度DCCP数据包。这消除了在DCCP上使用RTP时对RTP no op数据包[18]和类似应用程序级保留的需要。如果已知使用中的DCCP CCID提供传输级别的keepalive，或者如果应用程序可以确定路径上没有NAT设备，则不需要发送此应用程序级别的keepalive。
RTP data packets MUST obey the dictates of DCCP congestion control. In some cases, the congestion control will require a sender to send at a rate below that which the payload format would otherwise use. To support this, an application could use either a rate-adaptive payload format, or a range of payload formats (allowing it to switch to a lower rate format if necessary). Details of the rate adaptation policy for particular payload formats are outside the scope of this memo (but see [19] and [20] for guidance).
RTP数据包必须遵守DCCP拥塞控制的规定。在某些情况下，拥塞控制将要求发送方以低于有效负载格式使用的速率发送。为了支持这一点，应用程序可以使用速率自适应有效负载格式，也可以使用一系列有效负载格式（如果需要，允许它切换到较低速率格式）。特定有效负载格式的速率自适应策略的详细信息不在本备忘录的范围内（但有关指导，请参见[19]和[20]）。
RTP extensions that provide application-level congestion control (e.g., [16]) will conflict with DCCP congestion control, and MUST NOT be used.
提供应用程序级拥塞控制（例如，[16]）的RTP扩展将与DCCP拥塞控制冲突，不得使用。
DCCP allows an application to choose the checksum coverage, using a partial checksum to allow an application to receive packets with corrupt payloads. Some RTP Payload Formats (e.g., [21]) can make use of this feature in conjunction with payload-specific mechanisms to improve performance when operating in environments with frequent non-congestive packet corruption. If such a payload format is used, an RTP end system MAY enable partial checksums at the DCCP layer, in which case the checksum MUST cover at least the DCCP and RTP headers to ensure packets are correctly delivered. Partial checksums MUST NOT be used unless supported by mechanisms in the RTP payload format.
DCCP允许应用程序选择校验和覆盖范围，使用部分校验和允许应用程序接收具有损坏有效负载的数据包。一些RTP有效负载格式（例如，[21]）可以将此功能与特定于有效负载的机制结合使用，以提高在非拥塞性数据包频繁损坏的环境中运行时的性能。如果使用这样的有效负载格式，RTP终端系统可以在DCCP层启用部分校验和，在这种情况下，校验和必须至少覆盖DCCP和RTP报头，以确保数据包被正确传递。除非RTP有效负载格式中的机制支持，否则不得使用部分校验和。
The RTP Control Protocol (RTCP) is used in the standard manner with DCCP. RTCP packets are grouped into compound packets, as described in Section 6.1 of [1], and each compound RTCP packet is transported in a single DCCP datagram.
RTP控制协议（RTCP）以DCCP的标准方式使用。如[1]第6.1节所述，RTCP数据包分组为复合数据包，每个复合RTCP数据包在单个DCCP数据报中传输。
The usual RTCP timing rules apply, with the additional constraint that RTCP packets MUST obey the DCCP congestion control algorithm negotiated for the connection. This can prevent a participant from sending an RTCP packet at the expiration of the RTCP transmission timer if there is insufficient network capacity available. In such cases the RTCP packet is delayed and sent at the earliest possible instant when capacity becomes available. The actual time the RTCP packet was sent is then used as the basis for calculating the next RTCP transmission time.
通常的RTCP定时规则适用，附加的约束是RTCP数据包必须遵守为连接协商的DCCP拥塞控制算法。如果可用网络容量不足，这可以防止参与者在RTCP传输计时器到期时发送RTCP数据包。在这种情况下，当容量可用时，RTCP数据包被延迟并在尽可能早的时间发送。发送RTCP数据包的实际时间随后用作计算下一个RTCP传输时间的基础。
RTCP packets comprise only a small fraction of the total traffic in an RTP session. Accordingly, it is expected that delays in their transmission due to congestion control will not be common, provided the configured nominal "session bandwidth" (see Section 6.2 of [1]) is in line with the bandwidth achievable on the DCCP connection. If, however, the capacity of the DCCP connection is significantly below the nominal session bandwidth, RTCP packets may be delayed enough for participants to time out due to apparent inactivity. In such cases, the session parameters SHOULD be re-negotiated to more closely match the available capacity, for example by performing a re-invite with an updated "b=" line when using the Session Initiation Protocol [22] for signalling.
RTCP数据包只占RTP会话中总流量的一小部分。因此，如果配置的标称“会话带宽”（见[1]第6.2节）与DCCP连接上可实现的带宽一致，则预计由于拥塞控制导致的传输延迟将不常见。但是，如果DCCP连接的容量明显低于标称会话带宽，则RTCP数据包可能会因明显不活动而延迟到参与者超时的程度。在这种情况下，应重新协商会话参数，以更紧密地匹配可用容量，例如，在使用会话启动协议[22]进行信令时，使用更新的“b=”行执行重新邀请。
Note: Since the nominal session bandwidth is chosen based on media codec capabilities, a session where the nominal bandwidth is much larger than the available bandwidth will likely become unusable due to constraints on the media channel, and so require negotiation of a lower bandwidth codec, before it becomes unusable due to constraints on the RTCP channel.
注意：由于标称会话带宽是根据媒体编解码器功能选择的，因此标称带宽远大于可用带宽的会话可能会由于媒体通道的限制而变得不可用，因此需要协商较低带宽的编解码器，在由于RTCP通道上的限制而变得不可用之前。
As noted in Section 17.1 of [2], there is the potential for overlap between information conveyed in RTCP packets and that conveyed in DCCP acknowledgement options. In general this is not an issue since RTCP packets contain media-specific data that is not present in DCCP acknowledgement options, and DCCP options contain network-level data that is not present in RTCP. Indeed, there is no overlap between the five RTCP packet types defined in the RTP specification [1] and the standard DCCP options [2]. There are, however, cases where overlap does occur: most clearly between the Loss RLE Report Blocks defined as part of the RTCP Extended Reports [23] and the DCCP Ack Vector option. If there is overlap between RTCP report packets and DCCP acknowledgements, an application SHOULD use either RTCP feedback or DCCP acknowledgements, but not both (use of both types of feedback will waste available network capacity, but is not otherwise harmful).
如[2]第17.1节所述，RTCP数据包中传输的信息与DCCP确认选项中传输的信息之间可能存在重叠。一般来说，这不是问题，因为RTCP数据包包含DCCP确认选项中不存在的媒体特定数据，而DCCP选项包含RTCP中不存在的网络级数据。实际上，RTP规范[1]和标准DCCP选项[2]中定义的五种RTCP数据包类型之间没有重叠。但是，在某些情况下确实会发生重叠：最明显的是，在定义为RTCP扩展报告[23]一部分的丢失RLE报告块和DCCP Ack Vector选项之间。如果RTCP报告数据包和DCCP确认之间存在重叠，则应用程序应使用RTCP反馈或DCCP确认，但不能同时使用（使用这两种类型的反馈将浪费可用网络容量，但在其他方面无害）。
The obvious mapping of RTP onto DCCP creates two DCCP connections for each RTP flow: one for RTP data packets and one for RTP control packets. A frequent criticism of RTP relates to the number of ports it uses, since large telephony gateways can support more than 32768 RTP flows between pairs of gateways, and so run out of UDP ports. In addition, use of multiple ports complicates NAT traversal. For these reasons, it is RECOMMENDED that the RTP and RTCP traffic for a single RTP session is multiplexed onto a single DCCP connection following the guidelines in [7], where possible (it may not be possible in all circumstances, for example when translating from an RTP stream over a non-DCCP transport that uses conflicting RTP payload types and RTCP packet types).
RTP到DCCP的明显映射为每个RTP流创建了两个DCCP连接：一个用于RTP数据包，另一个用于RTP控制包。RTP经常受到批评，这与它使用的端口数量有关，因为大型电话网关可以在网关对之间支持超过32768个RTP流，因此UDP端口不足。此外，使用多个端口会使NAT遍历复杂化。出于这些原因，建议尽可能按照[7]中的指南将单个RTP会话的RTP和RTCP流量多路传输到单个DCCP连接上（这在所有情况下都不可能，例如，当通过使用冲突RTP有效负载类型和RTCP数据包类型的非DCCP传输从RTP流进行转换时）。
An end system SHOULD NOT assume that it will observe only a single RTP synchronisation source (SSRC) because it is using DCCP framing. An RTP session can span any number of transport connections, and can include RTP mixers or translators bringing other participants into the session. The use of a unicast DCCP connection does not imply that the RTP session will have only two participants, and RTP end systems SHOULD assume that multiple synchronisation sources may be observed when using RTP over DCCP, unless otherwise signalled.
终端系统不应假设它将只观察单个RTP同步源（SSRC），因为它使用DCCP帧。RTP会话可以跨越任意数量的传输连接，并且可以包括RTP混频器或将其他参与者带入会话的转换器。使用单播DCCP连接并不意味着RTP会话将只有两个参与者，并且RTP终端系统应假设在通过DCCP使用RTP时可能观察到多个同步源，除非另有信号指示。
An RTP translator bridging multiple DCCP connections to form a single RTP session needs to be aware of the congestion state of each DCCP connection, and must adapt the media to the available capacity of each. The Codec Control Messages defined in [24] may be used to signal congestion state to the media senders, allowing them to adapt their transmission. Alternatively, media transcoding may be used to perform adaptation: this is computationally expensive, induces delay, and generally gives poor-quality results. Depending on the payload, it might also be possible to use some form of scalable coding.
桥接多个DCCP连接以形成单个RTP会话的RTP转换器需要了解每个DCCP连接的拥塞状态，并且必须使媒体适应每个DCCP连接的可用容量。[24]中定义的编解码器控制消息可用于向媒体发送方发送拥塞状态信号，从而允许它们调整传输。或者，可以使用媒体转码来执行自适应：这在计算上是昂贵的，导致延迟，并且通常给出低质量的结果。根据有效负载的不同，也可以使用某种形式的可伸缩编码。
A single RTP session may also span a DCCP connection and some other type of transport connection. An example might be an RTP over DCCP connection from an RTP end system to an RTP translator, with an RTP over UDP/IP multicast group on the other side of the translator. A second example might be an RTP over DCCP connection that links Public Switched Telephone Network (PSTN) gateways. The issues for such an RTP translator are similar to those when linking two DCCP connections, except that the congestion control algorithms on either side of the translator may not be compatible. Implementation of effective translators for such an environment is non-trivial.
单个RTP会话也可以跨越DCCP连接和其他类型的传输连接。例如，从RTP端系统到RTP转换器的RTP over DCCP连接，在转换器的另一侧有RTP over UDP/IP多播组。第二个示例可能是连接公共交换电话网（PSTN）网关的RTP over DCCP连接。这种RTP转换器的问题与链接两个DCCP连接时的问题类似，只是转换器两侧的拥塞控制算法可能不兼容。在这样的环境中实现有效的翻译人员绝非易事。
In general, there is no conflict between new RTP profiles and DCCP framing, and most RTP profiles can be negotiated for use over DCCP with the following exceptions:
一般来说，新的RTP配置文件和DCCP帧之间没有冲突，大多数RTP配置文件可以协商在DCCP上使用，但以下情况除外：
o An RTP profile that is intolerant of packet corruption may conflict with the DCCP partial checksum feature. An example of this is the integrity protection provided by the RTP/SAVP profile, which cannot be used in conjunction with DCCP partial checksums.
o 不能容忍数据包损坏的RTP配置文件可能与DCCP部分校验和功能冲突。RTP/SAVP配置文件提供的完整性保护就是一个例子，不能与DCCP部分校验和一起使用。
o An RTP profile that mandates a particular non-DCCP lower-layer transport will conflict with DCCP.
o 要求特定非DCCP低层传输的RTP配置文件将与DCCP冲突。
RTP profiles that fall under these exceptions SHOULD NOT be used with DCCP unless the conflicting features can be disabled.
属于这些例外情况的RTP配置文件不应与DCCP一起使用，除非可以禁用冲突的功能。
Of the profiles currently defined, the RTP Profile for Audio and Video Conferences with Minimal Control [4], the Secure Real-time Transport Protocol [8], the Extended RTP Profile for RTCP-based Feedback [9], and the Extended Secure RTP Profile for RTCP-based Feedback [10] MAY be used with DCCP (noting the potential conflict between DCCP partial checksums and the integrity protection provided by the secure RTP variants -- see Section 6).
在当前定义的配置文件中，具有最小控制的音频和视频会议的RTP配置文件[4]、安全实时传输协议[8]、基于RTCP的反馈的扩展RTP配置文件[9]和基于RTCP的反馈的扩展安全RTP配置文件[10]可与DCCP一起使用（注意DCCP部分校验和与安全RTP变体提供的完整性保护之间的潜在冲突——参见第6节）。
The Session Description Protocol (SDP) [3] and the offer/answer model [11] are widely used to negotiate RTP sessions (for example, using the Session Initiation Protocol [22]). This section describes how SDP is used to signal RTP sessions running over DCCP.
会话描述协议（SDP）[3]和提供/应答模型[11]广泛用于协商RTP会话（例如，使用会话发起协议[22]）。本节介绍如何使用SDP向通过DCCP运行的RTP会话发送信号。
SDP uses a media ("m=") line to convey details of the media format and transport protocol used. The ABNF syntax of a media line is as follows (from [3]):
SDP使用媒体（“m=”）行传达所用媒体格式和传输协议的详细信息。媒体线路的ABNF语法如下（见[3]）：
media-field = %x6d "=" media SP port ["/" integer] SP proto
1*(SP fmt) CRLF
media-field = %x6d "=" media SP port ["/" integer] SP proto
1*(SP fmt) CRLF
The proto field denotes the transport protocol used for the media, while the port indicates the transport port to which the media is sent. Following [5] and [12], this memo defines these five values of the proto field to indicate media transported using DCCP:
proto字段表示介质使用的传输协议，而端口表示介质发送到的传输端口。在[5]和[12]之后，本备忘录定义了proto字段的这五个值，以指示使用DCCP传输的介质：
DCCP
DCCP/RTP/AVP
DCCP/RTP/SAVP
DCCP/RTP/AVPF
DCCP/RTP/SAVPF
DCCP
DCCP/RTP/AVP
DCCP/RTP/SAVP
DCCP/RTP/AVPF
DCCP/RTP/SAVPF
The "DCCP" protocol identifier is similar to the "UDP" and "TCP" protocol identifiers and denotes the DCCP transport protocol [2], but not its upper-layer protocol. An SDP "m=" line that specifies the "DCCP" protocol MUST further qualify the application-layer protocol using a "fmt" identifier (the "fmt" namespace is managed in the same manner as for the "UDP" protocol identifier). A single DCCP port is used, as denoted by the port field in the media line. The "DCCP" protocol identifier MUST NOT be used to signal RTP sessions running over DCCP; those sessions MUST use a protocol identifier of the form "DCCP/RTP/..." as described below.
“DCCP”协议标识符类似于“UDP”和“TCP”协议标识符，表示DCCP传输协议[2]，但不表示其上层协议。指定“DCCP”协议的SDP“m=”行必须使用“fmt”标识符进一步限定应用层协议（“fmt”命名空间的管理方式与“UDP”协议标识符的管理方式相同）。使用单个DCCP端口，如媒体行中的端口字段所示。“DCCP”协议标识符不得用于向通过DCCP运行的RTP会话发送信号；这些会话必须使用形式为“DCCP/RTP/…”的协议标识符，如下所述。
The "DCCP/RTP/AVP" protocol identifier refers to RTP using the RTP Profile for Audio and Video Conferences with Minimal Control [4] running over DCCP.
“DCCP/RTP/AVP”协议标识符指的是使用RTP配置文件的RTP，用于音频和视频会议，并在DCCP上运行最小控制[4]。
The "DCCP/RTP/SAVP" protocol identifier refers to RTP using the Secure Real-time Transport Protocol [8] running over DCCP.
“DCCP/RTP/SAVP”协议标识符是指使用在DCCP上运行的安全实时传输协议[8]的RTP。
The "DCCP/RTP/AVPF" protocol identifier refers to RTP using the Extended RTP Profile for RTCP-based Feedback [9] running over DCCP.
“DCCP/RTP/AVPF”协议标识符指使用扩展RTP配置文件的RTP，用于在DCCP上运行的基于RTCP的反馈[9]。
The "DCCP/RTP/SAVPF" protocol identifier refers to RTP using the Extended Secure RTP Profile for RTCP-based Feedback [10] running over DCCP.
“DCCP/RTP/SAVPF”协议标识符指使用扩展安全RTP配置文件的RTP，用于在DCCP上运行的基于RTCP的反馈[10]。
RTP payload formats used with the "DCCP/RTP/AVP", "DCCP/RTP/SAVP", "DCCP/RTP/AVPF", and "DCCP/RTP/SAVPF" protocol identifiers MUST use the payload type number as their "fmt" value. If the payload type number is dynamically assigned, an additional "rtpmap" attribute MUST be included to specify the format name and parameters as defined by the media type registration for the payload format.
与“DCCP/RTP/AVP”、“DCCP/RTP/SAVP”、“DCCP/RTP/AVPF”和“DCCP/RTP/SAVPF”协议标识符一起使用的RTP有效负载格式必须使用有效负载类型号作为其“fmt”值。如果动态分配有效负载类型编号，则必须包含一个附加的“rtpmap”属性，以指定有效负载格式的媒体类型注册所定义的格式名称和参数。
DCCP port 5004 is registered for use by the RTP profiles listed above, and SHOULD be the default port chosen by applications using those profiles. If multiple RTP sessions are active from a host, even-numbered ports in the dynamic range SHOULD be used for the other sessions. If RTCP is to be sent on a separate DCCP connection to RTP, the RTCP connection SHOULD use the next higher destination port number, unless an alternative DCCP port is signalled using the "a=rtcp:" attribute [13]. For improved interoperability, "a=rtcp:" SHOULD be used whenever an alternate DCCP port is used.
DCCP端口5004已注册以供上面列出的RTP配置文件使用，并且应该是使用这些配置文件的应用程序选择的默认端口。如果主机上有多个RTP会话处于活动状态，则动态范围内的偶数端口应用于其他会话。如果RTCP通过单独的DCCP连接发送到RTP，RTCP连接应使用下一个更高的目标端口号，除非使用“a=RTCP:”属性发出替代DCCP端口信号[13]。为了提高互操作性，应在使用备用DCCP端口时使用“a=rtcp:”。
In addition to the port number, specified on the SDP "m=" line, a DCCP connection has an associated service code. A single new SDP attribute ("dccp-service-code") is defined to signal the DCCP service code according to the following ABNF [14]:
除了SDP“m=”行上指定的端口号外，DCCP连接还具有相关的服务代码。定义了一个新的SDP属性（“dccp服务代码”），以根据以下ABNF[14]向dccp服务代码发送信号：
dccp-service-attr = %x61 "=dccp-service-code:" service-code
dccp-service-attr = %x61 "=dccp-service-code:" service-code
service-code = hex-sc / decimal-sc / ascii-sc
service-code = hex-sc / decimal-sc / ascii-sc
hex-sc = %x53 %x43 "=" %x78 *HEXDIG
hex-sc = %x53 %x43 "=" %x78 *HEXDIG
decimal-sc = %x53 %x43 "=" *DIGIT
decimal-sc = %x53 %x43 "=" *DIGIT
ascii-sc = %x53 %x43 ":" *sc-char
ascii-sc = %x53 %x43 ":" *sc-char
sc-char = %d42-43 / %d45-47 / %d63-90 / %d95 / %d97-122
sc-char = %d42-43 / %d45-47 / %d63-90 / %d95 / %d97-122
where DIGIT and HEXDIG are as defined in [14]. The service code is interpreted as defined in Section 8.1.2 of [2] and may be specified using either the hexadecimal, decimal, or ASCII formats. A parser MUST interpret service codes according to their numeric value, independent of the format used to represent them in SDP.
其中，数字和十六进制数的定义见[14]。服务代码按照[2]第8.1.2节的定义进行解释，可以使用十六进制、十进制或ASCII格式进行指定。解析器必须根据服务代码的数值来解释服务代码，这与SDP中用于表示服务代码的格式无关。
The following DCCP service codes are registered for use with RTP:
注册了以下DCCP服务代码，以便与RTP一起使用：
o SC:RTPA (equivalently SC=1381257281 or SC=x52545041): an RTP session conveying audio data (and OPTIONAL multiplexed RTCP)
o SC:RTPA（相当于SC=1381257281或SC=X5255041）：传输音频数据的RTP会话（以及可选的多路复用RTCP）
o SC:RTPV (equivalently SC=1381257302 or SC=x52545056): an RTP session conveying video data (and OPTIONAL multiplexed RTCP)
o SC:RTPV（相当于SC=1381257302或SC=X5255056）：传输视频数据的RTP会话（和可选多路复用RTCP）
o SC:RTPT (equivalently SC=1381257300 or SC=x52545054): an RTP session conveying text media (and OPTIONAL multiplexed RTCP)
o SC:RTPT（相当于SC=1381257300或SC=X5255054）：传输文本媒体的RTP会话（和可选多路复用RTCP）
o SC:RTPO (equivalently SC=1381257295 or SC=x5254504f): an RTP session conveying any other type of media (and OPTIONAL multiplexed RTCP)
o SC:RTPO（相当于SC=1381257295或SC=X525504F）：传输任何其他类型媒体（和可选多路复用RTCP）的RTP会话
o SC:RTCP (equivalently SC=1381253968 or SC=x52544350): an RTCP connection, separate from the corresponding RTP
o SC:RTCP（相当于SC=1381253968或SC=X5254350）：与相应RTP分离的RTCP连接
To ease the job of middleboxes, applications SHOULD use these service codes to identify RTP sessions running within DCCP. The service code SHOULD match the top-level media type signalled for the session
为了简化中间盒的工作，应用程序应该使用这些服务代码来识别在DCCP中运行的RTP会话。服务代码应与为会话发出信号的顶级媒体类型相匹配
(i.e., the SDP "m=" line), with the exception connections using media types other than audio, video, or text, which use SC:RTPO, and connections that transport only RTCP packets, which use SC:RTCP.
（即SDP“m=”行），但使用音频、视频或文本以外的媒体类型的连接（使用SC:RTPO）和仅传输RTCP数据包（使用SC:RTCP）的连接除外。
The "a=dccp-service-code:" attribute is a media-level attribute that is not subject to the charset attribute.
“a=dccp服务代码：”属性是不受字符集属性约束的媒体级属性。
The "a=setup:" attribute indicates which of the endpoints should initiate the DCCP connection establishment (i.e., send the initial DCCP-Request packet). The "a=setup:" attribute MUST be used in a manner comparable with [12], except that DCCP connections are being initiated rather than TCP connections.
“a=setup:”属性指示哪些端点应启动DCCP连接建立（即，发送初始DCCP请求数据包）。“a=setup:”属性必须以与[12]类似的方式使用，除了启动DCCP连接而不是TCP连接。
After the initial offer/answer exchange, the endpoints may decide to re-negotiate various parameters. The "a=connection:" attribute MUST be used in a manner compatible with [12] to decide whether a new DCCP connection needs to be established as a result of subsequent offer/ answer exchanges, or if the existing connection should still be used.
在初始要约/应答交换之后，端点可以决定重新协商各种参数。“a=connection:”属性必须以与[12]兼容的方式使用，以确定是否需要在后续的报价/应答交换后建立新的DCCP连接，或者是否仍应使用现有连接。
A single DCCP connection can be used to transport multiplexed RTP and RTCP packets. Such multiplexing MUST be signalled using an "a=rtcp-mux" attribute according to [7]. If multiplexed RTP and RTCP are not to be used, then the "a=rtcp-mux" attribute MUST NOT be present in the SDP offer, and a separate DCCP connection MUST be opened to transport the RTCP data on a different DCCP port.
单个DCCP连接可用于传输多路复用RTP和RTCP数据包。根据[7]，这种多路复用必须使用“a=rtcp mux”属性发出信号。如果不使用多路复用RTP和RTCP，则SDP产品中不得存在“a=RTCP mux”属性，并且必须打开单独的DCCP连接，以便在不同的DCCP端口上传输RTCP数据。
An offerer at 192.0.2.47 signals its availability for an H.261 video session, using RTP/AVP over DCCP with service code "RTPV" (using the hexadecimal encoding of the service code in the SDP). RTP and RTCP packets are multiplexed onto a single DCCP connection:
192.0.2.47的报价人通过DCCP上的RTP/AVP和服务代码“RTPV”（使用SDP中服务代码的十六进制编码）向H.261视频会话发送可用性信号。RTP和RTCP数据包被多路复用到单个DCCP连接上：
v=0
o=alice 1129377363 1 IN IP4 192.0.2.47
s=-
c=IN IP4 192.0.2.47
t=0 0
m=video 5004 DCCP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC=x52545056
a=setup:passive
a=connection:new
v=0
o=alice 1129377363 1 IN IP4 192.0.2.47
s=-
c=IN IP4 192.0.2.47
t=0 0
m=video 5004 DCCP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC=x52545056
a=setup:passive
a=connection:new
An answerer at 192.0.2.128 receives this offer and responds with the following answer:
192.0.2.128的回答者收到此报价，并回答如下：
v=0
o=bob 1129377364 1 IN IP4 192.0.2.128
s=-
c=IN IP4 192.0.2.128
t=0 0
m=video 9 DCCP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC:RTPV
a=setup:active
a=connection:new
v=0
o=bob 1129377364 1 IN IP4 192.0.2.128
s=-
c=IN IP4 192.0.2.128
t=0 0
m=video 9 DCCP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC:RTPV
a=setup:active
a=connection:new
The end point at 192.0.2.128 then initiates a DCCP connection to port 5004 at 192.0.2.47. DCCP port 5004 is used for both the RTP and RTCP data, and port 5005 is unused. The textual encoding of the service code is used in the answer, and represents the same service code as in the offer.
192.0.2.128处的端点随后在192.0.2.47处启动到端口5004的DCCP连接。DCCP端口5004用于RTP和RTCP数据，端口5005未使用。答案中使用服务代码的文本编码，表示与报价中相同的服务代码。
The security considerations in the RTP specification [1] and any applicable RTP profile (e.g., [4], [8], [9], or [10]) or payload format apply when transporting RTP over DCCP.
当通过DCCP传输RTP时，RTP规范[1]和任何适用的RTP配置文件（例如[4]、[8]、[9]或[10]）或有效负载格式中的安全注意事项适用。
The security considerations in the DCCP specification [2] apply.
DCCP规范[2]中的安全注意事项适用。
The SDP signalling described in Section 5 is subject to the security considerations of [3], [11], [12], [5], and [7].
第5节中描述的SDP信令受[3]、[11]、[12]、[5]和[7]的安全考虑的约束。
The provision of effective congestion control for RTP through use of DCCP is expected to help reduce the potential for denial of service present when RTP flows ignore the advice in [1] to monitor packet loss and reduce their sending rate in the face of persistent congestion.
通过使用DCCP为RTP提供有效的拥塞控制，预计将有助于减少当RTP流忽略[1]中的建议时出现拒绝服务的可能性，以监控数据包丢失，并在面临持续拥塞时降低其发送速率。
There is a potential conflict between the Secure RTP profiles ([8], [10]) and the DCCP partial checksum option, since these profiles introduce, and recommend the use of, message authentication for RTP and RTCP packets. Message authentication codes of the type used by these profiles cannot be used with partial checksums, since any bit error in the DCCP packet payload will cause the authentication check to fail. Accordingly, DCCP partial checksums SHOULD NOT be used in conjunction with Secure Real-time Transport Protocol (SRTP) authentication. The confidentiality features of the basic RTP specification cannot be used with DCCP partial checksums, since bit
安全RTP配置文件（[8]、[10]）和DCCP部分校验和选项之间存在潜在冲突，因为这些配置文件为RTP和RTCP数据包引入并建议使用消息身份验证。这些配置文件使用的类型的消息身份验证代码不能与部分校验和一起使用，因为DCCP数据包有效负载中的任何位错误都将导致身份验证检查失败。因此，DCCP部分校验和不应与安全实时传输协议（SRTP）认证结合使用。基本RTP规范的保密特性不能与DCCP部分校验和一起使用，因为
errors propagate. Also, despite the fact that bit errors do not propagate when using AES in counter mode, the Secure RTP profiles SHOULD NOT be used with DCCP partial checksums, since the profiles require authentication for security, and authentication is incompatible with partial checksums.
错误传播。此外，尽管在计数器模式下使用AES时比特错误不会传播，但安全RTP配置文件不应与DCCP部分校验和一起使用，因为配置文件要求进行安全认证，且认证与部分校验和不兼容。
The following SDP "proto" field identifiers have been registered (see Section 5.1):
已注册以下SDP“proto”字段标识符（见第5.1节）：
Type SDP Name Reference
---- -------- ---------
proto DCCP [RFC5762]
DCCP/RTP/AVP [RFC5762]
DCCP/RTP/SAVP [RFC5762]
DCCP/RTP/AVPF [RFC5762]
DCCP/RTP/SAVPF [RFC5762]
Type SDP Name Reference
---- -------- ---------
proto DCCP [RFC5762]
DCCP/RTP/AVP [RFC5762]
DCCP/RTP/SAVP [RFC5762]
DCCP/RTP/AVPF [RFC5762]
DCCP/RTP/SAVPF [RFC5762]
The following new SDP attribute ("att-field") has been registered:
已注册以下新的SDP属性（“att字段”）：
Contact name: Colin Perkins <csp@csperkins.org>
Contact name: Colin Perkins <csp@csperkins.org>
Attribute name: dccp-service-code
属性名称：dccp服务代码
Long-form attribute name in English: DCCP service code
英文长格式属性名称：DCCP服务代码
Type of attribute: Media level.
属性类型：媒体级别。
Subject to the charset attribute? No.
是否受字符集属性的约束？不
Purpose of the attribute: see RFC 5762, Section 5.2
属性用途：见RFC 5762，第5.2节
Allowed attribute values: see RFC 5762, Section 5.2
允许的属性值：见RFC 5762，第5.2节
The following DCCP service code values have been registered (see Section 5.2):
已注册以下DCCP服务代码值（见第5.2节）：
1381257281 RTPA RTP session conveying audio [RFC5762]
data (and associated RTCP)
1381257302 RTPV RTP session conveying video [RFC5762]
data (and associated RTCP)
1381257300 RTPT RTP session conveying text [RFC5762]
media (and associated RTCP)
1381257295 RTPO RTP session conveying other [RFC5762]
media (and associated RTCP)
1381253968 RTCP RTCP connection, separate from [RFC5762]
the corresponding RTP
1381257281 RTPA RTP session conveying audio [RFC5762]
data (and associated RTCP)
1381257302 RTPV RTP session conveying video [RFC5762]
data (and associated RTCP)
1381257300 RTPT RTP session conveying text [RFC5762]
media (and associated RTCP)
1381257295 RTPO RTP session conveying other [RFC5762]
media (and associated RTCP)
1381253968 RTCP RTCP connection, separate from [RFC5762]
the corresponding RTP
The following DCCP ports have been registered (see Section 5.1):
已注册以下DCCP端口（见第5.1节）：
avt-profile-1 5004/dccp RTP media data [RFC3551, RFC5762] avt-profile-2 5005/dccp RTP control protocol [RFC3551, RFC5762]
avt-profile-1 5004/dccp RTP媒体数据[RFC3551，RFC5762]avt-profile-2 5005/dccp RTP控制协议[RFC3551，RFC5762]
Note: ports 5004/tcp, 5004/udp, 5005/tcp, and 5005/udp have existing registrations, but incorrect descriptions and references. The IANA has updated the existing registrations as follows:
注意：端口5004/tcp、5004/udp、5005/tcp和5005/udp已有注册，但描述和引用不正确。IANA已将现有注册更新如下：
avt-profile-1 5004/tcp RTP media data [RFC3551, RFC4571]
avt-profile-1 5004/udp RTP media data [RFC3551]
avt-profile-2 5005/tcp RTP control protocol [RFC3551, RFC4571]
avt-profile-2 5005/udp RTP control protocol [RFC3551]
avt-profile-1 5004/tcp RTP media data [RFC3551, RFC4571]
avt-profile-1 5004/udp RTP media data [RFC3551]
avt-profile-2 5005/tcp RTP control protocol [RFC3551, RFC4571]
avt-profile-2 5005/udp RTP control protocol [RFC3551]
This work was supported in part by the UK Engineering and Physical Sciences Research Council. Thanks are due to Philippe Gentric, Magnus Westerlund, Sally Floyd, Dan Wing, Gorry Fairhurst, Stephane Bortzmeyer, Arjuna Sathiaseelan, Tom Phelan, Lars Eggert, Eddie Kohler, Miguel Garcia, and the other members of the DCCP working group for their comments.
这项工作得到了英国工程和物理科学研究委员会的部分支持。感谢Philippe Gentric、Magnus Westerlund、Sally Floyd、Dan Wing、Gorry Fairhurst、Stephane Bortzmeyer、Arjuna Sathiaseelan、Tom Phelan、Lars Eggert、Eddie Kohler、Miguel Garcia和DCCP工作组其他成员的评论。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[2] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[2] Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC4340，2006年3月。
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[3] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[4] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[5] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[5] Lazzaro，J.，“面向连接传输上的帧实时传输协议（RTP）和RTP控制协议（RTCP）数据包”，RFC 4571，2006年7月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[7] Perkins，C.和M.Westerlund，“在单个端口上多路复用RTP数据和控制数据包”，RFC 5761，2010年4月。
[8] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[8] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[9] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[9] Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[10] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ SAVPF)", RFC 5124, February 2008.
[10] Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 51242008年2月。
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[11] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[12] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[12] Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 41452005年9月。
[13] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[13] Huitema，C.，“会话描述协议（SDP）中的实时控制协议（RTCP）属性”，RFC 3605，2003年10月。
[14] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[14] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[15] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[15] Floyd，S.和J.Kempf，“IAB对互联网语音流量拥塞控制的关注”，RFC 3714，2004年3月。
[16] Gharai, L., "RTP with TCP Friendly Rate Control", Work in Progress, July 2007.
[16] Gharai，L.，“具有TCP友好速率控制的RTP”，正在进行的工作，2007年7月。
[17] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[17] Floyd，S.，Handley，M.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 5348，2008年9月。
[18] Andreasen, F., Oran, D., and D. Wing, "A No-Op Payload Format for RTP", Work in Progress, May 2005.
[18] Andreasen，F.，Oran，D.，和D.Wing，“RTP的无操作有效载荷格式”，正在进行的工作，2005年5月。
[19] Phelan, T., "Strategies for Streaming Media Applications Using TCP-Friendly Rate Control", Work in Progress, July 2007.
[19] Phelan，T.，“使用TCP友好速率控制的流媒体应用策略”，进展中的工作，2007年7月。
[20] Phelan, T., "Datagram Congestion Control Protocol (DCCP) User Guide", Work in Progress, April 2005.
[20] Phelan，T.，“数据报拥塞控制协议（DCCP）用户指南”，正在进行的工作，2005年4月。
[21] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, April 2007.
[21] Sjoberg，J.，Westerlund，M.，Lakaniemi，A.，和Q.Xie，“自适应多速率（AMR）和自适应多速率宽带（AMR-WB）音频编解码器的RTP有效载荷格式和文件存储格式”，RFC 4867，2007年4月。
[22] 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.
[22] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[23] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[23] Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[24] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", Work in Progress, October 2007.
[24] Wenger，S.，Chandra，U.，Westerlund，M.，和B.Burman，“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”，正在进行的工作，2007年10月。
Author's Address
作者地址
Colin Perkins University of Glasgow Department of Computing Science Glasgow G12 8QQ UK
柯林帕金斯格拉斯哥大学计算科学系格拉斯哥G128QQ英国
EMail: csp@csperkins.org
EMail: csp@csperkins.org