用于通用前向纠错的 RTP 有效载荷格式 （RFC-5109）

RFC文档链接

本备忘录的状态

本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。 本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。 本备忘录的分发不受限制。

摘要

本文件规定了封装在 RTP 中的媒体数据的通用前向纠错 (FEC) 的有效载荷格式。 它基于异或（奇偶校验）操作。 除了使用各种保护组大小来适应不同的媒体和信道特性之外，本文档中描述的有效载荷格式允许终端系统使用各种保护长度和级别来应用保护。 它可以根据丢包情况完全恢复受保护的数据包或部分恢复有效载荷的关键部分。 该方案与不具备FEC能力的主机完全兼容，因此组播组中没有实现FEC的接收者仍然可以通过简单地忽略保护数据来工作。 本规范废弃了 RFC 2733 和 RFC 3009。本文档中指定的 FEC 不向后兼容 RFC 2733 和 RFC 3009。

1、简介

实时应用的性质意味着它们通常比普通数据传输具有更严格的延迟要求。 因此，重传丢失的数据包通常不是此类应用程序的有效选项。 在这些情况下，尝试从数据包丢失中恢复信息的更好方法是通过前向纠错 (FEC)。 FEC 是用于防止分组交换网络中数据包丢失的主要方法之一 [9, 10]。 特别是使用传统的纠错码，例如奇偶校验码、里德-所罗门码和汉明码，已经得到了广泛的应用。 要应用这些机制，需要协议支持。 RFC 2733 [9] 和 RFC 3009 [11] 定义了这样的 FEC 协议之一。 然而，在这两个 RFC 中，RTP 报头中的一些字段（P、X 和 CC 字段）的指定方式与 RTP [1] 中的设计不一致。 这可以防止对 RTP 数据包进行独立于负载的有效性检查。

本文档扩展了 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 的现有主机应尽可能更新以遵循此规范。

本文档定义了 RTP [1] 的有效载荷格式，允许对实时媒体进行通用前向纠错。 在这种情况下，通用意味着 FEC 协议  (1) 独立于受保护媒体的性质，无论是音频、视频还是其他； (2) 足够灵活以支持多种 FEC 配置； (3) 为自适应而设计，以便无需带外信令即可轻松修改 FEC 技术； (4) 支持多种不同的机制来传输 FEC 数据包。

此外，在许多情况下，网络连接的带宽是非常有限的资源。 另一方面，大多数传统的 FEC 方案并不是为了优化利用有限的带宽资源而设计的。 一个经常使用的改进是非均匀差错保护，它为数据流的不同部分提供不同级别的保护，这些部分的重要性各不相同。 非均匀差错保护方案通常可以更有效地利用带宽以提供更好的数据流整体保护以防止丢失。 适当的协议支持对于实现这些非均匀差错保护机制是必不可少的。 大多数非均匀差错保护方案的应用需要了解数据流不同部分的重要性。 因此，大多数此类方案是根据受保护媒体的结构为特定类型的媒体设计的，因此不是通用的。

FEC 算法和协议在本文档中定义为通用前向纠错，对实时媒体具有非均匀差错保护。 此处定义的特定算法称为不均匀级别保护 (ULP)。 有效载荷数据受到一个或多个保护级别的保护。 通过使用较小的分组大小（与较高的保护级别相比）来生成 FEC 数据包，较低的保护级别可以提供更大的保护。 正如我们将在下面讨论的，音频/视频应用通常会受益于非均匀差错保护方案，这些方案为每个数据包的开始部分提供更多保护，例如 ULP。 靠近数据包开头的数据通常比数据包中更远的数据更重要，并且往往携带更多的信息。

众所周知，在许多多媒体流中，更重要的数据部分总是位于数据包的开头。 这是编解码器设计中的常见做法，因为数据包的开头更接近标头处的重新同步标记，因此更有可能被正确解码。 此外，几乎所有的媒体格式在数据包的开头都有帧头，这是数据包中最重要的部分。

对于视频流，大多数现代格式都有可选的数据分区模式来提高错误恢复能力，其中视频宏块头数据、运动矢量数据和离散余弦变换 (DCT) 系数数据被分离到各自的分区中。例如，在ITU-T H.263 version 3中，有可选的附件5的数据分区语法。在MPEG-4 Visual Simple Profile中，有可选的数据分区模式。启用这些模式后，视频宏块 (MB) 标头和运动矢量分区（对视频重建质量更重要）在视频数据包开头的分区中传输，而剩余 DCT 系数分区（不太重要）在靠近数据包末尾的分区中传输。由于数据按重要性降序排列，因此在传输中对数据包的开始部分提供更多保护将是有益的。

对于音频流，许多新音频编解码器生成的比特流还包含具有不同重要性级别的数据。 然后按重要性降序传输这些不同的类别。 在这些情况下，对数据包的开头应用更多保护也将是有益的。 即使对于统一重要性的音频流，也可以将各种时移和拉伸技术应用于部分恢复的音频数据包。

音频/视频应用通常会受益于本文档中指定的 FEC 算法。 使用 ULP，可以进一步提高保护媒体有效载荷的效率。 本文件规定了将通用 FEC 应用于 RTP 媒体有效载荷的协议和算法。

2、术语

本文档中使用了以下术语：

媒体有效负载：从发送方传输的原始、未受保护的用户数据。 媒体有效载荷放置在 RTP 数据包内。

媒体头：包含媒体有效载荷的数据包的 RTP 头。

媒体包：媒体有效载荷和媒体头的组合称为媒体包。

FEC 数据包：发送端的 FEC 算法将媒体数据包作为输入。 它们既输出它们通过的媒体数据包，也输出称为 FEC 数据包的新生成的数据包，其中包含用于纠错的冗余媒体数据。 FEC 数据包根据本文档中指定的规则进行格式化。

FEC 报头：FEC 数据包中包含的报头信息。

FEC Level Header：包含在每个级别的 FEC 数据包中的头信息。

FEC 有效载荷：FEC 数据包的有效载荷。 它可以分为多个层次。

关联：当一个或多个媒体包用于生成 FEC 包（通过使用异或操作）时，FEC 包被称为与一个或多个媒体包“关联”（反之亦然）。 如果没有另外明确说明，它仅指用于生成 0 级 FEC 有效载荷的那些数据包。

本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是 按照 RFC 2119 [2] 中的描述进行解释。

3、基本操作

当 RTP 会话中的发送方希望使用通用奇偶校验 FEC 保护其发送的媒体流时，将使用此处描述的有效载荷格式。 此格式支持的 FEC 基于简单的异或 (XOR) 奇偶校验操作。 发送方从需要保护的媒体流中获取数据包，并确定这些数据包的保护级别和每个级别的保护长度。 如下文第 7 节所述，将数据分组在一起。 XOR 操作应用于有效载荷以生成 FEC 信息。 遵循此处定义的程序的结果是包含 FEC 信息的 RTP 数据包。 这些数据包可在接收器处用于恢复生成 FEC 信息的数据包或部分数据包。

