Network Working Group A. Li, Ed.
Request for Comments: 5109 December 2007
Obsoletes: 2733, 3009
Category: Standards Track
Network Working Group A. Li, Ed.
Request for Comments: 5109 December 2007
Obsoletes: 2733, 3009
Category: Standards Track
RTP Payload Format for Generic Forward Error Correction
用于通用前向纠错的RTP有效负载格式
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009.
本文档为封装在RTP中的媒体数据指定了通用前向纠错（FEC）的有效负载格式。它基于异或（奇偶校验）操作。本文档中描述的有效负载格式允许终端系统使用不同的保护长度和级别，以及使用不同的保护组大小来适应不同的介质和信道特性来应用保护。它能够根据数据包丢失情况完全恢复受保护的数据包或部分恢复有效负载的关键部分。该方案与不支持FEC的主机完全兼容，因此，不实现FEC的多播组中的接收器仍然可以通过忽略保护数据来工作。本规范淘汰了RFC 2733和RFC 3009。本文件中规定的FEC与RFC 2733和RFC 3009不向后兼容。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................5
3. Basic Operation .................................................6
4. Parity Codes ....................................................7
5. Uneven Level Protection (ULP) ...................................7
6. RTP Media Packet Structure ......................................9
7. FEC Packet Structure ............................................9
7.1. Packet Structure ...........................................9
7.2. RTP Header for FEC Packets ................................10
7.3. FEC Header for FEC Packets ................................11
7.4. FEC Level Header for FEC Packets ..........................12
8. Protection Operation ...........................................15
8.1. Generation of the FEC Header ..............................15
8.2. Generation of the FEC Payload .............................16
9. Recovery Procedures ............................................16
9.1. Reconstruction of the RTP Header ..........................16
9.2. Reconstruction of the RTP Payload .........................18
10. Examples ......................................................19
10.1. An Example Offers Similar Protection as RFC 2733 .........19
10.2. An Example with Two Protection Levels ....................21
10.3. An Example with FEC as Redundant Coding ..................26
11. Security Considerations .......................................29
12. Congestion Considerations .....................................30
13. IANA Considerations ...........................................31
13.1. Registration of audio/ulpfec .............................31
13.2. Registration of video/ulpfec .............................32
13.3. Registration of text/ulpfec ..............................34
13.4. Registration of application/ulpfec .......................35
14. Multiplexing of FEC ...........................................36
14.1. FEC as a Separate Stream .................................36
14.2. FEC as Redundant Encoding ................................38
14.3. Offer / Answer Consideration .............................39
15. Application Statement .........................................40
16. Acknowledgments ...............................................42
17. References ....................................................42
17.1. Normative References .....................................42
17.2. Informative References ...................................43
1. Introduction ....................................................2
2. Terminology .....................................................5
3. Basic Operation .................................................6
4. Parity Codes ....................................................7
5. Uneven Level Protection (ULP) ...................................7
6. RTP Media Packet Structure ......................................9
7. FEC Packet Structure ............................................9
7.1. Packet Structure ...........................................9
7.2. RTP Header for FEC Packets ................................10
7.3. FEC Header for FEC Packets ................................11
7.4. FEC Level Header for FEC Packets ..........................12
8. Protection Operation ...........................................15
8.1. Generation of the FEC Header ..............................15
8.2. Generation of the FEC Payload .............................16
9. Recovery Procedures ............................................16
9.1. Reconstruction of the RTP Header ..........................16
9.2. Reconstruction of the RTP Payload .........................18
10. Examples ......................................................19
10.1. An Example Offers Similar Protection as RFC 2733 .........19
10.2. An Example with Two Protection Levels ....................21
10.3. An Example with FEC as Redundant Coding ..................26
11. Security Considerations .......................................29
12. Congestion Considerations .....................................30
13. IANA Considerations ...........................................31
13.1. Registration of audio/ulpfec .............................31
13.2. Registration of video/ulpfec .............................32
13.3. Registration of text/ulpfec ..............................34
13.4. Registration of application/ulpfec .......................35
14. Multiplexing of FEC ...........................................36
14.1. FEC as a Separate Stream .................................36
14.2. FEC as Redundant Encoding ................................38
14.3. Offer / Answer Consideration .............................39
15. Application Statement .........................................40
16. Acknowledgments ...............................................42
17. References ....................................................42
17.1. Normative References .....................................42
17.2. Informative References ...................................43
The nature of real-time applications implies that they usually have more stringent delay requirements than normal data transmissions. As a result, retransmission of the lost packets is generally not a valid option for such applications. In these cases, a better method to attempt recovery of information from packet loss is through Forward Error Correction (FEC). FEC is one of the main methods used to
实时应用的性质意味着它们通常比正常数据传输有更严格的延迟要求。结果，对于这样的应用，丢失的分组的重新传输通常不是有效的选项。在这些情况下，尝试从数据包丢失中恢复信息的更好方法是通过前向纠错（FEC）。FEC是一种主要的检测方法
protect against packet loss over packet-switched networks [9, 10]. In particular, the use of traditional error correcting codes, such as parity, Reed-Solomon, and Hamming codes, has seen much application. To apply these mechanisms, protocol support is required. RFC 2733 [9] and RFC 3009 [11] defined one of such FEC protocols. However, in these two RFCs a few fields (the P, X, and CC fields) in the RTP header are specified in ways that are not consistent as they are designed in RTP [1]. This prevents the payload-independent validity check of the RTP packets.
防止分组交换网络上的分组丢失[9,10]。特别是，使用传统的纠错码，如奇偶校验码、里德-所罗门码和汉明码，已经得到了广泛的应用。要应用这些机制，需要协议支持。RFC 2733[9]和RFC 3009[11]定义了这样的FEC协议之一。但是，在这两个RFC中，RTP标头中的一些字段（P、X和CC字段）的指定方式与RTP[1]中的设计方式不一致。这可防止RTP数据包的有效负载独立有效性检查。
This document extends the FEC defined in RFC 2733 and RFC 3009 to include unequal error protection on the payload data. It specifies a general algorithm with the two previous RFCs as its special cases. This specification also fixes the above-mentioned inconsistency with RFC 2733 and RFC 3009, and will obsolete those two previous RFCs. Please note that the payload specified in this document is not backward compatible with RFC 2733 and RFC 3009. Because the payload specified in this document is signaled by different MIMEs from those of RFC 3009, there is no concern of misidentification of different parity FEC versions in capacity exchange. For parity FECs specified here and in RFC 2733 and RFC 3009, the payload data are unaltered and additional FEC data are sent along to protect the payload data. Hence, the communication of the payload data would flow without problem between hosts of different parity FEC versions and hosts that did not implement parity FEC. The receiving hosts with incompatible FEC from the sending host would not be able to benefit from the additional FEC data, so it is recommended that existing host implementing RFC 2733 and RFC 3009 should be updated to follow this specification when possible.
本文档扩展了RFC 2733和RFC 3009中定义的FEC，以包括有效负载数据上的不等错误保护。它指定了一个通用算法，其中前两个RFC是它的特例。本规范还修复了上述与RFC 2733和RFC 3009的不一致之处，并将淘汰之前的两个RFC。请注意，本文档中指定的有效负载与RFC 2733和RFC 3009不向后兼容。由于本文件中规定的有效载荷由不同于RFC 3009的MIME发出信号，因此不存在容量交换中不同奇偶校验FEC版本的错误识别问题。对于此处以及RFC 2733和RFC 3009中指定的奇偶校验FEC，有效负载数据保持不变，并发送附加FEC数据以保护有效负载数据。因此，有效负载数据的通信将在不同奇偶校验FEC版本的主机和未实现奇偶校验FEC的主机之间无问题地流动。具有来自发送主机的不兼容FEC的接收主机将无法从附加FEC数据中获益，因此建议在可能的情况下更新实现RFC 2733和RFC 3009的现有主机，以遵循此规范。
This document defines a payload format for RTP [1] that allows for generic forward error correction of real-time media. In this context, generic means that the FEC protocol is (1) independent of the nature of the media being protected, be it audio, video, or otherwise; (2) flexible enough to support a wide variety of FEC configurations; (3) designed for adaptivity so that the FEC technique can be modified easily without out-of-band signaling; and (4) supportive of a number of different mechanisms for transporting the FEC packets.
本文档定义了RTP[1]的有效负载格式，该格式允许实时媒体的通用前向纠错。在此上下文中，通用意味着FEC协议（1）独立于被保护媒体的性质，无论是音频、视频还是其他媒体；（2） 足够灵活，可支持多种FEC配置；（3） 设计用于自适应，以便可以轻松修改FEC技术，而无需带外信令；和（4）支持用于传输FEC分组的多个不同机制。
Furthermore, in many scenarios the bandwidth of the network connections is a very limited resource. On the other hand, most of the traditional FEC schemes are not designed for optimal utilization of the limited bandwidth resource. An often used improvement is unequal error protection that provides different levels of protection for different parts of the data stream, which vary in importance. The unequal error protection schemes can usually make more efficient use of bandwidth to provide better overall protection of the data
此外，在许多情况下，网络连接的带宽是非常有限的资源。另一方面，大多数传统的FEC方案并不是为了优化利用有限的带宽资源而设计的。一种常用的改进是不等错误保护，它为数据流的不同部分提供不同级别的保护，这些部分的重要性不同。不等差错保护方案通常可以更有效地利用带宽，以提供更好的数据总体保护
stream against the loss. Proper protocol support is essential for realizing these unequal error protection mechanisms. The application of most of the unequal error protection schemes requires having the knowledge of the importance for different parts of the data stream. For that reason, most of such schemes are designed for particular types of media according to the structure of the media protected, and as a result, are not generic.
以防损失。适当的协议支持对于实现这些不平等的错误保护机制至关重要。大多数不等错误保护方案的应用要求了解数据流不同部分的重要性。因此，大多数此类方案是根据受保护介质的结构为特定类型的介质设计的，因此不是通用的。
The FEC algorithm and protocol are defined in this document for generic forward error correction with unequal error protection for real-time media. The particular algorithm defined here is called the Uneven Level Protection (ULP). The payload data are protected by one or more protection levels. Lower protection levels can provide greater protection by using smaller group sizes (compared to higher protection levels) for generating the FEC packet. As we will discuss below, audio/video applications would generally benefit from unequal error protection schemes that give more protection to the beginning part of each packet such as ULP. The data that are closer to the beginning of the packet are in general more important and tend to carry more information than the data farther behind in the packet.
本文件中定义了FEC算法和协议，用于实时媒体中具有不等错误保护的通用前向纠错。这里定义的特定算法称为不均匀级别保护（ULP）。有效负载数据受一个或多个保护级别的保护。较低的保护级别可以通过使用较小的组大小（与较高的保护级别相比）来生成FEC分组来提供更大的保护。正如我们将在下面讨论的，音频/视频应用程序通常会受益于不等的错误保护方案，该方案为每个数据包的开始部分（如ULP）提供更多的保护。通常，距离数据包开头较近的数据比数据包后面较远的数据更重要，并且往往携带更多的信息。
It is well known that in many multimedia streams the more important parts of the data are always at the beginning of the data packet. This is the common practice in codec design since the beginning of the packet is closer to the re-synchronization marker at the header and thus is more likely to be correctly decoded. In addition, almost all media formats have the frame headers at the beginning of the packet, which is the most vital part of the packet.
众所周知，在许多多媒体流中，数据的更重要部分总是在数据包的开头。这是编解码器设计中的常见做法，因为数据包的开头更接近报头处的重新同步标记，因此更有可能被正确解码。此外，几乎所有媒体格式的帧头都位于数据包的开头，这是数据包最重要的部分。
For video streams, most modern formats have optional data partitioning modes to improve error resilience in which the video macroblock header data, motion vector data, and Discrete Cosine Transform (DCT) coefficient data are separated into their individual partitions. For example, in ITU-T H.263 version 3, there is the optional data partitioned syntax of Annex V. In MPEG-4 Visual Simple Profile, there is the optional data partitioning mode. When these modes are enabled, the video macroblock (MB) header and motion vector partitions (which are much more important to the quality of the video reconstruction) are transmitted in the partition(s) at the beginning of the video packet while residue DCT coefficient partitions (which are less important) are transmitted in the partition close to the end of the packet. Because the data is arranged in descending order of importance, it would be beneficial to provide more protection to the beginning part of the packet in transmission.
对于视频流，大多数现代格式具有可选的数据分区模式，以提高错误恢复能力，其中视频宏块头数据、运动矢量数据和离散余弦变换（DCT）系数数据被分离到各自的分区中。例如，在ITU-T H.263版本3中，有附录V的可选数据分区语法。在MPEG-4 Visual Simple Profile中，有可选的数据分区模式。当这些模式被启用时，视频宏块（MB）头部和运动矢量分区（对视频重建的质量更重要）在视频分组开始时的分区中传输，而剩余DCT系数分区（不太重要）在靠近数据包末尾的分区中传输。因为数据是按重要性降序排列的，所以在传输中为数据包的开始部分提供更多的保护将是有益的。
For audio streams, the bitstreams generated by many of the new audio codecs also contain data with different classes of importance. These different classes are then transmitted in order of descending
对于音频流，许多新的音频编解码器生成的比特流还包含具有不同重要性的数据。这些不同的类然后按降序传输
importance. Applying more protection to the beginning of the packet would also be beneficial in these cases. Even for uniform-significance audio streams, various time shifting and stretching techniques can be applied to the partially recovered audio data packets.
重要性在这些情况下，对数据包的开头应用更多的保护也将是有益的。即使对于意义一致的音频流，也可以对部分恢复的音频数据分组应用各种时间移位和拉伸技术。
Audio/video applications would generally benefit from the FEC algorithms specified in this document. With ULP, the efficiency of the protection of the media payload can potentially be further improved. This document specifies the protocol and algorithm for applying the generic FEC to the RTP media payloads.
音频/视频应用通常会受益于本文档中指定的FEC算法。使用ULP，可以潜在地进一步提高媒体有效负载的保护效率。本文件规定了将通用FEC应用于RTP媒体有效载荷的协议和算法。
The following terms are used throughout this document:
本文件中使用了以下术语：
Media Payload: The raw, unprotected user data that are transmitted from the sender. The media payload is placed inside of an RTP packet.
媒体有效负载：从发送方传输的未受保护的原始用户数据。媒体有效负载放置在RTP数据包内。
Media Header: The RTP header for the packet containing the media payload.
媒体头：包含媒体有效负载的数据包的RTP头。
Media Packet: The combination of a media payload and media header is called a media packet.
媒体包：媒体负载和媒体头的组合称为媒体包。
FEC Packet: The FEC algorithms at the transmitter take the media packets as an input. They output both the media packets that they are passed, and newly generated packets called FEC packets, which contain redundant media data used for error correction. The FEC packets are formatted according to the rules specified in this document.
FEC数据包：发射机的FEC算法将媒体数据包作为输入。它们输出所传递的媒体数据包和新生成的称为FEC数据包的数据包，其中包含用于纠错的冗余媒体数据。FEC数据包按照本文件规定的规则进行格式化。
FEC Header: The header information contained in an FEC packet.
FEC头：FEC数据包中包含的头信息。
FEC Level Header: The header information contained in an FEC packet for each level.
FEC级别标头：FEC数据包中包含的每个级别的标头信息。
FEC Payload: The payload of an FEC packet. It may be divided into multiple levels.
FEC有效载荷：FEC数据包的有效载荷。它可以分为多个层次。
Associated: A FEC packet is said to be "associated" with one or more media packets (or vice versa) when those media packets are used to generate the FEC packet (by use of the exclusive-or operation). It refers to only those packets used to generate the level 0 FEC payload, if not explicitly stated otherwise.
关联：当使用一个或多个媒体分组来生成FEC分组（通过使用异或操作）时，FEC分组被称为与一个或多个媒体分组“关联”（反之亦然）。它仅指用于生成0级FEC有效载荷的那些数据包，如果没有明确说明的话。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
The payload format described here is used when the sender in an RTP session would like to protect the media stream it is sending with generic parity FEC. The FEC supported by this format is based on simple exclusive-or (XOR) parities operation. The sender takes the packets from the media stream requiring protection and determines the protection levels for these packets and the protection length for each level. The data are grouped together as described below in Section 7. The XOR operation is applied across the payload to generate the FEC information. The results following the procedures defined here are RTP packets containing FEC information. These packets can be used at the receiver to recover the packets or parts of the packets used to generate the FEC information.
当RTP会话中的发送方希望保护其使用通用奇偶校验FEC发送的媒体流时，使用此处描述的有效负载格式。此格式支持的FEC基于简单的异或（XOR）对等操作。发送方从需要保护的媒体流中获取数据包，并确定这些数据包的保护级别以及每个级别的保护长度。数据分组如下第7节所述。XOR操作应用于整个有效负载以生成FEC信息。遵循此处定义的过程的结果是包含FEC信息的RTP数据包。这些分组可在接收机处用于恢复用于生成FEC信息的分组或分组的一部分。
The payload format for FEC contains information that allows the sender to tell the receiver exactly which media packets are protected by the FEC packet, and the protection levels and lengths for each of the levels. Specifically, each FEC packet contains an offset mask m(k) for each protection level k. If the bit i in the mask m(k) is set to 1, then media packet number N + i is protected by this FEC packet at level k. N is called the sequence number base, and is sent in the FEC packet as well. The amount of data that is protected at level k is indicated by L(k), which is also sent in the FEC packet. The protection length, offset mask, payload type, and sequence number base fully identify the parity code applied to generate the FEC packet with little overhead. A set of rules is described in Section 7.4 that defines how the mask should be set for different protection levels, with examples in Section 10.
FEC的有效载荷格式包含允许发送方准确地告诉接收方哪些媒体分组受到FEC分组的保护，以及每个级别的保护级别和长度的信息。具体地，每个FEC分组包含用于每个保护级别k的偏移掩码m（k）。如果掩码m（k）中的位i设置为1，则媒体分组号N+i由该FEC分组在k级保护。N称为序列号基，也在FEC数据包中发送。在k级受到保护的数据量由L（k）表示，L（k）也在FEC分组中发送。保护长度、偏移掩码、有效负载类型和序列号基数完全识别用于生成FEC数据包的奇偶校验码，开销很小。第7.4节描述了一组规则，定义了如何为不同的保护级别设置遮罩，第10节给出了示例。
This document also describes procedures on transmitting all the protection operation parameters in-band. This allows the sender great flexibility; the sender can adapt the protection to current network conditions and be certain the receivers can still make use of the FEC for recovery.
本文件还描述了在频带内传输所有保护操作参数的程序。这使得发送者有很大的灵活性；发送方可以根据当前网络条件调整保护，并确保接收方仍然可以使用FEC进行恢复。
At the receiver, both the FEC and original media are received. If no media packets are lost, the FEC packets can be ignored. In the event of a loss, the FEC packets can be combined with other received media to recover all or part of the missing media packets.
在接收器处，FEC和原始媒体都被接收。如果没有媒体数据包丢失，则可以忽略FEC数据包。在丢失的情况下，FEC分组可以与其他接收的媒体组合以恢复丢失的媒体分组的全部或部分。
For brevity, we define the function f(x,y,..) to be the XOR (parity) operator applied to the data blocks x,y,... The output of this function is another block, called the parity block. For simplicity, we assume here that the parity block is computed as the bitwise XOR of the input blocks. The exact procedure is specified in Section 8.
为简洁起见，我们将函数f（x，y，…）定义为应用于数据块x，y，。。。此函数的输出是另一个块，称为奇偶校验块。为简单起见，我们在此假设奇偶校验块计算为输入块的按位异或。具体程序见第8节。
Protection of data blocks using parity codes is accomplished by generating one or more parity blocks over a group of data blocks. To be most effective, the parity blocks must be generated by linearly independent combinations of data blocks. The particular combination is called a parity code. The payload format uses XOR parity codes.
使用奇偶校验码保护数据块是通过在一组数据块上生成一个或多个奇偶校验块来实现的。为了最有效，奇偶校验块必须由数据块的线性独立组合生成。这种特殊的组合称为奇偶校验码。有效负载格式使用异或奇偶校验码。
For example, consider a parity code that generates a single parity block over two data blocks. If the original media packets are a,b,c,d, the packets generated by the sender are:
例如，考虑在两个数据块上生成单个奇偶校验块的奇偶校验码。如果原始媒体分组是a、b、c、d，则发送方生成的分组是：
a b c d <-- media stream
f(a,b) f(c,d) <-- FEC stream
a b c d <-- media stream
f(a,b) f(c,d) <-- FEC stream
where time increases to the right. In this example, the error correction scheme (we use the terms scheme and code interchangeably) introduces a 50% overhead. But if b is lost, a and f(a,b) can be used to recover b.
时间向右增加。在本例中，纠错方案（我们交替使用术语方案和代码）引入了50%的开销。但是如果b丢失，a和f（a，b）可以用来恢复b。
It may be useful to point out that there are many other types of forward error correction codes that can also be used to protect the payload besides the XOR parity code. One notable example is Reed-Solomon code, and there are many others [12]. However, XOR parity code is used here because of its effectiveness and simplicity in both protocol design and implementation. This is particularly important for implementation in nodes with limited resources.
指出除异或奇偶校验码外，还有许多其他类型的前向纠错码也可用于保护有效负载，这可能是有用的。一个著名的例子是Reed-Solomon代码，还有许多其他代码[12]。然而，由于XOR奇偶校验码在协议设计和实现中的有效性和简单性，所以这里使用XOR奇偶校验码。这对于在资源有限的节点中实现尤其重要。
As we can see from the simple example above, the protection on the data depends on the size of the group. In the above example, the group size is 2. So if any one of the three packets (two payload packets and one FEC packet) is lost, the original payload data can still be recovered.
从上面的简单示例可以看出，对数据的保护取决于组的大小。在上面的示例中，组大小为2。因此，如果三个数据包（两个有效负载数据包和一个FEC数据包）中的任何一个丢失，原始有效负载数据仍然可以恢复。
In general, the FEC protection operation is a trade-off between the bandwidth and the protection strength. The more FEC packets that are generated as a fraction of the source media packets, the stronger the protection against loss but the greater the bandwidth consumed by the combined stream.
通常，FEC保护操作是带宽和保护强度之间的权衡。作为源媒体分组的一部分生成的FEC分组越多，对丢失的保护就越强，但是组合流消耗的带宽就越大。
As is the common case in most of the media payload, not all the parts of the packets are of the same importance. Using this property, one can potentially achieve more efficient use of the channel bandwidth using unequal error protection, i.e., applying different protection for different parts of the packet. More bandwidth is spent on protecting the more important parts, while less bandwidth on the less important parts.
与大多数媒体有效负载中的常见情况一样，并非数据包的所有部分都具有相同的重要性。使用此属性，可以使用不等错误保护（即，对分组的不同部分应用不同的保护）潜在地实现更有效地使用信道带宽。更多的带宽用于保护更重要的部分，而较少的带宽用于不太重要的部分。
The packets are separated into sections of decreasing importance, and protection of different strength is applied to each portion - the sections are known as "levels". The protection operation is applied independently at each level. A single FEC packet can carry parity data for multiple levels. This algorithm is called uneven level protection, or ULP.
数据包被分成重要性降低的部分，并且对每个部分应用不同强度的保护——这些部分被称为“级别”。保护操作在每个级别上独立应用。单个FEC数据包可以携带多个级别的奇偶校验数据。这种算法称为不均匀级别保护，或ULP。
The protection of ULP is illustrated in Figure 1 below. In this example, two ULP FEC packets are protecting four payload packets.
ULP的保护如下图1所示。在此示例中，两个ULP FEC数据包正在保护四个有效负载数据包。
ULP FEC packet #1 has only one level, which protects packets A and B. Instead of applying parity operation to the entire packets of A and B, it only protects a length of data of both packets. The length, which can be chosen and changed dynamically during a session, is called the protection length.
ULP FEC数据包#1只有一个级别，用于保护数据包A和B。它不是对A和B的整个数据包应用奇偶校验操作，而是只保护两个数据包的一段数据。可以在会话期间动态选择和更改的长度称为保护长度。
ULP FEC packet #2 has two protection levels. The level 0 protection is the same as for ULP FEC packet #1 except that it is operating on packets C and D. The level 1 protection is using parity operation applied on data from packets A, B, C, and D. Note that level 1 protection operates on a different set of packets from level 0 and has a different protection length from level 0, so are any other levels. Information is all conveyed in-band through the protocols specified in this document.
ULP FEC数据包#2有两个保护级别。0级保护与ULP FEC数据包#1的保护相同，只是它在数据包C和D上运行。1级保护使用对来自数据包A、B、C和D的数据应用的奇偶校验操作。请注意，1级保护在不同于0级的数据包集上运行，并且具有不同于0级的保护长度，其他水平也是如此。所有信息均通过本文件中规定的协议在频带内传输。
Packet A #####################
: :
Packet B ############### :
: :
ULP FEC Packet #1 @@@@@@@@ :
: :
Packet C ########### :
: :
Packet D ###################################
: :
ULP FEC Packet #2 @@@@@@@@@@@@@@@@@
: : :
:<-L0->:<--L1-->:
Packet A #####################
: :
Packet B ############### :
: :
ULP FEC Packet #1 @@@@@@@@ :
: :
Packet C ########### :
: :
Packet D ###################################
: :
ULP FEC Packet #2 @@@@@@@@@@@@@@@@@
: : :
:<-L0->:<--L1-->:
Figure 1: Unequal Level Protection
图1：不等级别保护
As we have discussed in the introduction, media streams usually have the more important parts at the beginning of the packet. It is usually useful to have the stronger protection in the levels closer to the beginning of the packet, and weaker protection in the levels farther back. ULP algorithm provides such FEC protection.
正如我们在引言中所讨论的，媒体流通常在数据包的开头有更重要的部分。通常，在距离数据包开始较近的级别具有较强的保护，而在距离较远的级别具有较弱的保护是有用的。ULP算法提供了这样的FEC保护。
ULP FEC not only provides more protection to the beginning of the packet (which is more important), it also avoids as much as possible the less efficient scenarios that an earlier section of a packet is unrecoverable while a later section can be recovered (and often has to be discarded).
ULP FEC不仅为数据包的开头提供了更多的保护（这一点更为重要），它还尽可能避免了效率较低的情况，即数据包的前一部分不可恢复，而后一部分可以恢复（通常必须丢弃）。
The formatting of the media packets is unaffected by FEC. If the FEC is sent as a separate stream, the media packets are sent as if there was no FEC.
媒体数据包的格式不受FEC的影响。如果FEC作为单独的流发送，则媒体分组被发送，如同没有FEC一样。
This approach has the advantage that media packets can be interpreted by receivers that do not support FEC. This compatibility with non-FEC capable receivers is particularly useful in the multicast scenarios. The overhead for using the FEC scheme is only present in FEC packets, and can be easily monitored and adjusted by tracking the amount of FEC in use.
这种方法的优点是，不支持FEC的接收器可以解释媒体分组。这种与不支持FEC的接收器的兼容性在多播场景中特别有用。使用FEC方案的开销仅存在于FEC分组中，并且可以通过跟踪使用中的FEC量来容易地监视和调整。
A FEC packet is constructed by placing an FEC header and one or more levels of FEC header and payload into the RTP payload, as shown in Figure 2:
通过将FEC报头和一个或多个级别的FEC报头和有效载荷放入RTP有效载荷中来构造FEC分组，如图2所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header (12 octets or more) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Header (10 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 0 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 0 Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 1 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 1 Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cont. |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header (12 octets or more) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Header (10 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 0 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 0 Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 1 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 1 Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cont. |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: FEC Packet Structure
图2:FEC数据包结构
The RTP header for FEC packets is only used when the FEC are sent in a separate stream from the protected payload stream (as defined in Section 14). Hence, much of the discussion below applies only to that scenario. All the fields in the RTP header of FEC packets are used according to RFC 3550 [1], with some of them further clarified below.
FEC分组的RTP报头仅在FEC以独立于受保护有效负载流（如第14节中所定义）的流发送时使用。因此，下面的大部分讨论仅适用于该场景。FEC数据包的RTP报头中的所有字段均根据RFC 3550[1]使用，其中一些字段将在下文中进一步说明。
Marker: This field is not used for this payload type, and SHALL be set to 0.
标记：此字段不用于此有效负载类型，应设置为0。
Synchronization Source (SSRC): The SSRC value SHALL be the same as the SSRC value of the media stream it protects.
同步源（SSRC）：SSRC值应与其保护的媒体流的SSRC值相同。
Sequence Number (SN): The sequence number has the standard definition - it MUST be one higher than the sequence number in the previously transmitted FEC packet.
序列号（SN）：序列号具有标准定义-它必须比先前传输的FEC数据包中的序列号高一个。
Timestamp (TS): The timestamp MUST be set to the value of the media RTP clock at the instant the FEC packet is transmitted. Thus, the TS value in FEC packets is always monotonically increasing.
时间戳（TS）：时间戳必须设置为FEC数据包传输时媒体RTP时钟的值。因此，FEC分组中的TS值总是单调增加的。
Payload type: The payload type for the FEC packets is determined through dynamic, out-of-band means. According to RFC 3550 [1], RTP participants that cannot recognize a payload type must discard it. This provides backward compatibility. The FEC mechanisms can then be
有效负载类型：FEC数据包的有效负载类型通过动态带外方式确定。根据RFC 3550[1]，无法识别有效负载类型的RTP参与者必须放弃它。这提供了向后兼容性。然后，可以使用FEC机制
used in a multicast group with mixed FEC-capable and FEC-incapable receivers, particularly when the FEC protection is sent as redundant encoding (see Section 14). In such cases, the FEC protection will have a payload type that is not recognized by the FEC-incapable receivers, and will thus be disregarded.
在具有混合FEC能力和FEC不能力接收器的多播组中使用，特别是当FEC保护作为冗余编码发送时（参见第14节）。在这种情况下，FEC保护将具有FEC无能力接收机无法识别的有效负载类型，因此将被忽略。
The FEC header is 10 octets. The format of the header is shown in Figure 3 and consists of extension flag (E bit), long-mask flag (L bit), P recovery field, X recovery field, CC recovery field, M recovery field, PT recovery field, SN base field, TS recovery field, and length recovery field.
FEC头是10个八位字节。标头的格式如图3所示，由扩展标志（E位）、长掩码标志（L位）、P恢复字段、X恢复字段、CC恢复字段、M恢复字段、PT恢复字段、SN基字段、TS恢复字段和长度恢复字段组成。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|L|P|X| CC |M| PT recovery | SN base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|L|P|X| CC |M| PT recovery | SN base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: FEC Header Format
图3:FEC头格式
The E bit is the extension flag reserved to indicate any future extension to this specification. It SHALL be set to 0, and SHOULD be ignored by the receiver.
E位是保留的扩展标志，用于指示本规范的任何未来扩展。应设置为0，接收器应忽略该值。
The L bit indicates whether the long mask is used. When the L bit is not set, the mask is 16 bits long. When the L bit is set, the mask is then 48 bits long.
L位指示是否使用长掩码。未设置L位时，掩码长度为16位。设置L位时，掩码的长度为48位。
The P recovery field, the X recovery field, the CC recovery field, the M recovery field, and the PT recovery field are obtained via the protection operation applied to the corresponding P, X, CC, M, and PT values from the RTP header of the media packets associated with the FEC packet.
P恢复字段、X恢复字段、CC恢复字段、M恢复字段和PT恢复字段通过应用于来自与FEC分组相关联的媒体分组的RTP报头的对应P、X、CC、M和PT值的保护操作获得。
The SN base field MUST be set to the lowest sequence number, taking wrap around into account, of those media packets protected by FEC (at all levels). This allows for the FEC operation to extend over any string of at most 16 packets when the L field is set to 0, or 48 packets when the L field is set to 1, and so on.
SN基本字段必须设置为受FEC保护的媒体数据包（在所有级别）的最低序列号（考虑环绕）。这允许FEC操作在L字段设置为0时扩展到最多16个分组的任何字符串上，或在L字段设置为1时扩展到48个分组上，依此类推。
The TS recovery field is computed via the protection operation applied to the timestamps of the media packets associated with this FEC packet. This allows the timestamp to be completely recovered.
TS恢复字段通过应用于与该FEC分组相关联的媒体分组的时间戳的保护操作来计算。这允许完全恢复时间戳。
The length recovery field is used to determine the length of any recovered packets. It is computed via the protection operation applied to the unsigned network-ordered 16-bit representation of the sums of the lengths (in bytes) of the media payload, CSRC list, extension and padding of each of the media packets associated with this FEC packet (in other words, the CSRC list, RTP extension, and padding of the media payload packets, if present, are "counted" as part of the payload). This allows the FEC procedure to be applied even when the lengths of the protected media packets are not identical. For example, assume that an FEC packet is being generated by xor'ing two media packets together. The length of the payload of two media packets is 3 (0b011) and 5 (0b101) bytes, respectively. The length recovery field is then encoded as 0b011 xor 0b101 = 0b110.
长度恢复字段用于确定任何已恢复数据包的长度。它是通过应用于无符号网络的保护操作来计算的，该无符号网络以16位表示，表示与该FEC分组相关联的每个媒体分组的媒体有效载荷、csc列表、扩展和填充的长度总和（以字节为单位）（换句话说，CSC列表、RTP扩展和媒体有效负载数据包的填充（如果存在）被“计算”为有效负载的一部分）。这样，即使受保护媒体数据包的长度不相同，也可以应用FEC过程。例如，假设通过将两个媒体数据包异或在一起生成FEC数据包。两个媒体数据包的有效负载长度分别为3（0b011）和5（0b101）然后将长度恢复字段编码为0b011 xor 0b101=0b110。
The FEC level header is 4 or 8 octets (depending on the L bit in the FEC header). The formats of the headers are shown in Figure 4.
FEC级报头为4或8个八位字节（取决于FEC报头中的L位）。标题的格式如图4所示。
The FEC level headers consist of a protection length field and a mask field. The protection length field is 16 bits long. The mask field is 16 bits long (when the L bit is not set) or 48 bits long (when the L bit is set).
FEC级标头由保护长度字段和掩码字段组成。保护长度字段的长度为16位。掩码字段的长度为16位（未设置L位时）或48位（设置L位时）。
The mask field in the FEC level header indicates which packets are associated with the FEC packet at the current level. It is either 16 or 48 bits depending on the value of the L bit. If bit i in the mask is set to 1, then the media packet with sequence number N + i is associated with this FEC packet, where N is the SN Base field in the FEC packet header. The most significant bit of the mask corresponds to i=0, and the least significant to i=15 when the L bit is set to 0, or i=47 when the L bit is set to 1.
FEC级别报头中的掩码字段指示哪些包与当前级别的FEC包相关联。它是16位还是48位取决于L位的值。如果掩码中的比特i设置为1，则序列号为N+i的媒体分组与该FEC分组相关联，其中N是FEC分组报头中的SN基本字段。掩码的最高有效位对应于i=0，当L位设置为0时，最低有效位对应于i=15，或当L位设置为1时，i=47。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection Length | mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask cont. (present only when L = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection Length | mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask cont. (present only when L = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ULP Level Header Format
图4:ULP级别标头格式
The setting of the mask field shall follow the following rules:
掩码字段的设置应遵循以下规则：
a. A media packet SHALL be protected only once at each protection level higher than level 0. A media packet MAY be protected more than once at level 0 by different packets, providing the protection lengths of level 0 of these packets are equal.
a. 在高于0级的每个保护级别上，媒体数据包只能保护一次。如果媒体分组的级别0的保护长度相等，则可以通过不同分组在级别0对媒体分组进行多次保护。
b. For a media packet to be protected at level p, it MUST also be protected at level p-1 in any FEC packets. Please note that the protection level p for a media packet can be in an FEC packet that is different from the one that contains protection level p-1 for the same media packet.
b. 对于要在p级保护的媒体数据包，它在任何FEC数据包中也必须在p-1级保护。请注意，媒体数据包的保护级别p可以位于FEC数据包中，该FEC数据包与包含相同媒体数据包的保护级别p-1的FEC数据包不同。
c. If a ULP FEC packet contains protection at level p, it MUST also contain protection at level p-1. Note that the combination of payload packets that are protected in level p may be different from those of level p-1.
c. 如果ULP FEC数据包包含p级保护，则它还必须包含p-1级保护。注意，在级别p中受保护的有效载荷分组的组合可能不同于级别p-1的有效载荷分组的组合。
The rationale for rule (a) is that multiple protection increases the complexity of the recovery implementation. At higher levels, the multiple protection offers diminishing benefit, so its application is restricted to level 0 for simpler implementation. The rationale for rule (b) is that the protection offset (for each associated packet) is not explicitly signaled in the protocol. With this restriction, the offset can be easily deducted from protection lengths of the levels. The rationale of rule (c) is that the level of protection is not explicitly indicated. This rule is set to implicitly specify the levels.
规则（a）的基本原理是多重保护增加了恢复实施的复杂性。在更高级别上，多重保护提供的好处越来越小，因此其应用程序仅限于级别0，以简化实现。规则（b）的基本原理是，保护偏移量（对于每个关联的数据包）在协议中没有显式地用信号表示。有了这一限制，可以很容易地从电平的保护长度中扣除偏移量。规则（c）的基本原理是没有明确说明保护级别。此规则设置为隐式指定级别。
One example of the protection combinations is illustrated in Figure 5 below. It is the same example as shown in Figure 1. This same example is also shown in more detail in Section 10.2 to illustrate how the fields in the headers are set.
保护组合的一个示例如下图5所示。这与图1所示的示例相同。第10.2节也详细介绍了该示例，以说明如何设置标题中的字段。
Packet A #####################
: :
Packet B ############### :
: :
ULP FEC Packet #1 @@@@@@@@ :
: :
Packet C ########### :
: :
Packet D ###################################
: :
ULP FEC Packet #2 @@@@@@@@@@@@@@@@@
: : :
:<-L0->:<--L1-->:
Packet A #####################
: :
Packet B ############### :
: :
ULP FEC Packet #1 @@@@@@@@ :
: :
Packet C ########### :
: :
Packet D ###################################
: :
ULP FEC Packet #2 @@@@@@@@@@@@@@@@@
: : :
:<-L0->:<--L1-->:
Payload packet # | ULP FEC packet that protects at level
| L0 L1
---------------------+---------------------------------------
A | #1 #2
B | #1 #2
C | #2 #2
D | #2 #2
Payload packet # | ULP FEC packet that protects at level
| L0 L1
---------------------+---------------------------------------
A | #1 #2
B | #1 #2
C | #2 #2
D | #2 #2
Figure 5: An Example of Protection Combination
图5：保护组合示例
In this example, ULP FEC packet #1 only has protection level 0. ULP FEC packet #2 has protection levels 0 and 1. Read across the table, it is shown that payload packet A is protected by ULP FEC packet #1 at level 0, by ULP FEC packet #2 at level 1, and so on. Also, it can be easily seen from the table that ULP FEC packet #2 protects at level 0 payload packets C and D, at level 1 payload packets A-D, and so on. For additional examples with more details, please refer to Section 10, "Examples".
在此示例中，ULP FEC数据包#1的保护级别仅为0。ULP FEC数据包#2的保护级别为0和1。从表中可以看出，有效负载数据包A在0级受ULP FEC数据包#1保护，在1级受ULP FEC数据包#2保护，依此类推。此外，从表中可以很容易地看出，ULP FEC数据包#2在0级有效负载数据包C和D、1级有效负载数据包A-D等处进行保护。有关更多详细信息的其他示例，请参阅第10节“示例”。
The payload of the ULP FEC packets of each level is the protection operation (XOR) applied to the media payload and padding of the media packets associated with the ULP FEC packet at that level. Details are described in Section 8 on the protection operation.
每个级别的ULP FEC分组的有效载荷是应用于媒体有效载荷的保护操作（XOR）和在该级别上与ULP FEC分组相关联的媒体分组的填充。有关保护操作的详细信息，请参见第8节。
The size of the ULP FEC packets is determined by the protection lengths chosen for the protection operation. In the above example, ULP FEC packet #1 has length L0 (plus the header overhead). ULP FEC packet #2 with two levels has length L0+L1 (plus the header overhead). It is longer than some of the packets it protects (packets B and C in this example), and is shorter than some of the packets it protects (packets A and D in this example).
ULP FEC分组的大小由为保护操作选择的保护长度确定。在上面的示例中，ULP FEC分组#1的长度为L0（加上报头开销）。具有两个级别的ULP FEC数据包#2的长度为L0+L1（加上报头开销）。它比它保护的一些数据包（本例中的数据包B和C）长，比它保护的一些数据包（本例中的数据包A和D）短。
Note that it's possible for the FEC packet (non-ULP and ULP) to be larger than the longest media packets it protects because of the overhead from the headers and/or if a large protection length is chosen for ULP. This could cause difficulties if this results in the FEC packet exceeding the Maximum Transmission Unit size for the path along which it is sent.
注意，由于来自报头的开销和/或如果为ULP选择了较大的保护长度，FEC数据包（非ULP和ULP）可能大于其保护的最长媒体数据包。如果这导致FEC分组超过其发送路径的最大传输单元大小，则这可能导致困难。
FEC packets are formed from an "FEC bit string" that is generated from the data of the protected media RTP packets. More specifically, the FEC bit string is the bitwise exclusive OR of the "protected bit strings" of the protected media RTP packets.
FEC分组由从受保护媒体RTP分组的数据生成的“FEC比特串”形成。更具体地说，FEC比特串是受保护媒体RTP分组的“受保护比特串”的按位异或。
The following procedure MAY be followed for the protection operation. Other procedures MAY be used, but the end result MUST be identical to the one described here.
保护操作可遵循以下程序。可以使用其他程序，但最终结果必须与此处描述的相同。
In the case of the FEC header, the protected bit strings (80 bits in length) are generated for each media packet to be protected at FEC level 0. It is formed by concatenating the following fields together in the order specified:
在FEC报头的情况下，为每个要在FEC级别0保护的媒体分组生成受保护比特串（长度为80比特）。它是通过按指定顺序将以下字段连接在一起形成的：
o The first 64 bits of the RTP header (64 bits)
o RTP报头的前64位（64位）
o Unsigned network-ordered 16-bit representation of the media 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位）
After the FEC bit string is formed by applying parity operation on the protected bit strings, the FEC header is generated from the FEC bit string as follows:
通过对受保护的位串应用奇偶校验操作形成FEC位串后，根据FEC位串生成FEC头，如下所示：
The first (most significant) 2 bits in the FEC bit string are skipped. The next bit in the FEC bit string is written into the P recovery bit of the FEC header in the FEC packet. The next bit in the FEC bit string is written into the E recovery bit of the FEC header. The next 4 bits of the FEC bit string are written into the CC recovery field of the FEC header. The next bit is written into the M recovery bit of the FEC header. The next 7 bits of the FEC bit string are written into the PT recovery field in the FEC header. The next 16 bits are skipped. The next 32 bits of the FEC bit string are written into the TS recovery field in the FEC header. The next 16 bits are written into the length recovery field in the packet header.
跳过FEC位字符串中的前2位（最高有效位）。FEC位字符串中的下一位写入FEC分组中FEC报头的P恢复位。FEC位字符串中的下一位写入FEC头的E恢复位。FEC位串的下4位写入FEC报头的CC recovery字段。下一位写入FEC报头的M恢复位。FEC位串的下7位写入FEC报头中的PT recovery字段。接下来的16位被跳过。FEC位字符串的下32位写入FEC报头中的TS恢复字段。接下来的16位写入数据包报头中的长度恢复字段。
For generation of the FEC payload, the protected bit strings are simply the protected RTP packets. The FEC bit string is thus the bitwise exclusive OR of these protected media RTP packets. Such FEC bit strings need to be generated for each level, as the group of protected payload packets may be different for each level. If the lengths of the protected RTP packets are not equal, each shorter packet MUST be padded to the length of the longest packet by adding octet 0 at the end.
为了生成FEC有效载荷，受保护的比特串只是受保护的RTP分组。因此，FEC位字符串是这些受保护媒体RTP数据包的按位异或。需要为每个级别生成这样的FEC比特串，因为每个级别的受保护有效负载分组组可能不同。如果受保护的RTP数据包的长度不相等，则每个较短的数据包必须通过在末尾添加八位字节0来填充到最长数据包的长度。
For protection level n (n = 0, 1, ...), only Ln octets of data are set as the FEC level n payload data after the level n ULP header. The data is the Ln octets of data starting with the (Sn + 13)th octet in the FEC bit string, where:
对于保护级别n（n=0，1，…），在级别n ULP报头之后，只有Ln个八位字节的数据被设置为FEC级别n有效负载数据。数据是以FEC位字符串中的第（Sn+13）个八位字节开始的Ln个八位字节的数据，其中：
Sn = sum(Li : 0 <= i < n).
Sn=总和（Li:0<=i<n）。
Li is the protection length of level i, and S0 is defined to be 0. The reason for omitting the first 12 octets is that that information is protected by the FEC header already.
Li为一级保护长度，S0定义为0。省略前12个八位字节的原因是该信息已经受到FEC报头的保护。
The FEC packets allow end systems to recover from the loss of media packets. This section describes the procedure for performing this recovery.
FEC数据包允许终端系统从媒体数据包的丢失中恢复。本节介绍执行此恢复的过程。
Recovery requires two distinct operations. The first determines which packets (media and FEC) must be combined in order to recover a missing packet. Once this is done, the second step is to actually reconstruct the data. The second step MUST be performed as described below. The first step MAY be based on any algorithm chosen by the implementer. Different algorithms result in a trade-off between complexity and the ability to recover missing packets, if possible.
恢复需要两个不同的操作。第一种方法确定为了恢复丢失的数据包，必须组合哪些数据包（媒体和FEC）。完成后，第二步是实际重建数据。第二步必须按如下所述执行。第一步可以基于实现者选择的任何算法。如果可能的话，不同的算法会在复杂性和恢复丢失数据包的能力之间进行权衡。
The lost payload packets may be recovered in full or in parts depending on the data-loss situation due to the nature of unequal error protection (when it is used). The partial recovery of the packet can be detected by checking the recovery length of the packet retrieved from the FEC header against the actual length of the recovered payload data.
丢失的有效载荷分组可以全部或部分地恢复，这取决于由于不平等错误保护的性质（当使用时）而导致的数据丢失情况。可以通过检查从FEC报头检索的分组的恢复长度与恢复的有效负载数据的实际长度来检测分组的部分恢复。
Let T be the list of packets (FEC and media) that can be combined to recover some media packet xi at level 0. The procedure is as follows:
让T是可以组合在0级恢复一些媒体分组席的分组（FEC和媒体）列表。程序如下：
1. For the media packets in T, compute the first 80 bits of the protected bit string following the procedure as described for generating the FEC header in the previous section.
1. 对于T中的媒体分组，按照上一节中描述的用于生成FEC报头的过程，计算受保护比特串的前80位。
2. For the FEC packet in T, the FEC bit string is the 80-bit FEC header.
2. 对于T中的FEC分组，FEC位字符串是80位FEC报头。
3. Calculate the recovery bit string as the bitwise exclusive OR of the protected bit string generated from all the media packets in T and the FEC bit string generated from all the FEC packets in T.
3. 将恢复位字符串计算为T中所有媒体包生成的受保护位字符串和T中所有FEC包生成的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 recovery bit string.
5. 将新数据包的版本设置为2。跳过恢复位字符串中的前2位。
6. Set the Padding bit in the new packet to the next bit in the recovery bit string.
6. 将新数据包中的填充位设置为恢复位字符串中的下一位。
7. Set the Extension bit in the new packet to the next bit in the recovery bit string.
7. 将新数据包中的扩展位设置为恢复位字符串中的下一位。
8. Set the CC field to the next 4 bits in the recovery bit string.
8. 将CC字段设置为恢复位字符串中的下4位。
9. Set the marker bit in the new packet to the next bit in the recovery bit string.
9. 将新数据包中的标记位设置为恢复位字符串中的下一位。
10. Set the payload type in the new packet to the next 7 bits in the recovery bit string.
10. 将新数据包中的有效负载类型设置为恢复位字符串中的下7位。
11. Set the SN field in the new packet to xi. Skip the next 16 bits in the recovery bit string.
11. 将新数据包中的SN字段设置为席。跳过恢复位字符串中的下16位。
12. Set the TS field in the new packet to the next 32 bits in the recovery bit string.
12. 将新数据包中的TS字段设置为恢复位字符串中的下一个32位。
13. Take the next 16 bits of the recovery bit string. Whatever unsigned integer this represents (assuming network-order), take that many bytes from the recovery bit string and append them to the new packet. This represents the CSRC list, extension, payload, and the padding of the RTP payload.
13. 取恢复位串的下16位。无论这代表什么无符号整数（假设网络顺序），从恢复位字符串中提取这么多字节，并将它们附加到新数据包中。这表示CSC列表、扩展、有效负载和RTP有效负载的填充。
14. Set the SSRC of the new packet to the SSRC of the media stream it's protecting, i.e., the SSRC of the media stream to which the FEC stream is associated.
14. 将新数据包的SSRC设置为其保护的媒体流的SSRC，即FEC流关联的媒体流的SSRC。
This procedure will recover the header of an RTP packet up to the SSRC field.
此过程将RTP数据包的报头恢复到SSRC字段。
Let T be the list of packets (FEC and media) that can be combined to recover some media packet xi at a certain protection level. The procedure is as follows:
让T是可以组合在一定保护级别上恢复一些媒体分组席的分组（FEC和媒体）列表。程序如下：
1. Assume that we are reconstructing the data for level n, the first step is to get the protection length of level n (Ln) from the ULP header of level n.
1. 假设我们正在重建级别n的数据，第一步是从级别n的ULP报头获取级别n（Ln）的保护长度。
2. For the FEC packets in T, the FEC bit string of level n is FEC level n payload, i.e., the Ln octets of data following the ULP header of level n.
2. 对于T中的FEC分组，n级的FEC比特串是FEC n级有效载荷，即，在n级的ULP报头之后的数据的Ln个八位组。
3. For the media packets in T, the protected bit string of level n is Ln octets of data starting with the (Sn + 13)th octet of the packet. Sn is the same as defined in Section 8.2. Note that the protection of level 0 starts from the 13th octet of the media packet after the SSRC field. The information of the first 12 octets are protected by the FEC header.
3. 对于T中的媒体分组，级别n的受保护比特串是从分组的第（Sn+13）个八位字节开始的数据的Ln个八位字节。Sn与第8.2节中的定义相同。请注意，级别0的保护从SSRC字段之后的媒体数据包的第13个八位字节开始。前12个八位字节的信息受FEC报头保护。
4. If any of the protected bit strings of level n generated from the media packets are shorter than the protection length of the current level, pad them to that length. The padding of octet 0 MUST be added at the end of the bit string.
4. 如果从媒体分组生成的任何级别n的受保护位串短于当前级别的保护长度，则将其填充到该长度。必须在位字符串的末尾添加八位字节0的填充。
5. Calculate the recovery bit string as the bitwise exclusive OR of the protected bit string of level n generated from all the media packets in T and the FEC bit string of level n generated from all the FEC packets in T.
5. 将恢复位字符串计算为从T中的所有媒体分组生成的n级受保护位字符串和从T中的所有FEC分组生成的n级FEC位字符串的按位异或。
6. The recovery bit string of the current protection level as generated above is combined through concatenation with the recovery bit string of all the other levels to form the (fully or partially) recovered media packet. Note that the recovery bit string of each protection level MUST be placed at the correct location in the recovered media packet for that level based on protection length settings.
6. 如上所生成的当前保护级别的恢复比特串通过与所有其他级别的恢复比特串串联而组合，以形成（完全或部分）恢复的媒体分组。请注意，每个保护级别的恢复位字符串必须根据保护长度设置放置在该级别的恢复媒体数据包中的正确位置。
7. The total length of the recovered media packet is recovered from the recovery operation at protection level 0 of the recovered media packet. This information can be used to check if the complete recovery operation (of all levels) has recovered the packet to its full length.
7. 在恢复的媒体分组的保护级别为0时，从恢复操作中恢复恢复的媒体分组的总长度。此信息可用于检查（所有级别的）完整恢复操作是否已将数据包恢复到其完整长度。
The data protected at the lower protection level is recoverable in a majority of the cases if the higher-level protected data is recoverable. This procedure (together with the procedure for the lower protection levels) will usually recover both the header and payload of an RTP packet up to the protection length of the current level.
如果较高级别的受保护数据是可恢复的，则在大多数情况下，以较低保护级别保护的数据是可恢复的。此过程（以及较低保护级别的过程）通常会将RTP数据包的报头和有效负载恢复到当前级别的保护长度。
In the first two examples considered below (Sections 10.1 and 10.2), we assume that the FEC streams are sent through a separate RTP session as described in Section 14.1. For these examples, we assume that four media packets are to be sent, A, B, C, and D, from SSRC 2. Their sequence numbers are 8, 9, 10, and 11, respectively, and have timestamps of 3, 5, 7, and 9, respectively. Packets A and C use payload type 11, and packets B and D use payload type 18. Packet A has 200 bytes of payload, packet B 140, packet C 100, and packet D 340. Packets A and C have their marker bit set.
在下面考虑的前两个示例（第10.1节和第10.2节）中，我们假设FEC流通过单独的RTP会话发送，如第14.1节所述。对于这些示例，我们假设要从SSRC 2发送四个媒体包，A、B、C和D。它们的序列号分别为8、9、10和11，时间戳分别为3、5、7和9。数据包A和C使用有效负载类型11，数据包B和D使用有效负载类型18。数据包A具有200字节的有效载荷、数据包B 140、数据包C 100和数据包D 340。数据包A和C设置了它们的标记位。
The third example (Section 10.3) is to illustrate when the FEC data is sent as redundant data with the payload packets.
第三个示例（第10.3节）用于说明FEC数据何时与有效负载分组一起作为冗余数据发送。
We can protect the four payload packets to their full length in one single level with one FEC packet. This offers similar protection as RFC 2733. The scheme is as shown in Figure 6.
我们可以使用一个FEC数据包在一个级别上保护四个有效负载数据包的完整长度。这提供了与RFC 2733类似的保护。该方案如图6所示。
+-------------------+ :
Packet A | | :
+-------------+-----+ :
Packet B | | :
+---------+---+ :
Packet C | | :
+---------+-----------------------+
Packet D | |
+---------------------------------+
:
+---------------------------------+
Packet FEC | |
+---------------------------------+
: :
:<------------- L0 -------------->:
+-------------------+ :
Packet A | | :
+-------------+-----+ :
Packet B | | :
+---------+---+ :
Packet C | | :
+---------+-----------------------+
Packet D | |
+---------------------------------+
:
+---------------------------------+
Packet FEC | |
+---------------------------------+
: :
:<------------- L0 -------------->:
Figure 6: FEC Scheme with Single-Level Protection
图6：具有单级保护的FEC方案
An FEC packet is generated from these four packets. We assume that payload type 127 is used to indicate an FEC packet. The resulting RTP header is shown in Figure 7.
从这四个包生成FEC包。我们假设有效负载类型127用于指示FEC分组。生成的RTP头如图7所示。
The FEC header in the FEC packet is shown in Figure 8.
FEC包中的FEC头如图8所示。
The FEC level header for level 0 is shown in Figure 9.
级别0的FEC级别标头如图9所示。
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|0|0|0 0 0 0|0|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|0|0 0 0 0|0|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 2 Padding: 0 Extension: 0 Marker: 0 PT: 127 SN: 1 TS: 9 SSRC: 2
版本：2填充：0扩展：0标记：0 PT:127序列号：1 TS:9 SSRC:2
Figure 7: RTP Header of FEC Packet
图7:FEC数据包的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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0 0 0 0|0|0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1 0 1 1 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|0|0 0 0 0|0|0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1 0 1 1 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: 0 [this specification]
L: 0 [short 16-bit mask]
P rec.: 0 [0 XOR 0 XOR 0 XOR 0]
X rec.: 0 [0 XOR 0 XOR 0 XOR 0]
CC rec.: 0 [0 XOR 0 XOR 0 XOR 0]
M rec.: 0 [1 XOR 0 XOR 1 XOR 0]
PT rec.: 0 [11 XOR 18 XOR 11 XOR 18]
SN base: 8 [min(8,9,10,11)]
TS rec.: 8 [3 XOR 5 XOR 7 XOR 9]
len. rec.: 372 [200 XOR 140 XOR 100 XOR 340]
E: 0 [this specification]
L: 0 [short 16-bit mask]
P rec.: 0 [0 XOR 0 XOR 0 XOR 0]
X rec.: 0 [0 XOR 0 XOR 0 XOR 0]
CC rec.: 0 [0 XOR 0 XOR 0 XOR 0]
M rec.: 0 [1 XOR 0 XOR 1 XOR 0]
PT rec.: 0 [11 XOR 18 XOR 11 XOR 18]
SN base: 8 [min(8,9,10,11)]
TS rec.: 8 [3 XOR 5 XOR 7 XOR 9]
len. rec.: 372 [200 XOR 140 XOR 100 XOR 340]
Figure 8: FEC Header of FEC Packet
图8:FEC数据包的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 0 0 0 0 0 1 0 1 0 1 0 1 0 0|1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 0 0 0 0 0 1 0 1 0 1 0 1 0 0|1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L0: 340 [the longest of 200, 140, 100, and 340] mask: 61440 [with Bits 1, 2, 3, and 4 marked accordingly for Packets 8, 9, 10, and 11]
L0:340[最长的200、140、100和340]掩码：61440[为数据包8、9、10和11相应地标记位1、2、3和4]
The payload length for level 0 is 340 bytes.
级别0的有效负载长度为340字节。
Figure 9: FEC Level Header (Level 0)
图9:FEC级别标头（级别0）
A more complex example is to use FEC at two levels. The level 0 FEC will provide greater protection to the beginning part of the payload packets. The level 1 FEC will apply additional protection to the rest of the packets. This is illustrated in Figure 10. In this example, L0 = 70 and L1 = 90.
一个更复杂的例子是在两个级别使用FEC。0级FEC将为有效负载数据包的开始部分提供更大的保护。1级FEC将对其余数据包应用额外的保护。如图10所示。在本例中，L0=70和L1=90。
+------:--------:---+
Packet A | : : |
+------:------+-:---+
Packet B | : | :
+------:--+---+ :
: :
+------+ :
ULP #1 | | :
+------+ :
: :
+------:--+ :
Packet C | : | :
+------:--+-----:-----------------+
Packet D | : : |
+------:--------:-----------------+
: :
+------:--------+
ULP #2 | : |
+------:--------+
: : :
:<-L0->:<--L1-->:
+------:--------:---+
Packet A | : : |
+------:------+-:---+
Packet B | : | :
+------:--+---+ :
: :
+------+ :
ULP #1 | | :
+------+ :
: :
+------:--+ :
Packet C | : | :
+------:--+-----:-----------------+
Packet D | : : |
+------:--------:-----------------+
: :
+------:--------+
ULP #2 | : |
+------:--------+
: : :
:<-L0->:<--L1-->:
Figure 10: ULP FEC Scheme with Protection Level 0 and Level 1
图10：具有0级和1级保护的ULP FEC方案
This will result in two FEC packets - #1 and #2.
这将导致两个FEC数据包#1和#2。
The resulting ULP FEC packet #1 will have the RTP header as shown in Figure 11. The FEC header for ULP FEC packet #1 will be as shown in Figure 12. The level 0 ULP header for #1 will be as shown in Figure 13.
产生的ULP FEC数据包#1将具有如图11所示的RTP报头。ULP FEC数据包#1的FEC报头如图12所示。#1的0级ULP标头如图13所示。
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|0|0|0 0 0 0|1|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|0|0 0 0 0|1|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 2 Padding: 0 Extension: 0 Marker: 1 PT: 127 SN: 1 TS: 5 SSRC: 2
版本：2填充：0扩展：0标记：1 PT:127序列号：1 TS:5 SSRC:2
Figure 11: RTP Header of FEC Packet #1
图11:FEC数据包的RTP报头#1
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|0|0|0 0 0 0|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|0|0 0 0 0|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: 0 [this specification]
L: 0 [short 16-bit mask]
P rec.: 0 [0 XOR 0 XOR 0 XOR 0]
X rec.: 0 [0 XOR 0 XOR 0 XOR 0]
CC rec.: 0 [0 XOR 0 XOR 0 XOR 0]
M rec.: 0 [1 XOR 0 XOR 1 XOR 0]
PT rec.: 25 [11 XOR 18]
SN base: 8 [min(8,9)]
TS rec.: 6 [3 XOR 5]
len. rec.: 68 [200 XOR 140]
E: 0 [this specification]
L: 0 [short 16-bit mask]
P rec.: 0 [0 XOR 0 XOR 0 XOR 0]
X rec.: 0 [0 XOR 0 XOR 0 XOR 0]
CC rec.: 0 [0 XOR 0 XOR 0 XOR 0]
M rec.: 0 [1 XOR 0 XOR 1 XOR 0]
PT rec.: 25 [11 XOR 18]
SN base: 8 [min(8,9)]
TS rec.: 6 [3 XOR 5]
len. rec.: 68 [200 XOR 140]
Figure 12: FEC Header of ULP FEC Packet #1
图12:ULP FEC数据包的FEC头#1
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 0 0 0 0 0 0 0 1 0 0 0 1 1 0|1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 0 0 0 0 0 0 0 1 0 0 0 1 1 0|1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L0: 70 mask: 49152 [with Bits 1 and 2 marked accordingly for Packets 8 and 9]
L0:70掩码：49152[为数据包8和9相应标记位1和2]
The payload length for level 0 is 70 bytes.
级别0的有效负载长度为70字节。
Figure 13: FEC Level Header (Level 0) for FEC Packet #1
图13:FEC数据包#1的FEC级别报头（级别0）
The resulting FEC packet #2 will have the RTP header as shown in Figure 14. The FEC header for FEC packet #2 will be as shown in Figure 15. The level 0 ULP header for #2 will be as shown in Figure 16. The level 1 ULP header for #2 will be as shown in Figure 17.
产生的FEC数据包#2将具有如图14所示的RTP报头。FEC数据包#2的FEC报头如图15所示。#2的0级ULP标头如图16所示。#2的1级ULP标头如图17所示。
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|0|0|0 0 0 0|1|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|0|0 0 0 0|1|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 2 Padding: 0 Extension: 0 Marker: 1 PT: 127 SN: 2 TS: 9 SSRC: 2
版本：2填充：0扩展：0标记：1 PT:127序列号：2 TS:9 SSRC:2
Figure 14: RTP Header of FEC Packet #2
图14:FEC数据包的RTP报头#2
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|0|0|0 0 0 0|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1 0 0 1 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|0|0 0 0 0|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1 0 0 1 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: 0 [this specification]
L: 0 [short 16-bit mask]
P rec.: 0 [0 XOR 0 XOR 0 XOR 0]
X rec.: 0 [0 XOR 0 XOR 0 XOR 0]
CC rec.: 0 [0 XOR 0 XOR 0 XOR 0]
M rec.: 0 [1 XOR 0 XOR 1 XOR 0]
PT rec.: 25 [11 XOR 18]
SN base: 8 [min(8,9,10,11)]
TS rec.: 14 [7 XOR 9]
len. rec.: 304 [100 XOR 340]
E: 0 [this specification]
L: 0 [short 16-bit mask]
P rec.: 0 [0 XOR 0 XOR 0 XOR 0]
X rec.: 0 [0 XOR 0 XOR 0 XOR 0]
CC rec.: 0 [0 XOR 0 XOR 0 XOR 0]
M rec.: 0 [1 XOR 0 XOR 1 XOR 0]
PT rec.: 25 [11 XOR 18]
SN base: 8 [min(8,9,10,11)]
TS rec.: 14 [7 XOR 9]
len. rec.: 304 [100 XOR 340]
Figure 15: FEC Header of FEC Packet #2
图15:FEC数据包的FEC报头#2
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 0 0 0 0 0 0 0 1 0 0 0 1 1 0|0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 0 0 0 0 0 0 0 1 0 0 0 1 1 0|0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L0: 70 mask: 12288 [with Bits 3 and 4 marked accordingly for Packets 10 and 11]
L0:70掩码：12288[为数据包10和11相应标记位3和4]
The payload length for level 0 is 70 bytes.
级别0的有效负载长度为70字节。
Figure 16: FEC Level Header (Level 0) for FEC Packet #2
图16:FEC数据包#2的FEC级别报头（级别0）
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 0 0 0 0 0 0 0 1 0 1 1 0 1 0|1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 0 0 0 0 0 0 0 1 0 1 1 0 1 0|1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L1: 90 mask: 61440 [with Bits 1, 2, 3, and 4 marked accordingly for Packets 8, 9, 10, and 11]
L1:90掩码：61440[为数据包8、9、10和11相应地标记位1、2、3和4]
The payload length for level 1 is 90 bytes.
级别1的有效负载长度为90字节。
Figure 17: FEC Level Header (Level 1) for FEC Packet #2
图17:FEC数据包#2的FEC级别报头（级别1）
This example illustrates FEC sent as redundant coding in the same stream as the payload. We assume that five media packets are to be sent, A, B, C, D, and E, from SSRC 2. Their sequence numbers are 8, 9, 10, 11, and 12, respectively, and have timestamps of 3, 5, 7, 9, and 11, respectively. All the media data is coded with primary coding (and FEC as redundant coding only protects the primary coding) and uses payload type 11. Packet A has 200 bytes of payload, packet B 140, packet C 100, packet D 340, and packet E 160. Packets A and C have their marker bit set.
该示例说明了在与有效负载相同的流中作为冗余编码发送的FEC。我们假设将从SSRC 2发送五个媒体包，A、B、C、D和E。它们的序列号分别为8、9、10、11和12，时间戳分别为3、5、7、9和11。所有媒体数据都使用主编码（FEC作为冗余编码仅保护主编码）进行编码，并使用有效负载类型11。分组A具有200字节的有效载荷、分组B 140、分组C 100、分组D 340和分组E 160。数据包A和C设置了它们的标记位。
The FEC scheme we use will be with one level as illustrated by Figure 6 in Section 10.1. The protection length L0 = 340 octets.
我们使用的FEC方案将具有一个级别，如第10.1节图6所示。保护长度L0=340个八位字节。
A redundant coding packetization is used with payload type 100. The payload type of the FEC is assumed to be 127. The first four RED packets, RED #1 through RED #4, each contains an individual media packet, A, B, C, or D, respectively. The FEC data protecting the media data in the first four media packets is generated. The fifth packet, RED #5, contains this FEC data as redundant coding along with media packet E.
冗余编码分组用于有效负载类型100。假设FEC的有效载荷类型为127。前四个红包，从RED#1到RED#4，分别包含一个单独的媒体包A、B、C或D。生成保护前四个媒体分组中的媒体数据的FEC数据。第五个数据包，红色#5，包含作为冗余编码的FEC数据以及媒体数据包E。
RED Packet #1: Media Packet A
RED Packet #2: Media Packet B
RED Packet #3: Media Packet C
RED Packet #4: Media Packet D
RED Packet #5: FEC Packet, Media Packet E
RED Packet #1: Media Packet A
RED Packet #2: Media Packet B
RED Packet #3: Media Packet C
RED Packet #4: Media Packet D
RED Packet #5: FEC Packet, Media Packet E
RED packets #1 through #4 will have the structure as shown in Figure 18. The RTP header of the RED packet #1 is as shown in Figure 19, with all the other RED packets in similar format with corresponding sequence numbers and timestamps. The primary encoding block header of the RED packets is as shown in Figure 20.
红包#1到#4的结构如图18所示。红色数据包#1的RTP报头如图19所示，所有其他红色数据包的格式类似，具有相应的序列号和时间戳。红包的主要编码块头如图20所示。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header (RED) - 6 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Encoding Block Header (RED) - 1 octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Packet Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header (RED) - 6 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Encoding Block Header (RED) - 1 octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Packet Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: RED Packet Structure - Media Data Only
图18：红包结构-仅媒体数据
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|0|0|0 0 0 0|0|1 1 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|0|0 0 0 0|0|1 1 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 2 Padding: 0 Extension: 0 Marker: 0 [Even though media packet A has marker set] PT: 100 [Payload type for RED] SN: 1 TS: 5 SSRC: 2
版本：2填充：0扩展：0标记：0[即使媒体数据包A已设置标记]PT:100[红色的有效负载类型]序列号：1 TS:5 SSRC:2
Figure 19: RTP Header of RED Packet #1
图19：红色数据包的RTP报头#1
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0 0 0 1 0 1 1|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0 0 0 1 0 1 1|
+-+-+-+-+-+-+-+-+
F bit: 0 [This is the primary coding data] Block PT: 11 [The payload type of media]
F位：0[这是主编码数据]块PT:11[媒体的有效负载类型]
Figure 20: Primary Encoding Block Header
图20：主编码块头
The FEC data is generated not directly from the RED packets, but from the virtual RTP packets containing the media packet data. Those virtual RTP packets can be very easily generated from the RED packets both with and without redundant coding included. The conversion from RED packets to virtual RTP packets is simply done by (1) removing any RED block headers and redundant coding data, and (2) replacing the PT in the RTP header with the PT of the primary coding.
FEC数据不是直接从红包生成的，而是从包含媒体分组数据的虚拟RTP分组生成的。这些虚拟RTP包可以非常容易地从包含冗余编码和不包含冗余编码的红包生成。从红包到虚拟RTP包的转换只需（1）删除任何红包头和冗余编码数据，以及（2）用主编码的PT替换RTP头中的PT即可。
Note: In the payload format for redundant coding as specified by RFC 2198, the marker bit is lost as soon as the primary coding is carried in the RED packets. So the marker bit cannot be recovered regardless of whether or not the FEC is used.
注：在RFC 2198规定的冗余编码有效载荷格式中，一旦红包中携带了主编码，标记位就会丢失。因此，无论是否使用FEC，都无法恢复标记位。
As mentioned above, RED packet #5 will contain the FEC data (that protects media packets A, B, C, and D) as well as the data of media packet E. The structure of RED packet #5 is as illustrated in Figure 21.
如上所述，红包#5将包含FEC数据（保护媒体包A、B、C和D）以及媒体包E的数据。红包#5的结构如图21所示。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header (RED) - 6 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redundant Encoding Block Header (RED) - 4 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Packet Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Encoding Block Header (RED) - 1 octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Packet Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header (RED) - 6 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redundant Encoding Block Header (RED) - 4 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Packet Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Encoding Block Header (RED) - 1 octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Packet Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: RED Packet Structure - With FEC Data
图21：红色数据包结构-具有FEC数据
The RTP header of the RED packets with FEC included is the same as shown in Figure 19, with their corresponding sequence numbers and timestamps.
包含FEC的红包的RTP报头与图19所示相同，具有相应的序列号和时间戳。
In RED packet #5, the redundant encoding block header for the FEC packet data block is as shown below in Figure 22. It will be followed by the FEC packet data, which, in this case, includes an FEC header (10 octets as shown in Figure 8), ULP level 0 header (4 octets as shown in Figure 9), and the ULP level 0 data (340 octets as set for level 0). These are followed by the primary encoding block that contains the data of media packet E.
在红色分组#5中，FEC分组数据块的冗余编码块报头如下图22所示。接着是FEC分组数据，在这种情况下，FEC分组数据包括FEC报头（如图8所示的10个八位字节）、ULP 0级报头（如图9所示的4个八位字节）和ULP 0级数据（为0级设置的340个八位字节）。随后是包含媒体分组E的数据的主编码块。
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|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 1 0 1 1 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 1 0 1 1 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F bit: 1 [This is the redundant coding data]
Block PT: 127 [The dynamic payload type for FEC]
TS Offset: 0 [The instance at which the FEC data is
transmitted]
Block Len: 354 [FEC header (10 octets) plus ULP level 0 header
(4 octets) and ULP level 0 data (340 octets)]
F bit: 1 [This is the redundant coding data]
Block PT: 127 [The dynamic payload type for FEC]
TS Offset: 0 [The instance at which the FEC data is
transmitted]
Block Len: 354 [FEC header (10 octets) plus ULP level 0 header
(4 octets) and ULP level 0 data (340 octets)]
Figure 22: Redundant Encoding Block Header
图22：冗余编码块头
There are two ways to use FEC with encryption in secure communications: one way is to apply the FEC on already encrypted payloads, and the other way is to apply the FEC before the encryption. The first case is encountered when FEC is needed by a not trusted node during transmission after the media data is encrypted. The second case is encountered when media data is protected by FEC before it is transmitted through a secured transport.
在安全通信中，有两种方法将FEC与加密一起使用：一种方法是将FEC应用于已加密的有效载荷，另一种方法是在加密之前应用FEC。第一种情况是，在媒体数据加密后的传输过程中，不受信任的节点需要FEC。第二种情况是，媒体数据在通过安全传输传输之前受到FEC的保护。
Since the protected payload of this FEC is RTP packets, applying FEC on encrypted payloads is primarily applicable in the case of secure RTP (SRTP) [13]. Because the FEC applies XOR across the payload, the FEC packets should be cryptographically as secure as the original payload. In such cases, additional encryption of the FEC packets is not necessary.
由于该FEC的受保护有效载荷是RTP数据包，因此在加密有效载荷上应用FEC主要适用于安全RTP（SRTP）[13]。因为FEC在整个有效负载上应用XOR，所以FEC数据包在加密方面应该与原始有效负载一样安全。在这种情况下，不需要对FEC分组进行额外加密。
In the following discussion, it is assumed that the FEC is applied to the payload before the encryption. The use of FEC has implications on the usage and changing of keys for encryption. As the FEC packets do consist of a separate stream, there are a number of combinations on the usage of encryption. These include:
在下面的讨论中，假设在加密之前将FEC应用于有效载荷。FEC的使用对加密密钥的使用和更改有影响。由于FEC数据包由单独的流组成，因此在加密的使用上有许多组合。这些措施包括：
o The FEC stream may be encrypted, while the media stream is not.
o FEC流可以被加密，而媒体流不被加密。
o The media stream may be encrypted, while the FEC stream is not.
o 媒体流可以被加密，而FEC流不被加密。
o The media stream and FEC stream are both encrypted, but using the same key.
o 媒体流和FEC流都是加密的，但使用相同的密钥。
o The media stream and FEC stream are both encrypted, but using different keys.
o 媒体流和FEC流都是加密的，但使用不同的密钥。
The first three of these would require all application-level signaling protocols used to be aware of the usage of FEC, and to thus exchange keys and negotiate encryption usage on the media and FEC streams separately. In the final case, no such additional mechanisms are needed. The first two cases present a layering violation, as ULP FEC packets should be treated no differently than other RTP packets. Encrypting just one stream may also make certain known-plaintext attacks possible. For these reasons, applications utilizing encryption SHOULD encrypt both streams, i.e., the last two options.
前三种协议要求所有应用级信令协议用于了解FEC的使用情况，从而分别在媒体和FEC流上交换密钥和协商加密使用情况。在最后一种情况下，不需要这种额外的机制。前两种情况表现出分层冲突，因为ULP FEC数据包应与其他RTP数据包进行相同的处理。仅加密一个流也可能使某些已知的明文攻击成为可能。出于这些原因，使用加密的应用程序应该加密两个流，即最后两个选项。
Furthermore, because the encryption may potentially be weakened by the known relationship between the media payload and FEC data for certain ciphers, different encryption keys MUST be used for each stream when the media payload and the FEC data are sent in separate streams. Note that when SRTP [13] is used for security of the RTP sessions, different keys for each RTP session are required by the SRTP specification.
此外，由于针对某些密码的媒体有效载荷和FEC数据之间的已知关系可能会削弱加密，因此当媒体有效载荷和FEC数据在单独的流中发送时，必须对每个流使用不同的加密密钥。注意，当SRTP[13]用于RTP会话的安全性时，SRTP规范要求每个RTP会话使用不同的密钥。
The changing of encryption keys is another crucial issue that needs to be addressed. Consider the case where two packets a and b are sent along with the FEC packet that protects them. The keys used to encrypt a and b are different, so which key should be used to decode the FEC packet? In general, old keys need to be cached, so that when the keys change for the media stream, the old key can be used until it is determined that the key has changed for the ULP FEC packets as well. Furthermore, the new key SHOULD be used to encrypt the FEC packets that are generated from a combination of payload packets encrypted by the old and new keys. The sender and the receiver need to define how the encryption is performed and how the keys are used.
更改加密密钥是另一个需要解决的关键问题。考虑两个数据包A和B连同保护它们的FEC包一起发送的情况。用于加密a和b的密钥不同，那么应该使用哪个密钥来解码FEC数据包？通常，需要缓存旧密钥，以便当媒体流的密钥改变时，可以使用旧密钥，直到确定ULP FEC分组的密钥也改变为止。此外，新密钥应用于加密由新旧密钥加密的有效载荷分组的组合生成的FEC分组。发送方和接收方需要定义如何执行加密以及如何使用密钥。
Altering the FEC data and packets can have a big impact on the reconstruction operation. An attack by changing some bits in the FEC data can have a significant effect on the calculation and the recovery of the payload packets. For example, changing the length recovery field can result in the recovery of a packet that is too long. Also, the computational complexity of the recovery can easily be affected for up to at least one order of magnitude. Depending on the application scenario, it may be helpful to perform a sanity check on the received payload and FEC data before performing the recovery operation and to determine the validity of the recovered data from the recovery operation before using them.
改变FEC数据和数据包会对重建操作产生很大影响。通过改变FEC数据中的某些位进行的攻击会对有效载荷数据包的计算和恢复产生重大影响。例如，更改长度恢复字段可能导致恢复过长的数据包。此外，恢复的计算复杂性很容易受到至少一个数量级的影响。根据应用场景的不同，在执行恢复操作之前，对接收到的有效负载和FEC数据执行健全性检查，并在使用恢复操作之前确定恢复数据的有效性可能会有所帮助。
Another issue with the use of FEC is its impact on network congestion. In many situations, the packet loss in the network is induced by congestions. In such scenarios, adding FEC when encountering increasing network losses should be avoided. If it is
使用FEC的另一个问题是它对网络拥塞的影响。在许多情况下，网络中的数据包丢失是由拥塞引起的。在这种情况下，应避免在遇到不断增加的网络损失时添加FEC。如果是
used on a widespread basis, this can result in increased congestion and eventual congestion collapse. The applications may include stronger protections while at the same time reduce the bandwidth for the payload packets. In any event, implementations MUST NOT substantially increase the total amount of bandwidth in use (including the payload and the FEC) as network losses increase.
在广泛使用的基础上，这可能会导致拥堵加剧，最终导致拥堵崩溃。这些应用可以包括更强的保护，同时减少有效载荷分组的带宽。在任何情况下，实施不得随着网络损耗的增加而显著增加使用中的带宽总量（包括有效负载和FEC）。
The general congestion control considerations for transporting RTP data apply; see RTP [1] and any applicable RTP profile (e.g., RTP/AVP [14]). An additional requirement if best-effort service is being used is that users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path, and experiencing the same network conditions, would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
传输RTP数据的一般拥塞控制注意事项适用；参见RTP[1]和任何适用的RTP配置文件（例如RTP/AVP[14]）。如果使用尽力而为服务，另一个要求是此有效负载格式的用户必须监控数据包丢失，以确保数据包丢失率在可接受的参数范围内。如果通过相同网络路径并经历相同网络条件的TCP流将实现在合理时间尺度上测量的平均吞吐量，即不小于RTP流所实现的平均吞吐量，则认为丢包是可接受的。可以通过实现拥塞控制机制来适应传输速率（或分层多播会话订阅的层数），或者如果丢失率高得令人无法接受，则通过安排接收机离开会话来满足该条件。
Four new media subtypes have been registered with IANA, as described in this section. This registration is done using the registration template [3] and following RFC 3555 [4].
如本节所述，IANA注册了四种新媒体子类型。此注册使用注册模板[3]和以下RFC 3555[4]完成。
Type name: audio
类型名称：音频
Subtype name: ulpfec
子类型名称：ulpfec
Required parameters:
所需参数：
rate: The RTP timestamp rate that is used to mark the time of transmission of the FEC packet in a separate stream. In cases in which it is sent as redundant data to another stream, the rate SHALL be the same as the primary encoding it is used to protect. When used in a separate stream, the rate SHALL be larger than 1000 Hz, to provide sufficient resolution to RTCP operations. The selected rate MAY be any value above 1000 Hz but is RECOMMENDED to match the rate of the media this stream protects.
速率：RTP时间戳速率，用于标记FEC数据包在单独流中的传输时间。在将其作为冗余数据发送到另一个流的情况下，速率应与用于保护的主要编码相同。当在单独的流中使用时，速率应大于1000 Hz，以便为RTCP操作提供足够的分辨率。所选速率可以是高于1000 Hz的任何值，但建议与该流保护的媒体速率相匹配。
Optional parameters:
可选参数：
onelevelonly: This specifies whether only one level of FEC protection is used. The permissible values are 0 and 1. If 1 is signaled, only one level of FEC protection SHALL be used in the stream. If 0 is signaled, more than one level of FEC protection MAY be used. If omitted, it has the default value of 0.
onelevelonly：指定是否仅使用一级FEC保护。允许值为0和1。如果信号为1，则流中只能使用一级FEC保护。如果发出0信号，则可使用一个以上级别的FEC保护。如果省略，则默认值为0。
Encoding considerations: This format is framed (see Section 4.8 in the template document [3]) and contains binary data.
编码注意事项：此格式为框架格式（见模板文件[3]第4.8节），包含二进制数据。
Security considerations: The same security considerations apply to these media type registrations as to the payloads for them, as detailed in RFC 5109.
安全注意事项：这些媒体类型注册的安全注意事项与有效负载的安全注意事项相同，详见RFC 5109。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 5109
已发布规范：RFC 5109
Applications that use this media type: Multimedia applications that seek to improve resiliency to loss by sending additional data with the media stream.
使用此媒体类型的应用程序：通过使用媒体流发送附加数据来提高丢失恢复能力的多媒体应用程序。
Additional information: none
其他信息：无
Person & email address to contact for further information: Adam Li adamli@hyervision.com IETF Audio/Video Transport Working Group
联系人和电子邮件地址，以获取更多信息：Adam Liadamli@hyervision.comIETF音频/视频传输工作组
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media, type depends on RTP framing, and hence is only defined for transfer via RTP [1]. Transport within other framing protocols SHALL NOT be defined as this is a robustness mechanism for RTP.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[1]。不应定义其他帧协议内的传输，因为这是RTP的健壮性机制。
Author: Adam Li adamli@hyervision.com
作者：亚当·李adamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: video
类型名称：视频
Subtype name: ulpfec
子类型名称：ulpfec
Required parameters:
所需参数：
rate: The RTP timestamp rate that is used to mark the time of transmission of the FEC packet in a separate stream. In cases in which it is sent as redundant data to another stream, the rate SHALL be the same as the primary encoding it is used to protect. When used in a separate stream, the rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. The selected rate MAY be any value above 1000 Hz, but is RECOMMENDED to match the rate of the media this stream protects.
速率：RTP时间戳速率，用于标记FEC数据包在单独流中的传输时间。在将其作为冗余数据发送到另一个流的情况下，速率应与用于保护的主要编码相同。当在单独的流中使用时，速率应大于1000 Hz，以便为RTCP操作提供足够的分辨率。所选速率可以是高于1000 Hz的任何值，但建议与此流保护的媒体速率相匹配。
Optional parameters:
可选参数：
onelevelonly: This specifies whether only one level of FEC protection is used. The permissible values are 0 and 1. If 1 is signaled, only one level of FEC protection SHALL be used in the stream. If 0 is signaled, more than one level of FEC protection MAY be used. If omitted, it has the default value of 0.
onelevelonly：指定是否仅使用一级FEC保护。允许值为0和1。如果信号为1，则流中只能使用一级FEC保护。如果发出0信号，则可使用一个以上级别的FEC保护。如果省略，则默认值为0。
Encoding considerations: This format is framed (see Section 4.8 in the template document [3]) and contains binary data.
编码注意事项：此格式为框架格式（见模板文件[3]第4.8节），包含二进制数据。
Security considerations: The same security considerations apply to these media type registrations as to the payloads for them, as detailed in RFC 5109.
安全注意事项：这些媒体类型注册的安全注意事项与有效负载的安全注意事项相同，详见RFC 5109。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 5109
已发布规范：RFC 5109
Applications that use this media type: Multimedia applications that seek to improve resiliency to loss by sending additional data with the media stream.
使用此媒体类型的应用程序：通过使用媒体流发送附加数据来提高丢失恢复能力的多媒体应用程序。
Additional information: none
其他信息：无
Person & email address to contact for further information: Adam Li adamli@hyervision.com IETF Audio/Video Transport Working Group
联系人和电子邮件地址，以获取更多信息：Adam Liadamli@hyervision.comIETF音频/视频传输工作组
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [1]. Transport within other framing protocols SHALL NOT be defined as this is a robustness mechanism for RTP.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[1]。不应定义其他帧协议内的传输，因为这是RTP的健壮性机制。
Author: Adam Li adamli@hyervision.com
作者：亚当·李adamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: text
类型名称：text
Subtype name: ulpfec
子类型名称：ulpfec
Required parameters:
所需参数：
rate: The RTP timestamp rate that is used to mark the time of transmission of the FEC packet in a separate stream. In cases in which it is sent as redundant data to another stream, the rate SHALL be the same as the primary encoding it is used to protect. When used in a separate stream, the rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. The selected rate MAY be any value above 1000 Hz, but is RECOMMENDED to match the rate of the media this stream protects.
速率：RTP时间戳速率，用于标记FEC数据包在单独流中的传输时间。在将其作为冗余数据发送到另一个流的情况下，速率应与用于保护的主要编码相同。当在单独的流中使用时，速率应大于1000 Hz，以便为RTCP操作提供足够的分辨率。所选速率可以是高于1000 Hz的任何值，但建议与此流保护的媒体速率相匹配。
Optional parameters:
可选参数：
onelevelonly: This specifies whether only one level of FEC protection is used. The permissible values are 0 and 1. If 1 is signaled, only one level of FEC protection SHALL be used in the stream. If 0 is signaled, more than one level of FEC protection MAY be used. If omitted, it has the default value of 0.
onelevelonly：指定是否仅使用一级FEC保护。允许值为0和1。如果信号为1，则流中只能使用一级FEC保护。如果发出0信号，则可使用一个以上级别的FEC保护。如果省略，则默认值为0。
Encoding considerations: This format is framed (see Section 4.8 in the template document [3]) and contains binary data.
编码注意事项：此格式为框架格式（见模板文件[3]第4.8节），包含二进制数据。
Security considerations: The same security considerations apply to these media type registrations as to the payloads for them, as detailed in RFC 5109.
安全注意事项：这些媒体类型注册的安全注意事项与有效负载的安全注意事项相同，详见RFC 5109。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 5109
已发布规范：RFC 5109
Applications that use this media type: Multimedia applications that seek to improve resiliency to loss by sending additional data with the media stream.
使用此媒体类型的应用程序：通过使用媒体流发送附加数据来提高丢失恢复能力的多媒体应用程序。
Additional information: none
其他信息：无
Person & email address to contact for further information: Adam Li adamli@hyervision.com IETF Audio/Video Transport Working Group
联系人和电子邮件地址，以获取更多信息：Adam Liadamli@hyervision.comIETF音频/视频传输工作组
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [1]. Transport within other framing protocols SHALL NOT be defined as this is a robustness mechanism for RTP.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[1]。不应定义其他帧协议内的传输，因为这是RTP的健壮性机制。
Author: Adam Li adamli@hyervision.com
作者：亚当·李adamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: application
类型名称：应用程序
Subtype name: ulpfec
子类型名称：ulpfec
Required parameters:
所需参数：
rate: The RTP timestamp rate that is used to mark the time of transmission of the FEC packet in a separate stream. In cases in which it is sent as redundant data to another stream, the rate SHALL be the same as the primary encoding it is used to protect. When used in a separate stream, the rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. The selected rate MAY be any value above 1000 Hz, but is RECOMMENDED to match the rate of the media this stream protects.
速率：RTP时间戳速率，用于标记FEC数据包在单独流中的传输时间。在将其作为冗余数据发送到另一个流的情况下，速率应与用于保护的主要编码相同。当在单独的流中使用时，速率应大于1000 Hz，以便为RTCP操作提供足够的分辨率。所选速率可以是高于1000 Hz的任何值，但建议与此流保护的媒体速率相匹配。
Optional parameters:
可选参数：
onelevelonly: This specifies whether only one level of FEC protection is used. The permissible values are 0 and 1. If 1 is signaled, only one level of FEC protection SHALL be used in the stream. If 0 is signaled, more than one level of FEC protection MAY be used. If omitted, it has the default value of 0.
onelevelonly：指定是否仅使用一级FEC保护。允许值为0和1。如果信号为1，则流中只能使用一级FEC保护。如果发出0信号，则可使用一个以上级别的FEC保护。如果省略，则默认值为0。
Encoding considerations: This format is framed (see Section 4.8 in the template document [3]) and contains binary data.
编码注意事项：此格式为框架格式（见模板文件[3]第4.8节），包含二进制数据。
Security considerations: The same security considerations apply to these media type registrations as to the payloads for them, as detailed in RFC 5109.
安全注意事项：这些媒体类型注册的安全注意事项与有效负载的安全注意事项相同，详见RFC 5109。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 5109
已发布规范：RFC 5109
Applications that use this media type: Multimedia applications that seek to improve resiliency to loss by sending additional data with the media stream.
使用此媒体类型的应用程序：通过使用媒体流发送附加数据来提高丢失恢复能力的多媒体应用程序。
Additional information: none
其他信息：无
Person & email address to contact for further information: Adam Li adamli@hyervision.com IETF Audio/Video Transport Working Group
联系人和电子邮件地址，以获取更多信息：Adam Liadamli@hyervision.comIETF音频/视频传输工作组
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [1]. Transport within other framing protocols SHALL NOT be defined as this is a robustness mechanism for RTP.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[1]。不应定义其他帧协议内的传输，因为这是RTP的健壮性机制。
Author: Adam Li adamli@hyervision.com
作者：亚当·李adamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
The FEC packets can be sent to the receiver along with the protected payload primarily in one of two ways: as a separate stream, or in the same stream as redundant encoding. The configuration options MUST be indicated out of band. This section also describes how this can be accomplished using the Session Description Protocol (SDP), specified in RFC 2327 [8].
FEC分组可以与受保护的有效载荷一起主要以两种方式之一发送到接收机：作为单独的流，或者作为冗余编码在同一流中。必须在带外指示配置选项。本节还描述了如何使用RFC 2327[8]中指定的会话描述协议（SDP）实现这一点。
When the FEC packets are sent in a separate stream, several pieces of information must be conveyed:
当FEC数据包在单独的流中发送时，必须传输几条信息：
o The address and port to which the FEC is being sent
o 正在向其发送FEC的地址和端口
o The payload type number for the FEC
o FEC的有效负载类型编号
o Which media stream the FEC is protecting
o FEC正在保护哪个媒体流
There is no static payload type assignment for FEC, so dynamic payload type numbers MUST be used. The SSRC of the FEC stream MUST be set to that of the protected payload stream. The association of the FEC stream with its corresponding stream is done by line grouping in SDP [5] with the FEC semantics [6] or other external means.
FEC没有静态有效负载类型分配，因此必须使用动态有效负载类型编号。FEC流的SSRC必须设置为受保护有效负载流的SSRC。FEC流与其对应流的关联通过SDP[5]中的行分组和FEC语义[6]或其他外部手段来完成。
Following the principles as discussed in Section 5.2 of RFC 3550 [1], multiplexing of the FEC stream and its associated payload stream is usually provided by the destination transport address (network address and port number), which is different for each RTP session. Sending FEC together with the payload in one single RTP session and multiplex only by SSRC or payload type precludes: (1) the use of different network paths or network resource allocations for the payload and the FEC protection data; (2) reception of a subset of the media if desired, particularly for the hosts that do not understand FEC; and (3) receiver implementations that use separate processes for the different media. In addition, multiplexing FEC with payload data streams will affect the timing and sequence number space of the original payload stream, which is usually undesirable. So the FEC stream and the payload stream SHOULD be sent through two separate RTP session, and multiplexing them by payload type into one single RTP session SHOULD be avoided. In addition, the FEC and the payload MUST NOT be multiplexed by SSRC into one single RTP session since they always have the same SSRC.
按照RFC 3550[1]第5.2节中讨论的原则，FEC流及其相关有效负载流的复用通常由目的地传输地址（网络地址和端口号）提供，该地址对于每个RTP会话是不同的。在单个RTP会话中与有效载荷一起发送FEC，并且仅通过SSRC或有效载荷类型进行多路复用，从而排除：（1）对有效载荷和FEC保护数据使用不同的网络路径或网络资源分配；（2） 如果需要，尤其是对于不理解FEC的主机，接收媒体的子集；以及（3）对不同介质使用单独过程的接收器实现。此外，将FEC与有效负载数据流复用将影响原始有效负载流的定时和序列号空间，这通常是不需要的。因此，FEC流和有效负载流应该通过两个单独的RTP会话发送，并且应该避免将它们按有效负载类型复用到单个RTP会话中。此外，由于FEC和有效载荷始终具有相同的SSRC，因此SSRC不得将它们多路复用到单个RTP会话中。
Just like any media stream, the port number and the payload type number for the FEC stream are conveyed in their m line in the SDP. There is no static payload type assignment for FEC, so dynamic payload type numbers MUST be used. The binding to the number is indicated by an rtpmap attribute. The name used in this binding is "ulpfec". The address that the FEC stream is on is conveyed in its corresponding c line.
与任何媒体流一样，FEC流的端口号和有效负载类型号在SDP中以m线传输。FEC没有静态有效负载类型分配，因此必须使用动态有效负载类型编号。与编号的绑定由rtpmap属性指示。此绑定中使用的名称是“ulpfec”。FEC流所在的地址在其对应的c线中传输。
The association relationship between the FEC stream and the payload stream it protects is conveyed through media line grouping in SDP (RFC 3388) [5] using FEC semantics (RFC 4756) [6]. The FEC stream and the protected payload stream form an FEC group.
FEC流与其保护的有效负载流之间的关联关系通过使用FEC语义（RFC 4756）[6]的SDP（RFC 3388）[5]中的媒体线分组来传送。FEC流和受保护的有效负载流形成FEC组。
The following is an example SDP for FEC application in a multicast session:
以下是多播会话中FEC应用程序的SDP示例：
v=0
o=adam 289083124 289083124 IN IP4 host.example.com
s=ULP FEC Seminar
t=0 0
c=IN IP4 224.2.17.12/127
a=group:FEC 1 2
a=group:FEC 3 4
m=audio 30000 RTP/AVP 0
a=mid:1
m=application 30002 RTP/AVP 100
a=rtpmap:100 ulpfec/8000
a=mid:2
m=video 30004 RTP/AVP 31
a=mid:3
m=application 30004 RTP/AVP 101
c=IN IP4 224.2.17.13/127
a=rtpmap:101 ulpfec/8000
a=mid:4
v=0
o=adam 289083124 289083124 IN IP4 host.example.com
s=ULP FEC Seminar
t=0 0
c=IN IP4 224.2.17.12/127
a=group:FEC 1 2
a=group:FEC 3 4
m=audio 30000 RTP/AVP 0
a=mid:1
m=application 30002 RTP/AVP 100
a=rtpmap:100 ulpfec/8000
a=mid:2
m=video 30004 RTP/AVP 31
a=mid:3
m=application 30004 RTP/AVP 101
c=IN IP4 224.2.17.13/127
a=rtpmap:101 ulpfec/8000
a=mid:4
The presence of two a=group lines in this SDP indicates that there are two FEC groups. The first FEC group, as indicated by the "a=group:FEC 1 2" line, consists of stream 1 (an audio stream using PCM [14]) and stream 2 (the protecting FEC stream). The FEC stream is sent to the same multicast group and has the same Time to Live (TTL) as the audio, but on a port number two higher. The second FEC group, as indicated by the "a=group:FEC 3 4" line, consists of stream 3 (a video stream) and stream 4 (the protecting FEC stream). The FEC stream is sent to a different multicast address, but has the same port number (30004) as the payload video stream.
此SDP中存在两条a=组线表示存在两个FEC组。如“a=组：FEC 1 2”行所示，第一个FEC组由流1（使用PCM[14]的音频流）和流2（保护FEC流）组成。FEC流被发送到同一个多播组，并且与音频具有相同的生存时间（TTL），但位于更高的端口号2。如“a＝group:fec34”行所示，第二FEC组由流3（视频流）和流4（保护FEC流）组成。FEC流被发送到不同的多播地址，但具有与有效负载视频流相同的端口号（30004）。
When the FEC stream is being sent as a secondary codec in the redundant encoding format, this must be signaled through SDP. To do this, the procedures defined in RFC 2198 [7] are used to signal the use of redundant encoding. The FEC payload type is indicated in the same fashion as any other secondary codec. The FEC MUST protect only the main codec, with the payload of FEC engine coming from virtual RTP packets created from the main codec data. The virtual RTP packets can be very easily converted from the RFC 2198 packets by simply (1) removing all the additional headers and the redundant coding data, and (2) replacing the payload type in the RTP header with that of the primary codec.
当FEC流以冗余编码格式作为辅助编解码器发送时，必须通过SDP发出信号。为此，RFC 2198[7]中定义的程序用于发出使用冗余编码的信号。FEC有效负载类型以与任何其他辅助编解码器相同的方式指示。FEC必须仅保护主编解码器，FEC引擎的有效负载来自从主编解码器数据创建的虚拟RTP数据包。通过简单地（1）移除所有附加报头和冗余编码数据，以及（2）用主编解码器的有效载荷类型替换RTP报头中的有效载荷类型，可以非常容易地从RFC 2198分组转换虚拟RTP分组。
Note: In the payload format for redundant coding as specified by RFC 2198, the marker bit is lost as soon as the primary coding is carried in the RED packets. So the marker bit cannot be recovered regardless of whether or not the FEC is used.
注：在RFC 2198规定的冗余编码有效载荷格式中，一旦红包中携带了主编码，标记位就会丢失。因此，无论是否使用FEC，都无法恢复标记位。
Because the FEC data (including the ULP header) is sent in the same packets as the protected payload, the FEC data is associated with the protected payload by being bundled in the same stream.
由于FEC数据（包括ULP报头）在与受保护的有效负载相同的分组中发送，因此FEC数据通过捆绑在相同流中而与受保护的有效负载相关联。
When the FEC stream is sent as a secondary codec in the redundant encoding format, this can be signaled through SDP. To do this, the procedures defined in RFC 2198 [7] are used to signal the use of redundant encoding. The FEC payload type is indicated in the same fashion as any other secondary codec. An rtpmap attribute MUST be used to indicate a dynamic payload type number for the FEC packets. The FEC MUST protect only the main codec.
当FEC流以冗余编码格式作为辅助编解码器发送时，可以通过SDP发出信号。为此，RFC 2198[7]中定义的程序用于发出使用冗余编码的信号。FEC有效负载类型以与任何其他辅助编解码器相同的方式指示。rtpmap属性必须用于指示FEC数据包的动态有效负载类型编号。FEC必须仅保护主编解码器。
For example:
例如：
m=audio 12345 RTP/AVP 121 0 5 100
a=rtpmap:121 red/8000/1
a=rtpmap:100 ulpfec/8000
a=fmtp:121 0/5/100
m=audio 12345 RTP/AVP 121 0 5 100
a=rtpmap:121 red/8000/1
a=rtpmap:100 ulpfec/8000
a=fmtp:121 0/5/100
This SDP indicates that there is a single audio stream, which can consist of PCM (media format 0), DVI (media format 5), the redundant encodings (indicated by media format 121, which is bound to red through the rtpmap attribute), or FEC (media format 100, which is bound to ulpfec through the rtpmap attribute). Although the FEC format is specified as a possible coding for this stream, the FEC MUST NOT be sent by itself for this stream. Its presence in the m line is required only because non-primary codecs must be listed here according to RFC 2198. The fmtp attribute indicates that the redundant encodings format can be used, with DVI as a secondary coding and FEC as a tertiary encoding.
该SDP表示存在单个音频流，该音频流可由PCM（媒体格式0）、DVI（媒体格式5）、冗余编码（由媒体格式121表示，通过rtpmap属性绑定到红色）或FEC（媒体格式100，通过rtpmap属性绑定到ulpfec）组成。尽管FEC格式被指定为该流的可能编码，但FEC不能针对该流自行发送。仅因为根据RFC 2198，此处必须列出非主编解码器，所以需要在m行中显示它。fmtp属性表示可以使用冗余编码格式，DVI作为二级编码，FEC作为三级编码。
Some considerations are needed when SDP is used for offer / answer [15] exchange.
当SDP用于报价/应答[15]交换时，需要考虑一些因素。
The "onelevelonly" parameter is declarative. For streams declared as sendonly, the value indicates whether only one level of FEC will be sent. For streams declared as recvonly or sendrecv, the value indicates what the receiver accepts to receive.
“onelevelonly”参数是声明性的。对于声明为sendonly的流，该值指示是否只发送一级FEC。对于声明为RECVOLY或sendrecv的流，该值指示接收方接受接收的内容。
When the FEC is sent as a separate stream and signaled through media line grouping in SDP (RFC 3388) [5] using FEC semantics (RFC 4756) [6], the offering side MUST implement both RFC 3388 and RFC 4756. The rules for offer / answer in RFC 3388 and RFC 4756 SHALL be followed with the below additional consideration. For all offers with FEC, the answerer MAY refuse the separate FEC session by setting the port to 0, and remove the "a=group" attribute that groups that FEC session with the RTP session being protected. If the answerer accepts the usage of FEC, the answerer simply accepts the FEC RTP session and the grouping in the offer by including the same grouping in the answer. Note that the rejection of the FEC RTP session does not prevent the media sessions from being accepted and used without FEC.
当FEC作为单独的流发送并通过SDP中的媒体线分组（RFC 3388）[5]使用FEC语义（RFC 4756）[6]发出信号时，提供方必须同时实现RFC 3388和RFC 4756。应遵循RFC 3388和RFC 4756中的报价/应答规则，并考虑以下额外因素。对于具有FEC的所有报价，应答者可以通过将端口设置为0来拒绝单独的FEC会话，并删除将该FEC会话与受保护的RTP会话分组的“a=group”属性。如果应答者接受FEC的使用，应答者只需通过在应答中包含相同的分组来接受FEC RTP会话和报价中的分组。请注意，拒绝FEC RTP会话并不妨碍在没有FEC的情况下接受和使用媒体会话。
When the FEC stream is sent as a secondary codec in the redundant encoding format (RFC 2198) [7], the offering side can indicate the FEC stream as specified in Section 14.2. The answerer MAY reject the FEC stream by removing the payload type for the FEC stream. To accept the usage of FEC, the answerer must in the answer include the FEC payload type. Note that in cases in which the redundancy payload format [7] is used with FEC as the only secondary codec, when the FEC stream is rejected the redundant encoding payload type SHOULD also be removed.
当FEC流以冗余编码格式（RFC 2198）[7]作为辅助编解码器发送时，供应方可以按照第14.2节的规定指示FEC流。应答者可以通过移除FEC流的有效负载类型来拒绝FEC流。要接受FEC的使用，回答者必须在回答中包括FEC有效负载类型。注意，在冗余有效载荷格式[7]与FEC一起用作唯一的辅助编解码器的情况下，当FEC流被拒绝时，冗余编码有效载荷类型也应被移除。
This document describes a generic protocol for Forward Error Correction supporting a wide range of short block parity FEC algorithms, such as simple and interleaved parity codes. The scheme is limited to interleaving parity codes over a distance of 48 packets. This FEC algorithm is fully compatible with hosts that are not FEC-capable. Since the media payload is not altered and the protection is sent as additional information, the receivers that are unaware of the generic FEC as specified in this document can simply ignore the additional FEC information and process the main media payload. This interoperability is particularly important for compatibility with existing hosts, and also in the scenario where many different hosts need to communicate with each other at the same time, such as during multicast.
本文档描述了一种用于前向纠错的通用协议，该协议支持广泛的短块奇偶校验FEC算法，例如简单奇偶校验码和交织奇偶校验码。该方案仅限于在48个包的距离上交错奇偶校验码。此FEC算法与不支持FEC的主机完全兼容。由于媒体有效载荷没有改变，并且保护作为附加信息发送，因此不知道本文档中指定的通用FEC的接收器可以简单地忽略附加FEC信息并处理主媒体有效载荷。这种互操作性对于与现有主机的兼容性尤其重要，并且在许多不同主机需要同时相互通信的场景中（例如在多播期间）也是如此。
The generic FEC algorithm specified in this document is also a generic protection algorithm with the following features: (1) it is independent of the nature of the media being protected, whether that media is audio, video, or otherwise; (2) it is flexible enough to support a wide variety of FEC mechanisms and settings; (3) it is
本文件中规定的通用FEC算法也是一种通用保护算法，具有以下特点：（1）它与被保护媒体的性质无关，无论该媒体是音频、视频还是其他媒体；（2） 它足够灵活，可以支持多种FEC机制和设置；（3） 是的
designed for adaptivity, so that the FEC parameters can be modified easily without resorting to out-of-band signaling; and (4) it supports a number of different mechanisms for transporting the FEC packets.
设计用于自适应，因此可以轻松修改FEC参数，而无需借助带外信令；和（4）它支持用于传输FEC分组的许多不同机制。
The FEC specified here also provides the user with Unequal Error Protection capabilities. Some other algorithms may also provide the Unequal Error Protection capabilities through other means. For example, an Unequal Erasure Protection (UXP) scheme has been proposed in the AVT Working Group in "An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams". The UXP scheme applies unequal error protection to the media payloads by interleaving the payload stream to be protected with the additional redundancy information obtained using Reed-Solomon operations.
此处指定的FEC还为用户提供了不等的错误保护能力。一些其他算法也可以通过其他方式提供不平等的错误保护能力。例如，AVT工作组在“渐进式多媒体流的擦除弹性传输的RTP有效载荷格式”中提出了一种不平等擦除保护（UXP）方案。UXP方案通过将要保护的有效负载流与使用Reed-Solomon操作获得的附加冗余信息交织，对媒体有效负载应用不等错误保护。
By altering the structure of the protected media payload, the UXP scheme sacrifices the backward compatibility with terminals that do not support UXP. This makes it more difficult to apply UXP when backward compatibility is desired. In the case of ULP, however, the media payload remains unaltered and can always be used by the terminals. The extra protection can simply be ignored if the receiving terminals do not support ULP.
通过改变受保护媒体负载的结构，UXP方案牺牲了与不支持UXP的终端的向后兼容性。这使得在需要向后兼容性时应用UXP更加困难。然而，在ULP的情况下，媒体有效载荷保持不变，并且始终可以由终端使用。如果接收终端不支持ULP，则可以忽略额外的保护。
At the same time, also because the structure of the media payload is altered in UXP, UXP offers the unique ability to change packet size independent of the original media payload structure and protection applied, and is only subject to the protocol overhead constraint. This property is useful in scenarios when altering the packet size of the media at transport level is desired.
同时，也因为在UXP中改变了媒体有效载荷的结构，UXP提供了独立于原始媒体有效载荷结构和应用的保护而改变分组大小的独特能力，并且仅受协议开销约束。当需要在传输级别更改媒体的数据包大小时，此属性非常有用。
Because of the interleaving used in UXP, delays will be introduced at both the encoding and decoding sides. For UXP, all data within a transmission block need to arrive before encoding can begin, and a reasonable number of packets must be received before a transmission block can be decoded. The ULP scheme introduces little delay at the encoding side. On the decoding side, correctly received packets can be delivered immediately. Delay is only introduced in ULP when packet losses occur.
由于UXP中使用的交织，在编码和解码端都会引入延迟。对于UXP，传输块内的所有数据需要在编码开始之前到达，并且在传输块可以解码之前必须接收合理数量的数据包。ULP方案在编码端引入了很小的延迟。在解码端，可以立即发送正确接收的数据包。只有在发生数据包丢失时，才会在ULP中引入延迟。
Because UXP is an interleaved scheme, the unrecoverable errors occurring in data protected by UXP usually result in a number of corrupted holes in the payload stream. In ULP, on the other hand, the unrecoverable errors due to packet loss in the bitstream usually appear as contiguous missing pieces at the end of the packets. Depending on the encoding of the media payload stream, many applications may find it easier to parse and extract data from a
由于UXP是一种交织方案，UXP保护的数据中发生的不可恢复错误通常会导致有效负载流中出现大量损坏的漏洞。另一方面，在ULP中，由于位流中的数据包丢失而导致的不可恢复的错误通常在数据包的末尾显示为连续的缺失片段。根据媒体有效负载流的编码，许多应用程序可能会发现更容易从媒体中解析和提取数据
packet with only a contiguous piece missing at the end than a packet with multiple corrupted holes, especially when the holes are not coincident with the independently decodable fragment boundaries.
与具有多个损坏孔的数据包相比，在末尾仅缺少一个相邻片段的数据包，尤其是当这些孔与独立可解码的片段边界不一致时。
The exclusive-or (XOR) parity check operation used by ULP is simpler and faster than the more complex operations required by Reed-Solomon codes. This makes ULP more suitable for applications where computational cost is a constraint.
ULP使用的异或（XOR）奇偶校验操作比Reed-Solomon代码所需的更复杂的操作更简单、更快。这使得ULP更适合计算成本受限的应用。
As discussed above, both the ULP and the UXP schemes apply unequal error protection to the RTP media stream, but each uses a different technique. Both schemes have their own unique characteristics, and each can be applied to scenarios with different requirements.
如上所述，ULP和UXP方案都对RTP媒体流应用不同的错误保护，但各自使用不同的技术。这两种方案都有其独特的特点，每种方案都可以应用于具有不同需求的场景。
The following authors have made significant contributions to this document: Adam H. Li, Fang Liu, John D. Villasenor, Dong-Seek Park, Jeong-Hoon Park, Yung-Lyul Lee, Jonathan D. Rosenberg, and Henning Schulzrinne. The authors would also like to acknowledge the suggestions from many people, particularly Stephen Casner, Jay Fahlen, Cullen Jennings, Colin Perkins, Tao Tian, Matthieu Tisserand, Jeffery Tseng, Mark Watson, Stephen Wenger, and Magnus Westerlund.
以下作者对本文件做出了重要贡献：Adam H.Li、Fang Liu、John D.Villasenor、Dong Seek Park、Jeong Hoon Park、Yung Lyul Lee、Jonathan D.Rosenberg和Henning Schulzrinne。作者还想感谢许多人的建议，特别是斯蒂芬·卡斯纳、杰伊·法伦、卡伦·詹宁斯、科林·帕金斯、陶田、马蒂厄·蒂瑟兰、杰弗里·曾、马克·沃森、斯蒂芬·温格和马格纳斯·韦斯特隆德。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[3] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[4] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[4] Casner，S.，“RTP有效载荷格式的媒体类型注册”，RFC 4855，2007年2月。
[5] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[5] Camarillo，G.，Eriksson，G.，Holler，J.，和H.Schulzrinne，“会话描述协议（SDP）中媒体线路的分组”，RFC 3388，2002年12月。
[6] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006.
[6] 李安，“会话描述协议中的前向纠错分组语义”，RFC4756，2006年11月。
[7] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[7] 帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛特，J.，维加·加西亚，A.，和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[8] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[9] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[9] Rosenberg，J.和H.Schulzrinne，“通用前向纠错的RTP有效载荷格式”，RFC 2733，1999年12月。
[10] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[10] Perkins，C.和O.Hodson，“修复流媒体的选项”，RFC 2354，1998年6月。
[11] Rosenberg, J. and H. Schulzrinne, "Registration of parityfec MIME types", RFC 3009, November 2000.
[11] Rosenberg，J.和H.Schulzrinne，“parityfec MIME类型的注册”，RFC 3009，2000年11月。
[12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[12] 卢比，M.，维西萨诺，L.，杰梅尔，J.，里佐，L.，汉德利，M.，和J.克罗夫特，“前向纠错（FEC）构建块”，RFC 3452，2002年12月。
[13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[13] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[14] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[14] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[15] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[15] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
Editor's Address
编辑地址
Adam H. Li 10194 Wateridge Circle #152 San Diego, CA 92121 USA Phone: +1 858 622 9038 EMail: adamli@hyervision.com
Adam H.Li 10194 Wateridge Circle#152加利福尼亚州圣地亚哥92121美国电话：+1 858 622 9038电子邮件：adamli@hyervision.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.