Network Working Group J. Rosenberg
Request for Comments: 2733 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
December 1999
Network Working Group J. Rosenberg
Request for Comments: 2733 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
December 1999
An 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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the payload and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions.
本文档为RTP封装介质的通用前向纠错指定了有效负载格式。它专为基于异或（奇偶校验）运算的FEC算法而设计。有效负载格式允许终端系统使用任意块长度和奇偶校验方案进行传输。它还允许恢复有效负载和关键RTP报头字段。由于FEC作为一个单独的流发送，它与不支持FEC的主机向后兼容，因此不希望实现FEC的接收器可以忽略扩展。
Table of Contents
目录
1 Introduction ........................................... 2
2 Terminology ............................................ 2
3 Basic Operation ........................................ 3
4 Parity Codes ........................................... 5
5 RTP Media Packet Structure ............................. 6
6 FEC Packet Structure ................................... 7
6.1 RTP Header of FEC Packets .............................. 7
6.2 FEC Header ............................................. 7
7 Protection Operation ................................... 9
8 Recovery Procedures .................................... 10
8.1 Reconstruction ......................................... 10
8.2 Determination of When to Recover ....................... 12
1 Introduction ........................................... 2
2 Terminology ............................................ 2
3 Basic Operation ........................................ 3
4 Parity Codes ........................................... 5
5 RTP Media Packet Structure ............................. 6
6 FEC Packet Structure ................................... 7
6.1 RTP Header of FEC Packets .............................. 7
6.2 FEC Header ............................................. 7
7 Protection Operation ................................... 9
8 Recovery Procedures .................................... 10
8.1 Reconstruction ......................................... 10
8.2 Determination of When to Recover ....................... 12
9 Example ................................................ 16
10 Use with Redundant Encodings ........................... 17
11 Indicating FEC Usage in SDP ............................ 20
11.1 FEC as a Separate Stream ............................... 20
11.2 Use with Redundant Encodings ........................... 21
11.3 Usage with RTSP ........................................ 22
12 Security Considerations ................................ 23
13 Acknowledgments ........................................ 24
14 Authors' Addresses ..................................... 24
15 Bibliography ........................................... 25
16 Full Copyright Statement ............................... 26
9 Example ................................................ 16
10 Use with Redundant Encodings ........................... 17
11 Indicating FEC Usage in SDP ............................ 20
11.1 FEC as a Separate Stream ............................... 20
11.2 Use with Redundant Encodings ........................... 21
11.3 Usage with RTSP ........................................ 22
12 Security Considerations ................................ 23
13 Acknowledgments ........................................ 24
14 Authors' Addresses ..................................... 24
15 Bibliography ........................................... 25
16 Full Copyright Statement ............................... 26
1 Introduction
1导言
The quality of packet voice on the Internet has been mediocre due, in part, to high packet loss rates. This is especially true on wide-area connections. Unfortunately, the strict delay requirements of real-time multimedia usually eliminate the possibility of retransmissions.
互联网上的分组语音质量一般，部分原因是高分组丢失率。广域连接尤其如此。不幸的是，实时多媒体的严格延迟要求通常消除了重传的可能性。
It is for this reason that forward error correction (FEC) has been proposed to compensate for packet loss in the Internet [1] [2]. In particular, the use of traditional error correcting codes, such as parity, Reed-Solomon, and Hamming codes, has attracted attention. To support these mechanisms, protocol support is required.
正是出于这个原因，提出了前向纠错（FEC）来补偿互联网中的数据包丢失[1][2]。特别是，传统纠错码（如奇偶校验码、里德-所罗门码和汉明码）的使用引起了人们的注意。为了支持这些机制，需要协议支持。
This document defines a payload format for RTP [3] which 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 mechanisms, (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[3]的有效负载格式，该格式允许实时媒体的通用前向纠错。在这种情况下，通用意味着FEC协议（1）独立于被保护的媒体的性质，无论是音频、视频还是其他，（2）足够灵活以支持多种FEC机制，（3）为自适应而设计，以便可以在没有带外信令的情况下轻松修改FEC技术，以及（4）支持用于传输FEC分组的多种不同机制。
2 Terminology
2术语
The following terms are used throughout this document:
本文件中使用了以下术语：
Media Payload: is a piece of raw, un-protected user data which is to be transmitted from the sender. The media payload is placed inside of an RTP packet.
媒体有效载荷：是从发送方传输的未经保护的原始用户数据。媒体有效负载放置在RTP数据包内。
Media Header: is 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 forward error correction algorithms at the transmitter take the media packets as an input. They output both the media packets that they are passed, and new packets called FEC packets. The FEC packets are formatted according to the rules specified in this document.
FEC数据包：发射机的前向纠错算法将媒体数据包作为输入。它们输出所传递的媒体数据包和称为FEC数据包的新数据包。FEC数据包按照本文件规定的规则进行格式化。
FEC Header: The FEC header is the header information contained in an FEC packet.
FEC头：FEC头是FEC数据包中包含的头信息。
FEC Payload: The FEC payload is the payload in an FEC packet.
FEC有效载荷：FEC有效载荷是FEC数据包中的有效载荷。
Associated: An FEC packet is said to be "associated" with one or more media packets when those media packets are used to generate the FEC packet (by use of the exclusive or operation).
关联：当一个或多个媒体分组用于生成FEC分组时（通过使用异或操作），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 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中所述进行解释。
3 Basic Operation
3基本操作
The payload format described here is used whenever a participant in an RTP session would like to protect a media stream it is sending with forward error correction (FEC). The FEC supported by the format are those codes based on simple exclusive or (xor) parities. The sender takes some set of packets from the media stream, and applies an xor operation across the payloads. The sender also applies the xor operation over components of the RTP headers. Based on the procedures defined here, the result is an RTP packet containing FEC information. This packet can be used at the receiver to recover any one of the packets used to generate the FEC packet. This document does not mandate the particular set of media packets combined to generate an FEC packet (such a set [is] referred to as a code). Use of differing sets results in a tradeoff between overhead, delay, and recoverability. Section 4 outlines some possible combinations.
每当RTP会话中的参与者想要保护其发送的带有前向纠错（FEC）的媒体流时，就会使用这里描述的有效负载格式。该格式支持的FEC是那些基于简单异或（xor）平价的代码。发送方从媒体流中获取一些数据包集，并在有效负载上应用xor操作。发送方还对RTP头的组件应用xor操作。根据此处定义的过程，结果是包含FEC信息的RTP数据包。该分组可在接收器处用于恢复用于生成FEC分组的任何一个分组。本文档不强制要求组合的特定媒体分组集合生成FEC分组（这样的集合[被]称为代码）。使用不同的集合会导致开销、延迟和可恢复性之间的折衷。第4节概述了一些可能的组合。
The payload format contains information that allows the sender to tell the receiver exactly which media packets have been used to generate the FEC. Specifically, each FEC packet contains a bitmask, called the offset mask, containing 24 bits. If bit i in the mask is set to 1, the media packet with sequence number N + i was used to generate this FEC packet. N is called the sequence number base, and is sent in the FEC packet as well. The offset mask and payload type are sufficient to signal arbitrary parity based forward error correction schemes with little overhead.
有效载荷格式包含的信息允许发送方准确地告诉接收方哪些媒体包已用于生成FEC。具体地说，每个FEC分组包含一个位掩码，称为偏移掩码，包含24位。如果掩码中的位i设置为1，则序列号为N+i的媒体分组用于生成该FEC分组。N称为序列号基，也在FEC数据包中发送。偏移掩码和有效负载类型足以以较小的开销向基于任意奇偶校验的前向纠错方案发送信号。
This document also describes procedures that allow the receiver to make use of the FEC without having to know the details of specific codes. This allows the sender much flexibility; it can adapt the code in use based on network conditions, and be certain the receivers can still make use of the FEC for recovery.
本文件还描述了允许接收器使用FEC而无需知道特定代码细节的程序。这使得发送者有很大的灵活性；它可以根据网络条件调整正在使用的代码，并确保接收机仍然可以使用FEC进行恢复。
As the sender generates FEC packets, they are sent to the receivers. The sender still usually sends the original media stream, as if there were no FEC. This allows the media stream to still be used by receivers who are not FEC capable. However, some FEC codes do not require the original media to be sent; the FEC stream is sufficient for recovery. These codes have the drawback that all receivers must be FEC capable. However, they are supported by this format.
当发送方生成FEC数据包时，它们被发送到接收方。发送方通常仍然发送原始媒体流，就好像没有FEC一样。这允许不支持FEC的接收器仍使用媒体流。但是，某些FEC代码不要求发送原始媒体；FEC流足以进行恢复。这些代码的缺点是所有接收器都必须具有FEC能力。但是，此格式支持它们。
The FEC packets are not sent in the same RTP stream as the media packets. They can be sent as a separate stream, or as a secondary codec in the redundant codec payload format [5]. When sent as a separate stream, the FEC packets have their own sequence number space. Although the timestamps for the FEC packets are derived from the media packets, they increment monotonically. FEC packet streams thus work well with any header compression mechanism which requires fixed deltas between fields in the packet header.
FEC数据包与媒体数据包不在同一RTP流中发送。它们可以作为单独的流发送，也可以作为冗余编解码器负载格式的辅助编解码器发送[5]。当作为单独的流发送时，FEC数据包具有自己的序列号空间。尽管FEC分组的时间戳是从媒体分组导出的，但是它们是单调递增的。因此，FEC分组流与任何需要分组报头中字段之间的固定增量的报头压缩机制都能很好地工作。
This document does not prescribe the definition of "separate streams", but leaves this to applications and higher level protocols to define. For multicast, the separate stream may be implemented by separate multicast groups, different ports in the same group, or by a different SSRC within the same group/port. For unicast, different ports or different SSRC may be used. Each of these approaches has drawbacks and benefits which depend on the application.
本文件未规定“独立流”的定义，但将其留给应用程序和更高级别的协议来定义。对于多播，可以通过单独的多播组、同一组中的不同端口或同一组/端口中的不同SSRC来实现单独的流。对于单播，可以使用不同的端口或不同的SSRC。这些方法中的每一种都有缺点和优点，这取决于应用程序。
At the receiver, the FEC and original media are received. If no media packets are lost, the FEC can be ignored. In the event of loss, the FEC packets can be combined with other media and FEC packets that have been received, resulting in recovery of missing media packets. The recovery is exact; the payload is perfectly reconstructed, along with most components of the header.
在接收器处，接收FEC和原始媒体。如果没有媒体数据包丢失，则可以忽略FEC。在丢失的情况下，FEC分组可以与已接收的其他媒体和FEC分组组合，从而恢复丢失的媒体分组。恢复是准确的；有效负载与报头的大多数组件一起被完美地重构。
RTP packets which contain data formatted according to this specification (i.e., FEC packets) are signaled using dynamic RTP payload types.
包含根据本规范格式化的数据的RTP数据包（即FEC数据包）使用动态RTP有效负载类型发送信号。
4 Parity Codes
4奇偶校验码
For brevity, we define the function f(x,y,..) to be the XOR (parity) operator applied to the packets x,y,... The output of this function is another packet, called the parity packet. For simplicity, we assume here that the parity packet is computed as the bitwise XOR of the input packets. The exact procedure is specified in section 6.
为简洁起见，我们将函数f（x，y，…）定义为应用于数据包x，y，。。。此函数的输出是另一个数据包，称为奇偶校验数据包。为简单起见，我们在此假设奇偶校验数据包被计算为输入数据包的按位异或。具体程序见第6节。
Recovery of data packets using parity codes is accomplished by generating one or more parity packets over a group of data packets. To be effective, the parity packets must be generated by linearly independent combinations of data packets. The particular combination is called a parity code. One class of codes takes a group of k data packets, and generates n-k parity packets. There are a large number of possible parity codes for a given n,k. The payload format does not mandate a particular code.
使用奇偶校验码恢复数据包是通过在一组数据包上生成一个或多个奇偶校验包来实现的。为了有效，奇偶校验包必须由数据包的线性独立组合生成。这种特殊的组合称为奇偶校验码。一类代码接受一组k个数据包，并生成n-k个奇偶校验包。对于给定的n，k，存在大量可能的奇偶校验码。有效负载格式不要求特定代码。
For example, consider a parity code which generates a single parity packet over two data packets. 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。
Some additional codes are listed below. In each, the original media stream consists of packets a,b,c,d and so on.
下面列出了一些附加代码。在每一个中，原始媒体流由分组a、b、c、d等组成。
Scheme 1
--------
Scheme 1
--------
This scheme is the similar to the one in the example above. However, instead of sending b, followed by f(a,b), f(a,b) is sent before b. Doing this clearly requires additional delay at the sender. However, if allows some bursts of two consecutive packet losses to be recovered. The packets generated by the sender look like:
此方案与上面示例中的方案类似。但是，f（a，b）不是先发送b，然后发送f（a，b），而是先发送f（a，b）。这样做显然需要发送方额外的延迟。但是，if允许恢复两个连续数据包丢失的一些突发。发送方生成的数据包如下所示：
a b c d e <-- media stream
f(a,b) f(b,c) f(c,d) f(d,e) <-- FEC stream
a b c d e <-- media stream
f(a,b) f(b,c) f(c,d) f(d,e) <-- FEC stream
Scheme 2
--------
Scheme 2
--------
It is not strictly necessary for the original media stream to be transmitted. In this scheme, only FEC packets are transmitted. This scheme allows for recovery of all single packet losses and some consecutive packet losses, but with slightly less overhead than scheme 1. The packets generated by the sender look like:
严格来说，传输原始媒体流不是必需的。在该方案中，仅发送FEC分组。该方案允许恢复所有单个数据包丢失和一些连续数据包丢失，但开销略低于方案1。发送方生成的数据包如下所示：
f(a,b) f(a,c) f(a,b,c) f(c,d) f(c,e) f(c,d,e) <-- FEC stream
f(a,b) f(a,c) f(a,b,c) f(c,d) f(c,e) f(c,d,e) <-- FEC stream
Scheme 3
--------
Scheme 3
--------
This scheme requires the receiver to wait an additional four packet intervals to recover the original media packets. However, it can recover from one, two or three consecutive packet losses. The packets generated by the sender look like:
此方案要求接收器等待额外的四个数据包间隔来恢复原始媒体数据包。但是，它可以从一个、两个或三个连续的数据包丢失中恢复。发送方生成的数据包如下所示：
a b c d <-- media stream
f(a,b,c) f(a,c,d) f(a,b,d) <-- FEC stream
a b c d <-- media stream
f(a,b,c) f(a,c,d) f(a,b,d) <-- FEC stream
5 RTP Media Packet Structure
5 RTP媒体分组结构
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. If the FEC is being sent as a redundant codec, the media packets are sent as the main codec as defined in RFC 2198 [5].
媒体数据包的格式不受FEC的影响。如果FEC作为单独的流发送，则媒体分组被发送，如同没有FEC一样。如果FEC作为冗余编解码器发送，则媒体分组作为RFC 2198[5]中定义的主编解码器发送。
This lends to a very efficient encoding. When little (or no) FEC is used, there are mostly media packets being sent. This means that the overhead (present in FEC packets only) tracks the amount of FEC in use.
这有助于实现非常高效的编码。当使用很少（或没有）FEC时，主要是发送媒体数据包。这意味着开销（仅存在于FEC数据包中）跟踪FEC的使用量。
6 FEC Packet Structure
6 FEC分组结构
An FEC packet is constructed by placing an FEC header and FEC payload in the RTP payload, as shown in Figure 1:
通过在RTP有效载荷中放置FEC报头和FEC有效载荷来构造FEC分组，如图1所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: FEC Packet Structure
图1:FEC数据包结构
The version field is set to 2. The padding bit is computed via the protection operation, defined below. The extension bit is also computed via the protection operation. The SSRC value will generally be the same as the SSRC value of the media stream it protects. It MAY be different if the FEC stream is being demultiplexed via the SSRC value. The CC value is computed via the protection operation. The CSRC list is never present, independent of the value of the CC field. The extension is never present, independent of the value of the X bit. The marker bit is computed via the protection operation.
版本字段设置为2。填充位通过下面定义的保护操作计算。扩展位也通过保护操作计算。SSRC值通常与它保护的媒体流的SSRC值相同。如果FEC流通过SSRC值被解复用，则可能不同。通过保护操作计算CC值。CSC列表永远不存在，与CC字段的值无关。扩展永远不存在，与X位的值无关。通过保护操作计算标记位。
The sequence number has the standard definition: it MUST be one higher than the sequence number in the previously transmitted FEC packet. The timestamp MUST be set to the value of the media RTP clock at the instant the FEC packet is transmitted. This results in the TS value in FEC packets to be monotonically increasing, independent of the FEC scheme.
序列号具有标准定义：它必须比先前传输的FEC数据包中的序列号高一个。时间戳必须设置为FEC数据包传输时媒体RTP时钟的值。这导致FEC分组中的TS值单调增加，与FEC方案无关。
The payload type for the FEC packet is determined through dynamic, out of band means. According to RFC 1889 [3], RTP participants which cannot recognize a payload type must discard it. This provides backwards compatibility. The FEC mechanisms can then be used in a multicast group with mixed FEC-capable and FEC-incapable receivers.
FEC分组的有效载荷类型通过动态带外方式确定。根据RFC1889[3]，无法识别有效负载类型的RTP参与者必须放弃它。这提供了向后兼容性。然后，可以在具有混合FEC能力和FEC不能力接收器的多播组中使用FEC机制。
This header is 12 bytes. The format of the header is shown in Figure 2, and consists of an SN base field, length recovery field, E field, PT recovery field, mask field and TS recovery field.
这个头是12个字节。标头的格式如图2所示，由SN基本字段、长度恢复字段、E字段、PT恢复字段、掩码字段和TS恢复字段组成。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SN base | length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| PT recovery | mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SN base | length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| PT recovery | mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Parity Header Format
图2：奇偶校验头格式
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 media packets associated with this FEC packet (in other words, the CSRC list, extension, and padding, if present, are "counted" as part of the payload). This allows the FEC procedure to be applied even when the lengths of the media packets are not identical. For example, assume an FEC packet is being generated by xor'ing two media packets together. The length of the two media packets are 3 (0b011) and 5 (0b101) bytes, respectively. The length recovery field is then encoded as 0b011 xor 0b101 = 0b110.
长度恢复字段用于确定任何已恢复数据包的长度。它是通过应用于无符号网络的保护操作计算的，顺序为16位，表示与该FEC分组相关联的媒体有效载荷、CSC列表、媒体分组的扩展和填充的长度（以字节为单位）之和（换句话说，CSC列表、扩展和填充，如果存在，则被“计数”作为有效载荷的一部分）。这允许即使在媒体分组的长度不相同时也应用FEC过程。例如，假设一个FEC包是通过将两个媒体包异或在一起生成的。两个媒体数据包的长度分别为3（0b011）和5（0b101）字节。然后将长度恢复字段编码为0b011 xor 0b101=0b110。
The E bit indicates a header extension. Implementations conforming to this version of the specification MUST set this bit to zero.
E位表示标头扩展。符合本规范版本的实现必须将该位设置为零。
The PT recovery field is obtained via the protection operation applied to the payload type values of the media packets associated with the FEC packet.
PT恢复字段通过应用于与FEC分组相关联的媒体分组的有效载荷类型值的保护操作获得。
The mask field is 24 bits. 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 least significant bit corresponds to i=0, and the most significant to i=23.
掩码字段为24位。如果掩码中的比特i设置为1，则序列号为N+i的媒体分组与该FEC分组相关联，其中N是FEC分组报头中的SN基本字段。最低有效位对应于i=0，最高有效位对应于i=23。
The SN base field MUST be set to the minimum sequence number of those media packets protected by FEC. This allows for the FEC operation to extend over any string of at most 24 packets.
SN基本字段必须设置为受FEC保护的媒体数据包的最小序列号。这允许FEC操作扩展到最多24个数据包的任何字符串上。
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 payload of the FEC packet is the protection operation applied to the concatenation of the CSRC list, RTP extension, media payload, and padding of the media packets associated with the FEC packet.
FEC分组的有效载荷是应用于与FEC分组相关联的媒体分组的csc列表、RTP扩展、媒体有效载荷和填充的级联的保护操作。
Note that it's possible for the FEC packet to be slightly larger than the media packets it protects (due to the presence of the FEC header). 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.
请注意，FEC数据包可能略大于其保护的媒体数据包（由于FEC报头的存在）。如果这导致FEC分组超过其发送路径的最大传输单元大小，则这可能导致困难。
7 Protection Operation
7保护操作
The protection operation involves concatenating specific fields from the RTP header of the media packet, appending the payload, padding with zeroes, and then computing the xor across the resulting bit strings. The resulting bit string is used to generate the FEC packet.
保护操作涉及从媒体分组的RTP报头连接特定字段，附加有效负载，填充零，然后计算结果位字符串的异或。产生的比特串用于生成FEC分组。
The following procedure MAY be followed for the protection operation. Other procedures MAY be followed, but the end result MUST be identical to the one described here. For each media packet to be protected, a bit string is generated by concatenating the following fields together in the order specifed:
保护操作可遵循以下程序。可以遵循其他程序，但最终结果必须与此处描述的相同。对于要保护的每个媒体数据包，通过按指定顺序将以下字段连接在一起生成位字符串：
o Padding Bit (1 bit)
o 填充位（1位）
o Extension Bit (1 bit)
o 扩展位（1位）
o CC bits (4 bits)
o CC位（4位）
o Marker bit (1 bit)
o 标记位（1位）
o Payload Type (7 bits)
o 有效负载类型（7位）
o Timestamp (32 bits)
o 时间戳（32位）
o Unsigned network-ordered 16 bit representation of the sum of the lengths (in bytes) of the CSRC List, length of the padding, length of the extension, and length of the media payload (16 bits)
o CSC列表长度（以字节为单位）、填充长度、扩展长度和媒体有效负载长度（16位）之和的无符号网络顺序16位表示
o if CC is nonzero, the CSRC List (variable length)
o 如果CC为非零，则为CSC列表（可变长度）
o if X is 1, the Header Extension (variable length)
o 如果X为1，则标头扩展名（可变长度）
o the payload (variable length)
o 有效载荷（可变长度）
o Padding, if present (variable length)
o 填充，如果存在（可变长度）
Note that the Padding Bit (first entry above) forms the most significant bit of the bit string.
请注意，填充位（上面的第一个条目）构成位字符串的最高有效位。
If the lengths of the bit strings are not equal, each bit string that is shorter than the length of the longest, MUST be padded to the length of the longest. Any value for the pad may be used. The pad MUST be added at the end of the bit string.
如果位字符串的长度不相等，则每个比最长的长度短的位字符串必须填充到最长的长度。可以使用pad的任何值。必须在位字符串的末尾添加焊盘。
The parity operation is then applied across the bit strings. The result is the bit string used to build the FEC packet. Call this the FEC bit string.
然后，奇偶校验操作应用于位字符串。结果是用于构建FEC数据包的位字符串。将其称为FEC位字符串。
The first (most significant) bit in the FEC bit string is written into the Padding Bit of the FEC packet. The second bit in the FEC bit string is written into the Extension bit of the FEC packet. The next four bits of the FEC bit string are written into the CC field of the FEC packet. The next bit of the FEC bit string is written into the marker bit of the FEC packet. The next 7 bits of the FEC bit string are written into the PT recovery field in the FEC packet header. The next 32 bits of the FEC bit string are written into the TS recovery field in the packet header. The next 16 bits are written into the length recovery field in the FEC packet header. The remaining bits are set to be the payload of the FEC packet.
FEC位字符串中的第一个（最高有效）位写入FEC数据包的填充位。FEC位字符串中的第二位写入FEC数据包的扩展位。FEC比特串的下四个比特被写入FEC分组的CC字段。FEC位字符串的下一位写入FEC数据包的标记位。FEC比特串的下7个比特被写入FEC分组报头中的PT恢复字段。FEC位字符串的下32位写入数据包报头中的TS恢复字段。接下来的16位被写入FEC分组报头中的长度恢复字段。剩余比特被设置为FEC分组的有效载荷。
8 Recovery Procedures
8恢复程序
The FEC packets allow end systems to recover from the loss of media packets. All of the header fields of the missing packets, including CSRC lists, extensions, padding bits, marker and payload type, are recoverable. This section describes the procedure for performing this recovery.
FEC数据包允许终端系统从媒体数据包的丢失中恢复。丢失数据包的所有头字段，包括CSC列表、扩展名、填充位、标记和有效负载类型，都是可恢复的。本节介绍执行此恢复的过程。
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 tradeoff between complexity and the ability to recover missing packets if at all possible.
恢复需要两个不同的操作。第一种方法确定为了恢复丢失的数据包，必须组合哪些数据包（媒体和FEC）。完成后，第二步是实际重建数据。第二步必须按如下所述执行。第一步可以基于实现者选择的任何算法。不同的算法会在复杂度和尽可能恢复丢失数据包的能力之间进行权衡。
Let T be the list of packets (FEC and media) which can be combined to recover some media packet xi. The procedure is as follows:
让T是包的列表（FEC和媒体），可以组合起来恢复一些媒体包席。程序如下：
1. For the media packets in T, compute the bit string as described in the protection operation of the previous section.
1. 对于T中的媒体分组，按照上一节的保护操作中所述计算位字符串。
2. For the FEC packet in T, compute the bit string in the same fashion, except use the PT Recovery instead of Payload Type, TS Recovery instead of Timestamp, and always set the CSRC list, extension, and padding to null.
2. 对于T中的FEC数据包，以相同的方式计算位字符串，除了使用PT Recovery代替有效负载类型，使用TS Recovery代替时间戳，并且始终将CSC列表、扩展名和填充设置为null。
3. If any of the bit strings generated from the media packets are shorter than the bit string generated from the FEC packet, pad them to be the same length as the bit string generated from the FEC. The padding MUST be added at the end of the bit string, and MAY be of any value.
3. 如果从媒体分组生成的任何比特串短于从FEC分组生成的比特串，则将它们填充为与从FEC分组生成的比特串相同的长度。填充必须添加在位字符串的末尾，并且可以是任何值。
4. Perform the exclusive or (parity) operation across the bit strings, resulting in a recovery bit string.
4. 对位字符串执行异或（奇偶校验）操作，生成恢复位字符串。
5. Create a new packet with the standard 12 byte RTP header and no payload.
5. 创建一个具有标准12字节RTP报头且无有效负载的新数据包。
6. Set the version of the new packet to 2.
6. 将新数据包的版本设置为2。
7. Set the Padding bit in the new packet to the first bit in the recovery bit string.
7. 将新数据包中的填充位设置为恢复位字符串中的第一位。
8. Set the Extension bit in the new packet to the second bit in the recovery bit string.
8. 将新数据包中的扩展位设置为恢复位字符串中的第二位。
9. Set the CC field to the next four bits in the recovery bit string.
9. 将CC字段设置为恢复位字符串中的下四位。
10. Set the marker bit in the new packet to the next bit in the recovery bit string.
10. 将新数据包中的标记位设置为恢复位字符串中的下一位。
11. Set the payload type in the new packet to the next 7 bits in the recovery bit string.
11. 将新数据包中的有效负载类型设置为恢复位字符串中的下7位。
12. Set the SN field in the new packet to xi.
12. 将新数据包中的SN字段设置为席。
13. Set the TS field in the new packet to the next 32 bits in the recovery bit string.
13. 将新数据包中的TS字段设置为恢复位字符串中的下一个32位。
14. 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 padding.
14. 取恢复位串的下16位。无论这代表什么无符号整数（假设网络顺序），从恢复位字符串中提取这么多字节，并将它们附加到新数据包中。这表示CSC列表、扩展、有效负载和填充。
15. Set the SSRC of the new packet to the SSRC of the media stream it's protecting.
15. 将新数据包的SSRC设置为其保护的媒体流的SSRC。
This procedure will completely recover both the header and payload of an RTP packet.
此过程将完全恢复RTP数据包的报头和有效负载。
The previous section discussed how to recover a media packet with sequence number xi when all of the packets needed to recover it were available. The decision about whether to attempt recovery of some media packet xi, and how to determine if sufficient data is available to recover it, is left to the implementer. However, this section provides a simple algorithm which MAY be used for this purpose.
前一节讨论了如何在恢复所有需要恢复的包时恢复序列号席的媒体包。关于是否尝试恢复某些媒体分组席的决定以及如何确定是否有足够的数据可恢复它的决定留给了实现者。然而，本节提供了一个可用于此目的的简单算法。
The algorithm is described below in C code. The code assumes that several functions exist. recover_packet() takes the sequence number of a packet, and an FEC packet. Using the FEC packet and data packets received previously, the data packet with the given sequence number is recovered. add_fec_to_pending_list() adds the given FEC packet to a linked list of FEC packets which have not yet been used for recovery. wait_for_packet() waits for a packet, FEC or data, from the network. remove_from_pending_list() removes the FEC packet from the pending list. The structure packet contains a boolean variable fec which is true when the packet is FEC, false if it's media. When its an FEC packet, the mask and snbase field contain those values from the FEC packet header. When it's a media packet, the sn variable contains the sequence number of the packet. The global array A indicates which media packets have been received, and which have not. It is indexed by the sequence number of the packet.
下面用C代码描述该算法。代码假定存在多个函数。recover_packet（）获取数据包和FEC数据包的序列号。使用先前接收到的FEC分组和数据分组，恢复具有给定序列号的数据分组。add_fec_to_pending_list（）将给定的fec数据包添加到尚未用于恢复的fec数据包的链接列表中。wait_for_packet（）等待来自网络的数据包、FEC或数据。remove_from_pending_list（）从挂起列表中删除FEC数据包。结构数据包包含一个布尔变量fec，当数据包是fec时为真，如果是媒体则为假。当它是FEC数据包时，掩码和snbase字段包含来自FEC数据包头的那些值。当它是媒体分组时，sn变量包含分组的序列号。全局阵列A指示哪些媒体分组已被接收，哪些未被接收。它由数据包的序列号索引。
The function fec_recovery implements the algorithm. It waits for packets, and when it receives an FEC packet, calls recover_with_fec() to attempt to use it to recover. If no recovery is possible, the FEC packet is stored for later attempts. If the received packet was a media packet, its presence is noted, and any old FEC packets are checked to see if recovery is now possible. Recovered packets are treated as if they were received, triggering further attempts at recovery.
函数fec_recovery实现了该算法。它等待数据包，当接收到FEC数据包时，使用_FEC（）调用recover_，尝试使用它进行恢复。如果无法恢复，则存储FEC数据包以供以后尝试。如果接收到的数据包是媒体数据包，则记录其存在，并检查任何旧的FEC数据包，以查看现在是否可以恢复。恢复的数据包被视为已接收，从而触发进一步的恢复尝试。
A real implementation will need to use a circular buffer instead of the simple array (A in the code) in order to avoid running off the end of the buffer. In addition, the code below does not attempt to free up FEC packets that are old and were never used. Normally, such discarding is done based on time constraints introduced by the playout buffer. If an FEC data protects packets whose play time has elapsed, the FEC is no longer needed.
真正的实现将需要使用循环缓冲区而不是简单数组（代码中的A），以避免从缓冲区的末尾运行。此外，下面的代码不会尝试释放旧的、从未使用过的FEC数据包。通常，这种丢弃是基于播放缓冲区引入的时间约束来完成的。如果FEC数据保护播放时间已过的数据包，则不再需要FEC。
typedef struct packet_s {
类型定义结构数据包{
BOOLEAN fec; /* FEC or media */
BOOLEAN fec; /* FEC or media */
int sn; /* SN of the packet, for media only */
int sn; /* SN of the packet, for media only */
BOOLEAN mask[24]; /* Mask, FEC only */
int snbase; /* SN Base, FEC only */
BOOLEAN mask[24]; /* Mask, FEC only */
int snbase; /* SN Base, FEC only */
struct packet_s *next;
结构数据包\u s*下一步；
} packet;
}包；
BOOLEAN A[65535];
packet *pending_list;
BOOLEAN A[65535];
packet *pending_list;
packet *recover_with_fec(packet *fec_pkt) {
packet *recover_with_fec(packet *fec_pkt) {
packet *data_pkt;
int pkts_present, /* number of packets from the mask that are
present */
pkts_needed, /* number of packets needed is the number of ones
in the mask minus 1 */
pkt_to_recover, /* sn of the packet we are recovering */
i;
packet *data_pkt;
int pkts_present, /* number of packets from the mask that are
present */
pkts_needed, /* number of packets needed is the number of ones
in the mask minus 1 */
pkt_to_recover, /* sn of the packet we are recovering */
i;
pkts_present = 0;
pkts_当前=0；
/* The number of packets needed is the number of ones in the mask
minus 1. The code below increments pkts_needed by the number
of ones in the mask, so we initialize this to -1 so that the
final count is correct */
/* The number of packets needed is the number of ones in the mask
minus 1. The code below increments pkts_needed by the number
of ones in the mask, so we initialize this to -1 so that the
final count is correct */
pkts_needed = -1;
pkts_needed = -1;
/* Go through all 24 bits in the mask, and check if we have
all but one of the media packets */
/* Go through all 24 bits in the mask, and check if we have
all but one of the media packets */
for(i = 0; i < 24; i++) {
for(i = 0; i < 24; i++) {
/* If the packet is here and in the mask, increment counter */
/* If the packet is here and in the mask, increment counter */
if(A[i+fec_pkt->snbase] && fec_pkt->mask[i]) pkts_present++;
if(A[i+fec_pkt->snbase] && fec_pkt->mask[i]) pkts_present++;
/* Count the number of packets needed as well */
if(fec_pkt->mask[i]) pkts_needed++;
/* Count the number of packets needed as well */
if(fec_pkt->mask[i]) pkts_needed++;
/* The packet to recover is the one with a bit in the
mask that's not here yet */
if(!A[i+fec_pkt->snbase] && fec_pkt->mask[i])
pkt_to_recover = i+fec_pkt->snbase;
}
/* The packet to recover is the one with a bit in the
mask that's not here yet */
if(!A[i+fec_pkt->snbase] && fec_pkt->mask[i])
pkt_to_recover = i+fec_pkt->snbase;
}
/* If we can recover, do so. Otherwise, return NULL */
/* If we can recover, do so. Otherwise, return NULL */
if(pkts_present == pkts_needed) {
data_pkt = recover_packet(pkt_to_recover, fec_pkt);
} else {
data_pkt = NULL;
}
if(pkts_present == pkts_needed) {
data_pkt = recover_packet(pkt_to_recover, fec_pkt);
} else {
data_pkt = NULL;
}
return(data_pkt);
}
return(data_pkt);
}
void fec_recovery() {
无效fec_回收（）{
packet *p, /* packet received or regenerated */
*fecp, /* fec packet from pending list */
*pnew; /* new packets recovered */
packet *p, /* packet received or regenerated */
*fecp, /* fec packet from pending list */
*pnew; /* new packets recovered */
while(1) {
而(1){
p = wait_for_packet(); /* get packet from network */
p = wait_for_packet(); /* get packet from network */
while(p) {
while（p）{
/* if it's an FEC packet, try to recover with it. If we can't,
store it for later potential use. If we can recover, act as
if the recovered packet is received and try to recover some
more. Otherwise, if it's a data packet, mark it as received,
and check if we can now recover a data packet with the list
of pending FEC packets */
/* if it's an FEC packet, try to recover with it. If we can't,
store it for later potential use. If we can recover, act as
if the recovered packet is received and try to recover some
more. Otherwise, if it's a data packet, mark it as received,
and check if we can now recover a data packet with the list
of pending FEC packets */
if(p->fec == TRUE) {
pnew = recover_with_fec(p);
if(p->fec == TRUE) {
pnew = recover_with_fec(p);
if(pnew)
如果（pnew）
A[pnew->sn] = TRUE;
else
add_fec_to_pending_list(p);
A[pnew->sn] = TRUE;
else
add_fec_to_pending_list(p);
/* We assign pnew to p since the while loop will continue
to recover based on p not being NULL */
/* We assign pnew to p since the while loop will continue
to recover based on p not being NULL */
p = pnew;
p=pnew；
} else {
}否则{
/* Mark this data packet as here */
A[p->sn] = TRUE;
/* Mark this data packet as here */
A[p->sn] = TRUE;
free(p);
p = NULL;
free(p);
p = NULL;
/* Go through pending list. Try and recover a packet using
each FEC. If we are successful, add the data packet to
the list of received packets, remove the FEC packet from
the pending list, since we've used it, and then try to
recover some more */
/* Go through pending list. Try and recover a packet using
each FEC. If we are successful, add the data packet to
the list of received packets, remove the FEC packet from
the pending list, since we've used it, and then try to
recover some more */
for(fecp = pending_list; fecp != NULL; fecp = fecp->next) {
pnew = recover_with_fec(fecp);
if(pnew) {
for(fecp = pending_list; fecp != NULL; fecp = fecp->next) {
pnew = recover_with_fec(fecp);
if(pnew) {
/* The packet is now here, as we've recovered it */
A[pnew->sn] = TRUE;
/* The packet is now here, as we've recovered it */
A[pnew->sn] = TRUE;
/* One FEC packet can only be used once to recover,
so remove it from the pending list */
/* One FEC packet can only be used once to recover,
so remove it from the pending list */
remove_fec_from_pending_list(fecp);
从待处理列表（fecp）中删除fec；
p = pnew;
p=pnew；
break;
}
break;
}
} /*for*/
} /*for*/
} /*p->fec was false */
} /*p->fec was false */
} /* while p*/
} /* while p*/
} /* while 1 */
} /* while 1 */
}
}
9 Example
9例
Consider 2 media packets to be sent, x and y, from SSRC 2. Their sequence numbers are 8 and 9, respectively, with timestamps of 3 and 5, respectively. Packet x uses payload type 11, and packet y uses payload type 18. Packet x is has 10 bytes of payload, and packet y 11. Packet y has its marker bit set. The RTP headers for packets x and y are shown in Figures 3 and 4 respectively.
考虑从SSRC 2发送的2个媒体分组X和Y。它们的序列号分别为8和9，时间戳分别为3和5。数据包x使用有效负载类型11，数据包y使用有效负载类型18。数据包x有10个字节的有效负载，数据包y有11个字节。数据包y已设置其标记位。图3和图4分别显示了数据包x和y的RTP报头。
Media Packet x
媒体包x
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|0 0 0 1 0 1 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 0 1 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|0 0 0 1 0 1 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 0 1 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 PTI: 11 SN: 8 TS: 3 SSRC: 2
版本：2填充：0扩展：0标记：0 PTI:11序列号：8 TS:3 SSRC:2
Figure 3: RTP Header for Media Packet X
图3:X媒体包的RTP报头
An FEC packet is generated from these two. We assume that payload type 127 is used to indicate an FEC packet. The resulting RTP header is shown in Figure 5.
FEC数据包由这两个数据包生成。我们假设有效负载类型127用于指示FEC分组。生成的RTP头如图5所示。
The FEC header in the FEC packet is shown in Figure 6.
FEC包中的FEC头如图6所示。
11 Use with Redundant Encodings
11与冗余编码一起使用
One can consider an FEC packet as a "redundant coding" of the media.
人们可以考虑FEC包作为媒体的“冗余编码”。
Media Packet y
媒体包y
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|0 0 1 0 0 1 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 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|0 0 1 0 0 1 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 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 PTI: 18 SN: 9 TS: 5 SSRC: 2
版本：2填充：0扩展：0标记：1 PTI:18序列号：9 TS:5 SSRC:2
Figure 4: RTP Header for Media Packet Y
图4：媒体包Y的RTP报头
Because of this, the payload format for encoding of redundant audio data [5] can be used to carry the FEC data along with the media. The procedure for this is as follows.
因此，用于编码冗余音频数据[5]的有效载荷格式可用于携带FEC数据以及媒体。这方面的程序如下。
The FEC operation defined above acts on a stream of RTP media packets. The stream which is operated on is the stream before the encapsulation defined in RFC 2198 [5]. In other words, the media stream to be protected is encapsulated in standard RTP media packets. The FEC operation above is performed (with one minor change), generating a stream of FEC packets. The change to the procedure above is that if the RTP packets being protected contain an RTP extension, padding, or a CSRC list, these MUST be removed from the packets, and the CC field, Padding Bit, and Extension but MUST be set to zero, before the FEC operation is applied. These modified packets are used in the procedure above. Note that the sender MUST still send the original packets (with the CSRC list, padding, and extension in tact) as the primary encoding in RFC 2198. The removal of these fields only applies to the protection operation.
上面定义的FEC操作作用于RTP媒体分组流。操作的流是RFC 2198[5]中定义的封装之前的流。换句话说，要保护的媒体流被封装在标准RTP媒体分组中。执行上面的FEC操作（有一个小改变），生成FEC分组流。对上述过程的更改是，如果受保护的RTP数据包包含RTP扩展、填充或CSC列表，则在应用FEC操作之前，必须从数据包中删除这些内容，并且CC字段、填充位和扩展必须设置为零。在上述过程中使用这些修改后的数据包。请注意，发送方仍必须发送原始数据包（使用tact中的CSC列表、填充和扩展名）作为RFC 2198中的主要编码。删除这些字段仅适用于保护操作。
Once the FEC packets have been generated, the media payload is extracted from the media packets. This payload is used as the primary encoding as defined in RFC 2198. Then, the FEC header and payload of the FEC packets is extracted, and treated as a redundant encoding. Additional redundant encodings, besides FEC, MAY be added to the packet as well. These encodings will not be protected by FEC, however.
一旦FEC分组已经生成，就从媒体分组中提取媒体有效载荷。该有效载荷用作RFC 2198中定义的主要编码。然后，提取FEC分组的FEC报头和有效载荷，并将其视为冗余编码。除了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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 PTI: 127 SN: 1 TS: 5 SSRC: 2
版本：2填充：0扩展：0标记：1 PTI:127序列号：1 TS:5 SSRC:2
Figure 5: RTP Header of FEC for Packets X and Y
图5：数据包X和Y的FEC的RTP报头
The redundant encodings header for the primary codec is set as defined in RFC 2198. The redundant encodings header for the FEC data is set as follows. The block PT is set to the dynamic PT associated with the FEC format. The block length is set to the sum of the lengths of the FEC header and payload. The timestamp offset SHOULD be set to zero. The secondary coder payload includes the FEC header and FEC payload.
主编解码器的冗余编码头按照RFC 2198中的定义进行设置。FEC数据的冗余编码报头设置如下。块PT被设置为与FEC格式相关联的动态PT。块长度设置为FEC报头和有效负载的长度之和。时间戳偏移量应设置为零。辅助编码器有效载荷包括FEC报头和FEC有效载荷。
At the receiver, the primary codec and all secondary codecs are extracted as separate RTP packets. This is done by copying the sequence number, SSRC, marker bit, CC field, RTP version, and extension bit from the RTP header of the redundant encodings packet to the RTP header of each extracted packet. If the secondary codec contains FEC, the CC field, Extension Bit, and Padding Bit in the RTP header of the FEC packet MUST be set to zero instead. The payload type identifier in the extracted packet is copied from the block PT of the redundant encodings header. The timestamp of the extracted packet is the difference between the timestamp in the RTP header and
在接收器处，主编解码器和所有辅助编解码器被提取为单独的RTP数据包。这是通过将序列号、SSRC、标记位、CC字段、RTP版本和扩展位从冗余编码数据包的RTP报头复制到每个提取数据包的RTP报头来完成的。如果辅助编解码器包含FEC，则FEC数据包的RTP报头中的CC字段、扩展位和填充位必须改为零。从冗余编码报头的块PT复制提取的分组中的有效负载类型标识符。提取的数据包的时间戳是RTP报头中的时间戳和
the offset in the block header. The payload of the extracted packet is the data block. This will result in the FEC stream and media stream being extracted.
块标题中的偏移量。提取的分组的有效载荷是数据块。这将导致FEC流和媒体流被提取。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 0 0 0 0 0 1 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 1 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 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 0 0 0 0 0 1 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 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SN base: 8 [min(8,9)]
len. rec.: 1 [8 xor 9]
E: 0
PTI rec.: 25 [11 xor 18]
mask: 3
TS rec.: 6 [3 xor 5]
SN base: 8 [min(8,9)]
len. rec.: 1 [8 xor 9]
E: 0
PTI rec.: 25 [11 xor 18]
mask: 3
TS rec.: 6 [3 xor 5]
The payload length is 11 bytes.
有效负载长度为11字节。
Figure 6: FEC Header of Result
图6：结果的FEC头
To use the FEC and media packets for recovery, the CSRC list, extension, and padding MUST be removed from the media packets, if present, and the CC field, Extension Bit, and Padding Bit MUST be set to zero. These modified media packets, along with the FEC packets, are then used to recover based on the procedures in section 8. The recovered media packets will always have no extension, padding, or CSRC list. An implementation MAY copy these fields into the recovered packet from another media packet, if available.
要使用FEC和媒体数据包进行恢复，必须从媒体数据包（如果存在）中删除CSC列表、扩展和填充，并且CC字段、扩展位和填充位必须设置为零。这些修改后的媒体分组以及FEC分组随后用于基于第8节中的过程进行恢复。恢复的媒体数据包将始终没有扩展名、填充或列表。如果可用，实现可以将这些字段从另一媒体分组复制到恢复的分组中。
Using the redundant encodings payload format also implies that the marker bit may not be recovered correctly. Applications MUST set the marker bit to zero in media packets reconstructed using FEC encapsulated in RFC 2198 redundancy.
使用冗余编码有效负载格式还意味着可能无法正确恢复标记位。应用程序必须将使用RFC 2198冗余中封装的FEC重建的媒体包中的标记位设置为零。
An advantage of this approach is a reduction in the overhead for sending FEC packets.
这种方法的优点是减少了发送FEC数据包的开销。
11 Indicating FEC Usage in SDP
11表示在SDP中使用FEC
FEC packets contain RTP packets with dynamic payload type values. In addition, the FEC packets can be sent on separate multicast groups or separate ports from the media. The FEC can even be carried in packets containing media, using the redundant encodings payload format [5]. These configuration options must be indicated out of band. This section describes how this can be accomplished using the Session Description Protocol (SDP), specified in RFC 2327 [6].
FEC数据包包含具有动态有效负载类型值的RTP数据包。此外，FEC分组可以在单独的多播组上发送，也可以在媒体的单独端口上发送。FEC甚至可以使用冗余编码有效载荷格式在包含媒体的分组中携带[5]。必须在带外指示这些配置选项。本节描述了如何使用RFC 2327[6]中指定的会话描述协议（SDP）实现这一点。
In the first case, the FEC packets are sent as a separate stream. This can mean they are sent on a different port and/or multicast group from the media. When this is done, several pieces of information must be conveyed:
在第一种情况下，FEC分组作为单独的流发送。这可能意味着它们被发送到与媒体不同的端口和/或多播组。完成此操作后，必须传达几条信息：
o The address and port where the FEC is being sent to
o 发送FEC的地址和端口
o The payload type number for the FEC
o FEC的有效负载类型编号
o Which media stream the FEC is protecting
o FEC正在保护哪个媒体流
The payload type number for the FEC is conveyed in the m line of the media it is protecting, listed as if it were another valid encoding for the stream. 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 "parityfec".
FEC的有效负载类型号在其所保护的媒体的m行中传送，列示为流的另一个有效编码。FEC没有静态有效负载类型分配，因此必须使用动态有效负载类型编号。与编号的绑定由rtpmap属性指示。此绑定中使用的名称是“parityfec”。
The presence of the payload type number in the m line of the media it is protecting does not mean the FEC is sent to the same address and port as the media. Instead, this information is conveyed through an fmtp attribute line. The presence of the FEC payload type on the m line of the media serves only to indicate which stream the FEC is protecting.
它所保护的媒体的m行中存在有效负载类型号并不意味着FEC被发送到与媒体相同的地址和端口。相反，该信息通过fmtp属性行传输。媒体的m行上存在FEC有效负载类型仅用于指示FEC正在保护哪个流。
The format for the fmtp line for FEC is:
FEC的fmtp行格式为：
a=fmtp:<number> <port> <network type> <addresss type> <connection
address>
a=fmtp:<number> <port> <network type> <addresss type> <connection
address>
where 'number' is the payload type number present in the m line. Port is the port number where the FEC is sent to. The remaining three items - network type, address type, and connection address - have the same syntax and semantics as the c line from SDP. This allows the fmtp line to be partially parsed by the same parser used on the c
其中“number”是m线中存在的有效负载类型编号。Port是将FEC发送到的端口号。其余三项（网络类型、地址类型和连接地址）的语法和语义与SDP中的c行相同。这允许fmtp行被c上使用的相同解析器部分解析
lines. Note that since FEC cannot be hierarchically encoded, the <number of addresses> parameter MUST NOT appear in the connection address.
线请注意，由于FEC不能分层编码，因此连接地址中不得出现<number of addresses>参数。
The following is an example SDP for FEC:
以下是FEC的SDP示例：
v=0
o=hamming 2890844526 2890842807 IN IP4 126.16.64.4
s=FEC Seminar
c=IN IP4 224.2.17.12/127
t=0 0
m=audio 49170 RTP/AVP 0 78
a=rtpmap:78 parityfec/8000
a=fmtp:78 49172 IN IP4 224.2.17.12/127
m=video 51372 RTP/AVP 31 79
a=rtpmap:79 parityfec/8000
a=fmtp:79 51372 IN IP4 224.2.17.13/127
v=0
o=hamming 2890844526 2890842807 IN IP4 126.16.64.4
s=FEC Seminar
c=IN IP4 224.2.17.12/127
t=0 0
m=audio 49170 RTP/AVP 0 78
a=rtpmap:78 parityfec/8000
a=fmtp:78 49172 IN IP4 224.2.17.12/127
m=video 51372 RTP/AVP 31 79
a=rtpmap:79 parityfec/8000
a=fmtp:79 51372 IN IP4 224.2.17.13/127
The presence of two m lines in this SDP indicates that there are two media streams - one audio and one video. The media format of 0 indicates that the audio uses PCM, and is protected by FEC with payload type number 78. The FEC is sent to the same multicast group and TTL as the audio, but on a port number two higher (49172). The video is protected by FEC with payload type number 79. The FEC appears on the same port as the video (51372), but on a different multicast address.
此SDP中存在两条m线表示存在两个媒体流—一个音频流和一个视频流。媒体格式为0表示音频使用PCM，并受负载类型编号为78的FEC保护。FEC被发送到与音频相同的多播组和TTL，但端口号为2（49172）。视频由有效负载类型号为79的FEC保护。FEC显示在与视频（51372）相同的端口上，但在不同的多播地址上。
When the FEC stream is being sent as a secondary codec in the redundant encodings format, this must be signaled through SDP. To do this, the procedures defined in RFC 2198 are used to signal the use of redundant encodings. 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. In this case, the fmtp attribute for the FEC MUST NOT be present.
当FEC流以冗余编码格式作为辅助编解码器发送时，必须通过SDP发出信号。为此，RFC 2198中定义的过程用于发出使用冗余编码的信号。FEC有效负载类型以与任何其他辅助编解码器相同的方式指示。rtpmap属性必须用于指示FEC数据包的动态有效负载类型编号。FEC必须仅保护主编解码器。在这种情况下，FEC的fmtp属性不得存在。
For example:
例如：
m=audio 12345 RTP/AVP 121 0 5 100
a=rtpmap:121 red/8000/1
a=rtpmap:100 parityfec/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 parityfec/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 parityfec 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属性绑定到parityfec）组成。尽管FEC格式被指定为该流的可能编码，但FEC不能针对该流自行发送。仅因为根据RFC 2198，此处必须列出非主编解码器，所以需要在m行中显示它。fmtp属性表示可以使用冗余编码格式，DVI作为二级编码，FEC作为三级编码。
RTSP [7] can be used to request FEC packets to be sent as a separate stream. When SDP is used with RTSP, the Session Description does not include a connection address and port number for each stream. Instead, RTSP uses the concept of a "Control URL". Control URLs are used in SDP in two distinct ways.
RTSP[7]可用于请求将FEC数据包作为单独的流发送。当SDP与RTSP一起使用时，会话描述不包括每个流的连接地址和端口号。相反，RTSP使用“控制URL”的概念。控件URL在SDP中有两种不同的使用方式。
1. There is a single control URL for all streams. This is referred to as "aggregate control". In this case, the fmtp line for the FEC stream is omitted.
1. 所有流都有一个单独的控制URL。这被称为“总量控制”。在这种情况下，省略FEC流的fmtp行。
2. There is a Control URL assigned to each stream. This is referred to as "non-aggregate control". In this case, the fmtp line specifies the Control URL for the stream of FEC packets. The URL may be used in a SETUP command by an RTSP client.
2. 有一个分配给每个流的控件URL。这被称为“非汇总控制”。在这种情况下，fmtp行指定FEC数据包流的控制URL。RTSP客户端可以在设置命令中使用URL。
The format for the fmtp line for FEC with RTSP and non-aggregate control is:
具有RTSP和非聚合控制的FEC的fmtp行格式为：
a=fmtp:<number> <control URL>
a=fmtp:<number> <control URL>
where 'number' is the payload type number present in the m line. Control URL is the URL used to control the stream of FEC packets. Note that the Control URL does not need to be an absolute URL. The rules for converting a relative Control URL to an absolute URL are given in RFC 2326, Section C.1.1.
其中“number”是m线中存在的有效负载类型编号。Control URL是用于控制FEC数据包流的URL。请注意，控件URL不需要是绝对URL。RFC 2326第C.1.1节给出了将相对控制URL转换为绝对URL的规则。
12 Security Considerations
12安全考虑
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 permutations on the usage of encryption. In particular:
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 different keys.
o 媒体流和FEC流都是加密的，但使用不同的密钥。
o The media stream and FEC stream are both encrypted, but using the same key.
o 媒体流和FEC流都是加密的，但使用相同的密钥。
The first three of these would require any application level signaling protocols to be aware of the usage of FEC, and to thus exchange keys for it and negotiate its 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 FEC packets should really be treated no differently than other RTP packets. Encrypting just one may also make certain known-plaintext attacks possible. For these reasons, applications utilizing encryption SHOULD encrypt both streams.
前三种协议要求任何应用级信令协议都知道FEC的使用情况，从而为其交换密钥，并分别在媒体和FEC流上协商其使用情况。在最后一种情况下，不需要这种额外的机制。前两种情况表现出分层冲突，因为FEC数据包实际上应该与其他RTP数据包进行相同的处理。仅加密一个也可能使某些已知的明文攻击成为可能。出于这些原因，使用加密的应用程序应该对这两个流进行加密。
However, the changing of keys becomes problematic. For example, if two packets a and b are sent, and FEC packet f(a,b) is sent, and the keys used for a and b are different, which key should be used to decode f(a,b)? In general, old keys will likely need to be cached, so that when the keys change for the media stream, the old key is kept, and used, until it is determined that the key has changed on the FEC packets as well.
但是，密钥的更改会出现问题。例如，如果发送了两个数据包a和b，并且发送了FEC数据包f（a，b），并且用于a和b的密钥不同，那么应该使用哪个密钥来解码f（a，b）？通常，可能需要缓存旧密钥，以便当媒体流的密钥改变时，保留并使用旧密钥，直到确定FEC分组上的密钥也改变为止。
Another issue with the use of FEC is its impact on network congestion. Adding FEC in the face of increasing network losses is a bad idea, as it can lead to increased congestion and eventual congestion collapse if done on a widespread basis. As a result, implementers MUST NOT substantially increase the amount of FEC in use as network losses increase.
使用FEC的另一个问题是它对网络拥塞的影响。在网络损失不断增加的情况下增加FEC是一个坏主意，因为如果在广泛的基础上这样做，可能会导致拥塞增加，并最终导致拥塞崩溃。因此，实施者不得随着网络损耗的增加而大幅增加FEC的使用量。
13 Acknowledgments
13致谢
This work is based on an earlier draft on FEC, submitted by Budge and Mackenzie in 1997. We would also like to thank Steve Casner, Mark Handley, Orion Hodson and Colin Perkins for their comments. Thanks to Anders Klemets who wrote the section on usage with RTSP.
这项工作基于Budge和Mackenzie于1997年提交的早期FEC草案。我们还要感谢史蒂夫·卡斯纳、马克·汉德利、奥里恩·霍德森和科林·帕金斯的评论。感谢Anders Klemets编写了关于RTSP使用的部分。
14 Authors' Addresses
14作者地址
Jonathan Rosenberg dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07046
Jonathan Rosenberg dynamicsoft 200行政区套房，新泽西州西橙120号，邮编：07046
Email: jdrosen@dynamicsoft.com
Email: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401, 1214 Amsterdam Ave. New York, NY 10027-7003
Henning Schulzrinne哥伦比亚大学M/S 0401，纽约州纽约市阿姆斯特丹大道1214号，邮编10027-7003
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
15 Bibliography
15参考书目
[1] J.C. Bolot and A. V. Garcia, "Control mechanisms for packet audio in the internet," in Proceedings of the Conference on Computer Communications (IEEE Infocom) , (San Francisco, California), Mar. 1996.
[1] J.C.Bolot和A.V.Garcia，“互联网中数据包音频的控制机制”，《计算机通信会议记录》（IEEE Infocom）（加利福尼亚州旧金山），1996年3月。
[2] Perkins, C. and O. Hodson, "Options for Repair of Streaming media", RFC 2354, June 1998.
[2] Perkins，C.和O.Hodson，“修复流媒体的选项”，RFC 2354，1998年6月。
[3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[3] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[4] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[5] 帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛，J.C.，维加·加西亚，A.和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[6] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[7] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[7] Schulzrinne，H.，Rao，A.和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。