FEC 的有效载荷格式包含允许发送方准确告诉接收方哪些媒体数据包受 FEC 数据包保护以及每个级别的保护级别和长度的信息。 具体而言，每个 FEC 数据包包含每个保护级别 k 的偏移掩码 m(k)。 如果掩码 m(k) 中的位 i 设置为 1，则媒体数据包编号 N + i 受此 FEC 数据包在级别 k 的保护。 N 称为序列号基数，也在 FEC 数据包中发送。 在第 k 级保护的数据量由 L(k) 指示，它也在 FEC 数据包中发送。 保护长度、偏移掩码、有效载荷类型和序列号基础完全识别用于以很少开销生成 FEC 数据包的奇偶校验码。 第 7.4 节描述了一组规则，它定义了如何为不同的保护级别设置掩码，第 10 节中有示例。

本文档还描述了在带内传输所有保护操作参数的过程。 这让发送方有很大的灵活性； 发送方可以根据当前网络条件调整保护，并确保接收方仍然可以使用 FEC 进行恢复。

在接收方，FEC 和原始媒体都被接收。 如果没有媒体数据包丢失，则可以忽略 FEC 数据包。 在丢失的情况下，FEC 数据包可以与其他接收到的媒体组合以恢复全部或部分丢失的媒体数据包。

4、奇偶校验码

为简洁起见，我们将函数 f(x,y,..) 定义为应用于数据块 x,y,... 的 XOR（奇偶校验）运算符。该函数的输出是另一个块，称为奇偶校验块。 为简单起见，我们在这里假设奇偶校验块计算为输入块的按位异或。 确切的程序在第 8 节中指定。

使用奇偶校验码保护数据块是通过在一组数据块上生成一个或多个奇偶校验块来实现的。 为了最有效，奇偶校验块必须由数据块的线性独立组合生成。 该特定组合称为奇偶校验码。 有效载荷格式使用 XOR 奇偶校验码。

例如，考虑在两个数据块上生成单个奇偶校验块的奇偶校验码。 如果原始媒体数据包是 a,b,c,d，则发送方生成的数据包为：

a        b        c        d           <-- 媒体流

        f(a,b)         f(c,d)         <-- FEC 流

其中时间向右增加。 在这个例子中，纠错方案（我们交替使用术语方案和代码）引入了 50% 的开销。
但是如果 b 丢失了，可以使用 a 和 f(a,b) 来恢复 b。

需要指出的是，除了 XOR 奇偶校验码之外，还有许多其他类型的前向纠错码也可用于保护有效载荷。 一个值得注意的例子是 Reed-Solomon 代码，还有很多其他的 [12]。 然而，这里使用 XOR 奇偶校验码是因为它在协议设计和实现方面的有效性和简单性。 这对于在资源有限的节点中实现尤为重要。

5、不均匀水平保护(ULP)

从上面的简单例子我们可以看出，对数据的保护取决于组的大小。 在上面的例子中，组大小为2。所以如果三个数据包（两个负载数据包和一个FEC数据包）中的任何一个丢失，仍然可以恢复原始负载数据。

通常，FEC 保护操作是带宽和保护强度之间的权衡。 作为源媒体数据包的一部分生成的 FEC 数据包越多，对丢失的保护就越强，但组合流消耗的带宽就越大。

正如大多数媒体有效载荷中的常见情况一样，并非数据包的所有部分都具有相同的重要性。 使用这一特性，人们可以通过非均匀差错保护实现更有效的信道带宽使用，即对数据包的不同部分应用不同的保护。 更多的带宽用于保护更重要的部分，而更少的带宽用于保护不太重要的部分。

数据包被分成重要性递减的部分，并且对每个部分应用不同强度的保护——这些部分被称为“级别”。 保护操作在每个级别独立应用。 单个 FEC 数据包可以携带多个级别的奇偶校验数据。 这种算法称为不均匀级别保护，或 ULP。

ULP 的保护如下图 1 所示。 在此示例中，两个 ULP FEC 数据包保护四个负载数据包。

ULP FEC包#1只有一层，保护包A和B。不是对A和B的整个包应用奇偶校验操作，它只保护两个包的一段数据。 在会话期间可以动态选择和改变的长度称为保护长度。

ULP FEC 数据包#2 具有两个保护级别。 0 级保护与 ULP FEC 数据包 #1 相同，不同之处在于它对数据包 C 和 D 进行操作。 1 级保护使用应用于数据包 A、B、C 和 D 的奇偶校验操作。请注意，级别 1 级保护对与级别 0 操作一组数据包的，并且具有与级别 0 不同的保护长度，任何其他级别也是如此。 信息全部通过本文档中指定的协议在带内传送。

正如我们在介绍中所讨论的，媒体流通常在数据包的开头具有更重要的部分。 在靠近数据包开头的级别中具有更强的保护而在更远的级别中具有较弱的保护通常是有用的。 ULP 算法提供了这样的 FEC 保护。

ULP FEC 不仅为数据包的开头提供了更多保护（这更重要），还尽可能避免了效率较低的情况，即数据包的早期部分无法恢复而后面的部分可以恢复（并且通常 必须丢弃）。

6、RTP 媒体包结构

媒体数据包的格式不受 FEC 的影响。 如果 FEC 作为单独的流发送，则媒体数据包将像没有 FEC 一样发送。

这种方法的优点是媒体数据包可以被不支持 FEC 的接收器解释。 这种与不支持 FEC 的接收器的兼容性在多播场景中特别有用。 使用 FEC 方案的开销仅存在于 FEC 数据包中，并且可以通过跟踪使用中的 FEC 数量来轻松监控和调整。

7、FEC 数据包结构

7.1、数据包结构

FEC 数据包是通过将 FEC 标头和一层或多层 FEC 标头和有效载荷放入 RTP 有效载荷来构建的，如图 2 所示：

7.2、FEC 数据包的 RTP 头

FEC 数据包的 RTP 标头仅在 FEC 在与受保护的有效载荷流（如第 14 节中定义）不同的流中发送时使用。 因此，下面的大部分讨论仅适用于这种情况。 FEC 数据包的 RTP 头中的所有字段都根据 RFC 3550 [1] 使用，其中一些字段在下面进一步说明。

Marker 标记：此字段不用于此有效负载类型，应设置为 0。

同步源 (SSRC)：SSRC 值应与其保护的媒体流的 SSRC 值相同。

序列号（SN）：序列号有标准定义——它必须比先前传输的 FEC 数据包中的序列号高 1。

