Internet Engineering Task Force (IETF) Q. Xie
Request for Comments: 6354 August 2011
Updates: 2198, 4102
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) Q. Xie
Request for Comments: 6354 August 2011
Updates: 2198, 4102
Category: Standards Track
ISSN: 2070-1721
Forward-Shifted RTP Redundancy Payload Support
前向移位RTP冗余有效负载支持
Abstract
摘要
This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media).
本文档定义了一个简单的增强功能，以支持具有前向移位冗余编码的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/rfc6354.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6354.
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 ....................................................2
1.1. Sending Redundant Data Inband vs. Out-of-Band ..............3
2. Conventions .....................................................4
3. Allowing Forward-Shifted Redundant Data .........................4
4. Registration of Media Type "fwdred" .............................5
5. Mapping Media Type Parameters into SDP ..........................7
6. Usage in Offer/Answer ...........................................7
7. IANA Considerations .............................................7
8. Security Considerations .........................................8
9. Normative References ............................................8
Appendix A. Anti-Shadow Loss Concealment Using
Forward-Shifted Redundancy .............................9
A.1. Sender-Side Operations .....................................9
A.2. Receiver-Side Operations ..................................11
A.2.1. Normal-Mode Operation ................................11
A.2.2. Anti-Shadow-Mode Operation ...........................12
1. Introduction ....................................................2
1.1. Sending Redundant Data Inband vs. Out-of-Band ..............3
2. Conventions .....................................................4
3. Allowing Forward-Shifted Redundant Data .........................4
4. Registration of Media Type "fwdred" .............................5
5. Mapping Media Type Parameters into SDP ..........................7
6. Usage in Offer/Answer ...........................................7
7. IANA Considerations .............................................7
8. Security Considerations .........................................8
9. Normative References ............................................8
Appendix A. Anti-Shadow Loss Concealment Using
Forward-Shifted Redundancy .............................9
A.1. Sender-Side Operations .....................................9
A.2. Receiver-Side Operations ..................................11
A.2.1. Normal-Mode Operation ................................11
A.2.2. Anti-Shadow-Mode Operation ...........................12
This document defines a simple enhancement to RFC 2198 [RFC2198] to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data.
本文档定义了对RFC 2198[RFC2198]的简单增强，以支持具有前向移位冗余编码的RTP会话，即在相应主数据之前发送冗余数据。
Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds of media). Such capability is highly desirable, especially in wireless mobile communication environments where the radio signal to a mobile wireless media receiver can be temporarily blocked by tall buildings, mountains, tunnels, etc. In other words, the receiver enters into a shadow of the radio coverage. No new data will be received when the receiver is in a shadow.
前向移位冗余可用于隐藏大量连续媒体帧的丢失（例如，连续丢失数秒的媒体）。这种能力是非常理想的，尤其是在无线移动通信环境中，其中到移动无线媒体接收器的无线电信号可以被高层建筑、山脉、隧道等暂时阻断。换句话说，接收器进入无线电覆盖的阴影中。当接收器处于阴影中时，不会接收新数据。
In some extreme cases, the receiver may have to spend seconds or even tens of seconds in a shadow. The traditional backward-shifted redundant encoding scheme (i.e., redundant data is sent after the primary data), as currently supported by RFC 2198 [RFC2198], does not address such consecutive frame losses.
在某些极端情况下，接收器可能需要在阴影中花费数秒甚至数十秒。RFC 2198[RFC2198]目前支持的传统后移冗余编码方案（即，在主数据之后发送冗余数据）不能解决此类连续帧丢失问题。
In contrast, the forward-shifted redundancy scheme allows one to apply effective anti-shadow loss management at the receiver (as illustrated in Appendix A), thus preventing service interruptions when a mobile receiver runs into such a shadow.
相反，前向移位冗余方案允许在接收器处应用有效的抗阴影丢失管理（如附录A所示），从而防止当移动接收器运行到这样的阴影时服务中断。
Anti-shadow loss concealment as described in this document can be readily applied to the streaming of pre-recorded media. Because of the need of generating the forward-shifted anti-shadow redundant stream, to apply anti-shadow loss concealment to the streaming of live media will require the insertion of a delay equal to or greater than the amount of forward-shifting at the source of media.
本文档中所述的防阴影丢失隐藏可以容易地应用于预记录媒体的流。由于需要生成前向移位的反阴影冗余流，要将反阴影丢失隐藏应用于实时媒体的流，将需要在媒体源处插入等于或大于前向移位量的延迟。
Regardless of the direction of time shift (e.g., forward-shifting, or backward-shifting as in RFC 2198) or the encoding scheme (e.g., Forward Error Correction (FEC), or non-FEC), there is always the option of sending the redundant data and the primary data either in the same RTP session (i.e., inband) or in separate RTP sessions (i.e., out-of-band). There are pros and cons for either approach, as outlined below.
无论时间移位的方向（例如，前向移位或RFC 2198中的后向移位）或编码方案（例如，前向纠错（FEC）或非FEC），始终可以选择在同一RTP会话（即带内）或单独的RTP会话（即带外）中发送冗余数据和主数据. 这两种方法各有利弊，如下所述。
Inband Approach:
带内进近：
o Pro: A single RTP session is faster to set up and easier to manage.
o 赞成：单个RTP会话设置更快，管理更容易。
o Pro: A single RTP session presents a simpler problem for NAT/ firewall traversal.
o 赞成：单个RTP会话为NAT/防火墙遍历提供了一个更简单的问题。
o Pro: Less overall overhead -- one source of RTP/UDP/IP overhead.
o 优点：总体开销较小——RTP/UDP/IP开销的一个来源。
o Con: Lack of flexibility -- difficult for middle boxes such as gateways to add/remove the redundant data.
o 缺点：缺乏灵活性--网关等中间设备很难添加/删除冗余数据。
o Con: Need more specification -- special payload formats need to be defined to carry the redundant data inband.
o 缺点：需要更多的规范——需要定义特殊的有效负载格式来携带带内的冗余数据。
Out-of-Band Approach:
带外方法：
o Pro: Flexibility -- redundant data can be more easily added, removed, or replaced by a middle box such as a gateway.
o 优点：灵活性--可以更轻松地添加、删除冗余数据，或者用中间框（如网关）替换冗余数据。
o Pro: Little or no specification -- no new payload format is needed.
o 赞成：很少或没有规范——不需要新的有效负载格式。
o Con: Multiple RTP sessions may take longer to set up and may be more complex to manage.
o 缺点：设置多个RTP会话可能需要更长的时间，并且管理起来可能更复杂。
o Con: Multiple RTP sessions for NAT/firewall traversal are harder to address.
o 缺点：NAT/防火墙穿越的多个RTP会话更难处理。
o Con: Bigger overall overhead -- more than one source of RTP/UDP/IP overhead.
o 缺点：总体开销更大——RTP/UDP/IP开销的来源不止一个。
It is noteworthy that the specification of inband payload formats, as described in this document and in RFC 2198, does not preclude a deployment from using the out-of-band approach. Rather, it gives the deployment the choice to use whichever approach is deemed most beneficial under a given circumstance.
值得注意的是，本文件和RFC 2198中所述的带内有效载荷格式规范并不妨碍使用带外方法进行部署。相反，它让部署可以选择在给定情况下使用被认为最有利的方法。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In RFC 2198, the timestamp offset in the additional header corresponding to a redundant block is defined as a 14-bit unsigned offset of the timestamp relative to the timestamp given in the RTP header. As stated in RFC 2198:
在RFC 2198中，与冗余块相对应的附加报头中的时间戳偏移被定义为时间戳相对于RTP报头中给定的时间戳的14位无符号偏移。如RFC 2198所述：
The use of an unsigned offset implies that redundant data must be sent after the primary data, and is hence a time to be subtracted from the current timestamp to determine the timestamp of the data for which this block is the redundancy.
使用无符号偏移量意味着冗余数据必须在主数据之后发送，因此是从当前时间戳中减去的时间，以确定此块为冗余的数据的时间戳。
This effectively prevents RFC 2198 from being used to support forward-shifted redundant blocks.
这有效地防止RFC 2198用于支持前向移位冗余块。
In order to support the use of forward-shifted redundant blocks, the media type "fwdred", which allows a parameter called "forwardshift", is introduced to indicate the capability of and willingness to use forward-shifted redundancy and the base value of timestamp forward-shifting. The base value of "forwardshift" is an integer equal to or greater than '0' in RTP timestamp units.
为了支持前向移位冗余块的使用，引入了媒体类型“fwdred”，它允许一个称为“forwardshift”的参数，以指示使用前向移位冗余的能力和意愿以及时间戳前向移位的基值。“forwardshift”的基值是一个整数，以RTP时间戳为单位，等于或大于“0”。
In an RTP session that uses forward-shifted redundant encodings, the timestamp of a redundant block in a received RTP packet is determined as follows:
在使用前向移位冗余编码的RTP会话中，所接收RTP分组中冗余块的时间戳确定如下：
timestamp of redundant block = timestamp in RTP header - timestamp offset in additional header + forward-shift base value
冗余块的时间戳=RTP报头中的时间戳-附加报头中的时间戳偏移量+前向移位基值
Note that generally, in a forward-shifted session, the timestamp offset in the additional header is set to '0'.
请注意，通常，在前向移位会话中，附加报头中的时间戳偏移量设置为“0”。
The sender MUST NOT change the contents of a packet that appears in a forward-shifted stream when it is time to send it in the main stream.
当在主流中发送数据包时，发送方不得更改前向移位流中出现的数据包的内容。
The definition is based on media type "red" defined in RFC 2198 [RFC2198] and RFC 4102 [RFC4102], with the addition of the "forwardshift" parameter.
该定义基于RFC 2198[RFC2198]和RFC 4102[RFC4102]中定义的媒体类型“red”，并添加了“forwardshift”参数。
Type names: audio, text
类型名称：音频、文本
Subtype names: fwdred
子类型名称：fwdred
Required parameters:
所需参数：
rate: as defined in [RFC4102].
费率：如[RFC4102]所定义。
pt: as defined in [RFC4102].
pt：如[RFC4102]中所定义。
forwardshift: An unsigned integer can be specified as the value.
forwardshift：可以将无符号整数指定为值。
If this parameter has a value greater than '0', it indicates that the sender of this parameter will use forward-shifting with a base value as specified when sending out redundant data. This value is in RTP timestamp units.
如果此参数的值大于“0”，则表示此参数的发送方在发送冗余数据时将使用指定的基值进行前移。此值以RTP时间戳单位表示。
If this parameter has a value of '0', it indicates that the sender of this parameter will not use forward-shifting when sending its redundant data; i.e., the sender will have the same behaviors as defined in RFC 2198.
如果此参数的值为“0”，则表示此参数的发送方在发送其冗余数据时不会使用前移；i、 例如，发送方将具有RFC 2198中定义的相同行为。
Optional parameters:
可选参数：
ptime: as defined in [RFC4102] [RFC4566].
ptime：如[RFC4102][RFC4566]所定义。
maxptime: as defined in [RFC4102] [RFC4867].
maxptime:如[RFC4102][RFC4867]所定义。
Encoding considerations:
编码注意事项：
This media type is framed binary data (see RFC 4288, Section 4.8) and is only defined for transfer of RTP redundant data frames specified in RFC 2198.
该媒体类型为帧二进制数据（见RFC 4288，第4.8节），仅用于传输RFC 2198中规定的RTP冗余数据帧。
Security considerations: See Section 6 of RFC 2198.
安全注意事项：见RFC 2198第6节。
Interoperability considerations: none.
互操作性考虑：无。
Published specification:
已发布的规范：
RTP redundant data frame format is specified in RFC 2198.
RFC 2198中规定了RTP冗余数据帧格式。
Applications that use this media type:
使用此媒体类型的应用程序：
It is expected that real-time audio/video, text streaming, and conferencing tools/applications that want protection against losses of a large number of consecutive frames will be interested in using this type.
预计需要防止大量连续帧丢失的实时音频/视频、文本流和会议工具/应用程序将对使用这种类型感兴趣。
Additional information: none.
其他信息：无。
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Qiaobing Xie <Qiaobing.Xie@gmail.com>
Qiaobing Xie <Qiaobing.Xie@gmail.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550 [RFC3550]). Transfer within other framing protocols is not defined at this time.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550[RFC3550]）。此时未定义其他帧协议内的传输。
Author:
作者：
Qiaobing Xie
谢乔冰
Change controller:
更改控制器：
IETF Audio/Video Transport working group delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the forward-shifted redundant format, the mapping is as follows:
媒体类型规范中包含的信息与会话描述协议（SDP）[RFC4566]中的字段具有特定映射，该协议通常用于描述RTP会话。当SDP用于指定采用前向移位冗余格式的会话时，映射如下所示：
o The media type ("audio") goes in SDP "m=" as the media name.
o 媒体类型（“音频”）以SDP“m=”作为媒体名称。
o The media subtype ("fwdred") goes in SDP "a=rtpmap" as the encoding name.
o 媒体子类型（“fwdred”）以SDP“a=rtpmap”作为编码名称。
o The required parameter "forwardshift" goes in the SDP "a=fmtp" attribute by copying it directly from the media type string as "forwardshift=value".
o 所需参数“forwardshift”通过直接从媒体类型字符串复制为“forwardshift=value”进入SDP“a=fmtp”属性。
The following is an example of usage that indicates forward-shifted (by 5.1 sec) redundancy:
以下是表示前向移位（5.1秒）冗余的使用示例：
m=audio 12345 RTP/AVP 121 0 5
a=rtpmap:121 fwdred/8000/1
a=fmtp:121 0/5 forwardshift=40800
m=audio 12345 RTP/AVP 121 0 5
a=rtpmap:121 fwdred/8000/1
a=fmtp:121 0/5 forwardshift=40800
The following is an example of usage that indicates sending redundancy without forward-shifting (equivalent to RFC 2198):
以下是指示发送冗余而不进行前向移位的用法示例（相当于RFC 2198）：
m=audio 12345 RTP/AVP 121 0 5
a=rtpmap:121 fwdred/8000/1
a=fmtp:121 0/5 forwardshift=0
m=audio 12345 RTP/AVP 121 0 5
a=rtpmap:121 fwdred/8000/1
a=fmtp:121 0/5 forwardshift=0
The "forwardshift" SDP parameter specified in this document is declarative, and all reasonable values are expected to be supported.
本文档中指定的“forwardshift”SDP参数是声明性的，所有合理的值都应得到支持。
IANA made the assignments described below per this document.
IANA根据本文件完成了下述任务。
o IANA added the following to the "Audio Media Types" registry:
o IANA在“音频媒体类型”注册表中添加了以下内容：
fwdred [RFC6354]
fwdred[RFC6354]
o IANA added the following to the "Text Media Types" registry:
o IANA在“文本媒体类型”注册表中添加了以下内容：
fwdred [RFC6354]
fwdred[RFC6354]
Security considerations discussed in Section 6 of [RFC2198], Section 4 of [RFC4856], and Sections 9 and 14 of [RFC3550] apply to this specification. In addition, to prevent denial-of-service attacks, a receiver SHOULD be prepared to ignore a 'forwardshift' parameter declaration if it considers the offset value in the declaration excessive. In such a case, the receiver SHOULD also ignore the redundant stream in the resultant RTP session.
[RFC2198]第6节、[RFC4856]第4节以及[RFC3550]第9节和第14节中讨论的安全注意事项适用于本规范。此外，为了防止拒绝服务攻击，如果接收方认为声明中的偏移量值过大，则应准备忽略“forwardshift”参数声明。在这种情况下，接收器还应忽略结果RTP会话中的冗余流。
[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月。
[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月。
[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月。
[RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", RFC 4102, June 2005.
[RFC4102]Jones，P.，“文本/红色MIME子类型的注册”，RFC41022005年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月。
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007.
[RFC4856]Casner，S.，“音频和视频会议RTP配置文件中有效负载格式的媒体类型注册”，RFC 4856，2007年2月。
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, April 2007.
[RFC4867]Sjoberg，J.，Westerlund，M.，Lakaniemi，A.，和Q.Xie，“自适应多速率（AMR）和自适应多速率宽带（AMR-WB）音频编解码器的RTP有效载荷格式和文件存储格式”，RFC 4867，2007年4月。
Appendix A. Anti-Shadow Loss Concealment Using Forward-Shifted Redundancy
附录A.使用前向移位冗余的抗阴影丢失隐藏
(This Appendix is included for Informational purposes.)
（本附录仅供参考。）
It is not unusual in a wireless mobile communication environment that the radio signal to a mobile wireless media receiver can be temporarily blocked by tall buildings, mountains, tunnels, etc. for a period of time. In other words, the receiver enters into a shadow of the radio coverage. When the receiver is in such a shadow, no new data will be received. In some extreme cases, the receiver may have to spend seconds or even tens of seconds in such a shadow.
在无线移动通信环境中，发送到移动无线媒体接收器的无线电信号可以被高层建筑、山脉、隧道等暂时阻断一段时间，这并不罕见。换句话说，接收器进入无线电覆盖的阴影中。当接收器处于这种阴影中时，将不会接收到新数据。在某些极端情况下，接收器可能需要在这样的阴影中花费数秒甚至数十秒。
Without special design considerations to compensate for the loss of data due to shadowing, a mobile user may experience an unacceptable level of service interruptions. Traditional redundant encoding schemes (including RFC 2198 and most FEC schemes) are known to be ineffective in dealing with such losses of consecutive frames.
如果没有特殊的设计考虑来补偿由于阴影造成的数据丢失，移动用户可能会遇到不可接受的服务中断。传统的冗余编码方案（包括RFC 2198和大多数FEC方案）在处理连续帧的这种丢失方面是无效的。
However, the employment of forward-shifted redundancy, in combination with the anti-shadow loss concealment at the receiver, as described here, can effectively prevent service interruptions due to the effect of shadowing.
然而，如本文所述，前移冗余的使用与接收机处的抗阴影丢失隐藏相结合，可以有效地防止由于阴影效应而导致的服务中断。
For anti-shadow loss management, the RTP sender simply adds a forward-shifted redundant stream (called anti-shadow or AS stream) while transmitting the primary media stream. The amount of forward-shifting, which should remain constant for the duration of the session, will determine the maximal length of shadows that can be completely concealed at the receiver, as explained below.
对于反阴影丢失管理，RTP发送方只需在传输主媒体流时添加前向移位的冗余流（称为反阴影或AS流）。如下文所述，在会话期间应保持恒定的前向移位量将确定可在接收器处完全隐藏的阴影的最大长度。
Except for the fact that the redundant stream is forward-shifted relative to the primary stream (i.e., the redundant data is sent ahead of the corresponding primary data), the design decision and trade-offs on the quality, encoding, bandwidth overhead, etc. of the redundant stream are not different from the traditional RTP payload redundant scheme.
除了冗余流相对于主流进行前移（即，冗余数据在相应主数据之前发送）的事实之外，设计决策和质量、编码、带宽开销的权衡，冗余流的等与传统的RTP有效负载冗余方案没有区别。
The following diagram illustrates a segment of the transmission sequence of a forward-shifted redundant RTP session, in which the AS stream is forward-shifted by 155 frames. If, for simplicity here, we assume that the value of the timestamp is incremented by 1 between two consecutive frames, this forward-shifted redundancy can then be indicated with:
下图示出了前向移位冗余RTP会话的传输序列的一段，其中AS流被前向移位155帧。为了简单起见，如果我们假设时间戳的值在两个连续帧之间增加1，则该前向移位冗余可以用以下方式表示：
forwardshift=155
前移=155
and the setting of the timestamp offset to 0 in all the additional headers. This can mean 3.1 seconds of forward-shifting if each frame represents 20 ms of original media.
以及在所有附加头中将时间戳偏移设置为0。如果每帧代表20毫秒的原始介质，则这可能意味着3.1秒的前移。
Primary stream AS stream
作为流的主流
... | |
v v
Pkt k+8 [ 111 ] [ 266 ]
| |
v v
Pkt k+7 [ 110 ] [ 265 ]
| |
v v
^ Pkt k+6 [ 109 ] [ 264 ]
| | |
| v v
Pkt k+5 [ 108 ] [ 263 ]
T | |
I v v
M Pkt k+4 [ 107 ] [ 262 ]
E | |
v v
Pkt k+3 [ 106 ] [ 261 ]
| |
v v
Pkt k+2 [ 105 ] [ 260 ]
| |
v v
Pkt k+1 [ 104 ] [ 259 ]
| |
v v
Pkt k [ 103 ] [ 258 ]
| |
v v
... | |
v v
Pkt k+8 [ 111 ] [ 266 ]
| |
v v
Pkt k+7 [ 110 ] [ 265 ]
| |
v v
^ Pkt k+6 [ 109 ] [ 264 ]
| | |
| v v
Pkt k+5 [ 108 ] [ 263 ]
T | |
I v v
M Pkt k+4 [ 107 ] [ 262 ]
E | |
v v
Pkt k+3 [ 106 ] [ 261 ]
| |
v v
Pkt k+2 [ 105 ] [ 260 ]
| |
v v
Pkt k+1 [ 104 ] [ 259 ]
| |
v v
Pkt k [ 103 ] [ 258 ]
| |
v v
(Transmitted first)
（先发）
Figure 1: An Example of Forward-Shifted Redundant RTP Packet Transmission
图1：前向移位冗余RTP数据包传输示例
The anti-shadow receiver is illustrated in the following diagram.
防阴影接收器如下图所示。
+---------+
normal mode sw1 | media | media
Primary stream ======================o___o==>| decoder |===> output
AS stream ---- +---------+ device
| AS mode o
| +---------+ |
| | anti- | |
------->| shadow |----
| buffer |
+---------+
|
V
expired frames
discarded
+---------+
normal mode sw1 | media | media
Primary stream ======================o___o==>| decoder |===> output
AS stream ---- +---------+ device
| AS mode o
| +---------+ |
| | anti- | |
------->| shadow |----
| buffer |
+---------+
|
V
expired frames
discarded
Figure 2: Anti-Shadow RTP Receiver
图2：抗阴影RTP接收机
The anti-shadow receiver operates between two modes -- "normal mode" and "AS mode". When the receiver is not in a shadow (i.e., when it still receives new data), it operates in the normal mode. Otherwise, it operates in the AS mode.
防阴影接收器在两种模式之间工作——“正常模式”和“AS模式”。当接收器不在阴影中时（即，当它仍然接收新数据时），它在正常模式下工作。否则，它将在AS模式下运行。
In the normal mode, after receiving a new RTP packet that contains the primary data and forward-shifted AS data, the receiver passes the primary data directly to the appropriate media decoder for play-out (a de-jittering buffer may be used before the play-out, but for simplicity we assume that none is used here), while the received AS data is stored in an anti-shadow buffer.
在正常模式下，在接收到包含主数据且前向移位为数据的新RTP数据包后，接收器将主数据直接传递给适当的媒体解码器以进行播放（在播放之前可以使用去抖动缓冲区，但为简单起见，我们假设此处不使用去抖动缓冲区），而接收的AS数据存储在反阴影缓冲区中。
Moreover, data stored in the anti-shadow buffer will be continuously checked to determine whether it has expired. If any redundant data in the anti-shadow buffer is found to have a timestamp older (i.e., smaller) than that of the last primary frame passed to the media decoder, it will be considered expired and be purged from the anti-shadow buffer.
此外，将持续检查存储在反阴影缓冲区中的数据，以确定其是否已过期。如果发现反阴影缓冲区中的任何冗余数据的时间戳比传递给媒体解码器的最后一个主帧的时间戳旧（即，更小），则该数据将被视为过期，并从反阴影缓冲区中清除。
The following example illustrates the operation of the anti-shadow buffer in normal mode. We use the same assumption as in Figure 1, and assume that the initial timestamp value is 103 when the session starts.
以下示例说明了正常模式下反阴影缓冲区的操作。我们使用与图1相同的假设，并假设会话启动时初始时间戳值为103。
Timestamp Timestamp
Time being of media in
(in ms) played out AS buffer Note
------------------------------------------------------------------
t < 0 -- (buffer empty)
...
t=0 103 258 (hold 1 AS frame)
t=20 104 258-259 (hold 2 AS frames)
t=40 105 258-260 (hold 3 AS frames)
Timestamp Timestamp
Time being of media in
(in ms) played out AS buffer Note
------------------------------------------------------------------
t < 0 -- (buffer empty)
...
t=0 103 258 (hold 1 AS frame)
t=20 104 258-259 (hold 2 AS frames)
t=40 105 258-260 (hold 3 AS frames)
... t=3080 257 258-412 (full, hold 155 AS frames) t=3100 258 259-413 (full, frame 258 purged) t=3120 259 260-414 (full, frame 259 purged) ...
... t=3080 257 258-412（满，保持155帧）t=3100 258 259-413（满，帧258清除）t=3120 259 260-414（满，帧259清除）。。。
t=6240 415 416-570 (always holds 3.1 sec worth of redundant data) ...
t=6240 415 416-570（始终保持3.1秒的冗余数据）。。。
Figure 3: Example of Anti-Shadow Buffer Operation in Normal Mode
图3：正常模式下的反阴影缓冲区操作示例
Before the beginning of the session (t<0), the anti-shadow buffer will be empty. When the first primary frame is received, the play-out will start immediately, and the first received AS frame is stored in the anti-shadow buffer. With the arrival of more forward-shifted redundant frames, the anti-shadow buffer will gradually be filled up.
在会话开始之前（t<0），反阴影缓冲区将为空。当接收到第一个主帧时，播放将立即开始，第一个接收到的AS帧存储在防阴影缓冲区中。随着更多前移冗余帧的到来，反阴影缓冲区将逐渐填满。
For the example shown in Figure 3, after 3.08 seconds (the amount of the forward-shifting minus one frame) from the start of the session, the anti-shadow buffer will be full, holding exactly 3.1 seconds worth of redundant data, with the oldest frame corresponding to t=3.1 sec and the youngest frame corresponding to t=6.18 sec.
对于图3所示的示例，在会话开始后3.08秒（前移量减去一帧）后，反阴影缓冲区将满，正好保存3.1秒的冗余数据，最旧的帧对应于t=3.1秒，最年轻的帧对应于t=6.18秒。
It is not difficult to see that in normal mode, because of the continuous purge of expired frames and the addition of new frames, the anti-shadow buffer will always be full, holding the next 'forwardshift' amount of redundant frames.
不难看出，在正常模式下，由于持续清除过期帧和添加新帧，反阴影缓冲区将始终充满，保留下一个“forwardshift”数量的冗余帧。
When the receiver enters a shadow (or any other conditions that prevent the receiver from getting new media data), the receiver switches to the anti-shadow mode, in which it simply continues the play-out from the forward-shifted redundant data stored in the anti-shadow buffer.
当接收器进入阴影（或阻止接收器获取新媒体数据的任何其他条件）时，接收器切换到反阴影模式，在该模式下，它只是继续播放存储在反阴影缓冲区中的前向移位冗余数据。
For the example in Figure 3, if the receiver enters a shadow at t=3120, it can continue the play-out by using the forward-shifted redundant frames (ts=260-414) from the anti-shadow buffer. As long as the receiver can move out of the shadow by t=6240, there will be no service interruption.
对于图3中的示例，如果接收器在t=3120处进入阴影，它可以使用来自反阴影缓冲区的前向移位冗余帧（ts=260-414）继续播放。只要接收器能够以t=6240的速度移出阴影，就不会有服务中断。
When the shadow condition ends (meaning new data starts to arrive again), the receiver immediately switches back to the normal mode of operation, playing out from newly arrived primary frames. At the same time, the arrival of new AS frames will start to re-fill the anti-shadow buffer.
当阴影条件结束时（意味着新数据开始再次到达），接收器立即切换回正常操作模式，从新到达的主帧播放。同时，新AS帧的到达将开始重新填充反阴影缓冲区。
However, if the duration of the shadow is longer than the amount of forward-shifting, the receiver will run out of media frames from its anti-shadow buffer. At that point, service interruption will occur.
但是，如果阴影的持续时间长于前向移位量，则接收器将耗尽其反阴影缓冲区中的媒体帧。此时，将发生服务中断。
Author's Address
作者地址
Qiaobing Xie 15901 Wetherburn Rd. Chesterfield, MO 63017 US
美国密苏里州切斯特菲尔德韦瑟伯恩路15901号谢乔平邮编63017
Phone: +1-847-893-0222
EMail: Qiaobing.Xie@gmail.com
Phone: +1-847-893-0222
EMail: Qiaobing.Xie@gmail.com