RFC2733中文--前向纠错码(FEC)

Z_X_Lei

已于 2022-02-25 15:06:11 修改

阅读量394

点赞数

分类专栏：音视频文章标签：网络 qos

于 2022-02-25 14:29:30 首次发布

原文链接：https://datatracker.ietf.org/doc/rfc2733/

版权

音视频专栏收录该内容

5 篇文章 0 订阅

订阅专栏

转载http://www.rosoo.net/a/201110/15146.html
整理格式便于阅读

TAG:

本备忘录状态
本文档讲述了一种Internet通信的标准Internet跟踪协议,并对其改进提出了讨论和建议。请参考最新版本的"Internet Official Protocol Standards"(STD1)来获得本协议的标准化进程和状态，此备忘录的发布不受任何限制。
版权注意
版权归因特网协会（1999）所有，保留一切权利。

摘要：

本文档规定了一般性的前向纠错的媒体数据流的RTP打包格式。这种格式针对基于异或操作的FEC算法进行了特殊设计，它允许终端系统使用任意长度的纠错码，并且可以同时恢复出荷载数据和RTP头中的关键数据。由于FEC作为一个分离的数据流进行传送，这种方案可以向后兼容那些没有实现FEC解码器的接收终端。对于那样的终端来说，可以简单地将FEC数据丢掉。

(目录)

1 简介

在Internet上用分组传送话音的质量不够好的一个重要原因是比较高的丢包率。尤其在广域网中，这个问题相当突出。不幸的是，实时多媒体业务对于延时的要求相当严格，因此不大可能通过重传来解决丢包的问题。正是出于这个原因，大家提出用前向纠错（FEC）来解决Internet上的丢包问题[1] [2]。尤其是对于传统纠错码如校验码、RS码、汉明码等的使用引起了很多人的注意。为了能够更好地应用这些纠错码，必须有相关的协议来支持。

本文档定义了一种RTP的荷载格式，允许对于实时媒体流进行一般性的前向纠错。在这里“一般性”指的是

（1）与被保护的媒体类型无关，即音频、视频或其它；
（2）足够灵活，能够支持多种FEC机制；
（3）自适应性，可以方便的修改FEC方案而不需要带外的信令支持；
（4）支持若干种不同的FEC包的传输机制。

2 术语

本文档中使用了下面这些术语：

媒体荷载：一段待传输的未加保护的用户数据。媒体荷载放在一个RTP包的内部。
媒体头：包含媒体荷载的包的RTP头
媒体包：媒体荷载与媒体头合起来称作媒体包
FEC包：发送端将媒体包作为前向纠错算法的输入，输出除了这些媒体包之外，还有一些新的数据包称作FEC包。FEC包的格式在本文档中进行说明。
FEC头：FEC包的头信息称作FEC头。
FEC荷载：FEC荷载是FEC包中的荷载。
关联的：一个FEC包称作与一个或几个媒体包是关联的，如果在这个FEC包的产生过程中这几个媒体包用作EC算法的输入关键词“必须”，“必须不”，“要求的”，“会“，”不会“，“应该”，“不应该”，“建议的”，“或许”，“可选的”在RFC2119[4]中解释。

3 基本操作