时间戳（TS）：时间戳必须设置为传输 FEC 数据包时媒体 RTP 时钟的值。 因此，FEC 数据包中的 TS 值总是单调增加的。

负载类型：FEC 数据包的负载类型是通过动态的带外方式确定的。 根据 RFC 3550 [1]，不能识别有效载荷类型的 RTP 参与者必须丢弃它。 这提供了向后兼容性。 然后，FEC 机制可以用于具有混合 FEC 能力和 FEC 能力接收器的多播组中，特别是当 FEC 保护作为冗余编码发送时（见第 14 节）。 在这种情况下，FEC 保护将具有无法被 非FEC 能力接收者识别的有效载荷类型，因此将被忽略。

7.3、FEC 数据包的 FEC 标头

FEC 报头是 10 个八位字节。 头的格式如图3所示，由扩展标志（E位）、长掩码标志（L位）、P恢复字段、X恢复字段、CC恢复字段、M恢复字段、PT恢复字段、SN组成 基字段、TS恢复字段和长度恢复字段。

E 位是保留的扩展标志，用于指示对本规范的任何未来扩展。 它应该被设置为 0，并且应该被接收者忽略。

 L 位指示是否使用长掩码。 当 L 位未设置时，掩码长度为 16 位。 当 L 位被设置时，掩码长度为 48 位。

P恢复字段、X恢复字段、CC恢复字段、M恢复字段和PT恢复字段是通过对RTP头中对应的P、X、CC、M和PT值应用的保护操作获得的 与 FEC 数据包关联的媒体数据包。

SN 基字段必须设置为受 FEC 保护的那些媒体数据包（在所有级别）中最低的序列号，考虑到环绕。 这允许 FEC 操作在 L 字段设置为 0 时扩展到最多 16 个数据包的任何字符串，或者当 L 字段设置为 1 时扩展到 48 个数据包，依此类推。

TS 恢复字段是通过应用于与该 FEC 数据包相关联的媒体数据包的时间戳的保护操作来计算的。 这允许完全恢复时间戳。

长度恢复字段用于确定任何恢复数据包的长度。 它是通过对与此 FEC 数据包相关联的每个媒体数据包的媒体有效载荷、CSRC 列表、扩展和填充的长度（以字节为单位）总和的无符号网络排序 16 位表示的保护操作来计算的 （换句话说，媒体有效载荷数据包的 CSRC 列表、RTP 扩展和填充（如果存在）被“计算”为有效载荷的一部分）。 即使受保护媒体数据包的长度不同，这也允许应用 FEC 程序。 例如，假设 FEC 数据包是通过将两个媒体数据包异或在一起而生成的。 两个媒体包的净荷长度分别为3（0b011）和5（0b101）字节。 然后将长度恢复字段编码为 0b011 xor 0b101 = 0b110。

7.4、FEC 数据包的 FEC Level 标头

FEC 级头是 4 或 8 个八位字节（取决于 FEC 头中的 L 位）。 头的格式如图4所示。

FEC 级报头由保护长度字段和掩码字段组成。 保护长度字段是 16 位长。 掩码字段长 16 位（未设置 L 位时）或 48 位长（设置 L 位时）。 

FEC 级别报头中的掩码字段指示哪些数据包与当前级别的 FEC 数据包相关联。 它是 16 位或 48 位，取决于 L 位的值。 如果掩码中的位 i 设置为 1，则序列号为 N + i 的媒体包与此 FEC 包相关联，其中 N 是 FEC 包头中的 SN Base 字段。 掩码的最高有效位对应于 i=0，最低有效位在 L 位设置为 0 时为 i=15，或在 L 位设置为 1 时为 i=47。

掩码字段的设置应遵循以下规则：

a、一个媒体包应该在高于 0 级的每个保护级别只被保护一次。一个媒体包可以在 0 级被不同的包保护不止一次，前提是这些包的 0 级保护长度相等。

b、对于要在 p 级保护的媒体包，它也必须在任何 FEC 包中的 p-1 级受到保护。 请注意，相同媒体包的保护级别p和保护级别p-1可以在不同的FEC包中。

c、如果 ULP FEC 数据包包含级别 p 的保护，则它也必须包含级别 p-1 的保护。 请注意，在级别 p 中受保护的负载数据包的组合可能与级别 p-1 中的不同。

规则 (a) 的基本原理是多重保护增加了恢复实施的复杂性。 在更高级别上，多重保护提供的好处越来越少，因此为了更简单的实现，它的应用仅限于级别 0。 规则 (b) 的基本原理是保护偏移（对于每个关联的数据包）没有在协议中明确地用信号通知。 有了这个限制，可以很容易地从级别的保护长度中扣除偏移量。 规则 (c) 的基本原理是未明确指明保护级别。 此规则设置为隐式指定级别。

下面的图 5 说明了保护组合的一个示例。 它与图 1 中所示的示例相同。第 10.2 节中也更详细地显示了这个相同的示例，以说明如何设置标题中的字段。

在此示例中，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 节“示例”。

每个级别的 ULP FEC 数据包的有效载荷是应用于媒体有效载荷和与该级别的 ULP FEC 数据包关联的媒体数据包的填充的保护操作 (XOR)。 详细信息在保护操作的第 8 节中描述。

ULP FEC 数据包的大小取决于为保护操作选择的保护长度。 在上面的示例中，ULP FEC 数据包 #1 的长度为 L0（加上标头开销）。 具有两个级别的 ULP FEC 数据包 #2 的长度为 L0+L1（加上报头开销）。 它比它保护的一些数据包（本例中的数据包 B 和 C）长，也比它保护的一些数据包（本例中的数据包 A 和 D）短。

请注意，FEC 数据包（非 ULP 和 ULP）可能比它保护的最长媒体数据包大，因为来自标头的开销或者如果为 ULP 选择了较大的保护长度。 如果这导致 FEC 数据包超过其发送路径的最大传输单元大小，则这可能会导致困难。

8、保护操作

FEC 数据包由“FEC 位串”构成，该“FEC 位串”由受保护媒体 RTP 数据包的数据生成。 更具体地说，FEC位串是受保护媒体RTP数据包的“受保护位串”的按位异或。

保护操作可以遵循以下程序。 可以使用其他程序，但最终结果必须与此处描述的相同。

8.1、FEC 报头的生成

在 FEC 标头的情况下，为每个要在 FEC 级别 0 保护的媒体数据包生成受保护的位串（长度为 80 位）。它是通过按指定的顺序将以下字段连接在一起而形成的：

• RTP头的前64位（64位）
• 媒体数据包长度的无符号网络顺序 16 位表示，以字节为单位减去 12（对于固定 RTP 标头），即以下所有长度的总和（如果存在）：CSRC 列表、扩展标头、RTP 有效载荷和 RTP 填充（16 位）

