Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 7198 Cisco
Category: Standards Track C. Perkins
ISSN: 2070-1721 University of Glasgow
April 2014
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 7198 Cisco
Category: Standards Track C. Perkins
ISSN: 2070-1721 University of Glasgow
April 2014
Duplicating RTP Streams
复制RTP流
Abstract
摘要
Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules.
对于实时多媒体会话来说，数据包丢失是不可取的，但由于各种原因（包括计划外的网络中断）可能会发生数据包丢失。在单播传输中，由于丢失数据包的数量可能很大，因此根据中断持续时间，从此类中断中恢复可能会很困难。在多播传输中，恢复更具挑战性，因为许多接收器可能会受到中断的影响。对于这个挑战，一个不会产生无界延迟的解决方案是复制数据包并在独立的冗余流中发送它们，前提是底层网络满足某些要求。本文档解释了如何在不破坏RTP或RTP控制协议（RTCP）规则的情况下复制实时传输协议（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/rfc7198.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7198.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Requirements Notation . . . . . . . . . . . . 4
3. Use Cases for Dual Streaming . . . . . . . . . . . . . . . . 4
3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 4
3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 5
3.3. Dual Streaming over a Single Path or Multiple Paths . . . 5
3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 7
4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 7
4.2. Signaling Considerations . . . . . . . . . . . . . . . . 7
5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 8
5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 9
5.2. Signaling Considerations . . . . . . . . . . . . . . . . 9
6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 10
7. Congestion Control Considerations . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Requirements Notation . . . . . . . . . . . . 4
3. Use Cases for Dual Streaming . . . . . . . . . . . . . . . . 4
3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 4
3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 5
3.3. Dual Streaming over a Single Path or Multiple Paths . . . 5
3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 7
4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 7
4.2. Signaling Considerations . . . . . . . . . . . . . . . . 7
5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 8
5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 9
5.2. Signaling Considerations . . . . . . . . . . . . . . . . 9
6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 10
7. Congestion Control Considerations . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
The Real-time Transport Protocol (RTP) [RFC3550] is widely used today for delivering IPTV traffic and other real-time multimedia sessions. Many of these applications support very large numbers of receivers and rely on intra-domain UDP/IP multicast for efficient distribution of traffic within the network.
实时传输协议（RTP）[RFC3550]目前广泛用于传输IPTV流量和其他实时多媒体会话。其中许多应用程序支持大量的接收器，并依靠域内UDP/IP多播在网络内高效地分配流量。
While this combination has proved successful, there does exist a weakness. As [RFC2354] noted, packet loss is not avoidable. This loss might be due to congestion; it might also be a result of an unplanned outage caused by a flapping link, a link or interface failure, a software bug, or a maintenance person accidentally cutting the wrong fiber. Since UDP/IP flows do not provide any means for detecting loss and retransmitting packets, it is left up to the RTP layer and the applications to detect, and recover from, packet loss.
虽然这一组合被证明是成功的，但确实存在一个弱点。正如[RFC2354]所指出的，数据包丢失是无法避免的。这种损失可能是由于交通拥挤造成的；这也可能是由于链路抖动、链路或接口故障、软件错误或维护人员意外切断错误光纤而导致的意外中断。由于UDP/IP流不提供任何检测丢失和重新传输数据包的方法，因此由RTP层和应用程序来检测和恢复数据包丢失。
In a carefully managed network, congestion should not normally happen; however, network outages can still happen due to the reasons listed above. In such a managed network, one technique to recover from packet loss without incurring unbounded delay is to duplicate the packets and send them in separate redundant streams. As described later in this document, the probability that two copies of the same packet are lost in cases of non-congestive packet loss is quite small.
在精心管理的网络中，拥塞通常不会发生；但是，由于上述原因，网络中断仍然可能发生。在这样一个受管理的网络中，从数据包丢失中恢复而不产生无界延迟的一种技术是复制数据包并在单独的冗余流中发送它们。如本文后面所述，在非拥塞性分组丢失的情况下，相同分组的两个副本丢失的概率非常小。
Variations on this idea have been implemented and deployed today [IC2011]. However, duplication of RTP streams without breaking the RTP and RTCP functionality has not been documented properly. This document discusses the most common use cases and explains how duplication can be achieved for RTP streams in such use cases to address the immediate market needs. In the future, if there will be a different use case that is not covered by this document, a new specification that explains how RTP duplication should be done in such a scenario may be needed.
这一理念的变体已经在今天实施和部署[IC2011]。但是，在不破坏RTP和RTCP功能的情况下复制RTP流的情况没有得到适当的记录。本文档讨论了最常见的用例，并解释了如何在此类用例中实现RTP流的复制，以满足当前的市场需求。将来，如果本文档未涵盖不同的用例，则可能需要一个新的规范来解释在这种情况下如何进行RTP复制。
Stream duplication offers a simple way to protect media flows from packet loss. It has a comparatively high overhead in terms of bandwidth, since everything is sent twice, but with a low overhead in terms of processing. It is also very predictable in its overheads. Alternative approaches, for example, retransmission-based recovery [RFC4588] or Forward Error Correction [RFC6363], may be suitable in some other cases.
流复制提供了一种保护媒体流免受数据包丢失的简单方法。就带宽而言，它的开销相对较高，因为所有内容都发送两次，但在处理方面的开销较低。它的管理费用也是可以预测的。替代方法，例如，基于重传的恢复[RFC4588]或前向纠错[RFC6363]，可能适用于某些其他情况。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Dual streaming refers to a technique that involves transmitting two redundant RTP streams (the original plus its duplicate) of the same content, with each stream capable of supporting the playback when there is no packet loss. Therefore, adding an additional RTP stream provides a protection against packet loss. The level of protection depends on how the packets are sent and transmitted inside the network.
双流是指一种技术，涉及传输相同内容的两个冗余RTP流（原始流加上其副本），每个流能够在没有数据包丢失的情况下支持播放。因此，添加额外的RTP流可以防止数据包丢失。保护级别取决于数据包在网络内的发送和传输方式。
It is important to note that dual streaming can easily be extended to support cases when more than two streams are desired. However, using three or more streams is rare in practice, due to the high overhead that it incurs and the little additional protection it provides.
需要注意的是，当需要两个以上的流时，可以轻松地扩展双流以支持这种情况。然而，在实践中很少使用三个或更多的流，因为它会带来高开销，并且提供的额外保护很少。
From a routing perspective, two streams are considered identical if the following two IP header fields are the same (in addition to the transport ports), since they will be both routed over the same path:
从路由角度来看，如果以下两个IP头字段相同（除了传输端口），则认为两个流是相同的，因为它们都将通过相同的路径路由：
o IP Source Address
o IP源地址
o IP Destination Address
o IP目的地址
Two routing-plane identical RTP streams might carry the same payload but can use different Synchronization Sources (SSRCs) to differentiate the RTP packets belonging to each stream. In the context of dual RTP streaming, we assume that the sender duplicates the RTP packets and sends them in separate RTP streams, each with a unique SSRC. All the redundant streams are transmitted in the same RTP session.
两个路由平面相同的RTP流可能携带相同的负载，但可以使用不同的同步源（SSRC）来区分属于每个流的RTP包。在双RTP流的上下文中，我们假设发送方复制RTP数据包并在单独的RTP流中发送它们，每个RTP流具有唯一的SSRC。所有冗余流在同一RTP会话中传输。
For example, one main stream and its duplicate stream can be sent to the same IP destination address and UDP destination port with a certain delay between them [RFC7197]. The streams carry the same payload in their respective RTP packets with identical sequence numbers. This allows receivers (or other nodes responsible for gap filling and duplicate suppression) to identify and suppress the
例如，一个主流及其复制流可以发送到相同的IP目标地址和UDP目标端口，两者之间有一定的延迟[RFC7197]。流在其各自的RTP分组中携带相同的有效负载，并且具有相同的序列号。这允许接收器（或负责间隙填充和重复抑制的其他节点）识别和抑制
duplicate packets, and subsequently produce a hopefully loss-free and duplication-free output stream. This process is commonly called "stream merging" or "de-duplication".
复制数据包，然后产生一个无丢失和无重复的输出流。此过程通常称为“流合并”或“重复数据消除”。
An RTP source might be associated with multiple network interfaces, allowing it to send two redundant streams from two separate source addresses. Such streams can be routed over diverse or identical paths, depending on the routing algorithm used inside the network. At the receiving end, the node responsible for duplicate suppression can look into various RTP header fields, for example, SSRC and sequence number, to identify and suppress the duplicate packets.
RTP源可能与多个网络接口相关联，允许它从两个单独的源地址发送两个冗余流。这些流可以通过不同或相同的路径进行路由，这取决于网络内部使用的路由算法。在接收端，负责重复抑制的节点可以查看各种RTP报头字段，例如SSRC和序列号，以识别和抑制重复分组。
If source-specific multicast (SSM) transport is used to carry such redundant streams, there will be a separate SSM session for each redundant stream since the streams are sourced from different interfaces (i.e., IP addresses). Thus, the receiving host has to join each SSM session separately.
如果使用源特定多播（SSM）传输来承载这些冗余流，则每个冗余流将有一个单独的SSM会话，因为这些流来自不同的接口（即IP地址）。因此，接收主机必须单独加入每个SSM会话。
Alternatively, the destination host could also have multiple IP addresses for an RTP source to send the redundant streams to.
或者，目标主机还可以为RTP源提供多个IP地址，以便将冗余流发送到该RTP源。
Having described the characteristics of the streams, one can reach the following conclusions:
描述了流的特征后，可以得出以下结论：
1. When two routing-plane identical streams are used, the flow labels will be the same. This makes it impractical to forward the packets onto different paths. In order to minimize packet loss, the packets belonging to one stream are often interleaved with packets belonging to its duplicate stream, and with a delay, so that if there is a packet loss, such a delay would allow the same packet from the duplicate stream to reach the receiver because the chances that the same packet is lost in transit again are often small. This is what is also known as "time-shifted redundancy", "temporal redundancy" or simply "delayed duplication" [RFC7197] [IC2011]. This approach can be used with both types of dual streaming, described in Sections 3.1 and 3.2.
1. 当使用两个路由平面相同的流时，流标签将相同。这使得将数据包转发到不同的路径是不切实际的。为了最小化分组丢失，属于一个流的分组通常与属于其重复流的分组交织，并且具有延迟，因此如果存在分组丢失，这种延迟将允许来自重复流的相同分组到达接收器，因为相同分组在传输中再次丢失的机会通常很小。这就是所谓的“时移冗余”、“时间冗余”或简单的“延迟复制”[RFC7197][IC2011]。该方法可用于第3.1节和第3.2节所述的两种类型的双流。
2. If the two streams have different IP headers, an additional opportunity arises in that one is able to build a network, with physically diverse paths, to deliver the two streams concurrently to the intended receivers. This reduces the delay when packet loss occurs and needs to be recovered. Additionally, it also further reduces chances for packet loss. An unrecoverable loss happens only when two network failures happen in such a way that
2. 如果这两个流具有不同的IP报头，则另一个机会出现在其中一个流能够构建具有物理上不同路径的网络，以将这两个流并发地交付给预期的接收器。这减少了数据包丢失发生和需要恢复时的延迟。此外，它还进一步减少了数据包丢失的机会。只有当两次网络故障以如下方式发生时，才会发生无法恢复的损失：
the same packet is affected on both paths. This is referred to as Spatial Diversity or Spatial Redundancy [IC2011]. The techniques used to build diverse paths are beyond the scope of this document.
同一数据包在两条路径上都受影响。这被称为空间多样性或空间冗余[IC2011]。用于构建不同路径的技术超出了本文档的范围。
Note that spatial redundancy often offers less delay in recovering from packet loss, provided that the forwarding delay of the network paths are more or less the same. (This is often ensured through careful network design.) For both temporal and spatial redundancy approaches, packet misordering might still happen and needs to be handled using the sequence numbers of some sort (e.g., RTP sequence numbers).
注意，如果网络路径的转发延迟大致相同，则空间冗余通常在从分组丢失中恢复时提供较少的延迟。（这通常通过仔细的网络设计来确保。）对于时间和空间冗余方法，仍然可能发生数据包错序，需要使用某种序列号（例如RTP序列号）来处理。
Temporal and spatial redundancy deal with different patterns of packet loss. The former helps with transient loss (within the duplication window), while the latter helps with longer-term packet loss that affects only one of the two redundant paths.
时间和空间冗余处理不同的数据包丢失模式。前者有助于暂时性丢失（在复制窗口内），而后者有助于长期数据包丢失（仅影响两条冗余路径中的一条）。
To summarize, dual streaming allows an application and a network to work together to provide a near-zero-loss transport with a bounded or minimum delay. The additional advantage includes a predictable bandwidth overhead that is proportional to the minimum bandwidth needed for the multimedia session, but independent of the number of receivers experiencing a packet loss and requesting a retransmission. For a survey and comparison of similar approaches, refer to [IC2011].
总之，双流允许应用程序和网络协同工作，以有限或最小的延迟提供接近零的传输损耗。额外的优点包括可预测的带宽开销，该带宽开销与多媒体会话所需的最小带宽成比例，但与经历分组丢失和请求重传的接收器的数量无关。有关类似方法的调查和比较，请参阅[IC2011]。
One of the following conditions is currently REQUIRED to hold in applications using this specification:
在使用本规范的应用中，目前需要满足以下条件之一：
o The original and duplicate RTP streams are carried (with their own SSRCs) in the same "m" line. (There could be other RTP streams listed in the same "m" line.)
o 原始和重复的RTP流（带有它们自己的SSRC）在同一条“m”线上传输。（可能有其他RTP流列在同一“m”行中。）
o The original and duplicate RTP streams are carried in separate "m" lines, and there is no other RTP stream listed in either "m" line.
o 原始和重复的RTP流在单独的“m”行中进行，并且在任一“m”行中都没有列出其他RTP流。
When the original and duplicate RTP streams are carried in separate "m" lines in a Session Description Protocol (SDP) description and if the SDP description has one or more other RTP streams listed in either "m" line, duplication grouping is not trivial and further signaling will be needed; this is left for future standardization.
当在会话描述协议（SDP）描述中在单独的“m”行中携带原始和复制RTP流时，并且如果SDP描述在任一“m”行中列出了一个或多个其他RTP流，则复制分组不是微不足道的，并且将需要进一步的信令；这是留给未来的标准化。
To achieve temporal redundancy, the main and duplicate RTP streams SHOULD be sent using the sample 5-tuple of transport protocol, source and destination IP addresses, and source and destination transport ports. Due to the possible presence of network address and port translation (NAPT) devices, load balancers, or other middleboxes, use of anything other than an identical 5-tuple and flow label might also cause spatial redundancy (which might introduce an additional delay due to the delta between the path delays), and so it is NOT RECOMMENDED unless the path is known to be free of such middleboxes.
为了实现时间冗余，应使用传输协议、源和目标IP地址以及源和目标传输端口的样本5元组发送主RTP流和重复RTP流。由于可能存在网络地址和端口转换（NAPT）设备、负载平衡器或其他中间盒，使用相同的5元组和流标签以外的任何东西也可能导致空间冗余（这可能由于路径延迟之间的增量而引入额外延迟），因此，除非已知路径中没有此类中间盒，否则不建议使用。
Since the main and duplicate RTP streams follow an identical path, they are part of the same RTP session. Accordingly, the sender MUST choose a different SSRC for the duplicate RTP stream than it chose for the main RTP stream, following the rules in Section 8 of [RFC3550].
由于主RTP流和复制RTP流遵循相同的路径，因此它们是同一RTP会话的一部分。因此，发送方必须按照[RFC3550]第8节中的规则，为重复RTP流选择与为主RTP流选择不同的SSRC。
If RTCP is being sent for the main RTP stream, then the sender MUST also generate RTCP for the duplicate RTP stream. The RTCP for the duplicate RTP stream is generated exactly as if the duplicate RTP stream were a regular media stream. The sender MUST NOT duplicate the RTCP packets sent for the main RTP stream when sending the duplicate stream; instead, it MUST generate new RTCP reports for the duplicate stream. The sender MUST use the same RTCP CNAME in the RTCP reports it sends for both streams, so that the receiver can synchronize them.
如果为主RTP流发送RTCP，则发送方还必须为重复RTP流生成RTCP。复制RTP流的RTCP的生成与复制RTP流是常规媒体流的生成完全相同。发送复制流时，发送方不得复制为主RTP流发送的RTCP数据包；相反，它必须为重复流生成新的RTCP报告。发送方必须在为两个流发送的RTCP报告中使用相同的RTCP CNAME，以便接收方可以同步它们。
The main and duplicate streams are conceptually synchronized using the standard mechanism based on RTCP Sender Reports, deriving a mapping between their timelines. However, the RTP timestamps and sequence numbers MUST be identical in the main and duplicate streams, making the mapping quite trivial.
主流和复制流在概念上是使用基于RTCP发送方报告的标准机制进行同步的，从而导出其时间线之间的映射。但是，RTP时间戳和序列号在主流和重复流中必须相同，这使得映射非常简单。
Both the main and duplicate RTP streams, and their corresponding RTCP reports, will be received. If RTCP is used, receivers MUST generate RTCP reports for both the main and duplicate streams in the usual way, treating them as entirely separate media streams.
将接收主RTP流和复制RTP流及其相应的RTCP报告。如果使用RTCP，接收器必须以通常的方式为主流和复制流生成RTCP报告，将其视为完全独立的媒体流。
Signaling is needed to allow the receiver to determine that an RTP stream is a duplicate of another, rather than a separate stream that needs to be rendered in parallel. There are two parts to this: an SDP extension is needed in the offer/answer exchange to negotiate support for temporal redundancy; and signaling is needed to indicate
需要信令来允许接收机确定RTP流是另一个流的副本，而不是需要并行呈现的单独流。这有两个部分：在提供/应答交换中需要SDP扩展来协商对时间冗余的支持；需要信号来指示
which stream is the duplicate. (The latter can be done in-band using an RTCP extension or out-of-band in the SDP description.)
哪个流是重复的。（后者可以使用RTCP扩展在带内完成，也可以在SDP说明中的带外完成。）
Out-of-band signaling is needed for both features. The SDP attribute to signal duplication in the SDP offer/answer exchange ('duplication-delay') is defined in [RFC7197]. The required SDP grouping semantics are defined in [RFC7104].
这两种功能都需要带外信令。SDP提供/应答交换中信号复制的SDP属性（“复制延迟”）在[RFC7197]中定义。[RFC7104]中定义了所需的SDP分组语义。
In the following SDP example, a video stream is duplicated, and the main and duplicate streams are transmitted in two separate SSRCs (1000 and 1010):
在以下SDP示例中，复制视频流，并且在两个单独的ssrc（1000和1010）中发送主和复制流：
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1a@example.com
a=ssrc:1010 cname:ch1a@example.com
a=ssrc-group:DUP 1000 1010
a=duplication-delay:50
a=mid:Ch1
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1a@example.com
a=ssrc:1010 cname:ch1a@example.com
a=ssrc-group:DUP 1000 1010
a=duplication-delay:50
a=mid:Ch1
Section 3.2 of [RFC7104] states that it is advisable that the SSRC listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is sent first, with the other SSRC (i.e., SSRC of 1010) being the time-delayed duplicate. This is not critical, however, and a receiving host should size its playout buffer based on the 'duplication-delay' attribute and play the stream that arrives first in preference, with the other stream acting as a repair stream, irrespective of the order in which they are signaled.
[RFC7104]第3.2节指出，建议首先发送“a=SSRC组：”行中首先列出的SSRC（即SSRC为1000），另一个SSRC（即SSRC为1010）为延时副本。但是，这并不重要，接收主机应根据“复制延迟”属性调整其播放缓冲区的大小，并优先播放首先到达的流，而另一个流作为修复流，而不考虑它们的信号发送顺序。
Assuming the network is structured appropriately, when using spatial redundancy, the duplicate RTP stream is sent using a different source and/or destination address/port pair. This will be a separate RTP session from the session conveying the main RTP stream. Thus, the SSRCs used for the main and duplicate streams MUST be chosen randomly, following the rules in Section 8 of [RFC3550]. Accordingly, they will almost certainly not match each other. The sender MUST, however, use the same RTCP CNAME for both the main and duplicate streams. An "a=group:DUP" line or "a=ssrc-group:DUP" line is used to indicate duplication.
假设网络结构适当，当使用空间冗余时，使用不同的源和/或目标地址/端口对发送重复的RTP流。这将是一个独立于传输主RTP流的会话的RTP会话。因此，必须按照[RFC3550]第8节中的规则随机选择用于主流和重复流的SSRC。因此，它们几乎肯定不会相互匹配。但是，发送方必须对主流和复制流使用相同的RTCP CNAME。“a=group:DUP”行或“a=ssrc group:DUP”行用于指示重复。
If RTCP is being sent for the main RTP stream, then the sender MUST also generate RTCP for the duplicate RTP stream. The RTCP for the duplicate RTP stream is generated exactly as if the duplicate RTP stream were a regular media stream. The sender MUST NOT duplicate the RTCP packets sent for the main RTP stream when sending the duplicate stream; instead, it MUST generate new RTCP reports for the duplicate stream. The sender MUST use the same RTCP CNAME in the RTCP reports it sends for both streams, so that the receiver can synchronize them.
如果为主RTP流发送RTCP，则发送方还必须为重复RTP流生成RTCP。复制RTP流的RTCP的生成与复制RTP流是常规媒体流的生成完全相同。发送复制流时，发送方不得复制为主RTP流发送的RTCP数据包；相反，它必须为重复流生成新的RTCP报告。发送方必须在为两个流发送的RTCP报告中使用相同的RTCP CNAME，以便接收方可以同步它们。
The main and duplicate streams are conceptually synchronized using the standard mechanism based on RTCP Sender Reports, deriving a mapping between their timelines. However, the RTP timestamps and sequence numbers MUST be identical in the main and duplicate streams, making the mapping quite trivial.
主流和复制流在概念上是使用基于RTCP发送方报告的标准机制进行同步的，从而导出其时间线之间的映射。但是，RTP时间戳和序列号在主流和重复流中必须相同，这使得映射非常简单。
Both the main and duplicate RTP streams, and their corresponding RTCP reports, will be received. If RTCP is used, receivers MUST generate RTCP reports for both the main and duplicate streams in the usual way, treating them as entirely separate media streams.
将接收主RTP流和复制RTP流及其相应的RTCP报告。如果使用RTCP，接收器必须以通常的方式为主流和复制流生成RTCP报告，将其视为完全独立的媒体流。
The required SDP grouping semantics have been defined in [RFC7104]. In the following example, the redundant streams have different IP destination addresses. The example shows the same UDP port number and IP source address for each stream, but either or both could have been different for the two streams.
[RFC7104]中定义了所需的SDP分组语义。在以下示例中，冗余流具有不同的IP目标地址。该示例显示了每个流的相同UDP端口号和IP源地址，但两个流中的一个或两个可能不同。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
a=group:DUP S1a S1b
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=mid:S1a
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:101 MP2T/90000
a=mid:S1b
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
a=group:DUP S1a S1b
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=mid:S1a
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:101 MP2T/90000
a=mid:S1b
This uses the same RTP/RTCP mechanisms from Sections 4 and 5, plus a combination of signaling provided in each of these sections.
这使用了第4节和第5节中相同的RTP/RTCP机制，加上这些章节中提供的信令组合。
Duplicating RTP streams has several considerations in the context of congestion control. First of all, RTP duplication MUST NOT be used in cases where the primary cause of packet loss is congestion since duplication can make congestion only worse. Furthermore, RTP duplication SHOULD NOT be used where there is a risk of congestion upon duplicating an RTP stream. Duplication is RECOMMENDED only to be used for protection against network outages due to a temporary link or network element failure and where it is known (e.g., through explicit operator configuration) that there is sufficient network capacity to carry the duplicated traffic. The capacity requirement constrains the use of duplication to managed networks and makes it unsuitable for use on unmanaged public networks.
在拥塞控制的上下文中，复制RTP流有几个考虑因素。首先，在数据包丢失的主要原因是拥塞的情况下，不能使用RTP复制，因为复制只会使拥塞更加严重。此外，如果复制RTP流时存在拥塞风险，则不应使用RTP复制。建议复制仅用于防止由于临时链路或网元故障而导致的网络中断，并且已知（例如，通过明确的操作员配置）有足够的网络容量承载复制的流量。容量要求限制了复制到受管网络的使用，使其不适合在非受管公共网络上使用。
It is essential that the nodes responsible for the duplication and de-duplication are aware of the original stream's requirements and the available capacity inside the network. If there is an adaptation capability for the original stream, these nodes have to assume the same adaptation capability for the duplicated stream, too. For example, if the source doubles the bitrate for the original stream, the bitrate of the duplicate stream will also be doubled.
负责复制和重复数据消除的节点必须了解原始流的要求和网络内的可用容量。如果原始流具有自适应能力，则这些节点也必须对复制流具有相同的自适应能力。例如，如果源将原始流的比特率加倍，则复制流的比特率也将加倍。
Depending on where de-duplication takes place, there could be different scenarios. When the duplication and de-duplication take place inside the network before the ultimate endpoints that will consume the RTP media, the whole process is transparent to these endpoints. Thus, these endpoints will apply any congestion control, if applicable, on the de-duplicated RTP stream. This output stream will have fewer losses than either the original or duplicated stream will have, and the endpoint will make congestion control decisions accordingly. However, if de-duplication takes place at the ultimate endpoint, this endpoint MUST consider the aggregate of the original and duplicated RTP stream in any congestion control it wants to apply. The endpoint will observe the losses in each stream separately, and this information can be used to fine-tune the duplication process. For example, the duplication interval can be adjusted based on the duration of a common packet loss in both streams. In these scenarios, the RTP Monitoring Framework [RFC6792] can be used to monitor the duplicated streams in the same way an ordinary RTP would be monitored.
根据重复数据消除发生的位置，可能会出现不同的情况。当复制和重复数据消除发生在网络内部，而最终端点将使用RTP介质时，整个过程对这些端点是透明的。因此，这些端点将对消除重复的RTP流应用任何拥塞控制（如果适用）。该输出流将比原始流或复制流具有更少的损失，并且端点将相应地做出拥塞控制决策。然而，如果在最终端点发生重复复制，则该端点必须考虑原始和复制RTP流的集合，以便在其想要应用的任何拥塞控制中考虑。端点将分别观察每个流中的损失，此信息可用于微调复制过程。例如，可以基于两个流中的公共分组丢失的持续时间来调整复制间隔。在这些场景中，RTP监控框架[RFC6792]可用于监控复制流，监控方式与普通RTP相同。
The security considerations of [RFC3550], [RFC7104], [RFC7197], and any RTP profiles and payload formats in use apply.
[RFC3550]、[RFC7104]、[RFC7197]以及使用中的任何RTP配置文件和有效负载格式的安全注意事项适用。
Duplication can be performed end-to-end, with the media sender generating a duplicate RTP stream, and the receiver(s) performing de-duplication. In such cases, if the original media stream is to be authenticated (e.g., using Secure RTP (SRTP) [RFC3711]), then the duplicate stream also needs to be authenticated, and duplicate packets that fail the authentication check need to be discarded.
复制可以端到端执行，媒体发送方生成重复的RTP流，接收方执行重复数据消除。在这种情况下，如果要对原始媒体流进行身份验证（例如，使用安全RTP（SRTP）[RFC3711]），则还需要对重复流进行身份验证，并且需要丢弃未通过身份验证检查的重复数据包。
Stream duplication and de-duplication can also be performed by in-network middleboxes. Such middleboxes will need to rewrite the RTP SSRC such that the RTP packets in the duplicate stream have a different SSRC to the original stream, and such middleboxes will need to generate and respond to RTCP packets corresponding to the duplicate stream. This sort of in-network duplication service has the potential to act as an amplifier for denial-of-service attacks if the attacker can cause attack traffic to be duplicated. To prevent this, middleboxes providing the duplication service need to authenticate the traffic to be duplicated as being from a legitimate source, for example, using the SRTP profile [RFC3711]. This requires the middlebox to be part of the security context of the media session being duplicated, so it has access to the necessary keying material for authentication. To do this, the middlebox will need to be privy to the session setup signaling. Details of how that is done will depend on the type of signaling used (SIP, Real Time Streaming Protocol (RTSP), WebRTC, etc.), and is not specified here.
流复制和重复数据消除也可以通过网络中间盒执行。此类中间盒将需要重写RTP SSRC，以便复制流中的RTP分组具有与原始流不同的SSRC，并且此类中间盒将需要生成并响应与复制流相对应的RTCP分组。如果攻击者能够复制攻击流量，这种网络内复制服务有可能成为拒绝服务攻击的放大器。为了防止这种情况，提供复制服务的中间盒需要验证要复制的流量是否来自合法来源，例如，使用SRTP配置文件[RFC3711]。这要求中间盒是被复制媒体会话的安全上下文的一部分，因此它可以访问必要的密钥材料进行身份验证。要做到这一点，中间盒需要知道会话设置信令。如何完成的细节将取决于所使用的信令类型（SIP、实时流协议（RTSP）、WebRTC等），此处未指定。
Similarly, to prevent packet injection attacks, a de-duplication middlebox needs to authenticate original and duplicate streams, and ought not use non-authenticated packets that are received. Again, this requires the middlebox to be part of the security context and to have access to the appropriate signaling and keying material.
类似地，为了防止数据包注入攻击，重复数据消除中间盒需要对原始流和重复流进行身份验证，并且不应使用接收到的未经身份验证的数据包。同样，这要求中间盒是安全上下文的一部分，并且能够访问适当的信令和密钥材料。
The use of the encryption features of SRTP does not affect stream de-duplication middleboxes, since the RTP headers are sent in the clear.
使用SRTP的加密功能不会影响重复数据流消除中间件，因为RTP报头以明文形式发送。
Thanks to Magnus Westerlund for his suggestions.
感谢马格纳斯·韦斯特隆德的建议。
[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月。
[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月。
[RFC7197] Begen, A., Cai, Y., and H. Ou, "Duplication Delay Attribute in the Session Description Protocol", RFC 7197, April 2014.
[RFC7197]Begen，A.，Cai，Y.，和H.Ou，“会话描述协议中的复制延迟属性”，RFC 7197，2014年4月。
[RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping Semantics in the Session Description Protocol", RFC 7104, January 2014.
[RFC7104]Begen，A.，Cai，Y.，和H.Ou，“会话描述协议中的复制分组语义”，RFC 7104，2014年1月。
[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月。
[RFC2354] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[RFC2354]Perkins，C.和O.Hodson，“修复流媒体的选项”，RFC 2354，1998年6月。
[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月。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6363]Watson，M.，Begen，A.，和V.Roca，“前向纠错（FEC）框架”，RFC6363，2011年10月。
[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", RFC 6792, November 2012.
[RFC6792]Wu，Q.，Hunt，G.，和P.Arden，“RTP监控框架的使用指南”，RFC 6792，2012年11月。
[IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, "Toward Lossless Video Transport", IEEE Internet Computing, Vol. 15, No. 6, pp. 48-57, November 2011.
[IC2011]Evans，J.，Begen，A.，Greengrass，J.，和C.Filsfils，“朝向无损视频传输”，IEEE互联网计算，第15卷，第6期，第48-57页，2011年11月。
Authors' Addresses
作者地址
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
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ UK
柯林帕金斯格拉斯哥大学计算科学学院格拉斯哥G128QQ英国
EMail: csp@csperkins.org
URI: http://csperkins.org/
EMail: csp@csperkins.org
URI: http://csperkins.org/