Internet Engineering Task Force (IETF) B. Ver Steeg
Request for Comments: 6285 A. Begen
Category: Standards Track Cisco
ISSN: 2070-1721 T. Van Caenegem
Alcatel-Lucent
Z. Vax
Magnum Semiconductor
June 2011
Internet Engineering Task Force (IETF) B. Ver Steeg
Request for Comments: 6285 A. Begen
Category: Standards Track Cisco
ISSN: 2070-1721 T. Van Caenegem
Alcatel-Lucent
Z. Vax
Magnum Semiconductor
June 2011
Unicast-Based Rapid Acquisition of Multicast RTP Sessions
基于单播的多播RTP会话快速获取
Abstract
摘要
When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts.
当RTP接收器加入多播会话时，它可能需要获取并解析某些参考信息，然后才能处理在多播会话中发送的任何数据。根据连接时间、参考信息重复（或出现）间隔的长度、参考信息的大小以及应用程序和传输属性，RTP接收器可以有效地使用多播数据之前的时间延迟（我们称之为采集延迟）会发生变化并且可能很大。对于经常在不同多播会话（例如视频广播）之间切换的接收器来说，这是一种不希望出现的现象。
In this document, we describe a method using the existing RTP and RTP Control Protocol (RTCP) machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem.
在本文档中，我们描述了一种使用现有RTP和RTP控制协议（RTCP）机制的方法，以减少采集延迟。在该方法中，在多播流之前或伴随多播流，辅助单播RTP会话携带参考信息到接收器。这种单播RTP流可以以比自然比特率更快的速率传输，以进一步加速捕获。此功能的激励性用例是承载实时压缩音频和视频的多播应用程序。然而，这种方法也可以用于其他类型的多播应用中，在这些应用中，捕获延迟足够长而成为一个问题。
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/rfc6285.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6285.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 6
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Elements of Delay in Multicast Applications . . . . . . . . . 8
5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 10
6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Synchronization of Primary Multicast Streams . . . . . . . 24
6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 25
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 6
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Elements of Delay in Multicast Applications . . . . . . . . . 8
5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 10
6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Synchronization of Primary Multicast Streams . . . . . . . 24
6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 25
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 34
7.3.1. Response Code Definitions . . . . . . . . . . . . . . 37
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 39
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 41
8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 41
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 44
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 48
11.2. Registration of SDP Attribute Values . . . . . . . . . . . 48
11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 48
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 48
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 49
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 50
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Normative References . . . . . . . . . . . . . . . . . . . 52
14.2. Informative References . . . . . . . . . . . . . . . . . . 54
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 34
7.3.1. Response Code Definitions . . . . . . . . . . . . . . 37
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 39
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 41
8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 41
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 44
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 48
11.2. Registration of SDP Attribute Values . . . . . . . . . . . 48
11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 48
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 48
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 49
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 50
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Normative References . . . . . . . . . . . . . . . . . . . 52
14.2. Informative References . . . . . . . . . . . . . . . . . . 54
Most multicast flows carry a stream of inter-related data. Receivers need to acquire certain information to start processing any data sent in the multicast session. This document refers to this information as Reference Information. The Reference Information is conventionally sent periodically in the multicast session (although its content can change over time) and usually consists of items such as a description of the schema for the rest of the data, references to which data to process, encryption information including keys, and any other information required to process the data in the multicast stream [IC2009].
大多数多播流携带相互关联的数据流。接收者需要获取某些信息才能开始处理在多播会话中发送的任何数据。本文件将此信息称为参考信息。参考信息通常在多播会话中周期性地发送（尽管其内容可以随时间而改变），并且通常包括诸如剩余数据的模式描述、要处理的数据所指向的参考、包括密钥的加密信息等项，以及处理多播流中的数据所需的任何其他信息[IC2009]。
Real-time multicast applications require receivers to buffer data. Receivers may have to buffer data to smooth out the network jitter, to allow loss-repair methods such as Forward Error Correction and retransmission to recover the missing packets, and to satisfy the data-processing requirements of the application layer.
实时多播应用需要接收器缓冲数据。接收机可能必须缓冲数据以平滑网络抖动，允许诸如前向纠错和重传之类的丢失修复方法来恢复丢失的分组，并满足应用层的数据处理要求。
When a receiver joins a multicast session, it has no control over what point in the flow is currently being transmitted. Sometimes the receiver might join the session right before the Reference
当接收器加入多播会话时，它无法控制流中当前正在传输的点。有时，接收方可能会在引用之前加入会话
Information is sent in the session. In this case, the required waiting time is usually minimal. Other times, the receiver might join the session right after the Reference Information has been transmitted. In this case, the receiver has to wait for the Reference Information to appear again in the flow before it can start processing any multicast data. In some other cases, the Reference Information is not contiguous in the flow but dispersed over a large period, which forces the receiver to wait for the whole Reference Information to arrive before starting to process the rest of the data.
信息在会话中发送。在这种情况下，所需的等待时间通常很短。其他时候，接收机可能在参考信息被发送之后立即加入会话。在这种情况下，接收器必须等待参考信息再次出现在流中，然后才能开始处理任何多播数据。在一些其他情况下，参考信息在流中不是连续的，而是分散在一个较长的时间段上，这迫使接收器在开始处理其余数据之前等待整个参考信息到达。
The net effect of waiting for the Reference Information and waiting for various buffers to fill up is that receivers can experience significantly large delays in data processing. In this document, we refer to the difference between the time an RTP receiver wants to join the multicast session and the time the RTP receiver acquires all the necessary Reference Information as the Acquisition Delay. The acquisition delay might not be the same for different receivers; it usually varies depending on the join time, length of the Reference Information repetition (or appearance) interval, and size of the Reference Information, as well as the application and transport properties.
等待参考信息和等待各种缓冲区填满的净效果是，接收器在数据处理中可能会经历显著的大延迟。在本文档中，我们将RTP接收器想要加入多播会话的时间与RTP接收器获取所有必要参考信息的时间之间的差异作为获取延迟。不同接收机的捕获延迟可能不同；它通常根据连接时间、引用信息重复（或出现）间隔的长度、引用信息的大小以及应用程序和传输属性而变化。
The varying nature of the acquisition delay adversely affects the receivers that frequently switch among multicast sessions. While this problem equally applies to both any-source multicast (ASM) and source-specific multicast (SSM) applications, in this specification we address it for the SSM-based applications by describing a method that uses the fundamental tools offered by the existing RTP and RTCP protocols [RFC3550]. In this method, either the multicast source (or the distribution source in an SSM session) retains the Reference Information for a period after its transmission, or an intermediary network element (that we refer to as Retransmission Server) joins the multicast session and continuously caches the Reference Information as it is sent in the session and acts as a feedback target (see [RFC5760]) for the session. When an RTP receiver wishes to join the same multicast session, instead of simply issuing a Source Filtering Group Management Protocol (SFGMP) Join message, it sends a request to the feedback target for the session and asks for the Reference Information. The retransmission server starts a new unicast RTP (retransmission) session and sends the Reference Information to the RTP receiver over that session. If there is residual bandwidth, the retransmission server might burst the Reference Information faster than its natural rate. As soon as the receiver acquires the Reference Information, it can join the multicast session and start processing the multicast data. A simplified network diagram showing this method through an intermediary network element is depicted in Figure 1.
捕获延迟的变化性质对频繁在多播会话之间切换的接收器产生不利影响。虽然该问题同样适用于任何源多播（ASM）和源特定多播（SSM）应用程序，但在本规范中，我们通过描述一种使用现有RTP和RTCP协议提供的基本工具的方法[RFC3550]来解决基于SSM的应用程序的问题。在该方法中，多播源（或SSM会话中的分发源）或中间网元（我们称之为重传服务器）在传输后的一段时间内保留参考信息加入多播会话，并在会话中发送参考信息时连续缓存参考信息，并充当会话的反馈目标（请参见[RFC5760]）。当RTP接收器希望加入相同的多播会话时，它不只是发出源过滤组管理协议（SFGMP）加入消息，而是向会话的反馈目标发送请求并请求参考信息。重传服务器启动新的单播RTP（重传）会话，并通过该会话将参考信息发送给RTP接收器。如果存在剩余带宽，则重传服务器可能会以高于其自然速率的速度突发参考信息。一旦接收器获得参考信息，它就可以加入多播会话并开始处理多播数据。图1中描述了通过中间网络元素显示此方法的简化网络图。
This method potentially reduces the acquisition delay. We refer to this method as Unicast-Based Rapid Acquisition of Multicast RTP Sessions. A primary use case for this method is to reduce the channel-change times in IPTV networks where compressed video streams are multicast in different SSM sessions and viewers randomly join these sessions.
该方法潜在地减少了捕获延迟。我们将这种方法称为基于单播的多播RTP会话的快速获取。该方法的主要用例是减少IPTV网络中的信道改变时间，其中压缩视频流在不同SSM会话中进行多播，并且观众随机加入这些会话。
-----------------------
+--->| Intermediary |
| | Network Element |
| ...|(Retransmission Server)|
| : -----------------------
| :
| v
----------- ---------- ----------
| Multicast | | |---------->| Joining |
| Source |------->| Router |..........>| RTP |
| | | | | Receiver |
----------- ---------- ----------
|
| ----------
+---------------->| Existing |
| RTP |
| Receiver |
----------
-----------------------
+--->| Intermediary |
| | Network Element |
| ...|(Retransmission Server)|
| : -----------------------
| :
| v
----------- ---------- ----------
| Multicast | | |---------->| Joining |
| Source |------->| Router |..........>| RTP |
| | | | | Receiver |
----------- ---------- ----------
|
| ----------
+---------------->| Existing |
| RTP |
| Receiver |
----------
-------> Multicast RTP Flow
.......> Unicast RTP Flow
-------> Multicast RTP Flow
.......> Unicast RTP Flow
Figure 1: Rapid Acquisition through an Intermediary Network Element
图1：通过中间网元快速获取
A principle design goal in this solution is to use the existing tools in the RTP/RTCP protocol family. This improves the versatility of the existing implementations and promotes faster deployment and better interoperability. To this effect, we use the unicast retransmission support of RTP [RFC4588] and the capabilities of RTCP to handle the signaling needed to accomplish the acquisition.
此解决方案的一个主要设计目标是使用RTP/RTCP协议系列中的现有工具。这提高了现有实现的多功能性，并促进了更快的部署和更好的互操作性。为此，我们使用RTP[RFC4588]的单播重传支持和RTCP的能力来处理完成捕获所需的信令。
A reasonable effort has been made in this specification to design a solution that reliably works in both engineered and best-effort networks. However, a proper congestion control combined with the desired behavior of this solution is difficult to achieve. Rather, this solution has been designed based on the assumption that the retransmission server and the RTP receivers have some knowledge about where the bottleneck between them is. This assumption does not generally hold unless both the retransmission server and the RTP receivers are in the same edge network. Thus, this solution should
本规范中已做出合理努力，以设计一种在工程网络和尽力而为网络中可靠工作的解决方案。然而，结合此解决方案的期望行为的适当拥塞控制是难以实现的。相反，此解决方案是基于重传服务器和RTP接收器对它们之间的瓶颈位置有一定了解的假设而设计的。除非重传服务器和RTP接收器都位于同一边缘网络中，否则此假设通常不成立。因此，这一解决方案应该
not be used across any best-effort path of the Internet. Furthermore, this solution should only be used in networks that are already carrying non-congestion-responsive multicast traffic and have throttling mechanisms in the retransmission servers to ensure the (unicast) burst traffic is a known constant upper-bound multiplier on the multicast load.
不得在互联网的任何尽力而为的路径上使用。此外，此解决方案应仅用于已承载非拥塞响应多播流量且在重传服务器中具有节流机制的网络，以确保（单播）突发流量是多播负载上的已知恒定上限乘数。
In this memo, we describe a protocol that handles the rapid acquisition of a single multicast RTP session (called a primary multicast RTP session) carrying one or more RTP streams (called primary multicast streams). If desired, multiple instances of this protocol may be run in parallel to acquire multiple RTP sessions simultaneously.
在本备忘录中，我们描述了一种协议，该协议处理单个多播RTP会话（称为主多播RTP会话）的快速获取，该会话承载一个或多个RTP流（称为主多播流）。如果需要，可并行运行该协议的多个实例以同时获取多个RTP会话。
When an RTP receiver requests the Reference Information from the retransmission server, it can opt to rapidly acquire a specific subset of the available RTP streams in the primary multicast RTP session. Alternatively, the RTP receiver can request the rapid acquisition of all of the RTP streams in that RTP session. Regardless of how many RTP streams are requested by the RTP receiver or how many will be actually sent by the retransmission server, only one unicast RTP session will be established by the retransmission server. This unicast RTP session is separate from the associated primary multicast RTP session. As a result, there are always two different RTP sessions in a single instance of the rapid acquisition protocol: (i) the primary multicast RTP session with its associated unicast feedback and (ii) the unicast RTP session.
当RTP接收器从重传服务器请求参考信息时，它可以选择在主多播RTP会话中快速获取可用RTP流的特定子集。或者，RTP接收器可以请求快速获取该RTP会话中的所有RTP流。无论RTP接收器请求了多少个RTP流，或者重发服务器实际发送了多少个RTP流，重发服务器将只建立一个单播RTP会话。此单播RTP会话独立于关联的主多播RTP会话。因此，在快速捕获协议的单个实例中始终存在两个不同的RTP会话：（i）主多播RTP会话及其相关的单播反馈和（ii）单播RTP会话。
If the RTP receiver wants to rapidly acquire multiple RTP sessions simultaneously, separate unicast RTP sessions will be established for each of them.
如果RTP接收器希望同时快速获取多个RTP会话，则将为每个RTP会话建立单独的单播RTP会话。
The rest of this specification is as follows. Section 3 provides a list of the definitions frequently used in this document. In Section 4, we describe the delay components in generic multicast applications. Section 5 presents an overview of the protocol design considerations for rapid acquisition. We provide the protocol details of the rapid acquisition method in Sections 6 and 7. Sections 8 and 9 discuss the Session Description Protocol (SDP) signaling issues with examples and NAT-related issues, respectively. Finally, Section 10 discusses the security considerations, and Section 11 details the IANA considerations.
本规范的其余部分如下所示。第3节列出了本文件中常用的定义。在第4节中，我们描述了通用多播应用程序中的延迟组件。第5节概述了快速采集的协议设计注意事项。我们在第6节和第7节中提供了快速采集方法的协议细节。第8节和第9节分别以示例和NAT相关问题讨论会话描述协议（SDP）信令问题。最后，第10节讨论了安全注意事项，第11节详细介绍了IANA注意事项。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses the following acronyms and definitions frequently:
本文件经常使用以下首字母缩略词和定义：
(Primary) SSM Session: The multicast session to which RTP receivers can join at a random point in time. A primary SSM session can carry multiple RTP streams.
（主要）SSM会话：RTP接收器可以在随机时间点加入的多播会话。主SSM会话可以承载多个RTP流。
Primary Multicast RTP Session: The multicast RTP session an RTP receiver is interested in acquiring rapidly. From the RTP receiver's viewpoint, the primary multicast RTP session has one associated unicast RTCP feedback stream to a Feedback Target, in addition to the primary multicast RTP stream(s).
主多播RTP会话：RTP接收方感兴趣快速获取的多播RTP会话。从RTP接收器的观点来看，除了主多播RTP流之外，主多播RTP会话还具有到反馈目标的一个相关联的单播RTCP反馈流。
Primary Multicast (RTP) Streams: The RTP stream(s) carried in the primary multicast RTP session.
主多播（RTP）流：主多播RTP会话中承载的RTP流。
Source Filtering Group Management Protocol (SFGMP): Following the definition in [RFC4604], SFGMP refers to the Internet Group Management Protocol (IGMP) version 3 [RFC3376] and the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and IPv6 networks, respectively. However, the rapid acquisition method introduced in this document does not depend on a specific version of either of these group management protocols. In the remainder of this document, SFGMP will refer to any group management protocol that has Join and Leave functionalities.
源筛选组管理协议（SFGMP）：根据[RFC4604]中的定义，SFGMP分别指IPv4和IPv6网络中的Internet组管理协议（IGMP）版本3[RFC3376]和多播侦听器发现协议（MLD）版本2[RFC3810]。但是，本文件中介绍的快速采集方法不依赖于这些组管理协议的特定版本。在本文件的其余部分中，SFGMP将提及任何具有加入和离开功能的集团管理协议。
Feedback Target (FT): Unicast RTCP feedback target as defined in [RFC5760]. FT_Ap denotes a specific feedback target running on a particular address and port.
反馈目标（FT）：[RFC5760]中定义的单播RTCP反馈目标。FT_Ap表示在特定地址和端口上运行的特定反馈目标。
Retransmission (or Burst) Packet: An RTP packet that is formatted as defined in Section 4 of [RFC4588]. The payload of a retransmission or burst packet comprises the retransmission payload header followed by the payload of the original RTP packet.
重传（或突发）数据包：按照[RFC4588]第4节的规定格式化的RTP数据包。重传或突发分组的有效载荷包括重传有效载荷报头，后跟原始RTP分组的有效载荷。
Reference Information: The set of certain media content and metadata information that is sufficient for an RTP receiver to start usefully consuming a media stream. The meaning, format, and size of this information are specific to the application and are out of the scope of this document.
参考信息：某些媒体内容和元数据信息的集合，足以使RTP接收器开始有效地使用媒体流。此信息的含义、格式和大小特定于应用程序，不在本文档的范围内。
Preamble Information: A more compact form of the whole or a subset of the Reference Information transmitted out-of-band.
前导信息：在带外传输的全部或部分参考信息的更紧凑形式。
(Unicast) Burst (or Retransmission) RTP Session: The unicast RTP session used to send one or more unicast burst RTP streams and their associated RTCP messages. The terms "burst RTP session" and "retransmission RTP session" can be used interchangeably.
（单播）突发（或重传）RTP会话：用于发送一个或多个单播突发RTP流及其相关RTCP消息的单播RTP会话。术语“突发RTP会话”和“重传RTP会话”可以互换使用。
(Unicast) Burst (Stream): A unicast stream of RTP retransmission packets that enable an RTP receiver to rapidly acquire the Reference Information associated with a primary multicast stream. Each burst stream is identified by its Synchronization Source (SSRC) identifier that is unique in the primary multicast RTP session. Following the session-multiplexing guidelines in [RFC4588], each unicast burst stream will use the same SSRC and Canonical Name (CNAME) as its primary multicast RTP stream.
（单播）突发（流）：RTP重传分组的单播流，使RTP接收器能够快速获取与主多播流相关联的参考信息。每个突发流由其同步源（SSRC）标识符标识，该标识符在主多播RTP会话中是唯一的。按照[RFC4588]中的会话多路复用准则，每个单播突发流将使用与其主多播RTP流相同的SSRC和规范名称（CNAME）。
Retransmission Server (RS): The RTP/RTCP endpoint that can generate the retransmission packets and the burst streams. The RS may also generate other non-retransmission packets to aid rapid acquisition.
重传服务器（RS）：可以生成重传数据包和突发流的RTP/RTCP端点。RS还可以生成其他非重传分组以帮助快速捕获。
In a source-specific multicast (SSM) delivery system, there are three major elements that contribute to the acquisition delay when an RTP receiver switches from one multicast session to another one. These are:
在源特定多播（SSM）传输系统中，当RTP接收器从一个多播会话切换到另一个多播会话时，有三个主要因素会导致捕获延迟。这些是：
o Multicast-switching delay
o 多播交换延迟
o Reference Information latency
o 参考信息延迟
o Buffering delays
o 缓冲延迟
Multicast-switching delay is the delay that is experienced when leaving the current multicast session (if any) and joining the new multicast session. In typical systems, the multicast join and leave operations are handled by a group management protocol. For example, the receivers and routers participating in a multicast session can use the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810]. In either of these protocols, when a receiver wants to join a multicast session, it sends a message to its upstream router and the routing infrastructure sets up the multicast forwarding state to deliver the packets of the multicast session to the new receiver. The join times vary depending on the proximity of the upstream router, the current state of the multicast tree, the load on the system, and the protocol implementation. Current systems provide
多播切换延迟是指离开当前多播会话（如果有）并加入新多播会话时所经历的延迟。在典型系统中，多播加入和离开操作由组管理协议处理。例如，参与多播会话的接收器和路由器可以使用因特网组管理协议（IGMP）版本3[RFC3376]或多播侦听器发现协议（MLD）版本2[RFC3810]。在这两种协议中，当接收器想要加入多播会话时，它向其上游路由器发送消息，路由基础设施设置多播转发状态以将多播会话的数据包传递给新的接收器。连接时间取决于上游路由器的接近程度、多播树的当前状态、系统上的负载以及协议实现。现有系统提供
join latencies, usually less than 200 milliseconds (ms). If the receiver had been participating in another multicast session before joining the new session, it needs to send a Leave message to its upstream router to leave the session. In common multicast routing protocols, the leave times are usually smaller than the join times; however, it is possible that the Leave and Join messages might get lost, in which case the multicast-switching delay inevitably increases.
连接延迟，通常小于200毫秒（ms）。如果接收器在加入新会话之前已经参与了另一个多播会话，那么它需要向其上游路由器发送一条离开消息以离开会话。在常见的组播路由协议中，离开时间通常小于加入时间；然而，离开和加入消息可能丢失，在这种情况下，多播切换延迟不可避免地增加。
Reference Information latency is the time it takes the receiver to acquire the Reference Information. It is highly dependent on the proximity of the actual time the receiver joined the session to the next time the Reference Information will be sent to the receivers in the session, whether or not the Reference Information is sent contiguously, and the size of the Reference Information. For some multicast flows, there is a little or no interdependency in the data, in which case the Reference Information latency will be nil or negligible. For other multicast flows, there is a high degree of interdependency. One example of interest is the multicast flows that carry compressed audio/video. For these flows, the Reference Information latency can become quite large and be a major contributor to the overall delay.
参考信息延迟是接收器获取参考信息所需的时间。它高度依赖于接收器加入会话的实际时间与将在会话中向接收器发送参考信息的下一次时间的接近程度、参考信息是否连续发送以及参考信息的大小。对于某些多播流，数据中存在少量或没有相互依赖性，在这种情况下，参考信息延迟将为零或可忽略不计。对于其他多播流，存在高度的相互依赖性。一个有趣的例子是承载压缩音频/视频的多播流。对于这些流，参考信息延迟可能变得相当大，并且是总体延迟的主要因素。
The buffering component of the overall acquisition delay is driven by the way the application layer processes the payload. In many multicast applications, an unreliable transport protocol such as UDP [RFC0768] is often used to transmit the data packets, and the reliability, if needed, is usually addressed through other means such as Forward Error Correction (e.g., [RFC6015]) and retransmission. These loss-repair methods require buffering at the receiver side to function properly. In many applications, it is also often necessary to de-jitter the incoming data packets before feeding them to the application. The de-jittering process also increases the buffering delays. Besides these network-related buffering delays, there are also specific buffering needs that are required by the individual applications. For example, standard video decoders typically require a certain amount, sometimes up to a few seconds, of coded video data to be available in the pre-decoding buffers prior to starting to decode the video bitstream.
总体采集延迟的缓冲组件由应用层处理有效负载的方式驱动。在许多多播应用中，诸如UDP[RFC0768]之类的不可靠传输协议通常用于传输数据分组，并且如果需要，通常通过诸如前向纠错（例如，[RFC6015]）和重传等其他手段来解决可靠性问题。这些损耗修复方法需要在接收器端进行缓冲以正常工作。在许多应用程序中，在将传入数据包馈送到应用程序之前，通常还需要消除其抖动。去抖动过程也会增加缓冲延迟。除了这些与网络相关的缓冲延迟外，个别应用程序还需要特定的缓冲需求。例如，标准视频解码器通常要求在开始解码视频比特流之前在预解码缓冲器中提供一定量（有时高达几秒钟）的编码视频数据。
5. Protocol Design Considerations and Their Effect on Resource Management for Rapid Acquisition
5. 协议设计考虑因素及其对快速采办资源管理的影响
This section is for informational purposes and does not contain requirements for implementations.
本节仅供参考，不包含实施要求。
Rapid acquisition is an optimization of a system that is expected to continue to work correctly and properly whether or not the optimization is effective or even fails due to lost control and feedback messages, congestion, or other problems. This is fundamental to the overall design requirements surrounding the protocol definition and to the resource management schemes to be employed together with the protocol (e.g., Quality of Service (QoS) machinery, server load management, etc). In particular, the system needs to operate within a number of constraints:
快速捕获是对系统的优化，无论优化是否有效，或由于失去控制和反馈消息、拥塞或其他问题而失败，系统都将继续正常工作。这对于围绕协议定义的总体设计要求以及与协议一起使用的资源管理方案（例如，服务质量（QoS）机制、服务器负载管理等）至关重要。特别是，系统需要在多个约束条件下运行：
o First, a rapid acquisition operation must fail gracefully. The user experience must not be significantly worse for trying and failing to complete rapid acquisition compared to simply joining the multicast session.
o 首先，快速采办操作必须以优雅的方式失败。与简单地加入多播会话相比，如果尝试并未能完成快速捕获，用户体验一定不会明显恶化。
o Second, providing the rapid acquisition optimizations must not cause collateral damage to either the multicast session being joined or other multicast sessions sharing resources with the rapid acquisition operation. In particular, the rapid acquisition operation must avoid interference with the multicast session that might be simultaneously being received by other hosts. In addition, it must also avoid interference with other multicast and non-multicast sessions sharing the same network resources. These properties are possible but are usually difficult to achieve.
o 其次，提供快速捕获优化不得对正在加入的多播会话或与快速捕获操作共享资源的其他多播会话造成附带损害。具体地说，快速获取操作必须避免干扰其他主机可能同时接收的多播会话。此外，它还必须避免与共享相同网络资源的其他多播和非多播会话的干扰。这些特性是可能的，但通常很难实现。
One challenge is the existence of multiple bandwidth bottlenecks between the receiver and the server(s) in the network providing the rapid acquisition service. In commercial IPTV deployments, for example, bottlenecks are often present in the aggregation network connecting the IPTV servers to the network edge, the access links (e.g., DSL, Data Over Cable Service Interface Specification (DOCSIS)), and the home network of the subscribers. Some of these links might serve only a single subscriber, limiting congestion impact to the traffic of only that subscriber, but others can be shared links carrying multicast sessions of many subscribers. Also note that the state of these links can vary over time. The receiver might have knowledge of a portion of this network or might have partial knowledge of the entire network. The methods employed by the devices to acquire this network state information is out of the scope of this document. The receiver should be able to signal the server with the bandwidth that it believes it can handle. The server also needs to be able to rate limit the flow in order to stay within the
一个挑战是在提供快速捕获服务的网络中，接收器和服务器之间存在多个带宽瓶颈。例如，在商业IPTV部署中，瓶颈通常存在于将IPTV服务器连接到网络边缘、接入链路（例如DSL、有线数据服务接口规范（DOCSIS））和用户的家庭网络的聚合网络中。其中一些链路可能只服务于单个订阅者，从而将拥塞影响仅限于该订阅者的通信量，但其他链路可以是承载多个订阅者的多播会话的共享链路。还请注意，这些链接的状态可能随时间而变化。接收机可能知道该网络的一部分，或者可能知道整个网络的一部分。设备用于获取该网络状态信息的方法不在本文件范围内。接收器应该能够用它认为可以处理的带宽向服务器发送信号。服务器还需要能够对流量进行速率限制，以保持在
performance envelope that it knows about. Both the server and receiver need to be able to inform the other of changes in the requested and delivered rates. However, the protocol must be robust in the presence of packet loss, so this signaling must include the appropriate default behaviors.
它知道的性能信封。服务器和接收方都需要能够将请求和交付速率的变化通知另一方。然而，该协议在存在分组丢失时必须是健壮的，因此该信令必须包括适当的默认行为。
A second challenge is that for some uses (e.g., high-bitrate video) the unicast burst bitrate is high while the flow duration of the unicast burst is short. This is because the purpose of the unicast burst is to allow the RTP receiver to join the multicast quickly and thereby limit the overall resources consumed by the burst. Such high-bitrate, short-duration flows are not amenable to conventional admission-control techniques. For example, end-to-end per-flow signaled admission-control techniques such as Resource Reservation Protocol (RSVP) have too much latency and control channel overhead to be a good fit for rapid acquisition. Similarly, using a TCP (or TCP-like) approach with a 3-way handshake and slow-start to avoid inducing congestion would defeat the purpose of attempting rapid acquisition in the first place by introducing many round-trip times (RTTs) of delay.
第二个挑战是，对于某些用途（例如，高比特率视频），单播突发比特率高，而单播突发的流持续时间短。这是因为单播突发的目的是允许RTP接收器快速加入多播，从而限制突发所消耗的总体资源。这种高比特率、短持续时间的流不适合于传统的接纳控制技术。例如，诸如资源预留协议（RSVP）之类的端到端每流信号接入控制技术具有太多的延迟和控制信道开销，不适合快速捕获。类似地，使用TCP（或类似TCP）方法，通过3路握手和慢速启动来避免引起拥塞，首先会引入大量的往返时间（RTT）延迟，从而破坏快速捕获的目的。
These observations lead to certain unavoidable requirements and goals for a rapid acquisition protocol. These are:
这些观察结果导致了快速采集协议的某些不可避免的要求和目标。这些是：
o The protocol must be designed to allow a deterministic upper bound on the extra bandwidth used (compared to just joining the multicast session). A reasonable size bound is e*B, where B is the nominal bandwidth of the primary multicast streams and e is an excess-bandwidth coefficient. The total duration of the unicast burst must have a reasonable bound; long unicast bursts devolve to the bandwidth profile of multi-unicast for the whole system.
o 协议必须设计为允许使用额外带宽的确定上限（与仅加入多播会话相比）。合理的大小界限是e*B，其中B是主多播流的标称带宽，e是超额带宽系数。单播突发的总持续时间必须有一个合理的界限；对于整个系统来说，长的单播突发将退化为多个单播的带宽分布。
o The scheme should minimize (or better eliminate) the overlap of the unicast burst and the primary multicast stream. This minimizes the window during which congestion could be induced on a bottleneck link compared to just carrying the multicast or unicast packets alone.
o 该方案应最小化（或更好地消除）单播突发和主多播流的重叠。与仅承载多播或单播数据包相比，这最大限度地减少了瓶颈链路上可能导致拥塞的窗口。
o The scheme must minimize (or better eliminate) any gap between the unicast burst and the primary multicast stream, which has to be repaired later or, in the absence of repair, will result in loss being experienced by the application.
o 该方案必须最小化（或更好地消除）单播突发和主多播流之间的任何间隙，该间隙必须在以后修复，或者在没有修复的情况下，将导致应用程序经历丢失。
In addition to the above, there are some other protocol design issues to be considered. First, there is at least one RTT of "slop" in the control loop. In starting a rapid acquisition burst, this manifests as the time between the client requesting the unicast burst and the burst description and/or the first unicast burst packets arriving at
除上述内容外，还需要考虑其他一些协议设计问题。首先，控制回路中至少有一个“slop”RTT。在启动快速捕获突发时，这表现为请求单播突发的客户端与突发描述和/或到达的第一个单播突发数据包之间的时间
the receiver. For managing and terminating the unicast burst, there are two possible approaches for the control loop. First, the receiver can adapt to the unicast burst as received, converge based on observation, and explicitly terminate the unicast burst with a second control loop exchange (which takes a minimum of one RTT, just as starting the unicast burst does). Alternatively, the server generating the unicast burst can precompute the burst parameters based on the information in the initial request and tell the receiver the burst duration.
接受者。对于管理和终止单播突发，控制循环有两种可能的方法。首先，接收机可以在接收时适应单播突发，基于观察收敛，并使用第二个控制环路交换明确终止单播突发（这需要至少一个RTT，就像启动单播突发一样）。或者，生成单播突发的服务器可以基于初始请求中的信息预计算突发参数，并告诉接收机突发持续时间。
The protocol described in the next section allows either method of controlling the rapid acquisition unicast burst.
下一节中描述的协议允许控制快速捕获单播突发的任一方法。
We start this section with an overview of the Rapid Acquisition of Multicast RTP Sessions (RAMS) method.
本节首先概述了快速获取多播RTP会话（RAMS）的方法。
[RFC5760] specifies an extension to the RTP Control Protocol (RTCP) to use unicast feedback in an SSM session. It defines an architecture that introduces the concept of Distribution Source, which, in an SSM context, distributes the RTP data and redistributes RTCP information to all RTP receivers. This RTCP information is retrieved from the Feedback Target, to which RTCP unicast feedback traffic is sent. One or more entities different from the Distribution Source MAY implement the feedback target functionality, and different RTP receivers MAY use different feedback targets.
[RFC5760]指定RTP控制协议（RTCP）的扩展，以在SSM会话中使用单播反馈。它定义了一个引入分布式源概念的体系结构，在SSM上下文中，分布式源将RTP数据分发并将RTCP信息重新分发给所有RTP接收器。此RTCP信息从反馈目标检索，RTCP单播反馈流量发送到该目标。与分发源不同的一个或多个实体可以实现反馈目标功能，并且不同的RTP接收机可以使用不同的反馈目标。
This document builds further on these concepts to reduce the acquisition delay when an RTP receiver joins a multicast session at a random point in time by introducing the concept of the Burst Source and new RTCP feedback messages. The Burst Source has a cache where the most recent packets from the primary multicast RTP session are continuously stored. When an RTP receiver wants to receive a primary multicast stream, it can first request a unicast burst from the Burst Source before it joins the SSM session. In this burst, the packets are formatted as RTP retransmission packets [RFC4588] and carry Reference Information. This information allows the RTP receiver to start usefully consuming the RTP packets sent in the primary multicast RTP session.
本文档进一步基于这些概念，通过引入突发源和新RTCP反馈消息的概念，减少RTP接收器在随机时间点加入多播会话时的捕获延迟。突发源具有高速缓存，其中连续存储来自主多播RTP会话的最新数据包。当RTP接收器想要接收主多播流时，它可以在加入SSM会话之前首先从突发源请求单播突发。在该突发中，分组被格式化为RTP重传分组[RFC4588]，并携带参考信息。此信息允许RTP接收器开始有效地使用在主多播RTP会话中发送的RTP数据包。
Using an accelerated bitrate (as compared to the nominal bitrate of the primary multicast stream) for the unicast burst implies that at a certain point in time, the payload transmitted in the unicast burst is going to be the same as the payload in the associated multicast stream, i.e., the unicast burst will catch up with the primary
对单播突发使用加速比特率（与主多播流的标称比特率相比）意味着在某个时间点，在单播突发中传输的有效载荷将与相关多播流中的有效载荷相同，即，单播突发将赶上主多播流
multicast stream. At this point, the RTP receiver no longer needs to receive the unicast burst and can join the SSM session. This method is referred to as the Rapid Acquisition of Multicast RTP Sessions (RAMS).
多播流。此时，RTP接收器不再需要接收单播突发，并且可以加入SSM会话。这种方法被称为快速获取多播RTP会话（RAMS）。
This document defines extensions to [RFC4585] for an RTP receiver to request a unicast burst as well as for additional control messaging that can be leveraged during the acquisition process.
本文档定义了对[RFC4585]的扩展，用于RTP接收器请求单播突发以及在采集过程中可利用的附加控制消息。
As shown in Figure 2, the main entities involved in rapid acquisition and the message flows are:
如图2所示，参与快速采集的主要实体和消息流如下：
o Multicast Source
o 多播源
o Feedback Target (FT)
o 反馈目标（FT）
o Burst/Retransmission Source (BRS)
o 突发/重传源（BRS）
o RTP Receiver (RTP_Rx)
o RTP接收器（RTP_Rx）
----------- --------------
| |------------------------------------>| |
| |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| |
| | | |
| Multicast | ---------------- | |
| Source | | Retransmission | | |
| |-------->| Server (RS) | | |
| |.-.-.-.->| | | |
| | | ------------ | | |
----------- | | Feedback | |<.=.=.=.=.| |
| | Target (FT)| |<~~~~~~~~~| RTP Receiver |
PRIMARY MULTICAST | ------------ | | (RTP_Rx) |
RTP SESSION with | | | |
UNICAST FEEDBACK | | | |
| | | |
- - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- -
| | | |
UNICAST BURST | ------------ | | |
(or RETRANSMISSION) | | Burst/ | |<~~~~~~~~>| |
RTP SESSION | | Retrans. | |.........>| |
| |Source (BRS)| |<.=.=.=.=>| |
| ------------ | | |
| | | |
---------------- --------------
----------- --------------
| |------------------------------------>| |
| |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| |
| | | |
| Multicast | ---------------- | |
| Source | | Retransmission | | |
| |-------->| Server (RS) | | |
| |.-.-.-.->| | | |
| | | ------------ | | |
----------- | | Feedback | |<.=.=.=.=.| |
| | Target (FT)| |<~~~~~~~~~| RTP Receiver |
PRIMARY MULTICAST | ------------ | | (RTP_Rx) |
RTP SESSION with | | | |
UNICAST FEEDBACK | | | |
| | | |
- - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- -
| | | |
UNICAST BURST | ------------ | | |
(or RETRANSMISSION) | | Burst/ | |<~~~~~~~~>| |
RTP SESSION | | Retrans. | |.........>| |
| |Source (BRS)| |<.=.=.=.=>| |
| ------------ | | |
| | | |
---------------- --------------
-------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Flow
-------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Flow
Figure 2: Flow Diagram for Unicast-Based Rapid Acquisition
图2：基于单播的快速捕获流程图
As defined in [RFC5760], the feedback target (FT) is the entity to which the RTP_Rx sends its RTCP feedback messages indicating packet loss by means of an RTCP NACK message or indicating RTP_Rx's desire to rapidly acquire the primary multicast RTP session by means of an RTCP feedback message defined in this document. While the Burst/ Retransmission Source (BRS) is responsible for responding to these messages and for further RTCP interaction with the RTP_Rx in the case of a rapid acquisition process, it is assumed in the remainder of this document that these two logical entities (FT and BRS) are combined in a single physical entity and they share state. In the remainder of the text, the term Retransmission Server (RS) is used whenever appropriate, to refer to this single physical entity.
如[RFC5760]中所定义，反馈目标（FT）是RTP_Rx向其发送RTCP反馈消息的实体，该消息通过RTCP NACK消息指示分组丢失，或通过本文件中定义的RTCP反馈消息指示RTP_Rx希望快速获取主多播RTP会话。虽然突发/重传源（BRS）负责响应这些消息，并在快速采集过程中负责RTCP与RTP_Rx的进一步交互，但在本文件的其余部分中，假设这两个逻辑实体（FT和BRS）组合在一个物理实体中，并且它们共享状态。在本文的其余部分中，术语重传服务器（RS）在适当的情况下用于指代该单一物理实体。
The FT is involved in the primary multicast RTP session and receives unicast feedback for that session as in [RFC5760]. The BRS is involved in the unicast burst (or retransmission) RTP session and transmits the unicast burst and retransmission packets formatted as RTP retransmission packets [RFC4588] in a single separate unicast RTP session to each RTP_Rx. In the unicast burst RTP session, as in any other RTP session, the BRS and RTP_Rx regularly send the periodic sender and receiver reports, respectively.
FT参与主多播RTP会话，并接收该会话的单播反馈，如[RFC5760]所示。BRS参与单播突发（或重传）RTP会话，并在单个单独的单播RTP会话中将格式化为RTP重传分组[RFC4588]的单播突发和重传分组发送到每个RTP_Rx。在单播突发RTP会话中，如同在任何其他RTP会话中一样，BRS和RTP_Rx分别定期发送周期性发送方和接收方报告。
The unicast burst is started by an RTCP feedback message that is defined in this document based on the common packet format provided in [RFC4585]. An RTP retransmission is triggered by an RTCP NACK message defined in [RFC4585]. Both of these messages are sent to the FT of the primary multicast RTP session and can start the unicast burst/retransmission RTP session.
单播突发由RTCP反馈消息启动，该消息根据[RFC4585]中提供的通用数据包格式在本文件中定义。RTP重传由[RFC4585]中定义的RTCP NACK消息触发。这两条消息都被发送到主多播RTP会话的FT，并且可以启动单播突发/重传RTP会话。
In the extended RTP profile for RTCP-based feedback (RTP/Audio-Visual Profile with Feedback (AVPF)), there are certain rules that apply to scheduling of both of these messages sent to the FT in the primary multicast RTP session; these are detailed in Section 3.5 of [RFC4585]. One of the rules states that in a multi-party session such as the SSM sessions we are considering in this specification, an RTP_Rx cannot send an RTCP feedback message for a minimum of one second after joining the session (i.e., Tmin=1.0 second). While this rule has the goal of avoiding problems associated with flash crowds in typical multi-party sessions, it defeats the purpose of rapid acquisition. Furthermore, when RTP receivers delay their messages requesting a burst by a deterministic or even a random amount, it still does not make a difference since such messages are not related and their timings are independent from each other. Thus, in this specification, we initialize Tmin to zero and allow the RTP receivers to send a burst request message right at the beginning. For the subsequent messages (e.g., updated requests) during rapid acquisition, the timing rules of [RFC4585] still apply.
在基于RTCP的反馈的扩展RTP配置文件（RTP/带反馈的视听配置文件（AVPF））中，存在适用于在主多播RTP会话中发送到FT的这两条消息的调度的某些规则；这些在[RFC4585]的第3.5节中有详细说明。其中一条规则规定，在多方会话（如我们在本规范中考虑的SSM会话）中，RTP_Rx在加入会话后至少1秒内（即Tmin=1.0秒）无法发送RTCP反馈消息。虽然这条规则的目标是避免在典型的多方会议中出现与闪电人群相关的问题，但它无法实现快速获取的目的。此外，当RTP接收器将其请求突发的消息延迟确定性或甚至随机量时，这仍然没有区别，因为此类消息不相关且它们的定时彼此独立。因此，在本规范中，我们将Tmin初始化为零，并允许RTP接收器在一开始就发送突发请求消息。对于快速采集期间的后续消息（例如更新的请求），[RFC4585]的定时规则仍然适用。
Figure 3 depicts an example of messaging flow for rapid acquisition. The RTCP feedback messages are explained below. The optional messages are indicated in parentheses, and they might or might not be present during rapid acquisition. In a scenario where rapid acquisition is performed by a feedback target co-located with the media sender, the same method (with the identical message flows) still applies.
图3描述了用于快速获取的消息传递流的示例。RTCP反馈信息解释如下。可选消息用括号表示，它们可能在快速采集期间出现，也可能不出现。在由与媒体发送者位于同一位置的反馈目标执行快速捕获的场景中，相同的方法（具有相同的消息流）仍然适用。
-------------------------
| Retransmission Server |
----------- | ------ ------------ | -------- ------------
| Multicast | | | FT | | Burst/Ret. | | | | | RTP |
| Source | | | | | Source | | | Router | | Receiver |
| | | ------ ------------ | | | | (RTP_Rx) |
----------- | | | | -------- ------------
| ------------------------- | |
| | | | |
|-- RTP Multicast ---------->--------------->| |
|-. RTCP Multicast -.-.-.-.->-.-.-.-.-.-.-.->| |
| | | | |
| | |********************************|
| | |* PORT MAPPING SETUP *|
| | |********************************|
| | | | |
| |<~~~~~~~~~~~~~~~~~~~~~~~~~ RTCP RAMS-R ~~~|
| | | | |
| | |********************************|
| | |* UNICAST SESSION ESTABLISHED *|
| | |********************************|
| | | | |
| | |~~~ RTCP RAMS-I ~~~~~~~~~~~~~~~>|
| | | | |
| | |... Unicast RTP Burst .........>|
| | | | |
| |<~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP RAMS-R) ~~|
| | | | |
| | |~~ (RTCP RAMS-I) ~~~~~~~~~~~~~~>|
| | | | |
| | | | |
| | | |<= SFGMP Join ==|
| | | | |
|-- RTP Multicast ------------------------------------------->|
|-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>|
| | | | |
| | | | |
| | |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~|
| | | | |
: : : : :
| | |<.=.= Unicast RTCP Reports .=.=>|
: : : for the unicast session :
| | | | |
-------------------------
| Retransmission Server |
----------- | ------ ------------ | -------- ------------
| Multicast | | | FT | | Burst/Ret. | | | | | RTP |
| Source | | | | | Source | | | Router | | Receiver |
| | | ------ ------------ | | | | (RTP_Rx) |
----------- | | | | -------- ------------
| ------------------------- | |
| | | | |
|-- RTP Multicast ---------->--------------->| |
|-. RTCP Multicast -.-.-.-.->-.-.-.-.-.-.-.->| |
| | | | |
| | |********************************|
| | |* PORT MAPPING SETUP *|
| | |********************************|
| | | | |
| |<~~~~~~~~~~~~~~~~~~~~~~~~~ RTCP RAMS-R ~~~|
| | | | |
| | |********************************|
| | |* UNICAST SESSION ESTABLISHED *|
| | |********************************|
| | | | |
| | |~~~ RTCP RAMS-I ~~~~~~~~~~~~~~~>|
| | | | |
| | |... Unicast RTP Burst .........>|
| | | | |
| |<~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP RAMS-R) ~~|
| | | | |
| | |~~ (RTCP RAMS-I) ~~~~~~~~~~~~~~>|
| | | | |
| | | | |
| | | |<= SFGMP Join ==|
| | | | |
|-- RTP Multicast ------------------------------------------->|
|-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>|
| | | | |
| | | | |
| | |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~|
| | | | |
: : : : :
| | |<.=.= Unicast RTCP Reports .=.=>|
: : : for the unicast session :
| | | | |
-------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages
=======> SFGMP Messages
.......> Unicast RTP Flow
-------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages
=======> SFGMP Messages
.......> Unicast RTP Flow
Figure 3: Message Flows for Unicast-Based Rapid Acquisition
图3：基于单播的快速捕获的消息流
This document defines the expected behaviors of the RS and RTP_Rx. It is instructive to consider independently operating implementations on the RS and RTP_Rx that request the burst, describe the burst, start the burst, join the multicast session, and stop the burst. These implementations send messages to each other, but provisions are needed for the cases where the control messages get lost, or reordered, or are not being delivered to their destinations.
本文件定义了RS和RTP_Rx的预期行为。在RS和RTPYRX上独立地请求实现突发，描述突发，启动突发，加入多播会话，并停止突发，这是有启发性的。这些实现相互发送消息，但在控制消息丢失、重新排序或未传递到目的地的情况下，需要作出规定。
The following steps describe rapid acquisition in detail:
以下步骤详细描述了快速采集：
1. Port Mapping Setup: For the primary multicast RTP session, the RTP and RTCP destination ports are declaratively specified (refer to Section 8 for examples in SDP). However, the RTP_Rx needs to choose its RTP and RTCP receive ports for the unicast burst RTP session. Since this unicast session is established after the RTP_Rx has sent a RAMS Request (RAMS-R) message as unicast feedback in the primary multicast RTP session, the RTP_Rx MUST first set up the port mappings between the unicast and multicast sessions and send this mapping information to the FT along with the RAMS-R message so that the BRS knows how to communicate with the RTP_Rx.
1. 端口映射设置：对于主多播RTP会话，RTP和RTCP目标端口以声明方式指定（SDP中的示例请参阅第8节）。但是，RTP_Rx需要为单播突发RTP会话选择其RTP和RTCP接收端口。由于该单播会话是在RTP_Rx在主多播RTP会话中发送RAMS请求（RAMS-R）消息作为单播反馈后建立的，RTP_Rx必须首先设置单播和多播会话之间的端口映射，并将该映射信息与RAMS-R消息一起发送给FT，以便BRS知道如何与RTP_Rx通信。
The details of this setup procedure are explained in [RFC6284]. Other NAT-related issues are left to Section 9 to keep the present discussion focused on the RAMS message flows.
[RFC6284]中解释了此设置过程的详细信息。其他与NAT相关的问题留待第9节讨论，以使目前的讨论集中在RAMS消息流上。
2. Request: The RTP_Rx sends a rapid acquisition request (RAMS-R) for the primary multicast RTP session to the unicast feedback target of that session. The request contains the SSRC identifier of the RTP_Rx (aka SSRC of packet sender) and can contain the media sender SSRC identifier(s) of the primary multicast stream(s) of interest (aka SSRC of media source). The RAMS-R message can contain parameters that constrain the burst, such as the buffer and bandwidth limits.
2. 请求：RTP_Rx向该会话的单播反馈目标发送主多播RTP会话的快速捕获请求（RAMS-R）。该请求包含RTP_Rx的SSRC标识符（也称为数据包发送方的SSRC），并且可以包含感兴趣的主多播流（也称为媒体源的SSRC）的媒体发送方SSRC标识符。RAMS-R消息可以包含约束突发的参数，例如缓冲区和带宽限制。
Before joining the SSM session, the RTP_Rx learns the addresses for the multicast source, group, and RS by out-of-band means. If the RTP_Rx desires to rapidly acquire only a subset of the primary multicast streams available in the primary multicast RTP
在加入SSM会话之前，RTP_Rx通过带外方式学习多播源、组和RS的地址。如果RTP_Rx希望仅快速获取主多播RTP中可用的主多播流的子集
session, the RTP_Rx MUST also acquire the SSRC identifiers for the desired RTP streams out-of-band. Based on this information, the RTP_Rx populates the desired SSRC(s) in the RAMS-R message.
在会话中，RTP_Rx还必须获取带外所需RTP流的SSRC标识符。基于此信息，RTP_Rx在RAMS-R消息中填充所需的SSRC。
When the FT successfully receives the RAMS-R message, the BRS responds to it by accepting or rejecting the request. Immediately before the BRS sends any RTP or RTCP packet(s) described below, it establishes the unicast burst RTP session.
当FT成功接收到RAMS-R消息时，BRS通过接受或拒绝请求来响应该消息。BRS在发送下文所述的任何RTP或RTCP数据包之前，立即建立单播突发RTP会话。
3. Response: The BRS sends RAMS Information (RAMS-I) message(s) to the RTP_Rx to convey the status for the burst(s) requested by the RTP_Rx.
3. 响应：BRS向RTP_Rx发送RAMS信息（RAMS-I）消息，以传达RTP_Rx请求的突发状态。
If the primary multicast RTP session associated with the FT_Ap (a specific feedback target running on a particular address and port) on which the RAMS-R message was received contains only a single primary multicast stream, the BRS SHALL always use the SSRC of the RTP stream associated with the FT_Ap in the RAMS-I message(s) regardless of the media sender SSRC requested in the RAMS-R message. In such cases the 'ssrc' attribute MAY be omitted from the media description. If the requested SSRC and the actual media sender SSRC do not match, the BRS MUST explicitly populate the correct media sender SSRC in the initial RAMS-I message (see Section 7.3).
如果与接收RAMS-R消息的FT_Ap（在特定地址和端口上运行的特定反馈目标）相关联的主多播RTP会话仅包含单个主多播流，则BRS应始终在RAMS-I消息中使用与FT_Ap相关联的RTP流的SSRC无论RAMS-R消息中请求的媒体发送方SSRC是什么。在这种情况下，“ssrc”属性可以从媒体描述中省略。如果请求的SSRC和实际的媒体发送方SSRC不匹配，BRS必须在初始RAMS-I消息中明确填写正确的媒体发送方SSRC（见第7.3节）。
The FT_Ap could also be associated with an RTP session that carries two or more primary multicast streams. If the RTP_Rx wants to issue a collective request to receive the whole primary multicast RTP session, it does not need the 'ssrc' attributes to be described in the media description.
FT_Ap还可以与承载两个或多个主多播流的RTP会话相关联。如果RTP_Rx想要发出集体请求以接收整个主多播RTP会话，则不需要在媒体描述中描述“ssrc”属性。
If the FT_Ap is associated with two or more RTP sessions, RTP_Rx's request will be ambiguous. To avoid any ambiguity, each FT_Ap MUST be only associated with a single RTP session.
如果FT_Ap与两个或多个RTP会话关联，RTP_Rx的请求将不明确。为避免任何歧义，每个FT_Ap必须仅与单个RTP会话关联。
If the RTP_Rx is willing to rapidly acquire only a subset of the primary multicast streams, the RTP_Rx MUST list all the media sender SSRC(s) denoting the stream(s) it wishes to acquire in the RAMS-R message. Upon receiving such a message, the BRS MAY accept the request for all or a subset of the media sender SSRC(s) that match the RTP stream(s) it serves. The BRS MUST reject all other requests with an appropriate response code.
如果RTP_Rx愿意仅快速获取主多播流的子集，则RTP_Rx必须在RAMS-R消息中列出表示其希望获取的流的所有媒体发送方SSRC。在接收到这样的消息时，BRS可以接受对与它所服务的RTP流匹配的媒体发送方SSRC的全部或子集的请求。BRS必须使用适当的响应代码拒绝所有其他请求。
* Reject Responses: The BRS MUST take into account any limitations that may have been specified by the RTP_Rx in the RAMS-R message when making a decision regarding the request. If the RTP_Rx has requested to acquire the whole primary multicast RTP session but the BRS cannot provide a rapid
* 拒绝响应：BRS必须考虑RTP_Rx在RAMS-R消息中指定的任何限制，以决定请求。如果RTP_Rx已请求获取整个主多播RTP会话，但BRS无法提供快速响应
acquisition service for any of the primary multicast streams, the BRS MUST reject the request via a single RAMS-I message with a collective reject response code, which is defined as 510 in Section 11.6 and whose media sender SSRC field is set to one of SSRCs served by this FT_Ap. Upon receiving this RAMS-I message, the RTP_Rx abandons the rapid acquisition attempt and can immediately join the multicast session by sending an SFGMP Join message towards its upstream multicast router.
获取服务对于任何主多播流，BRS必须通过单个RAMS-I消息拒绝请求，该消息带有集体拒绝响应代码，该代码在第11.6节中定义为510，其媒体发送方SSRC字段设置为该FT_Ap服务的SSRC之一。收到此RAMS-I消息后，RTP_Rx放弃快速捕获尝试，并可通过向其上游多播路由器发送SFGMP join消息立即加入多播会话。
In all other cases, the BRS MUST send a separate RAMS-I message with the appropriate 5xx-level response code (as defined in Section 11.6) for each primary multicast stream that has been requested by the RTP_Rx but cannot be served by the BRS. There could be multiple reasons why the BRS has rejected the request; however, the BRS chooses the most appropriate response code to inform the RTP_Rx.
在所有其他情况下，对于RTP_Rx请求但BRS无法服务的每个主多播流，BRS必须发送一条单独的RAMS-I消息，其中包含相应的5xx级响应代码（如第11.6节所定义）。BRS拒绝该请求可能有多种原因；但是，BRS选择最合适的响应代码通知RTP_Rx。
Upon receiving a reject response indicating a transient problem such as insufficient BRS or network resources, if the RTP_Rx wants to retry sending the same request, the RTP_Rx MUST follow the RTCP timer rules of [RFC4585] to allow the transient problems to go away. However, if the reject response indicates a non-transient problem (such as the ones reported by response codes 504, 505, and 506), the RTP_Rx MUST NOT attempt a retry. Different response codes have different scopes. Refer to Section 7.3.1 for details.
在接收到表示暂时性问题（如BRS或网络资源不足）的拒绝响应后，如果RTP_Rx想要重试发送相同的请求，RTP_Rx必须遵循[RFC4585]的RTCP定时器规则，以允许暂时性问题消失。然而，如果拒绝响应指示非瞬态问题（例如响应代码504、505和506报告的问题），则RTP_Rx不得尝试重试。不同的响应代码具有不同的作用域。详见第7.3.1节。
The BRS can employ a policing mechanism against the broken RTP_Rx implementations that are not following these rules. See Section 10 for details.
BRS可以针对不遵守这些规则的中断RTP_Rx实现采用一种监管机制。详见第10节。
* Accept Responses: The BRS MUST send at least one separate RAMS-I message with the appropriate response code (either zero indicating a private response or response code 200 indicating success as listed in Section 11.6) for each primary multicast stream that has been requested by the RTP_Rx and will be served by the BRS. Such RAMS-I messages comprise fields that can be used to describe the individual unicast burst streams. When there is a RAMS-R request for multiple primary multicast streams, the BRS MUST include all the individual RAMS-I messages corresponding to that RAMS-R request in the same compound RTCP packet if these messages fit in the same packet. Note that if the BRS is sending only the preamble information but not the whole unicast burst stream, it will not accept the request but will send a response code 511 instead, as defined in Section 11.6.
* 接受响应：对于RTP_Rx请求并将由BRS服务的每个主多播流，BRS必须至少发送一条单独的RAMS-I消息，该消息带有适当的响应代码（零表示私有响应，或响应代码200表示第11.6节中列出的成功）。此类RAMS-I消息包括可用于描述单个单播突发流的字段。当存在针对多个主多播流的RAMS-R请求时，BRS必须将与该RAMS-R请求相对应的所有单个RAMS-I消息包含在同一复合RTCP数据包中（如果这些消息适合于同一数据包）。注意，如果BRS仅发送前导信息而不发送整个单播突发流，则它将不接受请求，而是发送响应码511，如第11.6节中所定义。
The RAMS-I message carries the RTP sequence number of the first packet transmitted in the respective RTP stream to allow the RTP_Rx to detect any missing initial packet(s). When the BRS accepts a request for a primary multicast stream, this field MUST always be populated in the RAMS-I message(s) sent for this particular primary multicast stream. It is RECOMMENDED that the BRS sends a RAMS-I message at the start of the burst so that the RTP_Rx can quickly detect any missing initial packet(s).
RAMS-I消息携带在相应RTP流中传输的第一分组的RTP序列号，以允许RTP_Rx检测任何丢失的初始分组。当BRS接受主多播流的请求时，必须始终在为此特定主多播流发送的RAMS-I消息中填充此字段。建议BRS在突发开始时发送RAMS-I消息，以便RTP_Rx能够快速检测任何丢失的初始数据包。
It is possible that the RAMS-I message for a primary multicast stream can get delayed or lost, and the RTP_Rx can start receiving RTP packets before receiving a RAMS-I message. An RTP_Rx implementation MUST NOT assume it will quickly receive the initial RAMS-I message. For redundancy purposes, it is RECOMMENDED that the BRS repeats the RAMS-I messages multiple times as long as it follows the RTCP timer rules defined in [RFC4585].
主多播流的RAMS-I消息可能会延迟或丢失，并且RTP_Rx可以在接收RAMS-I消息之前开始接收RTP分组。RTP_Rx实施不得假设其将快速接收初始RAMS-I消息。出于冗余目的，建议BRS重复RAMS-I消息多次，只要遵循[RFC4585]中定义的RTCP定时器规则。
4. Unicast Burst: For the primary multicast stream(s) for which the request is accepted, the BRS starts sending the unicast burst(s) that comprises one or more RTP retransmission packets sent in the unicast burst RTP session. In some applications, the BRS can send preamble information data to the RTP_Rx in addition to the requested burst to prime the media decoder(s). However, for the BRS to send the preamble information in a particular format, explicit signaling from the RTP_Rx is required. In other words, the BRS MUST NOT send preamble information in a particular format unless the RTP_Rx has signaled support for that format in the RAMS-R message through a public or private extension as defined in Section 7.1.
4. 单播突发：对于接受请求的主多播流，BRS开始发送单播突发，该单播突发包含在单播突发RTP会话中发送的一个或多个RTP重传数据包。在一些应用中，BRS除了请求的突发之外，还可以向RTP_Rx发送前导信息数据，以对媒体解码器进行初始化。然而，对于BRS以特定格式发送前导信息，需要来自RTP_Rx的显式信令。换句话说，除非RTP_Rx已通过第7.1节中定义的公共或私有扩展在RAMS-R消息中表示支持该格式，否则BRS不得以特定格式发送前导信息。
The format of this preamble data is RTP-payload specific and not specified here.
此前导数据的格式是RTP有效负载特定的，此处未指定。
5. Updated Request: The RTP_Rx MAY send an updated RAMS-R message (as unicast feedback in the primary multicast RTP session) with a different value for one or more fields of an earlier RAMS-R message. The BRS MUST be able to detect whether a burst is already planned for or being transmitted to this particular RTP_Rx for this particular media sender SSRC. If there is an existing burst planned for or being transmitted, the newly arriving RAMS-R is an updated request; otherwise, it is a new request. It is also possible that the RTP_Rx has sent an improperly formatted RAMS-R message or used an invalid value in the RAMS-R message. If notified by the BRS using a 4xx-level
5. 更新的请求：RTP_Rx可发送更新的RAMS-R消息（作为主多播RTP会话中的单播反馈），该消息的值与先前RAMS-R消息的一个或多个字段的值不同。BRS必须能够检测该特定媒体发送器SSRC是否已经计划或正在向该特定RTP_Rx发送突发。如果存在计划或正在传输的现有突发，则新到达的RAMS-R是更新的请求；否则，这是一个新的请求。RTP_Rx也可能发送了格式不正确的RAMS-R消息或在RAMS-R消息中使用了无效值。如果BRS使用4xx级别通知
response code (as defined in Section 11.6) and only after following the timing rules of [RFC4585], the RTP_Rx MAY resend its corrected request.
响应代码（如第11.6节所定义），并且只有在遵循[RFC4585]的定时规则后，RTP_Rx才可以重新发送其更正的请求。
The BRS determines the identity of the requesting RTP_Rx by looking at its canonical name identifier (CNAME item in the source description (SDES)). Thus, the RTP_Rx MUST choose a method that ensures it uses a unique CNAME identifier. Such methods are provided in [RFC6222]. In addition to one or more fields with updated values, an updated RAMS-R message may also include the fields whose values did not change.
BRS通过查看其规范名称标识符（源描述（SDES）中的CNAME项）来确定请求RTP_Rx的身份。因此，RTP_Rx必须选择一种确保其使用唯一CNAME标识符的方法。[RFC6222]中提供了此类方法。除了具有更新值的一个或多个字段外，更新的RAMS-R消息还可能包括其值未更改的字段。
Upon receiving an updated request, the BRS can use the updated values for sending/shaping the burst or refine the values and use the refined values for sending/shaping the burst. Subsequently, the BRS MAY send an updated RAMS-I message in the unicast burst RTP session to indicate the changes it made.
在接收到更新的请求时，BRS可以使用更新的值来发送/成形突发或细化值并使用细化的值来发送/成形突发。随后，BRS可在单播突发RTP会话中发送更新的RAMS-I消息以指示其所做的更改。
It is an implementation-dependent decision for an RTP_RX whether and when to send an updated request. However, note that the updated request messages can get delayed and arrive at the BRS after the initial unicast burst was completed. In this case, the updated request message can trigger a new unicast burst, and by then if the RTP_Rx has already started receiving multicast data, a congestion is likely to occur. In this case, the RTP_Rx can detect this only after a delay, and then it can try to terminate the new burst. However, in the meantime, the RTP_Rx can experience packet loss or other problems. This and other similar corner cases SHOULD be carefully examined if updated requests are to be used.
RTP_RX是否以及何时发送更新的请求取决于实现。但是，请注意，更新的请求消息可能会延迟，并在初始单播突发完成后到达BRS。在这种情况下，更新的请求消息可以触发新的单播突发，并且到那时，如果RTP_Rx已经开始接收多播数据，则可能发生拥塞。在这种情况下，RTP_Rx只能在延迟后检测到这一点，然后它可以尝试终止新的突发。然而，与此同时，RTP_Rx可能会遇到分组丢失或其他问题。如果要使用更新的请求，则应仔细检查此情况和其他类似情况。
6. Updated Response: The BRS can send more than one RAMS-I message in the unicast burst RTP session, e.g., to update the value of one or more fields in an earlier RAMS-I message. The updated RAMS-I messages might or might not be a direct response to a RAMS-R message. The BRS can also send updated RAMS-I messages to signal the RTP_Rx in real time to join the SSM session when the BRS had already sent an initial RAMS-I message, e.g., at the start of the burst. The RTP_Rx depends on the BRS to learn the join time, which can be conveyed by the first RAMS-I message or can be sent/revised in a later RAMS-I message. If the BRS is not capable of determining the join time in the initial RAMS-I message, the BRS MUST send another RAMS-I message (with the join time information) later.
6. 更新的响应：BRS可以在单播突发RTP会话中发送多个RAMS-I消息，例如，更新先前RAMS-I消息中一个或多个字段的值。更新的RAMS-I消息可能是也可能不是对RAMS-R消息的直接响应。当BRS已经发送初始RAMS-I消息时，例如在突发开始时，BRS还可以发送更新的RAMS-I消息以实时向RTP_Rx发送信号，以加入SSM会话。RTP_Rx取决于BRS学习连接时间，连接时间可以通过第一条RAMS-I消息传送，也可以在以后的RAMS-I消息中发送/修改。如果BRS无法确定初始RAMS-I消息中的连接时间，BRS必须稍后发送另一条RAMS-I消息（带有连接时间信息）。
7. Multicast Join Signaling: The RAMS-I message allows the BRS to signal explicitly when the RTP_Rx needs to send the SFGMP Join message. The RTP_Rx SHOULD use this information from the most
7. 多播加入信令：RAMS-I消息允许BRS在RTP_Rx需要发送SFGMP加入消息时明确发出信号。RTP_Rx应使用来自most的此信息
recent RAMS-I message unless it has more accurate information. If the request is accepted, this information MUST be conveyed in at least one RAMS-I message, and its value MAY be updated by subsequent RAMS-I messages.
最近的RAMS-I消息，除非它有更准确的信息。如果请求被接受，则必须在至少一条RAMS-I消息中传达该信息，其值可通过后续RAMS-I消息更新。
There can be missing packets if the RTP_Rx joins the multicast session too early or too late. For example, if the RTP_Rx starts receiving the primary multicast stream while it is still receiving the unicast burst at a high excess bitrate, this can result in an increased risk of packet loss. Or, if the RTP_Rx joins the multicast session some time after the unicast burst is finished, there can be a gap between the burst and multicast data (a number of RTP packets might be missing). In both cases, the RTP_Rx can issue retransmission requests (via RTCP NACK messages sent as unicast feedback in the primary multicast RTP session) [RFC4585] to the FT entity of the RS to fill the gap. The BRS might or might not respond to such requests. When it responds and the response causes significant changes in one or more values reported earlier to the RTP_Rx, an updated RAMS-I SHOULD be sent to the RTP_Rx.
如果RTP_Rx加入多播会话太早或太迟，则可能会丢失数据包。例如，如果RTP_Rx开始接收主多播流，而它仍然以高的超额比特率接收单播突发，这可能导致分组丢失的风险增加。或者，如果RTP_Rx在单播突发结束后的某个时间加入多播会话，则突发数据和多播数据之间可能存在间隙（可能丢失许多RTP分组）。在这两种情况下，RTP_Rx可以（通过在主多播RTP会话中作为单播反馈发送的RTCP NACK消息）[RFC4585]向RS的FT实体发出重传请求以填补该间隙。BRS可能会也可能不会响应此类请求。当其响应且响应导致先前报告给RTP_Rx的一个或多个值发生重大变化时，应向RTP_Rx发送更新的RAMS-I。
8. Multicast Receive: After the join, the RTP_Rx starts receiving the primary multicast stream(s).
8. 多播接收：加入后，RTP_Rx开始接收主多播流。
9. Terminate: The BRS can know when it needs to ultimately stop the unicast burst based on its parameters. However, the RTP_Rx may need to ask the BRS to terminate the burst prematurely or at a specific sequence number. For this purpose, the RTP_Rx uses the RAMS Termination (RAMS-T) message sent as RTCP feedback in the unicast burst RTP session. A separate RAMS-T message is sent for each primary multicast stream served by the BRS unless an RTCP BYE message has been sent in the unicast burst RTP session as described in Step 10. For the burst requests that were rejected by the BRS, there is no need to send a RAMS-T message.
9. 终止：BRS可以根据其参数知道何时需要最终停止单播突发。然而，RTP_Rx可能需要请求BRS提前终止突发或以特定序列号终止突发。为此，RTP_Rx使用在单播突发RTP会话中作为RTCP反馈发送的RAMS终止（RAMS-T）消息。除非已在单播突发RTP会话中发送RTCP BYE消息（如步骤10所述），否则将为BRS服务的每个主多播流发送单独的RAMS-T消息。对于被BRS拒绝的突发请求，无需发送RAMS-T消息。
If the RTP_Rx wants to terminate a burst prematurely, it MUST send a RAMS-T message for the SSRC of the primary multicast stream it wishes to terminate. This message is sent in the unicast burst RTP session. Upon receiving this message, the BRS MUST terminate the unicast burst. If the RTP_Rx requested to acquire the entire primary multicast RTP session but wants to terminate this request before it learns the individual media sender SSRC(s) via RAMS-I message(s) or RTP packets, the RTP_Rx cannot use RAMS-T message(s) and thus MUST send an RTCP BYE message in the unicast burst RTP session to terminate the request.
如果RTP_Rx想要提前终止突发，它必须为它想要终止的主多播流的SSRC发送RAMS-T消息。此消息在单播突发RTP会话中发送。收到此消息后，BRS必须终止单播突发。如果RTP_Rx请求获取整个主多播RTP会话，但希望在通过RAMS-I消息或RTP数据包了解单个媒体发送方SSRC之前终止该请求，则RTP_Rx不能使用RAMS-T消息，因此必须在单播突发RTP会话中发送RTCP BYE消息以终止该请求。
Otherwise, the default behavior for the RTP_Rx is to send a RAMS-T message in the unicast burst RTP session immediately after it joins the multicast session and has started receiving multicast packets. In that case, the RTP_Rx MUST send a RAMS-T message with the sequence number of the first RTP packet received in the primary multicast stream. Then, the BRS MUST terminate the respective burst after it sends the unicast burst packet whose Original Sequence Number (OSN) field in the RTP retransmission payload header matches this number minus one. If the BRS has already sent that unicast burst packet when the RAMS-T message arrives, the BRS MUST terminate the respective burst immediately.
否则，RTP_Rx的默认行为是在加入多播会话并开始接收多播分组后，立即在单播突发RTP会话中发送RAMS-T消息。在这种情况下，RTP_Rx必须发送具有在主多播流中接收的第一个RTP分组的序列号的RAMS-T消息。然后，BRS必须在发送其在RTP重传有效载荷报头中的原始序列号（OSN）字段与该数字减1匹配的单播突发数据包之后终止相应的突发。如果BRS在RAMS-T消息到达时已发送该单播突发数据包，则BRS必须立即终止相应的突发。
If an RTCP BYE message has not been issued yet as described in Step 10, the RTP_Rx MUST send at least one RAMS-T message for each primary multicast stream served by the BRS. The RAMS-T message(s) MUST be sent to the BRS in the unicast burst RTP session. Against the possibility of a message loss, it is RECOMMENDED that the RTP_Rx repeats the RAMS-T messages multiple times as long as it follows the RTCP timer rules defined in [RFC4585].
如果尚未发出RTCP BYE消息（如步骤10所述），RTP_Rx必须为BRS服务的每个主多播流发送至少一条RAMS-T消息。RAMS-T消息必须在单播突发RTP会话中发送到BRS。针对消息丢失的可能性，建议RTP_Rx重复RAMS-T消息多次，只要它遵循[RFC4585]中定义的RTCP定时器规则。
The binding between RAMS-T and ongoing bursts is achieved through RTP_Rx's CNAME identifier and packet sender and media sender SSRCs. Choosing a globally unique CNAME makes sure that the RAMS-T messages are processed correctly.
RAMS-T和正在进行的突发之间的绑定是通过RTP_Rx的CNAME标识符以及数据包发送方和媒体发送方SSRC实现的。选择全局唯一的CNAME可确保正确处理RAMS-T消息。
10. Terminate with RTCP BYE: When the RTP_Rx is receiving one or more burst streams, if the RTP_Rx becomes no longer interested in acquiring any of the primary multicast streams, the RTP_Rx SHALL issue an RTCP BYE message for the unicast burst RTP session and another RTCP BYE message for the primary multicast RTP session. These RTCP BYE messages are sent to the BRS and FT logical entities, respectively.
10. 以RTCP BYE终止：当RTP_Rx接收到一个或多个突发流时，如果RTP_Rx不再对获取任何主多播流感兴趣，RTP_Rx应为单播突发RTP会话发出RTCP BYE消息，并为主多播RTP会话发出另一RTCP BYE消息。这些RTCP BYE消息分别发送到BRS和FT逻辑实体。
Upon receiving an RTCP BYE message, the BRS MUST terminate the rapid acquisition operation and cease transmitting any further burst packets and retransmission packets. If support for [RFC5506] has been signaled, the RTCP BYE message MAY be sent in a reduced-size RTCP packet. Otherwise, Section 6.1 of [RFC3550] mandates the RTCP BYE message always be sent with a sender or receiver report in a compound RTCP packet. If no data has been received, an empty receiver report MUST be still included. With the information contained in the receiver report, the RS can figure out how many duplicate RTP packets have been delivered to the RTP_Rx (note that this will be an upper-bound estimate as one or more packets might have been lost during the burst
一旦接收到RTCP BYE消息，BRS必须终止快速采集操作，并停止传输任何进一步的突发数据包和重传数据包。如果已发出支持[RFC5506]的信号，则RTCP BYE消息可在减小的RTCP数据包中发送。否则，[RFC3550]第6.1节要求RTCP BYE消息始终与复合RTCP数据包中的发送方或接收方报告一起发送。如果未收到任何数据，则仍必须包含空的接收方报告。利用接收机报告中包含的信息，RS可以计算出有多少重复的RTP分组已被传送到RTP_Rx（注意，这将是上限估计，因为在突发期间一个或多个分组可能已丢失）
transmission). The impact of duplicate packets and measures that can be taken to minimize the impact of receiving duplicate packets will be addressed in Section 6.4.
传输）。第6.4节将说明重复数据包的影响以及可采取的措施，以尽量减少接收重复数据包的影响。
Since an RTCP BYE message issued for the unicast burst RTP session terminates that session and ceases transmitting any further packets in that session, there is no need for sending explicit RAMS-T messages, which would only terminate their respective bursts.
由于为单播突发RTP会话发出的RTCP BYE消息终止该会话并停止在该会话中传输任何进一步的数据包，因此不需要发送显式RAMS-T消息，该消息只会终止其各自的突发。
For the purpose of gathering detailed information about RTP_Rx's rapid acquisition experience, [MULTICAST-ACQ] defines an RTCP Extended Report (XR) Block. This report is designed to be payload-independent; thus, it can be used by any multicast application that supports rapid acquisition.
为了收集有关RTP_Rx快速采集体验的详细信息，[MULTICAST-ACQ]定义了RTCP扩展报告（XR）块。本报告旨在独立于有效载荷；因此，它可以被任何支持快速捕获的多播应用程序使用。
When an RTP_RX acquires multiple primary multicast streams, it might need to synchronize them for playout. This synchronization is achieved by the help of the RTCP sender reports [RFC3550]. If the playout will start before the RTP_Rx has joined the multicast session, the RTP_Rx needs to receive the information reflecting the synchronization among the primary multicast streams early enough so that it can play out the media in a synchronized fashion.
当RTP_RX获取多个主多播流时，可能需要同步它们以进行播放。此同步通过RTCP发送方报告[RFC3550]的帮助实现。如果播放将在RTP_Rx加入多播会话之前开始，则RTP_Rx需要足够早地接收反映主多播流之间的同步的信息，以便它能够以同步方式播放媒体。
The suggested approach is to use the RTP header extension mechanism [RFC5285] and convey the synchronization information in a header extension as defined in [RFC6051]. Per [RFC4588], "if the original RTP header carried an RTP header extension, the retransmission packet SHOULD carry the same header extension". Thus, as long as the multicast source emits a header extension with the synchronization information frequently enough, there is no additional task that needs to be carried out by the BRS. The synchronization information will be sent to the RTP_Rx along with the burst packets. The frequent header extensions sent in the primary multicast RTP sessions also allow rapid synchronization of the RTP streams for the RTP receivers that do not support RAMS or that directly join the multicast session without running RAMS. Thus, in RAMS applications, it is RECOMMENDED that the multicast sources frequently send synchronization information by using header extensions following the rules presented in [RFC6051]. The regular sender reports are still sent in the unicast session by following the rules of [RFC3550].
建议的方法是使用RTP报头扩展机制[RFC5285]，并在[RFC6051]中定义的报头扩展中传递同步信息。根据[RFC4588]，“如果原始RTP报头带有RTP报头扩展，则重传数据包应带有相同的报头扩展”。因此，只要多播源足够频繁地发射具有同步信息的报头扩展，就不需要BRS执行额外的任务。同步信息将与突发数据包一起发送到RTP_Rx。在主多播RTP会话中发送的频繁报头扩展还允许RTP接收器快速同步RTP流，这些RTP接收器不支持RAM或直接加入多播会话而不运行RAM。因此，在RAMS应用程序中，建议多播源根据[RFC6051]中的规则，通过使用报头扩展来频繁发送同步信息。常规发送方报告仍然按照[RFC3550]的规则在单播会话中发送。
This section provides informative guidelines about how the BRS can shape the transmission of the unicast burst and how congestion can be dealt with in the RAMS process. When the RTP_Rx detects that the unicast burst is causing severe congestion, it can prefer to send a RAMS-T message immediately to stop the unicast burst.
本节提供了有关BRS如何影响单播突发传输以及如何在RAMS过程中处理拥塞的信息指南。当RTP_Rx检测到单播突发造成严重拥塞时，它更愿意立即发送RAMS-T消息以停止单播突发。
A higher bitrate for the unicast burst naturally conveys the Reference Information and media content to the RTP_Rx faster. This way, the RTP_Rx can start consuming the data sooner, which results in a faster acquisition. A higher bitrate also represents a better utilization of the BRS resources. As the burst may continue until it catches up with the primary multicast stream, the higher the bursting bitrate, the less data the BRS needs to transmit. However, a higher bitrate for the burst also increases the chances for congestion-caused packet loss. Thus, as discussed in Section 5, there has to be an upper bound on the bandwidth used by the burst.
单播突发的较高比特率自然地将参考信息和媒体内容更快地传送到RTP_Rx。这样，RTP_Rx可以更快地开始消耗数据，从而加快采集速度。更高的比特率还表示更好地利用了BRS资源。由于突发可能会一直持续到赶上主多播流，突发比特率越高，BRS需要传输的数据就越少。然而，较高的突发比特率也会增加拥塞导致的数据包丢失的机会。因此，如第5节所述，突发使用的带宽必须有一个上限。
When the BRS transmits the unicast burst, it is expected to take into account all available information to prevent any packet loss that might take place during the bursting as a result of buffer overflow on the path between the RS and RTP_Rx and at the RTP_Rx itself. The bursting bitrate can be determined by taking into account the following information, when available:
当BRS传输单播突发时，预计将考虑所有可用信息，以防止突发期间由于RS和RTP_Rx之间的路径上以及RTP_Rx本身的缓冲区溢出而可能发生的任何分组丢失。突发比特率可以通过考虑以下信息（如果可用）来确定：
(a) Information obtained via the RAMS-R message, such as Max RAMS Buffer Fill Requirement and/or Max Receive Bitrate (see Section 7.2).
(a) 通过RAMS-R消息获得的信息，如最大RAMS缓冲区填充要求和/或最大接收比特率（见第7.2节）。
(b) Information obtained via RTCP receiver reports provided by the RTP_Rx in the retransmission session, allowing in-session bitrate adaptations for the burst. When these receiver reports indicate packet loss, this can indicate a certain congestion state in the path from the RS to the RTP_Rx.
(b) 通过RTP_Rx在重传会话中提供的RTCP接收器报告获得的信息，允许对突发进行会话内比特率自适应。当这些接收器报告指示分组丢失时，这可以指示从RS到RTP_Rx的路径中的某种拥塞状态。
(c) Information obtained via RTCP NACKs provided by the RTP_Rx in the primary multicast RTP session, allowing in-session bitrate adaptations for the burst. Such RTCP NACKs are transmitted by the RTP_Rx in response to packet loss detection in the burst. NACKs can indicate a certain congestion state on the path from the RS to RTP_Rx.
(c) 通过RTP_Rx在主多播RTP会话中提供的RTCP NACK获得的信息，允许对突发进行会话内比特率自适应。RTP_Rx响应于突发中的分组丢失检测而发送此类RTCP nack。nack可以指示从RS到RTP_Rx的路径上的某种拥塞状态。
(d) There can be other feedback received from the RTP_Rx, e.g., in the form of Explicit Congestion Notification - Congestion Experienced (ECN-CE) markings [ECN-FOR-RTP] that can influence in-session bitrate adaptation.
(d) 可以存在从RTP_Rx接收的其他反馈，例如，以可影响会话内比特率自适应的显式拥塞通知-经历拥塞（ECN-CE）标记[ECN-FOR-RTP]的形式。
(e) Information obtained via updated RAMS-R messages, allowing in-session bitrate adaptations, if supported by the BRS.
(e) 通过更新的RAMS-R消息获得的信息，如果BRS支持，允许会话内比特率自适应。
(f) Transport protocol-specific information. For example, when Datagram Congestion Control Protocol (DCCP) is used to transport the RTP burst, the ACKs from the DCCP client can be leveraged by the BRS / DCCP server for burst shaping and congestion control.
(f) 传输协议特定信息。例如，当使用数据报拥塞控制协议（DCCP）传输RTP突发时，BRS/DCCP服务器可以利用来自DCCP客户端的ACK进行突发整形和拥塞控制。
(g) Preconfigured settings for each RTP_Rx or a set of RTP_Rxs that indicate the upper-bound bursting bitrates for which no packet loss will occur as a result of congestion along the path of the RS to RTP_Rx. For example, in managed IPTV networks, where the bottleneck bandwidth along the end-to-end path is known and where the network between the RS and this link is provisioned and dimensioned to carry the burst streams, the bursting bitrate does not exceed the provisioned value. These settings can also be dynamically adapted using application-aware knowledge.
(g) 每个RTP_Rx或一组RTP_Rx的预配置设置，指示上界突发比特率，对于上界突发比特率，沿RS到RTP_Rx的路径的拥塞不会导致分组丢失。例如，在被管理的IPTV网络中，其中沿端到端路径的瓶颈带宽是已知的，并且在RS和该链路之间的网络被配置和尺寸化以承载突发流的情况下，突发比特率不超过所配置的值。还可以使用应用程序感知知识动态调整这些设置。
The BRS chooses the initial burst bitrate as follows:
BRS按照如下方式选择初始突发比特率：
o When using RAMS in environments as described in (g), the BRS MUST transmit the burst packets at an initial bitrate higher than the nominal bitrate but within the engineered or reserved bandwidth limit.
o 在（g）中所述的环境中使用RAM时，BRS必须以高于标称比特率但在工程或保留带宽限制内的初始比特率传输突发数据包。
o When the BRS cannot determine a reliable bitrate value for the unicast burst (using (a) through (g)), it is desirable for the BRS to choose an appropriate initial bitrate not above the nominal bitrate and increase it gradually unless a congestion is detected.
o 当BRS不能确定单播突发的可靠比特率值时（使用（a）到（g）），期望BRS选择不高于标称比特率的适当初始比特率并逐渐增加它，除非检测到拥塞。
In both cases, during the burst transmission, the BRS MUST continuously monitor for packet losses as a result of congestion by means of one or more of the mechanisms described in (b) through (f). When the BRS relies on RTCP receiver reports, sufficient bandwidth needs to be provided to RTP_Rx for RTCP transmission in the unicast burst RTP session. To achieve a reasonable fast adaptation against congestion, it is recommended that the RTP_Rx sends a receiver report at least once every two RTTs between the RS and RTP_Rx. Although the specific heuristics and algorithms that deduce a congestion state and how the BRS acts subsequently are outside the scope of this specification, the following two methods are the best practices:
在这两种情况下，在突发传输期间，BRS必须通过（b）到（f）中描述的一个或多个机制来持续监控由于拥塞而导致的分组丢失。当BRS依赖RTCP接收器报告时，需要向RTP_Rx提供足够的带宽，以便在单播突发RTP会话中进行RTCP传输。为了实现针对拥塞的合理快速自适应，建议RTP_Rx在RS和RTP_Rx之间至少每两个RTT发送一次接收器报告。虽然推断拥塞状态和BRS随后如何行动的特定启发式和算法不在本规范的范围内，但以下两种方法是最佳实践：
o Upon detection of a significant amount of packet loss, which the BRS attributes to congestion, the BRS decreases the burst bitrate. The rate by which the BRS increases and decreases the bitrate for the burst can be determined by a TCP-friendly bitrate adaptation algorithm for RTP over UDP or, in the case of (f), by the congestion control algorithms defined in DCCP [RFC5762].
o 在检测到大量数据包丢失（BRS将其归因于拥塞）时，BRS降低突发比特率。BRS增加和减少突发比特率的速率可以通过UDP上RTP的TCP友好比特率自适应算法确定，或者在（f）的情况下，通过DCCP[RFC5762]中定义的拥塞控制算法确定。
o If the congestion is persistent and the BRS has to reduce the burst bitrate to a point where the RTP_Rx buffer might underrun or the burst will consume too many resources, the BRS terminates the burst and transmits a RAMS-I message to RTP_Rx with the appropriate response code. It is then up to RTP_Rx to decide when to join the multicast session.
o 如果拥塞持续存在，BRS必须将突发比特率降低到RTP_Rx缓冲区可能运行不足或突发将消耗太多资源的程度，则BRS终止突发，并使用适当的响应代码向RTP_Rx发送RAMS-I消息。然后由RTP_Rx决定何时加入多播会话。
Even though there is no congestion experienced during the burst, congestion may anyway arise near the end of the burst as the RTP_Rx eventually needs to join the multicast session. During this brief period, both the burst packets and the multicast packets can be simultaneously received by the RTP_Rx, thus enhancing the risk of congestion.
即使在突发过程中没有遇到拥塞，但由于RTP_Rx最终需要加入多播会话，在突发结束时可能会出现拥塞。在这短暂的时间段内，RTP_Rx可以同时接收突发分组和多播分组，从而提高拥塞风险。
Since the BRS signals the RTP_Rx when the BRS expects the RTP_Rx to send the SFGMP Join message, the BRS can have a rough estimate of when the RTP_Rx will start receiving multicast packets in the SSM session. The BRS can keep on sending burst packets but reduces the bitrate accordingly at the appropriate instant by taking the bitrate of the whole SSM session into account. If the BRS ceases transmitting the burst packets before the burst catches up, any gap resulting from this imperfect switch-over by the RTP_Rx can be later repaired by requesting retransmissions for the missing packets from the RS. The retransmissions can be shaped by the BRS to make sure that they do not cause collateral loss in the primary multicast RTP session and the unicast burst RTP session.
由于当BRS期望RTP_Rx发送SFGMP加入消息时，BRS向RTP_Rx发送信号，因此BRS可以粗略估计RTP_Rx将在SSM会话中何时开始接收多播数据包。BRS可以继续发送突发数据包，但通过考虑整个SSM会话的比特率，在适当的时刻相应地降低比特率。如果BRS在突发捕获之前停止发送突发数据包，由于RTP_Rx的这种不完美切换而产生的任何间隙可在稍后通过请求来自RS的丢失分组的重新传输来修复。重新传输可由BRS成形，以确保它们不会在主多播RTP会话和单播突发RTP会话中造成附带损失。
In this section, we examine the implications of losing the RAMS-R, RAMS-I, or RAMS-T messages and other failure cases.
在本节中，我们将研究丢失RAMS-R、RAMS-I或RAMS-T消息以及其他故障情况的影响。
When the RTP_Rx sends a RAMS-R message to initiate a rapid acquisition but the message gets lost and the FT does not receive it, the RTP_Rx will get neither a RAMS-I message nor a unicast burst. In this case, the RTP_Rx MAY resend the request when it is eligible to do so based on the RTCP timer rules defined in [RFC4585]. Or, after a reasonable amount of time, the RTP_Rx can time out (based on the previous observed response times) and immediately join the SSM session.
当RTP_Rx发送RAMS-R消息以启动快速采集，但该消息丢失且FT未接收到该消息时，RTP_Rx既不会收到RAMS-I消息，也不会收到单播突发。在这种情况下，当RTP_Rx有资格根据[RFC4585]中定义的RTCP定时器规则重新发送请求时，RTP_Rx可以重新发送请求。或者，在合理的时间量之后，RTP_Rx可以超时（基于先前观察到的响应时间），并立即加入SSM会话。
In the case where RTP_Rx starts receiving a unicast burst but does not receive a corresponding RAMS-I message within a reasonable amount of time, the RTP_Rx can either discard the burst data or decide not to interrupt the unicast burst and be prepared to join the SSM session at an appropriate time it determines or as indicated in a subsequent RAMS-I message (if available). If the network is subject
如果RTP_Rx开始接收单播突发，但在合理的时间内未接收到相应的RAMS-I消息，RTP_Rx可丢弃突发数据或决定不中断单播突发，并准备在其确定的适当时间或如后续RAMS-I消息（如可用）所示加入SSM会话。如果网络是主题
to packet loss, it is RECOMMENDED that the BRS repeats the RAMS-I messages multiple times based on the RTCP timer rules defined in [RFC4585].
对于数据包丢失，建议BRS根据[RFC4585]中定义的RTCP定时器规则多次重复RAMS-I消息。
In the failure cases where the RAMS-I message is lost or the RAMS-R message is lost and the RTP_Rx gives up, the RTP_Rx MUST still terminate the burst(s) it requested by following the rules described in Section 6.2.
在RAMS-I消息丢失或RAMS-R消息丢失且RTP_Rx放弃的故障情况下，RTP_Rx仍必须按照第6.2节所述规则终止其请求的突发。
In the case where a RAMS-T message sent by the RTP_Rx does not reach its destination, the BRS can continue sending burst packets even though the RTP_Rx no longer needs them. If an RTP_Rx is receiving burst packets it no longer needs after sending a RAMS-T message, it is RECOMMENDED that the RTP_Rx repeats the RAMS-T message multiple times based on the RTCP timer rules defined in [RFC4585]. The BRS MUST be provisioned to terminate the burst when it can no longer send the burst packets faster than it receives the primary multicast stream packets.
在RTP_Rx发送的RAMS-T消息未到达其目的地的情况下，BRS可以继续发送突发数据包，即使RTP_Rx不再需要它们。如果RTP_Rx在发送RAMS-T消息后接收到不再需要的突发数据包，建议RTP_Rx根据[RFC4585]中定义的RTCP定时器规则多次重复RAMS-T消息。当BRS发送突发数据包的速度不再快于接收主多播流数据包的速度时，必须设置BRS以终止突发数据包。
Section 6.3.5 of [RFC3550] explains the rules pertaining to timing out an SSRC. When the BRS accepts to serve the requested burst(s) and establishes the retransmission session, the BRS needs to check the liveness of the RTP_Rx via the RTCP messages and reports the RTP_Rx sends. The default rules explained in [RFC3550] apply in RAMS as well.
[RFC3550]第6.3.5节解释了与SSRC超时相关的规则。当BRS接受服务于请求的突发并建立重传会话时，BRS需要通过RTCP消息检查RTP_Rx的活跃度，并报告RTP_Rx发送。[RFC3550]中解释的默认规则也适用于RAM。
This section defines the formats of the RTCP transport-layer feedback messages that are exchanged between the retransmission server (RS) and RTP receiver (RTP_Rx) during rapid acquisition. These messages are referred to as the RAMS Messages. They are payload-independent and MUST be used by all RTP-based multicast applications that support rapid acquisition regardless of the payload they carry.
本节定义了在快速采集期间在重传服务器（RS）和RTP接收器（RTP_Rx）之间交换的RTCP传输层反馈消息的格式。这些消息称为RAMS消息。它们独立于有效载荷，必须由所有支持快速捕获的基于RTP的多播应用程序使用，而不管它们携带的有效载荷如何。
Payload-specific feedback messages are not defined in this document. However, further optional payload-independent and payload-specific information can be included in the exchange.
本文档中未定义特定于负载的反馈消息。然而，进一步的可选有效负载独立和有效负载特定信息可以包括在交换中。
The common packet format for the RTCP feedback messages is defined in Section 6.1 of [RFC4585] and is also sketched in Figure 4.
[RFC4585]第6.1节中定义了RTCP反馈消息的通用数据包格式，图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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | 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 | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 4: The Common Packet Format for the RTCP Feedback Messages
图4:RTCP反馈消息的通用数据包格式
Each feedback message has a fixed-length field for version, padding, feedback message type (FMT), packet type (PT), length, SSRC of packet sender, SSRC of media source, and a variable-length field for feedback control information (FCI).
每个反馈消息都有一个用于版本、填充、反馈消息类型（FMT）、数据包类型（PT）、长度、数据包发送方的SSRC、媒体源的SSRC的固定长度字段，以及用于反馈控制信息（FCI）的可变长度字段。
In the RAMS messages, the PT field is set to RTPFB (205) and the FMT field is set to RAMS (6). Individual RAMS messages are identified by a sub-field called sub-feedback message type (SFMT). Any Reserved field SHALL be set to zero and ignored.
在RAMS消息中，PT字段设置为RTPFB（205），FMT字段设置为RAMS（6）。单个RAMS消息由称为子反馈消息类型（SFMT）的子字段标识。任何保留字段应设置为零并忽略。
Depending on the specific scenario and timeliness/importance of a RAMS message, it can be desirable to send it in a reduced-size RTCP packet [RFC5506]. However, unless support for [RFC5506] has been signaled, compound RTCP packets MUST be used by following [RFC3550] rules.
根据特定场景和RAMS消息的及时性/重要性，可能希望以较小的RTCP数据包[RFC5506]发送该消息。但是，除非已发出支持[RFC5506]的信号，否则必须按照[RFC3550]规则使用复合RTCP数据包。
Following the rules specified in [RFC3550], all integer fields in the messages defined below are carried in network-byte order, that is, most significant byte (octet) first, also known as big-endian. Unless otherwise stated, numeric constants are in decimal (base 10).
按照[RFC3550]中指定的规则，下面定义的消息中的所有整数字段都以网络字节顺序进行传输，也就是说，最高有效字节（八位字节）优先，也称为big-endian。除非另有说明，否则数值常量为十进制（以10为基数）。
To improve the functionality of the RAMS method in certain applications, it can be desirable to define new fields in the RAMS Request, Information, and Termination messages. Such fields MUST be encoded as Type-Length-Value (TLV) elements as described below and sketched in Figure 5:
为了在某些应用程序中改进RAMS方法的功能，可能需要在RAMS请求、信息和终止消息中定义新字段。这些字段必须编码为类型长度值（TLV）元素，如下所述，如图5所示：
o Type: A single-octet identifier that defines the type of the parameter represented in this TLV element.
o 类型：定义此TLV元素中表示的参数类型的单个八位组标识符。
o Length: A two-octet field that indicates the length (in octets) of the TLV element excluding the Type and Length fields and the 8-bit Reserved field between them. This length does not include any padding that is required for alignment.
o 长度：两个八位字节字段，表示TLV元素的长度（以八位字节为单位），不包括类型字段和长度字段以及它们之间的8位保留字段。此长度不包括对齐所需的任何填充。
o Value: Variable-size set of octets that contains the specific value for the parameter.
o 值：包含参数特定值的可变大小的八位字节集。
In the extensions, the Reserved field SHALL be set to zero and ignored. If a TLV element does not fall on a 32-bit boundary, the last word MUST be padded to the boundary using further bits set to zero.
在扩展中，保留字段应设置为零并忽略。如果TLV元素不在32位边界上，则必须使用设置为零的其他位将最后一个字填充到边界。
An RTP_Rx or BRS MAY include vendor-neutral and private extensions in any RAMS message. The RTP_Rx or BRS MUST place such extensions after the mandatory fields and mandatory TLV elements (if any) and MAY place such extensions in any order. The RTP_Rx or BRS MUST NOT include multiple TLV elements with the same Type value in a RAMS message.
RTP_Rx或BRS可在任何RAMS消息中包括供应商中立和专用扩展。RTP_Rx或BRS必须将此类扩展放置在必填字段和必填TLV元素（如有）之后，并且可以按任何顺序放置此类扩展。RTP_Rx或BRS不得在RAMS消息中包含具有相同类型值的多个TLV元件。
The support for extensions (unless specified otherwise) is OPTIONAL. An RTP_Rx or BRS receiving a vendor-neutral or private extension that it does not understand MUST ignore that extension.
对扩展的支持（除非另有规定）是可选的。RTP_Rx或BRS收到其不理解的供应商中立或私有扩展时，必须忽略该扩展。
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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of a TLV Element
图5：TLV元件的结构
If the goal in defining new TLV elements is to extend the functionality in a vendor-neutral manner, they MUST be registered with IANA through the guidelines provided in Section 11.5.
如果定义新TLV元素的目的是以供应商中立的方式扩展功能，则必须通过第11.5节提供的指南向IANA注册这些元素。
The current document defines several vendor-neutral extensions in the subsequent sections.
当前文档在后续章节中定义了多个与供应商无关的扩展。
It is desirable to allow vendors to use private extensions in a TLV format. For interoperability, such extensions must not collide with each other.
允许供应商使用TLV格式的私有扩展是可取的。为了实现互操作性，这些扩展不能相互冲突。
A certain range of TLV Types (between and including 128 and 254 ) is reserved for private extensions (refer to Section 11.5). IANA management for these extensions is unnecessary, and they are the responsibility of individual vendors.
一定范围的TLV类型（介于128和254之间）保留给专用扩展（参考第11.5节）。IANA对这些扩展的管理是不必要的，它们是各个供应商的责任。
The structure that MUST be used for the private extensions is depicted in Figure 6. Here, the enterprise numbers are as listed on http://www.iana.org. This will ensure the uniqueness of the private extensions and avoid any collision.
私有扩展必须使用的结构如图6所示。在这里，企业编号如上所列http://www.iana.org. 这将确保私有扩展的唯一性并避免任何冲突。
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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Structure of a Private Extension
图6：私有扩展的结构
The RAMS Request (RAMS-R) message is identified by SFMT=1. This message is sent as unicast feedback in the primary multicast RTP session by the RTP_Rx to request rapid acquisition of a primary multicast RTP session or one or more primary multicast streams belonging to the same primary multicast RTP session. In the RAMS-R message, the RTP_Rx MUST set both the packet sender SSRC and media sender SSRC fields to its own SSRC since the media sender SSRC may not be known. The RTP_Rx MUST provide explicit signaling as described below to request stream(s). This minimizes the chances of accidentally requesting a wrong primary multicast stream.
RAMS请求（RAMS-R）消息由SFMT=1标识。该消息由RTP_Rx在主多播RTP会话中作为单播反馈发送，以请求快速获取主多播RTP会话或属于同一主多播RTP会话的一个或多个主多播流。在RAMS-R消息中，RTP_Rx必须将数据包发送方SSRC和媒体发送方SSRC字段设置为其自己的SSRC，因为媒体发送方SSRC可能未知。RTP_Rx必须提供如下所述的明确信令，以请求流。这将意外请求错误的主多播流的机会降至最低。
The FCI field MUST contain only one RAMS Request. The FCI field has the structure depicted in Figure 7.
FCI字段只能包含一个RAMS请求。FCI字段的结构如图7所示。
The semantics of the RAMS-R message is independent of the payload type carried in the primary multicast RTP session.
RAMS-R消息的语义与主多播RTP会话中承载的有效负载类型无关。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Requested Media Sender SSRC(s) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Requested Media Sender SSRC(s) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FCI Field Syntax for the RAMS Request Message
图7:RAMS请求消息的FCI字段语法
o Requested Media Sender SSRC(s): Mandatory TLV element that lists the media sender SSRC(s) requested by the RTP_Rx. The BRS MUST ignore the media sender SSRC specified in the header of the RAMS-R message.
o 请求的媒体发送方SSRC：列出RTP_Rx请求的媒体发送方SSRC的强制TLV元素。BRS必须忽略RAMS-R消息头中指定的媒体发送方SSRC。
If the Length field is set to zero (i.e., no media sender SSRC is listed), it means that the RTP_Rx is requesting to rapidly acquire the entire primary multicast RTP session. Otherwise, the RTP_Rx lists the individual media sender SSRCs in this TLV element and sets the Length field of the TLV element to 4*n, where n is the number of SSRC entries.
如果长度字段设置为零（即，未列出任何媒体发送方SSRC），则表示RTP_Rx正在请求快速获取整个主多播RTP会话。否则，RTP_Rx列出该TLV元素中的各个媒体发送方SSRC，并将TLV元素的长度字段设置为4*n，其中n是SSRC条目的数量。
Type: 1
类型：1
o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element that denotes the minimum milliseconds of data that the RTP_Rx desires to have in its buffer before allowing the data to be consumed by the application.
o 最小RAM缓冲区填充要求（32位）：可选TLV元素，表示RTP_Rx在允许应用程序使用数据之前希望在其缓冲区中包含的最小数据毫秒数。
The RTP_Rx can have knowledge of its buffering requirements. These requirements can be application and/or device specific. For instance, the RTP_Rx might need to have a certain amount of data in its application buffer to handle transmission jitter and/or to be able to support error-control methods. If the BRS is told the minimum buffering requirement of the receiver, the BRS can tailor the burst(s) more precisely, e.g., by choosing an appropriate starting point. The methods used by the RTP_Rx to determine this value are application specific and thus out of the scope of this document.
RTP_Rx可以了解其缓冲要求。这些要求可以是特定于应用和/或设备的。例如，RTP_Rx可能需要在其应用缓冲器中具有一定量的数据，以处理传输抖动和/或能够支持差错控制方法。如果BRS被告知接收器的最小缓冲要求，则BRS可以更精确地定制突发，例如，通过选择适当的起始点。RTP_Rx用于确定该值的方法是特定于应用的，因此不在本文件的范围内。
If specified, the amount of backfill that will be provided by the unicast bursts and any payload-specific information MUST NOT be smaller than the specified value. Otherwise, the backfill will not be able to build up the desired level of buffer at the RTP_Rx and can cause buffer underruns.
如果指定，单播突发和任何有效负载特定信息将提供的回填量不得小于指定值。否则，回填将无法在RTP_Rx处建立所需的缓冲水平，并可能导致缓冲不足。
Type: 2
类型：2
o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element that denotes the maximum milliseconds of data that the RTP_Rx can buffer without losing the data due to buffer overflow.
o 最大RAM缓冲区填充要求（32位）：可选TLV元素，表示RTP_Rx可以缓冲的最大数据毫秒数，而不会因缓冲区溢出而丢失数据。
The RTP_Rx can have knowledge of its buffering requirements. These requirements can be application or device specific. For instance, one particular RTP_Rx might have more physical memory than another RTP_Rx and thus can buffer more data. If the BRS knows the buffering ability of the receiver, the BRS can tailor the burst(s) more precisely. The methods used by the receiver to determine this value are application specific and thus out of the scope of this document.
RTP_Rx可以了解其缓冲要求。这些要求可以是特定于应用程序或设备的。例如，一个特定的RTP_Rx可能比另一个RTP_Rx具有更多的物理内存，因此可以缓冲更多的数据。如果BRS知道接收器的缓冲能力，BRS可以更精确地调整突发。接收方用于确定该值的方法是特定于应用的，因此不在本文件的范围内。
If specified, the amount of backfill that will be provided by the unicast bursts and any payload-specific information MUST NOT be larger than this value. Otherwise, the backfill may cause buffer overflows at the RTP_Rx.
如果指定，单播突发和任何负载特定信息将提供的回填量不得大于该值。否则，回填可能导致RTP_Rx处的缓冲区溢出。
Type: 3
类型：3
o Max Receive Bitrate (64 bits): Optional TLV element that denotes the maximum bitrate (in bits per second) at which the RTP_Rx can process the aggregation of the unicast burst(s) and any payload-specific information that will be provided by the BRS. The limits can include local receiver limits as well as network limits that are known to the receiver.
o 最大接收比特率（64位）：可选TLV元素，表示RTP_Rx可以处理单播突发和BRS提供的任何有效负载特定信息的聚合的最大比特率（以比特/秒为单位）。限制可以包括本地接收器限制以及接收器已知的网络限制。
If specified, the total bitrate of the unicast burst(s) plus any payload-specific information MUST NOT be larger than this value. Otherwise, congestion and packet loss are more likely to occur.
如果指定，单播突发的总比特率加上任何负载特定信息不得大于该值。否则，更可能发生拥塞和数据包丢失。
Type: 4
类型：4
o Preamble-only Allowed (0 bits): Optional TLV element that indicates that the RTP_Rx is willing to receive only the preamble information for the desired primary multicast stream(s) in case the BRS cannot send the unicast burst stream(s). (In such cases, the BRS will not accept the request, but will send a response code 511 in the RAMS-I message as defined in Section 11.6.) Note that
o 仅允许前导码（0位）：可选TLV元素，指示RTP_Rx在BRS无法发送单播突发流的情况下只愿意接收所需主多播流的前导码信息。（在这种情况下，BRS将不接受请求，但将在第11.6节定义的RAMS-I消息中发送响应代码511。）注意
the RTP_Rx signals the particular preamble format(s) it supports through a public or a private extension in the same RAMS-R message.
RTP_Rx通过同一RAMS-R消息中的公共或私有扩展向其支持的特定前导格式发送信号。
If this TLV element does not exist in the RAMS-R message, the BRS MUST NOT respond to the RAMS-R message by sending the preamble information only. Since this TLV element does not carry a Value field, the Length field MUST be set to zero.
如果RAMS-R消息中不存在该TLV元素，则BRS不得仅通过发送前导信息来响应RAMS-R消息。由于此TLV元素不包含值字段，因此长度字段必须设置为零。
Type: 5
类型：5
o Supported Enterprise Number(s): Optional TLV element that indicates the enterprise number(s) that the RTP_Rx implementation supports. Similar to the private extensions, the enterprise numbers here are as listed on http://www.iana.org. This TLV element, if exists, provides a hint to the BRS about which private extensions the RTP_Rx can potentially support. Note that an RTP_Rx does not necessarily support all the private extensions under a particular enterprise number. Unless the BRS explicitly knows which private extensions an RTP_Rx supports (through this or some out-of-band means), the BRS SHOULD NOT use private extensions in the RAMS-I messages. The BRS SHOULD rather use only vendor-neutral extensions. The Length field of this TLV element is set to 4*n, where n is the number of enterprise number entries.
o 受支持的企业编号：可选TLV元素，指示RTP_Rx实施支持的企业编号。与专用扩展类似，此处的企业编号如上所列http://www.iana.org. 此TLV元素（如果存在）向BRS提供RTP_Rx可能支持哪些专用扩展的提示。请注意，RTP_Rx不一定支持特定企业编号下的所有专用扩展。除非BRS明确知道RTP_Rx支持哪些专用扩展（通过此方式或某些带外方式），否则BRS不应在RAMS-I消息中使用专用扩展。BRS应该只使用供应商中立的扩展。此TLV元素的长度字段设置为4*n，其中n是企业编号条目的数量。
Type: 6
类型：6
The RAMS Information (RAMS-I) message is identified by SFMT=2. This message is used to describe the unicast burst that will be sent for rapid acquisition. It also includes other useful information for the RTP_Rx as described below.
RAMS信息（RAMS-I）消息由SFMT=2标识。此消息用于描述将被发送用于快速捕获的单播突发。它还包括RTP_Rx的其他有用信息，如下所述。
A separate RAMS-I message with the appropriate response code is sent in the unicast burst RTP session by the BRS for each primary multicast stream that has been requested by the RTP_Rx. In each of these RAMS-I messages, the media sender SSRC and packet sender SSRC fields are both set to the SSRC of the BRS, which equals the SSRC of the respective primary multicast stream.
BRS在单播突发RTP会话中为RTP_Rx请求的每个主多播流发送带有适当响应代码的单独RAMS-I消息。在这些RAMS-I消息中的每个消息中，媒体发送方SSRC和分组发送方SSRC字段都被设置为BRS的SSRC，其等于各自主多播流的SSRC。
The FCI field MUST contain only one RAMS Information message. The FCI field has the structure depicted in Figure 8.
FCI字段必须仅包含一条RAMS信息消息。FCI字段的结构如图8所示。
The semantics of the RAMS-I message is independent of the payload type carried in the primary multicast RTP session.
RAMS-I消息的语义独立于主多播RTP会话中承载的有效负载类型。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=2 | MSN | Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=2 | MSN | Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FCI Field Syntax for the RAMS Information Message
图8:RAMS信息消息的FCI字段语法
A RAMS-I message has the following fields:
RAMS-I消息包含以下字段：
o Message Sequence Number (MSN) (8 bits) : Mandatory field that denotes the sequence number of the RAMS-I message for the particular media sender SSRC specified in the message header. The MSN value SHALL be set to zero when a new RAMS request is received. During rapid acquisition, the same RAMS-I message MAY be repeated for redundancy purposes without incrementing the MSN value. If an updated RAMS-I message will be sent (either with new information or updated information), the MSN value SHALL be incremented by one. In the MSN field, the regular wrapping rules apply. Note that if the RTP_Rx has sent an updated request, it MUST check every RAMS-I message entirely, regardless of whether or not the MSN value has changed.
o 消息序列号（MSN）（8位）：必填字段，表示消息头中指定的特定媒体发送方SSRC的RAMS-I消息序列号。当收到新的RAMS请求时，MSN值应设置为零。在快速采集期间，出于冗余目的，相同的RAMS-I消息可能会重复，而不会增加MSN值。如果将发送更新的RAMS-I消息（包括新信息或更新信息），MSN值应增加1。在MSN字段中，常规换行规则适用。请注意，如果RTP_Rx发送了更新的请求，则无论MSN值是否已更改，它必须完全检查每个RAMS-I消息。
o Response (16 bits): Mandatory field that denotes the response code for this RAMS-I message. This document defines several initial response codes in Section 7.3.1 and registers them with IANA in Section 11.6. If a new vendor-neutral response code will be defined, it MUST be registered with IANA through the guidelines specified in Section 11.6. If the new response code is intended to be used privately by a vendor, there is no need for IANA management. Instead, the vendor MUST use the private extension mechanism (Section 7.1.2) to convey its message and MUST indicate this by putting zero in the Response field.
o 响应（16位）：表示此RAMS-I消息响应代码的必填字段。本文件在第7.3.1节中定义了几个初始响应代码，并在第11.6节中向IANA注册了这些代码。如果将定义新的供应商中立响应代码，则必须按照第11.6节规定的指南向IANA注册。如果新的响应代码打算由供应商私下使用，则无需IANA管理。相反，供应商必须使用专用扩展机制（第7.1.2节）来传达其信息，并且必须通过在响应字段中输入零来表明这一点。
When the RTP_Rx receives a RAMS-I message with a response code that it does not understand, the RTP_Rx MUST send a RAMS-T message immediately to the BRS.
当RTP_Rx接收到带有其无法理解的响应代码的RAMS-I消息时，RTP_Rx必须立即向BRS发送RAMS-T消息。
The following TLV elements have been defined for the RAMS-I messages:
已为RAMS-I消息定义了以下TLV元素：
o Media Sender SSRC (32 bits): Optional TLV element that specifies the media sender SSRC of the unicast burst stream. If the FT_Ap that received the RAMS-R message is associated with a single primary multicast stream but the requested media sender SSRC does not match the SSRC of the RTP stream associated with this FT_Ap,
o 媒体发送方SSRC（32位）：可选TLV元素，指定单播突发流的媒体发送方SSRC。如果接收RAMS-R消息的FT_Ap与单个主多播流相关联，但请求的媒体发送方SSRC与与该FT_Ap关联的RTP流的SSRC不匹配，
the BRS includes this TLV element in the initial RAMS-I message to let the RTP_Rx know that the media sender SSRC has changed. If the two SSRCs match, there is no need to include this TLV element.
BRS在初始RAMS-I消息中包含该TLV元素，以让RTP_Rx知道媒体发送器SSRC已更改。如果两个SSRC匹配，则无需包括该TLV元素。
Type: 31
类型：31
o RTP Seqnum of the First Packet (16 bits): TLV element that specifies the RTP sequence number of the first packet that will be sent in the respective unicast RTP stream. This allows the RTP_Rx to know whether one or more packets sent by the BRS have been dropped at the beginning of the stream. If the BRS accepts the RAMS request, this element exists. If the BRS rejects the RAMS request, this element SHALL NOT exist.
o 第一个数据包的RTP Seqnum（16位）：TLV元素，指定将在各自的单播RTP流中发送的第一个数据包的RTP序列号。这允许RTP_Rx知道由BRS发送的一个或多个数据包是否在流的开始处被丢弃。如果BRS接受RAMS请求，则该元素存在。如果BRS拒绝RAMS请求，则该元素不应存在。
Type: 32
类型：32
o Earliest Multicast Join Time (32 bits): TLV element that specifies the delta time (in ms) between the arrival of the first RTP packet in the unicast RTP stream (which could be a burst packet or a payload-specific packet) and the earliest time instant when an RTP_Rx MAY send an SFGMP Join message to join the multicast session. A zero value indicated in this element means that the RTP_Rx MAY send the SFGMP Join message right away. If the RTP_Rx does not want to wait until the earliest multicast join time, it MAY send a RAMS-T message, and after a reasonable amount of time, it MAY join the SSM session.
o 最早多播加入时间（32位）：TLV元素，指定单播RTP流中第一个RTP数据包（可以是突发数据包或有效负载特定数据包）到达与RTP_Rx可发送SFGMP加入消息以加入多播会话的最早时间瞬间之间的增量时间（毫秒）。此元素中指示的零值表示RTP_Rx可立即发送SFGMP Join消息。如果RTP_Rx不想等到最早的多播加入时间，它可以发送RAMS-T消息，并且在合理的时间量之后，它可以加入SSM会话。
If the RAMS request has been accepted, the BRS sends this element at least once so that the RTP_Rx knows when to join the multicast session. If the burst request has been rejected as indicated in the Response field, this element MUST indicate a zero value. In that case, it is up to the RTP_Rx when or whether to join the multicast session.
如果RAMS请求已被接受，BRS将至少发送此元素一次，以便RTP_Rx知道何时加入多播会话。如果响应字段中指示的突发请求已被拒绝，则该元素必须指示零值。在这种情况下，何时或是否加入多播会话取决于RTP_Rx。
When the BRS serves two or more bursts and sends a separate RAMS-I message for each burst, the join times specified in these RAMS-I messages SHOULD correspond to more or less the same time instant, and the RTP_Rx sends the SFGMP Join message based on the earliest join time.
当BRS服务于两个或多个突发并为每个突发发送单独的RAMS-I消息时，这些RAMS-I消息中指定的连接时间应或多或少地对应于相同的时间瞬间，RTP_Rx根据最早的连接时间发送SFGMP连接消息。
Type: 33
类型：33
o Burst Duration (32 bits): Optional TLV element that denotes the time the burst will last (in ms), i.e., the difference between the expected transmission times of the first and the last burst packets that the BRS is planning to send in the respective unicast RTP stream. In the absence of additional stimulus, the BRS will
o 突发持续时间（32位）：可选TLV元素，表示突发将持续的时间（毫秒），即BRS计划在各自单播RTP流中发送的第一个和最后一个突发数据包的预期传输时间之差。在没有额外刺激的情况下，BRS将
send a burst of this duration. However, the burst duration can be modified by subsequent events, including changes in the primary multicast stream and reception of RAMS-T messages.
发送此持续时间的突发消息。然而，突发持续时间可由后续事件修改，包括主多播流中的变化和RAMS-T消息的接收。
The BRS MUST terminate the flow in the timeframe indicated by this burst duration or the duration established by those subsequent events even if it does not get a RAMS-T or a BYE message from the RTP_Rx. It is OPTIONAL to send this element in a RAMS-I message when the burst request is accepted. If the burst request has been rejected as indicated in the Response field, this element MAY be omitted or indicate a zero value.
BRS必须在该突发持续时间或这些后续事件确定的持续时间内终止流，即使它没有从RTP_Rx获得RAMS-T或BYE消息。当突发请求被接受时，可以选择在RAMS-I消息中发送此元素。如果如响应字段中所示，突发请求已被拒绝，则可省略该元素或指示零值。
Type: 34
类型：34
o Max Transmit Bitrate (64 bits): Optional TLV element that denotes the maximum bitrate (in bits per second) that will be used by the BRS for the RTP stream associated with this RAMS-I message.
o 最大传输比特率（64位）：可选TLV元素，表示BRS将用于与此RAMS-I消息相关的RTP流的最大比特率（以位/秒为单位）。
Type: 35
类型：35
1xx-Level Response Codes: These response codes are sent for informational purposes.
1xx级别响应代码：发送这些响应代码是为了提供信息。
o 100: This is used when the BRS wants to update a value that was sent earlier to the RTP_Rx.
o 100：当BRS想要更新先前发送到RTP_Rx的值时，使用此选项。
2xx-Level Response Codes: These response codes are sent to indicate success.
2xx级别响应代码：发送这些响应代码表示成功。
o 200: This is used when the server accepts the RAMS request.
o 200：当服务器接受RAMS请求时使用。
o 201: This is used when the unicast burst has been completed and the BRS wants to notify the RTP_Rx.
o 201：当单播突发已完成且BRS想要通知RTP_Rx时，使用此选项。
4xx-Level Response Codes: These response codes are sent to indicate that the message sent by the RTP_Rx is either improperly formatted or contains an invalid value. The rules the RTP_Rx needs to follow upon receiving one of these response codes are outlined in Step 5 in Section 6.2. The 4xx-level response codes are also used as status codes in the Multicast Acquisition Report Block [MULTICAST-ACQ] in order to collect RTP_Rx-based error conditions.
4xx级响应代码：发送这些响应代码是为了表明RTP_Rx发送的消息格式不正确或包含无效值。RTP_Rx在收到其中一个响应代码后需要遵循的规则在第6.2节的步骤5中概述。4xx级响应代码也用作多播采集报告块[Multicast-ACQ]中的状态代码，以收集基于RTP_Rx的错误条件。
o 400: This is used when the RAMS-R message is improperly formatted.
o 400：当RAMS-R消息格式不正确时使用。
o 401: This is used when the minimum RAMS buffer fill requirement value indicated in the RAMS-R message is invalid.
o 401：当RAMS-R消息中指示的最小RAM缓冲区填充要求值无效时，使用此选项。
o 402: This is used when the maximum RAMS buffer fill requirement value indicated in the RAMS-R message is invalid.
o 402：当RAMS-R消息中指示的最大RAMS缓冲区填充要求值无效时使用。
o 403: This is used when the maximum receive bitrate value indicated in the RAMS-R message is insufficient.
o 403：当RAMS-R消息中指示的最大接收比特率值不足时使用。
o 404: This is used when the RAMS-T message is improperly formatted.
o 404：当RAMS-T消息格式不正确时使用此选项。
5xx-Level Response Codes: These response codes are sent to indicate an error on the BRS side. The rules the RTP_Rx needs to follow upon receiving one of these response codes are outlined in Step 3 in Section 6.2. The 5xx-level response codes are also used as status codes in the Multicast Acquisition Report Block [MULTICAST-ACQ] in order to collect BRS-based error conditions.
5xx级响应代码：发送这些响应代码是为了指示BRS侧的错误。RTP_Rx在收到其中一个响应代码后需要遵循的规则在第6.2节的步骤3中概述。5xx级响应代码也用作多播采集报告块[Multicast-ACQ]中的状态代码，以收集基于BRS的错误条件。
o 500: This is used when the BRS has experienced an internal error and cannot accept the RAMS request.
o 500：当BRS遇到内部错误且无法接受RAMS请求时，使用此选项。
o 501: This is used when the BRS does not have enough bandwidth to send the unicast burst stream.
o 501：当BRS没有足够的带宽发送单播突发流时，使用此选项。
o 502: This is used when the BRS terminates the unicast burst stream due to network congestion.
o 502：当BRS由于网络拥塞而终止单播突发流时使用。
o 503: This is used when the BRS does not have enough CPU resources to send the unicast burst stream.
o 503：当BRS没有足够的CPU资源发送单播突发流时，使用此选项。
o 504: This is used when the BRS does not support sending a unicast burst stream.
o 504：当BRS不支持发送单播突发流时，使用此选项。
o 505: This is used when the requesting RTP_Rx is not eligible to receive a unicast burst stream.
o 505：当请求的RTP_Rx不符合接收单播突发流的条件时，使用此选项。
o 506: This is used when RAMS functionality is not enabled for the requested multicast stream.
o 506：当请求的多播流未启用RAMS功能时，使用此选项。
o 507: This is used when the BRS cannot find a valid starting point for the unicast burst stream that satisfies the RTP_Rx's requirements.
o 507：当BRS无法找到满足RTP_Rx要求的单播突发流的有效起始点时，使用此选项。
o 508: This is used when the BRS cannot find the essential reference information for the requested multicast stream.
o 508：当BRS无法找到所请求的多播流的基本参考信息时，使用此选项。
o 509: This is used when the BRS cannot match the requested SSRC to any of the streams it is serving.
o 509：当BRS无法将请求的SSRC与其服务的任何流匹配时，使用此选项。
o 510: This is used when the BRS cannot serve the requested entire session.
o 510：当BRS无法为请求的整个会话提供服务时，使用此选项。
o 511: This is used when the BRS sends only the preamble information but not the whole unicast burst stream.
o 511：当BRS仅发送前导信息而不发送整个单播突发流时，使用该方法。
o 512: This is used when the RAMS request is denied due to a policy for the requested multicast stream, the RTP_Rx, or this particular BRS.
o 512：当RAMS请求由于请求的多播流、RTP_Rx或此特定BRS的策略而被拒绝时，使用此选项。
The RAMS Termination (RAMS-T) message is identified by SFMT=3.
RAMS终止（RAMS-T）消息由SFMT=3标识。
The RAMS Termination is used to assist the BRS in determining when to stop the burst. A separate RAMS-T message is sent in the unicast burst RTP session by the RTP_Rx for each primary multicast stream that has been served by the BRS. Each of these RAMS-T message's media sender SSRC field SHALL BE populated with the SSRC of the media stream to be terminated. If the media sender SSRC populated in the RAMS-T message does not match the SSRC of the burst served by the BRS, BRS SHALL ignore the RAMS-T message.
RAMS终端用于协助BRS确定何时停止突发。RTP_Rx在单播突发RTP会话中为BRS服务的每个主多播流发送单独的RAMS-T消息。每个RAMS-T消息的媒体发送方SSRC字段应填充待终止媒体流的SSRC。如果RAMS-T消息中填充的媒体发送方SSRC与BRS服务的突发的SSRC不匹配，BRS应忽略RAMS-T消息。
If the RTP_Rx wants the BRS to stop a burst prematurely, it sends a RAMS-T message as described below. Upon receiving this message, the BRS stops the respective burst immediately. If the RTP_Rx wants the BRS to terminate all of the bursts, it needs to send all of the respective RAMS-T messages in a single compound RTCP packet.
如果RTP_Rx希望BRS提前停止突发，它将发送一条RAMS-T消息，如下所述。收到此消息后，BRS立即停止相应的突发。如果RTP_Rx希望BRS终止所有突发，则需要在单个复合RTCP数据包中发送所有相应的RAMS-T消息。
The default behavior for the RTP_Rx is to send a RAMS-T message immediately after it joined the multicast session and started receiving multicast packets. In that case, the RTP_Rx includes the sequence number of the first RTP packet received in the primary multicast stream in the RAMS-T message. With this information, the BRS can decide when to terminate the unicast burst.
RTP_Rx的默认行为是在加入多播会话并开始接收多播数据包后立即发送RAMS-T消息。在这种情况下，RTP_Rx在RAMS-T消息中包括在主多播流中接收的第一RTP分组的序列号。利用此信息，BRS可以决定何时终止单播突发。
The FCI field MUST contain only one RAMS Termination. The FCI field has the structure depicted in Figure 9.
FCI字段只能包含一个RAMS终端。FCI字段的结构如图9所示。
The semantics of the RAMS-T message is independent of the payload type carried in the primary multicast RTP session.
RAMS-T消息的语义与主多播RTP会话中承载的有效负载类型无关。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: FCI field syntax for the RAMS Termination message
图9:RAMS终止消息的FCI字段语法
o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional TLV element that specifies the extended RTP sequence number of the first packet received from the SSM session for a particular primary multicast stream. The low 16 bits contain the sequence number of the first packet received from the SSM session, and the most significant 16 bits extend that sequence number with the corresponding count of sequence number cycles, which can be maintained according to the algorithm in Appendix A.1 of [RFC3550].
o 扩展RTP Seqnum of First Multicast Packet（32位）：可选TLV元素，用于指定从SSM会话接收的特定主多播流的第一个数据包的扩展RTP序列号。低16位包含从SSM会话接收的第一个数据包的序列号，最高有效16位将该序列号扩展为相应的序列号周期计数，可根据[RFC3550]附录A.1中的算法进行维护。
Type: 61
类型：61
The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. Here we add the following syntax to the 'rtcp-fb' attribute (the feedback type and optional parameters are all case sensitive):
[RFC4585]中定义了“rtcp fb”属性的语法。在这里，我们将以下语法添加到“rtcp fb”属性中（反馈类型和可选参数都区分大小写）：
(In the following ABNF [RFC5234], rtcp-fb-nack-param is used as defined in [RFC4585].)
（在以下ABNF[RFC5234]中，使用了[RFC4585]中定义的rtcp fb nack参数。）
rtcp-fb-nack-param =/ SP "rai"
rtcp fb nack param=/SP“rai”
The following parameter is defined in this document for use with 'nack':
本文档中定义了以下参数，用于“nack”：
o 'rai' stands for Rapid Acquisition Indication and indicates the use of RAMS messages as defined in Section 7.
o “rai”代表快速采集指示，表示使用第7节中定义的RAMS消息。
This document also defines a new media-level SDP attribute ('rams-updates') that indicates whether or not the BRS supports updated request messages. This attribute is used in a declarative manner and no Offer/Answer Model behavior is specified. If the BRS supports updated request messages and this attribute is included in the SDP description, the RTP_Rx can send updated requests. The BRS might or might not be able to accept value changes in every field in
本文档还定义了一个新的媒体级SDP属性（“rams-updates”），用于指示BRS是否支持更新的请求消息。此属性以声明方式使用，未指定提供/应答模型行为。如果BRS支持更新的请求消息，并且该属性包含在SDP描述中，则RTP_Rx可以发送更新的请求。BRS可能接受也可能无法接受中每个字段的值更改
an updated RAMS-R message. However, if the 'rams-updates' attribute is not included in the SDP description, the RTP_Rx SHALL NOT send updated requests. The RTP_Rx MAY still repeat its initial request without changes, though.
更新的RAMS-R消息。但是，如果SDP描述中未包含“rams更新”属性，RTP_Rx不得发送更新请求。不过，RTP_Rx仍可以重复其初始请求而不做任何更改。
The use of SDP to describe the RAMS entities normatively requires support for:
使用SDP规范性地描述RAMS实体需要支持：
o The SDP grouping framework and flow identification (FID) semantics [RFC5888]
o SDP分组框架和流标识（FID）语义[RFC5888]
o The RTP/AVPF profile [RFC4585]
o RTP/AVPF配置文件[RFC4585]
o The RTP retransmission payload format [RFC4588]
o RTP重传有效负载格式[RFC4588]
o The RTCP extensions for SSM sessions with unicast feedback [RFC5760]
o 具有单播反馈的SSM会话的RTCP扩展[RFC5760]
o The 'multicast-rtcp' attribute [RFC6128]
o “多播rtcp”属性[RFC6128]
o Multiplexing RTP and RTCP on a single port on both endpoints in the unicast session [RFC5761]
o 在单播会话中，在两个端点上的单个端口上多路复用RTP和RTCP[RFC5761]
o The 'portmapping-req' attribute [RFC6284]
o “端口映射请求”属性[RFC6284]
Support for the source-specific media attributes [RFC5576] can also be needed when the 'ssrc' attribute is to be used for the media descriptions.
当“ssrc”属性用于媒体描述时，还需要支持源特定媒体属性[RFC5576]。
This section provides a declarative SDP [RFC4566] example (for the RTP_Rx side) for enabling rapid acquisition of multicast RTP sessions.
本节提供了一个声明性SDP[RFC4566]示例（用于RTP_Rx端），用于快速获取多播RTP会话。
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=Rapid Acquisition Example
t=0 0
a=group:FID 1 2
a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream
c=IN IP4 233.252.0.2/255
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:98 MP2T/90000
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=Rapid Acquisition Example
t=0 0
a=group:FID 1 2
a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream
c=IN IP4 233.252.0.2/255
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:98 MP2T/90000
a=multicast-rtcp:42000
a=rtcp:43000 IN IP4 192.0.2.1
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack rai
a=ssrc:123321 cname:iptv-ch32@rams.example.com
a=rams-updates
a=portmapping-req:54000 IN IP4 192.0.2.1
a=mid:1
m=video 51000 RTP/AVPF 99
i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1
a=sendonly
a=rtpmap:99 rtx/90000
a=rtcp-mux
a=rtcp:51500
a=fmtp:99 apt=98;rtx-time=5000
a=portmapping-req:55000
a=mid:2
a=multicast-rtcp:42000
a=rtcp:43000 IN IP4 192.0.2.1
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack rai
a=ssrc:123321 cname:iptv-ch32@rams.example.com
a=rams-updates
a=portmapping-req:54000 IN IP4 192.0.2.1
a=mid:1
m=video 51000 RTP/AVPF 99
i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1
a=sendonly
a=rtpmap:99 rtx/90000
a=rtcp-mux
a=rtcp:51500
a=fmtp:99 apt=98;rtx-time=5000
a=portmapping-req:55000
a=mid:2
Figure 10: Example SDP for a Single-Channel RAMS Scenario
图10：单通道RAM场景的示例SDP
In this example SDP description, we have a primary multicast (source) stream and a unicast retransmission stream. The source stream is multicast from a distribution source (with a source IP address of 198.51.100.1) to the multicast destination address of 233.252.0.2 and port 41000. The corresponding RTCP traffic is multicast to the same multicast destination address at port 42000. Here, we are assuming that the multicast RTP and RTCP ports are carefully chosen so that different RTP and RTCP streams do not collide with each other.
在这个示例SDP描述中，我们有一个主多播（源）流和一个单播重传流。源流是从分发源（源IP地址为198.51.100.1）到多播目标地址233.252.0.2和端口41000的多播。相应的RTCP通信量多播到端口42000处的同一多播目标地址。这里，我们假设仔细选择了多播RTP和RTCP端口，以便不同的RTP和RTCP流不会相互冲突。
The feedback target (FT_Ap) residing on the RS (with an address of 192.0.2.1) at port 43000 is declared with the "a=rtcp" line [RFC3605]. The support for the conventional retransmission is indicated through the "a=rtcp-fb:98 nack" line. The RTP receiver(s) can report missing packets on the source stream to the feedback target and request retransmissions. The SDP above includes the "a=sendonly" line for the media description of the retransmission stream since the retransmissions are sent in only one direction.
位于端口43000的RS（地址为192.0.2.1）上的反馈目标（FT_Ap）用“a=rtcp”行[RFC3605]声明。通过“a=rtcp fb:98 nack”行表示对传统重传的支持。RTP接收器可以向反馈目标报告源流上丢失的数据包，并请求重新传输。上面的SDP包括用于重传流的媒体描述的“a＝sendonly”行，因为重传仅在一个方向上发送。
The support for rapid acquisition is indicated through the "a=rtcp-fb:98 nack rai" line. The parameter 'rtx-time' applies to both the conventional retransmissions and rapid acquisition. However, when rapid acquisition is enabled, the standard definition for the parameter 'rtx-time' given in [RFC4588] is not followed. Instead, when rapid acquisition support is enabled, 'rtx-time' specifies the time in milliseconds that the BRS keeps an RTP packet in its cache
通过“a=rtcp fb:98 nack rai”行显示对快速采集的支持。参数“rtx时间”适用于常规重传和快速捕获。但是，当启用快速采集时，不遵循[RFC4588]中给出的参数“rtx时间”的标准定义。相反，当启用快速采集支持时，“rtx时间”指定BRS在其缓存中保留RTP数据包的时间（以毫秒为单位）
available for retransmission (measured from the time the packet was received by the BRS, not from the time indicated in the packet timestamp).
可用于重传（从BRS接收数据包的时间开始测量，而不是从数据包时间戳中指示的时间开始测量）。
Once an RTP_Rx has acquired an SDP description, it can ask for rapid acquisition before it joins a primary multicast RTP session. To do so, it sends a RAMS-R message to the feedback target of that primary multicast RTP session. If the FT_Ap is associated with only one RTP stream, the RTP_Rx does not need to learn the SSRC of that stream via an out-of-band method. If the BRS accepts the rapid acquisition request, it will send a RAMS-I message with the correct SSRC identifier. If the FT_Ap is associated with a multi-stream RTP session and the RTP_Rx is willing to request rapid acquisition for the entire session, the RTP_Rx again does not need to learn the SSRCs via an out-of-band method. However, if the RTP_Rx intends to request a particular subset of the primary multicast streams, it must learn their SSRC identifiers and list them in the RAMS-R message. Since this RTP_Rx has not yet received any RTP packets for the primary multicast stream(s), the RTP_Rx must in this case learn the SSRC value(s) from the 'ssrc' attribute of the media description [RFC5576]. In addition to the SSRC value, the 'cname' source attribute must also be present in the SDP description [RFC5576].
一旦RTP_Rx获得SDP描述，它可以在加入主多播RTP会话之前请求快速获取。为此，它向该主多播RTP会话的反馈目标发送RAMS-R消息。如果FT_Ap仅与一个RTP流相关联，则RTP_Rx不需要通过带外方法学习该流的SSRC。如果BRS接受快速采集请求，它将发送带有正确SSRC标识符的RAMS-I消息。如果FT_Ap与多流RTP会话相关联，并且RTP_Rx愿意为整个会话请求快速捕获，则RTP_Rx再次不需要通过带外方法学习ssrc。然而，如果RTP_Rx打算请求主多播流的特定子集，它必须学习它们的SSRC标识符并在RAMS-R消息中列出它们。由于该RTP_Rx尚未收到主多播流的任何RTP数据包，因此在这种情况下，RTP_Rx必须从媒体描述的“SSRC”属性中学习SSRC值[RFC5576]。除SSRC值外，“cname”源属性还必须出现在SDP描述中[RFC5576]。
Listing the SSRC values for the primary multicast streams in the SDP file does not create a problem in SSM sessions when an SSRC collision occurs. This is because in SSM sessions, an RTP_Rx that observed an SSRC collision with a media sender must change its own SSRC [RFC5760] by following the rules defined in [RFC3550].
当SSRC冲突发生时，在SDP文件中列出主多播流的SSRC值不会在SSM会话中产生问题。这是因为在SSM会话中，观察到与媒体发送器发生SSRC冲突的RTP_Rx必须按照[RFC3550]中定义的规则更改其自身的SSRC[RFC5760]。
A feedback target that receives a RAMS-R message becomes aware that the RTP_Rx wants to rapidly catch up with a primary multicast RTP session. If the necessary conditions are satisfied (as outlined in Section 7 of [RFC4585]) and available resources exist, the BRS can react to the RAMS-R message by sending any transport-layer (and optional payload-specific, when allowed) feedback message(s) and starting the unicast burst.
接收RAMS-R消息的反馈目标意识到RTP_Rx想要快速赶上主多播RTP会话。如果满足必要条件（如[RFC4585]第7节所述）且存在可用资源，则BRS可通过发送任何传输层（以及允许时的可选有效负载特定）反馈消息并启动单播突发来对RAMS-R消息作出反应。
In this section, we considered the simplest scenario where the primary multicast RTP session carried only one stream and the RTP_Rx wanted to rapidly acquire this stream only. Best practices for scenarios where the primary multicast RTP session carries two or more streams or the RTP_Rx wants to acquire one or more streams from multiple primary multicast RTP sessions at the same time are presented in [RAMS-SCENARIOS].
在本节中，我们考虑了最简单的场景，其中主多播RTP会话仅承载一个流，而RTP_Rx只希望快速获取该流。主多播RTP会话承载两个或多个流或RTP_Rx希望同时从多个主多播RTP会话获取一个或多个流的场景的最佳实践在[RAMS-scenarios]中介绍。
For a variety of reasons, one or more Network Address Port Translators (NAPT, hereafter simply called NAT) can exist between the RTP_Rx and RS. NATs have a variety of operating characteristics for UDP traffic [RFC4787]. For a NAT to permit traffic from the BRS to arrive at the RTP_Rx, the NAT(s) must first either:
由于各种原因，RTP_Rx和RS之间可能存在一个或多个网络地址端口转换器（NAPT，以下简称NAT）。NAT具有UDP流量的各种操作特征[RFC4787]。为了使NAT允许来自BRS的流量到达RTP_Rx，NAT必须首先：
a. See UDP (or DCCP) traffic sent from the RTP_Rx (which is on the 'inside' of the NAT) to the BRS (which is on the 'outside' of the NAT). This traffic has the same transport address as the subsequent response traffic, or
a. 请参阅从RTP_Rx（位于NAT的“内部”）发送到BRS（位于NAT的“外部”）的UDP（或DCCP）流量。此通信与后续响应通信具有相同的传输地址，或
b. Be configured to forward certain ports (e.g., using HTML configuration or Universal Plug and Play (UPnP) Internet Gateway Device (IGD) [UPnP-IGD]). Details of this are out of the scope of this document.
b. 被配置为转发某些端口（例如，使用HTML配置或通用即插即用（UPnP）互联网网关设备（IGD）[UPnP IGD]）。这方面的详细信息不在本文件的范围内。
For both (a) and (b), the RTP_Rx is responsible for maintaining the NAT's state if it wants to receive traffic from the BRS on that port. For (a), the RTP_Rx MUST send UDP traffic to keep the NAT binding alive, at least every 30 seconds [RFC4787]. While (a) is more like an automatic/dynamic configuration, (b) is more like a manual/static configuration.
对于（a）和（b），如果RTP_Rx想要从该端口上的BRS接收流量，则RTP_Rx负责维护NAT的状态。对于（a），RTP_Rx必须至少每30秒发送一次UDP通信量以保持NAT绑定活动[RFC4787]。虽然（a）更像是自动/动态配置，（b）更像是手动/静态配置。
When the RTP_Rx sends a request (RAMS-R) message to the FT as unicast feedback in the primary multicast RTP session and the request is received by the FT, a new unicast burst RTP session will be established between the BRS and RTP_Rx.
当RTP_Rx在主多播RTP会话中向FT发送请求（RAMS-R）消息作为单播反馈，并且FT接收到该请求时，将在BRS和RTP_Rx之间建立新的单播突发RTP会话。
While the FT and BRS ports on the RS are already signaled via out-of-band means (e.g., SDP), the RTP_Rx needs to convey the RTP and RTCP ports it wants to use on its side for the new session. Since there are two RTP sessions (one multicast and one unicast) involved during this process and one of them is established upon a feedback message sent in the other one, this requires an explicit port mapping method.
当RS上的FT和BRS端口已经通过带外方式（例如SDP）发出信号时，RTP_Rx需要传输其希望在其一侧用于新会话的RTP和RTCP端口。由于此过程中涉及两个RTP会话（一个多播和一个单播），并且其中一个会话是根据另一个会话中发送的反馈消息建立的，因此需要显式端口映射方法。
Applications using RAMS MUST support the method presented in [RFC6284] both on the RS and RTP_Rx side to allow RTP receivers to use their desired ports and to support RAMS behind NAT devices. The port mapping message exchange needs to take place whenever the RTP_Rx intends to make use of the RAMS protocol for rapidly acquiring a specific multicast RTP session prior to joining the associated SSM session.
使用RAM的应用程序必须在RS和RTP_Rx端支持[RFC6284]中介绍的方法，以允许RTP接收器使用其所需端口，并支持NAT设备后面的RAM。只要RTP_Rx打算利用RAMS协议在加入相关SSM会话之前快速获取特定多播RTP会话，就需要进行端口映射消息交换。
Applications that are using RAMS make heavy use of the unicast feedback mechanism described in [RFC5760], the payload format defined in [RFC4588], and the port mapping solution specified in [RFC6284]. Thus, these applications are subject to the general security considerations discussed in those documents. In particular, the threats and risks discussed in [RFC5760] need to be considered carefully. In this section, we give an overview of the guidelines and suggestions described in these specifications from a RAMS perspective. We also discuss the security considerations that explicitly apply to applications using RAMS.
使用RAM的应用程序大量使用[RFC5760]中描述的单播反馈机制、[RFC4588]中定义的有效负载格式以及[RFC6284]中指定的端口映射解决方案。因此，这些应用程序受这些文件中讨论的一般安全考虑的约束。特别是，需要仔细考虑[RFC5760]中讨论的威胁和风险。在本节中，我们从RAMS的角度概述了这些规范中描述的指南和建议。我们还讨论了明确适用于使用RAM的应用程序的安全注意事项。
First of all, much of the session description information is available in the SDP descriptions that are distributed to the media senders, retransmission servers, and RTP receivers. Adequate security measures are RECOMMENDED to ensure the integrity and authenticity of the SDP descriptions so that transport addresses of the media senders, distribution sources, feedback targets, and other session-specific information can be protected. See [RFC4566] for details.
首先，大部分会话描述信息在分发给媒体发送方、重传服务器和RTP接收方的SDP描述中可用。建议采取适当的安全措施，以确保SDP描述的完整性和真实性，从而保护媒体发件人、分发源、反馈目标和其他特定于会话的信息的传输地址。详见[RFC4566]。
Compared to an RTCP NACK message that triggers one or more retransmissions, a RAMS Request (RAMS-R) message can trigger a new burst stream to be sent by the retransmission server. Depending on the application-specific requirements and conditions existing at the time of the RAMS-R reception by the retransmission server, the resulting burst stream can potentially contain a large number of retransmission packets. Since these packets are sent faster than the nominal rate, RAMS consumes more resources on the retransmission servers, RTP receivers, and the network. In particular, this can make denial-of-service (DoS) attacks more intense and hence more harmful than attacks that target ordinary retransmission sessions.
与触发一次或多次重传的RTCP NACK消息相比，RAMS请求（RAMS-R）消息可以触发重传服务器发送的新突发流。根据重发服务器在RAMS-R接收时存在的应用特定需求和条件，产生的突发流可能包含大量重发分组。由于这些数据包的发送速度快于标称速率，因此RAM会消耗重传服务器、RTP接收器和网络上的更多资源。特别是，这会使拒绝服务（DoS）攻击比针对普通重传会话的攻击更激烈，因此危害更大。
As RAMS messages are sent as RTCP messages, counter-measures SHOULD be taken to prevent tampered or spoofed RTCP packets, following the suggestions given in [RFC4588]. Tampered RAMS-R messages can trigger inappropriate burst streams or alter the existing burst streams in an inappropriate way. For example, if the Max Receive Bitrate field is altered by a tampered RAMS-R message, the updated burst can overflow the buffer at the receiver side or, oppositely, can slow down the burst to the point that it becomes useless. Tampered RAMS Termination (RAMS-T) messages can terminate valid burst streams prematurely resulting in gaps in the received RTP packets. RAMS Information (RAMS-I) messages contain fields that are critical for a successful rapid acquisition. Any tampered information in the RAMS-I message can easily cause an RTP receiver to make wrong decisions. Consequently, the RAMS operation can fail.
由于RAMS消息以RTCP消息的形式发送，因此应按照[RFC4588]中给出的建议，采取反措施防止篡改或欺骗RTCP数据包。被篡改的RAMS-R消息可能触发不适当的突发流，或以不适当的方式改变现有的突发流。例如，如果最大接收比特率字段被篡改的RAMS-R消息更改，则更新的突发可能会使接收器端的缓冲区溢出，或者相反，会使突发变慢到无用的程度。篡改RAMS终止（RAMS-T）消息可提前终止有效的突发流，从而导致接收到的RTP数据包出现间隙。RAMS信息（RAMS-I）消息包含对成功快速采集至关重要的字段。RAMS-I消息中的任何篡改信息都很容易导致RTP接收器做出错误的决定。因此，RAMS操作可能会失败。
RTCP BYE messages are similar to RAMS-T messages in the sense that they can be used to stop an existing burst. The CNAME of an RTP receiver is used to bind the RTCP BYE message to an existing burst. Thus, one should be careful if the CNAMEs are reasonably easy to guess and off-path attacks can be performed. Also note that the CNAMEs might be redistributed to all participants in the multicast group (as in ASM or the simple feedback model of [RFC5760]).
RTCP BYE消息与RAMS-T消息类似，因为它们可用于停止现有突发。RTP接收器的CNAME用于将RTCP BYE消息绑定到现有突发。因此，如果CNAMEs相当容易猜测，并且可以执行非路径攻击，则应小心。还请注意，CNAMEs可能会重新分配给多播组中的所有参与者（如ASM或[RFC5760]的简单反馈模型）。
The retransmission server has to consider if values indicated in a RAMS-R message are reasonable. For example, a request demanding a large value of many seconds in the Min RAMS Buffer Fill Requirement element should, unless special use cases exist, likely be rejected since it is likely to be an attempt to prolong a DoS attack on the retransmission server, RTP receiver, and/or the network. The Max Receive Bitrate could also be set to a very large value to try to get the retransmission server to cause massive congestion by bursting at a bitrate that will not be supported by the network. An RTP_Rx should also consider if the values for the Earliest Multicast Join Time and Burst Duration indicated by the retransmission server in a RAMS-I message are reasonable. For example, if the burst packets stop arriving and the join time is still significantly far into the future, this could be a sign of a man-in-the-middle attack where the RAMS-I message has been manipulated by an attacker.
重传服务器必须考虑RAMS R消息中所指示的值是否合理。例如，除非存在特殊用例，否则在最小RAM缓冲区填充要求元素中要求大量秒数的请求可能会被拒绝，因为这可能是试图延长对重传服务器、RTP接收器和/或网络的DoS攻击。最大接收比特率也可以设置为一个非常大的值，试图使重传服务器以网络不支持的比特率崩溃，从而造成大规模拥塞。RTPYRX也应该考虑RAMS I消息中重传服务器所指示的最早多播加入时间和突发持续时间的值是否合理。例如，如果突发数据包停止到达，且加入时间仍远未到来，则这可能是中间人攻击的迹象，其中RAMS-I消息已被攻击者操纵。
A basic mitigation against DoS attacks introduced by an attacker injecting tampered RAMS messages is source address validation [RFC2827]. Also, most of the DoS attacks can be prevented by the integrity and authenticity checks enabled by Secure RTP (SRTP) [RFC3711]. However, an attack can still be started by legitimate endpoints that send several valid RAMS-R messages to a particular feedback target in a synchronized fashion and in a very short amount of time. Since a RAMS operation can temporarily consume a large amount of resources, a series of the RAMS-R messages can temporarily overload the retransmission server. In these circumstances, the retransmission server can, for example, reject incoming RAMS requests until its resources become available again. One means to ameliorate this threat is to apply a per-endpoint policing mechanism on the incoming RAMS requests. A reasonable policing mechanism should consider application-specific requirements and minimize false negatives.
针对攻击者注入被篡改的RAMS消息而引入的DoS攻击的一个基本缓解措施是源地址验证[RFC2827]。此外，大多数DoS攻击可以通过安全RTP（SRTP）[RFC3711]启用的完整性和真实性检查来防止。但是，合法端点仍然可以启动攻击，这些端点以同步方式在极短时间内向特定反馈目标发送多条有效RAMS-R消息。由于RAMS操作可能会临时消耗大量资源，一系列RAMS-R消息可能会临时使重传服务器过载。在这些情况下，重传服务器例如可以拒绝传入的RAMS请求，直到其资源再次可用。改善这种威胁的一种方法是对传入的RAMS请求应用每端点策略机制。合理的警务机制应考虑应用特定要求和尽量减少假阴性。
In addition to the DoS attacks, man-in-the-middle and replay attacks will also be harmful. RAMS-R messages do not carry any information that allows the retransmission server to detect duplication or replay attacks. Thus, the possibility of a replay attack using a captured valid RAMS-R message exists unless a mitigation method such as Secure RTCP (SRTCP) is used. Similarly, RAMS-T messages can be replayed. The RAMS-I has a sequence number that makes replay attacks less
除了拒绝服务攻击，中间人攻击和重播攻击也将是有害的。RAMS-R消息不包含允许重传服务器检测重复或重播攻击的任何信息。因此，除非使用安全RTCP（SRTCP）等缓解方法，否则存在使用捕获的有效RAMS-R消息进行重放攻击的可能性。同样，RAMS-T消息也可以重播。RAMS-I有一个序列号，可以减少重播攻击
likely but not impossible. Man-in-the-middle attacks that are capable of capturing, injecting, or modifying the RAMS messages can easily accomplish the attacks described above. Thus, cryptographic integrity and authentication is the only reliable protection. To protect the RTCP messages from man-in-the-middle and replay attacks, the RTP receivers and retransmission server SHOULD perform a Datagram Transport Layer Security (DTLS)-SRTP handshake [RFC5764] over the RTCP channel. Because there is no integrity-protected signaling channel between an RTP receiver and the retransmission server, the retransmission server MUST maintain a list of certificates owned by legitimate RTP receivers, or their certificates MUST be signed by a trusted Certificate Authority. Once the DTLS-SRTP security is established, non-SRTCP-protected messages received from a particular RTP receiver are ignored by the retransmission server. To reduce the impact of DTLS-SRTP overhead when communicating with different feedback targets on the same retransmission server, it is RECOMMENDED that RTP receivers and the retransmission server both support TLS Session Resumption without Server-side State [RFC5077]. To help scale SRTP to handle many RTP receivers asking for retransmissions of identical data, implementors may consider using the same SRTP key for SRTP data sent to the receivers [SRTP-EKT] and be aware that such key sharing allows those receivers to impersonate the sender. Thus, source address validation remains important.
可能，但并非不可能。能够捕获、注入或修改RAMS消息的中间人攻击可以轻松完成上述攻击。因此，密码完整性和身份验证是唯一可靠的保护。为了保护RTCP消息免受中间人攻击和重播攻击，RTP接收器和重传服务器应通过RTCP通道执行数据报传输层安全（DTLS）-SRTP握手[RFC5764]。由于RTP接收器和重传服务器之间没有完整性保护的信令通道，重传服务器必须维护合法RTP接收器拥有的证书列表，或者其证书必须由可信证书颁发机构签名。一旦DTLS-SRTP安全性建立，从特定RTP接收器接收的非SRTCP保护消息将被重传服务器忽略。为了减少在同一重传服务器上与不同反馈目标通信时DTLS-SRTP开销的影响，建议RTP接收器和重传服务器都支持TLS会话恢复，而无需服务器端状态[RFC5077]。为了帮助缩放SRTP来处理许多请求相同数据重传的RTP接收机，实现者可以考虑使用SRTP密钥发送给接收者[SRTP-EKT]的SRTP密钥，并且意识到这样的密钥共享允许那些接收者模拟发送者。因此，源地址验证仍然很重要。
[RFC4588] RECOMMENDS that cryptography mechanisms be used for the retransmission payload format to provide protection against known plain-text attacks. As discussed in [RFC4588], the retransmission payload format sets the timestamp field in the RTP header to the media timestamp of the original packet, and this does not compromise the confidentiality. Furthermore, if cryptography is used to provide security services on the original stream, then the same services, with equivalent cryptographic strength, MUST be provided on the retransmission stream per [RFC4588].
[RFC4588]建议将加密机制用于重传有效负载格式，以提供针对已知纯文本攻击的保护。如[RFC4588]中所述，重传有效负载格式将RTP报头中的时间戳字段设置为原始分组的媒体时间戳，并且这不会损害机密性。此外，如果使用加密技术在原始流上提供安全服务，则必须根据[RFC4588]在重传流上提供具有同等加密强度的相同服务。
Finally, a retransmission server that has become subverted by an attacker is almost impossible to protect against as such a server can perform a large number of different actions to deny service to receivers.
最后，被攻击者破坏的重传服务器几乎不可能受到保护，因为这样的服务器可以执行大量不同的操作来拒绝向接收方提供服务。
The following contact information is used for all registrations in this document:
以下联系信息用于本文档中的所有注册：
Ali Begen abegen@cisco.com
阿里出生abegen@cisco.com
Note that the "RAMS" (value 2) in the Multicast Acquisition Method Registry refers to the method described in Section 6 of this document.
请注意，多播获取方法注册表中的“RAMS”（值2）指的是本文件第6节中描述的方法。
This document registers a new attribute name in SDP.
此文档在SDP中注册一个新的属性名称。
SDP Attribute ("att-field"): Attribute name: rams-updates Long form: Support for Updated RAMS Request Messages Type of name: att-field Type of attribute: Media level Subject to charset: No Purpose: See this document Reference: [RFC6285] Values: None
SDP属性（“att字段”）：属性名称：rams更新长格式：支持更新的rams请求消息名称类型：att字段属性类型：媒体级别取决于字符集：无目的：请参阅此文档参考：[RFC6285]值：无
This document registers a new value for the 'nack' attribute to be used with the 'rtcp-fb' attribute in SDP. For more information about the 'rtcp-fb' attribute, refer to Section 4.2 of [RFC4585].
本文档为“nack”属性注册了一个新值，用于SDP中的“rtcp fb”属性。有关“rtcp fb”属性的更多信息，请参阅[RFC4585]的第4.2节。
Value name: rai Long name: Rapid Acquisition Indication Usable with: nack Reference: [RFC6285]
值名称：rai长名称：可用于nack参考的快速采集指示：[RFC6285]
Within the RTPFB range, the following format (FMT) value is registered:
在RTPFB范围内，注册以下格式（FMT）值：
Name: RAMS Long name: Rapid Acquisition of Multicast Sessions Value: 6 Reference: [RFC6285]
名称：RAMS长名称：快速获取多播会话值：6参考：[RFC6285]
This document creates a new sub-registry for the sub-feedback message type (SFMT) values to be used with the FMT value registered for RAMS messages. The registry is called the SFMT Values for RAMS Messages Registry. This registry is managed by the IANA according to the Specification Required policy of [RFC5226].
本文档为子反馈消息类型（SFMT）值创建一个新的子注册表，该值将与为RAMS消息注册的FMT值一起使用。该注册表称为RAMS消息注册表的SFMT值。该注册表由IANA根据[RFC5226]的规范要求策略进行管理。
The length of the SFMT field in the RAMS messages is a single octet, allowing 256 values. The registry is initialized with the following entries:
RAMS消息中SFMT字段的长度为单个八位字节，允许256个值。注册表使用以下项进行初始化：
Value Name Reference
----- -------------------------------------------------- ------------
0 Reserved [RFC6285]
1 RAMS Request [RFC6285]
2 RAMS Information [RFC6285]
3 RAMS Termination [RFC6285]
4-254 Unassigned - Specification Required
255 Reserved [RFC6285]
Value Name Reference
----- -------------------------------------------------- ------------
0 Reserved [RFC6285]
1 RAMS Request [RFC6285]
2 RAMS Information [RFC6285]
3 RAMS Termination [RFC6285]
4-254 Unassigned - Specification Required
255 Reserved [RFC6285]
The SFMT values 0 and 255 are reserved for future use.
SFMT值0和255保留供将来使用。
Any registration for an unassigned SFMT value needs to contain the following information:
未分配SFMT值的任何注册都需要包含以下信息：
o Contact information of the one doing the registration, including at least name, address, and email.
o 注册人的联系信息，至少包括姓名、地址和电子邮件。
o A detailed description of what the new SFMT represents and how it shall be interpreted.
o 详细说明新SFMT代表的内容以及应如何解释。
New RAMS functionality is intended to be introduced by using the extension mechanism within the existing RAMS message types not by introducing new message types unless it is absolutely necessary.
新的RAMS功能旨在通过在现有RAMS消息类型中使用扩展机制而不是通过引入新的消息类型来引入，除非是绝对必要的。
This document creates a new IANA TLV space registry for the RAMS extensions. The registry is called the RAMS TLV Space Registry. This registry is managed by the IANA according to the Specification Required policy of [RFC5226].
本文档为RAMS扩展创建一个新的IANA TLV空间注册表。该注册表称为RAMS TLV空间注册表。该注册表由IANA根据[RFC5226]的规范要求策略进行管理。
The length of the Type field in the TLV elements is a single octet, allowing 256 values. The Type values 0 and 255 are reserved for future use. The Type values between (and including) 128 and 254 are reserved for private extensions.
TLV元素中类型字段的长度为单个八位字节，允许256个值。类型值0和255保留供将来使用。介于（包括）128和254之间的类型值保留给专用扩展。
The registry is initialized with the following entries:
注册表使用以下项进行初始化：
Type Description Reference
---- ----------------------------------------------- -------------
0 Reserved [RFC6285]
1 Requested Media Sender SSRC(s) [RFC6285]
2 Min RAMS Buffer Fill Requirement [RFC6285]
3 Max RAMS Buffer Fill Requirement [RFC6285]
4 Max Receive Bitrate [RFC6285]
5 Request for Preamble Only [RFC6285]
6 Supported Enterprise Number(s) [RFC6285]
7-30 Unassigned - Specification Required
31 Media Sender SSRC [RFC6285]
32 RTP Seqnum of the First Packet [RFC6285]
33 Earliest Multicast Join Time [RFC6285]
34 Burst Duration [RFC6285]
35 Max Transmit Bitrate [RFC6285]
36-60 Unassigned - Specification Required
61 Extended RTP Seqnum of First Multicast Packet [RFC6285]
62-127 Unassigned - Specification Required
128-254 Reserved for Private Use
255 Reserved [RFC6285]
Type Description Reference
---- ----------------------------------------------- -------------
0 Reserved [RFC6285]
1 Requested Media Sender SSRC(s) [RFC6285]
2 Min RAMS Buffer Fill Requirement [RFC6285]
3 Max RAMS Buffer Fill Requirement [RFC6285]
4 Max Receive Bitrate [RFC6285]
5 Request for Preamble Only [RFC6285]
6 Supported Enterprise Number(s) [RFC6285]
7-30 Unassigned - Specification Required
31 Media Sender SSRC [RFC6285]
32 RTP Seqnum of the First Packet [RFC6285]
33 Earliest Multicast Join Time [RFC6285]
34 Burst Duration [RFC6285]
35 Max Transmit Bitrate [RFC6285]
36-60 Unassigned - Specification Required
61 Extended RTP Seqnum of First Multicast Packet [RFC6285]
62-127 Unassigned - Specification Required
128-254 Reserved for Private Use
255 Reserved [RFC6285]
Any registration for an unassigned Type value needs to contain the following information:
未分配类型值的任何注册都需要包含以下信息：
o Contact information of the one doing the registration, including at least name, address, and email.
o 注册人的联系信息，至少包括姓名、地址和电子邮件。
o A detailed description of what the new TLV element represents and how it shall be interpreted.
o 新TLV元素代表的内容以及应如何解释的详细说明。
This document creates a new IANA TLV space registry for the RAMS response codes. The registry is called the RAMS Response Code Space Registry. This registry is managed by the IANA according to the Specification Required policy of [RFC5226].
本文档为RAMS响应代码创建一个新的IANA TLV空间注册表。该注册表称为RAMS响应代码空间注册表。该注册表由IANA根据[RFC5226]的规范要求策略进行管理。
The length of the Response field is two octets, allowing 65536 codes. However, in this document, the response codes have been classified and registered following an HTTP-style code numbering. New response codes should be classified following the guidelines below:
响应字段的长度为两个八位字节，允许65536个代码。然而，在本文件中，响应代码已按照HTTP样式代码编号进行分类和注册。新的响应代码应按照以下指南进行分类：
Code Level Purpose
---------- ---------------
1xx Informational
2xx Success
3xx Redirection
4xx RTP Receiver (RTP_Rx) Error
5xx Burst/Retransmission Source (BRS) Error
Code Level Purpose
---------- ---------------
1xx Informational
2xx Success
3xx Redirection
4xx RTP Receiver (RTP_Rx) Error
5xx Burst/Retransmission Source (BRS) Error
The Response code 65535 is reserved for future use.
响应代码65535保留供将来使用。
The registry is initialized with the following entries:
注册表使用以下项进行初始化：
Code Description Reference
----- -------------------------------------------------- ------------
0 A private response code is included in the message [RFC6285]
Code Description Reference
----- -------------------------------------------------- ------------
0 A private response code is included in the message [RFC6285]
100 Parameter update for RAMS session [RFC6285]
RAMS会话的100参数更新[RFC6285]
200 RAMS request has been accepted [RFC6285] 201 Unicast burst has been completed [RFC6285]
200 RAMS请求已被接受[RFC6285]201单播突发已完成[RFC6285]
400 Invalid RAMS-R message syntax [RFC6285]
401 Invalid min buffer requirement in RAMS-R message [RFC6285]
402 Invalid max buffer requirement in RAMS-R message [RFC6285]
403 Insufficient max bitrate requirement in RAMS-R
message [RFC6285]
404 Invalid RAMS-T message syntax [RFC6285]
400 Invalid RAMS-R message syntax [RFC6285]
401 Invalid min buffer requirement in RAMS-R message [RFC6285]
402 Invalid max buffer requirement in RAMS-R message [RFC6285]
403 Insufficient max bitrate requirement in RAMS-R
message [RFC6285]
404 Invalid RAMS-T message syntax [RFC6285]
500 An unspecified BRS internal error has occurred [RFC6285]
501 BRS has insufficient bandwidth to start RAMS
session [RFC6285]
502 Burst is terminated due to network congestion [RFC6285]
503 BRS has insufficient CPU cycles to start RAMS
session [RFC6285]
504 RAMS functionality is not available on BRS [RFC6285]
505 RAMS functionality is not available for RTP_Rx [RFC6285]
506 RAMS functionality is not available for
the requested multicast stream [RFC6285]
507 BRS has no valid starting point available for
the requested multicast stream [RFC6285]
508 BRS has no reference information available for
the requested multicast stream [RFC6285]
509 BRS has no RTP stream matching the requested SSRC [RFC6285]
510 RAMS request to acquire the entire session
has been denied [RFC6285]
511 Only the preamble information is sent [RFC6285]
512 RAMS request has been denied due to a policy [RFC6285]
500 An unspecified BRS internal error has occurred [RFC6285]
501 BRS has insufficient bandwidth to start RAMS
session [RFC6285]
502 Burst is terminated due to network congestion [RFC6285]
503 BRS has insufficient CPU cycles to start RAMS
session [RFC6285]
504 RAMS functionality is not available on BRS [RFC6285]
505 RAMS functionality is not available for RTP_Rx [RFC6285]
506 RAMS functionality is not available for
the requested multicast stream [RFC6285]
507 BRS has no valid starting point available for
the requested multicast stream [RFC6285]
508 BRS has no reference information available for
the requested multicast stream [RFC6285]
509 BRS has no RTP stream matching the requested SSRC [RFC6285]
510 RAMS request to acquire the entire session
has been denied [RFC6285]
511 Only the preamble information is sent [RFC6285]
512 RAMS request has been denied due to a policy [RFC6285]
Any registration for an unassigned Response code needs to contain the following information:
未分配响应代码的任何注册都需要包含以下信息：
o Contact information of the one doing the registration, including at least name, address, and email.
o 注册人的联系信息，至少包括姓名、地址和电子邮件。
o A detailed description of what the new Response code describes and how it shall be interpreted.
o 新响应代码描述的内容以及解释方式的详细说明。
Dave Oran, Magnus Westerlund, and Colin Perkins have contributed significantly to this specification by providing text and solutions to some of the issues raised during the development of this specification.
Dave Oran、Magnus Westerlund和Colin Perkins对本规范做出了重大贡献，他们为本规范开发过程中提出的一些问题提供了文本和解决方案。
The following individuals reviewed earlier versions of this specification and provided helpful comments: Joerg Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox, Jose Rey, Sean Sheedy, and Keith Drage.
以下人员审查了本规范的早期版本，并提供了有用的意见：Joerg Ott、Roni Even、Dan Wing、Tony Faustini、Peilin Yang、Jeff Goldberg、Muriel Deschanel、Orit Levin、Guy Hirson、Tom Taylor、Xavier Marjou、Ye Kui Wang、Zixuan Zou、Ingemar Johansson、Haibin Song、Ning Zong、Jonathan Lennox、Jose Rey、，肖恩·希迪和基思·德雷奇。
[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月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[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月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605]Huitema，C.，“会话描述协议（SDP）中的实时控制协议（RTCP）属性”，RFC3605，2003年10月。
[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月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[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月。
[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月。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[RFC4604]Holbrook，H.，Cain，B.，和B.Haberman，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，2006年8月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，2008年1月。
[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月。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008.
[RFC5285]Singer，D.和H.Desneni，“RTP标头扩展的一般机制”，RFC 5285，2008年7月。
[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月。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.
[RFC5576]Lennox，J.，Ott，J.，和T.Schierl，“会话描述协议（SDP）中的源特定媒体属性”，RFC 55762009年6月。
[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月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路传输RTP数据和控制数据包”，RFC 5761，2010年4月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，2010年5月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，2010年6月。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.
[RFC6051]Perkins，C.和T.Schierl，“RTP流的快速同步”，RFC 60512010年11月。
[RFC6128] Begen, A., "RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions", RFC 6128, February 2011.
[RFC6128]Begen，A.，“源特定多播（SSM）会话的RTP控制协议（RTCP）端口”，RFC 61282011年2月。
[RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping Between Unicast and Multicast RTP Sessions", RFC 6284, June 2011.
[RFC6284]Begen，A.，Wing，D.，和T.Van Caenegem，“单播和多播RTP会话之间的端口映射”，RFC 62842011年6月。
[ECN-FOR-RTP] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", Work in Progress, May 2011.
[ECN-FOR-RTP]Westerlund，M.，Johansson，I.，Perkins，C.，O'Hanlon，P.，和K.Carlberg，“UDP上RTP的显式拥塞通知（ECN）”，正在进行的工作，2011年5月。
[IC2009] Begen, A., Glazebrook, N., and W. Ver Steeg, "Reducing Channel Change Times in IPTV with Real-Time Transport Protocol (IEEE Internet Computing)", May 2009.
[IC2009]Begen，A.，Glazebrook，N.，和W.Ver Steeg，“使用实时传输协议（IEEE互联网计算）减少IPTV中的频道切换时间”，2009年5月。
[MULTICAST-ACQ] Begen, A. and E. Friedrich, "Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", Work in Progress, May 2011.
[MULTICAST-ACQ]Begen，A.和E.Friedrich，“RTP控制协议（RTCP）扩展报告（XRs）的多播采集报告块类型”，正在进行的工作，2011年5月。
[RAMS-SCENARIOS] Begen, A., "Considerations and Guidelines for Deploying the Rapid Acquisition of Multicast Sessions (RAMS) Method", Work in Progress, June 2011.
[RAMS-SCENARIOS]Begen，A.，“部署快速获取多播会话（RAMS）方法的注意事项和指南”，正在进行的工作，2011年6月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", RFC 5762, April 2010.
[RFC5762]Perkins，C.，“RTP和数据报拥塞控制协议（DCCP）”，RFC 5762，2010年4月。
[RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)", RFC 6015, October 2010.
[RFC6015]Begen，A.，“用于1-D交错奇偶校验前向纠错（FEC）的RTP有效载荷格式”，RFC6015，2010年10月。
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 6222, April 2011.
[RFC6222]Begen，A.，Perkins，C.，和D.Wing，“选择RTP控制协议（RTCP）规范名称（CNAMEs）的指南”，RFC 6222，2011年4月。
[SRTP-EKT] McGrew, D., Andreasen, F., Wing, D., and K. Fischer, "Encrypted Key Transport for Secure RTP", Work in Progress, March 2011.
[SRTP-EKT]McGrew，D.，Andreasen，F.，Wing，D.，和K.Fischer，“安全RTP的加密密钥传输”，正在进行的工作，2011年3月。
[UPnP-IGD] UPnP Forum, "Universal Plug and Play (UPnP) Internet Gateway Device (IGD)", December 2010.
[UPnP IGD]UPnP论坛，“通用即插即用（UPnP）互联网网关设备（IGD）”，2010年12月。
Authors' Addresses
作者地址
Bill Ver Steeg Cisco 5030 Sugarloaf Parkway Lawrenceville, GA 30044 USA
美国佐治亚州劳伦斯维尔Sugarloaf公园路5030号，邮编30044
EMail: billvs@cisco.com
EMail: billvs@cisco.com
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco位于加拿大多伦多湾街181号M5J 2T3
EMail: abegen@cisco.com
EMail: abegen@cisco.com
Tom Van Caenegem Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
2018年比利时安特卫普50号汤姆·范·凯恩杰姆阿尔卡特-朗讯哥白尼公司
EMail: Tom.Van_Caenegem@alcatel-lucent.be
EMail: Tom.Van_Caenegem@alcatel-lucent.be
Zeev Vax Magnum Semiconductor, Inc. 591 Yosemite Drive Milpitas, CA 95035 USA
Zeev Vax Magnum半导体公司，美国加利福尼亚州约塞米蒂大道591号，米尔皮塔斯，邮编95035
EMail: zeev.vax@magnumsemi.com
EMail: zeev.vax@magnumsemi.com