通过对受保护位串应用奇偶校验操作形成 FEC 位串后，FEC 头由 FEC 位串生成如下：

FEC 位串中的第一个（最高有效）2 位被跳过。 FEC 位串中的下一位写入 FEC 数据包中 FEC 头的 P 恢复位。 FEC 位串中的下一位被写入 FEC 头的 E 恢复位。 FEC 位串的下 4 位写入 FEC 报头的 CC 恢复字段。 下一位写入 FEC 头的 M 恢复位。 FEC 位串的下 7 位写入 FEC 头中的 PT 恢复字段。 接下来的 16 位被跳过。 FEC 位串的下 32 位写入 FEC 头中的 TS 恢复字段。 接下来的 16 位被写入包头中的长度恢复字段。

8.2、FEC有效载荷的生成

对于 FEC 有效载荷的生成，受保护的位串只是受保护的 RTP 数据包。 因此，FEC 位串是这些受保护媒体 RTP 数据包的按位异或。 需要为每个级别生成这样的 FEC 位串，因为每个级别的受保护有效载荷分组组可能不同。 如果受保护的 RTP 数据包的长度不相等，则每个较短的数据包必须通过在末尾添加八位字节 0 来填充到最长数据包的长度。

对于保护级别 n (n = 0, 1, ...)，只有 Ln 个八位字节的数据被设置为在级别 n ULP 头之后的 FEC 级别 n 有效载荷数据。 数据是从 FEC 位串中的第 (Sn + 13) 个八位字节开始的 Ln 个八位字节，其中：

Sn = sum(Li : 0 <= i < n).

Li 是第 i 层的保护长度，S0 定义为 0。省略前 12 个八位字节的原因是该信息已经受到 FEC 头的保护。

9、恢复程序

FEC 数据包允许终端系统从媒体数据包丢失中恢复。 本节介绍执行此恢复的过程。

恢复需要两个不同的操作。 第一个确定必须组合哪些数据包（媒体和 FEC）以恢复丢失的数据包。 完成此操作后，第二步是实际重建数据。 第二步必须按如下所述执行。 第一步可以基于实现者选择的任何算法。 如果可能，不同的算法会导致复杂性和恢复丢失数据包的能力之间的权衡。

由于不等差错保护的性质（当使用时），丢失的有效载荷数据包可以全部或部分恢复，这取决于数据丢失情况。 可以通过检查从 FEC 报头检索到的数据包的恢复长度与恢复的有效载荷数据的实际长度来检测数据包的部分恢复。

9.1、RTP头的重建

令L为数据包列表（FEC和媒体包），可以组合来恢复在级别0的某些媒体数据包xi。过程如下：

1. 对于 T 中的媒体数据包，按照上一节中描述的生成 FEC 报头的过程计算受保护位串的前 80 位。

2. 对于 T 中的 FEC 数据包，FEC 位串是 80 位 FEC 头。

3. 将 T 中所有媒体包生成的受保护位串与 T 中所有 FEC 包生成的 FEC 位串按位异或来计算恢复b位串。

4. 使用标准的 12 字节 RTP 标头创建一个没有有效负载的新数据包。

5. 将新数据包的版本设置为 2。跳过恢复位串中的前 2 位。

6. 将新数据包中的填充位设置为恢复位串中的下一位。

7. 将新数据包中的扩展位设置为恢复位串中的下一位。

8. 将 CC 字段设置为恢复位串中的下一个 4 位。

9. 将新数据包中的标记位设置为恢复位串中的下一位。

10. 将新数据包中的有效载荷类型设置为恢复位串中的下 7 位。

11. 将新数据包中的 SN 字段设置为 xi。 跳过恢复位串中接下来的 16 位。

12. 将新数据包中的 TS 字段设置为恢复位串中的下一个 32 位。

13. 取恢复位串的下一个 16 位。 无论这代表什么无符号整数（假设网络顺序），从恢复位字符串中取出那么多字节并将它们附加到新数据包中。 这表示 CSRC 列表、扩展名、有效载荷和 RTP 有效载荷的填充。

14. 将新数据包的 SSRC 设置为其保护的媒体流的 SSRC，即 FEC 流关联的媒体流的 SSRC。

此过程将恢复 RTP 数据包的标头直至 SSRC 字段。

9.2、RTP有效载荷的重建

令T为数据包列表（FEC和媒体包），可以组合来恢复在某个保护级别的某些媒体数据包xi。过程如下：

1. 假设我们正在重构第 n 级的数据，第一步是从第 n 级的 ULP 头中得到第 n 级的保护长度（Ln）。

2. 对于 T 中的 FEC 数据包，第 n 级 FEC 比特串是 FEC 第 n 级有效载荷，即 n 级 ULP 头后面的数据的 Ln 个八位字节。

3. 对于T中的媒体包，n级保护比特串是从包的第(Sn+13)个八位字节开始的Ln个八位字节的数据。 Sn 与第 8.2 节中定义的相同。 请注意，0 级保护从 SSRC 字段后媒体数据包的第 13 个八位字节开始。 前 12 个八位字节的信息受 FEC 头保护。

4. 如果从媒体包生成的第 n 级受保护位串中的任何一个比当前级别的保护长度短，则将它们填充到该长度。 字节 0 的填充必须添加在位串的末尾。

5. 将 T 中所有媒体包生成的 n 级保护比特串与 T 中所有 FEC 包生成的 n 级 FEC 比特串按位异或来计算恢复比特串。

6. 上述生成的当前保护级别的恢复位串与所有其他级别的恢复位串串接，形成（完全或部分）恢复的媒体包。 请注意，每个保护级别的恢复比特串必须根据保护长度设置放置在该级别的恢复媒体数据包中的正确位置。

7. 恢复的媒体包的总长度从恢复的媒体包的保护级别0的恢复操作中恢复。 此信息可用于检查（所有级别的）完整恢复操作是否已将数据包恢复到其全长。

如果较高级别的受保护数据是可恢复的，则在大多数情况下，在较低保护级别受保护的数据是可恢复的。 该过程（连同用于较低保护级别的过程）通常将恢复 RTP 数据包的标头和有效载荷，直至达到当前级别的保护长度。

10、示例

在下面考虑的前两个示例中（第 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 设置了它们的标记位。

第三个例子（第 10.3 节）是为了说明 FEC 数据何时作为冗余数据与有效载荷数据包一起发送。

10.1、提供与 RFC 2733 类似的保护的示例

我们可以使用一个 FEC 数据包在单个级别中保护四个有效载荷数据包的全长。 这提供了与 RFC 2733 类似的保护。 该方案如图 6 所示。

从这四个数据包生成一个 FEC 数据包。 我们假设有效载荷类型 127 用于指示 FEC 数据包。 生成的 RTP 标头如图 7 所示。

