Internet Engineering Task Force (IETF) M. Zanaty
Request for Comments: 8627 Cisco
Category: Standards Track V. Singh
ISSN: 2070-1721 callstats.io
A. Begen
Networked Media
G. Mandyam
Qualcomm Inc.
July 2019
Internet Engineering Task Force (IETF) M. Zanaty
Request for Comments: 8627 Cisco
Category: Standards Track V. Singh
ISSN: 2070-1721 callstats.io
A. Begen
Networked Media
G. Mandyam
Qualcomm Inc.
July 2019
RTP Payload Format for Flexible Forward Error Correction (FEC)
用于灵活前向纠错（FEC）的RTP有效负载格式
Abstract
摘要
This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP. These parity codes are systematic codes (Flexible FEC, or "FLEX FEC"), where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams. These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes that are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of complexity. The RTP payload formats that are defined in this document address scalability issues experienced with the earlier specifications and offer several improvements. Due to these changes, the new payload formats are not backward compatible with earlier specifications; however, endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets.
本文档为前向纠错（FEC）数据包定义了新的RTP有效载荷格式，前向纠错（FEC）数据包由RTP封装的源媒体中的非交织奇偶校验码和交织奇偶校验码生成。这些奇偶校验码是系统码（Flexible-FEC，或“FLEX-FEC”），其中从来自一个或多个源RTP流的一组源分组生成多个FEC修复分组。这些FEC修复包在冗余RTP流中发送，该冗余RTP流与承载源包的源RTP流分离。传输中丢失的RTP源数据包可以使用接收到的源数据包和修复数据包来重建。本规范中定义的非交织奇偶校验码和交织奇偶校验码分别以复杂性为代价提供了针对随机和突发数据包丢失的良好保护。本文档中定义的RTP有效负载格式解决了早期规范中遇到的可伸缩性问题，并提供了一些改进。由于这些变化，新的有效载荷格式与早期规范不向后兼容；但是，不实现此规范的端点仍然可以通过忽略FEC修复数据包来工作。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8627.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8627.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Parity Codes . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. One-Dimensional (1-D) Non-interleaved (Row) FEC
Protection . . . . . . . . . . . . . . . . . . . . . 5
1.1.2. 1-D Interleaved (Column) FEC Protection . . . . . . . 6
1.1.3. Use Cases for 1-D FEC Protection . . . . . . . . . . 7
1.1.4. Two-Dimensional (2-D) (Row and Column) FEC Protection 8
1.1.5. FEC Protection with Flexible Mask . . . . . . . . . . 10
1.1.6. FEC Overhead Considerations . . . . . . . . . . . . . 10
1.1.7. FEC Protection with Retransmission . . . . . . . . . 10
1.1.8. Repair Window Considerations . . . . . . . . . . . . 11
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 11
3. Definitions and Notations . . . . . . . . . . . . . . . . . . 11
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . 12
4.2. FEC Repair Packets . . . . . . . . . . . . . . . . . . . 13
4.2.1. RTP Header of FEC Repair Packets . . . . . . . . . . 13
4.2.2. FEC Header of FEC Repair Packets . . . . . . . . . . 15
5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 20
5.1. Media Type Registration -- Parity Codes . . . . . . . . . 20
5.1.1. Registration of audio/flexfec . . . . . . . . . . . . 21
5.1.2. Registration of video/flexfec . . . . . . . . . . . . 22
5.1.3. Registration of text/flexfec . . . . . . . . . . . . 23
5.1.4. Registration of application/flexfec . . . . . . . . . 24
5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 25
5.2.1. Offer/Answer Model Considerations . . . . . . . . . . 25
5.2.2. Declarative Considerations . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Parity Codes . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. One-Dimensional (1-D) Non-interleaved (Row) FEC
Protection . . . . . . . . . . . . . . . . . . . . . 5
1.1.2. 1-D Interleaved (Column) FEC Protection . . . . . . . 6
1.1.3. Use Cases for 1-D FEC Protection . . . . . . . . . . 7
1.1.4. Two-Dimensional (2-D) (Row and Column) FEC Protection 8
1.1.5. FEC Protection with Flexible Mask . . . . . . . . . . 10
1.1.6. FEC Overhead Considerations . . . . . . . . . . . . . 10
1.1.7. FEC Protection with Retransmission . . . . . . . . . 10
1.1.8. Repair Window Considerations . . . . . . . . . . . . 11
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 11
3. Definitions and Notations . . . . . . . . . . . . . . . . . . 11
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . 12
4.2. FEC Repair Packets . . . . . . . . . . . . . . . . . . . 13
4.2.1. RTP Header of FEC Repair Packets . . . . . . . . . . 13
4.2.2. FEC Header of FEC Repair Packets . . . . . . . . . . 15
5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 20
5.1. Media Type Registration -- Parity Codes . . . . . . . . . 20
5.1.1. Registration of audio/flexfec . . . . . . . . . . . . 21
5.1.2. Registration of video/flexfec . . . . . . . . . . . . 22
5.1.3. Registration of text/flexfec . . . . . . . . . . . . 23
5.1.4. Registration of application/flexfec . . . . . . . . . 24
5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 25
5.2.1. Offer/Answer Model Considerations . . . . . . . . . . 25
5.2.2. Declarative Considerations . . . . . . . . . . . . . 26
6. Protection and Recovery Procedures -- Parity Codes . . . . . 26
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2. Repair Packet Construction . . . . . . . . . . . . . . . 26
6.3. Source Packet Reconstruction . . . . . . . . . . . . . . 28
6.3.1. Associating the Source and Repair Packets . . . . . . 28
6.3.2. Recovering the RTP Header . . . . . . . . . . . . . . 30
6.3.3. Recovering the RTP Payload . . . . . . . . . . . . . 31
6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC
Protection . . . . . . . . . . . . . . . . . . . . . 31
7. Signaling Requirements . . . . . . . . . . . . . . . . . . . 34
7.1. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 35
7.1.1. Example SDP for Flexible FEC Protection with In-Band
SSRC Mapping . . . . . . . . . . . . . . . . . . . . 35
7.1.2. Example SDP for Flexible FEC Protection with Explicit
Signaling in the SDP . . . . . . . . . . . . . . . . 35
7.2. On the Use of the RTP Stream Identifier Source
Description . . . . . . . . . . . . . . . . . . . . . . . 36
8. Congestion Control Considerations . . . . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. Normative References . . . . . . . . . . . . . . . . . . 38
11.2. Informative References . . . . . . . . . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
6. Protection and Recovery Procedures -- Parity Codes . . . . . 26
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2. Repair Packet Construction . . . . . . . . . . . . . . . 26
6.3. Source Packet Reconstruction . . . . . . . . . . . . . . 28
6.3.1. Associating the Source and Repair Packets . . . . . . 28
6.3.2. Recovering the RTP Header . . . . . . . . . . . . . . 30
6.3.3. Recovering the RTP Payload . . . . . . . . . . . . . 31
6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC
Protection . . . . . . . . . . . . . . . . . . . . . 31
7. Signaling Requirements . . . . . . . . . . . . . . . . . . . 34
7.1. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 35
7.1.1. Example SDP for Flexible FEC Protection with In-Band
SSRC Mapping . . . . . . . . . . . . . . . . . . . . 35
7.1.2. Example SDP for Flexible FEC Protection with Explicit
Signaling in the SDP . . . . . . . . . . . . . . . . 35
7.2. On the Use of the RTP Stream Identifier Source
Description . . . . . . . . . . . . . . . . . . . . . . . 36
8. Congestion Control Considerations . . . . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. Normative References . . . . . . . . . . . . . . . . . . 38
11.2. Informative References . . . . . . . . . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
This document defines new RTP payload formats for the Forward Error Correction (FEC) that is generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP [RFC3550]. The type of the source media protected by these parity codes can be audio, video, text, or application. The FEC data are generated according to the media type parameters, which are communicated out of band (e.g., in the Session Description Protocol (SDP)). Furthermore, the associations or relationships between the source and repair RTP streams may be communicated in or out of band. The in-band mechanism is advantageous when the endpoint is adapting the FEC parameters. The out-of-band mechanism may be preferable when the FEC parameters are fixed. While this document fully defines the use of FEC to protect RTP streams, it also leverages several definitions along with the basic source/repair header description from [RFC6363] in their application to the parity codes defined here.
本文档为前向纠错（FEC）定义了新的RTP有效载荷格式，前向纠错（FEC）由RTP[RFC3550]中封装的源介质中的非交织奇偶校验码和交织奇偶校验码生成。受这些奇偶校验码保护的源媒体类型可以是音频、视频、文本或应用程序。FEC数据根据媒体类型参数生成，这些参数在带外（例如，在会话描述协议（SDP）中）通信。此外，源和修复RTP流之间的关联或关系可以在带内或带外进行通信。当端点调整FEC参数时，带内机制是有利的。当FEC参数固定时，带外机制可能是优选的。虽然本文档完全定义了使用FEC保护RTP流，但它还利用了几个定义以及[RFC6363]中的基本源/修复头描述，将其应用于此处定义的奇偶校验码。
The Redundancy RTP Stream [RFC7656] repair packets proposed in this document protect the Source RTP Stream packets that belong to the same RTP session.
本文档中提出的冗余RTP流[RFC7656]修复数据包保护属于同一RTP会话的源RTP流数据包。
The RTP payload formats that are defined in this document address the scalability issues experienced with the formats defined in earlier specifications including [RFC2733], [RFC5109], and [SMPTE2022-1].
本文档中定义的RTP有效负载格式解决了早期规范中定义的格式（包括[RFC2733]、[RFC5109]和[SMPTE2022-1]）遇到的可伸缩性问题。
Both the non-interleaved and interleaved parity codes use the eXclusive OR (XOR) operation to generate the repair packets. The following steps take place:
非交织奇偶校验码和交织奇偶校验码都使用异或（XOR）操作来生成修复包。执行以下步骤：
1. The sender determines a set of source packets to be protected by FEC based on the media type parameters.
1. 发送方基于媒体类型参数确定要由FEC保护的一组源分组。
2. The sender applies the XOR operation on the source packets to generate the required number of repair packets.
2. 发送方对源数据包应用XOR操作，以生成所需数量的修复数据包。
3. The sender sends the repair packet(s) along with the source packets, in different RTP streams, to the receiver(s). The repair packets may be sent proactively or on demand based on RTCP feedback messages such as NACK [RFC4585].
3. 发送方以不同的RTP流将修复包与源包一起发送到接收方。可以基于诸如NACK[RFC4585]之类的RTCP反馈消息主动或按需发送修复包。
At the receiver side, if all of the source packets are successfully received, there is no need for FEC recovery and the repair packets are discarded. However, if there are missing source packets, the repair packets can be used to recover the missing information. Figures 1 and 2 describe example block diagrams for the systematic parity FEC encoder and decoder, respectively.
在接收机侧，如果成功接收到所有源分组，则不需要FEC恢复，并且丢弃修复分组。然而，如果存在丢失的源数据包，则可以使用修复数据包来恢复丢失的信息。图1和图2分别描述了系统奇偶校验FEC编码器和解码器的示例框图。
+------------+
+--+ +--+ +--+ +--+ --> | Systematic | --> +--+ +--+ +--+ +--+
+--+ +--+ +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+
| Encoder |
| (Sender) | --> +==+ +==+
+------------+ +==+ +==+
+------------+
+--+ +--+ +--+ +--+ --> | Systematic | --> +--+ +--+ +--+ +--+
+--+ +--+ +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+
| Encoder |
| (Sender) | --> +==+ +==+
+------------+ +==+ +==+
Source Packet: +--+ Repair Packet: +==+
+--+ +==+
Source Packet: +--+ Repair Packet: +==+
+--+ +==+
Figure 1: Block Diagram for Systematic Parity FEC Encoder
图1：系统奇偶校验FEC编码器框图
+------------+
+--+ X X +--+ --> | Systematic | --> +--+ +--+ +--+ +--+
+--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+
| Decoder |
+==+ +==+ --> | (Receiver) |
+==+ +==+ +------------+
+------------+
+--+ X X +--+ --> | Systematic | --> +--+ +--+ +--+ +--+
+--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+
| Decoder |
+==+ +==+ --> | (Receiver) |
+==+ +==+ +------------+
Source Packet: +--+ Repair Packet: +==+ Lost Packet: X
+--+ +==+
Source Packet: +--+ Repair Packet: +==+ Lost Packet: X
+--+ +==+
Figure 2: Block Diagram for Systematic Parity FEC Decoder
图2：系统奇偶校验FEC解码器的框图
In Figure 2, it is clear that the FEC repair packets have to be received by the endpoint within a certain amount of time for the FEC recovery process to be useful. The repair window is defined as the time that spans a FEC block, which consists of the source packets and the corresponding repair packets. At the receiver side, the FEC decoder SHOULD buffer source and repair packets at least for the duration of the repair window to allow all the repair packets to arrive. The FEC decoder can start decoding the already-received packets sooner; however, it should not register a FEC decoding failure until it waits at least for the duration of the repair window.
在图2中，很明显，FEC修复包必须在一定的时间内由端点接收，以便FEC恢复过程有用。修复窗口定义为跨越FEC块的时间，该FEC块由源数据包和相应的修复数据包组成。在接收器侧，FEC解码器应至少在修复窗口期间缓冲源和修复分组，以允许所有修复分组到达。FEC解码器可以更快地开始解码已经接收到的分组；但是，在至少等待修复窗口的持续时间之前，不应注册FEC解码故障。
Consider a group of D x L source packets that have Sequence Numbers starting from 1 running to D x L (where D and L are as defined in Section 3.2) and a repair packet is generated by applying the XOR operation to every L consecutive packets as sketched in Figure 3. This process is referred to as "1-D non-interleaved FEC protection". As a result of this process, D repair packets are generated, which are referred to as non-interleaved (or row) FEC repair packets. In general, D and L represent values that describe how packets are grouped together from a depth and length perspective (respectively) when interleaving all D x L source packets.
考虑一组D x L源数据包，其序列号从1开始运行到D x L（其中D和L是在第3.2节中定义的），并且通过将XOR操作应用到每一个L连续包中生成修复包，如图3所示。该过程称为“1-D非交错FEC保护”。作为该处理的结果，生成了被称为非交织（或行）FEC修复分组的D个修复分组。通常，D和L表示的值描述了在交错所有D x L源数据包时，如何从深度和长度角度（分别）将数据包分组在一起。
+--------------------------------------------------+ --- +===+
| S_1 S_2 S3 ... S_L | + |XOR| = |R_1|
+--------------------------------------------------+ --- +===+
+--------------------------------------------------+ --- +===+
| S_L+1 S_L+2 S_L+3 ... S_2xL | + |XOR| = |R_2|
+--------------------------------------------------+ --- +===+
. . . . . .
. . . . . .
. . . . . .
+--------------------------------------------------+ --- +===+
| S_(D-1)xL+1 S_(D-1)xL+2 S_(D-1)xL+3 ... S_DxL | + |XOR| = |R_D|
+--------------------------------------------------+ --- +===+
+--------------------------------------------------+ --- +===+
| S_1 S_2 S3 ... S_L | + |XOR| = |R_1|
+--------------------------------------------------+ --- +===+
+--------------------------------------------------+ --- +===+
| S_L+1 S_L+2 S_L+3 ... S_2xL | + |XOR| = |R_2|
+--------------------------------------------------+ --- +===+
. . . . . .
. . . . . .
. . . . . .
+--------------------------------------------------+ --- +===+
| S_(D-1)xL+1 S_(D-1)xL+2 S_(D-1)xL+3 ... S_DxL | + |XOR| = |R_D|
+--------------------------------------------------+ --- +===+
Figure 3: Generating Non-interleaved (Row) FEC Repair Packets
图3：生成非交错（行）FEC修复包
Consider the case where the XOR operation is applied to the group of the source packets whose Sequence Numbers are L apart from each other, as sketched in Figure 4. In this case, the endpoint generates L repair packets. This process is referred to as "1-D interleaved FEC protection", and the resulting L repair packets are referred to as "interleaved (or column) FEC repair packets".
考虑XOR运算应用于序列号为L的源包组，如图4所示。在这种情况下，端点生成L个修复数据包。该过程被称为“1-D交错FEC保护”，并且产生的L个修复分组被称为“交错（或列）FEC修复分组”。
+-------------+ +-------------+ +-------------+ +-------+
| S_1 | | S_2 | | S3 | ... | S_L |
| S_L+1 | | S_L+2 | | S_L+3 | ... | S_2xL |
| . | | . | | | | |
| . | | . | | | | |
| . | | . | | | | |
| S_(D-1)xL+1 | | S_(D-1)xL+2 | | S_(D-1)xL+3 | ... | S_DxL |
+-------------+ +-------------+ +-------------+ +-------+
+ + + +
------------- ------------- ------------- -------
| XOR | | XOR | | XOR | ... | XOR |
------------- ------------- ------------- -------
= = = =
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| ... |C_L|
+===+ +===+ +===+ +===+
+-------------+ +-------------+ +-------------+ +-------+
| S_1 | | S_2 | | S3 | ... | S_L |
| S_L+1 | | S_L+2 | | S_L+3 | ... | S_2xL |
| . | | . | | | | |
| . | | . | | | | |
| . | | . | | | | |
| S_(D-1)xL+1 | | S_(D-1)xL+2 | | S_(D-1)xL+3 | ... | S_DxL |
+-------------+ +-------------+ +-------------+ +-------+
+ + + +
------------- ------------- ------------- -------
| XOR | | XOR | | XOR | ... | XOR |
------------- ------------- ------------- -------
= = = =
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| ... |C_L|
+===+ +===+ +===+ +===+
Figure 4: Generating Interleaved (Column) FEC Repair Packets
图4：生成交错（列）FEC修复包
A sender may generate one non-interleaved repair packet out of L consecutive source packets or one interleaved repair packet out of D nonconsecutive source packets. Regardless of whether the repair packet is a non-interleaved or an interleaved one, it can provide a full recovery of the missing information if there is only one packet missing among the corresponding source packets. This implies that 1-D non-interleaved FEC protection performs better when the source packets are randomly lost. However, if the packet losses occur in bursts, 1-D interleaved FEC protection performs better provided that L is chosen to be large enough, i.e., L-packet duration is not shorter than the observed burst duration. If the sender generates non-interleaved FEC repair packets and a burst loss hits the source packets, the repair operation fails. This is illustrated in Figure 5.
发送方可以从L个连续源分组中生成一个非交错修复分组，或者从D个非连续源分组中生成一个交错修复分组。无论修复分组是非交织的还是交织的，如果在相应的源分组中只有一个分组丢失，则它都可以提供丢失信息的完全恢复。这意味着，当源数据包随机丢失时，一维非交错FEC保护性能更好。然而，如果分组丢失发生在突发中，则1-D交错FEC保护执行得更好，前提是L被选择为足够大，即，L分组持续时间不短于观察到的突发持续时间。如果发送方生成非交织FEC修复数据包，并且突发丢失击中源数据包，则修复操作失败。这如图5所示。
+---+ +---+ +===+
| 1 | X X | 4 | |R_1|
+---+ +---+ +===+
+---+ +---+ +===+
| 1 | X X | 4 | |R_1|
+---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 5 | | 6 | | 7 | | 8 | |R_2|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 5 | | 6 | | 7 | | 8 | |R_2|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 9 | | 10| | 11| | 12| |R_3|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 9 | | 10| | 11| | 12| |R_3|
+---+ +---+ +---+ +---+ +===+
Figure 5: Example Scenario: 1-D Non-interleaved FEC Protection Fails Error Recovery (Burst Loss)
图5：示例场景：1-D非交错FEC保护失败错误恢复（突发丢失）
The sender may generate interleaved FEC repair packets to combat the bursty packet losses. However, two or more random packet losses may hit the source and repair packets in the same column. In that case, the repair operation fails as well. This is illustrated in Figure 6. Note that it is possible that two burst losses occur back-to-back, in which case, interleaved FEC repair packets may still fail to recover the lost data.
发送方可以生成交织的FEC修复分组来对抗突发性分组丢失。然而，两个或多个随机数据包丢失可能会击中源并修复同一列中的数据包。在这种情况下，修复操作也会失败。如图6所示。注意，两个突发丢失可能背靠背发生，在这种情况下，交织的FEC修复分组可能仍然无法恢复丢失的数据。
+---+ +---+ +---+
| 1 | X | 3 | | 4 |
+---+ +---+ +---+
+---+ +---+ +---+
| 1 | X | 3 | | 4 |
+---+ +---+ +---+
+---+ +---+ +---+
| 5 | X | 7 | | 8 |
+---+ +---+ +---+
+---+ +---+ +---+
| 5 | X | 7 | | 8 |
+---+ +---+ +---+
+---+ +---+ +---+ +---+
| 9 | | 10| | 11| | 12|
+---+ +---+ +---+ +---+
+---+ +---+ +---+ +---+
| 9 | | 10| | 11| | 12|
+---+ +---+ +---+ +---+
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| |C_4|
+===+ +===+ +===+ +===+
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| |C_4|
+===+ +===+ +===+ +===+
Figure 6: Example Scenario: 1-D Interleaved FEC Protection Fails Error Recovery (Periodic Loss)
图6：示例场景：1-D交错FEC保护失败错误恢复（周期性丢失）
In networks where the source packets are lost both randomly and in bursts, the sender ought to generate both non-interleaved and interleaved FEC repair packets. This type of FEC protection is known as "2-D parity FEC protection". At the expense of generating more FEC repair packets, thus increasing the FEC overhead, 2-D FEC provides superior protection against mixed loss patterns. However, it is still possible for 2-D parity FEC protection to fail to recover all of the lost source packets if a particular loss pattern occurs. An example scenario is illustrated in Figure 7.
在源数据包随机丢失和突发丢失的网络中，发送方应生成非交织和交织的FEC修复数据包。这种类型的FEC保护称为“二维奇偶校验FEC保护”。二维FEC以生成更多的FEC修复包为代价，从而增加了FEC开销，从而提供了针对混合丢失模式的优异保护。然而，如果发生特定的丢失模式，二维奇偶校验FEC保护仍然可能无法恢复所有丢失的源数据包。图7展示了一个示例场景。
+---+ +---+ +===+
| 1 | X X | 4 | |R_1|
+---+ +---+ +===+
+---+ +---+ +===+
| 1 | X X | 4 | |R_1|
+---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 5 | | 6 | | 7 | | 8 | |R_2|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 5 | | 6 | | 7 | | 8 | |R_2|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +===+
| 9 | X X | 12| |R_3|
+---+ +---+ +===+
+---+ +---+ +===+
| 9 | X X | 12| |R_3|
+---+ +---+ +===+
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| |C_4|
+===+ +===+ +===+ +===+
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| |C_4|
+===+ +===+ +===+ +===+
Figure 7: Example Scenario #1: 2-D Parity FEC Protection Fails Error Recovery
图7：示例场景#1:2-D奇偶校验FEC保护错误恢复失败
2-D parity FEC protection also fails when at least two rows are missing a source and the FEC packet and the missing source packets (in at least two rows) are aligned in the same column. An example loss pattern is sketched in Figure 8. Similarly, 2-D parity FEC protection cannot repair all missing source packets when at least two columns are missing a source and the FEC packet and the missing source packets (in at least two columns) are aligned in the same row.
当至少两行丢失源并且FEC数据包和丢失的源数据包（至少两行）在同一列中对齐时，二维奇偶校验FEC保护也会失败。图8中绘制了一个示例损失模式。类似地，当至少两列缺少源且FEC分组和丢失的源分组（至少两列中）在同一行中对齐时，二维奇偶校验FEC保护无法修复所有丢失的源分组。
+---+ +---+ +---+
| 1 | | 2 | X | 4 | X
+---+ +---+ +---+
+---+ +---+ +---+
| 1 | | 2 | X | 4 | X
+---+ +---+ +---+
+---+ +---+ +---+ +---+ +===+
| 5 | | 6 | | 7 | | 8 | |R_2|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 5 | | 6 | | 7 | | 8 | |R_2|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+
| 9 | | 10| X | 12| X
+---+ +---+ +---+
+---+ +---+ +---+
| 9 | | 10| X | 12| X
+---+ +---+ +---+
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| |C_4|
+===+ +===+ +===+ +===+
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| |C_4|
+===+ +===+ +===+ +===+
Figure 8: Example Scenario #2: 2-D Parity FEC Protection Fails Error Recovery
图8：示例场景#2：二维奇偶校验FEC保护错误恢复失败
It is possible to define FEC protection for selected packets in the source stream. This would enable differential protection, i.e., application of FEC selectively to packets that require a higher level of reliability than the other packets in the source stream. The sender will be required to send a bitmap indicating the packets to be protected, i.e., a "mask", to the receiver. Since the mask can be modified during an RTP session ("flexible mask"), this kind of FEC protection can also be used to implement FEC dynamically (e.g., for adaptation to different types of traffic during the RTP session).
可以为源流中的选定数据包定义FEC保护。这将启用差分保护，即，对需要比源流中的其他分组更高可靠性的分组选择性地应用FEC。发送方需要向接收方发送指示要保护的数据包的位图，即“掩码”。由于可以在RTP会话期间修改掩码（“灵活掩码”），因此这种FEC保护还可以用于动态地实现FEC（例如，用于在RTP会话期间适应不同类型的业务）。
The overhead is defined as the ratio of the number of bytes belonging to the repair packets to the number of bytes belonging to the protected source packets.
开销定义为属于修复数据包的字节数与属于受保护源数据包的字节数之比。
Generally, repair packets are larger in size than the source packets. Also, not all the source packets are necessarily equal in size. However, assuming that each repair packet carries an equal number of bytes as carried by a source packet, the overhead for different FEC protection methods can be computed as follows:
通常，修复包的大小大于源包。此外，并非所有源数据包的大小都必须相等。然而，假设每个修复分组承载的字节数与源分组承载的字节数相等，则不同FEC保护方法的开销可计算如下：
1-D Non-interleaved FEC Protection: Overhead = 1/L
1-D Non-interleaved FEC Protection: Overhead = 1/L
1-D Interleaved FEC Protection: Overhead = 1/D
1-D Interleaved FEC Protection: Overhead = 1/D
2-D Parity FEC Protection: Overhead = 1/L + 1/D
2-D Parity FEC Protection: Overhead = 1/L + 1/D
where L and D are the number of columns and rows in the source block, respectively.
其中L和D分别是源块中的列数和行数。
This specification supports both forward error correction, i.e., before any loss is reported, as well as retransmission of source packets after the loss is reported. The retransmission includes the RTP header of the source packet in addition to the payload. If a peer supporting both FLEX FEC and other RTP retransmission methods (see [RFC4588]) receives an Offer including both FLEX FEC and another RTP retransmission method, it MUST respond with an Answer containing only FLEX FEC.
该规范既支持前向纠错，即在报告任何丢失之前，也支持在报告丢失之后重新传输源数据包。除了有效载荷之外，重传还包括源分组的RTP报头。如果同时支持FLEX FEC和其他RTP重传方法的对等方（请参见[RFC4588]）收到包含FLEX FEC和另一个RTP重传方法的报价，则该对等方必须使用仅包含FLEX FEC的应答进行响应。
The value for the repair window duration is related to the maximum L and D values that are expected during a FLEX FEC session; therefore, it cannot be chosen arbitrarily. Repair packets that include L and D values larger than the repair window MUST NOT be sent. The rate of the source streams should also be considered, as the repair window duration should ideally span several packetization intervals in order to leverage the error correction capabilities of the parity code.
修复窗口持续时间的值与FLEX FEC会话期间预期的最大L和D值相关；因此，不能任意选择。不得发送包含大于修复窗口的L和D值的修复数据包。还应考虑源流的速率，因为修复窗口持续时间理想情况下应跨越多个分组间隔，以便利用奇偶校验码的纠错能力。
Because the FEC configuration can change with each repair packet (see Section 4.2.2), for any given repair packet, the FLEX FEC receiver MUST support all possible L and D combinations (both 1-D and 2-D interleaved over all source flows) and all flexible mask configurations (over all source flows) within the repair window to which it has agreed (e.g., through SDP or out-of-band signaling) for a FLEX FEC RTP session. In addition, the FLEX FEC receiver MUST support receipt of a retransmission of any source flow packet within the repair window to which it has agreed.
由于FEC配置可以随每个修复包（见第4.2.2节）而改变，因此对于任何给定的修复包，FLEX FEC接收器必须在其同意的修复窗口内支持所有可能的L和D组合（所有源流上的1-D和2-D交错）以及所有灵活的掩码配置（所有源流上的）（例如，通过SDP或带外信令）用于FLEX FEC RTP会话。此外，FLEX FEC接收器必须支持在其同意的修复窗口内接收任何源流数据包的重传。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document uses a number of definitions from [RFC6363]. Additionally, it defines the following and/or updates their definitions from [RFC6363].
本文件使用了[RFC6363]中的许多定义。此外，它定义了以下内容和/或更新了[RFC6363]中的定义。
1-D Non-interleaved Row FEC: A protection scheme that operates on consecutive source packets in the source block, able to recover a single lost source packet per row of the source block.
1-D非交错行FEC：一种保护方案，对源块中的连续源数据包进行操作，能够在源块的每行恢复单个丢失的源数据包。
1-D Interleaved Column FEC: A protection scheme that operates on interleaved source packets in the source block, able to recover a single lost source packet per column of the source block.
1-D交错列FEC：一种保护方案，对源块中的交错源数据包进行操作，能够在源块的每列恢复单个丢失的源数据包。
2-D FEC: A protection scheme that combines row and column FEC.
二维FEC：结合行和列FEC的保护方案。
Source Block: A set of source packets that are protected by a set of 1-D or 2-D FEC repair packets.
源块：由一组1-D或2-D FEC修复数据包保护的一组源数据包。
FEC Block: A source block and its corresponding FEC repair packets.
FEC块：源块及其相应的FEC修复包。
Repair Window: The time that spans a FEC block, which consists of the source packets and the corresponding FEC repair packets.
修复窗口：跨越FEC块的时间，由源数据包和相应的FEC修复数据包组成。
XOR Parity Codes: A FEC code that uses the eXclusive OR (XOR) parity operation to encode a set of source packets to form a FEC repair packet.
异或奇偶校验码：使用异或（XOR）奇偶校验操作对一组源数据包进行编码以形成FEC修复数据包的FEC码。
L: Number of columns of the source block (length of each row).
L：源块的列数（每行的长度）。
D: Number of rows of the source block (depth of each column).
D：源块的行数（每列的深度）。
bitmask: A 15-bit, 46-bit, or 110-bit mask indicating which source packets are protected by a FEC repair packet. If the bit i in the mask is set to 1, the source packet number N + i is protected by this FEC repair packet, where N is the Sequence Number base indicated in the FEC repair packet. The most significant bit of the mask corresponds to i=0. The least significant bit of the mask corresponds to i=14 in the 15-bit mask, i=45 in the 46-bit mask, or i=109 in the 110-bit mask.
位掩码：15位、46位或110位掩码，指示FEC修复数据包保护哪些源数据包。如果掩码中的位i设置为1，则源分组号N+i由该FEC修复分组保护，其中N是FEC修复分组中指示的序列号基数。掩码的最高有效位对应于i=0。掩码的最低有效位对应于15位掩码中的i=14、46位掩码中的i=45或110位掩码中的i=109。
This section describes the formats of the source packets and defines the formats of the FEC repair packets.
本节描述源数据包的格式，并定义FEC修复数据包的格式。
The source packets contain the information that identifies the source block and the position within the source block occupied by the packet. Since the source packets that are carried within an RTP stream already contain unique Sequence Numbers in their RTP headers [RFC3550], the source packets can be identified in a straightforward manner and there is no need to append any additional fields. The primary advantage of not modifying the source packets in any way is that it provides backward compatibility for the receivers that do not support FEC at all. In multicast scenarios, this backward compatibility becomes quite useful as it allows the non-FEC-capable and FEC-capable receivers to receive and interpret the same source packets sent in the same multicast session.
源数据包包含标识源块和数据包占用的源数据块内的位置的信息。由于RTP流中携带的源数据包在其RTP报头[RFC3550]中已经包含唯一的序列号，因此可以以简单的方式识别源数据包，并且无需附加任何附加字段。不以任何方式修改源数据包的主要优点是，它为根本不支持FEC的接收器提供向后兼容性。在多播场景中，这种向后兼容性非常有用，因为它允许不支持FEC和支持FEC的接收器接收和解释在同一多播会话中发送的相同源数据包。
The source packets are transmitted as usual without altering them. They are used along with the FEC repair packets to recover any missing source packets, making this scheme a systematic code.
源数据包照常传输，不改变它们。它们与FEC修复数据包一起用于恢复任何丢失的源数据包，使该方案成为一个系统代码。
The source packets are full RTP packets with optional contributing source (CSRC) list, RTP header extension, and padding. If any of these optional elements are present in the source RTP packet, and that source packet is lost, they are recovered by the FEC repair operation, which recovers the full source RTP packet including these optional elements.
源数据包是具有可选贡献源（CSC）列表、RTP头扩展和填充的完整RTP数据包。如果这些可选元素中的任何一个出现在源RTP数据包中，并且该源数据包丢失，则通过FEC修复操作恢复它们，该操作恢复包括这些可选元素的完整源RTP数据包。
The FEC repair packets will contain information that identifies the source block they pertain to and the relationship between the contained repair packets and the original source block. For this purpose, the RTP header of the repair packets is used, as well as another header within the RTP payload, called the "FEC header", as shown in Figure 9.
FEC修复包将包含标识其所属的源块以及所包含的修复包与原始源块之间的关系的信息。为此，使用修复包的RTP报头，以及RTP有效负载内的另一个报头，称为“FEC报头”，如图9所示。
Note that all the source stream packets that are protected by a particular FEC packet need to be in the same RTP session.
注意，受特定FEC分组保护的所有源流分组需要处于相同的RTP会话中。
+------------------------------+
| IP Header |
+------------------------------+
| Transport Header |
+------------------------------+
| RTP Header |
+------------------------------+ ---+
| FEC Header | |
+------------------------------+ | RTP Payload
| Repair Payload | |
+------------------------------+ ---+
+------------------------------+
| IP Header |
+------------------------------+
| Transport Header |
+------------------------------+
| RTP Header |
+------------------------------+ ---+
| FEC Header | |
+------------------------------+ | RTP Payload
| Repair Payload | |
+------------------------------+ ---+
Figure 9: Format of FEC Repair Packets
图9:FEC修复包的格式
The Repair Payload, which follows the FEC header, includes repair of everything following the fixed 12-byte RTP header of each source packet, including any CSRC identifier list and header extensions if present.
FEC报头之后的修复有效负载包括修复每个源分组的固定12字节RTP报头之后的所有内容，包括任何CSC标识符列表和报头扩展（如果存在）。
The RTP header is formatted according to [RFC3550] with some further clarifications listed below:
RTP标头根据[RFC3550]进行格式化，下面列出了一些进一步的说明：
Version (V) 2 bits: This MUST be set to 2 (binary 10), as this specification requires all source RTP packets and all FEC repair packets to use RTP version 2.
版本（V）2位：必须设置为2（二进制10），因为本规范要求所有源RTP数据包和所有FEC修复数据包使用RTP版本2。
Padding (P) bit: Source packets can have optional RTP padding, which can be recovered. FEC repair packets can have optional RTP padding, which is independent of the RTP padding of the source packets.
填充（P）位：源数据包可以有可选的RTP填充，可以恢复。FEC修复数据包可以具有可选的RTP填充，这独立于源数据包的RTP填充。
Extension (X) bit: Source packets can have optional RTP header extensions, which can be recovered. FEC repair packets can have optional RTP header extensions, which are independent of the RTP header extensions of the source packets.
扩展（X）位：源数据包可以有可选的RTP头扩展，可以恢复。FEC修复数据包可以具有可选的RTP报头扩展，它独立于源数据包的RTP报头扩展。
CSRC Count (CC) 4 bits, and CSRC List (CSRC_i) 32 bits each: Source packets can have an optional CSRC list and count, which can be recovered. FEC repair packets MUST use the CSRC list and count to specify the synchronization sources (SSRCs) of the source RTP stream(s) protected by this FEC repair packet.
CSC计数（CC）4位，CSC列表（CSC_i）32位：源数据包可以有可选的CSC列表和计数，可以恢复。FEC修复数据包必须使用CSC列表和计数来指定受此FEC修复数据包保护的源RTP流的同步源（SSRC）。
Marker (M) bit: This bit is not used for this payload type, SHALL be set to 0 by senders, and SHALL be ignored by receivers.
标记（M）位：该位不用于此有效负载类型，发送方应将其设置为0，接收方应忽略该位。
Payload Type: The (dynamic) payload type for the FEC repair packets is determined through out-of-band means (e.g., SDP). Note that this document registers new payload formats for the repair packets (refer to Section 5 for details). According to [RFC3550], an RTP receiver that cannot recognize a payload type must discard it. This provides backward compatibility. If a non-FEC-capable receiver receives a repair packet, it will not recognize the payload type; hence, it will discard the repair packet.
有效载荷类型：通过带外方式（例如，SDP）确定FEC修复分组的（动态）有效载荷类型。注意，本文件登记了维修包的新有效载荷格式（详情请参阅第5节）。根据[RFC3550]，无法识别有效负载类型的RTP接收器必须丢弃它。这提供了向后兼容性。如果不支持FEC的接收器接收到修复分组，则其将不识别有效负载类型；因此，它将丢弃修复包。
Sequence Number (SN): The Sequence Number follows the standard definition provided in [RFC3550]. Therefore, it must be one higher than the Sequence Number in the previously transmitted repair packet, and the initial value of the Sequence Number should be random (i.e., unpredictable).
序列号（SN）：序列号遵循[RFC3550]中提供的标准定义。因此，它必须比先前发送的修复分组中的序列号高一个，并且序列号的初始值应该是随机的（即，不可预测的）。
Timestamp (TS): The timestamp SHALL be set to a time corresponding to the repair packet's transmission time. Note that the timestamp value has no use in the actual FEC protection process and is usually useful for jitter calculations.
时间戳（TS）：时间戳应设置为与维修包传输时间相对应的时间。请注意，时间戳值在实际FEC保护过程中没有用处，通常用于抖动计算。
Synchronization Source (SSRC): The SSRC value for each repair stream SHALL be randomly assigned as per the guidelines provided in Section 8 of [RFC3550]. This allows the sender to multiplex the source and repair RTP streams in the same RTP session, or multiplex multiple repair streams in an RTP session. The repair stream's SSRC's CNAME SHOULD be identical to the CNAME of the source RTP stream(s) that this repair stream protects. A FEC stream that protects multiple source RTP streams with different CNAME's uses the CNAME associated with the entity generating the
同步源（SSRC）：应根据[RFC3550]第8节提供的指南，随机分配每个维修流的SSRC值。这允许发送方在同一RTP会话中复用源和修复RTP流，或者在RTP会话中复用多个修复流。修复流的SSRC的CNAME应该与该修复流保护的源RTP流的CNAME相同。保护具有不同CNAME的多个源RTP流的FEC流使用与生成该流的实体关联的CNAME
FEC stream or the CNAME of the entity on whose behalf it performs the protection operation. In cases when the repair stream covers packets from multiple source RTP streams with different CNAME values and none of these CNAME values can be associated with the entity generating the FEC stream, any of these CNAME values MAY be used.
FEC流或代表其执行保护操作的实体的CNAME。在修复流覆盖来自具有不同CNAME值的多个源RTP流的分组并且这些CNAME值中的任何一个都不能与生成FEC流的实体相关联的情况下，可以使用这些CNAME值中的任何一个。
In some networks, the RTP Source, which produces the source packets, and the FEC Source, which generates the repair packets from the source packets, may not be the same host. In such scenarios, using the same CNAME for the source and repair RTP streams means that the RTP Source and the FEC Source will share the same CNAME (for this specific source-repair stream association). A common CNAME may be produced based on an algorithm that is known both to the RTP and FEC Source [RFC7022]. This usage is compliant with [RFC3550].
在一些网络中，产生源分组的RTP源和从源分组产生修复分组的FEC源可能不是同一主机。在这种情况下，对源和修复RTP流使用相同的CNAME意味着RTP源和FEC源将共享相同的CNAME（对于此特定的源修复流关联）。公共CNAME可以基于RTP和FEC源已知的算法生成[RFC7022]。此用法符合[RFC3550]。
Note that due to the randomness of the SSRC assignments, there is a possibility of SSRC collision. In such cases, the collisions must be resolved as described in [RFC3550].
注意，由于SSRC分配的随机性，存在SSRC冲突的可能性。在这种情况下，必须按照[RFC3550]中所述解决碰撞。
The format of the FEC header has three variants, depending on the values in the first two bits (R and F bits) as shown in Figure 10. Note that R and F stand for "retransmit" and "fixed block", respectively. Two of these variants are meant to describe different methods for deriving the source data from a source packet for a repair packet. This allows for customizing the FEC method to allow for robustness against different levels of burst errors and random packet losses. The third variant is for a straight retransmission of the source packet.
FEC报头的格式有三种变体，具体取决于前两位（R和F位）中的值，如图10所示。注意，R和F分别代表“重传”和“固定块”。其中两种变体旨在描述用于从源数据包为修复数据包导出源数据的不同方法。这允许定制FEC方法以允许针对不同级别的突发错误和随机分组丢失的鲁棒性。第三种变体用于源数据包的直接重传。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|F|P|X| CC |M| PT recovery | ...varies depending on R/F... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ...varies depending on R/F... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Repair Payload follows FEC header :
: :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|F|P|X| CC |M| PT recovery | ...varies depending on R/F... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ...varies depending on R/F... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Repair Payload follows FEC header :
: :
Figure 10: FEC header
图10:FEC报头
The Repair Payload, which follows the FEC header, includes repair of everything following the fixed 12-byte RTP header of each source packet, including any CSRC identifier list and header extensions if present. An overview on how the Repair Payload can be used to recover source packets is provided in Section 6.
FEC报头之后的修复有效负载包括修复每个源分组的固定12字节RTP报头之后的所有内容，包括任何CSC标识符列表和报头扩展（如果存在）。第6节概述了如何使用修复有效负载来恢复源数据包。
+---+---+-----------------------------------------------------+
| R | F | FEC header variant |
+---+---+-----------------------------------------------------+
| 0 | 0 | Flexible FEC Mask fields indicate source packets |
| 0 | 1 | Fixed FEC L/D (cols/rows) indicate source packets |
| 1 | 0 | Retransmission of a single source packet |
| 1 | 1 | Reserved for future use, MUST NOT send, MUST ignore |
+---+---+-----------------------------------------------------+
+---+---+-----------------------------------------------------+
| R | F | FEC header variant |
+---+---+-----------------------------------------------------+
| 0 | 0 | Flexible FEC Mask fields indicate source packets |
| 0 | 1 | Fixed FEC L/D (cols/rows) indicate source packets |
| 1 | 0 | Retransmission of a single source packet |
| 1 | 1 | Reserved for future use, MUST NOT send, MUST ignore |
+---+---+-----------------------------------------------------+
Figure 11: R and F Bit Values for FEC Header Variants
图11:FEC头变量的R和F位值
The first variant, when R=0 and F=0, has a mask to signal protected source packets, as shown in Figure 12.
当R=0和F=0时，第一个变量有一个掩码，用于向受保护的源数据包发送信号，如图12所示。
The second variant, when R=0 and F=1, has a number of columns (L) and rows (D) to signal protected source packets, as shown in Figure 13.
当R=0和F=1时，第二个变量有许多列（L）和行（D）来表示受保护的源数据包，如图13所示。
The final variant, when R=1 and F=0, is a retransmission format as shown in Figure 15.
当R=1和F=0时，最后一个变量是重传格式，如图15所示。
No variant presently uses R=1 and F=1, which is reserved for future use. Current FLEX FEC implementations MUST NOT send packets with this variant, and receivers MUST ignore these packets. Future FLEX FEC implementations may use this by updating the media type registration.
目前没有任何变体使用R=1和F=1，这是为将来使用而保留的。当前的FLEX FEC实现不能使用此变体发送数据包，并且接收者必须忽略这些数据包。未来的FLEX FEC实现可能会通过更新媒体类型注册来使用此功能。
The FEC header for all variants consists of the following common fields:
所有变体的FEC标头由以下公共字段组成：
o The R bit MUST be set to 1 to indicate a retransmission packet, and MUST be set to 0 for FEC repair packets.
o R位必须设置为1以指示重传数据包，对于FEC修复数据包，R位必须设置为0。
o The F bit indicates the type of FEC repair packets, as shown in Figure 11, when the R bit is 0. The F bit MUST be set to 0 when the R bit is 1 for retransmission packets.
o 当R位为0时，F位表示FEC修复数据包的类型，如图11所示。对于重传数据包，当R位为1时，F位必须设置为0。
o The P, X, CC, M, and PT recovery fields are used to determine the corresponding fields of the recovered packets (see also Section 6.3.2).
o P、X、CC、M和PT恢复字段用于确定恢复数据包的相应字段（另见第6.3.2节）。
When R=0 and F=0, the FEC header includes flexible Mask fields.
当R=0和F=0时，FEC头包括灵活的掩码字段。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|P|X| CC |M| PT recovery | length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SN base_i |k| Mask [0-14] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|k| Mask [15-45] (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask [46-109] (optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... next SN base and Mask for CSRC_i in CSRC list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Repair Payload follows FEC header :
: :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|P|X| CC |M| PT recovery | length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SN base_i |k| Mask [0-14] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|k| Mask [15-45] (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask [46-109] (optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... next SN base and Mask for CSRC_i in CSRC list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Repair Payload follows FEC header :
: :
Figure 12: FEC Header for F=0
图12:F=0的FEC头
o The Length recovery (16 bits) field is used to determine the length of the recovered packets. This length includes all octets following the fixed 12-byte RTP header of source packets, including CSRC list and optional header extension(s) if present. It excludes the fixed 12-byte RTP header of source packets.
o 长度恢复（16位）字段用于确定恢复的数据包的长度。该长度包括源数据包固定的12字节RTP报头之后的所有八位字节，包括CSC列表和可选的报头扩展（如果存在）。它不包括源数据包的固定12字节RTP报头。
o The TS recovery (32 bits) field is used to determine the timestamp of the recovered packets.
o TS恢复（32位）字段用于确定恢复的数据包的时间戳。
o The CSRC_i (32 bits) field in the RTP header (not FEC header) describes the SSRC of the source packets protected by this particular FEC packet. If a FEC packet protects multiple SSRCs (indicated by the CSRC Count > 1 in the RTP header), there will be multiple blocks of data containing the SN base and Mask fields.
o RTP报头（非FEC报头）中的CSRC_i（32位）字段描述了受该特定FEC数据包保护的源数据包的SSRC。如果FEC数据包保护多个SSRC（由RTP报头中的CSC计数>1表示），则将有多个包含SN基和掩码字段的数据块。
o The SN base_i (16 bits) field indicates the lowest sequence number, taking wrap around into account, of the source packets for a particular SSRC (indicated in CSRC_i) protected by this repair packet.
o SN base_i（16位）字段指示受该修复包保护的特定SSRC（在csc_i中指示）的源包的最低序列号（考虑到环绕）。
o The Mask fields indicate a bitmask of which source packets are protected by this FEC repair packet, where bit j of the mask set to 1 indicates that the source packet with Sequence Number (SN base_i + j) is protected by this FEC repair packet, where j=0 is the most significant bit in the mask.
o 掩码字段表示源分组受该FEC修复分组保护的位掩码，其中掩码的位j设置为1表示序列号为（SN base_i+j）的源分组受该FEC修复分组保护，其中j＝0是掩码中的最高有效位。
o The k-bit in the bitmasks indicates if the mask is 15, 46, or 110 bits. k=1 denotes that another mask follows, and k=0 denotes that it is the last block of mask.
o 位掩码中的k位指示掩码是15位、46位还是110位。k=1表示后面跟着另一个掩码，k=0表示它是掩码的最后一块。
o The Repair Payload, which follows the FEC header, includes repair of everything following the fixed 12-byte RTP header of each source packet, including any CSRC identifier list and header extensions if present.
o FEC报头之后的修复有效负载包括修复每个源分组的固定12字节RTP报头之后的所有内容，包括任何CSC标识符列表和报头扩展（如果存在）。
When R=0 and F=1, the FEC header includes L and D fields for fixed columns and rows. The other fields are the same as the prior section. As in the previous section, the CSRC_i (32 bits) field in the RTP header (not FEC Header) describes the SSRC of the source packets protected by this particular FEC packet. If there are multiple SSRC's protected by the FEC packet, then there will be multiple blocks of data containing an SN base along with L and D fields.
当R=0和F=1时，FEC头包括固定列和行的L和D字段。其他字段与上一节相同。如前一节中所述，RTP报头（非FEC报头）中的csc_i（32位）字段描述了受该特定FEC分组保护的源分组的SSRC。如果有多个SSRC受FEC数据包保护，则将有多个数据块包含SN基以及L和D字段。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|P|X| CC |M| PT recovery | length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SN base_i | L (columns) | D (rows) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... next SN base and L/D for CSRC_i in CSRC list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Repair Payload follows FEC header :
: :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|P|X| CC |M| PT recovery | length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SN base_i | L (columns) | D (rows) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... next SN base and L/D for CSRC_i in CSRC list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Repair Payload follows FEC header :
: :
Figure 13: FEC Header for F=1
图13:F=1的FEC头
Consequently, the following conditions occur for L and D values:
因此，L和D值出现以下情况：
If L=0, D=0, reserved for future use, MUST NOT send, MUST ignore if received.
如果L=0，D=0，保留供将来使用，则不得发送，如果收到，则必须忽略。
If L>0, D=0, indicates row FEC, and no column FEC will follow (1D).
Source packets for each row: SN, SN+1, ..., SN+(L-1)
If L>0, D=0, indicates row FEC, and no column FEC will follow (1D).
Source packets for each row: SN, SN+1, ..., SN+(L-1)
If L>0, D=1, indicates row FEC, and column FEC will follow (2D). Source packets for each row: SN, SN+1, ..., SN+(L-1) Source packets for each col: SN, SN+L, ..., SN+(D-1)*L After all row FEC packets have been sent, the column FEC packets will be sent.
如果L>0，D=1，则表示行FEC，列FEC将跟随（2D）。每行的源数据包：SN，SN+1，…，SN+（L-1）每列的源数据包：SN，SN+L，…，SN+（D-1）*L发送所有行FEC数据包后，将发送列FEC数据包。
If L>0, D>1, indicates column FEC of every L packet, D times.
Source packets for each col: SN, SN+L, ..., SN+(D-1)*L
If L>0, D>1, indicates column FEC of every L packet, D times.
Source packets for each col: SN, SN+L, ..., SN+(D-1)*L
Figure 14: Interpreting the L and D Field Values
图14：解释L和D字段值
Given the 8-bit limit on L and D (as depicted in Figure 13), the maximum value of either parameter is 255. If L=0 and D=0 are in a packet, then the repair packet MUST be ignored by the receiver. In addition, when L=1 and D=0, the repair packet becomes a retransmission of a corresponding source packet.
给定L和D的8位限制（如图13所示），任一参数的最大值都是255。如果L=0和D=0在数据包中，则接收器必须忽略修复数据包。此外，当L＝1且D＝0时，修复分组成为对应源分组的重传。
The values of L and D for a given block of recovery data will correspond to the type of recovery in use for that block of data. In particular, for 2-D repair, the (L,D) values may not be constant across all packets for a given SSRC being repaired. Similarly, the L and D values can differ across different blocks of repair data (repairing different SSRCs) in a single packet. If the values of L and D result in a repair packet that exceed the repair window of the FLEX FEC session, then the repair packet MUST be ignored.
给定恢复数据块的L和D值将对应于该数据块使用的恢复类型。特别地，对于二维修复，对于正在修复的给定SSRC，在所有分组中，（L，D）值可能不是恒定的。类似地，L和D值可以在单个分组中的不同修复数据块（修复不同的ssrc）之间不同。如果L和D的值导致修复数据包超出FLEX FEC会话的修复窗口，则必须忽略该修复数据包。
It should be noted that the flexible mask-based approach may be inefficient for protecting a large number of source packets, or impossible to signal if larger than the largest mask size. In such cases, the fixed columns and rows variant may be more useful.
应当注意的是，灵活的基于掩码的方法对于保护大量源分组可能效率低下，或者如果大于最大掩码大小，则不可能发送信号。在这种情况下，固定列和固定行变量可能更有用。
When R=1 and F=0, the FEC packet is a retransmission of a single source packet. Note that the layout of this retransmission packet is different from other FEC repair packets. The Sequence Number (SN base_i) replaces the length recovery in the FEC header, since the length is already known for a single packet. There are no L, D, or Mask fields, since only a single packet is retransmitted, identified by the Sequence Number in the FEC header. The source packet SSRC is
当R＝1且F＝0时，FEC分组是单个源分组的重传。注意，该重传分组的布局不同于其他FEC修复分组。序列号（SN base_i）替换FEC报头中的长度恢复，因为单个分组的长度已经已知。没有L、D或掩码字段，因为只有一个数据包被重新传输，由FEC报头中的序列号标识。源数据包SSRC为
included in the FEC header for retransmissions, not in the RTP header CSRC list as in the FEC header variants with R=0. When performing retransmissions, a single repair packet stream (SSRC) MAY be used for retransmitting packets from multiple source packet streams (SSRCs), as well as transmitting FEC repair packets that protect multiple source packet streams (SSRCs).
包括在用于重新传输的FEC报头中，而不是在R=0的FEC报头变体中的RTP报头列表中。当执行重传时，单个修复分组流（SSRC）可用于重传来自多个源分组流（SSRC）的分组，以及传输保护多个源分组流（SSRC）的FEC修复分组。
This FEC header layout is identical to the source RTP (version 2) packet, starting with its RTP header, where the retransmission "payload" is everything following the fixed 12-byte RTP header of the source packet, including the CSRC list and extensions if present. Therefore, the only operation needed for sending retransmissions is to prepend a new RTP header to the source packet.
该FEC报头布局与源RTP（版本2）数据包相同，从其RTP报头开始，其中重传“有效载荷”是源数据包的固定12字节RTP报头之后的所有内容，包括CSC列表和扩展（如果存在）。因此，发送重传所需的唯一操作是将新的RTP报头预先发送到源分组。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|P|X| CC |M| Payload Type| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Retransmission Payload follows FEC header :
: :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|P|X| CC |M| Payload Type| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Retransmission Payload follows FEC header :
: :
Figure 15: FEC Header for Retransmission
图15：用于重传的FEC报头
This section provides the media subtype registration for the non-interleaved and interleaved parity FEC. The parameters that are required to configure the FEC encoding and decoding operations are also defined in this section. If no specific FEC code is specified in the subtype, then the FEC code defaults to the parity code defined in this specification.
本节提供非交织和交织奇偶校验FEC的媒体子类型注册。本节还定义了配置FEC编码和解码操作所需的参数。如果子类型中未指定特定的FEC代码，则FEC代码默认为本规范中定义的奇偶校验码。
This registration is done using the template defined in [RFC6838] and following the guidance provided in [RFC4855] along with [RFC4856].
使用[RFC6838]中定义的模板并遵循[RFC4855]和[RFC4856]中提供的指南进行注册。
Type name: audio
类型名称：音频
Subtype name: flexfec
子类型名称：flexfec
Required parameters:
所需参数：
o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream.
o 速率：RTP时间戳（时钟）速率。速率应大于1000 Hz，以便为RTCP操作提供足够的分辨率。但是，建议选择与受保护源RTP流的速率匹配的速率。
o repair-window: The time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds.
o 修复窗口：跨越源数据包和相应修复数据包的时间。修复窗口的大小以微秒为单位指定。
Encoding considerations: This media type is framed (see Section 4.8 in the template document [RFC6838]) and contains binary data.
编码注意事项：此媒体类型为框架（见模板文档[RFC6838]中的第4.8节），包含二进制数据。
Security considerations: See Section 9 of [RFC8627].
安全注意事项：见[RFC8627]第9节。
Interoperability considerations: None.
互操作性考虑：无。
Published specification: [RFC8627].
已发布规范：[RFC8627]。
Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media.
使用此媒体类型的应用程序：希望通过在源媒体之外发送冗余数据来提高数据包丢失恢复能力的多媒体应用程序。
Fragment identifier considerations: None.
片段标识符注意事项：无。
Additional information: None.
其他信息：无。
Person & email address to contact for further information: IESG <iesg@ietf.org> and IETF Audio/Video Transport Payloads Working Group (or its successor as delegated by the IESG).
联系人和电子邮件地址，以获取更多信息：IESG<iesg@ietf.org>IETF音频/视频传输有效载荷工作组（或IESG授权的继任者）。
Intended usage: COMMON.
预期用途：普通。
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transport via RTP [RFC3550].
使用限制：此媒体类型取决于RTP帧；因此，它仅定义为通过RTP[RFC3550]传输。
Author: Varun Singh <varun@callstats.io>.
作者：瓦伦·辛格<varun@callstats.io>.
Change controller: IETF Audio/Video Transport Payloads Working Group delegated from the IESG (or its successor as delegated by the IESG).
变更控制人：IESG（或IESG授权的其继任者）授权的IETF音频/视频传输有效载荷工作组。
Type name: video
类型名称：视频
Subtype name: flexfec
子类型名称：flexfec
Required parameters:
所需参数：
o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream.
o 速率：RTP时间戳（时钟）速率。速率应大于1000 Hz，以便为RTCP操作提供足够的分辨率。但是，建议选择与受保护源RTP流的速率匹配的速率。
o repair-window: The time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds.
o 修复窗口：跨越源数据包和相应修复数据包的时间。修复窗口的大小以微秒为单位指定。
Encoding considerations: This media type is framed (see Section 4.8 in the template document [RFC6838]) and contains binary data.
编码注意事项：此媒体类型为框架（见模板文档[RFC6838]中的第4.8节），包含二进制数据。
Security considerations: See Section 9 of [RFC8627].
安全注意事项：见[RFC8627]第9节。
Interoperability considerations: None.
互操作性考虑：无。
Published specification: [RFC8627].
已发布规范：[RFC8627]。
Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media.
使用此媒体类型的应用程序：希望通过在源媒体之外发送冗余数据来提高数据包丢失恢复能力的多媒体应用程序。
Fragment identifier considerations: None.
片段标识符注意事项：无。
Additional information: None.
其他信息：无。
Person & email address to contact for further information: IESG <iesg@ietf.org> and IETF Audio/Video Transport Payloads Working Group (or its successor as delegated by the IESG).
联系人和电子邮件地址，以获取更多信息：IESG<iesg@ietf.org>IETF音频/视频传输有效载荷工作组（或IESG授权的继任者）。
Intended usage: COMMON.
预期用途：普通。
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transport via RTP [RFC3550].
使用限制：此媒体类型取决于RTP帧；因此，它仅定义为通过RTP[RFC3550]传输。
Author: Varun Singh <varun@callstats.io>.
作者：瓦伦·辛格<varun@callstats.io>.
Change controller: IETF Audio/Video Transport Payloads Working Group delegated from the IESG (or its successor as delegated by the IESG).
变更控制人：IESG（或IESG授权的其继任者）授权的IETF音频/视频传输有效载荷工作组。
Type name: text
类型名称：text
Subtype name: flexfec
子类型名称：flexfec
Required parameters:
所需参数：
o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream.
o 速率：RTP时间戳（时钟）速率。速率应大于1000 Hz，以便为RTCP操作提供足够的分辨率。但是，建议选择与受保护源RTP流的速率匹配的速率。
o repair-window: The time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds.
o 修复窗口：跨越源数据包和相应修复数据包的时间。修复窗口的大小以微秒为单位指定。
Encoding considerations: This media type is framed (see Section 4.8 in the template document [RFC6838]) and contains binary data.
编码注意事项：此媒体类型为框架（见模板文档[RFC6838]中的第4.8节），包含二进制数据。
Security considerations: See Section 9 of [RFC8627].
安全注意事项：见[RFC8627]第9节。
Interoperability considerations: None.
互操作性考虑：无。
Published specification: [RFC8627].
已发布规范：[RFC8627]。
Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media.
使用此媒体类型的应用程序：希望通过在源媒体之外发送冗余数据来提高数据包丢失恢复能力的多媒体应用程序。
Fragment identifier considerations: None.
片段标识符注意事项：无。
Additional information: None.
其他信息：无。
Person & email address to contact for further information: IESG <iesg@ietf.org> and IETF Audio/Video Transport Payloads Working Group (or its successor as delegated by the IESG).
联系人和电子邮件地址，以获取更多信息：IESG<iesg@ietf.org>IETF音频/视频传输有效载荷工作组（或IESG授权的继任者）。
Intended usage: COMMON.
预期用途：普通。
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transport via RTP [RFC3550].
使用限制：此媒体类型取决于RTP帧；因此，它仅定义为通过RTP[RFC3550]传输。
Author: Varun Singh <varun@callstats.io>.
作者：瓦伦·辛格<varun@callstats.io>.
Change controller: IETF Audio/Video Transport Payloads Working Group delegated from the IESG (or its successor as delegated by the IESG).
变更控制人：IESG（或IESG授权的其继任者）授权的IETF音频/视频传输有效载荷工作组。
Type name: application
类型名称：应用程序
Subtype name: flexfec
子类型名称：flexfec
Required parameters:
所需参数：
o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream.
o 速率：RTP时间戳（时钟）速率。速率应大于1000 Hz，以便为RTCP操作提供足够的分辨率。但是，建议选择与受保护源RTP流的速率匹配的速率。
o repair-window: The time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds.
o 修复窗口：跨越源数据包和相应修复数据包的时间。修复窗口的大小以微秒为单位指定。
Encoding considerations: This media type is framed (see Section 4.8 in the template document [RFC6838]) and contains binary data.
编码注意事项：此媒体类型为框架（见模板文档[RFC6838]中的第4.8节），包含二进制数据。
Security considerations: See Section 9 of [RFC8627].
安全注意事项：见[RFC8627]第9节。
Interoperability considerations: None.
互操作性考虑：无。
Published specification: [RFC8627].
已发布规范：[RFC8627]。
Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media.
使用此媒体类型的应用程序：希望通过在源媒体之外发送冗余数据来提高数据包丢失恢复能力的多媒体应用程序。
Fragment identifier considerations: None.
片段标识符注意事项：无。
Additional information: None.
其他信息：无。
Person & email address to contact for further information: IESG <iesg@ietf.org> and IETF Audio/Video Transport Payloads Working Group (or its successor as delegated by the IESG).
联系人和电子邮件地址，以获取更多信息：IESG<iesg@ietf.org>IETF音频/视频传输有效载荷工作组（或IESG授权的继任者）。
Intended usage: COMMON.
预期用途：普通。
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transport via RTP [RFC3550].
使用限制：此媒体类型取决于RTP帧；因此，它仅定义为通过RTP[RFC3550]传输。
Author: Varun Singh <varun@callstats.io>.
作者：瓦伦·辛格<varun@callstats.io>.
Change controller: IETF Audio/Video Transport Payloads Working Group delegated from the IESG (or its successor as delegated by the IESG).
变更控制人：IESG（或IESG授权的其继任者）授权的IETF音频/视频传输有效载荷工作组。
Applications that use the 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. This section provides these mappings for the media subtypes registered by this document. 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 media type specification for "flexfec" and its associated parameters in SDP is as follows:
SDP中“flexfec”的介质类型规范及其相关参数的映射如下：
o The media type (e.g., "application") goes into the "m=" line as the media name.
o 媒体类型（例如，“应用程序”）作为媒体名称进入“m=”行。
o The media subtype goes into the "a=rtpmap" line as the encoding name. The RTP clock rate parameter ("rate") also goes into the "a=rtpmap" line as the clock rate.
o 媒体子类型进入“a=rtpmap”行作为编码名称。RTP时钟速率参数（“速率”）也作为时钟速率进入“a=rtpmap”行。
o The remaining required payload-format-specific parameters go into the "a=fmtp" line by copying them directly from the media type string as a semicolon-separated list of parameter=value pairs.
o 其余所需的特定于有效负载格式的参数直接从媒体类型字符串复制到“a=fmtp”行，作为参数=值对的分号分隔列表。
SDP examples are provided in Section 7.1.
第7.1节提供了SDP示例。
When offering parity FEC over RTP using SDP in an Offer/Answer model [RFC3264], the following considerations apply:
在提供/应答模型[RFC3264]中使用SDP通过RTP提供奇偶校验FEC时，应考虑以下因素：
o A sender application will indicate a repair window consistent with the desired amount of protection. Since the sender can change the FEC configuration on a packet-by-packet basis, note that the receiver must support any valid FLEX FEC configuration within the repair window associated with the offer (see Section 4.2.2). If the receiver cannot support the offered repair window it MUST reject the offer.
o 发送方应用程序将指示与所需保护量一致的修复窗口。由于发送方可以逐包更改FEC配置，请注意，接收方必须在与报价相关的修复窗口内支持任何有效的FLEX FEC配置（见第4.2.2节）。如果接收方无法支持提供的维修窗口，则必须拒绝该报价。
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 Any unknown option in the offer must be ignored and deleted from the answer (see Section 6 of [RFC3264]). If FEC is not desired by the receiver, it can be deleted from the answer.
o 报价中的任何未知选项必须忽略，并从答案中删除（见[RFC3264]第6节）。如果接收机不需要FEC，可以从应答中删除。
In declarative usage, like SDP in the Real-time Streaming Protocol (RTSP, for RTSP 1.0 see [RFC2326] and for RTSP 2.0 see [RFC7826]) or the Session Announcement Protocol (SAP) [RFC2974], the following considerations apply:
在声明性使用中，如实时流协议（RTSP，对于RTSP 1.0，请参见[RFC2326]，对于RTSP 2.0，请参见[RFC7826]）中的SDP或会话公告协议（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 that case, the receivers should choose the repair stream that is best for them.
o 通过声明多个RTP有效负载类型，可以提供多个配置（如果需要）。在这种情况下，接收器应该选择最适合他们的修复流。
This section provides a complete specification of the 1-D and 2-D parity codes and their RTP payload formats. It does not apply to the single packet retransmission format (R=1 in the FEC header).
本节提供了1-D和2-D奇偶校验码及其RTP有效负载格式的完整规范。它不适用于单包重传格式（FEC报头中的R=1）。
The following sections specify the steps involved in generating the repair packets and reconstructing the missing source packets from the repair packets.
以下部分指定生成修复包和从修复包重建丢失的源包所涉及的步骤。
The RTP header of a repair packet is formed based on the guidelines given in Section 4.2.
修理包的RTP报头是根据第4.2节给出的指南形成的。
The FEC header and Repair Payload of repair packets are formed by applying the XOR operation on the bit strings that are generated from the individual source packets protected by this particular repair packet. The set of the source packets that are associated with a given repair packet can be computed by the formula given in Section 6.3.1.
修复分组的FEC报头和修复有效载荷是通过对从受该特定修复分组保护的各个源分组生成的比特串应用异或操作而形成的。可通过第6.3.1节中给出的公式计算与给定修复数据包相关的源数据包集。
The bit string is formed for each source packet by concatenating the following fields together in the order specified:
通过按指定顺序将以下字段串联在一起，为每个源数据包形成位字符串：
o The first 16 bits of the RTP header (16 bits), though the first two (version) bits will be ignored by the recovery procedure.
o RTP报头的前16位（16位），但恢复过程将忽略前两位（版本）。
o Unsigned network-ordered 16-bit representation of the source packet length in bytes minus 12 (for the fixed RTP header), i.e., the sum of the lengths of all the following if present: the CSRC list, extension header, RTP payload, and RTP padding (16 bits).
o 源数据包长度的无符号网络顺序16位表示，字节数减去12（对于固定RTP报头），即以下所有数据包长度之和（如果存在）：CSC列表、扩展报头、RTP有效负载和RTP填充（16位）。
o The timestamp of the RTP header (32 bits).
o RTP报头的时间戳（32位）。
o All octets after the fixed 12-byte RTP header. (Note the SSRC field is skipped.)
o 固定的12字节RTP报头之后的所有八位字节。（注意跳过SSRC字段。）
The FEC bit string is generated by applying the parity operation on the bit strings produced from the source packets. The FEC header is generated from the FEC bit string as follows:
FEC位字符串是通过对源数据包生成的位字符串应用奇偶校验操作生成的。FEC头由FEC位字符串生成，如下所示：
o The first (most significant) 2 bits in the FEC bit string, which contain the RTP version field, are skipped. The R and F bits in the FEC header are set to the appropriate value, i.e., it depends on the chosen format variant. As a consequence of overwriting the RTP version field with the R and F bits, this payload format only supports RTP version 2.
o 跳过FEC位字符串中包含RTP版本字段的前2位（最高有效位）。FEC报头中的R和F位被设置为适当的值，即，它取决于所选择的格式变量。由于使用R和F位覆盖RTP版本字段，此有效负载格式仅支持RTP版本2。
o The next bit in the FEC bit string is written into the P recovery bit in the FEC header.
o FEC位字符串中的下一位写入FEC头中的P恢复位。
o The next bit in the FEC bit string is written into the X recovery bit in the FEC header.
o FEC位字符串中的下一位写入FEC头中的X恢复位。
o The next 4 bits of the FEC bit string are written into the CC recovery field in the FEC header.
o FEC位字符串的下4位写入FEC报头中的CC recovery字段。
o The next bit is written into the M recovery bit in the FEC header.
o 下一位写入FEC报头中的M恢复位。
o The next 7 bits of the FEC bit string are written into the PT recovery field in the FEC header.
o FEC位串的下7位写入FEC报头中的PT recovery字段。
o The next 16 bits are written into the length recovery field in the FEC header.
o 接下来的16位写入FEC报头中的长度恢复字段。
o The next 32 bits of the FEC bit string are written into the TS recovery field in the FEC header.
o FEC位字符串的下32位写入FEC报头中的TS恢复字段。
o The lowest Sequence Number of the source packets protected by this repair packet is written into the Sequence Number Base field in the FEC header. This needs to be repeated for each SSRC that has packets included in the source block.
o 受该修复包保护的源包的最低序列号被写入FEC报头中的序列号基字段。这需要对源块中包含数据包的每个SSRC重复。
o Depending on the chosen FEC header variant, the mask(s) is set when F=0 or the L and D values are set when F=1. This needs to be repeated for each SSRC that has packets included in the source block.
o 根据选择的FEC头变量，当F=0时设置掩码，或当F=1时设置L和D值。这需要对源块中包含数据包的每个SSRC重复。
o The rest of the FEC bit string, which contains everything after the fixed 12-byte RTP header of the source packet, is written into the Repair Payload following the FEC header, where "Payload" refers to everything after the fixed 12-byte RTP header, including extensions, CSRC list, true payloads, and padding.
o FEC位字符串的其余部分（包含源数据包的固定12字节RTP报头之后的所有内容）写入FEC报头之后的修复有效负载中，其中“有效负载”指固定12字节RTP报头之后的所有内容，包括扩展、CSC列表、真实有效负载和填充。
If the lengths of the source packets are not equal, each shorter packet MUST be padded to the length of the longest packet by adding octet zeros at the end.
如果源数据包的长度不相等，则每个较短的数据包必须通过在末尾添加八位组零来填充到最长数据包的长度。
Due to this possible padding and mandatory FEC header, a repair packet has a larger size than the source packets it protects. This may cause problems if the resulting repair packet size exceeds the Maximum Transmission Unit (MTU) size of the path over which the repair stream is sent.
由于这种可能的填充和强制FEC报头，修复数据包的大小大于它所保护的源数据包的大小。如果产生的修复包大小超过发送修复流的路径的最大传输单元（MTU）大小，则这可能会导致问题。
This section describes the recovery procedures that are required to reconstruct the missing source packets. The recovery process has two steps. In the first step, the FEC decoder determines which source and repair packets should be used in order to recover a missing packet. In the second step, the decoder recovers the missing packet, which consists of an RTP header and RTP payload.
本节介绍重建丢失的源数据包所需的恢复过程。恢复过程有两个步骤。在第一步骤中，FEC解码器确定应该使用哪个源和修复包来恢复丢失的包。在第二步中，解码器恢复丢失的数据包，该数据包由RTP报头和RTP有效负载组成。
The following describes the RECOMMENDED algorithms for the first and second steps. Based on the implementation, different algorithms MAY be adopted. However, the end result MUST be identical to the one produced by the algorithms described below.
下面介绍第一步和第二步的推荐算法。根据实现，可以采用不同的算法。但是，最终结果必须与下面描述的算法产生的结果相同。
Note that the same algorithms are used by the 1-D parity codes, regardless of whether the FEC protection is applied over a column or a row. The 2-D parity codes, on the other hand, usually require multiple iterations of the procedures described here. This iterative decoding algorithm is further explained in Section 6.3.4.
注意，无论FEC保护是应用于列还是行，一维奇偶校验码都使用相同的算法。另一方面，二维奇偶校验码通常需要对此处描述的过程进行多次迭代。第6.3.4节进一步解释了该迭代解码算法。
Before associating source and repair packets, the receiver must know in which RTP sessions the source and repair, respectively, are being sent. After this is established by the receiver, the first step is associating the source and repair packets. This association can be
在关联源和修复数据包之前，接收方必须知道源和修复分别在哪个RTP会话中发送。在接收器建立了这一点之后，第一步是将源数据包和修复数据包关联起来。这种联系可以是
via flexible bitmasks or fixed L and D offsets, which can be in the FEC header or signaled in SDP in optional payload format parameters when L=D=0 in the FEC header.
通过灵活的位掩码或固定的L和D偏移，当FEC报头中的L=D=0时，可以在FEC报头中或在SDP中以可选的有效负载格式参数发送信号。
To use flexible bitmasks, the first two FEC header bits MUST have R=0 and F=0. A 15-bit, 46-bit, or 110-bit mask indicates which source packets are protected by a FEC repair packet. If the bit i in the mask is set to 1, the source packet number N + i is protected by this FEC repair packet, where N is the Sequence Number base indicated in the FEC header. The most significant bit of the mask corresponds to i=0. The least significant bit of the mask corresponds to i=14 in the 15-bit mask, i=45 in the 46-bit mask, or i=109 in the 110-bit mask.
要使用灵活的位掩码，前两个FEC头位必须具有R=0和F=0。15位、46位或110位掩码指示哪些源数据包受FEC修复数据包的保护。如果掩码中的位i设置为1，则源分组号N+i受该FEC修复分组的保护，其中N是FEC报头中指示的序列号基数。掩码的最高有效位对应于i=0。掩码的最低有效位对应于15位掩码中的i=14、46位掩码中的i=45或110位掩码中的i=109。
The bitmasks are able to represent arbitrary protection patterns, for example, 1-D interleaved, 1-D non-interleaved, 2-D.
位掩码能够表示任意保护模式，例如，1-D交错、1-D非交错、2-D。
Denote the set of the source packets associated with repair packet p* by set T(p*). Note that in a source block whose size is L columns by D rows, set T includes D source packets plus one repair packet for the FEC protection applied over a column, and it includes L source packets plus one repair packet for the FEC protection applied over a row. Recall that 1-D interleaved and non-interleaved FEC protection can fully recover the missing information if there is only one source packet missing per column or row in set T. If more than one source packet is missing per column or row in set T, 1-D FEC protection may fail to recover all the missing information.
用集合T（p*）表示与修复分组p*相关联的源分组的集合。注意，在大小为L列×D行的源块中，集合T包括D个源分组加上一个用于在列上应用的FEC保护的修复分组，并且它包括L个源分组加上一个用于在行上应用的FEC保护的修复分组。回想一下，如果集合T中的每列或每行只有一个源数据包丢失，则1-D交错和非交错FEC保护可以完全恢复丢失的信息。如果集合T中的每列或每行有多个源数据包丢失，1-D FEC保护可能无法恢复所有丢失的信息。
When the value of L is non-zero, the 8-bit fields indicate the offset of packets protected by an interleaved (D>0) or non-interleaved (D=0) FEC packet. Using a combination of interleaved and non-interleaved FEC repair packets can form 2-D protection patterns.
当L的值非零时，8位字段指示由交织（D>0）或非交织（D＝0）FEC分组保护的分组的偏移量。使用交织和非交织FEC修复分组的组合可以形成二维保护模式。
Mathematically, for any received repair packet, p*, the sequence numbers of the source packets that are protected by this repair packet are determined as follows, where SN is the Sequence Number base in the FEC header:
数学上，对于任何接收到的修复分组p*，由该修复分组保护的源分组的序列号如下确定，其中SN是FEC报头中的序列号基：
For each SSRC (in CSRC list):
When D <= 1: Source packets for each row: SN, SN+1, ..., SN+(L-1)
When D > 1: Source packets for each col: SN, SN+L, ..., SN+(D-1)*L
For each SSRC (in CSRC list):
When D <= 1: Source packets for each row: SN, SN+1, ..., SN+(L-1)
When D > 1: Source packets for each col: SN, SN+L, ..., SN+(D-1)*L
For a given set T, the procedure for the recovery of the RTP header of the missing packet, whose Sequence Number is denoted by SEQNUM, is as follows:
对于给定的集合T，恢复丢失分组的RTP报头（其序列号由SEQNUM表示）的过程如下：
1. For each of the source packets that are successfully received in T, compute the 80-bit string by concatenating the first 64 bits of their RTP header and the unsigned network-ordered 16-bit representation of their length in bytes minus 12.
1. 对于在T中成功接收到的每个源数据包，通过将其RTP头的前64位与其长度的无符号网络顺序16位表示（字节减去12）连接起来，计算80位字符串。
2. For the repair packet in T, extract the FEC bit string as the first 80 bits of the FEC header.
2. 对于T中的修复包，提取FEC位字符串作为FEC报头的前80位。
3. Calculate the recovered bit string as the XOR of the bit strings generated from all source packets in T and the FEC bit string generated from the repair packet in T.
3. 将恢复的位字符串计算为T中所有源数据包生成的位字符串和T中修复数据包生成的FEC位字符串的异或。
4. Create a new packet with the standard 12-byte RTP header and no payload.
4. 创建一个具有标准12字节RTP报头且无有效负载的新数据包。
5. Set the version of the new packet to 2. Skip the first 2 bits in the recovered bit string.
5. 将新数据包的版本设置为2。跳过恢复的位字符串中的前2位。
6. Set the Padding bit in the new packet to the next bit in the recovered bit string.
6. 将新数据包中的填充位设置为恢复位字符串中的下一位。
7. Set the Extension bit in the new packet to the next bit in the recovered bit string.
7. 将新数据包中的扩展位设置为恢复位字符串中的下一位。
8. Set the CC field to the next 4 bits in the recovered bit string.
8. 将CC字段设置为恢复的位字符串中的下4位。
9. Set the Marker bit in the new packet to the next bit in the recovered bit string.
9. 将新数据包中的标记位设置为恢复位字符串中的下一位。
10. Set the Payload type in the new packet to the next 7 bits in the recovered bit string.
10. 将新数据包中的有效负载类型设置为恢复的位字符串中的下7位。
11. Set the SN field in the new packet to SEQNUM.
11. 将新数据包中的SN字段设置为SEQNUM。
12. Take the next 16 bits of the recovered bit string and set the new variable Y to whatever unsigned integer this represents (assuming network order). Convert Y to host order. Y represents the length of the new packet in bytes minus 12 (for the fixed RTP header), i.e., the sum of the lengths of all the following if present: the CSRC list, header extension, RTP payload, and RTP padding.
12. 取恢复的位字符串的下16位，并将新变量Y设置为它表示的无符号整数（假设网络顺序）。将Y转换为主机顺序。Y表示新数据包的长度，以字节减去12为单位（对于固定RTP报头），即以下所有数据包的长度之和（如果存在）：CSC列表、报头扩展、RTP有效负载和RTP填充。
13. Set the TS field in the new packet to the next 32 bits in the recovered bit string.
13. 将新数据包中的TS字段设置为恢复位字符串中的下一个32位。
14. Set the SSRC of the new packet to the SSRC of the missing source RTP stream.
14. 将新数据包的SSRC设置为丢失源RTP流的SSRC。
This procedure recovers the header of an RTP packet up to (and including) the SSRC field.
此过程将RTP数据包的报头恢复到（包括）SSRC字段。
Following the recovery of the RTP header, the procedure for the recovery of the RTP "payload" is as follows, where "payload" refers to everything following the fixed 12-byte RTP header, including extensions, CSRC list, true payload, and padding.
在恢复RTP报头之后，恢复RTP“有效负载”的过程如下所示，其中“有效负载”指固定的12字节RTP报头之后的所有内容，包括扩展、CSC列表、真实有效负载和填充。
1. Allocate Y additional bytes for the new packet generated in Section 6.3.2.
1. 为第6.3.2节中生成的新数据包分配Y个额外字节。
2. For each of the source packets that are successfully received in T, compute the bit string from the Y octets of data starting with the 13th octet of the packet. If any of the bit strings generated from the source packets has a length shorter than Y, pad them to that length. The zero-padding octets MUST be added at the end of the bit string. Note that the information of the first 8 octets are protected by the FEC header.
2. 对于在T中成功接收到的每个源数据包，从数据包的第13个八位字节开始计算数据的Y个八位字节的位字符串。如果源数据包生成的任何位字符串的长度小于Y，则将其填充到该长度。必须在位字符串的末尾添加零填充八位字节。注意，前8个八位字节的信息受FEC头的保护。
3. For the repair packet in T, compute the FEC bit string from the repair packet payload, i.e., the Y octets of data following the FEC header. Note that the FEC header may be different sizes depending on the variant and bitmask size.
3. 对于T中的修复分组，从修复分组有效载荷计算FEC比特串，即，FEC报头之后的Y个八位字节的数据。注意，根据变量和位掩码大小，FEC报头的大小可能不同。
4. Calculate the recovered bit string as the XOR of the bit strings generated from all source packets in T and the FEC bit string generated from the repair packet in T.
4. 将恢复的位字符串计算为T中所有源数据包生成的位字符串和T中修复数据包生成的FEC位字符串的异或。
5. Set the last Y octets in the new packet to the recovered bit string.
5. 将新数据包中的最后Y个八位字节设置为恢复的位字符串。
In 2-D parity FEC protection, the sender generates both non-interleaved and interleaved FEC repair packets to combat with the mixed loss patterns (random and bursty). At the receiver side, these FEC packets are used iteratively to overcome the shortcomings of the 1-D non-interleaved/interleaved FEC protection and improve the chances of full error recovery.
在2-D奇偶校验FEC保护中，发送方生成非交错和交错FEC修复数据包，以对抗混合丢失模式（随机和突发）。在接收端，这些FEC分组被迭代地使用，以克服一维非交织/交织FEC保护的缺点，并提高完全错误恢复的机会。
The iterative decoding algorithm runs as follows:
迭代解码算法运行如下：
1. Set num_recovered_until_this_iteration to zero
1. 将num_recovered_设置为零，直到此_迭代为零
2. Set num_recovered_so_far to zero
2. 将迄今为止恢复的数量设置为零
3. Recover as many source packets as possible by using the non-interleaved FEC repair packets as outlined in Sections 6.3.2 and 6.3.3 and increase the value of num_recovered_so_far by the number of recovered source packets.
3. 通过使用第6.3.2节和第6.3.3节中概述的非交错FEC修复数据包恢复尽可能多的源数据包，并将num_recovered_的值增加到恢复的源数据包的数量。
4. Recover as many source packets as possible by using the interleaved FEC repair packets as outlined in Sections 6.3.2 and 6.3.3 and increase the value of num_recovered_so_far by the number of recovered source packets.
4. 通过使用第6.3.2节和第6.3.3节中概述的交错FEC修复数据包恢复尽可能多的源数据包，并将num_recovered_的值增加到恢复的源数据包的数量。
5. If num_recovered_so_far > num_recovered_until_this_iteration ---num_recovered_until_this_iteration = num_recovered_so_far ---Go to step 3 Else ---Terminate
5. 如果num\u recovered\u so\u far>num\u recovered\u till\u this\u iteration--num\u recovered\u till\u this\u iteration=num\u recovered\u so\u far--转到步骤3，否则---终止
The algorithm terminates either when all missing source packets are fully recovered or when there are still remaining missing source packets but the FEC repair packets are not able to recover any more source packets. For the example scenarios when the 2-D parity FEC protection fails full recovery, refer to Section 1.1.4. Upon termination, variable num_recovered_so_far has a value equal to the total number of recovered source packets.
当所有丢失的源数据包被完全恢复时，或者当仍有剩余的丢失源数据包但FEC修复数据包无法恢复任何更多的源数据包时，该算法终止。有关二维奇偶校验FEC保护无法完全恢复的示例场景，请参阅第1.1.4节。终止时，变量num_recovered_to_的值等于恢复的源数据包总数。
Example:
例子：
Suppose that the receiver experienced the loss pattern sketched in Figure 16.
假设接收器经历了如图16所示的损失模式。
+---+ +---+ +===+
X X | 3 | | 4 | |R_1|
+---+ +---+ +===+
+---+ +---+ +===+
X X | 3 | | 4 | |R_1|
+---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 5 | | 6 | | 7 | | 8 | |R_2|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 5 | | 6 | | 7 | | 8 | |R_2|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +===+
| 9 | X X | 12| |R_3|
+---+ +---+ +===+
+---+ +---+ +===+
| 9 | X X | 12| |R_3|
+---+ +---+ +===+
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| |C_4|
+===+ +===+ +===+ +===+
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| |C_4|
+===+ +===+ +===+ +===+
Figure 16: Example: Loss Pattern for the Iterative Decoding Algorithm
图16：示例：迭代解码算法的丢失模式
The receiver executes the iterative decoding algorithm and recovers source packets #1 and #11 in the first iteration. The resulting pattern is sketched in Figure 17.
接收机执行迭代解码算法，并在第一次迭代中恢复源分组#1和#11。结果模式如图17所示。
+---+ +---+ +---+ +===+
| 1 | X | 3 | | 4 | |R_1|
+---+ +---+ +---+ +===+
+---+ +---+ +---+ +===+
| 1 | X | 3 | | 4 | |R_1|
+---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 5 | | 6 | | 7 | | 8 | |R_2|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 5 | | 6 | | 7 | | 8 | |R_2|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +===+
| 9 | X | 11| | 12| |R_3|
+---+ +---+ +---+ +===+
+---+ +---+ +---+ +===+
| 9 | X | 11| | 12| |R_3|
+---+ +---+ +---+ +===+
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| |C_4|
+===+ +===+ +===+ +===+
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| |C_4|
+===+ +===+ +===+ +===+
Figure 17: The Resulting Pattern after the First Iteration
图17：第一次迭代后的结果模式
Since the if condition holds true, the receiver runs a new iteration. In the second iteration, source packets #2 and #10 are recovered, resulting in a full recovery as sketched in Figure 18.
由于if条件为true，接收器将运行新的迭代。在第二次迭代中，恢复源数据包#2和#10，从而实现完全恢复，如图18所示。
+---+ +---+ +---+ +---+ +===+
| 1 | | 2 | | 3 | | 4 | |R_1|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 1 | | 2 | | 3 | | 4 | |R_1|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 5 | | 6 | | 7 | | 8 | |R_2|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 5 | | 6 | | 7 | | 8 | |R_2|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 9 | | 10| | 11| | 12| |R_3|
+---+ +---+ +---+ +---+ +===+
+---+ +---+ +---+ +---+ +===+
| 9 | | 10| | 11| | 12| |R_3|
+---+ +---+ +---+ +---+ +===+
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| |C_4|
+===+ +===+ +===+ +===+
+===+ +===+ +===+ +===+
|C_1| |C_2| |C_3| |C_4|
+===+ +===+ +===+ +===+
Figure 18: The Resulting Pattern after the Second Iteration
图18：第二次迭代后的结果模式
Out-of-band signaling should be designed to enable the receiver to identify the RTP streams associated with source packets and repair packets, respectively. At a minimum, the signaling must be designed to allow the receiver to:
带外信令的设计应使接收机能够分别识别与源分组和修复分组相关联的RTP流。信号必须至少设计为允许接收器：
o Determine whether one or more source RTP streams will be sent.
o 确定是否将发送一个或多个源RTP流。
o Determine whether one or more repair RTP streams will be sent.
o 确定是否将发送一个或多个修复RTP流。
o Associate the appropriate SSRC's to both source and repair streams.
o 将适当的SSRC与源和修复流相关联。
o Clearly identify which SSRC's are associated with each source block.
o 明确识别与每个源块相关的SSRC。
o Clearly identify which repair packets correspond to which source blocks.
o 清楚地识别哪些修复包对应于哪些源块。
o Make use of repair packets to recover source data associated with specific SSRC's.
o 利用修复数据包恢复与特定SSRC相关的源数据。
This section provides several Session Description Protocol (SDP) examples to demonstrate how these requirements can be met.
本节提供了几个会话描述协议（SDP）示例，以演示如何满足这些要求。
This section provides two SDP [RFC4566] examples. The examples use the FEC grouping semantics defined in [RFC5956].
本节提供了两个SDP[RFC4566]示例。示例使用[RFC5956]中定义的FEC分组语义。
7.1.1. Example SDP for Flexible FEC Protection with In-Band SSRC Mapping
7.1.1. 带内SSRC映射的灵活FEC保护示例SDP
In this example, we have one source video stream and one FEC repair stream. The source and repair streams are multiplexed on different SSRCs. The repair window is set to 200 ms.
在本例中，我们有一个源视频流和一个FEC修复流。源和修复流在不同的SSRC上多路复用。维修窗口设置为200毫秒。
v=0
o=mo 1122334455 1122334466 IN IP4 fec.example.com
s=FlexFEC minimal SDP signaling Example
t=0 0
m=video 30000 RTP/AVP 96 98
c=IN IP4 233.252.0.1/127
a=rtpmap:96 VP8/90000
a=rtpmap:98 flexfec/90000
a=fmtp:98; repair-window=200000
v=0
o=mo 1122334455 1122334466 IN IP4 fec.example.com
s=FlexFEC minimal SDP signaling Example
t=0 0
m=video 30000 RTP/AVP 96 98
c=IN IP4 233.252.0.1/127
a=rtpmap:96 VP8/90000
a=rtpmap:98 flexfec/90000
a=fmtp:98; repair-window=200000
7.1.2. Example SDP for Flexible FEC Protection with Explicit Signaling in the SDP
7.1.2. 示例SDP，用于在SDP中使用显式信令的灵活FEC保护
This example shows one source video stream (ssrc:1234) and one FEC repair streams (ssrc:2345). One FEC group is formed with the "a=ssrc-group:FEC-FR 1234 2345" line. The source and repair streams are multiplexed on different SSRCs. The repair window is set to 200 ms.
此示例显示一个源视频流（ssrc:1234）和一个FEC修复流（ssrc:2345）。一个FEC组由“a=ssrc组：FEC-FR 1234 2345”行组成。源和修复流在不同的SSRC上多路复用。维修窗口设置为200毫秒。
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=2-D Parity FEC with no in band signaling Example
t=0 0
m=video 30000 RTP/AVP 100 110
c=IN IP4 192.0.2.0/24
a=rtpmap:100 MP2T/90000
a=rtpmap:110 flexfec/90000
a=fmtp:110; repair-window:200000
a=ssrc:1234
a=ssrc:2345
a=ssrc-group:FEC-FR 1234 2345
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=2-D Parity FEC with no in band signaling Example
t=0 0
m=video 30000 RTP/AVP 100 110
c=IN IP4 192.0.2.0/24
a=rtpmap:100 MP2T/90000
a=rtpmap:110 flexfec/90000
a=fmtp:110; repair-window:200000
a=ssrc:1234
a=ssrc:2345
a=ssrc-group:FEC-FR 1234 2345
The RTP Stream Identifier Source Description [RTP-SDES] is a format that can be used to identify a single RTP source stream along with an associated repair stream. However, this specification already defines a method of source and repair stream identification that can enable protection of multiple source streams with a single repair stream. Therefore, the RTP Stream Identifier Source Description SHOULD NOT be used for the Flexible FEC payload format.
RTP流标识符源描述[RTP-SDES]是一种格式，可用于识别单个RTP源流以及相关修复流。然而，本规范已经定义了一种源和修复流识别方法，该方法可以使用单个修复流保护多个源流。因此，RTP流标识符源描述不应用于灵活的FEC有效负载格式。
FEC is an effective approach to provide applications resiliency against packet losses. However, in networks where the congestion is a major contributor to the packet loss, the potential impacts of using FEC should be considered carefully before injecting the repair streams into the network. In particular, in bandwidth-limited networks, FEC repair streams may consume a significant part of the available bandwidth and, consequently, may congest the network. In such cases, the applications MUST NOT arbitrarily increase the amount of FEC protection since doing so may lead to a congestion collapse. If desired, stronger FEC protection MAY be applied only after the source rate has been reduced.
FEC是一种有效的方法，可以为应用程序提供抗数据包丢失的弹性。然而，在拥塞是分组丢失的主要原因的网络中，在将修复流注入网络之前，应仔细考虑使用FEC的潜在影响。具体地，在带宽有限的网络中，FEC修复流可能消耗可用带宽的很大一部分，并且因此可能使网络拥塞。在这种情况下，应用程序不得任意增加FEC保护量，因为这样做可能导致拥塞崩溃。如果需要，只有在源速率降低后，才能应用更强的FEC保护。
In a network-friendly implementation, an application should avoid sending/receiving FEC repair streams if it knows that sending/ receiving those FEC repair streams would not help at all in recovering the missing packets. Examples of where FEC would not be beneficial are (1) if the successful recovery rate as determined by RTCP feedback is low (see [RFC5725] and [RFC7509] and (2) the application has a smaller latency requirement than the repair window adopted by the FEC configuration based on the expected burst loss duration and the target FEC overhead. It is RECOMMENDED that the amount and type (row, column, or both) of FEC protection is adjusted dynamically based on the packet loss rate and burst loss length observed by the applications.
在网络友好的实现中，如果应用程序知道发送/接收FEC修复流对恢复丢失的数据包毫无帮助，则应避免发送/接收FEC修复流。如果RTCP反馈确定的成功恢复率较低（参见[RFC5725]和[RFC7509]），则FEC将不起作用的示例有（1）和（2）基于预期的突发丢失持续时间和目标FEC开销，应用程序的延迟要求比FEC配置采用的修复窗口小。建议使用数量和类型（行、列或两者）根据应用程序观察到的丢包率和突发丢失长度，动态调整FEC保护的性能。
In multicast scenarios, it may be difficult to optimize the FEC protection per receiver. If there is a large variation among the levels of FEC protection needed by different receivers, it is RECOMMENDED that the sender offer multiple repair streams with different levels of FEC protection and the receivers join the corresponding multicast sessions to receive the repair stream(s) that is best for them.
在多播场景中，可能很难优化每个接收器的FEC保护。如果不同接收器所需的FEC保护级别之间存在较大差异，建议发送方提供具有不同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 can be provided by encrypting the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. Such a cryptographic system may 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 is from a member of the RTP session.
使用本规范中定义的有效负载格式的RTP数据包应遵守RTP规范[RFC3550]和任何适用RTP配置文件中讨论的安全注意事项。携带本备忘录中定义的RTP有效载荷格式的RTP数据包的主要安全注意事项是机密性、完整性和源真实性。可以通过加密RTP有效负载来提供机密性。RTP数据包的完整性是通过合适的密码完整性保护机制实现的。这样的密码系统还可以允许对有效载荷的源进行认证。此RTP有效负载格式的合适安全机制应提供机密性、完整性保护，并且至少能够确定RTP分组是否来自RTP会话的成员的源认证。
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 Datagram Transport Layer Security (DTLS, see [RFC6347]) when used along with RTP-over-UDP; other alternatives may exist.
请注意，根据本备忘录为RTP和有效负载提供安全性的适当机制可能会有所不同。它取决于所采用的应用程序、传输和信令协议。因此，单一的机制是不够的；但是，如果合适，建议使用安全实时传输协议（SRTP）[RFC3711]。当与UDP上的RTP一起使用时，可使用的其他机制包括IPsec[RFC4301]和数据报传输层安全（DTLS，请参阅[RFC6347]）；可能存在其他替代方案。
Given that FLEX FEC enables the protection of multiple source streams, there exists the possibility that multiple source buffers may be created that may not be used. An attacker could leverage unused source buffers as a means of occupying memory in a FLEX FEC endpoint. In addition, an attack against the FEC parameters themselves (e.g., repair window or D or L values) can result in a receiver having to allocate source buffer space that may also lead to excessive consumption of resources. Similarly, a network attacker could modify the recovery fields corresponding to packet lengths (assuming there are no message integrity mechanisms), which, in turn, could force unnecessarily large memory allocations at the receiver. Moreover, the application source data may not be perfectly matched with FLEX FEC Source partitioning. If this is the case, there is a possibility for unprotected source data if, for instance, the FLEX FEC implementation discards data that does not fit perfectly into its source processing requirements.
鉴于FLEX FEC能够保护多个源流，因此可能会创建多个不使用的源缓冲区。攻击者可以利用未使用的源缓冲区作为占用FLEX FEC端点内存的手段。此外，针对FEC参数本身（例如，修复窗口或D或L值）的攻击可导致接收器必须分配源缓冲区空间，这也可能导致资源的过度消耗。类似地，网络攻击者可以修改与数据包长度相对应的恢复字段（假设没有消息完整性机制），这反过来可能会在接收方强制分配不必要的大内存。此外，应用程序源数据可能与FLEX FEC源分区不完全匹配。在这种情况下，如果FLEX FEC实现丢弃不完全符合其源处理要求的数据，则有可能出现不受保护的源数据。
New media subtypes are subject to IANA registration. For the registration of the payload formats and their parameters introduced in this document, refer to Section 5.1.
新媒体子类型需要IANA注册。有关本文件中介绍的有效载荷格式及其参数的注册，请参阅第5.1节。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<https://www.rfc-editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<https://www.rfc-editor.org/info/rfc3550>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<https://www.rfc-editor.org/info/rfc4566>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <https://www.rfc-editor.org/info/rfc4855>.
[RFC4855]Casner，S.，“RTP有效载荷格式的媒体类型注册”，RFC 4855，DOI 10.17487/RFC4855，2007年2月<https://www.rfc-editor.org/info/rfc4855>.
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, DOI 10.17487/RFC4856, February 2007, <https://www.rfc-editor.org/info/rfc4856>.
[RFC4856]Casner，S.，“音频和视频会议RTP配置文件中有效载荷格式的媒体类型注册”，RFC 4856，DOI 10.17487/RFC4856，2007年2月<https://www.rfc-editor.org/info/rfc4856>.
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, DOI 10.17487/RFC5956, September 2010, <https://www.rfc-editor.org/info/rfc5956>.
[RFC5956]Begen，A.“会话描述协议中的前向纠错分组语义”，RFC 5956，DOI 10.17487/RFC5956，2010年9月<https://www.rfc-editor.org/info/rfc5956>.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, <https://www.rfc-editor.org/info/rfc6363>.
[RFC6363]Watson，M.，Begen，A.和V.Roca，“前向纠错（FEC）框架”，RFC 6363，DOI 10.17487/RFC6363，2011年10月<https://www.rfc-editor.org/info/rfc6363>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<https://www.rfc-editor.org/info/rfc6838>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, <https://www.rfc-editor.org/info/rfc7022>.
[RFC7022]Begen，A.，Perkins，C.，Wing，D.，和E.Rescorla，“选择RTP控制协议（RTCP）规范名称（CNAMEs）的指南”，RFC 7022，DOI 10.17487/RFC7022，2013年9月<https://www.rfc-editor.org/info/rfc7022>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, <https://www.rfc-editor.org/info/rfc2326>.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC 2326，DOI 10.17487/RFC2326，1998年4月<https://www.rfc-editor.org/info/rfc2326>.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, DOI 10.17487/RFC2733, December 1999, <https://www.rfc-editor.org/info/rfc2733>.
[RFC2733]Rosenberg，J.和H.Schulzrinne，“通用前向纠错的RTP有效载荷格式”，RFC 2733，DOI 10.17487/RFC2733，1999年12月<https://www.rfc-editor.org/info/rfc2733>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <https://www.rfc-editor.org/info/rfc2974>.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，DOI 10.17487/RFC2974，2000年10月<https://www.rfc-editor.org/info/rfc2974>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<https://www.rfc-editor.org/info/rfc3711>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<https://www.rfc-editor.org/info/rfc4301>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 4585，DOI 10.17487/RFC4585，2006年7月<https://www.rfc-editor.org/info/rfc4585>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <https://www.rfc-editor.org/info/rfc4588>.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，DOI 10.17487/RFC4588，2006年7月<https://www.rfc-editor.org/info/rfc4588>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC5109]Li，A.，Ed.“通用前向纠错的RTP有效载荷格式”，RFC 5109，DOI 10.17487/RFC5109，2007年12月<https://www.rfc-editor.org/info/rfc5109>.
[RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February 2010, <https://www.rfc-editor.org/info/rfc5725>.
[RFC5725]Begen，A.，Hsu，D.，和M.Lague，“RTP控制协议（RTCP）扩展报告（XRs）的修复后损失RLE报告块类型”，RFC 5725，DOI 10.17487/RFC5725，2010年2月<https://www.rfc-editor.org/info/rfc5725>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<https://www.rfc-editor.org/info/rfc6347>.
[RFC7509] Huang, R. and V. Singh, "RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics", RFC 7509, DOI 10.17487/RFC7509, May 2015, <https://www.rfc-editor.org/info/rfc7509>.
[RFC7509]Huang，R.和V.Singh，“修复后损失计数指标的RTP控制协议（RTCP）扩展报告（XR）”，RFC 7509，DOI 10.17487/RFC7509，2015年5月<https://www.rfc-editor.org/info/rfc7509>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <https://www.rfc-editor.org/info/rfc7656>.
[RFC7656]Lennox，J.，Gross，K.，Nandakumar，S.，Salgueiro，G.，和B.Burman，Ed.，“实时传输协议（RTP）源的语义和机制分类”，RFC 7656，DOI 10.17487/RFC7656，2015年11月<https://www.rfc-editor.org/info/rfc7656>.
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, <https://www.rfc-editor.org/info/rfc7826>.
[RFC7826]Schulzrinne，H.，Rao，A.，Lanphier，R.，Westerlund，M.，和M.Stiemering，Ed.，“实时流协议版本2.0”，RFC 7826，DOI 10.17487/RFC78262016年12月<https://www.rfc-editor.org/info/rfc7826>.
[RTP-SDES] Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", Work in Progress, draft-ietf-avtext-rid-09, October 2016.
[RTP-SDES]Roach，A.，Nandakumar，S.，和P.Thatcher，“RTP流标识符源描述（SDES）”，正在进行的工作，草稿-ietf-avtext-rid-092016年10月。
[SMPTE2022-1] SMPTE, "Forward Error Correction for Real-Time Video/Audio Transport over IP Networks", ST 2022-1:2007, SMPTE Standard, DOI 10.5594/SMPTE.ST2022-1.2007, May 2007.
[SMPTE2022-1]SMPTE，“IP网络实时视频/音频传输的前向纠错”，ST 2022-1:2007，SMPTE标准，DOI 10.5594/SMPTE.ST2022-1.2007，2007年5月。
Acknowledgments
致谢
Some parts of this document are borrowed from [RFC5109]. Thus, the author would like to thank the editor of [RFC5109] and those who contributed to [RFC5109].
本文件的某些部分借用自[RFC5109]。因此，作者要感谢[RFC5109]的编辑和那些对[RFC5109]做出贡献的人。
Thanks to Stephen Botzko, Bernard Aboba, Rasmus Brandt, Brian Baldino, Roni Even, Stefan Holmer, Jonathan Lennox, and Magnus Westerlund for providing valuable feedback on earlier draft versions of this document.
感谢Stephen Botzko、Bernard Aboba、Rasmus Brandt、Brian Baldino、Roni Even、Stefan Holmer、Jonathan Lennox和Magnus Westerlund为本文件早期草稿提供了宝贵的反馈。
Authors' Addresses
作者地址
Mo Zanaty Cisco Raleigh, NC United States of America
Mo Zanaty Cisco Raleigh，北卡罗来纳州，美利坚合众国
Email: mzanaty@cisco.com
Email: mzanaty@cisco.com
Varun Singh CALLSTATS I/O Oy Annankatu 31-33 C 42 Helsinki 00101 Finland
Varun Singh CALLSTATS I/O Oy Annankatu 31-33 C 42芬兰赫尔辛基00101
Email: varun.singh@iki.fi
URI: http://www.callstats.io/
Email: varun.singh@iki.fi
URI: http://www.callstats.io/
Ali Begen Networked Media Konya Turkey
阿里出生于土耳其科尼亚网络媒体公司
Email: ali.begen@networked.media
Email: ali.begen@networked.media
Giridhar Mandyam Qualcomm Inc. 5775 Morehouse Drive San Diego, CA 92121 United States of America
Giridhar Mandyam Qualcomm Inc.美国加利福尼亚州圣地亚哥Morehouse大道5775号，邮编92121
Phone: +1 858 651 7200
Email: mandyam@qti.qualcomm.com
Phone: +1 858 651 7200
Email: mandyam@qti.qualcomm.com