Internet Engineering Task Force (IETF) M. Watson
Request for Comments: 6682 Netflix
Category: Standards Track T. Stockhammer
ISSN: 2070-1721 Nomor Research
M. Luby
Qualcomm Incorporated
August 2012
Internet Engineering Task Force (IETF) M. Watson
Request for Comments: 6682 Netflix
Category: Standards Track T. Stockhammer
ISSN: 2070-1721 Nomor Research
M. Luby
Qualcomm Incorporated
August 2012
RTP Payload Format for Raptor Forward Error Correction (FEC)
猛禽前向纠错（FEC）的RTP有效载荷格式
Abstract
摘要
This document specifies an RTP payload format for the Forward Error Correction (FEC) repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework that supports the transport of repair data over both UDP and RTP. This document specifies the payload format that is required for the use of RTP to carry Raptor repair flows.
本文件规定了Raptor FEC方案产生的前向纠错（FEC）修复数据的RTP有效载荷格式。Raptor FEC方案指定用于IETF FEC框架，该框架支持通过UDP和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/rfc6682.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6682.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions, Definitions, and Acronyms ..........................3
3. Media Format Background .........................................3
4. Payload Format for FEC Repair Packets ...........................4
4.1. RTP Header Usage ...........................................4
4.2. Payload Header .............................................5
4.3. Payload Data ...............................................5
5. Congestion Control Considerations ...............................5
6. Media Types .....................................................5
6.1. Registration of the 'application/raptorfec' Media Type .....5
6.1.1. Media Type Definition ...............................5
6.2. Registration of the 'video/raptorfec' Media Type ...........7
6.2.1. Media Type Definition ...............................7
6.3. Registration of the 'audio/raptorfec' Media Type ...........8
6.3.1. Media Type Definition ...............................8
6.4. Registration of the 'text/raptorfec' Media Type ...........10
6.4.1. Media Type Definition ..............................10
7. Mapping to the Session Description Protocol (SDP) ..............12
8. Offer/Answer Considerations ....................................12
9. Declarative SDP Considerations .................................13
10. Repair Flow Generation and Recovery Procedures ................13
10.1. Overview .................................................13
10.2. Repair Packet Construction ...............................14
10.3. Usage of RTCP ............................................14
10.4. Source Packet Reconstruction .............................14
11. Session Description Protocol (SDP) Example ....................14
12. IANA Considerations ...........................................15
13. Security Considerations .......................................15
14. References ....................................................16
14.1. Normative References .....................................16
14.2. Informative References ...................................17
1. Introduction ....................................................3
2. Conventions, Definitions, and Acronyms ..........................3
3. Media Format Background .........................................3
4. Payload Format for FEC Repair Packets ...........................4
4.1. RTP Header Usage ...........................................4
4.2. Payload Header .............................................5
4.3. Payload Data ...............................................5
5. Congestion Control Considerations ...............................5
6. Media Types .....................................................5
6.1. Registration of the 'application/raptorfec' Media Type .....5
6.1.1. Media Type Definition ...............................5
6.2. Registration of the 'video/raptorfec' Media Type ...........7
6.2.1. Media Type Definition ...............................7
6.3. Registration of the 'audio/raptorfec' Media Type ...........8
6.3.1. Media Type Definition ...............................8
6.4. Registration of the 'text/raptorfec' Media Type ...........10
6.4.1. Media Type Definition ..............................10
7. Mapping to the Session Description Protocol (SDP) ..............12
8. Offer/Answer Considerations ....................................12
9. Declarative SDP Considerations .................................13
10. Repair Flow Generation and Recovery Procedures ................13
10.1. Overview .................................................13
10.2. Repair Packet Construction ...............................14
10.3. Usage of RTCP ............................................14
10.4. Source Packet Reconstruction .............................14
11. Session Description Protocol (SDP) Example ....................14
12. IANA Considerations ...........................................15
13. Security Considerations .......................................15
14. References ....................................................16
14.1. Normative References .....................................16
14.2. Informative References ...................................17
The FEC Framework [RFC6363] defines a general framework for the use of Forward Error Correction in association with arbitrary packet flows, including flows over UDP and RTP [RFC3550]. Forward Error Correction operates by generating redundant data packets ("repair data") that can be sent independently from the original flow. At a receiver, the original flow can be reconstructed provided a sufficient set of redundant data packets and possibly original data packets are received.
FEC框架[RFC6363]定义了与任意数据包流（包括UDP和RTP上的流[RFC3550]）相关联的前向纠错的通用框架。前向纠错通过生成可独立于原始流发送的冗余数据包（“修复数据”）进行操作。在接收器处，只要接收到足够多的冗余数据分组和可能的原始数据分组，就可以重构原始流。
The FEC Framework provides for independence between application protocols and FEC codes. The use of a particular FEC code within the framework is defined by means of a FEC Scheme, which may then be used with any application protocol compliant to the framework.
FEC框架提供了应用程序协议和FEC代码之间的独立性。框架内特定FEC代码的使用通过FEC方案来定义，该方案随后可与符合框架的任何应用协议一起使用。
Repair data flows may be sent directly over a transport protocol, such as UDP, or they may be encapsulated within specialized transports for multimedia, such as RTP.
修复数据流可以直接通过传输协议（如UDP）发送，也可以封装在专用的多媒体传输协议（如RTP）中。
This document defines the RTP payload format for the Raptor FEC Schemes defined in [RFC6681].
本文件定义了[RFC6681]中定义的猛禽FEC方案的RTP有效载荷格式。
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]中所述进行解释。
The Raptor and RaptorQ codes are efficient block-based fountain codes, meaning that from any group of source packets (or 'source block'), one can generate an arbitrary number of repair packets. The Raptor and RaptorQ codes have the property that the original group of source symbols can be recovered with a very high probability from any set of symbols (source and repair) only slightly greater in number than the original number of source symbols. The RaptorQ code additionally has the property that the probability that the original group of source symbols can be recovered from a set of symbols (source and repair) equal in number to the original number of source symbols is in many cases also very high.
Raptor和RaptorQ码是有效的基于块的喷泉码，这意味着从任何一组源包（或“源块”）中，可以生成任意数量的修复包。Raptor和RaptorQ代码的特性是，原始源符号组可以从任何符号集（源和修复）以非常高的概率恢复，其数量仅略大于原始源符号数量。RaptorQ代码还具有这样的特性：在许多情况下，源符号的原始组可以从一组符号（源符号和修复符号）中恢复的概率也非常高，这些符号的数量等于源符号的原始数量。
[RFC6681] defines six FEC Schemes for the use of the Raptor and RaptorQ codes with arbitrary packet flows. The first two schemes are fully applicable to arbitrary packet flows (using Raptor and RaptorQ respectively). The third and fourth schemes are slightly optimized versions of the first two schemes, which are applicable in
[RFC6681]定义了六种FEC方案，用于在任意数据包流中使用Raptor和RaptorQ码。前两种方案完全适用于任意分组流（分别使用Raptor和RaptorQ）。第三个和第四个方案是前两个方案的略微优化版本，适用于
applications with relatively small block sizes. The fifth and sixth schemes are variants of the third and fourth schemes, which are applicable to a single source flow that already has some kind of identifiable sequence number. The presence of a sequence number in the source flow allows for backwards-compatible operation (the source flows do not need to be modified in order to apply FEC). In this case, in the language of the FEC Framework, there is no need for an explicit FEC Source Payload ID; therefore, it is not included in the packets.
块大小相对较小的应用程序。第五和第六种方案是第三和第四种方案的变体，它们适用于已经具有某种可识别序列号的单个源流。源流中序列号的存在允许向后兼容操作（应用FEC不需要修改源流）。在这种情况下，在FEC框架的语言中，不需要显式的FEC源有效负载ID；因此，它不包括在包中。
This document specifies the payload format for RTP repair flows and can be used with any of the FEC Schemes defined in [RFC6681].
本文件规定了RTP修复流的有效载荷格式，可与[RFC6681]中定义的任何FEC方案一起使用。
Header fields SHALL be set according to the rules of [RFC3550]. In addition, the following rules and definitions apply for the RTP headers used with FEC repair packets:
应根据[RFC3550]的规则设置标题字段。此外，以下规则和定义适用于与FEC修复数据包一起使用的RTP报头：
o Marker bit: The marker bit SHALL be set to 1 for the last protection RTP packet sent for each source block, and otherwise set to 0.
o 标记位：对于每个源块发送的最后一个保护RTP数据包，标记位应设置为1，否则设置为0。
o Payload Type (PT): The payload type codes SHALL be assigned dynamically through non-RTP means. If the Session Description Protocol (SDP) is used for signaling, the rules in Section 7 apply.
o 有效载荷类型（PT）：应通过非RTP方式动态分配有效载荷类型代码。如果会话描述协议（SDP）用于信令，则第7节中的规则适用。
o Timestamp: This field contains the time at which the packet is transmitted. The time SHOULD be as close as possible to the packet's actual time of transmission. The timestamp value has no use in the actual FEC protection process. However, implementations SHOULD supply a value that can be used for packet-arrival timing or jitter calculations. The timestamp rate is specified using the "rate" media type parameter defined in Section 6. The operator SHALL select a "rate" larger than 1000 Hz to provide sufficient resolution to the Real-Time Transport Control Protocol (RTCP) operations, and the operator SHOULD select the rate that matches the rate of the protected source RTP stream.
o 时间戳：此字段包含数据包传输的时间。时间应尽可能接近数据包的实际传输时间。时间戳值在实际的FEC保护过程中没有用处。然而，实现应该提供一个可用于数据包到达定时或抖动计算的值。使用第6节中定义的“速率”媒体类型参数指定时间戳速率。操作员应选择大于1000 Hz的“速率”，以提供实时传输控制协议（RTCP）操作的足够分辨率，并且操作员应选择与受保护源RTP流速率匹配的速率。
o Synchronization Source (SSRC): The SSRC values MUST be set according to [RFC3550]. The SSRC value of the RTP repair flow MUST be different from the SSRC value of the protected source flow.
o 同步源（SSRC）：必须根据[RFC3550]设置SSRC值。RTP修复流的SSRC值必须不同于受保护源流的SSRC值。
There is no payload header in this payload format.
此有效负载格式中没有有效负载标头。
Procedures and data formats for the use of Raptor Forward Error Correction in a FECFRAME context are fully defined in [RFC6363] and [RFC6681] and are not duplicated here. The procedures of those documents apply in order to generate repair data streams to be carried by the payload formats defined in this document.
[RFC6363]和[RFC6681]中完全定义了FECFRAME上下文中使用Raptor前向纠错的程序和数据格式，此处不再重复。这些文件中的程序适用于生成由本文件中定义的有效载荷格式携带的维修数据流。
The RTP Payload SHALL contain a Repair FEC Payload ID as defined in [RFC6363] and [RFC6681].
RTP有效载荷应包含[RFC6363]和[RFC6681]中定义的维修FEC有效载荷ID。
See [RFC6363].
见[RFC6363]。
This RTP payload format is identified using the 'application/raptorfec' media type that is registered in accordance with [RFC4855] and uses the template of [RFC4288].
该RTP有效负载格式使用根据[RFC4855]注册并使用[RFC4288]模板的“应用程序/raptorfec”媒体类型进行标识。
Type name: application
类型名称：应用程序
Subtype name: raptorfec
子类型名称：raptorfec
Required parameters:
所需参数：
o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) rate is specified in Hz and the format is unsigned integer.
o 速率：RTP时间戳（时钟）速率。RTP时间戳（时钟）速率以Hz为单位指定，格式为无符号整数。
o raptor-scheme-id: The value of this parameter is the FEC Scheme ID for the specific Raptor FEC Scheme that will be used as defined in [RFC6681].
o raptor方案id：此参数的值是特定raptor FEC方案的FEC方案id，该方案将按照[RFC6681]中的定义使用。
o Kmax: The value of this parameter is the FEC Framework Configuration Information element, Maximum Source Block Length (MSBL), as defined in [RFC6681], encoded as a unsigned integer. For specific requirements for this value, refer to [RFC6681].
o Kmax：此参数的值是FEC框架配置信息元素，即[RFC6681]中定义的最大源块长度（MSBL），编码为无符号整数。有关该值的具体要求，请参阅[RFC6681]。
o T: The value of this parameter is the FEC Framework Configuration Information element, encoding symbol size, as defined in [RFC6681], encoded as a unsigned integer. For specific requirements for this value, refer to [RFC6681].
o T：此参数的值是FEC框架配置信息元素，编码符号大小，如[RFC6681]中所定义，编码为无符号整数。有关该值的具体要求，请参阅[RFC6681]。
o repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds and the format is unsigned integer.
o 修复窗口：跨越源数据包和相应修复数据包的最长时间。修复窗口的大小以微秒为单位指定，格式为无符号整数。
Optional parameters:
可选参数：
o P: The value of this parameter is the FEC Framework Configuration Information element, Payload ID Format, as defined in [RFC6681]. The default value of this parameter (when it does not appear explicitly) is 'A'.
o P：该参数的值是FEC框架配置信息元素，即[RFC6681]中定义的有效负载ID格式。此参数的默认值（当它没有显式显示时）为“A”。
Encoding considerations: This media type is framed and binary; see Section 4.8 in [RFC4288]
编码注意事项：此媒体类型为框架和二进制；参见[RFC4288]中的第4.8节
Security considerations: Please see the security considerations in [RFC6363].
安全注意事项：请参见[RFC6363]中的安全注意事项。
Interoperability considerations:
互操作性注意事项：
Published specification: [RFC6681]
已发布规范：[RFC6681]
Applications that use this media type: Real-time multimedia applications like video streaming, audio streaming, and video conferencing.
使用此媒体类型的应用程序：实时多媒体应用程序，如视频流、音频流和视频会议。
Additional information:
其他信息：
Magic number(s): <none defined>
Magic number(s): <none defined>
File extension(s): <none defined>
File extension(s): <none defined>
Macintosh file type code(s): <none defined>
Macintosh file type code(s): <none defined>
Person & email address to contact for further information: Thomas Stockhammer, stockhammer@nomor.de
联系人和电子邮件地址，以获取更多信息：Thomas Stockhammer，stockhammer@nomor.de
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author: Thomas Stockhammer, Nomor Research
作者：Thomas Stockhammer，Nomor Research
Change controller: IETF PAYLOAD working group delegated from the IESG.
变更控制员：IESG授权的IETF有效载荷工作组。
This RTP payload format is identified using the 'video/raptorfec' media type that is registered in accordance with [RFC4855] and uses the template of [RFC4288].
该RTP有效负载格式使用根据[RFC4855]注册并使用[RFC4288]模板的“视频/raptorfec”媒体类型识别。
Type name: video
类型名称：视频
Subtype name: raptorfec
子类型名称：raptorfec
Required parameters:
所需参数：
o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) rate is specified in Hz and the format is unsigned integer.
o 速率：RTP时间戳（时钟）速率。RTP时间戳（时钟）速率以Hz为单位指定，格式为无符号整数。
o raptor-scheme-id: The value of this parameter is the FEC Scheme ID for the specific Raptor FEC Scheme that will be used as defined in [RFC6681].
o raptor方案id：此参数的值是特定raptor FEC方案的FEC方案id，该方案将按照[RFC6681]中的定义使用。
o Kmax: The value of this parameter is the FEC Framework Configuration Information element, MSBL, as defined in [RFC6681], encoded as a unsigned integer. For specific requirements for this value, refer to [RFC6681].
o Kmax:此参数的值是[RFC6681]中定义的FEC框架配置信息元素MSBL，编码为无符号整数。有关该值的具体要求，请参阅[RFC6681]。
o T: The value of this parameter is the FEC Framework Configuration Information element, encoding symbol size, as defined in [RFC6681], encoded as a unsigned integer. For specific requirements for this value, refer to [RFC6681].
o T：此参数的值是FEC框架配置信息元素，编码符号大小，如[RFC6681]中所定义，编码为无符号整数。有关该值的具体要求，请参阅[RFC6681]。
o repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds, and the format is unsigned integer.
o 修复窗口：跨越源数据包和相应修复数据包的最长时间。修复窗口的大小以微秒为单位指定，格式为无符号整数。
Optional parameters:
可选参数：
o P: The value of this parameter is the FEC Framework Configuration Information element, Payload ID Format, as defined in [RFC6681]. The default value of this parameter (when it does not appear explicitly) is 'A'.
o P：该参数的值是FEC框架配置信息元素，即[RFC6681]中定义的有效负载ID格式。此参数的默认值（当它没有显式显示时）为“A”。
Encoding considerations: This media type is framed and binary; see Section 4.8 in [RFC4288].
编码注意事项：此媒体类型为框架和二进制；参见[RFC4288]中的第4.8节。
Security considerations: Please see the security considerations in [RFC6363].
安全注意事项：请参见[RFC6363]中的安全注意事项。
Interoperability considerations:
互操作性注意事项：
Published specification: [RFC6681]
已发布规范：[RFC6681]
Applications that use this media type: Real-time multimedia applications like video streaming, audio streaming, and video conferencing.
使用此媒体类型的应用程序：实时多媒体应用程序，如视频流、音频流和视频会议。
Additional information:
其他信息：
Magic number(s): <none defined>
Magic number(s): <none defined>
File extension(s): <none defined>
File extension(s): <none defined>
Macintosh file type code(s): <none defined>
Macintosh file type code(s): <none defined>
Person & email address to contact for further information: Thomas Stockhammer, stockhammer@nomor.de
联系人和电子邮件地址，以获取更多信息：Thomas Stockhammer，stockhammer@nomor.de
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author: Thomas Stockhammer, Nomor Research.
作者：Thomas Stockhammer，Nomor Research。
Change controller: IETF PAYLOAD working group delegated from the IESG.
变更控制员：IESG授权的IETF有效载荷工作组。
This RTP payload format is identified using the 'audio/raptorfec' media type that is registered in accordance with [RFC4855] and uses the template of [RFC4288].
该RTP有效负载格式使用根据[RFC4855]注册并使用[RFC4288]模板的“音频/raptorfec”媒体类型识别。
Type name: audio
类型名称：音频
Subtype name: raptorfec
子类型名称：raptorfec
Required parameters:
所需参数：
o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) rate is specified in Hz and the format is unsigned integer.
o 速率：RTP时间戳（时钟）速率。RTP时间戳（时钟）速率以Hz为单位指定，格式为无符号整数。
o raptor-scheme-id: The value of this parameter is the FEC Scheme ID for the specific Raptor FEC Scheme that will be used as defined in [RFC6681].
o raptor方案id：此参数的值是特定raptor FEC方案的FEC方案id，该方案将按照[RFC6681]中的定义使用。
o Kmax: The value of this parameter is the FEC Framework Configuration Information element, MSBL, as defined in [RFC6681], encoded as a unsigned integer. For specific requirements for this value, refer to [RFC6681].
o Kmax:此参数的值是[RFC6681]中定义的FEC框架配置信息元素MSBL，编码为无符号整数。有关该值的具体要求，请参阅[RFC6681]。
o T: The value of this parameter is the FEC Framework Configuration Information element, encoding symbol size, as defined in [RFC6681], encoded as a unsigned integer. For specific requirements for this value, refer to [RFC6681].
o T：此参数的值是FEC框架配置信息元素，编码符号大小，如[RFC6681]中所定义，编码为无符号整数。有关该值的具体要求，请参阅[RFC6681]。
o repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds and the format is unsigned integer.
o 修复窗口：跨越源数据包和相应修复数据包的最长时间。修复窗口的大小以微秒为单位指定，格式为无符号整数。
Optional parameters:
可选参数：
o P: The value of this parameter is the FEC Framework Configuration Information element, Payload ID Format, as defined in [RFC6681]. The default value of this parameter (when it does not appear explicitly) is 'A'.
o P：该参数的值是FEC框架配置信息元素，即[RFC6681]中定义的有效负载ID格式。此参数的默认值（当它没有显式显示时）为“A”。
Encoding considerations: This media type is framed and binary; see Section 4.8 in [RFC4288].
编码注意事项：此媒体类型为框架和二进制；参见[RFC4288]中的第4.8节。
Security considerations: Please see the security considerations in [RFC6363].
安全注意事项：请参见[RFC6363]中的安全注意事项。
Interoperability considerations:
互操作性注意事项：
Published specification: [RFC6681]
已发布规范：[RFC6681]
Applications that use this media type: Real-time multimedia applications like video streaming, audio streaming, and video conferencing.
使用此媒体类型的应用程序：实时多媒体应用程序，如视频流、音频流和视频会议。
Additional information:
其他信息：
Magic number(s): <none defined>
Magic number(s): <none defined>
File extension(s): <none defined>
File extension(s): <none defined>
Macintosh file type code(s): <none defined>
Macintosh file type code(s): <none defined>
Person & email address to contact for further information: Thomas Stockhammer, stockhammer@nomor.de
联系人和电子邮件地址，以获取更多信息：Thomas Stockhammer，stockhammer@nomor.de
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author: Thomas Stockhammer, Nomor Research.
作者：Thomas Stockhammer，Nomor Research。
Change controller: IETF PAYLOAD working group delegated from the IESG.
变更控制员：IESG授权的IETF有效载荷工作组。
This RTP payload format is identified using the 'text/raptorfec' media type that is registered in accordance with [RFC4855] and uses the template of [RFC4288].
该RTP有效负载格式使用根据[RFC4855]注册并使用[RFC4288]模板的“text/raptorfec”媒体类型识别。
Type name: text
类型名称：text
Subtype name: raptorfec
子类型名称：raptorfec
Required parameters:
所需参数：
o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) rate is specified in Hz and the format is unsigned integer.
o 速率：RTP时间戳（时钟）速率。RTP时间戳（时钟）速率以Hz为单位指定，格式为无符号整数。
o raptor-scheme-id: The value of this parameter is the FEC Scheme ID for the specific Raptor FEC Scheme that will be used as defined in [RFC6681].
o raptor方案id：此参数的值是特定raptor FEC方案的FEC方案id，该方案将按照[RFC6681]中的定义使用。
o Kmax: The value of this parameter is the FEC Framework Configuration Information element, MSBL, as defined in [RFC6681], encoded as a unsigned integer. For specific requirements for this value, refer to [RFC6681].
o Kmax:此参数的值是[RFC6681]中定义的FEC框架配置信息元素MSBL，编码为无符号整数。有关该值的具体要求，请参阅[RFC6681]。
o T: The value of this parameter is the FEC Framework Configuration Information element, encoding symbol size, as defined in [RFC6681], encoded as a unsigned integer. For specific requirements for this value, refer to [RFC6681].
o T：此参数的值是FEC框架配置信息元素，编码符号大小，如[RFC6681]中所定义，编码为无符号整数。有关该值的具体要求，请参阅[RFC6681]。
o repair-window: The maximum time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds and the format is unsigned integer.
o 修复窗口：跨越源数据包和相应修复数据包的最长时间。修复窗口的大小以微秒为单位指定，格式为无符号整数。
Optional parameters:
可选参数：
o P: The value of this parameter is the FEC Framework Configuration Information element, Payload ID Format, as defined in [RFC6681]. The default value of this parameter (when it does not appear explicitly) is 'A'.
o P：该参数的值是FEC框架配置信息元素，即[RFC6681]中定义的有效负载ID格式。此参数的默认值（当它没有显式显示时）为“A”。
Encoding considerations: This media type is framed and binary; see Section 4.8 in [RFC4288].
编码注意事项：此媒体类型为框架和二进制；参见[RFC4288]中的第4.8节。
Security considerations: Please see the security considerations in [RFC6363].
安全注意事项：请参见[RFC6363]中的安全注意事项。
Interoperability considerations:
互操作性注意事项：
Published specification: [RFC6681]
已发布规范：[RFC6681]
Applications that use this media type: Real-time multimedia applications like video streaming, audio streaming, and video conferencing.
使用此媒体类型的应用程序：实时多媒体应用程序，如视频流、音频流和视频会议。
Additional information:
其他信息：
Magic number(s): <none defined>
Magic number(s): <none defined>
File extension(s): <none defined>
File extension(s): <none defined>
Macintosh file type code(s): <none defined>
Macintosh file type code(s): <none defined>
Person & email address to contact for further information: Thomas Stockhammer, stockhammer@nomor.de
联系人和电子邮件地址，以获取更多信息：Thomas Stockhammer，stockhammer@nomor.de
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author: Thomas Stockhammer, Nomor Research.
作者：Thomas Stockhammer，Nomor Research。
Change controller: IETF PAYLOAD working group delegated from the IESG.
变更控制员：IESG授权的IETF有效载荷工作组。
Applications that are using RTP transport commonly use the Session Description Protocol (SDP) [RFC4566] to describe their RTP sessions. The information that is used to specify the media types in an RTP session has specific mappings to the fields in an SDP description. Note that if an application does not use SDP to describe the RTP sessions, an appropriate mapping must be defined and used to specify the media types and their parameters for the control/description protocol employed by the application.
使用RTP传输的应用程序通常使用会话描述协议（SDP）[RFC4566]来描述其RTP会话。用于指定RTP会话中的媒体类型的信息具有到SDP描述中的字段的特定映射。请注意，如果应用程序不使用SDP来描述RTP会话，则必须定义并使用适当的映射来指定应用程序使用的控制/描述协议的媒体类型及其参数。
The mapping of the above defined payload format media type and its parameters SHALL be done according to Section 3 of [RFC4855], following the suggestion therein regarding the mapping of payload-format-specific parameters into the "a=fmtp" field.
应按照[RFC4855]第3节中关于有效载荷格式特定参数映射到“a=fmtp”字段的建议，映射上述定义的有效载荷格式媒体类型及其参数。
When the RTP payload formats defined in this document are used, the media type parameters defined above MUST use the media types in this document and MUST NOT use those specified in [RFC6364].
使用本文档中定义的RTP有效负载格式时，上述定义的媒体类型参数必须使用本文档中的媒体类型，不得使用[RFC6364]中指定的媒体类型。
When offering Raptor FEC over RTP using SDP in an Offer/Answer model [RFC3264], the following considerations apply:
在报价/应答模型[RFC3264]中使用SDP通过RTP提供猛禽FEC时，应考虑以下因素：
o Each combination of the Kmax and T parameters produces different FEC data and is not compatible with any other combination. A sender application MAY desire to provide multiple offers with different sets of Kmax and T values, which is possible as long as the parameter values are valid. The receiver SHOULD normally choose the offer with the largest value of the product of Kmax and T that it supports.
o Kmax和T参数的每个组合产生不同的FEC数据，并且与任何其他组合不兼容。发送方应用程序可能希望提供具有不同Kmax和T值集的多个报价，只要参数值有效，这是可能的。接收方通常应选择其支持的Kmax和T产品价值最大的报价。
o The size of the repair window is related to the maximum delay between the transmission of a source packet and the associated repair packet. This directly impacts the buffering requirement on the receiver side and the receiver must consider this when choosing an offer.
o 修复窗口的大小与源分组的传输和相关联的修复分组之间的最大延迟有关。这直接影响接收机侧的缓冲需求，而接收机在选择要约时必须考虑这一点。
o When the P parameter is not present, the receiver MUST use FEC Payload ID Format A. In an answer that selects an offer in which the P parameter was omitted, the P parameter MUST either be omitted, or included with value "A".
o 当P参数不存在时，接收机必须使用FEC有效负载ID格式A。在选择省略P参数的报价的应答中，P参数必须被省略，或包含在值“A”中。
In declarative usage, like SDP in the Real-Time Streaming Protocol (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) [RFC2974], the following considerations apply:
在声明性使用中，如实时流协议（RTSP）[RFC2326]或会话公告协议（SAP）[RFC2974]中的SDP，以下注意事项适用：
o The payload format configuration parameters are all declarative and a participant MUST use the configuration that is provided for the session.
o 有效负载格式配置参数都是声明性的，参与者必须使用为会话提供的配置。
o More than one configuration MAY be provided (if desired) by declaring multiple RTP payload types. In this case, the receivers should choose the repair session that is best for them.
o 通过声明多个RTP有效负载类型，可以提供多个配置（如果需要）。在这种情况下，接收方应选择最适合自己的修复会话。
This document only specifies repair flow construction when the repair packets are delivered with RTP. Source packet construction is covered in [RFC6681]. This section provides an overview on how to generate a repair flow, including the repair packets and how to reconstruct missing source packets from a set of available source and repair packets. Detailed algorithms for the generation of Raptor and RaptorQ symbols are provided in [RFC5053] and [RFC6330], respectively.
本文件仅规定维修包随RTP交付时的维修流程构造。[RFC6681]中介绍了源数据包的构造。本节概述如何生成修复流，包括修复数据包，以及如何从一组可用的源数据包和修复数据包重建丢失的源数据包。[RFC5053]和[RFC6330]分别提供了生成Raptor和RaptorQ符号的详细算法。
As per the FEC Framework document [RFC6363], the FEC Framework Configuration Information includes, among others, the identification of the repair flow(s) and the source flow(s). Methods to convey FEC Framework Configuration Information are provided in [FEC-SIG]. Specifically, the reader is referred to the SDP elements document [RFC6364], which describes the usage of the 'SDP' encoding format as an example encoding format for FEC Framework Configuration Information.
根据FEC框架文件[RFC6363]，FEC框架配置信息包括修复流和源流的标识。[FEC-SIG]中提供了传递FEC框架配置信息的方法。具体而言，读者可以参考SDP元素文档[RFC6364]，该文档描述了“SDP”编码格式作为FEC框架配置信息的示例编码格式的用法。
For the generation of a repair flow:
要生成维修流程，请执行以下操作：
o repair packets SHALL be constructed according to Section 10.2, and
o 修理包应按照第10.2节的要求建造，以及
o RTCP SHALL be used according to Section 10.3.
o 应根据第10.3节使用RTCP。
For the reconstruction of a source packet of a source RTP session at the receiver, based on the availability of a source RTP session and a repair RTP session, the procedures in Section 10.4 may be used.
对于在接收器处基于源RTP会话和修复RTP会话的可用性重建源RTP会话的源分组，可使用第10.4节中的程序。
The construction of the repair packet is fully specified in Section 4. A repair packet is constructed by the concatenation of
第4节详细说明了修理包的结构。一个修复包是由
o an RTP header as specified in Section 4.1, and
o 第4.1节规定的RTP标头，以及
o payload data as defined in Section 4.3.
o 第4.3节中定义的有效载荷数据。
Repair Packet Construction may make use of the Sender Operation for RTP repair flows as specified in see [RFC6363], Section 4.2.
修复包构造可利用发送方操作进行RTP修复流，如[RFC6363]第4.2节所述。
RTCP SHALL be used according to [RFC3550]. If the repair RTP session is sent in a separate RTP session, the two sessions MUST be associated using RTCP CNAME (Canonical Name).
应根据[RFC3550]使用RTCP。如果修复RTP会话在单独的RTP会话中发送，则必须使用RTCP CNAME（规范名称）关联这两个会话。
Source Packet Reconstruction may make use of the receiver operation for the case of RTP repair flows as specified in [RFC6363], Section 4.3. Depending on the FEC Scheme using the ones defined in [RFC6681], the appropriate source blocks are formed. If enough data for decoding any or all of the missing source payloads in the source block has been received, the respective FEC decoding procedures are applied.
如[RFC6363]第4.3节所述，在RTP修复流的情况下，源数据包重构可利用接收器操作。根据使用[RFC6681]中定义的FEC方案，形成适当的源块。如果已经接收到用于解码源块中的任何或所有缺失源有效载荷的足够数据，则应用相应的FEC解码过程。
In case the FEC Scheme uses Raptor codes as defined in [RFC5053], then the Example FEC Decoder, as specified in [RFC5053], Section 5.5, may be used.
如果FEC方案使用[RFC5053]中定义的Raptor码，则可使用[RFC5053]第5.5节中规定的示例FEC解码器。
In case the FEC Scheme uses RaptorQ codes as defined in [RFC6330], then the Example FEC Decoder, as specified in [RFC6330], Section 5.4, may be used.
如果FEC方案使用[RFC6330]中定义的RaptorQ码，则可使用[RFC6330]第5.4节中规定的示例FEC解码器。
This section provides an SDP [RFC4566] example. Assume we have one source video stream (mid:S1) and one FEC repair stream (mid:R1). The 'group' attribute and the FEC grouping semantics defined in [RFC5888] and [RFC5956], respectively, are used to associate source and repair flows. We form one FEC group with the "a=group:FEC S1 R1" line. The source and repair streams are sent to the same port on different multicast groups. The repair window is set to 200 ms.
本节提供了一个SDP[RFC4566]示例。假设我们有一个源视频流（mid:S1）和一个FEC修复流（mid:R1）。[RFC5888]和[RFC5956]中分别定义的“group”属性和FEC分组语义用于关联源流和修复流。我们用“a=组：FEC S1 R1”行组成一个FEC组。源和修复流被发送到不同多播组上的同一端口。维修窗口设置为200毫秒。
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=Raptor RTP FEC Example
t=0 0
a=group:FEC-FR S1 R1
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=application 30000 RTP/AVP 110
c=IN IP4 233.252.0.2/127
a=rtpmap:110 raptorfec/90000
a=fmtp:110 raptor-scheme-id=1; Kmax=8192; T=128;
P=A; repair-window=200000
a=mid:R1
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=Raptor RTP FEC Example
t=0 0
a=group:FEC-FR S1 R1
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=application 30000 RTP/AVP 110
c=IN IP4 233.252.0.2/127
a=rtpmap:110 raptorfec/90000
a=fmtp:110 raptor-scheme-id=1; Kmax=8192; T=128;
P=A; repair-window=200000
a=mid:R1
IANA has registered 'application/raptorfec' as specified in Section 6.1.1, 'video/raptorfec' as specified in Section 6.2.1, 'audio/raptorfec' as specified in Section 6.3.1, and 'text/raptorfec' as specified in Section 6.4.1. The media type has also been added to the IANA registry for "RTP Payload Format media types" (http://www.iana.org/assignments/rtp-parameters).
IANA已按照第6.1.1节的规定注册了“应用程序/raptorfec”，按照第6.2.1节的规定注册了“视频/raptorfec”，按照第6.3.1节的规定注册了“音频/raptorfec”，按照第6.4.1节的规定注册了“文本/raptorfec”。媒体类型也已添加到IANA注册表中，用于“RTP有效负载格式媒体类型”(http://www.iana.org/assignments/rtp-parameters).
Security Considerations related to the use of the FEC Framework are addressed in [RFC6363]. These considerations apply in full to users of the RTP payload formats defined in this document, since these are defined in terms of the FEC Framework.
[RFC6363]中阐述了与FEC框架使用相关的安全注意事项。这些注意事项完全适用于本文档中定义的RTP有效负载格式的用户，因为这些格式是根据FEC框架定义的。
No further security considerations related specifically to the Raptor FEC Schemes defined in [RFC6681] have been identified.
尚未确定与[RFC6681]中定义的Raptor FEC方案具体相关的进一步安全注意事项。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encrypting the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. Such a cryptographic system can also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining if an RTP packet
使用本规范中定义的有效负载格式的RTP数据包应遵守RTP规范[RFC3550]和任何适用RTP配置文件中讨论的安全注意事项。携带本备忘录中定义的RTP有效载荷格式的RTP数据包的主要安全注意事项是机密性、完整性和源真实性。机密性是通过加密RTP有效负载来实现的。RTP数据包的完整性是通过合适的密码完整性保护机制实现的。这样的密码系统还可以允许对有效载荷的源进行身份验证。此RTP有效负载格式的适当安全机制应提供机密性、完整性保护，以及至少能够确定RTP数据包是否存在的源身份验证
is from a member of the RTP session. Note that the appropriate mechanism to provide security to RTP and payloads following this memo MAY vary. It is dependent on the application, transport, and signaling protocol employed. Therefore, a single mechanism is not sufficient; although, if suitable, using the Secure Real-Time Transport Protocol (SRTP) [RFC3711] is RECOMMENDED. Other mechanisms that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives exist.
来自RTP会话的成员。请注意，根据本备忘录为RTP和有效负载提供安全性的适当机制可能会有所不同。它取决于所采用的应用程序、传输和信令协议。因此，单一的机制是不够的；但是，如果合适，建议使用安全实时传输协议（SRTP）[RFC3711]。可使用的其他机制包括IPsec[RFC4301]和传输层安全（TLS）[RFC5246]（TCP上的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月。
[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月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855]Casner，S.，“RTP有效负载格式的媒体类型注册”，RFC 48552007年2月。
[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月。
[RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, October 2011.
[RFC6364]Begen，A.，“前向纠错（FEC）框架的会话描述协议元素”，RFC6364，2011年10月。
[RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward Error Correction (FEC) Schemes for FECFRAME", RFC 6681, August 2012.
[RFC6681]Watson，M.，Stockhammer，T.，和M.Luby，“FEC帧的猛禽前向纠错（FEC）方案”，RFC 66812012年8月。
[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月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, "Raptor Forward Error Correction Scheme for Object Delivery", RFC 5053, October 2007.
[RFC5053]Luby，M.，Shokrollahi，A.，Watson，M.，和T.Stockhammer，“用于对象交付的猛禽前向纠错方案”，RFC 5053，2007年10月。
[RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and L. Minder, "RaptorQ Forward Error Correction Scheme for Object Delivery", RFC 6330, August 2011.
[RFC6330]Luby，M.，Shokrollahi，A.，Watson，M.，Stockhammer，T.，和L.Minder，“用于对象交付的RaptorQ前向纠错方案”，RFC 6330，2011年8月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[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月。
[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月。
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, September 2010.
[RFC5956]Begen，A.“会话描述协议中的前向纠错分组语义”，RFC 59562010年9月。
[FEC-SIG] Asati, R., "Methods to convey FEC Framework Configuration Information", Work in Progress, February 2012.
[FEC-SIG]Asati，R.，“传达FEC框架配置信息的方法”，正在进行的工作，2012年2月。
Authors' Addresses
作者地址
Mark Watson Netflix 100 Winchester Circle Los Gatos, CA 95032 United States
马克·沃森·Netflix 100温彻斯特圈洛斯加托斯，加利福尼亚州，美国95032
EMail: watsonm@netflix.com
EMail: watsonm@netflix.com
Thomas Stockhammer Nomor Research Brecherspitzstrasse 8 Munich 81541 Germany
Thomas Stockhammer Nomor Research Brecherspitzstrasse 8慕尼黑81541德国
EMail: stockhammer@nomor.de
EMail: stockhammer@nomor.de
Michael Luby Qualcomm Research Berkeley 2030 Addison Street Berkeley, CA 94704 United States
美国加利福尼亚州伯克利艾迪生街2030号伯克利高通研究院迈克尔·鲁比，邮编94704
EMail: luby@qualcomm.com
EMail: luby@qualcomm.com