FEC 数据包中的 FEC 头如图 8 所示。

级别 0 的 FEC 级别报头如图 9 所示。

10.2、具有两个保护级别的示例

一个更复杂的例子是在两个级别使用 FEC。 0 级 FEC 将为有效载荷数据包的开始部分提供更好的保护。 1 级 FEC 将对其余数据包应用额外的保护。 这在图 10 中进行了说明。在此示例中，L0 = 70 、 L1 = 90。

这将产生两个 FEC 数据包 - #1 和 #2。

 生成的 ULP FEC 数据包 #1 将具有如图 11 所示的 RTP 标头。 ULP FEC 数据包 #1 的 FEC 标头将如图 12 所示。#1 的 0 级 ULP 标头将如图 13 所示 。

生成的 FEC 数据包 #2 将具有如图 14 所示的 RTP 标头。FEC 数据包 #2 的 FEC 标头将如图 15 所示。#2 的 0 级 ULP 标头将如图 16 所示。 #2 的 1 级 ULP 标头将如图 17 所示。

10.3、以 FEC 作为冗余编码的示例

此示例说明在与有效载荷相同的流中作为冗余编码发送的 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 设置了它们的标记位。

我们使用的 FEC 方案将具有一个级别，如第 10.1 节中的图 6 所示。 保护长度 L0 = 340 个八位字节。

冗余编码分组与有效载荷类型 100 一起使用。假设 FEC 的有效载荷类型为 127。前四个 RED 分组，RED #1 到 RED #4，每个都包含一个单独的媒体包 A、B、C、 或 D，分别。 生成保护前四个媒体包中的媒体数据的FEC数据。 第五个数据包 RED #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 数据包#1 到#4 的结构如图18 所示。RED 数据包#1 的RTP 标头如图19 所示，所有其他RED 数据包的格式类似，具有相应的序列号和时间戳。 RED 数据包的主要编码块头如图 20 所示。

FEC 数据不是直接从 RED 数据包中生成的，而是从包含媒体数据包数据的虚拟 RTP 数据包中生成的。 这些虚拟 RTP 数据包可以很容易地从包含和不包含冗余编码的 RED 数据包中生成。 从 RED 数据包到虚拟 RTP 数据包的转换很简单：（1）去除任何 RED 块头和冗余编码数据，（2）用主要编码的 PT 替换 RTP 头中的 PT。

注意：在 RFC 2198 规定的冗余编码的有效载荷格式中，一旦在 RED 数据包中携带主要编码，标记位就会丢失。 因此，无论是否使用 FEC，都无法恢复标记位。

如上所述，RED 数据包#5 将包含 FEC 数据（保护媒体数据包 A、B、C 和 D）以及媒体数据包 E 的数据。 RED 数据包 #5 的结构如图 21 所示 。

包含 FEC 的 RED 数据包的 RTP 头与图 19 所示相同，以及它们对应的序列号和时间戳。

在 RED 数据包 #5 中，FEC 数据包数据块的冗余编码块标头如下图 22 所示。它后面是 FEC 数据包数据，在这种情况下，它包括一个 FEC 标头（如图所示的 10 个八位字节） 在图 8 中）、ULP 0 级报头（图 9 中所示的 4 个八位字节）和 ULP 0 级数据（为 0 级设置的 340 个八位字节）。 这些后面是包含媒体数据包 E 数据的主要编码块。

11、安全注意事项

在安全通信中使用带加密的 FEC 有两种方法：一种方法是将 FEC 应用于已加密的有效载荷，另一种方法是在加密之前应用 FEC。 第一种情况是在媒体数据加密后传输过程中不可信节点需要FEC。 当媒体数据在通过安全传输传输之前受 FEC 保护时，会遇到第二种情况。

由于此 FEC 的受保护负载是 RTP 数据包，因此对加密负载应用 FEC 主要适用于安全 RTP (SRTP) [13]。 因为 FEC 在有效载荷上应用 XOR，所以 FEC 数据包在加密方面应该与原始有效载荷一样安全。 在这种情况下，不需要对 FEC 数据包进行额外加密。

在下面的讨论中，假设在加密之前将 FEC 应用于有效载荷。 FEC 的使用对加密密钥的使用和更改有影响。 由于 FEC 数据包确实由一个单独的流组成，因此在加密的使用上有多种组合。 这些包括：

• FEC 流可能会被加密，而媒体流则不会。
• 媒体流可能会被加密，而 FEC 流则不会。
• 媒体流和 FEC 流都经过加密，但使用相同的密钥。
• 媒体流和 FEC 流都是加密的，但使用不同的密钥。

其中前三个将要求所有应用级信令协议用于了解 FEC 的使用，从而分别交换密钥和协商对媒体和 FEC 流的加密使用。 在最后一种情况下，不需要这种额外的机制。 前两种情况表示分层违规，因为 ULP FEC 数据包的处理方式与其他 RTP 数据包没有区别。 仅加密一个流也可能使某些已知明文攻击成为可能。 由于这些原因，使用加密的应用程序应该加密两个流，即最后两个选项。

此外，因为对于某些密码，媒体有效载荷和 FEC 数据之间的已知关系可能会削弱加密，所以当媒体有效载荷和 FEC 数据在单独的流中发送时，必须对每个流使用不同的加密密钥。 请注意，当 SRTP [13] 用于 RTP 会话的安全性时，SRTP 规范要求每个 RTP 会话使用不同的密钥。

加密密钥的更改是另一个需要解决的关键问题。 考虑两个数据包 a 和 b 与保护它们的 FEC 数据包一起发送的情况。 用于加密a和b的密钥不同，那么应该使用哪个密钥来解码FEC数据包？ 通常，旧密钥需要缓存，以便当媒体流的密钥发生变化时，可以使用旧密钥，直到确定ULP FEC数据包的密钥也发生了变化。 此外，新密钥应该用于加密由旧密钥和新密钥加密的有效载荷数据包组合生成的 FEC 数据包。 发送方和接收方需要定义如何执行加密以及如何使用密钥

改变 FEC 数据和数据包会对重建操作产生很大影响。 通过更改 FEC 数据中的某些位进行的攻击会对有效载荷数据包的计算和恢复产生重大影响。 例如，更改长度恢复字段可能会导致恢复太长的数据包。 此外，恢复的计算复杂性很容易受到至少一个数量级的影响。 根据应用场景，在执行恢复操作之前对接收的有效载荷和 FEC 数据执行完整性检查并在使用之前确定从恢复操作中恢复的数据的有效性可能会有所帮助。

12、拥塞注意事项