这里描述的荷载格式用于一个RTP会话中的某一端想要用FEC来保护它所传送的媒体数据流的情况。这种格式所支持的FEC是基于简单异或校验的纠错算法。发送端从媒体数据流中取出若干个包，并对它们整个施以异或操作，包括RTP头。基于这样一个过程，可以得到一个包含FEC信息的RTP包。这个包可以被接收端用来恢复任何一个用来产生它的包。本文档中并未规定多少个媒体包合起来产生一个FEC包。不同参数的选取会导致在overhead，延时和恢复能力之间的一个不同的折中方案。第4节给出了一些可能的组合。
发送端需要告诉接收端哪些媒体包被用来产生了一个FEC包，这些信息都包含在荷载信息中。每个FEC包中包含一个24比特的mask，如果mask的第i 个比特为1，序号为N＋i的媒体包就参与了这个FEC包的生成。N称作基序号，也在FEC包中传送。通过这样一种方案就可以以相当小的overhead来用任意的FEC纠错方案恢复丢失的数据包。
本文档也描述了如何使接收端在不了解具体纠错码细节的情况下利用FEC的方法。这就给了发送端更大的灵活性，它可以根据网络状态而自适应选择纠错码，而接收端仍能够正确解码并用于恢复丢失的包。
发送端生成FEC包之后，就把它们发给接收端，同时，发送端也照常发送原来的媒体数据包，就好像没有FEC一样。这样对于没有FEC解码能力的接收端，媒体流也照常可以接收并解码。然而，对于某些纠错码来说，原始的媒体数据包是不需要传输的，仅靠FEC包就足以恢复丢失的包了。这类码就具有一个很大的缺点，就是要求所有的接收者都具有FEC解码能力。这类码在本文档中也是支持的。
FEC包并不与媒体包在同一个RTP流中传输，而是在一个独立的流中传输，或者作为冗余编码(redundantencoding）中的次编码（secondaryencoding）来传输[5]。当在另一个流中传输时，FEC包有它们自己的序号空间。FEC包的时间戳是从对应的媒体包中得来的，同样是单调递增。因此，这样的FEC包可以很好地应用于任何具有固定差值的包头压缩方案。本文并没有规定何为“一个独立的流”，而把它留给上层协议和具体应用去定义。对于多播的情况，“一个独立的流”可以通过不同的多播组来实现，或者同一个组的不同端口，或者同样的组和端口中不同的SSRC。对于单播的情况，可以使用不同的端口或者不同的SSRC。
这些方法都各有其优缺点，选用哪一种取决于具体的应用。接收端收到FEC包和媒体包之后，先判断是否有媒体包丢失。如果没有，FEC包就直接被丢弃。如果有丢包，就使用接收到的FEC包和媒体包来进行丢包的重建。这样一个重建过程是很精确的，荷载以及包头的大部分数据都可以完全恢复出来。
按照本协议来进行打包的RTP包可以使用一个动态RTP荷载类型号来通知接收端。

4 监督码

我们定义f(x,y,…)为数据包x,y,…等的异或，这个函数的输出也是一个数据包，称作监督包。为简单起见，我们假定监督包就是输入的各个包的对应比特异或得到。详细的过程描述在第6节中给出。
用监督码来恢复数据包是通过对一组数据包生成一个或多个监督包来完成的。为了提高编码的效率，这些监督包必须是数据包的线性无关的组合生成的。某一个特定的组合就称为一个监督码。对于k个一组的数据包，生成n-k个监督包，这样的监督码认为是同一类监督码。对于给定的n,k，可能的监督码有很多。荷载格式并未要求使用某个特定的监督码。

举个例子，考虑这样一种监督码，输入为两个数据包，输出为1一个监督包。如果原始媒体数据包是a,b,c,d，发送端送出的包如下所示：

a        b        c        d               <-- media stream
           f(a,b)            f(c,d)        <-- FEC stream

时间从左向右递增。在这个例子里，纠错码带来了50%的overhead。但是如果b丢失了，用a和f(a,b)就可以恢复出b。

下面还给出了一些其它的监督码。其中每一个的原始媒体数据流都包含数据包a,b,c,d等等。

方案 1
--------
这个方案与上面的例子很类似。区别在于，并不是发送b之后再发送f(a,b)。f(a,b)在b之前就发送出去了。显然这样做会给发送端带来额外的延时，但是用这种方案能够恢复出突发的连续两个丢包。发送端送出的包如下所示：

a        b        c        d        e        <-- media stream
  f(a,b)   f(b,c)   f(c,d)   f(d,e)          <-- FEC stream

方案 2
--------
事实上，并没有严格规定一定要传送原始媒体数据流。在这个方案中，只传送FEC数据包。这种方案能够恢复出所有单个的丢包和某些连续的丢包，而且overhead比方案1略小一些。发送端送出的数据包如下所示：

f(a,b)  f(a,c)  f(a,b,c)  f(c,d)  f(c,e)  f(c,d,e)  <-- FEC stream

方案 3
--------
这种方案要求接收端在恢复原始媒体数据包时等待4个数据包间隔的时间，也就是在接收端引入了4个数据包的延时。它的优越性在于它能够恢复出单个丢包，连续两个丢包乃至连续三个丢包。发送端送出的数据包如下所示：

a         b          c                    d     <-- media stream
            f(a,b,c)    f(a,c,d) f(a,b,d)       <-- FEC stream

5 RTP媒体数据包结构

媒体数据包的结构并不受FEC的影响。如果FEC包作为一个独立的流进行传输，媒体数据包的传输就与不使用FEC时完全没有区别。如果FEC作为一个冗余编码（redundantcodec）来进行传输，媒体数据包就作为RFC2198[5]中定义的主编码（primarycodec）。
这样一种编码方式是非常高效的。如果只使用了极少量的FEC，大部分数据包都是媒体数据包，这意味着overhead代表着FEC的冗余数据量。

6 FEC包结构

一个FEC包就是把一个FEC包头和FEC包的荷载放进RTP包的荷载中组成的，如下图所示：

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         FEC Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         FEC Payload                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.1 FEC包的RTP包头

在FEC包的RTP包头中，版本域设定为2，填充位通过保护操作计算得到，具体方法在后面给出。扩展位也是通过保护操作计算得到的。一般情况下，SSRC 的值应当与它所保护的媒体数据包的SSRC值一致。如果FEC流通过SSRC值来进行解复用的话，SSRC的值就有可能会不同。CC的值也是在保护操作中计算出来。不管CC域为何值，CSRC列表永远不存在。不管X比特为何值，头扩展部分永远不存在。标记位的值通过保护操作计算得出。
对于次序号有一个标准的定义：当前包的次序号必须比前一个包的次序号大1。时间戳必须设定为当前这个FEC包发送时对应的媒体流的RTP时钟的值。不管使用何种FEC方案，FEC包头中的TS值是单调递增的。
FEC包的荷载类型是动态确定的，即在带外通过信令来协商确定的。按照RFC1889[3]，RTP会话的某一方如果不能识别收到的RTP包的荷载类型的话，就必须将其丢弃。这样就很自然地提供了向后兼容的能力。FEC机制可以用在一个多播的环境中，某些接收端具有FEC解码能力，而某些不具有。

6.2 FEC头

FEC头的长度为12个字节，其格式如图2所示。它包含一个SN基数域，长度恢复域，E域，PT恢复域，mask域以及TS恢复域。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      SN base                  |        length recovery        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| PT recovery |                 mask                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          TS recovery                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

长度恢复域用来确定待恢复的数据包的长度。它的值是当前组中被保护的媒体数据包的长度（以字节为单位）的二进制和（逐位异或），用一个网络序的16比特无符号整数表示。在这里，媒体数据包的长度包括CSRC列表、扩展部分和填充的比特。这样即使在媒体数据包长度不一致的情况下，也一样可以使用FEC。举个例子，假定要用两个媒体数据包的异或来产生一个FEC包，这两个媒体数据包的长度分别为3（0b011）和5（0b101）个字节，那么长度恢复域的值就是0b011xor0b101=0b110。
比特E指示是否存在一个扩展部分。在当前版本中，这个比特必须设置为0。
PT恢复域是通过对相关的媒体数据包的荷载类型域的值进行异或操作得到的，从而能够用来恢复丢失包的荷载类型。
Mask域长度为24个比特，如果其中的第i个比特设置为1，那么序号为N+i的媒体数据包就与当前FEC包相关联。其中N是SN基数域的值。最低位（LSB）对应于i＝0，最高位（MSB）对应于i＝23。
SN基数域的值必须设置为与当前FEC包相关的媒体数据包中的最小的序号。这样一个FEC包最多可以与连续24个媒体数据包相关联。
TS恢复域是通过计算相关联的媒体数据包的时间戳的异或得到的。这样就可以恢复出丢掉的数据包的时间戳。
FEC包的荷载是对相关联的媒体数据包的CSRC列表、RTP头部扩展、媒体包荷载以及填充比特连在一起进行异或操作得到的。
值得注意的是FEC包的长度有可能会比它保护的媒体数据包的长度大一点，因为多了一个FEC头。如果FEC包的长度超出了下层协议允许的最大包长，这可能会给传输带来很大的问题。

7 保护操作

保护操作涉及到将RTP头中的某些域与媒体包的荷载级联起来，再加上填充比特，然后对这些序列计算它们的异或值。得到的比特序列就成为FEC包的某个组成部分。对于每一个要保护的媒体包，按照下面的次序将各个数据域级联起来生成一个比特序列，如果中间还插入了其它操作的话，最终结果必须与下面所描述的一致：

     o Padding Bit (1 bit) 填充位

     o Extension Bit (1 bit) 扩展位

     o CC bits (4 bits)

     o Marker bit (1 bit) 标记位

     o Payload Type (7 bits) 荷载类型

     o Timestamp (32 bits) 时间戳

     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) 长度恢复域的值（网络次序16比特无符号整数），也就是各个媒体数据包的荷载长度、
       CSRC列表长度以及填充比特长度的和异或的结果

     o if CC is nonzero, the CSRC List (variable length)
	   如果CC不为零，这里是CSRC列表（变长）
     o if X is 1, the Header Extension (variable length)
       如果扩展位为1，这里是头部扩展（变长）
     o the payload (variable length) 荷载（变长）

     o Padding, if present (variable length) 填充，如果存在的话（变长）

