Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 7197 Cisco
Category: Standards Track Y. Cai
ISSN: 2070-1721 Microsoft
H. Ou
Cisco
April 2014
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 7197 Cisco
Category: Standards Track Y. Cai
ISSN: 2070-1721 Microsoft
H. Ou
Cisco
April 2014
Duplication Delay Attribute in the Session Description Protocol
会话描述协议中的复制延迟属性
Abstract
摘要
A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as "time-shifted redundancy", "temporal redundancy", or simply "delayed duplication". This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol.
为防止由于网络中断而导致的数据包丢失（最长持续时间为T个时间单位），一种简单的方法是复制原始数据包，并发送至少间隔T个时间单位的每个副本。这种方法通常被称为“时移冗余”、“时间冗余”或简单的“延迟复制”。本文档定义了一个属性，用于指示会话描述协议中存在临时冗余媒体流和复制延迟。
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/rfc7197.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7197.
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 ....................................................2
2. Requirements Notation ...........................................4
3. The 'duplication-delay' Attribute ...............................5
4. SDP Examples ....................................................6
5. Security Considerations .........................................7
6. IANA Considerations .............................................8
6.1. Registration of SDP Attributes .............................9
7. Acknowledgements ................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
1. Introduction ....................................................2
2. Requirements Notation ...........................................4
3. The 'duplication-delay' Attribute ...............................5
4. SDP Examples ....................................................6
5. Security Considerations .........................................7
6. IANA Considerations .............................................8
6.1. Registration of SDP Attributes .............................9
7. Acknowledgements ................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
Inside an IP network, packet delivery may be interrupted due to failure of a physical link, interface, or device. To reduce the impact of such interruptions, some networks are built in a resilient manner, allowing for multiple alternative paths between two endpoints. However, if there is no resiliency in the network or the failure happens in a non-resilient part of the network, a temporary outage will occur (i.e., packets will get dropped). The outage will last until network reconvergence takes place (i.e., until connectivity is restored) around the failure. Typically, network reconvergence takes between tens and hundreds of milliseconds, depending on the size and features of the network.
在IP网络内，由于物理链路、接口或设备的故障，数据包传送可能会中断。为了减少此类中断的影响，一些网络以弹性的方式构建，允许在两个端点之间使用多条备选路径。但是，如果网络中没有弹性，或者故障发生在网络的非弹性部分，则将发生临时中断（即，数据包将被丢弃）。中断将持续到故障周围发生网络重新聚合（即，直到连接恢复）。通常，根据网络的大小和功能，网络重新聚合需要几十到几百毫秒。
There are a number of network-reconvergence technologies available today, such as IP Fast Convergence, MPLS Traffic Engineering Fast Reroute, and Multicast Only Fast Reroute. These technologies can be augmented by different types of application-layer loss-repair methods such as Forward Error Correction (FEC), retransmission, temporal
目前有许多网络再聚合技术可用，如IP快速聚合、MPLS流量工程快速重路由和仅组播快速重路由。这些技术可以通过不同类型的应用层丢失修复方法来增强，如前向纠错（FEC）、重传、时态恢复等
redundancy, and spatial redundancy to minimize (and sometimes totally eliminate) the impact of outages. Each combination has its distinct requirements in terms of bandwidth consumption and results in a different network complexity. Thus, a network operator has to carefully consider what combination to deploy for different parts of a network (e.g., core vs. edge). A detailed overview of network-convergence technologies and loss-repair methods is provided in [IC2011].
冗余和空间冗余，以最小化（有时完全消除）停机的影响。每种组合在带宽消耗方面都有其独特的要求，并导致不同的网络复杂性。因此，网络运营商必须仔细考虑为网络的不同部分（例如，核心与边缘）部署什么组合。[IC2011]提供了网络融合技术和损耗修复方法的详细概述。
One of the loss-repair methods is temporal redundancy, also known as delayed duplication. A media sender using this method transmits an original source packet and transmits its duplicate after a certain delay following the original transmission. If a network outage hits the original transmission, the expectation is that the second transmission arrives at the receiver (with a high probability). Alternatively, the second transmission may be hit by an outage and so gets dropped, and the original transmission completes successfully. Also, both transmissions can arrive on the receiver side; in that case, the receiver (or the node that does the duplicate suppression) needs to identify the duplicate packets and discard them appropriately, thereby producing a duplicate-free stream.
丢失修复方法之一是时间冗余，也称为延迟复制。使用此方法的媒体发送器发送原始源数据包，并在原始传输后经过一定延迟后发送其副本。如果网络中断影响到原始传输，则期望第二次传输到达接收器（概率很高）。或者，第二次传输可能受到中断的影响，因此被丢弃，并且原始传输成功完成。而且，两个传输都可以到达接收机侧；在这种情况下，接收器（或执行重复抑制的节点）需要识别重复包并适当地丢弃它们，从而产生重复的自由流。
Delayed duplication can be used in a variety of multimedia applications where there is sufficient bandwidth for the duplicated traffic and the application can tolerate the introduced delay. However, it must be used with care, since it might easily result in a new series of denial-of-service attacks. Delayed duplication is harmful in cases where the primary cause of packet loss is congestion, rather than a network outage due to a temporary link or network element failure. Duplication should only be used by endpoints that want to protect against network failures; protection against congestion must be achieved through other means, as duplication will only make congestion worse.
延迟复制可用于各种多媒体应用中，其中有足够的带宽用于复制的流量，并且应用程序可以容忍引入的延迟。但是，必须小心使用，因为它可能很容易导致一系列新的拒绝服务攻击。如果数据包丢失的主要原因是拥塞，而不是由于临时链路或网元故障导致的网络中断，则延迟复制是有害的。复制只能由希望防止网络故障的端点使用；必须通过其他方式实现对拥塞的保护，因为复制只会使拥塞更加严重。
One particular use case for delayed duplication is to improve the reliability of real-time video feeds inside a core IP network where bandwidth is plentiful and maximum reliability (preferably zero loss) is desired [IC2011]. Compared to other redundancy approaches such as FEC [RFC6363] and redundant data encoding (e.g., [RFC2198]), delayed duplication is easy to implement, since it does not require any special type of encoding or decoding.
延迟复制的一个特殊用例是提高核心IP网络内实时视频馈送的可靠性，该网络的带宽充足，需要最大的可靠性（最好是零损耗）[IC2011]。与FEC[RFC6363]和冗余数据编码（例如[RFC2198]）等其他冗余方法相比，延迟复制易于实现，因为它不需要任何特殊类型的编码或解码。
For duplicate suppression, the receiver has to be able to identify the identical packets. This is straightforward for media packets that carry one or more unique identifiers such as the sequence number field in the RTP header [RFC3550]. In non-RTP applications, the receiver can use unique sequence numbers if available or other alternative approaches to compare the incoming packets and discard the duplicate ones.
对于重复抑制，接收器必须能够识别相同的数据包。这对于携带一个或多个唯一标识符（如RTP报头[RFC3550]中的序列号字段）的媒体数据包来说非常简单。在非RTP应用中，接收器可以使用唯一的序列号（如果可用）或其他替代方法来比较传入的数据包并丢弃重复的数据包。
This specification introduces a new Session Description Protocol (SDP) [RFC4566] attribute for applications/services using the delayed duplication method to indicate the relative delay for each additional duplication. The attribute is used with the duplication grouping semantics defined in [RFC7104].
本规范为应用程序/服务引入了一个新的会话描述协议（SDP）[RFC4566]属性，使用延迟复制方法指示每个额外复制的相对延迟。该属性与[RFC7104]中定义的复制分组语义一起使用。
This specification does not explain how to select the duplication delay that a sender should use; the selection technique depends on the underlying network and the reconvergence technologies used inside such a network. This specification does not explain how the receiver should suppress the duplicate packets and merge the incoming streams to produce a loss-free and duplication-free output stream (a process commonly called "stream merging"), either. An application or a transport service that will use the delayed duplication method must determine its own rules about stream merging.
本规范未解释如何选择发送方应使用的复制延迟；选择技术取决于底层网络以及在此类网络中使用的再聚合技术。本规范也未解释接收机应如何抑制重复分组并合并传入流以产生无丢失和无重复的输出流（通常称为“流合并”的过程）。将使用延迟复制方法的应用程序或传输服务必须确定自己关于流合并的规则。
In practice, more than two redundant streams are unlikely to be used, since the additional delay and increased overhead are not easily justified. However, we define the new attribute in a general way so that it could be used with more than two redundant streams (i.e., multiple duplications), if needed. While the primary focus in this specification is the RTP-based transport, the new attribute is applicable to both RTP and non-RTP streams. Protocol issues and details on duplicating RTP streams are presented in [RFC7198].
在实践中，不太可能使用两个以上的冗余流，因为额外的延迟和增加的开销不容易证明是合理的。但是，我们以一种通用的方式定义新属性，以便在需要时可以与两个以上的冗余流（即多个重复）一起使用。虽然本规范主要关注基于RTP的传输，但新属性同时适用于RTP和非RTP流。[RFC7198]中介绍了复制RTP流的协议问题和详细信息。
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]中的说明进行解释。
The following ABNF [RFC5234] syntax formally describes the 'duplication-delay' attribute:
以下ABNF[RFC5234]语法正式描述了“复制延迟”属性：
delaying-attribute = "a=duplication-delay:" periods CRLF
periods = period *( SP period)
period = 1*DIGIT ; in milliseconds
delaying-attribute = "a=duplication-delay:" periods CRLF
periods = period *( SP period)
period = 1*DIGIT ; in milliseconds
ABNF Syntax for the 'duplication-delay' Attribute
“复制延迟”属性的ABNF语法
The 'duplication-delay' attribute is defined as both a media-level and session-level attribute. It specifies the relative delay with respect to the previous transmission of each duplication in milliseconds (ms) at the time of transmission. The following rules apply:
“复制延迟”属性定义为媒体级和会话级属性。它以毫秒（ms）为单位指定传输时每个复制的上一次传输的相对延迟。以下规则适用：
o If used as a media-level attribute, it MUST be used with the 'ssrc-group' attribute and "DUP" grouping semantics as defined in [RFC7104]. When used as a media-level attribute, the relative delay value(s) it specifies SHALL apply to every Synchronization Source (SSRC)-based duplication grouping in the same media description. In other words, one cannot specify different duplication delay values for different duplication groups in the same media description.
o 如果用作媒体级属性，则必须与[RFC7104]中定义的“ssrc group”属性和“DUP”分组语义一起使用。当用作介质级属性时，其指定的相对延迟值应适用于同一介质描述中基于同步源（SSRC）的每个复制分组。换句话说，不能在同一介质描述中为不同的复制组指定不同的复制延迟值。
o If used as a session-level attribute, it MUST be used with 'group' attribute and "DUP" grouping semantics as defined in [RFC7104]. When used as a session-level attribute, the relative delay value(s) it specifies SHALL apply to every duplication grouping in the same SDP description. In other words, one cannot specify different duplication delay values for different duplication groups in the same SDP description. If one needs to specify different duplication delay values for different duplication groups, then one MUST use different SDP descriptions for each or MUST use the 'duplication-delay' attribute at the media level. In that case, the 'duplication-delay' attribute MUST NOT be used at the session level.
o 如果用作会话级属性，则必须与[RFC7104]中定义的“组”属性和“DUP”分组语义一起使用。当用作会话级属性时，其指定的相对延迟值应适用于同一SDP描述中的每个复制分组。换句话说，不能在同一SDP描述中为不同的复制组指定不同的复制延迟值。如果需要为不同的复制组指定不同的复制延迟值，则必须为每个组使用不同的SDP描述，或者必须在媒体级别使用“复制延迟”属性。在这种情况下，不得在会话级别使用“复制延迟”属性。
o For offer/answer model considerations, refer to [RFC7104].
o 有关报价/应答模型的注意事项，请参阅[RFC7104]。
In the first example below, the multicast stream consists of two RTP streams, each duplicated once, resulting in two sets of two-stream groups. The same duplication delay of 100 ms is applied to each grouping. The first set's streams have SSRCs of 1000 and 1010, and the second set's streams have SSRCs of 1020 and 1030.
在下面的第一个示例中，多播流由两个RTP流组成，每个RTP流复制一次，从而形成两组两个流组。对每个分组应用相同的100 ms复制延迟。第一组流的SSRC为1000和1010，第二组流的SSRC为1020和1030。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100 101
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=rtpmap:101 MP2T/90000
a=ssrc:1020 cname:ch1b@example.com
a=ssrc:1030 cname:ch1b@example.com
a=ssrc-group:DUP 1020 1030
a=duplication-delay:100
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 101
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=rtpmap:101 MP2T/90000
a=ssrc:1020 cname:ch1b@example.com
a=ssrc:1030 cname:ch1b@example.com
a=ssrc-group:DUP 1020 1030
a=duplication-delay:100
a=mid:Ch1
Note that in actual use, SSRC values, which are random 32-bit numbers, could be much larger than the ones shown in this example.
请注意，在实际使用中，SSRC值（32位随机数）可能比本例中显示的值大得多。
In the second example below, the multicast stream is duplicated twice. 50 ms after the original transmission, the first duplicate is transmitted, and 100 ms after that, the second duplicate is transmitted. In other words, the same packet is transmitted three times over a period of 150 ms.
在下面的第二个示例中，多播流被复制两次。原始传输50 ms后，传输第一份副本，100 ms后，传输第二份副本。换言之，同一分组在150ms的周期内传输三次。
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:ch1c@example.com
a=ssrc:1010 cname:ch1c@example.com
a=ssrc:1020 cname:ch1c@example.com
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:ch1c@example.com
a=ssrc:1010 cname:ch1c@example.com
a=ssrc:1020 cname:ch1c@example.com
a=ssrc-group:DUP 1000 1010 1020
a=duplication-delay:50 100
a=mid:Ch1
a=ssrc-group:DUP 1000 1010 1020
a=duplication-delay:50 100
a=mid:Ch1
In the third example below, the multicast UDP stream is duplicated with a duplication delay of 50 ms. Redundant streams are sent in separate source-specific multicast (SSM) sessions, so the receiving host has to join both SSM sessions if it wants to receive both streams.
在下面的第三个示例中，以50 ms的复制延迟复制多播UDP流。冗余流在单独的源特定多播（SSM）会话中发送，因此接收主机必须加入两个SSM会话才能接收两个流。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
a=group:DUP S1a S1b
a=duplication-delay:50
m=audio 30000 udp mp4
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=mid:S1a
m=audio 40000 udp mp4
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=mid:S1b
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
a=group:DUP S1a S1b
a=duplication-delay:50
m=audio 30000 udp mp4
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=mid:S1a
m=audio 40000 udp mp4
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=mid:S1b
The 'duplication-delay' attribute is not believed to introduce any significant security risk to multimedia applications. A malevolent third party could use this attribute to misguide the receiver(s) about the duplication delays and/or the number of redundant streams. For example, if the malevolent third party increases the value of the duplication delay, the receiver(s) will unnecessarily incur a longer delay, since they will have to wait for the entire period. Or, if the duplication delay is reduced by the malevolent third party, the receiver(s) might not wait long enough for the duplicated transmission and incur unnecessary packet losses. However, these require intercepting and rewriting the packets carrying the SDP description; if an interceptor can do that, many more attacks are also possible.
“复制延迟”属性被认为不会给多媒体应用程序带来任何重大的安全风险。恶意的第三方可能会使用此属性来误导接收方复制延迟和/或冗余流的数量。例如，如果恶意第三方增加复制延迟的值，则接收方将不必要地招致更长的延迟，因为他们将不得不等待整个时间段。或者，如果恶意第三方减少了复制延迟，则接收器可能没有足够长的时间等待复制传输，并导致不必要的分组丢失。然而，这些要求截取和重写携带SDP描述的分组；如果拦截器能够做到这一点，那么还可能发生更多的攻击。
In order to avoid attacks of this sort, the SDP description needs to be integrity protected and provided with source authentication. This can, for example, be achieved on an end-to-end basis using S/MIME [RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME types (application/sdp). Alternatively, HTTPS [RFC2818] or the authentication method in the Session Announcement Protocol (SAP) [RFC2974] could be used as well.
为了避免此类攻击，SDP描述需要完整性保护并提供源身份验证。例如，当在使用MIME类型（应用程序/SDP）的信令分组中使用SDP时，这可以使用S/MIME[RFC5652][RFC5751]在端到端的基础上实现。或者，也可以使用HTTPS[RFC2818]或会话公告协议（SAP）[RFC2974]中的身份验证方法。
Another security risk is due to possible software misconfiguration or a software bug where a large number of duplicates could be unwillingly signaled in the 'duplication-delay' attribute. Similarly, an attacker can use this attribute to start a denial-of-service attack by signaling and sending too many duplicated streams. In applications where this attribute is to be used, it is a good practice to put a hard limit on both the number of duplicate streams and the total delay introduced due to duplication, regardless of what the SDP description specifies.
另一个安全风险是由于可能的软件配置错误或软件缺陷，在“复制延迟”属性中可能会不情愿地发出大量重复的信号。类似地，攻击者可以使用此属性发出信号并发送过多重复流，从而发起拒绝服务攻击。在使用此属性的应用程序中，最好对重复流的数量和由于重复而引入的总延迟设置硬限制，而不管SDP描述中指定了什么。
Since this mechanism causes duplication of media packets, if those packets are also cryptographically protected (e.g., encrypted) then such duplication could act as an accelerator if any Million Message [RFC3218] or similar attack such as Lucky 13 [Lucky13] exists against the security mechanism that is in use. Such acceleration could turn an otherwise infeasible attack into one that is practical; however, assuming that the amount of duplication is small and that such weak or broken security mechanisms should really not be used, the overall security impact of the duplication should be minimal. If, however, a bad actor were in control of the SDP but did not have access to the keying material used for media, then such a bad actor could potentially use the SDP to cause the media handling to use a weak or broken mechanism with a lot of duplication, in which case the duplication could be significant. Deployments where the SDP is controlled by an actor who should not have access to the media keying material should therefore be cautious in their use of this duplication mechanism.
由于该机制会导致媒体数据包的复制，如果这些数据包也受到加密保护（例如，加密），则如果存在针对正在使用的安全机制的任何百万消息[RFC3218]或类似攻击（如Lucky 13[Lucky13]），则该复制可以充当加速器。这种加速可能会使原本不可行的攻击变成实际的攻击；但是，假设复制的数量很小，并且不应该使用这种脆弱或损坏的安全机制，那么复制的总体安全影响应该是最小的。但是，如果一个坏角色控制着SDP，但无法访问用于介质的键控材料，那么这样一个坏角色可能会使用SDP导致介质处理使用一个弱的或损坏的机制，并产生大量重复，在这种情况下，重复可能会很严重。如果SDP由不应访问媒体密钥材料的参与者控制，则在使用此复制机制时应谨慎。
If this mechanism were used in conjunction with a source description (SDES) and if the key being used for media protection is derived from a human-memorable or otherwise dictionary-attackable secret, then the duplication done here could allow for a more efficient dictionary attack against the media. The right countermeasure is to use proper keying or, if using an SDES, to ensure that the keys used are not dictionary-attackable.
如果此机制与源描述（SDES）结合使用，并且如果用于媒体保护的密钥来自人类可记忆的或其他字典可攻击的秘密，则此处所做的复制可以允许对媒体进行更有效的字典攻击。正确的对策是使用正确的键控，或者，如果使用SDES，确保使用的键不可通过字典攻击。
The following contact information shall be used for the registration in this document:
本文件中的注册应使用以下联系信息：
Ali Begen abegen@cisco.com
阿里出生abegen@cisco.com
This document registers a new attribute name in SDP.
此文档在SDP中注册一个新的属性名称。
SDP Attribute ("att-field"):
SDP属性（“att字段”）：
Attribute name: duplication-delay Long form: Duplication delay for temporally redundant streams Type of name: att-field Type of attribute: Media or session level Subject to charset: No Purpose: Specifies the relative duplication delay(s) for redundant stream(s) Reference: [RFC7197] Values: See [RFC7197]
属性名称：复制延迟长格式：临时冗余流的复制延迟名称类型：att字段类型属性：媒体或会话级别受限于字符集：无目的：指定冗余流的相对复制延迟参考：[RFC7197]值：请参阅[RFC7197]
The authors would like to thank Colin Perkins, Paul Kyzivat, and Stephen Farrell for their suggestions and reviews.
作者要感谢Colin Perkins、Paul Kyzivat和Stephen Farrell的建议和评论。
[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月。
[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月。
[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月。
[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月。
[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月。
[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月。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[RFC2198]Perkins，C.，Kouvelas，I.，Hodson，O.，Hardman，V.，Handley，M.，Bolot，J.，Vega Garcia，A.，和S.Fosse Parisis，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[RFC7198] Begen, A. and C. Perkins, "Duplicating RTP Streams", RFC 7198, April 2014.
[RFC7198]Begen，A.和C.Perkins，“复制RTP流”，RFC7198，2014年4月。
[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月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC3218] Rescorla, E., "Preventing the Million Message Attack on Cryptographic Message Syntax", RFC 3218, January 2002.
[RFC3218]Rescorla，E.“防止对加密消息语法的百万消息攻击”，RFC 3218，2002年1月。
[Lucky13] AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking the TLS and DTLS Record Protocols", IEEE Symposium on Security and Privacy, May 2013, <http://ieeexplore.ieee.org/xpl/articleDetails.jsp? tp=&arnumber=6547131&queryText%3DLucky+Thirteen>.
[Lucky13]AlFardan，N.和K.Paterson，“幸运十三：打破TLS和DTLS记录协议”，IEEE安全和隐私研讨会，2013年5月<http://ieeexplore.ieee.org/xpl/articleDetails.jsp? tp=&arnumber=6547131&queryText%3DLucky+13th>。
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
Yiqun Cai Microsoft 1065 La Avenida Mountain View, CA 94043 USA
美国加利福尼亚州拉阿维尼达山景大道1065号益群蔡微软公司，邮编94043
EMail: yiqunc@microsoft.com
EMail: yiqunc@microsoft.com
Heidi Ou Cisco 170 W. Tasman Dr. San Jose, CA 95134 USA
Heidi Ou Cisco 170 W.Tasman博士，加利福尼亚州圣何塞，美国95134
EMail: hou@cisco.com
EMail: hou@cisco.com