使用 FEC 的另一个问题是它对网络拥塞的影响。 在许多情况下，网络中的数据包丢失是由拥塞引起的。 在这种情况下，应避免在遇到网络损耗增加时添加 FEC。 如果它被广泛使用，这会导致拥塞增加和最终拥塞崩溃。 应用程序可以包括更强的保护，同时减少有效载荷数据包的带宽。 在任何情况下，随着网络损耗的增加，实现不得大幅增加使用中的带宽总量（包括有效载荷和 FEC）。

适用于传输 RTP 数据的一般拥塞控制考虑； 参见 RTP [1] 和任何适用的 RTP 配置文件（例如，RTP/AVP [14]）。 如果使用尽力而为服务，一个额外的要求是，这种有效载荷格式的用户必须监控数据包丢失以确保数据包丢失率在可接受的参数范围内。 如果 TCP 流通过相同的网络路径并经历相同的网络条件，在合理的时间尺度上测量的平均吞吐量不低于 RTP 流所达到的平均吞吐量，则认为数据包丢失是可以接受的。 这个条件可以通过实施拥塞控制机制来满足传输速率（或为分层多播会话订阅的层数），或者如果丢失率高得无法接受，则通过安排接收器离开会话。

13、IANA 考虑事项

如本节所述，四种新媒体子类型已向 IANA 注册。 此注册是使用注册模板 [3] 并遵循 RFC 3555 [4] 完成的。

13.1、注册音频/ulpfec

类型名称：音频

子类型名称：ulpfec

所需参数：

速率：RTP 时间戳速率，用于标记单独流中 FEC 数据包的传输时间。 在将其作为冗余数据发送到另一个流的情况下，速率应与其用于保护的主要编码相同。 在单独的流中使用时，速率应大于 1000 Hz，以便为 RTCP 操作提供足够的分辨率。 选定的速率可以是高于 1000 Hz 的任何值，但建议与此流保护的媒体速率相匹配。

可选参数：

一个级别：这指定是否仅使用一级 FEC 保护。 允许的值为 0 和 1。如果信号为 1，则流中仅应使用一级 FEC 保护。 如果信号为 0，则可以使用多于一级的 FEC 保护。 如果省略，则默认值为 0。

编码注意事项：这种格式是有框架的（参见模板文档 [3] 中的第 4.8 节）并包含二进制数据。

安全考虑：相同的安全考虑适用于这些媒体类型注册以及它们的有效负载，如 RFC 5109 中详述。

互操作性考虑：无

已发布规范：RFC 5109

使用此媒体类型的应用程序：寻求通过随媒体流发送附加数据来提高丢失恢复能力的多媒体应用程序。

附加信息：无

要联系以获取更多信息的人员和电子邮件地址：

Adam Li adamli@hyervision.com
IETF Audio/Video Transport Working Group

预期用途：常见

使用限制：此媒体类型取决于 RTP 帧，因此仅定义为通过 RTP 传输 [1]。 不应定义其他成帧协议内的传输，因为这是 RTP 的健壮性机制。

作者：Adam Li adamli@hyervision.com

更改控制器：IETF 音频/视频传输工作组由 IESG 授权。

13.2、视频/ulpfec的注册

类型名称：视频

子类型名称：ulpfec

所需参数：

速率：RTP 时间戳速率，用于标记单独流中 FEC 数据包的传输时间。 在将其作为冗余数据发送到另一个流的情况下，速率应与其用于保护的主要编码相同。 在单独的流中使用时，速率应大于 1000 Hz，以便为 RTCP 操作提供足够的分辨率。 选定的速率可以是高于 1000 Hz 的任何值，但建议与此流保护的媒体速率相匹配。

可选参数：

一个级别：这指定是否仅使用一级 FEC 保护。 允许的值为 0 和 1。如果信号为 1，则流中仅应使用一级 FEC 保护。 如果信号为 0，则可以使用多于一级的 FEC 保护。 如果省略，则默认值为 0。

编码注意事项：这种格式是有框架的（参见模板文档 [3] 中的第 4.8 节）并包含二进制数据。

安全考虑：相同的安全考虑适用于这些媒体类型注册以及它们的有效负载，如 RFC 5109 中详述。

互操作性考虑：无

已发布规范：RFC 5109

使用此媒体类型的应用程序：寻求通过随媒体流发送附加数据来提高丢失恢复能力的多媒体应用程序。

附加信息：无

要联系以获取更多信息的人员和电子邮件地址：

Adam Li adamli@hyervision.com
IETF Audio/Video Transport Working Group

预期用途：常见

使用限制：此媒体类型取决于 RTP 帧，因此仅定义为通过 RTP 传输 [1]。 不应定义其他成帧协议内的传输，因为这是 RTP 的健壮性机制。

作者：Adam Li adamli@hyervision.com

更改控制器：IETF 音频/视频传输工作组由 IESG 授权。

13.3、text/ulpfec的注册

类型名称：文本

子类型名称：ulpfec

所需参数：

速率：RTP 时间戳速率，用于标记单独流中 FEC 数据包的传输时间。 在将其作为冗余数据发送到另一个流的情况下，速率应与其用于保护的主要编码相同。 在单独的流中使用时，速率应大于 1000 Hz，以便为 RTCP 操作提供足够的分辨率。 选定的速率可以是高于 1000 Hz 的任何值，但建议与此流保护的媒体速率相匹配。

可选参数：

一个级别：这指定是否仅使用一级 FEC 保护。 允许的值为 0 和 1。如果信号为 1，则流中仅应使用一级 FEC 保护。 如果信号为 0，则可以使用多于一级的 FEC 保护。 如果省略，则默认值为 0。

编码注意事项：这种格式是有框架的（参见模板文档 [3] 中的第 4.8 节）并包含二进制数据。

安全考虑：相同的安全考虑适用于这些媒体类型注册以及它们的有效负载，如 RFC 5109 中详述。

互操作性考虑：无

已发布规范：RFC 5109

使用此媒体类型的应用程序：寻求通过随媒体流发送附加数据来提高丢失恢复能力的多媒体应用程序。

附加信息：无

要联系以获取更多信息的人员和电子邮件地址：

Adam Li adamli@hyervision.com
IETF Audio/Video Transport Working Group

预期用途：常见

使用限制：此媒体类型取决于 RTP 帧，因此仅定义为通过 RTP 传输 [1]。 不应定义其他成帧协议内的传输，因为这是 RTP 的健壮性机制。

作者：Adam Li adamli@hyervision.com

更改控制器：IETF 音频/视频传输工作组由 IESG 授权。

13.4、应用程序/ulpfec的注册

类型名称：应用程序

子类型名称：ulpfec

所需参数：

速率：RTP 时间戳速率，用于标记单独流中 FEC 数据包的传输时间。 在将其作为冗余数据发送到另一个流的情况下，速率应与其用于保护的主要编码相同。 在单独的流中使用时，速率应大于 1000 Hz，以便为 RTCP 操作提供足够的分辨率。 选定的速率可以是高于 1000 Hz 的任何值，但建议与此流保护的媒体速率相匹配。

