Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 6679 I. Johansson
Category: Standards Track Ericsson
ISSN: 2070-1721 C. Perkins
University of Glasgow
P. O'Hanlon
University of Oxford
K. Carlberg
G11
August 2012
Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 6679 I. Johansson
Category: Standards Track Ericsson
ISSN: 2070-1721 C. Perkins
University of Glasgow
P. O'Hanlon
University of Oxford
K. Carlberg
G11
August 2012
Explicit Congestion Notification (ECN) for RTP over UDP
UDP上RTP的显式拥塞通知（ECN）
Abstract
摘要
This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined.
此备忘录指定如何使用RTP控制协议（RTCP）作为反馈机制，在UDP上运行实时传输协议（RTP）时使用显式拥塞通知（ECN）。它定义了一个用于定期ECN反馈的新RTCP扩展报告（XR）块，一个用于及时报告拥塞事件的新RTCP传输反馈消息，以及一个用于NAT（STUN）扩展的会话遍历实用程序，用于使用交互式连接建立（ICE）的可选初始化方法。还定义了能力协商的信号和程序以及初始化方法。
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/rfc6679.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6679.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Conventions, Definitions, and Acronyms ..........................5
3. Discussion, Requirements, and Design Rationale ..................6
3.1. Requirements ...............................................8
3.2. Applicability ..............................................8
3.3. Interoperability ..........................................12
4. Overview of Use of ECN with RTP/UDP/IP .........................13
5. RTCP Extensions for ECN Feedback ...............................16
5.1. RTP/AVPF Transport-Layer ECN Feedback Packet ..............16
5.2. RTCP XR Report Block for ECN Summary Information ..........19
6. SDP Signalling Extensions for ECN ..............................21
6.1. Signalling ECN Capability Using SDP .......................21
6.2. RTCP ECN Feedback SDP Parameter ...........................26
6.3. XR Block ECN SDP Parameter ................................26
6.4. ICE Parameter to Signal ECN Capability ....................27
7. Use of ECN with RTP/UDP/IP .....................................27
7.1. Negotiation of ECN Capability .............................27
7.2. Initiation of ECN Use in an RTP Session ...................28
7.3. Ongoing Use of ECN within an RTP Session ..................35
7.4. Detecting Failures ........................................38
8. Processing ECN in RTP Translators and Mixers ...................42
8.1. Transport Translators .....................................42
8.2. Fragmentation and Reassembly in Translators ...............43
8.3. Generating RTCP ECN Feedback in Media Transcoders .........45
8.4. Generating RTCP ECN Feedback in Mixers ....................46
9. Implementation Considerations ..................................47
10. IANA Considerations ...........................................47
10.1. SDP Attribute Registration ...............................47
10.2. RTP/AVPF Transport-Layer Feedback Message ................47
10.3. RTCP Feedback SDP Parameter ..............................48
10.4. RTCP XR Report Blocks ....................................48
10.5. RTCP XR SDP Parameter ....................................48
10.6. STUN Attribute ...........................................48
10.7. ICE Option ...............................................48
11. Security Considerations .......................................48
12. Examples of SDP Signalling ....................................51
12.1. Basic SDP Offer/Answer ...................................52
12.2. Declarative Multicast SDP ................................54
13. Acknowledgments ...............................................54
14. References ....................................................55
14.1. Normative References .....................................55
14.2. Informative References ...................................56
1. Introduction ....................................................4
2. Conventions, Definitions, and Acronyms ..........................5
3. Discussion, Requirements, and Design Rationale ..................6
3.1. Requirements ...............................................8
3.2. Applicability ..............................................8
3.3. Interoperability ..........................................12
4. Overview of Use of ECN with RTP/UDP/IP .........................13
5. RTCP Extensions for ECN Feedback ...............................16
5.1. RTP/AVPF Transport-Layer ECN Feedback Packet ..............16
5.2. RTCP XR Report Block for ECN Summary Information ..........19
6. SDP Signalling Extensions for ECN ..............................21
6.1. Signalling ECN Capability Using SDP .......................21
6.2. RTCP ECN Feedback SDP Parameter ...........................26
6.3. XR Block ECN SDP Parameter ................................26
6.4. ICE Parameter to Signal ECN Capability ....................27
7. Use of ECN with RTP/UDP/IP .....................................27
7.1. Negotiation of ECN Capability .............................27
7.2. Initiation of ECN Use in an RTP Session ...................28
7.3. Ongoing Use of ECN within an RTP Session ..................35
7.4. Detecting Failures ........................................38
8. Processing ECN in RTP Translators and Mixers ...................42
8.1. Transport Translators .....................................42
8.2. Fragmentation and Reassembly in Translators ...............43
8.3. Generating RTCP ECN Feedback in Media Transcoders .........45
8.4. Generating RTCP ECN Feedback in Mixers ....................46
9. Implementation Considerations ..................................47
10. IANA Considerations ...........................................47
10.1. SDP Attribute Registration ...............................47
10.2. RTP/AVPF Transport-Layer Feedback Message ................47
10.3. RTCP Feedback SDP Parameter ..............................48
10.4. RTCP XR Report Blocks ....................................48
10.5. RTCP XR SDP Parameter ....................................48
10.6. STUN Attribute ...........................................48
10.7. ICE Option ...............................................48
11. Security Considerations .......................................48
12. Examples of SDP Signalling ....................................51
12.1. Basic SDP Offer/Answer ...................................52
12.2. Declarative Multicast SDP ................................54
13. Acknowledgments ...............................................54
14. References ....................................................55
14.1. Normative References .....................................55
14.2. Informative References ...................................56
This memo outlines how Explicit Congestion Notification (ECN) [RFC3168] can be used for Real-time Transport Protocol (RTP) [RFC3550] flows running over UDP/IP that use the RTP Control Protocol (RTCP) as a feedback mechanism. The solution consists of feedback of ECN congestion experienced markings to the sender using RTCP, verification of ECN functionality end-to-end, and procedures for how to initiate ECN usage. Since the initiation process has some dependencies on the signalling mechanism used to establish the RTP session, a specification for signalling mechanisms using the Session Description Protocol (SDP) [RFC4566] is included.
本备忘录概述了如何将显式拥塞通知（ECN）[RFC3168]用于通过UDP/IP运行的实时传输协议（RTP）[RFC3550]流，该流使用RTP控制协议（RTCP）作为反馈机制。该解决方案包括使用RTCP向发送方反馈ECN拥塞标记，端到端验证ECN功能，以及如何启动ECN使用的程序。由于发起过程对用于建立RTP会话的信令机制有一些依赖性，因此包括使用会话描述协议（SDP）[RFC4566]的信令机制规范。
ECN can be used to minimise the impact of congestion on real-time multimedia traffic. The use of ECN provides a way for the network to send congestion control signals to the media transport without having to impair the media. Unlike packet loss, ECN signals unambiguously indicate congestion to the transport as quickly as feedback delays allow and without confusing congestion with losses that might have occurred for other reasons such as transmission errors, packet-size errors, routing errors, badly implemented middleboxes, policy violations, and so forth.
ECN可用于最小化拥塞对实时多媒体流量的影响。ECN的使用为网络向媒体传输发送拥塞控制信号提供了一种方式，而不必损害媒体。与数据包丢失不同，ECN信号会在反馈延迟允许的情况下尽快明确指示传输拥塞，并且不会将拥塞与可能由于其他原因（如传输错误、数据包大小错误、路由错误、实施不当的中间盒、违反策略等）而发生的丢失混淆。
The introduction of ECN into the Internet requires changes to both the network and transport layers. At the network layer, IP forwarding has to be updated to allow routers to mark packets, rather than discarding them in times of congestion [RFC3168]. In addition, transport protocols have to be modified to inform the sender that ECN-marked packets are being received, so it can respond to the congestion. The Transmission Control Protocol (TCP) [RFC3168], Stream Control Transmission Protocol (SCTP) [RFC4960], and Datagram Congestion Control Protocol (DCCP) [RFC4340] have been updated to support ECN, but to date, there is no specification describing how UDP-based transports, such as RTP [RFC3550], can use ECN. This is due to the lack of feedback mechanisms in UDP. Instead, the signalling control protocol on top of UDP needs to provide that feedback. For RTP, that feedback is provided by RTCP.
将ECN引入互联网需要对网络和传输层进行更改。在网络层，必须更新IP转发，以允许路由器标记数据包，而不是在拥塞时丢弃数据包[RFC3168]。此外，必须修改传输协议，以通知发送方正在接收带有ECN标记的数据包，以便发送方能够响应拥塞。传输控制协议（TCP）[RFC3168]、流控制传输协议（SCTP）[RFC4960]和数据报拥塞控制协议（DCCP）[RFC4340]已经更新以支持ECN，但迄今为止，没有描述基于UDP的传输（如RTP[RFC3550]）如何使用ECN的规范。这是因为UDP中缺少反馈机制。相反，UDP之上的信令控制协议需要提供这种反馈。对于RTP，该反馈由RTCP提供。
The remainder of this memo is structured as follows. We start by describing the conventions, definitions, and acronyms used in this memo in Section 2 and the design rationale and applicability in Section 3. Section 4 gives an overview of how ECN is used with RTP over UDP. RTCP extensions for ECN feedback are defined in Section 5 and SDP signalling extensions in Section 6. The details of how ECN is used with RTP over UDP are defined in Section 7. In Section 8, we describe how ECN is handled in RTP translators and mixers. Section 9 discusses some implementation considerations; Section 10 lists IANA considerations; and Section 11 discusses security considerations.
本备忘录的其余部分结构如下。我们首先在第2节中描述本备忘录中使用的约定、定义和首字母缩略词，并在第3节中描述设计原理和适用性。第4节概述了如何通过UDP将ECN与RTP一起使用。第5节定义了用于ECN反馈的RTCP扩展，第6节定义了SDP信令扩展。第7节详细介绍了如何将ECN与UDP上的RTP一起使用。在第8节中，我们将描述如何在RTP转换器和混频器中处理ECN。第9节讨论了一些实施注意事项；第10节列出了IANA的考虑事项；第11节讨论了安全考虑。
Finally, Section 12 provides some examples of SDP signalling for ECN feedback
最后，第12节提供了一些用于ECN反馈的SDP信令示例
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
Definitions and Abbreviations:
定义和缩写：
Sender: A sender of RTP packets carrying an encoded media stream. The sender can change how the media transmission is performed by varying the media coding or packetisation. It is one endpoint of the ECN control loop.
发送方：携带编码媒体流的RTP数据包的发送方。发送方可以通过改变媒体编码或打包来改变媒体传输的方式。它是ECN控制循环的一个端点。
Receiver: A receiver of RTP packets with the intention to consume the media stream. It sends RTCP feedback on the received stream. It is the other endpoint of the ECN control loop.
接收者：一个RTP数据包的接收者，意图使用媒体流。它在接收到的流上发送RTCP反馈。它是ECN控制循环的另一个端点。
ECN-Capable Host: A sender or receiver of a media stream that is capable of setting and/or processing ECN marks.
支持ECN的主机：媒体流的发送方或接收方，能够设置和/或处理ECN标记。
ECN-Capable Transport (ECT): A transport flow where both sender and receiver are ECN-capable hosts. Packets sent by an ECN-capable transport will be marked as ECT(0) or ECT(1) on transmission. See [RFC3168] for the definition of the ECT(0) and ECT(1) marks.
支持ECN的传输（ECT）：发送方和接收方都是支持ECN的主机的传输流。由支持ECN的传输发送的数据包在传输时将标记为ECT（0）或ECT（1）。有关ECT（0）和ECT（1）标记的定义，请参见[RFC3168]。
ECN-CE: ECN Congestion Experienced mark (see [RFC3168]).
ECN-CE:ECN拥塞经历标记（见[RFC3168]）。
ECN-Capable Packets: Packets with ECN mark set to either ECT(0), ECT(1), or ECN-CE.
支持ECN的数据包：ECN标记设置为ECT（0）、ECT（1）或ECN-CE的数据包。
Not-ECT packets: Packets that are not sent by an ECN-capable transport and are not ECN-CE marked.
非ECT数据包：不由支持ECN的传输发送且未标记ECN-CE的数据包。
ECN-Capable Queue: A queue that supports ECN-CE marking of ECN-capable packets to indicate congestion.
支持ECN的队列：支持ECN-CE标记支持ECN的数据包以指示拥塞的队列。
ECN-Blocking Middlebox: A middlebox that discards ECN-capable packets.
ECN阻塞中间盒：丢弃支持ECN的数据包的中间盒。
ECN-Reverting Middlebox: A middlebox that changes ECN-capable packets to not-ECT packets by removing the ECN mark.
ECN还原中间盒：通过移除ECN标记将支持ECN的数据包更改为非ECT数据包的中间盒。
Note that RTP mixers or translators that operate in such a manner that they terminate or split the ECN control loop will take on the role of receivers or senders. This is further discussed in Section 3.2.
请注意，RTP混频器或转换器以终止或分割ECN控制回路的方式运行，将承担接收器或发送器的角色。第3.2节对此进行了进一步讨论。
ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960], and DCCP [RFC4340] transports. These are all unicast protocols that negotiate the use of ECN during the initial connection establishment handshake (supporting incremental deployment and checking if ECN-marked packets pass all middleboxes on the path). ECN-CE marks are immediately echoed back to the sender by the receiving endpoint using an additional bit in feedback messages, and the sender then interprets the mark as equivalent to a packet loss for congestion control purposes.
ECN已指定用于TCP[RFC3168]、SCTP[RFC4960]和DCCP[RFC4340]传输。这些都是单播协议，它们在初始连接建立握手期间协商ECN的使用（支持增量部署，并检查带有ECN标记的数据包是否通过路径上的所有中间盒）。接收端点使用反馈消息中的附加位立即将ECN-CE标记回传给发送方，然后发送方出于拥塞控制目的将该标记解释为等同于分组丢失。
If RTP is run over TCP, SCTP, or DCCP, it can use the native ECN support provided by those protocols. This memo does not concern itself further with these use cases. However, RTP is more commonly run over UDP. This combination does not currently support ECN, and we observe that it has significant differences from the other transport protocols for which ECN has been specified. These include:
如果RTP通过TCP、SCTP或DCCP运行，它可以使用这些协议提供的本机ECN支持。本备忘录不涉及这些用例。然而，RTP更常见于UDP上运行。这种组合目前不支持ECN，我们观察到它与其他指定了ECN的传输协议有显著的区别。这些措施包括：
Signalling: RTP relies on separate signalling protocols to negotiate parameters before a session can be created and doesn't include an in-band handshake or negotiation at session setup time (i.e., there is no equivalent to the TCP three-way handshake in RTP).
信令：RTP依赖单独的信令协议在创建会话之前协商参数，不包括会话设置时的带内握手或协商（即RTP中没有与TCP三方握手等效的协议）。
Feedback: RTP does not explicitly acknowledge receipt of datagrams. Instead, the RTP Control Protocol (RTCP) provides reception quality feedback, and other back channel communication, for RTP sessions. The feedback interval is generally on the order of seconds, rather than once per network round-trip time (RTT) (although the RTP Audio-Visual Profile with Feedback (RTP/AVPF) profile [RFC4585] allows more rapid feedback in most cases). RTCP is also very much oriented around counting packets, which makes byte-counting congestion algorithms difficult to utilise.
反馈：RTP没有明确确认收到数据报。相反，RTP控制协议（RTCP）为RTP会话提供接收质量反馈和其他反向信道通信。反馈间隔通常以秒为单位，而不是每个网络往返时间（RTT）一次（尽管带有反馈的RTP视听配置文件（RTP/AVPF）配置文件[RFC4585]在大多数情况下允许更快速的反馈）。RTCP也非常注重数据包计数，这使得字节计数拥塞算法难以使用。
Congestion Response: While it is possible to adapt the transmission of many audio/visual streams in response to network congestion, and such adaptation is required by [RFC3550], the dynamics of the congestion response may be quite different to that of TCP or other transport protocols.
拥塞响应：虽然可以调整许多音频/视频流的传输以响应网络拥塞，并且[RFC3550]需要这种调整，但拥塞响应的动态可能与TCP或其他传输协议的动态大不相同。
Middleboxes: The RTP framework explicitly supports the concept of mixers and translators, which are middleboxes that are involved in media transport functions.
中间盒：RTP框架明确支持混音器和翻译器的概念，它们是媒体传输功能所涉及的中间盒。
Multicast: RTP is explicitly a group communication protocol and was designed from the start to support IP multicast (primarily Any-Source Multicast (ASM) [RFC1112], although a recent extension supports Source-Specific Multicast (SSM) [RFC3569] with unicast feedback [RFC5760]).
多播：RTP是一种明确的组通信协议，从一开始就被设计为支持IP多播（主要是任何源多播（ASM）[RFC1112]，尽管最近的扩展支持具有单播反馈[RFC5760]的源特定多播（SSM）[RFC3569]）。
Application Awareness: When ECN support is provided within the transport protocol, the ability of the application to react to congestion is limited, since it has little visibility into the transport layer. By adding support of ECN to RTP using RTCP feedback, the application is made aware of congestion, allowing a wider range of reactions in response to that congestion indication.
应用程序感知：当在传输协议中提供ECN支持时，应用程序对拥塞做出反应的能力是有限的，因为它对传输层的可见性很低。通过使用RTCP反馈向RTP添加对ECN的支持，应用程序可以了解拥塞，从而允许对拥塞指示做出更广泛的响应。
Counting vs. Detecting Congestion: TCP, and the protocols derived from it, are mainly designed to respond in the same way whether they experience a burst of congestion indications within one RTT or just a single congestion indication, whereas real-time applications may be concerned with the amount of congestion experienced and whether it is distributed smoothly or in bursts. When feedback of ECN was added to TCP [RFC3168], the receiver was designed to flip the echo congestion experienced (ECE) flag to 1 for a whole RTT then flop it back to zero. ECN feedback in RTCP, however, will need to report a count of how much congestion has been experienced within an RTCP reporting period, irrespective of round-trip times.
计数与检测拥塞：TCP及其派生的协议主要用于以相同的方式响应一个RTT内的突发拥塞指示或仅一个拥塞指示，然而，实时应用程序可能关注所经历的拥塞量，以及它是平滑分布还是以突发方式分布。当ECN的反馈被添加到TCP[RFC3168]时，接收器被设计为在整个RTT中将ECE标志翻转为1，然后将其翻转回零。然而，无论往返时间如何，RTCP中的ECN反馈需要报告RTCP报告期内经历了多少拥塞。
These differences significantly alter the shape of ECN support in RTP over UDP compared to ECN support in TCP, SCTP, and DCCP but do not invalidate the need for ECN support.
与TCP、SCTP和DCCP中的ECN支持相比，这些差异显著地改变了UDP上RTP中ECN支持的形状，但不会使ECN支持的需求无效。
ECN support is more important for RTP sessions than, for instance, is the case for many applications over TCP. This is because the impact of packet loss in real-time audio-visual media flows is highly visible to users. For TCP-based applications, however, TCP will retransmit lost packets, and while extra delay is incurred by having packets dropped rather than ECN-CE marked, the loss is repaired. Effective ECN support for RTP flows running over UDP will allow real-time audio-visual applications to respond to the onset of congestion before routers are forced to drop packets, allowing those applications to control how they reduce their transmission rate and hence media quality, rather than responding to and trying to conceal the effects of unpredictable packet loss. Furthermore, widespread deployment for ECN and active queue management in routers, should it occur, can potentially reduce unnecessary queuing delays in routers, lowering the round-trip time and benefiting interactive applications of RTP, such as voice telephony.
例如，对于RTP会话，ECN支持比TCP上的许多应用程序更重要。这是因为实时视听媒体流中的数据包丢失对用户的影响非常明显。但是，对于基于TCP的应用程序，TCP将重新传输丢失的数据包，并且由于丢弃数据包而不是标记ECN-CE而产生额外的延迟，则会修复丢失。对UDP上运行的RTP流的有效ECN支持将允许实时视听应用程序在路由器被迫丢弃数据包之前响应拥塞的出现，从而允许这些应用程序控制如何降低传输速率，从而降低媒体质量，而不是对不可预测的数据包丢失做出反应并试图掩盖其影响。此外，如果在路由器中广泛部署ECN和主动队列管理，可能会减少路由器中不必要的排队延迟，降低往返时间，并有利于RTP的交互式应用，如语音电话。
Considering ECN, transport protocols supporting ECN, and RTP-based applications, one can create a set of requirements that must be satisfied to at least some degree if ECN is to be used by RTP over UDP.
考虑到ECN、支持ECN的传输协议和基于RTP的应用程序，如果RTP要通过UDP使用ECN，可以创建一组至少在某种程度上必须满足的需求。
o REQ 1: A mechanism must exist to negotiate and initiate the use of ECN for RTP/UDP/IP sessions so that an RTP sender will not send packets with ECT in the IP header unless it knows that all potential receivers will understand any ECN-CE indications they might receive.
o REQ 1：必须存在协商和启动RTP/UDP/IP会话ECN使用的机制，以便RTP发送方不会在IP报头中发送带有ECT的数据包，除非它知道所有潜在接收方将理解他们可能接收到的任何ECN-CE指示。
o REQ 2: A mechanism must exist to feed back the reception of any packets that are ECN-CE marked to the packet sender.
o REQ 2：必须存在一种机制，用于将ECN-CE标记的任何数据包的接收反馈给数据包发送方。
o REQ 3: The provided mechanism should minimise the possibility of cheating (either by the sender or receiver).
o 要求3：提供的机制应尽量减少作弊的可能性（发送方或接收方）。
o REQ 4: Some detection and fallback mechanism should exist to avoid loss of communication due to the attempted usage of ECN in case an intermediate node clears ECT or drops packets that are ECT marked.
o REQ 4：应存在一些检测和回退机制，以避免在中间节点清除ECT或丢弃带有ECT标记的数据包时，由于尝试使用ECN而导致通信丢失。
o REQ 5: Negotiation of ECN should not significantly increase the time taken to negotiate and set up the RTP session (an extra RTT before the media can flow is unlikely to be acceptable for some use cases).
o REQ 5:ECN协商不应显著增加协商和设置RTP会话所需的时间（对于某些用例，在介质可以流动之前额外的RTT不太可能被接受）。
o REQ 6: Negotiation of ECN should not cause media clipping at the start of a session.
o 请求6：ECN协商不应在会话开始时导致媒体剪辑。
The following sections describe how these requirements can be met for RTP over UDP.
以下各节描述如何通过UDP实现RTP满足这些要求。
The use of ECN with RTP over UDP is dependent on negotiation of ECN capability between the sender and receiver(s) and validation of ECN support in all elements on the network path(s) traversed. RTP is used in a heterogeneous range of network environments and topologies, with different signalling protocols. The mechanisms defined here make it possible to verify support for ECN in each of these environments, irrespective of the topology.
将ECN与UDP上的RTP结合使用取决于发送方和接收方之间的ECN能力协商，以及所穿越网络路径上所有元素的ECN支持验证。RTP用于具有不同信令协议的各种网络环境和拓扑中。这里定义的机制使得在这些环境中验证对ECN的支持成为可能，而与拓扑无关。
Due to the need for each RTP sender that intends to use ECN with RTP to track all participants in the RTP session, the sub-sampling of the group membership as specified by "Sampling of the Group Membership in RTP" [RFC2762] MUST NOT be used.
由于每个RTP发送方需要将ECN与RTP一起使用来跟踪RTP会话中的所有参与者，因此不得使用“RTP中的组成员资格抽样”[RFC2762]中规定的组成员资格的子抽样。
The use of ECN is further dependent on a capability of the RTP media flow to react to congestion signalled by ECN-marked packets. Depending on the application, media codec, and network topology, this adaptation can occur in various forms and at various nodes. As an example, the sender can change the media encoding, the receiver can change the subscription to a layered encoding, or either reaction can be accomplished by a transcoding middlebox. [RFC5117] identifies seven topologies in which RTP sessions may be configured and which may affect the ability to use ECN:
ECN的使用还取决于RTP媒体流对由ECN标记的分组发出的拥塞信号作出反应的能力。根据应用程序、媒体编解码器和网络拓扑，这种自适应可以以各种形式在各种节点上发生。例如，发送方可以更改媒体编码，接收方可以将订阅更改为分层编码，或者任何一种反应都可以通过转码中间盒来完成。[RFC5117]确定了七种拓扑结构，其中可以配置RTP会话，并且可能影响ECN的使用能力：
Topo-Point-to-Point: This utilises standard unicast flows. ECN may be used with RTP in this topology in an analogous manner to its use with other unicast transport protocols, with RTCP conveying ECN feedback messages.
Topo点对点：这使用标准单播流。在该拓扑中，ECN可与RTP以类似于其与其他单播传输协议的使用的方式一起使用，RTCP传送ECN反馈消息。
Topo-Multicast: This is either an Any-Source Multicast (ASM) group [RFC3569] with potentially several active senders and multicast RTCP feedback or a Source-Specific Multicast (SSM) group [RFC4607] with a single distribution source and unicast RTCP feedback from receivers. RTCP is designed to scale to large group sizes while avoiding feedback implosion (see Section 6.2 of [RFC3550], [RFC4585], and [RFC5760]) and can be used by a sender to determine if all its receivers, and the network paths to those receivers, support ECN (see Section 7.2). It is somewhat more difficult to determine if all network paths from all senders to all receivers support ECN. Accordingly, we allow ECN to be used by an RTP sender using multicast UDP provided the sender has verified that the paths to all its known receivers support ECN, irrespective of whether the paths from other senders to their receivers support ECN ("all its known receivers" are all the synchronisation sources (SSRCs) from which the RTP sender has received RTP or RTCP in the last five reporting intervals, i.e., they have not timed out). Note that group membership may change during the lifetime of a multicast RTP session, potentially introducing new receivers that are not ECN capable or have a path that doesn't support ECN. Senders must use the mechanisms described in Section 7.4 to check that all receivers, and the network paths traversed to reach those receivers, continue to support ECN, and they need to fallback to non-ECN use if any receivers join that do not.
拓扑多播：这是一个具有多个活动发送方和多播RTCP反馈的任意源多播（ASM）组[RFC3569]，或一个具有单个分发源和来自接收方的单播RTCP反馈的源特定多播（SSM）组[RFC4607]。RTCP设计用于扩展到大组大小，同时避免反馈内爆（见[RFC3550]、[RFC4585]和[RFC5760]第6.2节），发送方可使用RTCP确定其所有接收机以及到这些接收机的网络路径是否支持ECN（见第7.2节）。确定从所有发送方到所有接收方的所有网络路径是否都支持ECN有些困难。因此，我们允许RTP发送方使用多播UDP使用ECN，前提是发送方已验证到其所有已知接收器的路径支持ECN，而不管从其他发送方到其接收器的路径是否支持ECN（“其所有已知接收器”都是同步源（SSRC）RTP发送方在最近五个报告间隔内已从中收到RTP或RTCP，即未超时）。请注意，在多播RTP会话的生命周期内，组成员身份可能会发生变化，从而可能引入不支持ECN的新接收器或具有不支持ECN的路径的新接收器。发送方必须使用第7.4节中描述的机制来检查所有接收方以及为到达这些接收方而穿越的网络路径是否继续支持ECN，如果任何接收方加入了不支持ECN的网络，则发送方需要退回到非ECN使用。
SSM groups that use unicast RTCP feedback [RFC5760] do need a few extra considerations. This topology can have multiple media senders that provide traffic to the distribution source (DS) and are separated from the DS. There can also be multiple feedback targets. The requirement for using ECN for RTP in this topology is that the media sender must be provided the feedback from the receivers. It may be in aggregated form from the feedback targets. We will not mention this SSM use case in the below text
使用单播RTCP反馈[RFC5760]的SSM组确实需要一些额外的注意事项。此拓扑可以有多个媒体发送器，它们向分发源（DS）提供流量，并与DS分离。也可以有多个反馈目标。在这种拓扑结构中，将ECN用于RTP的要求是必须向媒体发送方提供来自接收方的反馈。它可以是来自反馈目标的聚合形式。在下面的文本中，我们不会提到这个SSM用例
specifically, but when actions are required by the media source, they also apply to the case of SSM where the RTCP feedback goes to the feedback target.
具体而言，但当媒体源需要采取行动时，它们也适用于SSM的情况，其中RTCP反馈到反馈目标。
The mechanisms defined in this memo support multicast groups but are known to be conservative and don't scale to large groups. This is primarily because we require all members of the group to demonstrate that they can make use of ECN before the sender is allowed to send ECN-marked packets, since allowing some non-ECN-capable receivers causes fairness issues when the bottleneck link is shared by ECN and non-ECN flows that we have not (yet) been able to satisfactorily address. The rules regarding Determination of ECN Support in Section 7.2.1 may be relaxed in a future version of this specification to improve scaling once these issues have been resolved.
本备忘录中定义的机制支持多播组，但已知是保守的，不能扩展到大型组。这主要是因为我们要求组中的所有成员在允许发送方发送带有ECN标记的数据包之前证明他们可以使用ECN，因为当瓶颈链路由ECN和非ECN流共享时，允许一些不具备ECN能力的接收方会导致公平性问题，而我们还没有（尚未）这样做我们能够令人满意地解决这个问题。在本规范的未来版本中，可放宽第7.2.1节中关于确定ECN支持的规则，以在解决这些问题后改进扩展性。
Topo-Translator: An RTP translator is an RTP-level middlebox that is invisible to the other participants in the RTP session (although it is usually visible in the associated signalling session). There are two types of RTP translators: those that do not modify the media stream and are concerned with transport parameters, for example, a multicast to unicast gateway; and those that do modify the media stream, for example, transcoding between different media codecs. A single RTP session traverses the translator, and the translator must rewrite RTCP messages passing through it to match the changes it makes to the RTP data packets. A legacy, ECN-unaware, RTP translator is expected to ignore the ECN bits on received packets and to set the ECN bits to not-ECT when sending packets, thus causing ECN negotiation on the path containing the translator to fail (any new RTP translator that does not wish to support ECN may do so similarly). An ECN-aware RTP translator may act in one of three ways:
Topo Translator:RTP Translator是RTP级别的中间盒，RTP会话中的其他参与者看不见它（尽管它通常在相关的信令会话中可见）。有两种类型的RTP转换器：不修改媒体流且与传输参数有关的RTP转换器，例如，多播到单播网关；还有那些修改媒体流的，例如，在不同的媒体编解码器之间进行转码。单个RTP会话遍历转换器，转换器必须重写通过它的RTCP消息，以匹配它对RTP数据包所做的更改。传统的、不知道ECN的RTP转换器在发送数据包时会忽略接收到的数据包上的ECN位，并将ECN位设置为not ECT，从而导致包含转换器的路径上的ECN协商失败（任何不希望支持ECN的新RTP转换器都可以类似地这样做）。感知ECN的RTP翻译器可采用以下三种方式之一：
* If the translator does not modify the media stream, it should copy the ECN bits unchanged from the incoming to the outgoing datagrams, unless it is overloaded and experiencing congestion, in which case it may mark the outgoing datagrams with an ECN-CE mark. Such a translator passes RTCP feedback unchanged. See Section 8.1.
* 如果翻译器不修改媒体流，它应该将ECN位从传入数据报复制到传出数据报，除非它过载并遇到拥塞，在这种情况下，它可以用ECN-CE标记传出数据报。这样的翻译器不改变地传递RTCP反馈。见第8.1节。
* If the translator modifies the media stream to combine or split RTP packets but does not otherwise transcode the media, it must manage the ECN bits in a way analogous to that described in Section 5.3 of [RFC3168]. See Section 8.2 for details.
* 如果翻译器修改媒体流以合并或拆分RTP数据包，但没有对媒体进行转码，则翻译器必须以类似于[RFC3168]第5.3节所述的方式管理ECN位。详见第8.2节。
* If the translator is a media transcoder, or otherwise modifies the content of the media stream, the output RTP media stream may have radically different characteristics than the input RTP
* 如果转换器是媒体转码器，或者以其他方式修改媒体流的内容，则输出RTP媒体流可以具有与输入RTP完全不同的特性
media stream. Each side of the translator must then be considered as a separate transport connection, with its own ECN processing. This requires the translator to interpose itself into the ECN negotiation process, effectively splitting the connection into two parts with their own negotiation. Once negotiation has been completed, the translator must generate RTCP ECN feedback back to the source based on its own reception and must respond to RTCP ECN feedback received from the receiver(s) (see Section 8.3).
媒体流。然后，必须将转换器的每一侧视为一个单独的传输连接，具有自己的ECN处理。这要求译者介入ECN协商过程，通过自己的协商有效地将连接分成两部分。协商完成后，翻译人员必须根据自己的接收情况生成RTCP ECN反馈回源，并且必须对从接收方收到的RTCP ECN反馈作出响应（见第8.3节）。
It is recognised that ECN and RTCP processing in an RTP translator that modifies the media stream is non-trivial.
人们认识到，修改媒体流的RTP转换器中的ECN和RTCP处理是非常重要的。
Topo-Mixer: A mixer is an RTP-level middlebox that aggregates multiple RTP streams, mixing them together to generate a new RTP stream. The mixer is visible to the other participants in the RTP session and is also usually visible in the associated signalling session. The RTP flows on each side of the mixer are treated independently for ECN purposes, with the mixer generating its own RTCP ECN feedback and responding to ECN feedback for data it sends. Since unicast transport between the mixer and any endpoint are treated independently, it would seem reasonable to allow the transport on one side of the mixer to use ECN, while the transport on the other side of the mixer is not ECN capable, if this is desired. See Section 8.4 for details on how mixers should process ECN.
Topo Mixer：混合器是一个RTP级别的中间盒，它聚合多个RTP流，将它们混合在一起以生成新的RTP流。该混音器对RTP会话中的其他参与者可见，并且通常在相关的信令会话中也可见。出于ECN目的，混合器每侧的RTP流被独立处理，混合器生成自己的RTCP ECN反馈，并对其发送的数据响应ECN反馈。由于混合器和任何端点之间的单播传输是独立处理的，因此如果需要，允许混合器一侧的传输使用ECN似乎是合理的，而混合器另一侧的传输不支持ECN。有关混合器应如何处理ECN的详细信息，请参见第8.4节。
Topo-Video-switch-MCU: A video-switching Multipoint Control Unit (MCU) receives several RTP flows, but forwards only one of those flows onwards to the other participants at a time. The flow that is forwarded changes during the session, often based on voice activity. Since only a subset of the RTP packets generated by a sender are forwarded to the receivers, a video-switching MCU can break ECN negotiation (the success of the ECN negotiation may depend on the voice activity of the participant at the instant the negotiation takes place - shout if you want ECN). It also breaks congestion feedback and response, since RTP packets are dropped by the MCU depending on voice activity rather than network congestion. This topology is widely used in legacy products but is NOT RECOMMENDED for new implementations and SHALL NOT be used with ECN.
Topo视频开关MCU：视频开关多点控制单元（MCU）接收多个RTP流，但一次仅将其中一个流转发给其他参与者。在会话期间转发的流会发生变化，通常基于语音活动。由于只有发送方生成的RTP数据包的一个子集被转发到接收方，视频交换MCU可以中断ECN协商（ECN协商的成功可能取决于协商发生时参与者的语音活动-如果需要ECN，则呼喊）。它还中断了拥塞反馈和响应，因为MCU根据语音活动而不是网络拥塞丢弃RTP数据包。此拓扑广泛用于传统产品，但不建议用于新的实现，并且不应与ECN一起使用。
Topo-RTCP-terminating-MCU: In this scenario, each participant runs an RTP point-to-point session between itself and the MCU. Each of these sessions is treated independently for the purposes of ECN and RTCP feedback, potentially with some using ECN and some not.
Topo RTCP终止MCU：在这种情况下，每个参与者在自身和MCU之间运行RTP点对点会话。出于ECN和RTCP反馈的目的，这些会话中的每一个都是独立处理的，可能有些使用ECN，有些不使用。
Topo-Asymmetric: It is theoretically possible to build a middlebox that is a combination of an RTP mixer in one direction and an RTP translator in the other. To quote [RFC5117], "This topology is so problematic and it is so easy to get the RTCP processing wrong, that it is NOT RECOMMENDED to implement this topology".
拓扑不对称：理论上可以构建一个中间盒，它是一个方向上的RTP混频器和另一个方向上的RTP转换器的组合。引用[RFC5117]，“此拓扑结构问题严重，很容易使RTCP处理出错，因此不建议实施此拓扑结构”。
These topologies may be combined within a single RTP session.
这些拓扑可以在单个RTP会话中组合。
The ECN mechanism defined in this memo is applicable to both sender-and receiver-controlled congestion algorithms. The mechanism ensures that both senders and receivers will know about ECN-CE markings and any packet losses. Thus, the actual decision point for the congestion control is not relevant. This is a great benefit as the rate of an RTP session can be varied in a number of ways, for example, a unicast media sender might use TCP Friendly Rate Control (TFRC) [RFC5348] or some other algorithm, while a multicast session could use a sender-based scheme adapting to the lowest common supported rate or a receiver-driven mechanism using layered coding to support more heterogeneous paths.
本备忘录中定义的ECN机制适用于发送方和接收方控制的拥塞算法。该机制确保发送方和接收方都知道ECN-CE标记和任何数据包丢失。因此，拥塞控制的实际决策点并不相关。这是一个很大的好处，因为RTP会话的速率可以以多种方式变化，例如，单播媒体发送方可以使用TCP友好速率控制（TFRC）[RFC5348]或其他一些算法，而多播会话可以使用基于发送方的方案来适应最低的公共支持速率，或者使用分层编码的接收方驱动机制来支持更多的异构路径。
To ensure timely feedback of ECN-CE-marked packets when needed, this mechanism requires support for the RTP/AVPF profile [RFC4585] or any of its derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/ AVP profile [RFC3551] does not allow any early or immediate transmission of RTCP feedback and has a minimal RTCP interval whose default value (5 seconds) is many times the normal RTT between sender and receiver.
为确保在需要时及时反馈ECN CE标记的数据包，该机制需要支持RTP/AVPF配置文件[RFC4585]或其任何衍生工具，如RTP/SAVPF[RFC5124]。标准RTP/AVP配置文件[RFC3551]不允许提前或立即传输RTCP反馈，并且具有最小RTCP间隔，其默认值（5秒）是发送方和接收方之间正常RTT的许多倍。
To ensure interoperability for this specification, there is need for at least one common initialisation method for all implementations. Since initialisation using RTP and RTCP (Section 7.2.1) is the one method that works in all cases, although it is not optimal for all uses, it is selected as the mandatory-to-implement initialisation method. This method requires both the RTCP XR extension and the ECN feedback format, which require the RTP/AVPF profile to ensure timely feedback.
为确保本规范的互操作性，所有实现至少需要一种通用的初始化方法。由于使用RTP和RTCP（第7.2.1节）进行初始化是一种在所有情况下都有效的方法，尽管它并非适用于所有用途，但它被选为强制实施初始化方法。此方法需要RTCP XR扩展和ECN反馈格式，这需要RTP/AVPF配置文件以确保及时反馈。
When one considers all the uses of ECN for RTP, it is clear that congestion control mechanisms exist that are receiver driven only (Section 7.3.3). These congestion control mechanisms do not require timely feedback of congestion events to the sender. If such a congestion control mechanism is combined with an initialisation method that also doesn't require timely feedback using RTCP, like the leap-of-faith method (Section 7.2.3) or the ICE-based method (Section 7.2.2), then neither the ECN feedback format nor the RTP/ AVPF profile would appear to be needed. However, fault detection can
当我们考虑到ECN在RTP中的所有用途时，显然存在仅由接收器驱动的拥塞控制机制（第7.3.3节）。这些拥塞控制机制不需要将拥塞事件及时反馈给发送方。如果将这种拥塞控制机制与不需要使用RTCP及时反馈的初始化方法相结合，如信仰飞跃法（第7.2.3节）或基于ICE的方法（第7.2.2节），则似乎不需要ECN反馈格式或RTP/AVPF配置文件。但是，故障检测可以
be greatly improved by using receiver-side detection (Section 7.4.1) and early reporting of such cases using the ECN feedback mechanism.
通过使用接收器端检测（第7.4.1节）和使用ECN反馈机制提前报告此类情况，可以大大提高效率。
For interoperability, we mandate the implementation of the RTP/AVPF profile, with both RTCP extensions and the necessary signalling to support a common operations mode. This specification recommends the use of RTP/AVPF in all cases as negotiation of the common interoperability point requires RTP/AVPF, mixed negotiation of RTP/ AVP and RTP/AVPF depending on other SDP attributes in the same media block is difficult, and the fact that fault detection can be improved when using RTP/AVPF.
对于互操作性，我们要求实施RTP/AVPF配置文件，包括RTCP扩展和必要的信令，以支持通用操作模式。本规范建议在所有情况下使用RTP/AVPF，因为公共互操作性点的协商需要RTP/AVPF，RTP/AVP和RTP/AVPF的混合协商取决于同一媒体块中的其他SDP属性是困难的，并且使用RTP/AVPF时可以改进故障检测。
The use of the ECN feedback format is also recommended, but cases exist where its use is not required because timely feedback is not needed. These will be explicitly noted using the phrase "no timely feedback required" and generally occur in combination with receiver-driven congestion control and with the leap-of-faith and ICE-based initialisation methods. We also note that any receiver-driven congestion control solution that still requires RTCP for signalling of any adaptation information to the sender will still require RTP/ AVPF for timeliness.
也建议使用ECN反馈格式，但存在由于不需要及时反馈而不需要使用的情况。将使用短语“无需及时反馈”明确指出这些问题，通常与接收器驱动的拥塞控制、leap of faith和基于ICE的初始化方法结合使用。我们还注意到，任何仍然需要RTCP向发送方发送任何自适应信息的接收器驱动的拥塞控制解决方案仍然需要RTP/AVPF以确保及时性。
The solution for using ECN with RTP over UDP/IP consists of four different pieces that together make the solution work:
通过UDP/IP将ECN与RTP结合使用的解决方案由四个不同部分组成，它们共同构成了解决方案：
1. Negotiation of the capability to use ECN with RTP/UDP/IP
1. 协商将ECN与RTP/UDP/IP结合使用的能力
2. Initiation and initial verification of ECN-capable transport
2. ECN能力传输的启动和初始验证
3. Ongoing use of ECN within an RTP session
3. 在RTP会话中持续使用ECN
4. Handling of dynamic behaviour through failure detection, verification, and fallback
4. 通过故障检测、验证和回退处理动态行为
Before an RTP session can be created, a signalling protocol is used to negotiate or at least configure session parameters (see Section 7.1). In some topologies, the signalling protocol can also be used to discover the other participants. One of the parameters that must be agreed is the capability of a participant to support ECN. Note that all participants having the capability of supporting ECN does not necessarily imply that ECN is usable in an RTP session, since there may be middleboxes on the path between the participants that don't pass ECN-marked packets (for example, a firewall that blocks traffic with the ECN bits set). This document defines the information that needs to be negotiated and provides a mapping to SDP for use in both declarative and offer/answer contexts.
在创建RTP会话之前，使用信令协议协商或至少配置会话参数（见第7.1节）。在某些拓扑中，信令协议还可用于发现其他参与者。必须商定的参数之一是参与者支持ECN的能力。请注意，具有支持ECN能力的所有参与者并不一定意味着ECN在RTP会话中可用，因为参与者之间的路径上可能存在不传递带有ECN标记的数据包的中间盒（例如，使用ECN位集阻止通信的防火墙）。本文档定义了需要协商的信息，并提供了到SDP的映射，以便在声明性和提供/应答上下文中使用。
When a sender joins a session for which all participants claim to support ECN, it needs to verify that the ECN support is usable. There are three ways in which this verification can be done:
当发送方加入所有参与者都声称支持ECN的会话时，它需要验证ECN支持是否可用。可通过三种方式进行验证：
o The sender may generate a (small) subset of its RTP data packets with the ECN field of the IP header set to ECT(0) or ECT(1). Each receiver will then send an RTCP feedback packet indicating the reception of the ECT-marked RTP packets. Upon reception of this feedback from each receiver it knows of, the sender can consider ECN functional for its traffic. Each sender does this verification independently. When a new receiver joins an existing RTP session, it will send RTCP reports in the usual manner. If those RTCP reports include ECN information, verification will have succeeded, and sources can continue to send ECT packets. If not, verification fails, and each sender MUST stop using ECN (see Section 7.2.1 for details).
o 发送方可以生成其RTP数据分组的（小）子集，其中IP报头的ECN字段设置为ECT（0）或ECT（1）。然后，每个接收器将发送一个RTCP反馈数据包，指示接收到ECT标记的RTP数据包。当接收到来自它知道的每个接收机的反馈时，发送方可以考虑ECN功能来实现其业务。每个发送方都独立进行此验证。当新接收方加入现有RTP会话时，它将以通常的方式发送RTCP报告。如果这些RTCP报告包含ECN信息，则验证将成功，来源可以继续发送ECT数据包。否则，验证将失败，每个发送方必须停止使用ECN（有关详细信息，请参阅第7.2.1节）。
o Alternatively, ECN support can be verified during an initial end-to-end STUN exchange (for example, as part of ICE connection establishment). After having verified connectivity without ECN capability, an extra STUN exchange, this time with the ECN field set to ECT(0) or ECT(1), is performed on the candidate path that is about to be used. If successful, the path's capability to convey ECN-marked packets is verified. A new STUN attribute is defined to convey feedback that the ECT-marked STUN request was received (see Section 7.2.2), along with an ICE signalling option (Section 6.4) to indicate that the check is to be performed.
o 或者，可以在初始端到端STUN交换期间验证ECN支持（例如，作为ICE连接建立的一部分）。在验证无ECN功能的连接后，将在即将使用的候选路径上执行额外的STUN交换，这次ECN字段设置为ECT（0）或ECT（1）。如果成功，则验证路径传输带有ECN标记的数据包的能力。定义了一个新的STUN属性，以传达接收到ECT标记的STUN请求的反馈（见第7.2.2节），以及ICE信号选项（第6.4节），以指示将执行检查。
o Thirdly, the sender may make a leap of faith that ECN will work. This is only recommended for applications that know they are running in controlled environments where ECN functionality has been verified through other means. In this mode, it is assumed that ECN works, and the system reacts to failure indicators if the assumption proved wrong. The use of this method relies on a high confidence that ECN operation will be successful or an application where failure is not serious. The impact on the network and other users must be considered when making a leap of faith, so there are limitations on when this method is allowed (see Section 7.2.3).
o 第三，发送者可能会对ECN将起作用的信念产生飞跃。这仅建议应用程序知道它们正在受控环境中运行，在受控环境中，ECN功能已通过其他方式验证。在此模式下，假设ECN工作，如果假设被证明是错误的，系统会对故障指示灯作出反应。该方法的使用依赖于对ECN操作成功或故障不严重的应用的高度信心。在进行信仰飞跃时，必须考虑对网络和其他用户的影响，因此，这种方法何时被允许存在限制（见第7.2.3节）。
The first mechanism, using RTP with RTCP feedback, has the advantage of working for all RTP sessions, but the disadvantages of potential clipping if ECN-marked RTP packets are discarded by middleboxes and slow verification of ECN support. The STUN-based mechanism is faster to verify ECN support but only works in those scenarios supported by end-to-end STUN, such as within an ICE exchange. The third one, leap of faith, has the advantage of avoiding additional tests or complexities and enabling ECN usage from the first media packet. The downside is that if the end-to-end path contains middleboxes that do
第一种机制使用RTP和RTCP反馈，其优点是适用于所有RTP会话，但缺点是，如果中间盒丢弃带有ECN标记的RTP数据包，则可能会进行剪裁，并且验证ECN支持的速度较慢。基于STUN的机制可以更快地验证ECN支持，但仅适用于端到端STUN支持的场景，例如在ICE交换中。第三个是leap of faith，它的优点是避免了额外的测试或复杂性，并且能够从第一个媒体包使用ECN。缺点是，如果端到端路径包含中间盒，则
not pass ECN, the impact on the application can be severe: in the worst case, all media could be lost if a middlebox that discards ECN-marked packets is present. A less severe effect, but still requiring reaction, is the presence of a middlebox that re-marks ECT-marked packets to not-ECT, possibly marking packets with an ECN-CE mark as not-ECT. This could result in increased levels of congestion due to non-responsiveness and impact media quality as applications end up relying on packet loss as an indication of congestion.
未通过ECN，对应用程序的影响可能会很严重：在最坏的情况下，如果存在丢弃ECN标记数据包的中间盒，则所有媒体都可能丢失。一个不太严重的影响，但仍然需要反应，是存在一个中间盒，将带有ECT标记的数据包重新标记为not ECT，可能将带有ECN-CE标记的数据包标记为not ECT。这可能会由于无响应而导致拥塞级别增加，并影响媒体质量，因为应用程序最终依赖数据包丢失作为拥塞的指示。
Once ECN support has been verified (or assumed) to work for all receivers, a sender marks all its RTP packets as ECT packets, while receivers rapidly feed back reports on any ECN-CE marks to the sender using RTCP in RTP/AVPF immediate or early feedback mode, unless no timely feedback is required. Each feedback report indicates the receipt of new ECN-CE marks since the last ECN feedback packet and also counts the total number of ECN-CE-marked packets as a cumulative sum. This is the mechanism to provide the fastest possible feedback to senders about ECN-CE marks. On receipt of an ECN-CE-marked packet, the system must react to congestion as if packet loss has been reported. Section 7.3 describes the ongoing use of ECN within an RTP session.
一旦ECN支持被验证（或假设）适用于所有接收者，发送者将其所有RTP数据包标记为ECT数据包，而接收者在RTP/AVPF即时或早期反馈模式下使用RTCP将任何ECN-CE标记的报告快速反馈给发送者，除非不需要及时反馈。每个反馈报告指示自上一个ECN反馈数据包以来新ECN-CE标记的接收情况，并将ECN-CE标记数据包的总数作为累计和进行计数。这是一种向发件人提供有关ECN-CE标记的最快反馈的机制。在接收到ECN CE标记的数据包时，系统必须对拥塞做出反应，就像已经报告了数据包丢失一样。第7.3节描述了在RTP会话中持续使用ECN。
This rapid feedback is not optimised for reliability, so another mechanism, RTCP XR ECN Summary Reports, is used to ensure more reliable, but less timely, reporting of the ECN information. The ECN Summary Report contains the same information as the ECN feedback format, only packed differently for better efficiency with reports for many sources. It is sent in a compound RTCP packet, along with regular RTCP reception reports. By using cumulative counters for observed ECN-CE, ECT, not-ECT, packet duplication, and packet loss, the sender can determine what events have happened since the last report, independently of any RTCP packets having been lost.
这种快速反馈的可靠性未得到优化，因此使用另一种机制RTCP XR ECN Summary Reports（RTCP XR ECN摘要报告）来确保ECN信息的报告更加可靠，但不太及时。ECN摘要报告包含与ECN反馈格式相同的信息，只是为了提高许多来源的报告的效率而采用不同的打包方式。它与常规RTCP接收报告一起以复合RTCP数据包的形式发送。通过使用观察到的ECN-CE、ECT、not ECT、数据包重复和数据包丢失的累积计数器，发送方可以确定自上次报告以来发生了什么事件，与任何已丢失的RTCP数据包无关。
RTCP reports MUST NOT be ECT marked, since ECT-marked traffic may be dropped if the path is not ECN compliant. RTCP is used to provide feedback about what has been transmitted and what ECN markings that are received, so it is important that it is received in cases when ECT-marked traffic is not getting through.
RTCP报告不得带有ECT标记，因为如果路径不符合ECN，则可能会丢弃带有ECT标记的流量。RTCP用于提供有关传输内容和接收到的ECN标记的反馈，因此，在ECT标记的通信量未通过的情况下接收RTCP非常重要。
There are numerous reasons why the path the RTP packets take from the sender to the receiver may change, e.g., mobility and link failure followed by re-routing around it. Such an event may result in the packet being sent through a node that is ECN non-compliant, thus re-marking or dropping packets with ECT set. To prevent this from impacting the application for longer than necessary, the operation of ECN is constantly monitored by all senders (Section 7.4). Both the RTCP XR ECN Summary Reports and the ECN feedback packets allow the sender to compare the number of ECT(0), ECT(1), and not-ECT-marked
RTP数据包从发送方到接收方的路径可能会发生变化的原因有很多，例如，移动性和链路故障，随后围绕其重新路由。此类事件可能导致通过ECN不兼容的节点发送数据包，从而使用ECT集合重新标记或丢弃数据包。为了防止这对应用程序的影响超过必要的时间，所有发送方都会持续监控ECN的运行（第7.4节）。RTCP XR ECN摘要报告和ECN反馈数据包都允许发送方比较ECT（0）、ECT（1）和未标记ECT的数量
packets received with the number that were sent, while also reporting ECN-CE-marked and lost packets. If these numbers do not agree, it can be inferred that the path does not reliably pass ECN-marked packets. A sender detecting a possible ECN non-compliance issue should then stop sending ECT-marked packets to determine if that allows the packets to be correctly delivered. If the issues can be connected to ECN, then ECN usage is suspended.
接收的数据包带有发送的号码，同时还报告ECN CE标记的数据包和丢失的数据包。如果这些数字不一致，则可以推断路径不能可靠地传递带有ECN标记的数据包。检测到可能的ECN不合规问题的发送方应停止发送带有ECT标记的数据包，以确定这是否允许正确发送数据包。如果问题可以连接到ECN，则ECN使用将暂停。
This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585] transport-layer feedback format for reporting urgent ECN information and one RTCP XR [RFC3611] ECN Summary Report block type for regular reporting of the ECN marking information.
此备忘录定义了两个新的RTCP扩展：一个RTP/AVPF[RFC4585]传输层反馈格式用于报告紧急ECN信息，另一个RTCP XR[RFC3611]ECN摘要报告块类型用于定期报告ECN标记信息。
This RTP/AVPF transport-layer feedback format is intended for use in RTP/AVPF early or immediate feedback modes when information needs to urgently reach the sender. Thus, its main use is to report reception of an ECN-CE-marked RTP packet so that the sender may perform congestion control or to speed up the initiation procedures by rapidly reporting that the path can support ECN-marked traffic. The feedback format is also defined with reduced-size RTCP [RFC5506] in mind, where RTCP feedback packets may be sent without accompanying Sender or Receiver Reports that would contain the extended highest sequence number and the accumulated number of packet losses. Both are important for ECN to verify functionality and keep track of when CE marking does occur.
此RTP/AVPF传输层反馈格式用于RTP/AVPF早期或即时反馈模式，当信息需要紧急到达发送方时。因此，其主要用途是报告ECN-CE标记的RTP分组的接收，以便发送方可以执行拥塞控制，或者通过快速报告路径可以支持ECN标记的业务来加速发起过程。反馈格式也在考虑减小的RTCP[RFC5506]的情况下定义，其中RTCP反馈数据包可以在不附带发送方或接收方报告的情况下发送，发送方或接收方报告将包含扩展的最高序列号和数据包丢失的累积数。这两项对于ECN验证功能和跟踪CE标记发生的时间都很重要。
The RTP/AVPF transport-layer feedback packet starts with the common header defined by the RTP/AVPF profile [RFC4585], which is reproduced in Figure 1. The FMT field takes the value 8 to indicate that the Feedback Control Information (FCI) contains an ECN Feedback Report, as defined in Figure 2.
RTP/AVPF传输层反馈数据包以RTP/AVPF配置文件[RFC4585]定义的公共报头开始，如图1所示。FMT字段的值为8，表示反馈控制信息（FCI）包含ECN反馈报告，如图2所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=8 | PT=RTPFB=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=8 | PT=RTPFB=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 1: RTP/AVPF Common Packet Format for Feedback Messages
图1：反馈消息的RTP/AVPF通用数据包格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Highest Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lost Packets Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Highest Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lost Packets Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ECN Feedback Report Format
图2:ECN反馈报告格式
The ECN Feedback Report contains the following fields:
ECN反馈报告包含以下字段：
Extended Highest Sequence Number: The 32-bit extended highest sequence number received, as defined by [RFC3550]. Indicates the highest RTP sequence number to which this report relates.
扩展最高序列号：接收到的32位扩展最高序列号，由[RFC3550]定义。指示与此报告相关的最高RTP序列号。
ECT(0) Counter: The 32-bit cumulative number of RTP packets with ECT(0) received from this SSRC.
ECT（0）计数器：从该SSRC接收的带有ECT（0）的RTP数据包的32位累积数。
ECT(1) Counter: The 32-bit cumulative number of RTP packets with ECT(1) received from this SSRC.
ECT（1）计数器：从该SSRC接收的带有ECT（1）的RTP数据包的32位累积数。
ECN-CE Counter: The cumulative number of RTP packets received from this SSRC since the receiver joined the RTP session that were ECN-CE marked, including ECN-CE marks in any duplicate packets. The receiver should keep track of this value using a local representation that is at least 32 bits and only include the 16
ECN-CE计数器：自接收器加入RTP会话以来，从该SSRC接收到的带有ECN-CE标记的RTP数据包的累积数量，包括任何重复数据包中的ECN-CE标记。接收器应使用至少32位且仅包括16位的本地表示来跟踪该值
bits with least significance. In other words, the field will wrap if more than 65535 ECN-CE-marked packets have been received.
意义最小的位。换句话说，如果接收到超过65535个ECN CE标记的数据包，则该字段将换行。
not-ECT Counter: The cumulative number of RTP packets received from this SSRC since the receiver joined the RTP session that had an ECN field value of not-ECT. The receiver should keep track of this value using a local representation that is at least 32 bits and only include the 16 bits with least significance. In other words, the field will wrap if more than 65535 not-ECT packets have been received.
not ECT计数器：自接收器加入ECN字段值为not ECT的RTP会话以来，从此SSRC接收的RTP数据包的累积数量。接收器应使用至少32位的本地表示法跟踪该值，并且仅包括具有最低重要性的16位。换句话说，如果接收到超过65535个not ECT数据包，则该字段将换行。
Lost Packets Counter: The cumulative number of RTP packets that the receiver expected to receive minus the number of packets it actually received that are not a duplicate of an already received packet, from this SSRC since the receiver joined the RTP session. Note that packets that arrive late are not counted as lost. The receiver should keep track of this value using a local representation that is at least 32 bits and only include the 16 bits with least significance. In other words, the field will wrap if more than 65535 packets are lost.
Lost Packets Counter（丢失数据包计数器）：自接收器加入RTP会话以来，接收器预期从该SSRC接收的RTP数据包的累计数量减去其实际接收的数据包数量，该数据包不是已接收数据包的重复。请注意，延迟到达的数据包不被视为丢失。接收器应使用至少32位的本地表示法跟踪该值，并且仅包括具有最低重要性的16位。换句话说，如果丢失的数据包超过65535个，则该字段将换行。
Duplication Counter: The cumulative number of RTP packets received that are a duplicate of an already received packet from this SSRC since the receiver joined the RTP session. The receiver should keep track of this value using a local representation that is at least 32 bits and only include the 16 bits with least significance. In other words, the field will wrap if more than 65535 duplicate packets have been received.
重复计数器：自接收器加入RTP会话以来，接收到的RTP数据包的累计数量，与已从该SSRC接收到的数据包重复。接收器应使用至少32位的本地表示法跟踪该值，并且仅包括具有最低重要性的16位。换句话说，如果接收到超过65535个重复数据包，则该字段将换行。
All fields in the ECN Feedback Report are unsigned integers in network byte order. Each ECN Feedback Report corresponds to a single RTP source (SSRC). Multiple sources can be reported by including multiple ECN Feedback Report packets in an compound RTCP packet.
ECN反馈报告中的所有字段都是网络字节顺序的无符号整数。每个ECN反馈报告对应一个RTP源（SSRC）。通过在复合RTCP数据包中包含多个ECN反馈报告数据包，可以报告多个来源。
The counters SHALL be initiated to 0 for each new SSRC received. This enables detection of ECN-CE marks or packet loss on the initial report from a specific participant.
对于接收到的每个新SSRC，计数器应初始化为0。这使得能够在来自特定参与者的初始报告上检测ECN-CE标记或数据包丢失。
The use of at least 32-bit counters allows even extremely high packet volume applications to not have wrapping of counters within any timescale close to the RTCP reporting intervals. However, 32 bits are not sufficiently large to disregard the fact that wrappings may happen during the lifetime of a long-lived RTP session, and implementations need to be written to handle wrapping of the counters. It is recommended that implementations use local representation of these counters that are longer than 32 bits to enable easy handling of wraps.
使用至少32位计数器，即使是数据包容量极高的应用程序也可以在接近RTCP报告间隔的任何时间尺度内不包装计数器。但是，32位不够大，无法忽略在长寿命RTP会话的生命周期内可能发生包装的事实，需要编写实现来处理计数器的包装。建议实现使用长度超过32位的这些计数器的本地表示形式，以便轻松处理包装。
There is a difference in packet duplication reports between the packet loss counter that is defined in the Receiver Report Block [RFC3550] and that defined here. To avoid holding state for what RTP sequence numbers have been received, [RFC3550] specifies that one can count packet loss by counting the number of received packets and comparing that to the number of packets expected. As a result, a packet duplication can hide a packet loss. However, when populating the ECN Feedback Report, a receiver needs to track the sequence numbers actually received and count duplicates and packet loss separately to provide a more reliable indication. Reordering may, however, still result in packet loss being reported in one report and then removed in the next.
在接收器报告块[RFC3550]中定义的分组丢失计数器与此处定义的分组丢失计数器之间的分组复制报告存在差异。为了避免保留已接收RTP序列号的状态，[RFC3550]指定可以通过计算已接收数据包的数量并将其与预期数据包的数量进行比较来计算数据包丢失。因此，数据包复制可以隐藏数据包丢失。然而，当填充ECN反馈报告时，接收器需要跟踪实际接收到的序列号，并分别计算重复数和分组丢失数，以提供更可靠的指示。然而，重新排序仍然可能导致在一个报告中报告数据包丢失，然后在下一个报告中删除。
The ECN-CE counter is robust for packet duplication. Adding each received ECN-CE-marked packet to the counter is not an issue; in fact, it is required to ensure complete tracking of the ECN state. If one of the clones was ECN-CE marked, that is still an indication of congestion. Packet duplication has a potential impact on the ECN verification, and there is thus a need to count the duplicates.
ECN-CE计数器对数据包复制具有鲁棒性。将每个接收到的ECN CE标记的数据包添加到计数器不是问题；事实上，需要确保完全跟踪ECN状态。如果其中一个克隆带有ECN-CE标记，这仍然表明存在拥塞。数据包重复对ECN验证有潜在影响，因此需要对重复数据进行计数。
This unilateral XR report block combined with RTCP SR or RR report blocks carries the same information as the ECN Feedback Report and is based on the same underlying information. However, the ECN Feedback Report is intended to report an ECN-CE mark as soon as possible, while this extended report is for the regular RTCP reporting and continuous verification of the ECN functionality end-to-end.
此单边XR报告块与RTCP SR或RR报告块组合，携带与ECN反馈报告相同的信息，并基于相同的基础信息。然而，ECN反馈报告旨在尽快报告ECN-CE标记，而此扩展报告用于定期RTCP报告和端到端ECN功能的持续验证。
The ECN Summary Report block consists of one RTCP XR report block header, shown in Figure 3 followed by one or more ECN Summary Report data blocks, as defined in Figure 4.
ECN摘要报告块由一个RTCP XR报告块头组成，如图3所示，后面是一个或多个ECN摘要报告数据块，如图4所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=13 | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=13 | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: RTCP XR Report Header
图3:RTCP XR报告头
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lost Packets Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lost Packets Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RTCP XR ECN Summary Report
图4:RTCP XR ECN摘要报告
The RTCP XR ECN Summary Report contains the following fields:
RTCP XR ECN摘要报告包含以下字段：
BT: Block Type identifying the ECN Summary Report block. Value is 13.
BT：标识ECN摘要报告块的块类型。值为13。
Reserved: All bits SHALL be set to 0 on transmission and ignored on reception.
保留：传输时所有位应设置为0，接收时忽略。
Block Length: The length of this XR report block, including the header, in 32-bit words minus one. Used to indicate the number of ECN Summary Report data blocks present in the ECN Summary Report. This length will be 5*n, where n is the number of ECN Summary Report blocks, since blocks are a fixed size. The block length MAY be zero if there is nothing to report. Receivers MUST discard reports where the block length is not a multiple of five, since these cannot be valid.
块长度：此XR报告块的长度，包括标题，以32位字减去1表示。用于指示ECN摘要报告中存在的ECN摘要报告数据块的数量。该长度为5*n，其中n是ECN摘要报告块的数量，因为块的大小是固定的。如果没有要报告的内容，则块长度可能为零。如果数据块长度不是5的倍数，则接收方必须放弃报告，因为这些报告无效。
SSRC of Media Sender: The SSRC identifying the media sender this report is for.
媒体发件人的SSRC：标识此报告所针对的媒体发件人的SSRC。
ECT(0) Counter: as in Section 5.1.
ECT（0）计数器：如第5.1节所述。
ECT(1) Counter: as in Section 5.1.
ECT（1）计数器：如第5.1节所述。
ECN-CE Counter: as in Section 5.1.
ECN-CE计数器：如第5.1节所示。
not-ECT Counter: as in Section 5.1.
非ECT计数器：如第5.1节所述。
Lost Packets Counter: as in Section 5.1.
丢失数据包计数器：如第5.1节所述。
Duplication Counter: as in Section 5.1.
复制计数器：如第5.1节所述。
The extended highest sequence number counter for each SSRC is not present in an RTCP XR report, in contrast to the feedback version. The reason is that this summary report will rely on the information sent in the Sender Report (SR) or Receiver Report (RR) blocks part of the same RTCP compound packet. The extended highest sequence number is available from the SR or RR.
与反馈版本相比，RTCP XR报告中不存在每个SSRC的扩展最高序列号计数器。原因是此摘要报告将依赖于发送方报告（SR）或接收方报告（RR）块中发送的信息，这些信息是同一RTCP复合数据包的一部分。扩展的最高序列号可从SR或RR获得。
All the SSRCs that are present in the SR or RR SHOULD also be included in the RTCP XR ECN Summary Report. In cases where the number of senders are so large that the combination of SR/RR and the ECN summary for all the senders exceed the MTU, then only a subset of the senders SHOULD be included so that the reports for the subset fits within the MTU. The subsets SHOULD be selected round-robin across multiple intervals so that all sources are periodically reported. In case there are no SSRCs that currently are counted as senders in the session, the report block SHALL still be sent with no report block entry and a zero report block length to continuously indicate to the other participants the receiver capability to report ECN information.
SR或RR中存在的所有SSRC也应包含在RTCP XR ECN摘要报告中。如果发送者的数量如此之多，以至于所有发送者的SR/RR和ECN摘要的组合超过MTU，则仅应包括发送者的子集，以便子集的报告适合MTU。子集应在多个时间间隔内循环选择，以便定期报告所有来源。如果会话中没有当前被视为发送方的SSRC，则仍应发送报告块，但不包含报告块条目和零报告块长度，以持续向其他参与者指示接收器报告ECN信息的能力。
This section defines a number of SDP signalling extensions used in the negotiation of the ECN for RTP support when using SDP. This includes one SDP attribute "a=ecn-capable-rtp:" that negotiates the actual operation of ECN for RTP. Two SDP signalling parameters are defined to indicate the use of the RTCP XR ECN summary block and the RTP/AVPF feedback format for ECN. One ICE option SDP representation is also defined.
本节定义了在使用SDP时，在协商ECN以获得RTP支持时使用的许多SDP信令扩展。这包括一个SDP属性“a=ecn-capable rtp:”，该属性为rtp协商ecn的实际操作。定义了两个SDP信令参数，以指示对RTCP XR ECN摘要块和RTP/AVPF ECN反馈格式的使用。还定义了一个ICE选项SDP表示。
One new SDP attribute, "a=ecn-capable-rtp:", is defined. This is a media-level attribute and MUST NOT be used at the session level. It is not subject to the character set chosen. The aim of this signalling is to indicate the capability of the sender and receivers to support ECN, and to negotiate the method of ECN initiation to be used in the session. The attribute takes a list of initiation methods, ordered in decreasing preference. The defined values for the initiation method are:
定义了一个新的SDP属性“a=ecn-capable rtp:”。这是媒体级属性，不能在会话级使用。它不受所选字符集的约束。此信令的目的是指示发送方和接收方支持ECN的能力，并协商会话中使用的ECN启动方法。该属性获取一个初始化方法列表，按优先级递减顺序排列。启动方法的定义值为：
rtp: Using RTP and RTCP as defined in Section 7.2.1.
rtp：使用第7.2.1节中定义的rtp和RTCP。
ice: Using STUN within ICE as defined in Section 7.2.2.
ice：按照第7.2.2节的规定，在ice内使用眩晕。
leap: Using the leap-of-faith method as defined in Section 7.2.3.
leap：使用第7.2.3节中定义的信仰飞跃方法。
Further methods may be specified in the future, so unknown methods MUST be ignored upon reception.
将来可能会指定其他方法，因此在接收时必须忽略未知方法。
In addition, a number of OPTIONAL parameters may be included in the "a=ecn-capable-rtp:" attribute as follows:
此外，“a=ecn-capable rtp:”属性中还可以包括许多可选参数，如下所示：
mode: This parameter signals the endpoint's capability to set and read ECN marks in UDP packets. An examination of various operating systems has shown that end-system support for ECN marking of UDP packets may be symmetric or asymmetric. By this, we mean that some systems may allow endpoints to set the ECN bits in an outgoing UDP packet but not read them, while others may allow applications to read the ECN bits but not set them. This either/or case may produce an asymmetric support for ECN and thus should be conveyed in the SDP signalling. The "mode=setread" state is the ideal condition where an endpoint can both set and read ECN bits in UDP packets. The "mode=setonly" state indicates that an endpoint can set the ECT bit but cannot read the ECN bits from received UDP packets to determine if upstream congestion occurred. The "mode=readonly" state indicates that the endpoint can read the ECN bits to determine if congestion has occurred for incoming packets, but it cannot set the ECT bits in outgoing UDP packets. When the "mode=" parameter is omitted, it is assumed that the node has "setread" capabilities. This option can provide for an early indication that ECN cannot be used in a session. This would be the case when both the offerer and answerer set the "mode=" parameter to "setonly" or both set it to "readonly".
模式：此参数表示端点在UDP数据包中设置和读取ECN标记的能力。对各种操作系统的检查表明，对UDP数据包的ECN标记的终端系统支持可能是对称的，也可能是不对称的。这意味着，一些系统可能允许端点设置传出UDP数据包中的ECN位，但不读取它们，而其他系统可能允许应用程序读取ECN位，但不设置它们。这种情况可能产生对ECN的不对称支持，因此应在SDP信令中传送。“mode=setread”状态是端点可以设置和读取UDP数据包中ECN位的理想状态。“mode=setonly”状态表示端点可以设置ECT位，但不能从接收到的UDP数据包中读取ECN位，以确定是否发生了上行拥塞。“mode=readonly”状态表示端点可以读取ECN位以确定传入数据包是否发生拥塞，但它无法在传出UDP数据包中设置ECT位。省略“mode=”参数时，假定节点具有“setread”功能。此选项可提供ECN不能在会话中使用的早期指示。当报价人和应答人都将“mode=”参数设置为“setonly”或都将其设置为“readonly”时，就会出现这种情况。
ect: This parameter makes it possible to express the preferred ECT marking. This is either "random", "0", or "1", with "0" being implied if not specified. The "ect" parameter describes a receiver preference and is useful in the case where the receiver knows it is behind a link using IP header compression, the efficiency of which would be seriously disrupted if it were to receive packets with randomly chosen ECT marks. It is RECOMMENDED that ECT(0) marking be used.
ect：此参数可以表示首选ect标记。这是“随机”、“0”或“1”，如果未指定，则暗示为“0”。“ect”参数描述接收机偏好，并且在接收机知道它位于使用IP报头压缩的链路后面的情况下非常有用，如果接收机接收具有随机选择的ect标记的分组，则IP报头压缩的效率将严重中断。建议使用ECT（0）标记。
The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp:" attribute is shown in Figure 5.
图5显示了“a=ecn-capable rtp:”属性的ABNF[RFC5234]语法。
ecn-attribute = "a=ecn-capable-rtp:" SP init-list [SP parm-list]
init-list = init-value *("," init-value)
init-value = "rtp" / "ice" / "leap" / init-ext
init-ext = token
parm-list = parm-value *(";" SP parm-value)
parm-value = mode / ect / parm-ext
mode = "mode=" ("setonly" / "setread" / "readonly")
ect = "ect=" ("0" / "1" / "random")
parm-ext = parm-name "=" parm-value-ext
parm-name = token
parm-value-ext = token / quoted-string
quoted-string = ( DQUOTE *qdtext DQUOTE )
qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair / UTF8-NONASCII
; No DQUOTE and no "\"
quoted-pair = "\\" / ( "\" DQUOTE )
UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
ecn-attribute = "a=ecn-capable-rtp:" SP init-list [SP parm-list]
init-list = init-value *("," init-value)
init-value = "rtp" / "ice" / "leap" / init-ext
init-ext = token
parm-list = parm-value *(";" SP parm-value)
parm-value = mode / ect / parm-ext
mode = "mode=" ("setonly" / "setread" / "readonly")
ect = "ect=" ("0" / "1" / "random")
parm-ext = parm-name "=" parm-value-ext
parm-name = token
parm-value-ext = token / quoted-string
quoted-string = ( DQUOTE *qdtext DQUOTE )
qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair / UTF8-NONASCII
; No DQUOTE and no "\"
quoted-pair = "\\" / ( "\" DQUOTE )
UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
; external references:
; token from RFC 4566
; SP and DQUOTE from RFC 5234
; UTF8-1, UTF8-2, UTF8-3, and UTF8-4 from RFC 3629
; external references:
; token from RFC 4566
; SP and DQUOTE from RFC 5234
; UTF8-1, UTF8-2, UTF8-3, and UTF8-4 from RFC 3629
Figure 5: ABNF Grammar for the "a=ecn-capable-rtp:" Attribute
Figure 5: ABNF Grammar for the "a=ecn-capable-rtp:" Attribute
Note the above quoted string construct has an escaping mechanism for strings containing ". This uses \ (backslash) as an escaping mechanism, i.e., a " is replaced by \" (backslash double quote) and any \ (backslash) is replaced by \\ (backslash backslash) when put into the double quotes as defined by the above syntax. The string in a quoted string is UTF-8 [RFC3629].
注意，上面引用的字符串构造有一个转义机制，用于包含“.”的字符串。它使用\（反斜杠）作为转义机制，即“a”替换为\（反斜杠双引号），任何\（反斜杠）替换为\（反斜杠）当放入上述语法定义的双引号中时。带引号字符串中的字符串为UTF-8[RFC3629]。
When SDP is used with the offer/answer model [RFC3264], the party generating the SDP offer MUST insert an "a=ecn-capable-rtp:" attribute into the media section of the SDP offer of each RTP session for which it wishes to use ECN. The attribute includes one or more ECN initiation methods in a comma-separated list in decreasing order of preference, with any number of optional parameters following. The answering party compares the list of initiation methods in the offer with those it supports in order of preference. If there is a match and if the receiver wishes to attempt to use ECN in the session, it includes an "a=ecn-capable-rtp:" attribute containing its single preferred choice of initiation method, and any optional parameters, in the media sections of the answer. If there is no matching
当SDP与报价/应答模型[RFC3264]一起使用时，生成SDP报价的一方必须在其希望使用ecn的每个rtp会话的SDP报价的媒体部分插入“a=ecn-capable rtp:”属性。该属性在以逗号分隔的列表中按首选项的降序包含一个或多个ECN启动方法，并随附任意数量的可选参数。应答方按照优先顺序将报价中的发起方法列表与其支持的发起方法进行比较。如果存在匹配，并且如果接收方希望尝试在会话中使用ECN，则在应答的媒体部分中包含“a=ECN-capable rtp:”属性，该属性包含其单一首选的启动方法选择和任何可选参数。如果没有匹配
initiation method capability, or if the receiver does not wish to attempt to use ECN in the session, it does not include an "a=ecn-- capable-rtp:" attribute in its answer. If the attribute is removed in the answer, then ECN MUST NOT be used in any direction for that media flow. If there are initialisation methods that are unknown, they MUST be ignored on reception and MUST NOT be included in an answer.
初始化方法能力，或者如果接收方不希望在会话中尝试使用ECN，则在其应答中不包含“a=ECN--capable rtp:”属性。如果答案中删除了该属性，则不得在该媒体流的任何方向上使用ECN。如果存在未知的初始化方法，则在接收时必须忽略这些方法，并且不得将其包含在回答中。
The endpoints' capability to set and read ECN marks, as expressed by the optional "mode=" parameter, determines whether ECN support can be negotiated for flows in one or both directions:
端点设置和读取ECN标记的能力（由可选的“mode=”参数表示）决定了是否可以为一个或两个方向的流协商ECN支持：
o If the "mode=setonly" parameter is present in the "a=ecn-capable-rtp:" attribute of the offer and the answering party is also "mode=setonly", then there is no common ECN capability, and the answer MUST NOT include the "a=ecn-capable-rtp:" attribute. Otherwise, if the offer is "mode=setonly", then ECN may only be initiated in the direction from the offering party to the answering party.
o 如果报价的“a=ecn能力rtp:”属性中存在“mode=setonly”参数，且应答方也是“mode=setonly”，则不存在通用ecn能力，且应答不得包含“a=ecn能力rtp:”属性。否则，如果报价为“mode=setonly”，则ECN只能在报价方到应答方的方向上启动。
o If the "mode=readonly" parameter is present in the "a=ecn-capable-rtp:" attribute of the offer and the answering party is "mode=readonly", then there is no common ECN capability, and the answer MUST NOT include the "a=ecn-capable-rtp:" attribute. Otherwise, if the offer is "mode=readonly", then ECN may only be initiated in the direction from the answering party to the offering party.
o 如果报价的“a=ecn能力rtp:”属性中存在“mode=readonly”参数，且应答方为“mode=readonly”，则不存在通用ecn能力，且应答不得包含“a=ecn能力rtp:”属性。否则，如果报价为“mode=readonly”，则ECN只能在应答方到报价方的方向上启动。
o If the "mode=setread" parameter is present in the "a=ecn-capable-rtp:" attribute of the offer and the answering party is "setonly", then ECN may only be initiated in the direction from the answering party to the offering party. If the offering party is "mode=setread" but the answering party is "mode=readonly", then ECN may only be initiated in the direction from the offering party to the answering party. If both offer and answer are "mode=setread", then ECN may be initiated in both directions. Note that "mode=setread" is implied by the absence of a "mode=" parameter in the offer or the answer.
o 如果报价的“a=ecn-capable rtp:”属性中存在“mode=setread”参数，且应答方为“setonly”，则只能在应答方到报价方的方向上启动ecn。如果提供方为“mode=setread”，但应答方为“mode=readonly”，则ECN只能在从提供方到应答方的方向上启动。如果报价和应答均为“mode=setread”，则可以在两个方向上启动ECN。请注意，“mode=setread”是指报价或答案中没有“mode=”参数。
o An offer that does not include a "mode=" parameter MUST be treated as if a "mode=setread" parameter had been included.
o 不包含“mode=”参数的报价必须视为包含了“mode=setread”参数。
In an RTP session using multicast and ECN, participants that intend to send RTP packets SHOULD support setting ECT marks in RTP packets (i.e., should be "mode=setonly" or "mode=setread"). Participants receiving data need the capability to read ECN marks on incoming packets. It is important that receivers can read ECN marks ("mode=readonly" or "mode=setread"), since otherwise no sender in the
在使用多播和ECN的RTP会话中，打算发送RTP数据包的参与者应支持在RTP数据包中设置ECT标记（即，应为“mode=setonly”或“mode=setread”）。接收数据的参与者需要能够读取传入数据包上的ECN标记。重要的是，接收器可以读取ECN标记（“mode=readonly”或“mode=setread”），否则，系统中没有发送器
multicast session would be able to enable ECN. Accordingly, receivers that are "mode=setonly" SHOULD NOT join multicast RTP sessions that use ECN. If session participants that are not aware of the ECN for RTP signalling are invited to a multicast session and simply ignore the signalling attribute, the other party in the offer/ answer exchange SHOULD terminate the SDP dialogue so that the participant leaves the session.
多播会话将能够启用ECN。因此，“mode=setonly”的接收器不应该加入使用ECN的多播RTP会话。如果不知道RTP信令的ECN的会话参与者被邀请参加多播会话，而只是忽略信令属性，则提供/应答交换中的另一方应终止SDP对话，以便参与者离开会话。
The "ect=" parameter in the "a=ecn-capable-rtp:" attribute is set independently in the offer and the answer. Its value in the offer indicates a preference for the sending behaviour of the answering party, and its value in the answer indicates a sending preference for the behaviour of the offering party. It will be the sender's choice to honour the receiver's preference for what to receive or not. In multicast sessions, all senders SHOULD set the ECT marks using the value declared in the "ect=" parameter.
“a=ecn-capable rtp:”属性中的“ect=”参数在报价和答案中独立设置。其在要约中的价值表示对应答方发送行为的偏好，其在应答中的价值表示对要约方行为的发送偏好。寄件人可以选择尊重接收人对接收或不接收内容的偏好。在多播会话中，所有发送方都应使用“ECT=”参数中声明的值设置ECT标记。
Unknown optional parameters MUST be ignored on reception and MUST NOT be included in the answer. That way, a new parameter may be introduced and verified as supported by the other endpoint by having the endpoint include it in any answer.
接收时必须忽略未知可选参数，且答案中不得包含这些参数。通过这种方式，可以引入一个新参数，并通过让另一个端点将其包含在任何答案中来验证它是否受另一个端点的支持。
When SDP is used in a declarative manner, for example, in a multicast session using the Session Announcement Protocol (SAP) [RFC2974], negotiation of session description parameters is not possible. The "a=ecn-capable-rtp:" attribute MAY be added to the session description to indicate that the sender will use ECN in the RTP session. The attribute MUST include a single method of initiation. Participants MUST NOT join such a session unless they have the capability to receive ECN-marked UDP packets, implement the method of initiation, and generate RTCP ECN feedback. The mode parameter MAY also be included in declarative usage, to indicate the minimal capability is required by the consumer of the SDP. So, for example, in an SSM session, the participants configured with a particular SDP will all be in a media receive-only mode; thus, "mode=readonly" may be used as the receiver only needs to be able to report on the ECN markings. In ASM sessions, using "mode=readonly" is also reasonable, unless all senders are required to attempt to use ECN for their outgoing RTP data traffic, in which case the mode needs to be set to "setread".
当以声明方式使用SDP时，例如，在使用会话公告协议（SAP）[RFC2974]的多播会话中，会话描述参数的协商是不可能的。“a=ecn-capable rtp:”属性可以添加到会话描述中，以指示发送方将在rtp会话中使用ecn。该属性必须包含一个启动方法。参与者不得加入此类会话，除非他们能够接收带有ECN标记的UDP数据包、实施启动方法并生成RTCP ECN反馈。模式参数也可以包含在声明性用法中，以指示SDP的使用者所需的最小能力。因此，例如，在SSM会话中，配置有特定SDP的参与者将全部处于仅媒体接收模式；因此，“mode=readonly”可用于接收器仅需要能够报告ECN标记。在ASM会话中，使用“mode=readonly”也是合理的，除非要求所有发送方尝试将ECN用于其传出RTP数据通信，在这种情况下，需要将模式设置为“setread”。
The "a=ecn-capable-rtp:" attribute MAY be used with RTP media sessions using UDP/IP transport. It MUST NOT be used for RTP sessions using TCP, SCTP, or DCCP transport or for non-RTP sessions.
“a=ecn-capable rtp:”属性可用于使用UDP/IP传输的rtp媒体会话。它不能用于使用TCP、SCTP或DCCP传输的RTP会话或非RTP会话。
As described in Section 7.3.3, RTP sessions using ECN require rapid RTCP ECN feedback, unless timely feedback is not required due to a receiver-driven congestion control. To ensure that the sender can react to ECN-CE-marked packets, timely feedback is usually required. Thus, the use of the Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585] or another profile that inherits RTP/AVPF's signalling rules MUST be signalled unless timely feedback is not required. If timely feedback is not required, it is still RECOMMENDED to use RTP/AVPF. The signalling of an RTP/AVPF-based profile is likely to be required even if the preferred method of initialisation and the congestion control do not require timely feedback, as the common interoperable method is likely to be signalled or the improved fault reaction is desired.
如第7.3.3节所述，使用ECN的RTP会话需要快速RTCP ECN反馈，除非由于接收器驱动的拥塞控制而不需要及时反馈。为了确保发送方能够对ECN CE标记的数据包做出反应，通常需要及时反馈。因此，除非不需要及时反馈，否则必须向基于RTCP的反馈（RTP/AVPF）[RFC4585]的扩展RTP配置文件或继承RTP/AVPF信令规则的另一个配置文件发送信号。如果不需要及时反馈，仍然建议使用RTP/AVPF。即使首选的初始化方法和拥塞控制不需要及时反馈，也可能需要发送基于RTP/AVPF的配置文件的信号，因为可能会发送通用互操作方法的信号，或者需要改进的故障反应。
A new "nack" feedback parameter "ecn" is defined to indicate the usage of the RTCP ECN feedback packet format (Section 5.1). The ABNF [RFC5234] definition of the SDP parameter extension is:
定义了一个新的“nack”反馈参数“ecn”，以指示RTCP ecn反馈数据包格式的使用（第5.1节）。SDP参数扩展的ABNF[RFC5234]定义为：
rtcp-fb-nack-param = <See Section 4.2 of [RFC4585]>
rtcp-fb-nack-param =/ ecn-fb-par
ecn-fb-par = SP "ecn"
rtcp-fb-nack-param = <See Section 4.2 of [RFC4585]>
rtcp-fb-nack-param =/ ecn-fb-par
ecn-fb-par = SP "ecn"
The offer/answer rules for these SDP feedback parameters are specified in the RTP/AVPF profile [RFC4585].
RTP/AVPF配置文件[RFC4585]中规定了这些SDP反馈参数的提供/应答规则。
A new unilateral RTCP XR block for ECN summary information is specified; thus, the XR block SDP signalling also needs to be extended with a parameter. This is done in the same way as for the other XR blocks. The XR block SDP attribute as defined in Section 5.1 of the RTCP XR specification [RFC3611] is defined to be extensible. As no parameter values are needed for this ECN summary block, this parameter extension consists of a simple parameter name used to indicate support and intent to use the XR block.
指定用于ECN摘要信息的新单边RTCP XR块；因此，XR块SDP信令还需要使用参数进行扩展。这是以与其他XR块相同的方式完成的。RTCP XR规范[RFC3611]第5.1节中定义的XR block SDP属性定义为可扩展。由于此ECN摘要块不需要任何参数值，因此此参数扩展包含一个简单的参数名称，用于指示对使用XR块的支持和意图。
xr-format = <See Section 5.1 of [RFC3611]>
xr-format =/ ecn-summary-par
ecn-summary-par = "ecn-sum"
xr-format = <See Section 5.1 of [RFC3611]>
xr-format =/ ecn-summary-par
ecn-summary-par = "ecn-sum"
For SDP declarative and offer/answer usage, see the RTCP XR specification [RFC3611] and its description of how to handle unilateral parameters.
有关SDP声明性和提供/应答的用法，请参阅RTCP XR规范[RFC3611]及其如何处理单边参数的说明。
One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used with the SDP session level "a=ice-options" attribute in an SDP offer to indicate that the initiator of the ICE exchange has the capability to support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn"). The answering party includes this same attribute at the session level in the SDP answer if it also has the capability and removes the attribute if it does not wish to use ECN or doesn't have the capability to use ECN. If the ICE initiation method (Section 7.2.2) is actually going to be used, it is also needs to be explicitly negotiated using the "a=ecn-capable-rtp:" attribute. This ICE option SHALL be included when the ICE initiation method is offered or declared in the SDP.
定义了一个新的ICE[RFC5245]选项“rtp+ecn”。这与SDP报价中的SDP会话级别“a=ice选项”属性一起使用，以表明ice交换的发起方能够支持通过UDP流进行RTP的ECN（通过“a=ice选项：RTP+ECN”）。如果应答方也有能力，则在SDP应答中的会话级别包含该相同属性；如果应答方不希望使用ECN或没有能力使用ECN，则删除该属性。如果实际要使用ICE启动方法（第7.2.2节），还需要使用“a=ecn-capable rtp:”属性明确协商。当SDP中提供或声明了冰启动方法时，应包括该冰选项。
Note: This signalling mechanism is not strictly needed as long as the STUN ECN testing capability is used within the context of this document. It may, however, be useful if the ECN verification capability is used in additional contexts.
注：只要在本文件的上下文中使用STUN ECN测试能力，则不严格需要该信号机制。但是，如果在其他上下文中使用ECN验证功能，它可能会很有用。
In the detailed specification of the behaviour below, the different functions in the general case will first be discussed. In case special considerations are needed for middleboxes, multicast usage, etc., those will be specially discussed in related subsections.
在下面行为的详细说明中，将首先讨论一般情况下的不同功能。如果需要对中间盒、多播使用等进行特殊考虑，将在相关小节中特别讨论。
The first stage of ECN negotiation for RTP over UDP is to signal the capability to use ECN. An RTP system that supports ECN and uses SDP for its signalling MUST implement the SDP extension to signal ECN capability as described in Section 6.1, the RTCP ECN feedback SDP parameter defined in Section 6.2, and the XR Block ECN SDP parameter defined in Section 6.3. It MAY also implement alternative ECN capability negotiation schemes, such as the ICE extension described in Section 6.4. Other signalling systems will need to define signalling parameters corresponding to those defined for SDP.
UDP上RTP的ECN协商的第一阶段是向使用ECN的能力发出信号。支持ECN并使用SDP发送信号的RTP系统必须实现第6.1节中所述的SDP扩展发送ECN信号能力、第6.2节中定义的RTCP ECN反馈SDP参数以及第6.3节中定义的XR Block ECN SDP参数。它还可以实施替代的ECN能力协商方案，如第6.4节所述的ICE扩展。其他信号系统将需要定义与SDP定义的参数相对应的信号参数。
The "ecn-capable-rtp:" SDP attribute MUST be used when employing ECN for RTP according to this specification in systems using SDP. As the RTCP XR ECN Summary Report is required independently of the initialisation method or congestion control scheme, the "rtcp-xr" attribute with the "ecn-sum" parameter MUST also be used. The "rtcp-fb" attribute with the "nack" parameter "ecn" MUST be used whenever the initialisation method or a congestion control algorithm
在使用SDP的系统中，根据本规范将ecn用于rtp时，必须使用“ecn-capable rtp:”SDP属性。由于需要独立于初始化方法或拥塞控制方案的RTCP XR ECN摘要报告，因此还必须使用带有“ECN sum”参数的“RTCP XR”属性。无论何时使用初始化方法或拥塞控制算法，都必须使用带有“nack”参数“ecn”的“rtcp fb”属性
requires timely sender-side knowledge of received CE markings. If the congestion control scheme requires additional signalling, this should be indicated as appropriate.
要求发送方及时了解收到的CE标志。如果拥塞控制方案需要额外的信令，则应视情况予以指示。
Once the sender and the receiver(s) have agreed that they have the capability to use ECN within a session, they may attempt to initiate ECN use. All session participants connected over the same transport MUST use the same initiation method. RTP mixers or translators can use different initiation methods to different participants that are connected over different underlying transports. The mixer or translator will need to do individual signalling with each participant to ensure it is consistent with the ECN support in those cases where it does not function as one endpoint for the ECN control loop.
一旦发送方和接收方同意他们有能力在会话中使用ECN，他们可以尝试启动ECN使用。通过相同传输连接的所有会话参与者必须使用相同的启动方法。RTP混合器或转换器可以对通过不同底层传输连接的不同参与者使用不同的启动方法。混音器或翻译器需要与每个参与者单独发送信号，以确保其在不作为ECN控制回路的一个端点的情况下与ECN支持一致。
At the start of the RTP session, when the first few packets with ECT are sent, it is important to verify that IP packets with ECN field values of ECT or ECN-CE will reach their destination(s). There is some risk that the use of ECN will result in either reset of the ECN field or loss of all packets with ECT or ECN-CE markings. If the path between the sender and the receivers exhibits either of these behaviours, the sender needs to stop using ECN immediately to protect both the network and the application.
在RTP会话开始时，当发送带有ECT的前几个数据包时，必须验证ECN字段值为ECT或ECN-CE的IP数据包是否将到达其目的地。使用ECN可能会导致ECN字段重置或所有带有ECT或ECN-CE标记的数据包丢失。如果发送方和接收方之间的路径出现上述任一行为，发送方需要立即停止使用ECN以保护网络和应用程序。
The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic at any time. This is to ensure that packet loss due to ECN marking will not effect the RTCP traffic and the necessary feedback information it carries.
RTP发送方和接收方不得在任何时候标记其RTCP流量。这是为了确保由于ECN标记导致的数据包丢失不会影响RTCP通信量及其所携带的必要反馈信息。
An RTP system that supports ECN MUST implement the initiation of ECN using in-band RTP and RTCP described in Section 7.2.1. It MAY also implement other mechanisms to initiate ECN support, for example, the STUN-based mechanism described in Section 7.2.2, or use the leap-of-faith option if the session supports the limitations provided in Section 7.2.3. If support for both in-band and out-of-band mechanisms is signalled, the sender when negotiating SHOULD offer detection of ECT using STUN with ICE with higher priority than detection of ECT using RTP and RTCP.
支持ECN的RTP系统必须使用第7.2.1节所述的带内RTP和RTCP启动ECN。它还可以实施其他机制来启动ECN支持，例如，第7.2.2节中描述的基于STUN的机制，或者如果会话支持第7.2.3节中提供的限制，则使用信仰飞跃选项。如果同时支持带内和带外机制，则在协商时，发送方应提供使用带ICE的STUN的ECT检测，其优先级高于使用RTP和RTCP的ECT检测。
No matter how ECN usage is initiated, the sender MUST continually monitor the ability of the network, and all its receivers, to support ECN, following the mechanisms described in Section 7.4. This is necessary because path changes or changes in the receiver population may invalidate the ability of the system to use ECN.
无论如何启动ECN使用，发送方必须按照第7.4节中描述的机制，持续监控网络及其所有接收方支持ECN的能力。这是必要的，因为路径更改或接收器填充的更改可能会使系统使用ECN的能力无效。
The ECN initiation phase using RTP and RTCP to detect if the network path supports ECN comprises three stages. First, the RTP sender generates some small fraction of its traffic with ECT marks to act as a probe for ECN support. Then, on receipt of these ECT-marked packets, the receivers send RTCP ECN feedback packets and RTCP ECN Summary Reports to inform the sender that their path supports ECN. Finally, the RTP sender makes the decision to use ECN or not, based on whether the paths to all RTP receivers have been verified to support ECN.
使用RTP和RTCP检测网络路径是否支持ECN的ECN启动阶段包括三个阶段。首先，RTP发送方使用ECT标记生成其流量的一小部分，作为ECN支持的探测。然后，在收到这些ECT标记的数据包后，接收方发送RTCP ECN反馈数据包和RTCP ECN摘要报告，以通知发送方其路径支持ECN。最后，RTP发送方根据到所有RTP接收器的路径是否已验证为支持ECN，来决定是否使用ECN。
Generating ECN Probe Packets: During the ECN initiation phase, an RTP sender SHALL mark a small fraction of its RTP traffic as ECT, while leaving the reminder of the packets unmarked. The main reason for only marking some packets is to maintain usable media delivery during the ECN initiation phase in those cases where ECN is not supported by the network path. A secondary reason to send some not-ECT packets is to ensure that the receivers will send RTCP reports on this sender, even if all ECT-marked packets are lost in transit. The not-ECT packets also provide a baseline to compare performance parameters against. Another reason for only probing with a small number of packets is to reduce the risk that significant numbers of congestion markings might be lost if ECT is cleared to not-ECT by an ECN-reverting Middlebox. Then, any resulting lack of congestion response is likely to have little damaging effect on others. An RTP sender is RECOMMENDED to send a minimum of two packets with ECT markings per RTCP reporting interval. In case a random ECT pattern is intended to be used, at least one packet with ECT(0) and one with ECT(1) should be sent per reporting interval; in case a single ECT marking is to be used, only that ECT value SHOULD be sent. The RTP sender SHALL continue to send some ECT-marked traffic as long as the ECN initiation phase continues. The sender SHOULD NOT mark all RTP packets as ECT during the ECN initiation phase.
生成ECN探测数据包：在ECN启动阶段，RTP发送方应将其RTP流量的一小部分标记为ECT，同时保留未标记数据包的提醒。仅标记某些数据包的主要原因是，在网络路径不支持ECN的情况下，在ECN启动阶段保持可用的媒体交付。发送一些非ECT数据包的第二个原因是确保接收方将发送此发送方的RTCP报告，即使所有标记为ECT的数据包在传输过程中丢失。not ECT数据包还提供了比较性能参数的基线。仅使用少量数据包进行探测的另一个原因是，如果ECN恢复中间盒将ECT清除为not ECT，则可降低大量拥塞标记丢失的风险。然后，任何由此导致的拥塞响应的缺乏都可能对其他人没有什么破坏性影响。建议RTP发送方在每个RTCP报告间隔内至少发送两个带有ECT标记的数据包。如果打算使用随机ECT模式，则每个报告间隔应至少发送一个带有ECT（0）和一个带有ECT（1）的数据包；如果要使用单个ECT标记，则只应发送该ECT值。只要ECN启动阶段继续，RTP发送方应继续发送一些带有ECT标记的通信量。在ECN启动阶段，发送方不应将所有RTP数据包标记为ECT。
This memo does not mandate which RTP packets are marked with ECT during the ECN initiation phase. An implementation should insert ECT marks in RTP packets in a way that minimises the impact on media quality if those packets are lost. The choice of packets to mark is very media dependent. For audio formats, it would make sense for the sender to mark comfort noise packets or similar. For video formats, packets containing P- or B-frames (rather than I-frames) would be an appropriate choice. No matter which RTP packets are marked, those packets MUST NOT be sent in duplicate, with and without ECT, since the RTP sequence number is used to identify packets that are received with ECN markings.
此备忘录不强制要求在ECN启动阶段使用ECT标记哪些RTP数据包。一个实现应该在RTP数据包中插入ECT标记，以使这些数据包丢失时对媒体质量的影响最小化。要标记的数据包的选择非常依赖于媒体。对于音频格式，发送者标记舒适噪音包或类似内容是有意义的。对于视频格式，包含P帧或B帧（而不是I帧）的数据包将是一个合适的选择。无论标记了哪个RTP数据包，这些数据包都不得重复发送，无论是否使用ECT，因为RTP序列号用于识别使用ECN标记接收的数据包。
Generating RTCP ECN Feedback: If ECN capability has been negotiated in an RTP session, the receivers in the session MUST listen for ECT or ECN-CE-marked RTP packets and generate RTCP ECN feedback packets (Section 5.1) to mark their receipt. An immediate or early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD be generated on receipt of the first ECT- or ECN-CE-marked packet from a sender that has not previously sent any ECT traffic. Each regular RTCP report MUST also contain an ECN Summary Report (Section 5.2). Reception of subsequent ECN-CE-marked packets MUST result in additional early or immediate ECN feedback packets being sent unless no timely feedback is required.
生成RTCP ECN反馈：如果已在RTP会话中协商ECN能力，会话中的接收器必须侦听ECT或ECN CE标记的RTP数据包，并生成RTCP ECN反馈数据包（第5.1节）以标记其接收。从之前未发送任何ECT通信量的发送方接收到第一个带有ECT或ECN CE标记的数据包时，应立即或提前（取决于RTP/AVPF模式）生成ECN反馈数据包。每个常规RTCP报告还必须包含一份ECN总结报告（第5.2节）。除非不需要及时反馈，否则接收后续ECN CE标记的数据包必须导致发送额外的早期或立即ECN反馈数据包。
Determination of ECN Support: RTP is a group communication protocol, where members can join and leave the group at any time. This complicates the ECN initiation phase, since the sender must wait until it believes the group membership has stabilised before it can determine if the paths to all receivers support ECN (group membership changes after the ECN initiation phase has completed are discussed in Section 7.3).
确定ECN支持：RTP是一种组通信协议，成员可以随时加入和离开组。这使ECN启动阶段变得复杂，因为发送方必须等到它认为组成员资格已经稳定后，才能确定到所有接收方的路径是否支持ECN（ECN启动阶段完成后组成员资格的变化在第7.3节中讨论）。
An RTP sender shall consider the group membership to be stable after it has been in the session and sending ECT-marked probe packets for at least three RTCP reporting intervals (i.e., after sending its third regularly scheduled RTCP packet) and when a complete RTCP reporting interval has passed without changes to the group membership. ECN initiation is considered successful when the group membership is stable and all known participants have sent one or more RTCP ECN feedback packets or RTCP XR ECN Summary Reports indicating correct receipt of the ECT-marked RTP packets generated by the sender.
RTP发送者应考虑组成员在会话中是稳定的，并且发送至少三个RTCP报告间隔（即，在发送其第三个定期调度的RTCP分组之后）以及当没有改变组成员资格的情况下完整的RTCP报告间隔时发送ECT标记的探测分组。当组成员身份稳定且所有已知参与者已发送一个或多个RTCP ECN反馈数据包或RTCP XR ECN摘要报告，表明正确接收发送方生成的ECT标记RTP数据包时，ECN启动被视为成功。
As an optimisation, if an RTP sender is initiating ECN usage towards a unicast address, then it MAY treat the ECN initiation as provisionally successful if it receives an RTCP ECN Feedback Report or an RTCP XR ECN Summary Report indicating successful receipt of the ECT-marked packets, with no negative indications, from a single RTP receiver (where a single RTP receiver is considered as all SSRCs used by a single RTCP CNAME). After declaring provisional success, the sender MAY generate ECT-marked packets as described in Section 7.3, provided it continues to monitor the RTCP reports for a period of three RTCP reporting intervals from the time the ECN initiation started, to check if there are any other participants in the session. Thus, as long as any additional SSRC that report on the ECN usage are using the same RTCP CNAME as the previous reports and they are all indicating functional ECN, the sender may continue. If other participants are detected, i.e., other RTCP CNAMEs, the sender MUST fallback to only ECT-marking a small fraction of its RTP
作为一种优化，如果RTP发送方正在向单播地址发起ECN使用，则如果它从单个RTP接收器接收到RTCP ECN反馈报告或RTCP XR ECN摘要报告，指示成功接收到带有ECT标记的数据包，且没有负面指示，则它可以将ECN发起视为临时成功（单个RTP接收器被视为单个RTCP CNAME使用的所有SSRC）.在宣布临时成功后，发送方可按照第7.3节所述生成带有ECT标记的数据包，前提是从ECN启动开始，发送方在三个RTCP报告间隔内继续监控RTCP报告，以检查会话中是否有任何其他参与者。因此，只要任何附加SSRC有关ECN使用情况的报告与以前的报告使用相同的RTCP CNAME，并且这些报告都表示功能性ECN，发送方可以继续。如果检测到其他参与者，即其他RTCP CNAME，发送方必须退回到仅标记其RTP一小部分的ECT
packets, while it determines if ECN can be supported following the full procedure described above. Different RTCP CNAMEs received over a unicast transport may occur when using translators in a multi-party RTP session (e.g., when using a centralised conference bridge).
数据包，但它确定是否可以按照上述完整过程支持ECN。在多方RTP会话中使用翻译器时（例如，在使用集中会议网桥时），可能会通过单播传输接收到不同的RTCP CNAME。
Note: The above optimisation supports peer-to-peer unicast transport with several SSRCs multiplexed onto the same flow (e.g., a single participant with two video cameras or SSRC multiplexed RTP retransmission [RFC4588]). It is desirable to be able to rapidly negotiate ECN support for such a session, but the optimisation above can fail if there are implementations that use the same CNAME for different parts of a distributed implementation that have different transport characteristics (e.g., if a single logical endpoint is split across multiple hosts).
注：上述优化支持对等单播传输，多个SSRC复用到同一个流上（例如，一个参与者有两个摄像机或SSRC复用RTP重传[RFC4588]）。希望能够快速协商对此类会话的ECN支持，但如果存在对具有不同传输特性的分布式实现的不同部分使用相同CNAME的实现（例如，如果单个逻辑端点跨多个主机拆分），则上述优化可能会失败。
ECN initiation is considered to have failed at the instant the initiating RTP sender received an RTCP packet that doesn't contain an RTCP ECN Feedback Report or ECN Summary Report from any RTP session participant that has an RTCP RR with an extended RTP sequence number field that indicates that it should have received multiple (>3) ECT-marked RTP packets. This can be due to failure to support the ECN feedback format by the receiver or some middlebox or the loss of all ECT-marked packets. Both indicate a lack of ECN support.
当发起RTP发送方从任何RTP会话参与者处接收到不包含RTCP ECN反馈报告或ECN摘要报告的RTCP数据包时，认为ECN发起失败，该RTP会话参与者的RTCP RR带有扩展RTP序列号字段，表明其应已接收多个（>3）ECT标记的RTP数据包。这可能是由于接收器或某些中间盒无法支持ECN反馈格式，或者丢失了所有ECT标记的数据包。两者都表明缺乏ECN支持。
If the ECN negotiation succeeds, this indicates that the path can pass some ECN-marked traffic and that the receivers support ECN feedback. This does not necessarily imply that the path can robustly convey ECN feedback; Section 7.3 describes the ongoing monitoring that must be performed to ensure the path continues to robustly support ECN.
如果ECN协商成功，这表明路径可以通过一些ECN标记的流量，并且接收机支持ECN反馈。这并不一定意味着路径能够可靠地传递ECN反馈；第7.3节描述了必须执行的持续监控，以确保路径继续有力地支持ECN。
When a sender or receiver detects ECN failures on paths, they should log these to enable follow up and statistics gathering regarding broken paths. The logging mechanism used is implementation dependent.
当发送方或接收方在路径上检测到ECN故障时，他们应该记录这些故障，以便能够跟踪和收集有关损坏路径的统计信息。所使用的日志机制取决于实现。
This section describes an OPTIONAL method that can be used to avoid media impact and also ensure an ECN-capable path prior to media transmission. This method is considered in the context where the session participants are using ICE [RFC5245] to find working connectivity. We need to use ICE rather than STUN only, as the verification needs to happen from the media sender to the address and port on which the receiver is listening.
本节介绍一种可选方法，可用于避免媒体影响，并确保在媒体传输之前有一条支持ECN的路径。在会话参与者使用ICE[RFC5245]查找工作连接的情况下，考虑使用此方法。我们需要使用ICE而不仅仅是STUN，因为验证需要从媒体发送方到接收方正在监听的地址和端口进行。
Note that this method is only applicable to sessions when the remote destinations are unicast addresses. In addition, transport translators that do not terminate the ECN control loop and may distribute received packets to more than one other receiver must either disallow this method (and use the RTP/RTCP method instead) or implement additional handling as discussed below. This is because the ICE initialisation method verifies the underlying transport to one particular address and port. If the receiver at that address and port intends to use the received packets in a multi-point session, then the tested capabilities and the actual session behaviour are not matched.
请注意，此方法仅适用于远程目标为单播地址时的会话。此外，不终止ECN控制环路且可能将接收到的数据包分发给多个其他接收器的传输转换器必须禁止此方法（并改用RTP/RTCP方法）或执行以下讨论的附加处理。这是因为ICE初始化方法验证到一个特定地址和端口的底层传输。如果该地址和端口的接收器打算在多点会话中使用接收到的数据包，则测试的能力与实际会话行为不匹配。
To minimise the impact of setup delay, and to prioritise the fact that one has working connectivity rather than necessarily finding the best ECN-capable network path, this procedure is applied after having performed a successful connectivity check for a candidate, which is nominated for usage. At that point, an additional connectivity check is performed, sending the "ECN-CHECK" attribute in a STUN packet that is ECT marked. On reception of the packet, a STUN server supporting this extension will note the received ECN field value and send a STUN/UDP/IP packet in reply with the ECN field set to not-ECT and an ECN-CHECK attribute included. A STUN server that doesn't understand the extension, or is incapable of reading the ECN values on incoming STUN packets, should follow the rule in the STUN specification for unknown comprehension-optional attributes and ignore the attribute, resulting in the sender receiving a STUN response without the ECN-CHECK STUN attribute.
为了最大限度地减少设置延迟的影响，并优先考虑一个人具有工作连接，而不是一定要找到具有最佳ECN能力的网络路径这一事实，在对提名使用的候选人成功执行连接检查后，应用此程序。此时，执行额外的连接检查，在带有ECT标记的STUN数据包中发送“ECN-check”属性。在接收到数据包时，支持此扩展的STUN服务器将记录接收到的ECN字段值，并发送一个STUN/UDP/IP数据包，以回复ECN字段设置为not ECT并包含ECN-CHECK属性。不理解扩展名或无法读取传入STUN数据包上的ECN值的STUN服务器应遵循STUN规范中关于未知理解可选属性的规则，并忽略该属性，从而导致发送方在没有ECN-CHECK STUN属性的情况下接收STUN响应。
The ECN STUN checks can be lost on the path, for example, due to the ECT marking but also due to various other non ECN-related reasons causing packet loss. The goal is to detect when the ECT markings are rewritten or if it is the ECT marking that causes packet loss so that the path can be determined as not-ECT. Other reasons for packet loss should not result in a failure to verify the path as ECT. Therefore, a number of retransmissions should be attempted. But, the sender of ECN STUN checks will also have to set a criteria for when it gives up testing for ECN capability on the path. Since the ICE agent has successfully verified the path, an RTT measurement for this path can be performed. To have a high probability of successfully verifying the path, it is RECOMMENDED that the client retransmit the ECN STUN check at least 4 times. The transmission for that flow is stopped when an ECN-CHECK STUN response has been received, which doesn't indicate a retransmission of the request due to a temporary error, or the maximum number of retransmissions has been sent. The ICE agent is recommended to give up on the ECN verification MAX(1.5*RTT, 20 ms) after the last ECN STUN check was sent.
ECN STUN检查可能在路径上丢失，例如，由于ECT标记，但也由于各种其他非ECN相关原因导致数据包丢失。目标是检测ECT标记何时被重写，或者是否是ECT标记导致数据包丢失，以便可以确定路径不是ECT。数据包丢失的其他原因不应导致验证路径为ECT的失败。因此，应尝试多次重新传输。但是，ECN眩晕检查的发送方还必须为其何时放弃对路径上的ECN功能的测试设置标准。由于ICE代理已成功验证路径，因此可以对该路径执行RTT测量。为了具有成功验证路径的高概率，建议客户端至少重新传输4次ECN STUN检查。当接收到ECN-CHECK STUN响应时，该流的传输停止，该响应不表示由于临时错误而重新传输请求，或已发送最大重新传输次数。在发送最后一次ECN电击检查后，建议ICE代理放弃ECN验证最大值（1.5*RTT，20 ms）。
The transmission of the ECT-marked STUN connectivity checks containing the ECN-CHECK attribute can be done prior as well in parallel to actual media transmission. Both cases are supported, where the main difference is how aggressively the transmission of the STUN checks are done. The reason for this is to avoid adding additional startup delay until media can flow. If media is required immediately after nomination has occurred, the STUN checks SHALL be done in parallel. If the application does not require media transmission immediately, the verification of ECT SHOULD start using the aggressive mode. At any point in the process until ECT has been verified or found to not work, media transmission MAY be started, and the ICE agent SHALL transition from the aggressive mode to the parallel mode.
包含ECN-CHECK属性的ECT标记的STUN连接检查的传输可以在实际媒体传输之前进行，也可以并行进行。这两种情况都得到了支持，主要区别在于电击检查的传播力度有多大。这样做的原因是为了避免在介质流动之前增加额外的启动延迟。如果提名发生后立即需要媒体，则应同时进行眩晕检查。如果应用程序不需要立即传输介质，则应使用主动模式开始验证ECT。在过程中的任何一点，直到验证ECT或发现ECT不起作用，媒体传输可能开始，ICE代理应从攻击模式转换到并行模式。
The aggressive mode uses an interval between the retransmissions based on the Ta timer as defined in Section 16.1 for RTP Media Streams in ICE [RFC5245]. The number of ECN STUN checks needing to be sent will depend on the number of ECN-capable flows (N) that is to be established. The interval between each transmission of an ECN-CHECK packet MUST be Ta. In other words, for a given flow being verified for ECT, the retransmission timeout (RTO) is set to Ta*N.
主动模式使用基于第16.1节中针对ICE中RTP媒体流定义的Ta定时器的重传间隔[RFC5245]。需要发送的ECN STUN检查的数量将取决于要建立的支持ECN的流（N）的数量。ECN-CHECK数据包每次传输之间的间隔必须为Ta。换句话说，对于正在验证ECT的给定流，重传超时（RTO）被设置为Ta*N。
The parallel mode uses transmission intervals in order to prevent the ECT verification checks from increasing the total bitrate more than 10%. As ICE's regular transmission schedule is mimicking a common voice call in amount, to meet that goal for most media flows, setting the retransmission interval to Ta*N*k where k=10 fulfills that goal. Thus, the default behaviour SHALL be to use k=10 when in parallel mode. In cases where the bitrate of the STUN connectivity checks can be determined, they MAY be sent with smaller values of k, but k MUST NOT be smaller than 1, as long as the total bitrate for the connectivity checks are less than 10% of the used media bitrate. The RTP media packets being sent in parallel mode SHALL NOT be ECT marked prior to verification of the path as ECT.
并行模式使用传输间隔，以防止ECT验证检查将总比特率增加超过10%。由于ICE的常规传输计划在数量上模仿普通的语音呼叫，为了满足大多数媒体流的这一目标，将重传间隔设置为Ta*N*k，其中k=10实现了这一目标。因此，在并联模式下，默认行为应为使用k=10。在可以确定STUN连接检查的比特率的情况下，可以使用较小的k值发送这些检查，但k不得小于1，只要连接检查的总比特率小于所用媒体比特率的10%。在验证路径为ECT之前，以并行模式发送的RTP媒体包不得标记为ECT。
The STUN ECN-CHECK attribute contains one field and a flag, as shown in Figure 6. The flag indicates whether the echo field contains a valid value or not. The field is the ECN echo field and, when valid, contains the two ECN bits from the packet it echoes back. The ECN-CHECK attribute is a comprehension optional attribute.
STUN ECN-CHECK属性包含一个字段和一个标志，如图6所示。该标志指示echo字段是否包含有效值。该字段是ECN回显字段，有效时包含它回显的数据包中的两个ECN位。ECN-CHECK属性是一个可选属性。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ECF|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ECF|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ECN-CHECK STUN Attribute
图6:ECN-CHECK眩晕属性
V: Valid (1 bit) ECN Echo value field is valid when set to 1 and invalid when set 0.
V:Valid（1位）ECN Echo value字段设置为1时有效，设置为0时无效。
ECF: ECN Echo value field (2 bits) contains the ECN field value of the STUN packet it echoes back when the field is valid. If invalid, the content is arbitrary.
ECF:ECN回显值字段（2位）包含该字段有效时回显的STUN数据包的ECN字段值。如果无效，则内容是任意的。
Reserved: Reserved bits (29 bits) SHALL be set to 0 on transmission and SHALL be ignored on reception.
保留：保留位（29位）在传输时应设置为0，在接收时应忽略。
This attribute MAY be included in any STUN request to request the ECN field to be echoed back. In STUN requests, the V bit SHALL be set to 0. A compliant STUN server receiving a request with the ECN-CHECK attribute SHALL read the ECN field value of the IP/UDP packet in which the request was received. Upon forming the response, the server SHALL include the ECN-CHECK attribute setting the V bit to valid and include the read value of the ECN field into the ECF field. If the STUN responder was unable to ascertain, due to temporary errors, the ECN value of the STUN request, it SHALL set the V bit in the response to 0. The STUN client may retry immediately.
该属性可以包含在任何STUN请求中，以请求回显ECN字段。在STUN请求中，V位应设置为0。接收具有ECN-CHECK属性的请求的兼容STUN服务器应读取接收请求的IP/UDP数据包的ECN字段值。形成响应后，服务器应包括ECN-CHECK属性，将V位设置为有效，并将ECN字段的读取值包括在ECF字段中。如果由于临时错误，STUN响应者无法确定STUN请求的ECN值，则应将响应中的V位设置为0。STUN客户端可能会立即重试。
The ICE-based initialisation method does require some special consideration when used by a translator. This is especially for transport translators and translators that fragment or reassemble packets, since they do not separate the ECN control loops between the endpoints and the translator. When using ICE-based initiation, such a translator must ensure that any participants joining an RTP session for which ECN has been negotiated are successfully verified in the direction from the translator to the joining participant. Alternatively, it must correctly handle remarking of ECT RTP packets towards that participant. When a new participant joins the session, the translator will perform a check towards the new participant. If that is successfully completed, the ECT properties of the session are maintained for the other senders in the session. If the check fails, then the existing senders will now see a participant that fails to receive ECT. Thus, the failure detection in those senders will eventually detect this. However, to avoid misusing the network on the path from the translator to the new participant, the translator
当翻译人员使用基于ICE的初始化方法时，确实需要特别考虑。这尤其适用于传输转换器和拆分或重新组装数据包的转换器，因为它们不会分离端点和转换器之间的ECN控制循环。当使用基于ICE的启动时，此类翻译人员必须确保加入已协商ECN的RTP会话的任何参与者在翻译人员到加入参与者的方向上得到成功验证。或者，它必须正确处理对该参与者的ECT RTP数据包的注释。当新参与者加入会话时，翻译人员将对新参与者进行检查。如果成功完成，会话的ECT属性将为会话中的其他发件人保留。如果检查失败，那么现有发送者现在将看到一个未能接收ECT的参与者。因此，这些发送器中的故障检测最终将检测到这一点。然而，为了避免在从译者到新参与者的路径上误用网络，译者
SHALL remark the traffic intended to be forwarded from ECT to not-ECT. Any packets intended to be forwarded that are ECN-CE marked SHALL be discarded and not sent. In cases where the path from a new participant to the translator fails the ECT check, then only that sender will not contribute any ECT-marked traffic towards the translator.
应注明拟从ECT转发至非ECT的流量。任何打算转发的带有ECN-CE标记的数据包均应丢弃，不得发送。如果从新参与者到翻译器的路径未通过ECT检查，则只有该发送者不会向翻译器提供任何带有ECT标记的通信量。
This method for initiating ECN usage is a leap of faith that assumes that ECN will work on the used path(s). The method is to go directly to "ongoing use of ECN" as defined in Section 7.3. Thus, all RTP packets MAY be marked as ECT, and the failure detection MUST be used to detect any case when the assumption that the path is ECT capable is wrong. This method is only recommended for controlled environments where the whole path(s) between sender and receiver(s) has been built and verified to be ECT.
这种启动ECN使用的方法是一种信念的飞跃，它假设ECN将在使用的路径上工作。该方法直接转到第7.3节中定义的“ECN的持续使用”。因此，所有RTP分组都可以标记为ECT，并且故障检测必须用于检测路径能够ECT的假设错误时的任何情况。此方法仅推荐用于发送方和接收方之间的整个路径已构建并验证为ECT的受控环境。
If the sender marks all packets as ECT while transmitting on a path that contains an ECN-blocking middlebox, then receivers downstream of that middlebox will not receive any RTP data packets from the sender and hence will not consider it to be an active RTP SSRC. The sender can detect this and revert to sending packets without ECT marks, since RTCP SR/RR packets from such receivers will either not include a report for the sender's SSRC or will report that no packets have been received, but this takes at least one RTCP reporting interval. It should be noted that a receiver might generate its first RTCP packet immediately on joining a unicast session, or very shortly after joining an RTP/AVPF session, before it has had chance to receive any data packets. A sender that receives an RTCP SR/RR packet indicating lack of reception by a receiver SHOULD therefore wait for a second RTCP report from that receiver to be sure that the lack of reception is due to ECT-marking. Since this recovery process can take several tens of seconds, during which time the RTP session is unusable for media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation method be used in environments where ECN-blocking middleboxes are likely to be present.
如果发送方将所有分组标记为ECT，而在包含ECN阻塞中间框的路径上发送，那么该中间框的下游的接收器将不接收来自发送者的任何RTP数据包，因此不会认为它是主动RTP SSRC。发送方可以检测到这一点，并返回到发送不带ECT标记的数据包，因为来自此类接收方的RTCP SR/RR数据包将不包括发送方SSRC的报告，或将报告未收到任何数据包，但这至少需要一个RTCP报告间隔。应当注意，接收机可能在加入单播会话时立即生成其第一个RTCP分组，或者在加入RTP/AVPF会话后不久，在其有机会接收任何数据分组之前生成其第一个RTCP分组。因此，接收到RTCP SR/RR数据包的发送方应等待来自该接收方的第二份RTCP报告，以确保接收不足是由于ECT标记造成的。由于此恢复过程可能需要几十秒，在此期间RTP会话对媒体不可用，因此不建议在可能存在ECN阻塞中间盒的环境中使用leap of faith ECT启动方法。
Once ECN has been successfully initiated for an RTP sender, that sender begins sending all RTP data packets as ECT-marked, and its receivers send ECN feedback information via RTCP packets. This section describes procedures for sending ECT-marked data, providing ECN feedback information via RTCP, and responding to ECN feedback information.
RTP发送方成功启动ECN后，该发送方开始发送所有标有ECT的RTP数据包，其接收方通过RTCP数据包发送ECN反馈信息。本节描述发送ECT标记数据、通过RTCP提供ECN反馈信息以及响应ECN反馈信息的过程。
After a sender has successfully initiated ECN use, it SHOULD mark all the RTP data packets it sends as ECT. The sender SHOULD mark packets as ECT(0) unless the receiver expresses a preference for ECT(1) or for a random ECT value using the "ect" parameter in the "a=ecn-- capable-rtp:" attribute.
发送方成功启动ECN使用后，应将其发送的所有RTP数据包标记为ECT。发送方应将数据包标记为ECT（0），除非接收方使用“a=ecn--capable rtp:”属性中的“ECT”参数表示对ECT（1）或随机ECT值的偏好。
The sender SHALL NOT include ECT marks on outgoing RTCP packets and SHOULD NOT include ECT marks on any other outgoing control messages (e.g., STUN [RFC5389] packets, Datagram Transport Layer Security (DTLS) [RFC6347] handshake packets, or ZRTP [RFC6189] control packets) that are multiplexed on the same UDP port. For control packets there might be exceptions, like the STUN-based ECN-CHECK defined in Section 7.2.2.
发送方不得在传出RTCP数据包上包含ECT标记，也不得在同一UDP端口上复用的任何其他传出控制消息（例如STUN[RFC5389]数据包、数据报传输层安全（DTLS）[RFC6347]握手数据包或ZRTP[RFC6189]控制数据包）上包含ECT标记。对于控制数据包，可能存在例外情况，如第7.2.2节中定义的基于STUN的ECN检查。
An RTP receiver that receives a packet with an ECN-CE mark, or that detects a packet loss, MUST schedule the transmission of an RTCP ECN feedback packet as soon as possible (subject to the constraints of [RFC4585] and [RFC3550]) to report this back to the sender unless no timely feedback is required. The feedback RTCP packet SHALL consist of at least one ECN feedback packet (Section 5.1) reporting on the packets received since the last ECN feedback packet and will contain (at least) an RTCP SR/RR packet and an SDES packet, unless reduced-size RTCP [RFC5506] is used. The RTP/AVPF profile in early or immediate feedback mode SHOULD be used where possible, to reduce the interval before feedback can be sent. To reduce the size of the feedback message, reduced-size RTCP [RFC5506] MAY be used if supported by the endpoints. Both RTP/AVPF and reduced-size RTCP MUST be negotiated in the session setup signalling before they can be used.
接收带有ECN-CE标记的数据包或检测到数据包丢失的RTP接收器必须尽快安排RTCP ECN反馈数据包的传输（受[RFC4585]和[RFC3550]的约束），以向发送方报告此情况，除非不需要及时反馈。反馈RTCP数据包应包括至少一个ECN反馈数据包（第5.1节），报告自上一个ECN反馈数据包以来收到的数据包，并将包含（至少）一个RTCP SR/RR数据包和一个SDES数据包，除非使用了减小尺寸的RTCP[RFC5506]。应尽可能使用早期或即时反馈模式下的RTP/AVPF配置文件，以缩短发送反馈之前的间隔。为了减小反馈消息的大小，如果端点支持，可以使用减小大小的RTCP[RFC5506]。RTP/AVPF和缩小的RTCP必须在会话设置信令中协商，然后才能使用。
Every time a regular compound RTCP packet is to be transmitted, an ECN-capable RTP receiver MUST include an RTCP XR ECN Summary Report as described in Section 5.2 as part of the compound packet.
每次传输常规复合RTCP数据包时，支持ECN的RTP接收器必须包括第5.2节所述的RTCP XR ECN摘要报告，作为复合数据包的一部分。
The multicast feedback implosion problem, which occurs when many receivers simultaneously send feedback to a single sender, must be considered. The RTP/AVPF transmission rules will limit the amount of feedback that can be sent, avoiding the implosion problem but also delaying feedback by varying degrees from nothing up to a full RTCP reporting interval. As a result, the full extent of a congestion situation may take some time to reach the sender, although some feedback should arrive in a reasonably timely manner, allowing the sender to react on a single or a few reports.
当多个接收者同时向单个发送者发送反馈时，必须考虑多播反馈内爆问题。RTP/AVPF传输规则将限制可发送的反馈量，避免内爆问题，但也会不同程度地延迟反馈，从零延迟到整个RTCP报告间隔。因此，拥塞情况的全部范围可能需要一段时间才能到达发送方，尽管一些反馈应该以合理的及时方式到达，从而允许发送方对单个或几个报告作出反应。
The reception of RTP packets with ECN-CE marks in the IP header is a notification that congestion is being experienced. The default reaction on the reception of these ECN-CE-marked packets MUST be to provide the congestion control algorithm with a congestion notification that triggers the algorithm to react as if packet loss had occurred. There should be no difference in congestion response if ECN-CE marks or packet drops are detected.
在IP报头中接收带有ECN-CE标记的RTP数据包是一种正在经历拥塞的通知。接收到这些ECN CE标记的数据包时的默认反应必须是向拥塞控制算法提供拥塞通知，该通知触发算法作出反应，就好像发生了数据包丢失一样。如果检测到ECN-CE标记或数据包丢失，则拥塞响应应该没有差异。
Other reactions to ECN-CE may be specified in the future, following IETF Review. Detailed designs of such alternative reactions MUST be specified in a Standards Track RFC and be reviewed to ensure they are safe for deployment under any restrictions specified. A potential example for an alternative reaction could be emergency communications (such as that generated by first responders, as opposed to the general public) in networks where the user has been authorised. A more detailed description of these other reactions, as well as the types of congestion control algorithms used by end-nodes, is outside the scope of this document.
对ECN-CE的其他反应可能在未来的IETF审查后指定。此类替代反应的详细设计必须在标准跟踪RFC中规定，并进行审查，以确保在规定的任何限制条件下安全部署。替代反应的一个潜在例子是，在用户已获得授权的网络中，紧急通信（如由第一响应者产生的通信，而不是由普通公众产生的通信）可能是一种替代反应。对这些其他反应以及终端节点使用的拥塞控制算法类型的更详细描述不在本文档的范围内。
Depending on the media format, type of session, and RTP topology used, there are several different types of congestion control that can be used:
根据使用的媒体格式、会话类型和RTP拓扑，可以使用几种不同类型的拥塞控制：
Sender-Driven Congestion Control: The sender is responsible for adapting the transmitted bitrate in response to RTCP ECN feedback. When the sender receives the ECN feedback data, it feeds this information into its congestion control or bitrate adaptation mechanism so that it can react as if packet loss was reported. The congestion control algorithm to be used is not specified here, although TFRC [RFC5348] is one example that might be used.
发送方驱动的拥塞控制：发送方负责根据RTCP ECN反馈调整传输比特率。当发送方接收到ECN反馈数据时，它将该信息反馈到其拥塞控制或比特率自适应机制中，以便它能够像报告数据包丢失一样作出反应。此处未指定要使用的拥塞控制算法，尽管TFRC[RFC5348]是可能使用的一个示例。
Receiver-Driven Congestion Control: In a receiver-driven congestion control mechanism, the receivers can react to the ECN-CE marks themselves without providing ECN-CE feedback to the sender. This may allow faster response than sender-driven congestion control in some circumstances and also scale to large number of receivers and multicast usage. One example of receiver-driven congestion control is implemented by providing the content in a layered way, with each layer providing improved media quality but also increased bandwidth usage. The receiver locally monitors the ECN-CE marks on received packets to check if it experiences congestion with the current number of layers. If congestion is experienced, the receiver drops one layer, thus reducing the resource consumption on the path towards itself. For example, if a layered media encoding scheme such as H.264 Scalable Video Coding (SVC) is used, the receiver may change its layer
接收方驱动的拥塞控制：在接收方驱动的拥塞控制机制中，接收方可以自己对ECN-CE标记作出反应，而无需向发送方提供ECN-CE反馈。在某些情况下，这可能允许比发送方驱动的拥塞控制更快的响应，并且还可以扩展到大量接收方和多播使用。接收器驱动的拥塞控制的一个示例是通过以分层方式提供内容来实现的，每一层提供改进的媒体质量，但也增加了带宽使用。接收器本地监视接收到的数据包上的ECN-CE标记，以检查其是否在当前层数下遇到拥塞。如果遇到拥塞，则接收器会降低一层，从而减少通向自身的路径上的资源消耗。例如，如果使用诸如H.264可伸缩视频编码（SVC）的分层媒体编码方案，则接收机可以改变其层
subscription and so reduce the bitrate it receives. The receiver MUST still send an RTCP XR ECN Summary to the sender, even if it can adapt without contact with the sender, so that the sender can determine if ECN is supported on the network path. The timeliness of RTCP feedback is less of a concern with receiver-driven congestion control, and regular RTCP reporting of ECN summary information is sufficient (without using RTP/AVPF immediate or early feedback).
订阅，从而降低接收的比特率。接收方仍必须向发送方发送RTCP XR ECN摘要，即使它可以在不与发送方联系的情况下进行调整，以便发送方可以确定网络路径上是否支持ECN。RTCP反馈的及时性与接收器驱动的拥塞控制无关，RTCP定期报告ECN摘要信息就足够了（不使用RTP/AVPF即时或早期反馈）。
Hybrid: There might be mechanisms that utilise both some receiver behaviours and some sender-side monitoring, thus requiring both feedback of congestion events to the sender and taking receiver decisions and possible signalling to the sender. In this case, the congestion control algorithm needs to use the signalling to indicate which features of ECN for RTP are required.
混合：可能存在同时利用某些接收器行为和某些发送方监控的机制，因此既需要向发送方反馈拥塞事件，也需要做出接收器决策，并可能向发送方发送信号。在这种情况下，拥塞控制算法需要使用信令来指示需要用于RTP的ECN的哪些特性。
Responding to congestion indication in the case of multicast traffic is a more complex problem than for unicast traffic. The fundamental problem is diverse paths, i.e., when different receivers don't see the same path and thus have different bottlenecks, so the receivers may get ECN-CE-marked packets due to congestion at different points in the network. This is problematic for sender-driven congestion control, since when receivers are heterogeneous in regards to capacity, the sender is limited to transmitting at the rate the slowest receiver can support. This often becomes a significant limitation as group size grows. Also, as group size increases, the frequency of reports from each receiver decreases, which further reduces the responsiveness of the mechanism. Receiver-driven congestion control has the advantage that each receiver can choose the appropriate rate for its network path, rather than all receivers having to settle for the lowest common rate.
在多播流量的情况下响应拥塞指示是比单播流量更复杂的问题。基本问题是不同的路径，即，当不同的接收器看不到相同的路径，因此具有不同的瓶颈时，由于网络中不同点的拥塞，接收器可能会得到ECN CE标记的数据包。这对于发送方驱动的拥塞控制是有问题的，因为当接收器在容量方面是异构的时，发送方仅限于以最慢的接收器能够支持的速率进行传输。随着团队规模的增长，这通常成为一个显著的限制。此外，随着组大小的增加，来自每个接收器的报告频率降低，这进一步降低了机制的响应性。接收器驱动的拥塞控制的优点是，每个接收器都可以为其网络路径选择适当的速率，而不是所有接收器都必须满足于最低的公共速率。
We note that ECN support is not a silver bullet to improving performance. The use of ECN gives the chance to respond to congestion before packets are dropped in the network, improving the user experience by allowing the RTP application to control how the quality is reduced. An application that ignores ECN Congestion Experienced feedback is not immune to congestion: the network will eventually begin to discard packets if traffic doesn't respond. To avoid packet loss, it is in the best interest of an application to respond to ECN congestion feedback promptly.
我们注意到，ECN支持并不是提高性能的灵丹妙药。ECN的使用提供了在数据包在网络中丢弃之前响应拥塞的机会，通过允许RTP应用程序控制质量降低的方式来改善用户体验。忽略ECN拥塞经验反馈的应用程序无法避免拥塞：如果流量没有响应，网络最终将开始丢弃数据包。为了避免数据包丢失，及时响应ECN拥塞反馈符合应用程序的最佳利益。
Senders and receivers can deliberately ignore ECN-CE and thus get a benefit over behaving flows (cheating). The ECN nonce [RFC3540] is an addition to TCP that attempts to solve this issue as long as the sender acts on behalf of the network. The assumption that senders
发送方和接收方可以故意忽略ECN-CE，从而从行为流（欺骗）中获益。ECN nonce[RFC3540]是TCP的一个补充，只要发送方代表网络行事，它就会尝试解决此问题。假设发送者
act on behalf of the network may be false due to the nature of peer-to-peer use of RTP. Still, a significant portion of RTP senders are infrastructure devices (for example, streaming media servers) that do have an interest in protecting both service quality and the network. Even though there may be cases where the nonce may be applicable for RTP, it is not included in this specification. This is because a receiver interested in cheating would simply claim to not support the nonce, or even ECN itself. It is, however, worth mentioning that, as real-time media is commonly sensitive to increased delay and packet loss, it will be in the interest of both the media sender and receivers to minimise the number and duration of any congestion events as they will adversely affect media quality.
由于点对点使用RTP的性质，代表网络的行为可能是错误的。尽管如此，RTP发送方的很大一部分是基础设施设备（例如，流媒体服务器），它们对保护服务质量和网络都有兴趣。即使在某些情况下，nonce可能适用于RTP，但本规范中不包括该nonce。这是因为对欺骗感兴趣的接收者只会声称不支持nonce，甚至不支持ECN本身。然而，值得一提的是，由于实时媒体通常对增加的延迟和数据包丢失非常敏感，因此尽可能减少任何拥塞事件的数量和持续时间对媒体质量产生不利影响符合媒体发送者和接收者的利益。
RTP sessions can also suffer from path changes resulting in a non-ECN-compliant node becoming part of the path. That node may perform either of two actions that has an effect on the ECN and application functionality. The gravest is if the node drops packets with the ECN field set to ECT(0), ECT(1), or ECN-CE. This can be detected by the receiver when it receives an RTCP SR packet indicating that a sender has sent a number of packets that it has not received. The sender may also detect such a middlebox based on the receiver's RTCP RR packet, when the extended sequence number is not advanced due to the failure to receive packets. If the packet loss is less than 100%, then packet loss reporting in either the ECN feedback information or RTCP RR will indicate the situation. The other action is to re-mark a packet from ECT or ECN-CE to not-ECT. That has less dire results; however, it should be detected so that ECN usage can be suspended to prevent misusing the network.
RTP会话还可能遭受路径更改的影响，导致不符合ECN的节点成为路径的一部分。该节点可以执行对ECN和应用程序功能有影响的两个操作之一。最严重的情况是节点丢弃ECN字段设置为ECT（0）、ECT（1）或ECN-CE的数据包。当接收器接收到一个RTCP SR数据包时，可以检测到这一点，该数据包指示发送方已经发送了许多它尚未接收到的数据包。当扩展序列号由于未能接收分组而未提前时，发送方还可以基于接收方的RTCP-RR分组检测这样的中间盒。如果数据包丢失小于100%，则ECN反馈信息或RTCP RR中的数据包丢失报告将指示情况。另一个操作是将来自ECT或ECN-CE的数据包重新标记为not ECT。结果不那么可怕；但是，应该对其进行检测，以便可以暂停ECN的使用，以防止误用网络。
The RTCP XR ECN summary packet and the ECN feedback packet allow the sender to compare the number of ECT-marked packets of different types received with the number it actually sent. The number of ECT packets received, plus the number of ECN-CE-marked and lost packets, should correspond to the number of sent ECT-marked packets plus the number of received duplicates. If these numbers don't agree, there are two likely reasons: a translator changing the stream or not carrying the ECN markings forward or some node re-marking the packets. In both cases, the usage of ECN is broken on the path. By tracking all the different possible ECN field values, a sender can quickly detect if some non-compliant behaviour is happening on the path.
RTCP XR ECN摘要数据包和ECN反馈数据包允许发送方将接收到的不同类型的ECT标记数据包的数量与其实际发送的数量进行比较。接收到的ECT数据包的数量加上ECN CE标记和丢失数据包的数量，应与发送的ECT标记数据包的数量加上接收到的重复数据包的数量相对应。如果这些数字不一致，可能有两个原因：转换器更改流或不向前携带ECN标记，或者某个节点重新标记数据包。在这两种情况下，ECN的使用在路径上都会中断。通过跟踪所有不同的可能ECN字段值，发送方可以快速检测路径上是否发生了不符合要求的行为。
Thus, packet losses and non-matching ECN field value statistics are possible indications of issues with using ECN over the path. The next section defines both sender and receiver reactions to these cases.
因此，数据包丢失和不匹配的ECN字段值统计数据可能表明在路径上使用ECN存在问题。下一节将定义发送方和接收方对这些情况的反应。
Upon the detection of a potential failure, both the sender and the receiver can react to mitigate the situation.
一旦检测到潜在的故障，发送方和接收方都可以做出反应来缓解这种情况。
A receiver that detects a packet loss burst MAY schedule an early feedback packet that includes at least the RTCP RR and the ECN feedback message to report this to the sender. This will speed up the detection of the loss at the sender, thus triggering sender-side mitigation.
检测到分组丢失突发的接收机可以调度至少包括RTCP RR和ECN反馈消息的早期反馈分组，以将此报告给发送方。这将加快发送方对丢失的检测，从而触发发送方缓解。
A sender that detects high packet loss rates for ECT-marked packets SHOULD immediately switch to sending packets as not-ECT to determine if the losses are potentially due to the ECT markings. If the losses disappear when the ECT-marking is discontinued, the RTP sender should go back to initiation procedures to attempt to verify the apparent loss of ECN capability of the used path. If a re-initiation fails, then two possible actions exist:
如果发送方检测到带有ECT标记的数据包的高数据包丢失率，则应立即切换为将数据包作为非ECT发送，以确定丢失是否可能是由于ECT标记造成的。如果在ECT标记停止时损失消失，RTP发送器应返回启动程序，尝试验证所用路径的ECN能力的明显损失。如果重新启动失败，则存在两种可能的操作：
1. Periodically retry the ECN initiation to detect if a path change occurs to a path that is ECN capable.
1. 定期重试ECN启动，以检测支持ECN的路径是否发生路径更改。
2. Renegotiate the session to disable ECN support. This is a choice that is suitable if the impact of ECT probing on the media quality is noticeable. If multiple initiations have been successful, but the following full usage of ECN has resulted in the fallback procedures, then disabling of the ECN support is RECOMMENDED.
2. 重新协商会话以禁用ECN支持。如果ECT探测对介质质量的影响是明显的，那么这是一个合适的选择。如果多次启动成功，但以下ECN的完全使用导致了回退过程，则建议禁用ECN支持。
We foresee the possibility of flapping ECN capability due to several reasons: video-switching MCU or similar middleboxes that select to deliver media from the sender only intermittently; load-balancing devices that may in worst case result in some packets taking a different network path than the others; mobility solutions that switch the underlying network path in a transparent way for the sender or receiver; and membership changes in a multicast group. It is, however, appropriate to mention that there are also issues such as re-routing of traffic due to a flappy route table or excessive reordering and other issues that are not directly ECN related but nevertheless may cause problems for ECN.
我们预计，由于以下几个原因，ECN能力可能会出现波动：视频切换MCU或类似的中间盒，它们选择仅间歇地从发送方发送媒体；负载平衡设备，在最坏情况下可能导致某些数据包采用与其他数据包不同的网络路径；为发送方或接收方以透明方式切换底层网络路径的移动性解决方案；以及多播组中的成员身份更改。然而，值得一提的是，还存在一些问题，例如由于路径表不稳定或过度重新排序而导致的流量重新路由，以及其他与ECN没有直接关系但可能会导致ECN问题的问题。
This section contains discussion on how the ECN Summary Report information can be used to detect various types of ECN path issues. We first review the information the RTCP reports provide on a per-source (SSRC) basis:
本节讨论如何使用ECN摘要报告信息来检测各种类型的ECN路径问题。我们首先审查RTCP报告在每个来源（SSRC）的基础上提供的信息：
ECN-CE Counter: The number of RTP packets received so far in the session with an ECN field set to CE.
ECN-CE计数器：在ECN字段设置为CE的会话中，到目前为止接收到的RTP数据包数。
ECT (0/1) Counters: The number of RTP packets received so far in the session with an ECN field set to ECT (0) and ECT (1) respectively.
ECT（0/1）计数器：在ECN字段分别设置为ECT（0）和ECT（1）的会话中，到目前为止接收到的RTP数据包数。
not-ECT Counter: The number of RTP packets received so far in the session with an ECN field set to not-ECT.
not ECT计数器：在ECN字段设置为not ECT的会话中，到目前为止接收到的RTP数据包数。
Lost Packets Counter: The number of RTP packets that where expected based on sequence numbers but never received.
Lost Packets Counter（丢失数据包计数器）：根据序列号预期但从未收到的RTP数据包数。
Duplication Counter: The number of received RTP packets that are duplicates of already received ones.
重复计数器：已接收RTP数据包的重复数。
Extended Highest Sequence number: The highest sequence number seen when sending this report, but with additional bits, to handle disambiguation when wrapping the RTP sequence number field.
扩展最高序列号：发送此报告时看到的最高序列号，但带有附加位，用于在包装RTP序列号字段时处理消歧。
The counters will be initialised to zero to provide values for the RTP stream sender from the first report. After the first report, the changes between the last received report and the previous report are determined by simply taking the values of the latest minus the previous, taking wrapping into account. This definition is also robust to packet losses, since if one report is missing, the reporting interval becomes longer, but is otherwise equally valid.
计数器将初始化为零，以便为第一个报告中的RTP流发送器提供值。在第一次报告之后，上一次收到的报告与上一次报告之间的更改仅通过将最近一次报告的值减去上一次报告的值来确定，并考虑到包装。此定义对数据包丢失也很可靠，因为如果一个报告丢失，报告间隔会变长，但在其他方面同样有效。
In a perfect world, the number of not-ECT packets received should be equal to the number sent minus the Lost Packets Counter, and the sum of the ECT(0), ECT(1), and ECN-CE counters should be equal to the number of ECT-marked packet sent. Two issues may cause a mismatch in these statistics: severe network congestion or unresponsive congestion control might cause some ECT-marked packets to be lost, and packet duplication might result in some packets being received and counted in the statistics multiple times (potentially with a different ECN-mark on each copy of the duplicate).
在理想情况下，接收到的非ECT数据包数量应等于发送的数据包数量减去丢失数据包计数器，ECT（0）、ECT（1）和ECN-CE计数器的总和应等于发送的ECT标记数据包数量。有两个问题可能会导致这些统计数据不匹配：严重的网络拥塞或无响应的拥塞控制可能会导致某些ECT标记的数据包丢失，而数据包重复可能会导致某些数据包在统计数据中多次被接收和计数（可能在重复数据的每个副本上都有不同的ECN标记）。
The rate of packet duplication is tracked, allowing one to take the duplication into account. The value of the ECN field for duplicates will also be counted, and when comparing the figures, one needs to take into account in the calculation that some fraction of packet duplicates are not-ECT and some are ECT. Thus, when only sending not-ECT, the number of sent packets plus reported duplicates equals the number of received not-ECT. When sending only ECT, the number of sent ECT packets plus duplicates will equal ECT(0), ECT(1), ECN-CE, and packet loss. When sending a mix of not-ECT and ECT, there is an uncertainty if any duplicate or packet loss was an not-ECT or ECT. If the packet duplication is completely independent of the usage of
跟踪数据包复制的速率，以便考虑复制。重复数据的ECN字段值也将被计算，并且在比较这些数字时，需要在计算中考虑到部分数据包重复数据不是ECT，而部分数据包重复数据是ECT。因此，当仅发送not ECT时，发送的数据包数加上报告的重复数等于接收到的not ECT数。仅发送ECT时，发送的ECT数据包加上重复数据包的数量将等于ECT（0）、ECT（1）、ECN-CE和数据包丢失。当发送not ECT和ECT的混合时，不确定是否有任何重复或数据包丢失是not ECT或ECT。如果数据包复制完全独立于
ECN, then the fraction of packet duplicates should be in relation to the number of not-ECT vs. ECT packets sent during the period of comparison. This relation does not hold for packet loss, where higher rates of packet loss for not-ECT is expected than for ECT traffic.
ECN，则数据包重复部分应与比较期间发送的not ECT与ECT数据包的数量相关。这种关系不适用于数据包丢失，其中非ECT的数据包丢失率预计高于ECT流量。
Detecting clearing of ECN field: If the ratio between ECT and not-ECT transmitted in the reports has become all not-ECT, or has substantially changed towards not-ECT, then this is clearly an indication that the path results in clearing of the ECT field.
检测ECN字段的清除：如果报告中传输的ECT和not ECT之间的比率已变为all not ECT，或已实质性地变为not ECT，则这显然表明路径导致ECT字段的清除。
Dropping of ECT packets: To determine if the packet-drop ratio is different between not-ECT and ECT-marked transmission requires a mix of transmitted traffic. The sender should compare if the delivery percentage (delivered/transmitted) between ECT and not-ECT is significantly different. Care must be taken if the number of packets is low in either of the categories. One must also take into account the level of CE marking. A CE-marked packet would have been dropped unless it was ECT marked. Thus, the packet loss level for not-ECT should be approximately equal to the loss rate for ECT when counting the CE-marked packets as lost ones. A sender performing this calculation needs to ensure that the difference is statistically significant.
ECT数据包丢弃：要确定非ECT和ECT标记传输之间的数据包丢弃率是否不同，需要混合传输流量。发送方应比较ECT与非ECT之间的交付百分比（交付/传输）是否存在显著差异。如果任一类别中的数据包数量较低，则必须小心。还必须考虑CE标记的级别。除非标记了ECT，否则CE标记的数据包将被丢弃。因此，当将CE标记的分组作为丢失分组进行计数时，not-ECT的分组丢失水平应该大约等于ECT的丢失率。执行此计算的发送方需要确保差异具有统计显著性。
If erroneous behaviour is detected, it should be logged to enable follow up and statistics gathering.
如果检测到错误行为，应将其记录下来，以便进行跟踪和统计数据收集。
RTP translators and mixers that support ECN for RTP are required to process and potentially modify or generate ECN marking in RTP packets. They also need to process and potentially modify or generate RTCP ECN feedback packets for the translated and/or mixed streams. This includes both downstream RTCP reports generated by the media sender and also reports generated by the receivers, flowing upstream back towards the sender.
支持ECN for RTP的RTP转换器和混频器需要处理并可能修改或生成RTP数据包中的ECN标记。他们还需要处理并可能修改或生成用于翻译和/或混合流的RTCP ECN反馈数据包。这既包括由媒体发送方生成的下游RTCP报告，也包括由接收方生成的、向上游流回发送方的报告。
Some translators only perform transport-level translations, such as copying packets from one address domain, like from unicast to multicast. They may also perform relaying like copying an incoming packet to a number of unicast receivers. This section details the ECN-related actions for RTP and RTCP.
一些转换器只执行传输级别的转换，例如从一个地址域复制数据包，例如从单播复制到多播。它们还可以执行中继，例如将传入分组复制到多个单播接收机。本节详细介绍RTP和RTCP的ECN相关操作。
For RTP data packets, the translator, which does not modify the media stream, SHOULD copy the ECN bits unchanged from the incoming to the outgoing datagrams, unless the translator itself is overloaded and experiencing congestion, in which case it may mark the outgoing datagrams with an ECN-CE mark.
对于RTP数据包，不修改媒体流的转换器应将ECN位从传入数据包复制到传出数据包，除非转换器本身过载并遇到拥塞，在这种情况下，它可以用ECN-CE标记传出数据包。
A transport translator does not modify RTCP packets. However, it MUST perform the corresponding transport translation of the RTCP packets as it does with RTP packets being sent from the same source/ endpoint.
传输转换器不修改RTCP数据包。但是，它必须执行RTCP数据包的相应传输转换，就像从同一源/端点发送RTP数据包一样。
An RTP translator may fragment or reassemble RTP data packets without changing the media encoding and without reference to the congestion state of the networks it bridges. An example of this might be to combine packets of a voice-over-IP stream coded with one 20 ms frame per RTP packet into new RTP packets with two 20 ms frames per packet, thereby reducing the header overhead and thus stream bandwidth, at the expense of an increase in latency. If multiple data packets are re-encoded into one, or vice versa, the RTP translator MUST assign new sequence numbers to the outgoing packets. Losses in the incoming RTP packet stream may also induce corresponding gaps in the outgoing RTP sequence numbers. An RTP translator MUST rewrite RTCP packets to make the corresponding changes to their sequence numbers and to reflect the impact of the fragmentation or reassembly. This section describes how that rewriting is to be done for RTCP ECN feedback packets. Section 7.2 of [RFC3550] describes general procedures for other RTCP packet types.
RTP转换器可以在不改变媒体编码和不参考其桥接的网络的拥塞状态的情况下对RTP数据包进行分段或重新组装。这方面的一个示例可以是将IP语音流的分组（每个RTP分组编码一个20ms帧）组合成新的RTP分组（每个分组编码两个20ms帧），从而以延迟增加为代价降低报头开销和流带宽。如果将多个数据包重新编码为一个数据包，或者反之亦然，RTP转换器必须为传出的数据包分配新的序列号。传入RTP分组流中的丢失也可能导致传出RTP序列号中的相应间隙。RTP转换器必须重写RTCP数据包，以对其序列号进行相应的更改，并反映碎片或重组的影响。本节介绍如何对RTCP ECN反馈数据包进行重写。[RFC3550]第7.2节描述了其他RTCP数据包类型的一般程序。
The processing of arriving RTP packets for this case is as follows. If an ECN-marked packet is split into two, then both the outgoing packets MUST be ECN marked identically to the original; if several ECN-marked packets are combined into one, the outgoing packet MUST be either ECN-CE marked or dropped if any of the incoming packets are ECN-CE marked. If the outgoing combined packet is not ECN-CE marked, then it MUST be ECT marked if any of the incoming packets were ECT marked.
对于这种情况，到达的RTP数据包的处理如下。如果一个带有ECN标记的数据包被分成两个，那么两个传出数据包的ECN标记必须与原始数据包相同；如果多个带有ECN标记的数据包组合成一个，则传出数据包必须带有ECN-CE标记，或者如果任何传入数据包带有ECN-CE标记，则必须丢弃。如果传出组合数据包未标记ECN-CE，则如果任何传入数据包已标记ECT，则必须标记ECT。
RTCP ECN feedback packets (Section 5.1) contain seven fields that are rewritten in an RTP translator that fragments or reassembles packets: the extended highest sequence number, the duplication counter, the Lost Packets Counter, the ECN-CE counter, and not-ECT counter, the ECT(0) counter, and the ECT(1) counter. The RTCP XR report block for ECN summary information (Section 5.2) includes all of these fields except the extended highest sequence number, which is present in the
RTCP ECN反馈数据包（第5.1节）包含七个字段，这些字段在对数据包进行分段或重新组装的RTP转换器中重写：扩展最高序列号、复制计数器、丢失数据包计数器、ECN-CE计数器和非ECT计数器、ECT（0）计数器和ECT（1）计数器。ECN摘要信息的RTCP XR报告块（第5.2节）包括所有这些字段，但扩展的最高序列号除外，该序列号出现在
report block in an SR or RR packet. The procedures for rewriting these fields are the same for both the RTCP ECN feedback packet and the RTCP XR ECN summary packet.
SR或RR数据包中的报告块。对于RTCP ECN反馈数据包和RTCP XR ECN摘要数据包，重写这些字段的步骤相同。
When receiving an RTCP ECN feedback packet for the translated stream, an RTP translator first determines the range of packets to which the report corresponds. The extended highest sequence number in the RTCP ECN feedback packet (or in the RTCP SR/RR packet contained within the compound packet, in the case of RTCP XR ECN Summary Reports) specifies the end sequence number of the range. For the first RTCP ECN feedback packet received, the initial extended sequence number of the range may be determined by subtracting the sum of the Lost Packets Counter, the ECN-CE counter, the not-ECT counter, the ECT(0) counter and the ECT(1) counter minus the duplication counter, from the extended highest sequence number. For subsequent RTCP ECN feedback packets, the starting sequence number may be determined as being one after the extended highest sequence number of the previous RTCP ECN feedback packet received from the same SSRC. These values are in the sequence number space of the translated packets.
当接收到翻译流的RTCP ECN反馈数据包时，RTP转换器首先确定报告对应的数据包范围。RTCP ECN反馈数据包（或在RTCP XR ECN摘要报告的情况下，复合数据包中包含的RTCP SR/RR数据包）中的扩展最高序列号指定范围的结束序列号。对于接收到的第一个RTCP ECN反馈数据包，可通过从扩展的最高序列号减去丢失数据包计数器、ECN-CE计数器、非ECT计数器、ECT（0）计数器和ECT（1）计数器的总和减去复制计数器来确定范围的初始扩展序列号。对于后续RTCP ECN反馈数据包，起始序列号可确定为在从同一SSRC接收的先前RTCP ECN反馈数据包的扩展最高序列号之后的一个。这些值位于已翻译数据包的序列号空间中。
Based on its knowledge of the translation process, the translator determines the sequence number range for the corresponding original, pre-translation, packets. The extended highest sequence number in the RTCP ECN feedback packet is rewritten to match the final sequence number in the pre-translation sequence number range.
翻译人员根据其对翻译过程的了解，确定相应原始、翻译前数据包的序列号范围。将重写RTCP ECN反馈数据包中的扩展最高序列号，以匹配翻译前序列号范围中的最终序列号。
The translator then determines the ratio, R, of the number of packets in the translated sequence number space (numTrans) to the number of packets in the pre-translation sequence number space (numOrig) such that R = numTrans / numOrig. The counter values in the RTCP ECN Feedback Report are then scaled by dividing each of them by R. For example, if the translation process combines two RTP packets into one, then numOrig will be twice numTrans, giving R=0.5, and the counters in the translated RTCP ECN feedback packet will be twice those in the original.
然后，转换器确定翻译序列号空间（numTrans）中的分组数与翻译前序列号空间（numOrig）中的分组数的比率R，使得R＝numTrans/numOrig。然后，将RTCP ECN反馈报告中的计数器值除以R，以调整其比例。例如，如果翻译过程将两个RTP数据包合并为一个，则numOrig将是numTrans的两倍，即R=0.5，翻译后的RTCP ECN反馈数据包中的计数器将是原始数据包中的两倍。
The ratio, R, may have a value that leads to non-integer multiples of the counters when translating the RTCP packet. For example, a Voice over IP (VoIP) translator that combines two adjacent RTP packets into one if they contain active speech data, but passes comfort noise packets unchanged, would have an R value of between 0.5 and 1.0 depending on the amount of active speech. Since the counter values in the translated RTCP report are integer values, rounding will be necessary in this case.
在转换RTCP数据包时，比率R的值可能会导致计数器的非整数倍。例如，如果IP语音（VoIP）转换器将两个相邻的RTP数据包合并为一个，但它们包含活动语音数据，但传递的舒适噪声数据包不变，则其R值将在0.5到1.0之间，具体取决于活动语音的数量。由于转换后的RTCP报告中的计数器值是整数值，因此在这种情况下需要舍入。
When rounding counter values in the translated RTCP packet, the translator should try to ensure that they sum to the number of RTP packets in the pre-translation sequence number space (numOrig). The
在对翻译后的RTCP数据包中的计数器值进行舍入时，转换器应尝试确保它们与翻译前序列号空间（numOrig）中的RTP数据包数相加。这个
translator should also try to ensure that no non-zero counter is rounded to a zero value, unless the pre-translated values are zero, since that will lose information that a particular type of event has occurred. It is recognised that it may be impossible to satisfy both of these constraints; in such cases, it is better to ensure that no non-zero counter is mapped to a zero value, since this preserves congestion adaptation and helps the RTCP-based ECN initiation process.
转换器还应尝试确保非零计数器不会四舍五入为零值，除非预转换的值为零，因为这将丢失发生特定类型事件的信息。人们认识到，可能不可能同时满足这两个约束条件；在这种情况下，最好确保没有非零计数器映射到零值，因为这样可以保留拥塞自适应，并有助于基于RTCP的ECN启动过程。
One should be aware of the impact this type of translator has on the measurement of packet duplication. A translator performing aggregation and most likely also an fragmenting translator will suppress any duplication happening prior to itself. Thus, the reports and what is being scaled will only represent packet duplication happening from the translator to the receiver reporting on the flow.
人们应该意识到这种类型的翻译器对数据包重复测量的影响。执行聚合的翻译器和最有可能的碎片翻译器将抑制之前发生的任何复制。因此，报告和被缩放的内容将仅表示从转换器到在流上报告的接收器发生的数据包复制。
It should be noted that scaling the RTCP counter values in this way is meaningful only on the assumption that the level of congestion in the network is related to the number of packets being sent. This is likely to be a reasonable assumption in the type of environment where RTP translators that fragment or reassemble packets are deployed, as their entire purpose is to change the number of packets being sent to adapt to known limitations of the network, but is not necessarily valid in general.
应注意，以这种方式缩放RTCP计数器值仅在假设网络中的拥塞水平与发送的数据包数量相关的情况下才有意义。这可能是一种合理的假设，在RTP翻译器部署片段或重组数据包的环境类型中，因为它们的全部目的是改变发送的数据包的数量以适应网络的已知限制，但通常不一定有效。
The rewritten RTCP ECN Feedback Report is sent from the other side of the translator to that from which it arrived (as part of a compound RTCP packet containing other translated RTCP packets, where appropriate).
重写的RTCP ECN反馈报告从翻译器的另一端发送到它到达的另一端（作为包含其他翻译的RTCP数据包的复合RTCP数据包的一部分，如适用）。
An RTP translator that acts as a media transcoder cannot directly forward RTCP packets corresponding to the transcoded stream, since those packets will relate to the non-transcoded stream and will not be useful in relation to the transcoded RTP flow. Such a transcoder will need to interpose itself into the RTCP flow, acting as a proxy for the receiver to generate RTCP feedback in the direction of the sender relating to the pre-transcoded stream and acting in place of the sender to generate RTCP relating to the transcoded stream to be sent towards the receiver. This section describes how this proxying is to be done for RTCP ECN feedback packets. Section 7.2 of [RFC3550] describes general procedures for other RTCP packet types.
充当媒体转码器的RTP转换器不能直接转发对应于转码流的RTCP数据包，因为这些数据包将与非转码流相关，并且对于转码RTP流不有用。这样的转码器将需要将其自身插入到RTCP流中，充当接收器的代理以在与预转码流相关的发送器的方向上生成RTCP反馈，并代替发送器生成与要发送到接收器的转码流相关的RTCP。本节介绍如何对RTCP ECN反馈数据包执行代理。[RFC3550]第7.2节描述了其他RTCP数据包类型的一般程序。
An RTP translator acting as a media transcoder in this manner does not have its own SSRC and hence is not visible to other entities at the RTP layer. RTCP ECN feedback packets and RTCP XR report blocks
以这种方式充当媒体转码器的RTP转换器没有自己的SSRC，因此RTP层的其他实体不可见。RTCP ECN反馈数据包和RTCP XR报告块
for ECN summary information that are received from downstream relate to the translated stream and so must be processed by the translator as if they were the original media source. These reports drive the congestion control loop and media adaptation between the translator and the downstream receiver. If there are multiple downstream receivers, a logically separate transcoder instance must be used for each receiver and must process RTCP ECN Feedback and Summary Reports independently of the other transcoder instances. An RTP translator acting as a media transcoder in this manner MUST NOT forward RTCP ECN feedback packets or RTCP XR ECN Summary Reports from downstream receivers in the upstream direction.
对于ECN，从下游接收的摘要信息与翻译流相关，因此必须由翻译器处理，就像它们是原始媒体源一样。这些报告驱动转换器和下游接收器之间的拥塞控制循环和媒体自适应。如果有多个下游接收器，则必须为每个接收器使用逻辑上独立的转码器实例，并且必须独立于其他转码器实例处理RTCP ECN反馈和摘要报告。以这种方式充当媒体转码器的RTP转换器不得在上游方向转发来自下游接收器的RTCP ECN反馈数据包或RTCP XR ECN摘要报告。
An RTP translator acting as a media transcoder will generate RTCP reports upstream towards the original media sender, based on the reception quality of the original media stream at the translator. The translator will run a separate congestion control loop and media adaptation between itself and the media sender for each of its downstream receivers and must generate RTCP ECN feedback packets and RTCP XR ECN Summary Reports for that congestion control loop using the SSRC of that downstream receiver.
充当媒体转码器的RTP翻译器将基于翻译器处原始媒体流的接收质量，向原始媒体发送器上游生成RTCP报告。转换器将为其每个下游接收器在其自身和媒体发送方之间运行单独的拥塞控制环路和媒体适配，并且必须使用该下游接收器的SSRC为该拥塞控制环路生成RTCP ECN反馈数据包和RTCP XR ECN摘要报告。
An RTP mixer terminates one-or-more RTP flows, combines them into a single outgoing media stream, and transmits that new stream as a separate RTP flow. A mixer has its own SSRC and is visible to other participants in the session at the RTP layer.
RTP混合器终止一个或多个RTP流，将它们组合成单个传出媒体流，并将该新流作为单独的RTP流传输。混音器有自己的SSRC，在RTP层对会话中的其他参与者可见。
An ECN-aware RTP mixer must generate RTCP ECN feedback packets and RTCP XR report blocks for ECN summary information relating to the RTP flows it terminates, in exactly the same way it would if it were an RTP receiver. These reports form part of the congestion control loop between the mixer and the media senders generating the streams it is mixing. A separate control loop runs between each sender and the mixer.
感知ECN的RTP混合器必须生成RTCP ECN反馈数据包和RTCP XR报告块，以获取与其终止的RTP流相关的ECN摘要信息，其方式与RTP接收器完全相同。这些报告构成混合器和生成其正在混合的流的媒体发送器之间的拥塞控制环路的一部分。在每个发送器和混合器之间运行一个单独的控制回路。
An ECN-aware RTP mixer will negotiate and initiate the use of ECN on the mixed RTP flows it generates and will accept and process RTCP ECN Feedback Reports and RTCP XR report blocks for ECN relating to those mixed flows as if it were a standard media sender. A congestion control loop runs between the mixer and its receivers, driven in part by the ECN reports received.
感知ECN的RTP混合器将协商并启动在其生成的混合RTP流上使用ECN，并将接受和处理与这些混合流相关的RTCP ECN反馈报告和RTCP XR报告块，就像它是标准媒体发送器一样。拥塞控制环路在混频器及其接收器之间运行，部分由接收到的ECN报告驱动。
An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR ECN Summary Reports from downstream receivers in the upstream direction.
RTP混音器不得向上游方向转发来自下游接收器的RTCP ECN反馈数据包或RTCP XR ECN摘要报告。
To allow the use of ECN with RTP over UDP, an RTP implementation desiring to support receiving ECN-controlled media streams must support reading the value of the ECT bits on received UDP datagrams, and an RTP implementation desiring to support sending ECN-controlled media streams must support setting the ECT bits in outgoing UDP datagrams. The standard Berkeley sockets API pre-dates the specification of ECN and does not provide the functionality that is required for this mechanism to be used with UDP flows, making this specification difficult to implement portably.
为了允许在UDP上通过RTP使用ECN，希望支持接收ECN控制的媒体流的RTP实现必须支持读取接收到的UDP数据报上的ECT位的值，并且希望支持发送ECN控制的媒体流的RTP实现必须支持设置传出UDP数据报中的ECT位。标准的Berkeley sockets API早于ECN规范，并且没有提供此机制与UDP流一起使用所需的功能，这使得此规范难以可移植地实现。
Following the guidelines in [RFC4566], the IANA has registered one new media-level SDP attribute:
按照[RFC4566]中的指南，IANA注册了一个新的媒体级SDP属性：
o Contact name, email address and telephone number: Authors of RFC 6679
o 联系人姓名、电子邮件地址和电话号码：RFC 6679的作者
o Attribute-name: ecn-capable-rtp
o 属性名称：支持ecn的rtp
o Type of attribute: media-level
o 属性类型：媒体级别
o Subject to charset: no
o 以字符集为准：否
This attribute defines the ability to negotiate the use of ECT (ECN-capable transport) for RTP flows running over UDP/IP. This attribute is put in the SDP offer if the offering party wishes to receive an ECT flow. The answering party then includes the attribute in the answer if it wishes to receive an ECT flow. If the answerer does not include the attribute, then ECT MUST be disabled in both directions.
此属性定义协商在UDP/IP上运行的RTP流使用ECT（支持ECN的传输）的能力。如果要约方希望接收ECT流，则此属性将放入SDP要约中。然后，如果应答方希望接收ECT流，则在应答中包含该属性。如果回答者不包括该属性，则必须在两个方向上禁用ECT。
The IANA has registered one new RTP/AVPF Transport-Layer Feedback Message in the table of FMT values for RTPFB Payload Types [RFC4585] as defined in Section 5.1:
IANA已在第5.1节中定义的RTPFB有效载荷类型[RFC4585]的FMT值表中注册了一条新的RTP/AVPF传输层反馈消息：
Name: RTCP-ECN-FB Long name: RTCP ECN Feedback Value: 8 Reference: RFC 6679
名称：RTCP-ECN-FB长名称：RTCP ECN反馈值：8参考：RFC 6679
The IANA has registered one new SDP "rtcp-fb" attribute "nack" parameter "ecn" in the SDP ("ack" and "nack" Attribute Values) registry.
IANA已在SDP（“ack”和“nack”属性值）注册表中注册了一个新的SDP“rtcp fb”属性“nack”参数“ecn”。
Value name: ecn Long name: Explicit Congestion Notification Usable with: nack Reference: RFC 6679
值名称：ecn长名称：显式拥塞通知可用于：nack引用：RFC 6679
The IANA has registered one new RTCP XR Block Type as defined in Section 5.2:
IANA已注册了第5.2节中定义的一种新RTCP XR块类型：
Block Type: 13 Name: ECN Summary Report Reference: RFC 6679
块类型：13名称：ECN摘要报告参考：RFC 6679
The IANA has registered one new RTCP XR SDP Parameter "ecn-sum" in the "RTCP XR SDP Parameters" registry.
IANA已在“RTCP XR SDP参数”注册表中注册了一个新的RTCP XR SDP参数“ecn sum”。
Parameter name XR block (block type and name)
-------------- ------------------------------------
ecn-sum 13 ECN Summary Report
Parameter name XR block (block type and name)
-------------- ------------------------------------
ecn-sum 13 ECN Summary Report
A new STUN [RFC5389] attribute in the comprehension-optional range under IETF Review (0x8000-0xFFFF) has been assigned to the ECN-CHECK STUN attribute (0x802D) defined in Section 7.2.2. The STUN attribute registry can currently be found at: http://www.iana.org/assignments/stun-parameters.
IETF审查下的理解可选范围（0x8000-0xFFFF）中的新眩晕[RFC5389]属性已分配给第7.2.2节中定义的ECN-CHECK眩晕属性（0x802D）。眩晕属性注册表当前可在以下位置找到：http://www.iana.org/assignments/stun-parameters.
A new ICE option "rtp+ecn" has been registered in the "ICE Options" registry created by [RFC6336].
[RFC6336]创建的“ICE选项”注册表中已注册了一个新的ICE选项“rtp+ecn”。
The use of ECN with RTP over UDP as specified in this document has the following known security issues that need to be considered.
如本文档所述，将ECN与UDP上的RTP一起使用存在以下需要考虑的已知安全问题。
External threats to the RTP and RTCP traffic:
RTP和RTCP流量的外部威胁：
Denial of Service affecting RTCP: An attacker that can modify the traffic between the media sender and a receiver can achieve either of two things: 1) report a lot of packets as being congestion experience marked, thus forcing the sender into a congestion response; or 2) ensure that the sender disables the usage of ECN by reporting failures to receive ECN by changing the counter fields. This can also be accomplished by injecting false RTCP packets to the media sender. Reporting a lot of ECN-CE-marked traffic is likely the more efficient denial-of-service tool as that may likely force the application to use the lowest possible bitrates. The prevention against an external threat is to integrity protect the RTCP feedback information and authenticate the sender.
影响RTCP的拒绝服务：能够修改媒体发送方和接收方之间通信量的攻击者可以实现以下两种目的之一：1）将大量数据包报告为已标记拥塞体验，从而迫使发送方做出拥塞响应；或2）通过更改计数器字段来报告接收ECN的失败，确保发送方禁用ECN的使用。这也可以通过向媒体发送方注入错误的RTCP数据包来实现。报告大量ECN CE标记的流量可能是更有效的拒绝服务工具，因为这可能会迫使应用程序使用尽可能低的比特率。防止外部威胁的措施是完整性保护RTCP反馈信息并对发送方进行身份验证。
Information leakage: The ECN feedback mechanism exposes the receiver's perceived packet loss and the packets it considers to be ECN-CE marked. This is mostly not considered sensitive information. If it is considered sensitive, the RTCP feedback should be encrypted.
信息泄漏：ECN反馈机制暴露了接收方感知到的数据包丢失和它认为是ECN-CE标记的数据包。这通常不被视为敏感信息。如果认为敏感，则应加密RTCP反馈。
Changing the ECN bits: An on-path attacker that sees the RTP packet flow from sender to receiver and who has the capability to change the packets can rewrite ECT into ECN-CE, thus leading to erroneous congestion response in the sender or receiver. This denial of service against the media quality in the RTP session is impossible for an endpoint to protect itself against. Only network infrastructure nodes can detect this illicit re-marking. It will be mitigated by turning off ECN; however, if the attacker can modify its response to drop packets, the same vulnerability exist.
更改ECN位：发现RTP数据包从发送方流向接收方且有能力更改数据包的路径上攻击者可以将ECT重写为ECN-CE，从而导致发送方或接收方出现错误的拥塞响应。这种针对RTP会话中媒体质量的拒绝服务对于端点来说是不可能保护自己的。只有网络基础设施节点才能检测到这种非法重新标记。它将通过关闭ECN来缓解；但是，如果攻击者可以修改其响应以丢弃数据包，则存在相同的漏洞。
Denial of Service affecting the session setup signalling: If an attacker can modify the session signalling, it can prevent the usage of ECN by removing the signalling attributes used to indicate that the initiator is capable and willing to use ECN with RTP/UDP. This attack can be prevented by authentication and integrity protection of the signalling. We do note that any attacker that can modify the signalling has more interesting attacks they can perform than prevent the usage of ECN, like inserting itself as a middleman in the media flows enabling wire-tapping also for an off-path attacker.
影响会话设置信令的拒绝服务：如果攻击者可以修改会话信令，则可以通过删除用于指示启动器能够并愿意将ECN与RTP/UDP一起使用的信令属性来阻止ECN的使用。通过对信令进行身份验证和完整性保护，可以防止这种攻击。我们注意到，任何能够修改信令的攻击者都可以执行比阻止使用ECN更有趣的攻击，比如将自身作为中间人插入媒体流中，从而也可以对非路径攻击者进行窃听。
Threats that exist from misbehaving senders or receivers:
行为不端的发送方或接收方存在的威胁：
Receivers cheating: A receiver may attempt to cheat and fail to report reception of ECN-CE-marked packets. The benefit for a receiver cheating in its reporting would be to get an unfair
接收者欺骗：接收者可能试图欺骗并未能报告接收到ECN CE标记的数据包。接收者在报告中作弊的好处是得到不公平的赔偿
bitrate share across the resource bottleneck. It is far from certain that a receiver would be able to get a significant larger share of the resources. That assumes a high enough level of aggregation that there are flows to acquire shares from. The risk of cheating is that failure to react to congestion results in packet loss and increased path delay.
跨资源瓶颈的比特率共享。接收者能否获得更大的资源份额还远未可知。这需要有足够高的聚合级别，以便有资金流从中获取股份。作弊的风险在于，对拥塞的反应失败会导致数据包丢失和路径延迟增加。
Receivers misbehaving: A receiver may prevent the usage of ECN in an RTP session by reporting itself as non-ECN capable, forcing the sender to turn off usage of ECN. In a point-to-point scenario, there is little incentive to do this as it will only affect the receiver, thus failing to utilise an optimisation. For multi-party sessions, some motivation exists for why a receiver would misbehave as it can prevent the other receivers from using ECN. As an insider into the session, it is difficult to determine if a receiver is misbehaving or simply incapable, making it basically impossible in the incremental deployment phase of ECN for RTP usage to determine this. If additional information about the receivers and the network is known, it might be possible to deduce that a receiver is misbehaving. If it can be determined that a receiver is misbehaving, the only response is to exclude it from the RTP session and ensure that it no longer has any valid security context to affect the session.
接收者行为不当：接收者可能会报告自己不支持ECN，从而阻止在RTP会话中使用ECN，从而迫使发送者关闭ECN的使用。在点对点场景中，这样做的动机很小，因为这只会影响接收者，因此无法利用优化。对于多方会话，存在一些动机来解释为什么接收者会行为不当，因为这会阻止其他接收者使用ECN。作为会话的内部人员，很难确定接收者是否行为不端或根本没有能力，这使得在ECN的增量部署阶段，RTP使用基本上无法确定这一点。如果已知关于接收器和网络的附加信息，则可能推断接收器行为不正常。如果可以确定某个接收方行为不正常，则唯一的响应是将其从RTP会话中排除，并确保其不再具有任何影响会话的有效安全上下文。
Misbehaving senders: The enabling of ECN gives the media packets a higher degree of probability to reach the receiver compared to not-ECT-marked ones on an ECN-capable path. However, this is no magic bullet, and failure to react to congestion will most likely only slightly delay a network buffer over-run, in which its session also will experience packet loss and increased delay. There is some possibility that the media sender's traffic will push other traffic out of the way without being affected too negatively. However, we do note that a media sender still needs to implement congestion control functions to prevent the media from being badly affected by congestion events. Thus, the misbehaving sender is getting an unfair share. This can only be detected and potentially prevented by network monitoring and administrative entities. See Section 7 of [RFC3168] for more discussion of this issue.
行为不端的发送方：启用ECN使媒体数据包到达接收方的概率高于ECN路径上未标记ECT的数据包。然而，这并不是什么灵丹妙药，对拥塞做出反应的失败很可能只会使网络缓冲区在运行过程中略微延迟，在这种情况下，其会话也会经历数据包丢失和延迟增加。媒体发送者的流量可能会将其他流量推到一边，而不会受到太大的负面影响。然而，我们注意到媒体发送者仍然需要实现拥塞控制功能，以防止媒体受到拥塞事件的严重影响。因此，行为不端的发送者得到了不公平的份额。这只能由网络监视和管理实体检测并可能防止。有关此问题的更多讨论，请参见[RFC3168]第7节。
We note that the endpoint security functions needed to prevent an external attacker from interfering with the signalling are source authentication and integrity protection. To prevent information leakage from the feedback packets, encryption of the RTCP is also needed. For RTP, multiple possible solutions exist depending on the application context. Secure RTP (SRTP) [RFC3711] does satisfy the requirement to protect this mechanism. Note, however, that when using SRTP in group communication scenarios, different parties might
我们注意到，防止外部攻击者干扰信令所需的端点安全功能是源身份验证和完整性保护。为了防止反馈数据包的信息泄漏，还需要对RTCP进行加密。对于RTP，根据应用程序上下文，存在多种可能的解决方案。安全RTP（SRTP）[RFC3711]确实满足保护此机制的要求。但是，请注意，在组通信场景中使用SRTP时，不同的方可能会
share the same security context; in this case, the authentication mechanism only shows that one of those parties is involved, not necessarily which one. IPsec [RFC4301] and DTLS [RFC6347] can also provide the necessary security functions.
共享相同的安全上下文；在这种情况下，身份验证机制仅显示涉及其中一方，而不一定涉及哪一方。IPsec[RFC4301]和DTLS[RFC6347]也可以提供必要的安全功能。
The signalling protocols used to initiate an RTP session also need to be source authenticated and integrity protected to prevent an external attacker from modifying any signalling. An appropriate mechanism to protect the used signalling needs to be used. For SIP/ SDP, ideally Secure MIME (S/MIME) [RFC5751] would be used. However, with the limited deployment, a minimal mitigation strategy is to require use of SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop-by-hop protection.
用于启动RTP会话的信令协议还需要进行源身份验证和完整性保护，以防止外部攻击者修改任何信令。需要使用适当的机制来保护所使用的信令。对于SIP/SDP，最好使用安全的MIME（S/MIME）[RFC5751]。然而，在部署有限的情况下，最低限度的缓解策略是要求使用SIP（SIP over TLS）[RFC3261][RFC5630]至少实现逐跳保护。
We do note that certain mitigation methods will require network functions.
我们注意到，某些缓解方法需要网络功能。
This section contains a few different examples of the signalling mechanism defined in this specification in an SDP context. If there are discrepancies between these examples and the specification text, the specification text is definitive.
本节包含本规范在SDP上下文中定义的信令机制的几个不同示例。如果这些示例与规范文本之间存在差异，则规范文本是确定的。
This example is a basic offer/answer SDP exchange, assumed done by SIP (not shown). The intention is to establish a basic audio session point-to-point between two users.
此示例是一个基本的提供/应答SDP交换，假定由SIP完成（未显示）。目的是在两个用户之间建立一个基本的点对点音频会话。
The Offer:
报价：
v=0
o=jdoe 3502844782 3502844782 IN IP4 10.0.1.4
s=VoIP call
i=SDP offer for VoIP call with ICE and ECN for RTP
b=AS:128
b=RR:2000
b=RS:2500
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
a=ice-options:rtp+ecn
t=0 0
m=audio 45664 RTP/AVPF 97 98 99
c=IN IP4 192.0.2.3
a=rtpmap:97 G719/48000/1
a=fmtp:97 maxred=160
a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 PCMA/8000/1
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: ice rtp ect=0 mode=setread
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum
a=rtcp-rsize
a=candidate:1 1 UDP 2130706431 10.0.1.4 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.4 rport 8998
v=0
o=jdoe 3502844782 3502844782 IN IP4 10.0.1.4
s=VoIP call
i=SDP offer for VoIP call with ICE and ECN for RTP
b=AS:128
b=RR:2000
b=RS:2500
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
a=ice-options:rtp+ecn
t=0 0
m=audio 45664 RTP/AVPF 97 98 99
c=IN IP4 192.0.2.3
a=rtpmap:97 G719/48000/1
a=fmtp:97 maxred=160
a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 PCMA/8000/1
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: ice rtp ect=0 mode=setread
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum
a=rtcp-rsize
a=candidate:1 1 UDP 2130706431 10.0.1.4 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.4 rport 8998
This SDP offer presents a single media stream with 3 media payload types. It proposes to use ECN with RTP, with the ICE-based initialisation being preferred over the RTP/RTCP one. Leap of faith is not suggested to be used. The offerer is capable of both setting and reading the ECN bits. In addition, the use of both the RTCP ECN feedback packet and the RTCP XR ECN Summary Report are supported. ICE is also proposed with two candidates. It also supports reduced-size RTCP and can use it.
此SDP产品提供具有3种媒体负载类型的单一媒体流。它建议将ECN与RTP结合使用，基于ICE的初始化优先于RTP/RTCP初始化。不建议使用信仰的飞跃。提供方能够设置和读取ECN位。此外，还支持使用RTCP ECN反馈数据包和RTCP XR ECN摘要报告。ICE也被提议与两名候选人合作。它还支持缩小的RTCP并可以使用它。
The Answer:
答案是：
v=0
o=jdoe 3502844783 3502844783 IN IP4 198.51.100.235
s=VoIP call
i=SDP offer for VoIP call with ICE and ECN for RTP
b=AS:128
b=RR:2000
b=RS:2500
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
a=ice-options:rtp+ecn
t=0 0
m=audio 53879 RTP/AVPF 97 99
c=IN IP4 198.51.100.235
a=rtpmap:97 G719/48000/1
a=fmtp:97 maxred=160
a=rtpmap:99 PCMA/8000/1
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: ice ect=0 mode=readonly
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum
a=candidate:1 1 UDP 2130706431 198.51.100.235 53879 typ host
v=0
o=jdoe 3502844783 3502844783 IN IP4 198.51.100.235
s=VoIP call
i=SDP offer for VoIP call with ICE and ECN for RTP
b=AS:128
b=RR:2000
b=RS:2500
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
a=ice-options:rtp+ecn
t=0 0
m=audio 53879 RTP/AVPF 97 99
c=IN IP4 198.51.100.235
a=rtpmap:97 G719/48000/1
a=fmtp:97 maxred=160
a=rtpmap:99 PCMA/8000/1
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: ice ect=0 mode=readonly
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum
a=candidate:1 1 UDP 2130706431 198.51.100.235 53879 typ host
The answer confirms that only one media stream will be used. One RTP payload type was removed. ECN capability was confirmed, and the initialisation method will be ICE. However, the answerer is only capable of reading the ECN bits, which means that ECN can only be used for RTP flowing from the offerer to the answerer. ECT always set to 0 will be used in both directions. Both the RTCP ECN feedback packet and the RTCP XR ECN Summary Report will be used. Reduced-size RTCP will not be used as the answerer has not indicated support for it in the answer.
回答确认将只使用一个媒体流。删除了一种RTP有效负载类型。ECN能力已确认，初始化方法为ICE。然而，应答方只能读取ECN位，这意味着ECN只能用于从报价方到应答方的RTP流。ECT始终设置为0将在两个方向上使用。将同时使用RTCP ECN反馈数据包和RTCP XR ECN摘要报告。由于回答者在回答中未表示支持，因此不会使用缩小尺寸的RTCP。
The session below describes an Any-Source Multicast using a session with a single media stream.
下面的会话描述了使用具有单个媒体流的会话的任意源多播。
v=0
o=jdoe 3502844782 3502844782 IN IP4 198.51.100.235
s=Multicast SDP session using ECN for RTP
i=Multicasted audio chat using ECN for RTP
b=AS:128
t=3502892703 3502910700
m=audio 56144 RTP/AVPF 97
c=IN IP4 233.252.0.212/127
a=rtpmap:97 g719/48000/1
a=fmtp:97 maxred=160
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: rtp mode=readonly; ect=0
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1500
a=rtcp-xr:ecn-sum
v=0
o=jdoe 3502844782 3502844782 IN IP4 198.51.100.235
s=Multicast SDP session using ECN for RTP
i=Multicasted audio chat using ECN for RTP
b=AS:128
t=3502892703 3502910700
m=audio 56144 RTP/AVPF 97
c=IN IP4 233.252.0.212/127
a=rtpmap:97 g719/48000/1
a=fmtp:97 maxred=160
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: rtp mode=readonly; ect=0
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1500
a=rtcp-xr:ecn-sum
This is a declarative SDP example and indicates required functionality in the consumer of the SDP. The initialisation method required is the RTP/RTCP-based one, indicated by the "a=ecn-capable-rtp: rtp ..." line. Receivers are required to be able to read ECN marks ("mode=readonly"), and the ECT value is recommended to be set to 0 always ("ect=0"). The ECN usage in this session requires both ECN feedback and RTCP XR ECN Summary Reports, and their use is indicated through the "a=rtcp-fb:" and "a=rtcp-xr:ecn-sum" lines.
这是一个声明性SDP示例，指示SDP使用者中所需的功能。所需的初始化方法是基于RTP/RTCP的方法，由“a=ecn-capable RTP:RTP…”行表示。要求接收器能够读取ECN标记（“模式=只读”），建议将ECT值始终设置为0（“ECT=0”）。此会话中的ECN使用需要ECN反馈和RTCP XR ECN摘要报告，它们的使用通过“a=RTCP fb:”和“a=RTCP XR:ECN sum”行指示。
The authors wish to thank the following individuals for their reviews and comments: Thomas Belling, Bob Briscoe, Roni Even, Kevin P. Flemming, Tomas Frankkila, Christian Groves, Christer Holmgren, Cullen Jennings, Tom Van Caenegem, Simo Veikkolainen, Bill Ver Steeg, Dan Wing, Qin Wu, and Lei Zhu.
作者希望感谢以下个人的评论和评论：托马斯·贝林、鲍勃·布里斯科、罗尼·埃文、凯文·P·弗莱明、托马斯·弗兰基拉、克里斯蒂安·格罗夫斯、克里斯特·霍姆格伦、卡伦·詹宁斯、汤姆·范·凯恩格姆、西莫·维科莱宁、比尔·弗斯泰格、丹·荣、秦武和朱磊。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[RFC5348]Floyd，S.，Handley，M.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 5348，2008年9月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for Interactive Connectivity Establishment (ICE) Options", RFC 6336, July 2011.
[RFC6336]Westerlund，M.和C.Perkins，“交互式连接建立（ICE）选项的IANA注册”，RFC 63362011年7月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2762] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group Membership in RTP", RFC 2762, February 2000.
[RFC2762]Rosenberg，J.和H.Schulzrinne，“RTP中群体成员的抽样”，RFC 2762，2000年2月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]Spring，N.，Weterral，D.，和D.Ely，“带有nonce的鲁棒显式拥塞通知（ECN）信令”，RFC 35402003年6月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]Bhattacharyya，S.，“源特定多播（SSM）概述”，RFC 3569，2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4585] 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.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，2006年7月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 51172008年1月。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5124]Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 51242008年2月。
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009.
[RFC5506]Johansson，I.和M.Westerlund，“支持缩小尺寸实时传输控制协议（RTCP）：机会和后果”，RFC 5506，2009年4月。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5630]Audet，F.“会话启动协议（SIP）中SIPS URI方案的使用”，RFC 5630，2009年10月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5760]Ott，J.，Chesterfield，J.，和E.Schooler，“具有单播反馈的单源多播会话的RTP控制协议（RTCP）扩展”，RFC 57602010年2月。
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, April 2011.
[RFC6189]Zimmermann，P.，Johnston，A.，和J.Callas，“ZRTP：单播安全RTP的媒体路径密钥协议”，RFC 6189，2011年4月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
Authors' Addresses
作者地址
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 EMail: magnus.westerlund@ericsson.com
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista瑞典电话：+46 10 714 82 87电子邮件：Magnus。westerlund@ericsson.com
Ingemar Johansson Ericsson Laboratoriegrand 11 SE-971 28 Lulea Sweden Phone: +46 73 0783289 EMail: ingemar.s.johansson@ericsson.com
英格玛·约翰逊·爱立信实验室和11 SE-971 28 Lulea瑞典电话：+46 73 0783289电子邮件：Ingemar.s。johansson@ericsson.com
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom EMail: csp@csperkins.org
柯林帕金斯格拉斯哥大学计算科学学院格拉斯哥G128QQ英国电子邮件：csp@csperkins.org
Piers O'Hanlon University of Oxford Oxford Internet Institute 1 St Giles Oxford OX1 3JS United Kingdom EMail: piers.ohanlon@oii.ox.ac.uk
彼得奥汉伦牛津大学牛津互联网研究所1 ST吉尔斯牛津OX1 3JS英国电子邮件：桥墩。ohanlon@oii.ox.ac.uk
Ken Carlberg G11 1600 Clarendon Blvd Arlington, VA USA EMail: carlberg@g11.org.uk
Ken Carlberg G11 1600美国弗吉尼亚州阿灵顿克莱伦登大道电子邮件：carlberg@g11.org.uk