需要注意的是最前面的填充位是整个比特序列的最重要比特（MSB）。
如果各个媒体数据包的到的比特序列长度不相等，那么每一个都必须填充到最长的序列那么长。填充值可以是任意的，但必须填充在整个比特序列的最后。对所有这些比特序列进行对位异或操作，就可以得到一个监督比特序列，这个监督比特序列就可以用来生成FEC包。称这个比特序列为FEC比特序列。FEC比特序列中的第一个比特填入FEC包的填充位，第二个比特填入FEC包的扩展位，接下来的四个比特填入FEC包的CC域，再下来的一个比特填入FEC包的标记位，然后的七个比特写入FEC包头的PT恢复域，再后面的32个比特写入FEC包头的TS恢复域，再接下来的16个比特写入FEC包头中的长度恢复域。最后剩下的比特就作为FEC包的荷载。

8 恢复过程

8.1 重建

8.2 何时进行恢复

9 例子

考虑这样的情况，有两个媒体数据包x和y要从SSRC2发送出去。它们的序号分别为8和9，时间戳分别为3和5。x的荷载类型为11，y的荷载类型为18。x有十个字节的荷载，y有11个字节的荷载。y的标记位为1。x和y的RTP包头分别如图3和图4所示。

媒体数据包 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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version:   2
      Padding:   0
      Extension: 0
      Marker:    0
      PTI:       11
      SN:        8
      TS:        3
      SSRC:      2