可选参数：

一个级别：这指定是否仅使用一级 FEC 保护。 允许的值为 0 和 1。如果信号为 1，则流中仅应使用一级 FEC 保护。 如果信号为 0，则可以使用多于一级的 FEC 保护。 如果省略，则默认值为 0。

编码注意事项：这种格式是有框架的（参见模板文档 [3] 中的第 4.8 节）并包含二进制数据。

安全考虑：相同的安全考虑适用于这些媒体类型注册以及它们的有效负载，如 RFC 5109 中详述。

互操作性考虑：无

已发布规范：RFC 5109

使用此媒体类型的应用程序：寻求通过随媒体流发送附加数据来提高丢失恢复能力的多媒体应用程序。

附加信息：无

要联系以获取更多信息的人员和电子邮件地址：

Adam Li adamli@hyervision.com
IETF Audio/Video Transport Working Group

预期用途：常见

使用限制：此媒体类型取决于 RTP 帧，因此仅定义为通过 RTP 传输 [1]。 不应定义其他成帧协议内的传输，因为这是 RTP 的健壮性机制。

作者：Adam Li adamli@hyervision.com

更改控制器：IETF 音频/视频传输工作组由 IESG 授权

14、FEC的复用

FEC 数据包可以与受保护的有效载荷一起主要通过以下两种方式之一发送到接收器：作为单独的流，或作为冗余编码在同一流中。 配置选项必须在带外指示。 本节还描述了如何使用 RFC 2327 [8] 中指定的会话描述协议 (SDP) 来实现这一点。

14.1、FEC 作为单独的流

当 FEC 数据包在单独的流中发送时，必须传达几条信息：

• FEC 被发送到的地址和端口
• FEC 的有效载荷类型编号
• FEC 保护的媒体流

FEC 没有静态有效载荷类型分配，因此必须使用动态有效载荷类型编号。 FEC 流的 SSRC 必须设置为受保护的有效载荷流的 SSRC。 FEC 流与其对应流的关联是通过 SDP [5] 中具有 FEC 语义 [6] 的行分组或其他外部手段来完成的。

遵循 RFC 3550 [1] 的第 5.2 节中讨论的原则，FEC 流及其关联的有效载荷流的多路复用通常由目标传输地址（网络地址和端口号）提供，每个 RTP 会话的地址都不同。在一个单独的 RTP 会话中将 FEC 与有效载荷一起发送并仅通过 SSRC 或有效载荷类型进行复用排除： (1) 对有效载荷和 FEC 保护数据使用不同的网络路径或网络资源分配； (2) 如果需要，接收媒体子集，特别是对于不理解 FEC 的主机； (3) 接收器实现对不同的媒体使用不同的进程。此外，将 FEC 与有效载荷数据流复用会影响原始有效载荷流的时序和序列号空间，这通常是不可取的。所以 FEC 流和有效载荷流应该通过两个单独的 RTP 会话发送，并且应该避免将它们按有效载荷类型复用到一个单个 RTP 会话中。 此外，FEC 和有效载荷不得被 SSRC 复用为一个单一的 RTP 会话，因为它们始终具有相同的 SSRC。

就像任何媒体流一样，FEC 流的端口号和有效载荷类型号在 SDP 中的 m 行中传送。 FEC 没有静态有效载荷类型分配，因此必须使用动态有效载荷类型编号。 与号码的绑定由 rtpmap 属性指示。 此绑定中使用的名称是“ulpfec”。 FEC 流所在的地址在其相应的 c 行中传送。

FEC 流与其保护的有效载荷流之间的关联关系通过 SDP (RFC 3388) [5] 中的媒体线路分组使用 FEC 语义 (RFC 4756) [6] 来传达。 FEC 流和受保护的有效载荷流形成一个 FEC 组。

以下是组播会话中 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

此 SDP 中存在两条 a=group 行表明有两个 FEC 组。第一个 FEC 组，如“a=group:FEC 1 2”行所示，由流 1（使用 PCM [14] 的音频流）和流 2（保护 FEC 流）组成。 FEC 流被发送到同一个多播组，并且与音频具有相同的生存时间 (TTL)，但在比音频高两个的端口号。第二个 FEC 组，如“a=group:FEC 3 4”行所示，由流 3（视频流）和流 4（保护 FEC 流）组成。 FEC 流被发送到不同的多播地址，但与有效负载视频流具有相同的端口号 (30004)。

14.2、FEC 作为冗余编码

当 FEC 流以冗余编码格式作为辅助编解码器发送时，必须通过 SDP 发出信号。为此，使用 RFC 2198 [7] 中定义的程序来表示冗余编码的使用。 FEC 有效载荷类型以与任何其他辅助编解码器相同的方式指示。 FEC 必须只保护主编解码器，FEC 引擎的有效载荷来自从主编解码器数据创建的虚拟 RTP 数据包。 虚拟 RTP 数据包可以很容易地从 RFC 2198 数据包转换，只需 (1) 删除所有附加标头和冗余编码数据，以及 (2) 将 RTP 标头中的有效载荷类型替换为主要编解码器的有效载荷类型。

注意：在 RFC 2198 规定的冗余编码的有效载荷格式中，一旦在 RED 数据包中携带主要编码，标记位就会丢失。 因此，无论是否使用 FEC，都无法恢复标记位。

由于 FEC 数据（包括 ULP 标头）与受保护的负载在相同的数据包中发送，因此 FEC 数据通过捆绑在同一流中而与受保护的负载相关联。

当 FEC 流以冗余编码格式作为辅助编解码器发送时，这可以通过 SDP 发出信号。 为此，使用 RFC 2198 [7] 中定义的程序来表示冗余编码的使用。 FEC 有效载荷类型以与任何其他辅助编解码器相同的方式指示。 必须使用 rtpmap 属性来指示 FEC 数据包的动态有效载荷类型编号。 FEC 必须只保护主编解码器。

例如：

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

这个SDP表示有单个音频流，可以由PCM（媒体格式0）、DVI（媒体格式5）、冗余编码（媒体格式121表示，通过rtpmap属性绑定到red）、 或 FEC（媒体格式 100，通过 rtpmap 属性绑定到 ulpfec）。 尽管 FEC 格式被指定为该流的可能编码，但 FEC 不得为该流单独发送。 它在 m 行中的存在是必需的，因为必须根据 RFC 2198 在此处列出非主要编解码器。 fmtp 属性表示可以使用冗余编码格式，其中 DVI 作为二级编码，FEC 作为三级编码。

14.3、Offer / Answer 考虑

当 SDP 用于 offer/answer [15] 交换时需要一些考虑。

