rfc2733.txt

本程序为在linux下实现FTP传输文件的实现

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：范晨 (fanchen  [e-mail])
译文发布时间：2001-10-11
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。


Network Working Group                                       J. Rosenberg
Request for Comments: 2733                                   dynamicsoft
Category: Standards Track                                 H. Schulzrinne
                                                     Columbia University
                                                           December 1999

前向纠错（FEC）的RTP荷载格式
（RFC2733——An RTP Payload Format for Generic Forward Error Correction）


本备忘录状态 
本文档讲述了一种Internet通信的标准Internet跟踪协议,并对其改进提出了讨论和建
议。请参考最新版本的"Internet Official Protocol Standards" (STD 1) 来获得本协议的
标准化进程和状态，此备忘录的发布不受任何限制。
版权注意
版权归因特网协会（1999）所有，保留一切权利。
摘要
本文档规定了一般性的前向纠错的媒体数据流的RTP打包格式。这种格式针对基于异或
操作的FEC算法进行了特殊设计，它允许终端系统使用任意长度的纠错码，并且可以同时恢
复出荷载数据和RTP头中的关键数据。由于FEC作为一个分离的数据流进行传送，这种方案
可以向后兼容那些没有实现FEC解码器的接收终端。对于那样的终端来说，可以简单地将FEC
数据丢掉。

目  录
1 简介	2
2 术语	2
3 基本操作	3
4 监督码	3
5 RTP媒体数据包结构	5
6 FEC包结构	5
6.1 FEC包的RTP包头	5
6.2 FEC头	5
7 保护操作	6
8 恢复过程	7
8.1 重建	7
8.2 何时进行恢复	8
9 例子	11
10 冗余编码中使用FEC的用法	13
11 在SDP中表示FEC	14
11.1 FEC作为独立的流传输	14
11.2在冗余编码中使用FEC	15
11.3 在RTSP中的用法	16
12 安全性问题	16
13 致谢	17
14 作者地址	17
15 参考书目	17
16.版权声明	18
致谢	18

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流中传输，而是在一个独立的流中传输，或者作为冗
余编码（redundant encoding）中的次编码（secondary encoding）来传输[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               <-- 媒体流
              f(a,b)            f(c,d)        <-- FEC流

   时间从左向右递增。在这个例子里，纠错码带来了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        <-- 媒体流
     f(a,b)   f(b,c)   f(c,d)   f(d,e)          <-- FEC流

   方案 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流

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

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

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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP 头                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         FEC 头                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         FEC 荷载                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   图 1: FEC包结构
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 基数                  |        长度恢复               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| PT 恢复     |                 mask                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          TS 恢复                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   图 2: FEC头格式

长度恢复域用来确定待恢复的数据包的长度。它的值是当前组中被保护的媒体数据包的
长度（以字节为单位）的二进制和（逐位异或），用一个网络序的16比特无符号整数表示。
在这里，媒体数据包的长度包括CSRC列表、扩展部分和填充的比特。这样即使在媒体数据包
长度不一致的情况下，也一样可以使用FEC。举个例子，假定要用两个媒体数据包的异或来
产生一个FEC包，这两个媒体数据包的长度分别为3（0b011）和5（0b101）个字节，那么长
度恢复域的值就是0b011 xor 0b101 = 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 填充位 （1比特）
      o 扩展位 （1比特）
      o CC （4比特）
      o 标记位 （1比特）
      o 荷载类型 （7比特）
      o 时间戳 （32比特）
      o 长度恢复域的值 （网络次序16比特无符号整数），也就是各个媒体数据包的荷载
长度、CSRC列表长度以及填充比特长度的和异或的结果