“onelevelonly”参数是声明性的。 对于声明为 sendonly 的流，该值指示是否只发送一级 FEC。 对于声明为 recvonly 或 sendrecv 的流，该值表示接收者接受接收的内容。

当 FEC 作为单独的流发送并通过 SDP (RFC 3388) [5] 中的媒体线路分组使用 FEC 语义 (RFC 4756) [6] 发送信号时，提供方必须同时实现 RFC 3388 和 RFC 4756。应遵循 RFC 3388 和 RFC 4756 中的offer/answer规则，并进行以下额外考虑。对于所有使用 FEC 的提供者，应答者可以通过将端口设置为 0 来拒绝单独的 FEC 会话，并删除将 FEC 会话与受保护的 RTP 会话分组的“a=group”属性。如果应答者接受 FEC 的使用，则应答者通过在应答中包括相同的分组来简单地接受 FEC RTP 会话和提供者的分组。请注意，拒绝 FEC RTP 会话不会阻止媒体会话在没有 FEC 的情况下被接受和使用。

当 FEC 流作为冗余编码格式 (RFC 2198) [7] 中的辅助编解码器发送时，提供方可以按照第 14.2 节中的规定指示 FEC 流。 应答者可以通过移除 FEC 流的有效载荷类型来拒绝 FEC 流。 要接受 FEC 的使用，应答者必须在应答中包含 FEC 有效载荷类型。 请注意，在冗余负载格式 [7] 与 FEC 作为唯一的辅助编解码器一起使用的情况下，当 FEC 流被拒绝时，冗余编码负载类型也应该被删除。

15、应用声明

本文档描述了支持各种短块奇偶校验 FEC 算法的前向纠错通用协议，例如简单和交错奇偶校验码。该方案仅限于在 48 个数据包距离内的交错奇偶校验码。 此 FEC 算法与不支持 FEC 的主机完全兼容。由于媒体有效载荷没有改变并且保护是作为附加信息发送的，不知道本文档中指定的通用 FEC 的接收器可以简单地忽略附加 FEC 信息并处理主要媒体有效载荷。这种互操作性对于与现有主机的兼容性尤其重要，并且在许多不同主机需要同时相互通信的场景中，例如在多播期间。

本文档中规定的通用 FEC 算法也是具有以下特征的通用保护算法： (1) 它独立于被保护媒体的性质，无论该媒体是音频、视频还是其他； (2) 足够灵活，可以支持多种 FEC 机制和设置； (3) 自适应性设计，无需借助带外信令即可轻松修改FEC参数； (4) 它支持多种不同的 FEC 数据包传输机制。

此处指定的 FEC 还为用户提供了非均匀差错保护功能。 一些其他算法也可能通过其他方式提供非均匀差错保护能力。 例如，AVT 工作组在“用于渐进式多媒体流的擦除弹性传输的 RTP 有效载荷格式”中提出了非均匀擦除保护 (UXP) 方案。 UXP 方案通过将要保护的有效载荷流与使用 Reed-Solomon 操作获得的附加冗余信息交错，对媒体有效载荷应用非均匀差错保护。

通过改变受保护媒体有效载荷的结构，UXP 方案牺牲了与不支持 UXP 的终端的向后兼容性。 这使得在需要向后兼容时更难应用 UXP。 然而，在 ULP 的情况下，媒体有效载荷保持不变，并且始终可以由终端使用。 如果接收终端不支持 ULP，则可以简单地忽略额外的保护。

同时，也因为在 UXP 中改变了媒体有效载荷的结构，UXP 提供了改变数据包大小的独特能力，独立于原始媒体有效载荷结构和应用的保护，并且仅受协议开销约束。 当需要在传输级别更改媒体的数据包大小时，此属性很有用。

由于在 UXP 中使用了交织，因此在编码和解码端都会引入延迟。 对于 UXP，传输块内的所有数据需要在编码开始之前到达，并且在传输块可以被解码之前必须接收到合理数量的数据包。 ULP 方案在编码端引入的延迟很小。 在解码端，可以立即传送正确接收的数据包。 延迟仅在发生丢包时在 ULP 中引入。

由于 UXP 是一种交错方案，在受 UXP 保护的数据中发生的不可恢复的错误通常会导致有效载荷流中出现许多损坏的漏洞。 另一方面，在 ULP 中，由于比特流中的数据包丢失而导致的不可恢复的错误通常在数据包的末尾表现为连续的丢失片段。根据媒体有效负载流的编码，许多应用程序可能会发现，与具有多个损坏漏洞的数据包相比，从末尾仅丢失一个连续片段的数据包中解析和提取数据更容易，尤其是当孔洞与可独立解码的片段边界不一致时。

ULP 使用的异或 (XOR) 奇偶校验操作比 Reed-Solomon 代码所需的更复杂的操作更简单、更快。 这使得 ULP 更适合计算成本受限的应用。

如上所述，ULP 和 UXP 方案都对 RTP 媒体流应用了非均匀差错保护，但各自使用了不同的技术。 两种方案都有自己独特的特点，都可以适用于不同需求的场景。

16、致谢

略

17、参考

17.1、规范参考

[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP：实时应用的传输协议", STD 64, RFC 3550, July 2003.
[2] Bradner, S., "在 RFC 中用于表示需求级别的关键词", BCP 14, RFC 2119, March 1997.
[3] Freed, N. and J. Klensin, "媒体类型规格和注册程序", BCP 13, RFC 4288, December 2005.
[4] Casner, S., "RTP 有效载荷格式的媒体类型注册", RFC 4855, February 2007.
[5] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "会话描述协议 (SDP) 中媒体线的分组", RFC 3388, December 2002.
[6] Li, A., "会话描述协议中的前向纠错分组语义", RFC 4756, November 2006.

[7] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "冗余音频数据的 RTP 负载", RFC 2198, September 1997.
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP：会话描述协议", RFC 4566, July 2006.

17.2、参考资料

[9] Rosenberg, J. and H. Schulzrinne, "用于通用前向纠错的 RTP 有效载荷格式", RFC 2733, December 1999.
[10] Perkins, C. and O. Hodson, "流媒体修复选项", RFC 2354, June 1998.
[11] Rosenberg, J. and H. Schulzrinne, "parityfec MIME 类型的注册", RFC 3009, November 2000.
[12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "前向纠错 (FEC) 构建块", RFC 3452, December 2002.
[13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "安全实时传输协议 (SRTP)", RFC3711, March 2004.
[14] Schulzrinne, H. and S. Casner, "具有最少控制的音频和视频会议的 RTP 配置文件", STD 65, RFC 3551, July 2003.
[15] Rosenberg, J. and H. Schulzrinne, "具有会话描述协议 (SDP) 的提议/应答模型", RFC 3264, June 2002.

---