rfc2733.txt

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

   |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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      版本:      2
      填充位:    0
      扩展位:    0
      标记位:    1
      PTI:       18
      SN:        9
      TS:        5
      SSRC:      2

图 4: 媒体包y的RTP头

   由这两个包生成一个FEC包。我们假定用荷载类型值127来指示一个FEC包。得到的FEC
包的RTP包头如图5所示。
   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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      版本:      2
      填充位:    0
      扩展位:    0
      标记位:    1
      PTI:       127
      SN:        1
      TS:        5
      SSRC:      2
图 5: x,y的FEC包的RTP头

   FEC包的FEC头如图6所示。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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基数:    8    [min(8,9)]
      长度恢复域: 1    [8 xor 9]
      E:          0
      PTI恢复域:  25   [11 xor 18]
      mask:      3
      TS恢复域:   6    [3 xor 5]
      荷载长度为11个字节
图6: FEC包的FEC头
10 冗余编码中使用FEC的用法
   我们可以把一个FEC包看成是对媒体的一个冗余编码（redundant encoding）。这样一来，
[5]中所描述的冗余音频数据的荷载格式就可以用于FEC数据的打包。这个过程如下所述：
上面的FEC操作作用于一个RTP媒体数据包组成的流上。这个流也就是RFC2198[5]中进
行封装之前的流。换句话说，将待保护的媒体数据流封装在标准的RTP媒体包中，然后进行
前面定义过的FEC操作（有一点小的改动），生成一个FEC数据包的流。这里与前面不同的
一点在于：在进行FEC操作之前，必须把待保护的RTP媒体数据包的RTP头扩展、填充部分
以及CSRC列表去掉，并且CC域、填充位、扩展位必须设置为零，用这些修改之后的RTP媒
体数据包去生成FEC包。需要注意的是发送端要发送出去的仍然是原来没有修改的媒体数据
包，只是在计算FEC包的时候才去除掉这些域。
一旦生成了FEC包，将媒体数据包中的荷载提取出来，作为RFC2198中定义的主编码
（primary encoding），将FEC包中的FEC头和荷载提取出来，作为RFC2198中定义的冗余
编码（redundant encoding）。除了FEC之外，还可以向包中加入额外的冗余编码，但这些
信息不受FEC的保护。
主编码（primary codec）的冗余编码头（redundant encodings header）按照RFC2198
中的定义进行设置。下面给出FEC数据的冗余编码头的设置。块荷载类型域（block PT）设
置为与FEC格式相关联的动态PT值，块长度设置为FEC头和FEC荷载的长度之和。时间戳偏
移（timestamp offset）应当设置为0。次编码（secondary codec）的荷载包括FEC头和FEC
荷载。
在接收端，主编码和所有的次编码都作为不同的RTP包提取出来。这是通过把冗余编码
包中的RTP头的次序号、SSRC、标记位、CC域、RTP版本号和扩展位等拷贝到每一个提取出
的包的RTP头中去。如果次编码中包含FEC，FEC包的RTP头中的CC域、扩展位、填充位都
必须设置为零。提取出的包的荷载类型码是从冗余编码头中的块荷载类型域复制过来。提取
出的包的时间戳是RTP头中的时间戳与块头中的时间戳偏移之差。提取包的荷载就是块中的
数据部分。这样一来，FEC流和媒体数据流就被分别提取出来了。
要利用FEC包和已接收到的媒体数据包来恢复丢失的包，必须把媒体数据包中的CSRC列
表、扩展头、填充部分去掉，并把CC域，扩展位、填充位都设置为零。用这些修改之后的媒
体包，加上FEC包，基于第8节中的步骤，就可以恢复出丢失的包。恢复出的包将肯定没有
扩展部分、填充部分和CSRC列表部分。在具体实现中，如果其它包中存在这些部分，可以从
其它包中将这些部分拷贝过来。
使用冗余编码的荷载格式，有可能不能正确恢复出标记位。在使用RFC2198来进行FEC
封装的应用程序中，必须把恢复出的媒体数据包的标记位设置为零。
相对于发送完整的FEC包，这种方法的优点在于它能够减少overhead。
11 在SDP中表示FEC
FEC包的RTP荷载类型值是一个动态类型值。FEC包可以发到与媒体包不同的多播组或者
不同的端口。如果使用[5]中定义的冗余编码荷载格式，FEC数据甚至可以放在媒体包中一起
传输。这些配置选项必须在带外明确指示出来。这一节讲述如何用RFC2327[6]中定义的会话
描述协议（Session Description Protocol, SDP）来完成这一工作。
11.1 FEC作为独立的流传输
在第一种情况中，FEC包是作为一个独立的流来进行传输的。这可能意味着它们被发往
与媒体包不同的端口或不同的多播组。这时，必须传达以下几条消息：
        o FEC包被发往的地址和端口
        o FEC包的荷载类型号
        o 它保护的是哪个媒体数据流
FEC的荷载类型号是在它所保护的媒体的m行（译者注：媒体描述行，media description 
line，见RFC2327）中传送的。由于没有为FEC分配静态的荷载类型值，因此必须使用动态
的荷载类型值。这个值的绑定是通过一个rtpmap属性来指示的，绑定中所使用的名称
为"parityfec"。
FEC的荷载类型号出现在它所保护的媒体的m行中并不意味着FEC包要发送到相同的地
址和端口。事实上，FEC包的端口和地址信息是通过fmtp属性行来传递的。在媒体的m行中
出现FEC荷载类型指示为了指出FEC保护的是哪个媒体流。
FEC的fmtp行的格式如下所示：
   a=fmtp:<荷载类型号> <端口> <网络类型> <地址类型> <连接地址>
其中“荷载类型号”就是在m行中出现的荷载类型号。“端口”是FEC包将要发送的端
口。其余的三项，网络类型，地址类型和连接地址与SDP的c行中的语法语义是相同的。这
样fmtp行可以部分地用与c行相同的解析器来进行解析。需要注意的是由于FEC不能够分级
编码，<地址数量（number of addresses）>参数必须不出现在连接地址中。
下面是一个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
在上面的SDP描述中出现两个m行是因为其中存在两个媒体流，一个音频流和一个视频
流。媒体格式为0代表用PCM编码的音频，它被荷载类型号为78的FEC流保护。FEC流被发
往与音频相同的多播组，TTL参数也相同，但端口号大2（49172）。视频流被荷载类型号为
79的FEC流保护，这个FEC流的端口号是一样的，但是多播地址不一样。
11.2在冗余编码中使用FEC
当FEC流以冗余编码格式作为一个次编码来发送的时候，必须通过SDP通知对方。为了
做到这一点，使用RFC2198中定义的步骤来通知对方使用了冗余编码。FEC的荷载类型就象
其它任意一个次编码那样表示出来。必须用一个rtpmap属性行来指示出FEC包的动态荷载类
型号。FEC必须只保护主编码。这时，FEC的fmtp属性必须不出现。
   举个例子:
   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
这个SDP例子指示有一个单一的音频流，由PCM格式（媒体格式0）和DVI格式（媒体
格式5）组成，一个冗余编码（用媒体格式121表示，在rtpmap属性中绑定为red），以及
一个FEC（媒体格式100，在rtpmap属性中绑定为parityfec）。尽管FEC格式是作为媒体
流的一个可能编码来描述的，但它必须不单独传送。它出现在m行中只是因为按照RFC2198，
非主编码（non-primary codec）都必须在这里列出来。fmtp属性指出冗余编码格式可以这
样使用：DVI作为一个次编码（secondary coding），而FEC作为第三编码（tertiary encoding）。
11.3 在RTSP中的用法
RTSP[7]可以用来请求将FEC包作为一个独立的流进行传输。当在RTSP中使用SDP时，
每个流的会话描述中并不包含连接地址和端口号。作为代替，RTSP使用了控制URL（Control 
URL）的概念。SDP中以两种不同的方式来使用控制URL。
1.   所有的流使用一个控制URL。这被称为“集中控制”。在这种情况下，FEC流的fmtp
行被省略了。
2.   每一个流都有一个控制URL。这被称为“非集中控制”。在这种情况下，FEC流的
fmtp行指定它的控制URL。这个URL可以被用在RTSP客户端的SETUP命令中。
非集中控制的FEC流用RTSP时，它的fmtp行的格式为：
   a=fmtp:<荷载类型号> <控制URL>
其中荷载类型号就是出现在m行中的荷载类型号。控制URL就是用于控制这个FEC流的
URL。
需要注意的是控制URL并不一定是一个绝对URL。将一个相对的控制URL转化为一个绝
对的控制URL的规则在RFC2326的C.1.1中给出。
12 安全性问题
使用FEC对于加密时密钥的用法和更改有一定的影响。由于FEC包组成了一个独立的流，
在加密的用法上可以有几种不同的排列组合：
     o 可以对FEC流加密，而不对媒体流加密
     o 可以对媒体流加密，而不对FEC流加密
     o 可以对媒体流和FEC流同时加密，但使用不同的密钥
     o 可以对媒体流和FEC流同时加密，但使用相同的密钥
前面三种要求应用层的信令协议知道使用了FEC，并因此对媒体流和FEC流分别进行用
法协商，并分别交换密钥。在最后一种情况里，并不需要有这些机制，只要想对待媒体包一
样去对待FEC包就可以了。前面两种情况可能会引起分层冲突，因为实际上不应该将FEC包
与其它媒体包区别对待，并且只对其中一个流加密会带来明文攻击的危险。出于这些考虑，
使用了加密的应用就应当对两个流都进行加密。
然而，在密钥的变更中会出现一些问题。例如，如果发送了两个数据包a和b，还有一
个FEC包f(a,b)。如果a和b所使用的密钥是不同的，那么应该用哪一个密钥来解密f(a,b)？
一般说来，用过的密钥都会被缓存起来，这样当媒体流的密钥更改之后，旧的密钥被保留下
来备用，直到它发现FEC包的密钥也发生更改了。
使用FEC的另一个问题是它对于网络拥塞的影响。面对网络丢包越来越多的情况加入FEC
不是一个好办法，它可能会导致拥塞更加严重并最终崩溃。因此，实现者在网络丢包增加的
情况下必须不大量增加FEC冗余数据，以保证整个网络的性能。
13 致谢
这份方案是基于Budge和Mackenzie于1997年提交的一个早期FEC草案，在此表示感谢。我
们感谢Steve Casner, Mark Handley, Orion Hodson 和 Colin Perkins对我们工作所提出
的批评和建议，并感谢Anders Klemets写了“在RTSP中的用法”这一节。
14 作者地址
   Jonathan Rosenberg
   dynamicsoft
   200 Executive Drive
   Suite 120
   West Orange, NJ 07046
   Email: [e-mail]

   Henning Schulzrinne
   Columbia University
   M/S 0401, 1214 Amsterdam Ave.
   New York, NY 10027-7003
   EMail: [e-mail]
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.
   [2] Perkins, C. and O. Hodson, "Options for Repair of Streaming
       media", RFC 2354, June 1998.
   [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
       A Transport Protocol for Real-Time Applications", RFC 1889,
       January 1996.
   [4] Bradner, S., "Key words for use in RFCs to indicate requirement
       levels", BCP 14, RFC 2119, March 1997.
   [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.
   [6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
       RFC 2327, April 1998.
   [7] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
       Protocol (RTSP)", RFC 2326, April 1998.
16.版权声明
   版权归Internet协会所有（1999）。保留所有权利。
   本文及其译本可以提供给其他任何人，可以准备继续进行注释，可以继续拷贝、出版、发
布，无论是全部还是部分，没有任何形式的限制，不过要在所有这样的拷贝和后续工作中提
供上述声明和本段文字。无论如何，本文档本身不可以做任何的修改，比如删除版权声明或
是关于Internet协会、其他的Internet组织的参考资料等。除了是为了开发Internet标准
的需要，或是需要把它翻译成除英语外的其他语言的时候，在这种情况下，在Internet标准
程序中的版权定义必须被附加其中。
   上面提到的有限授权允许永远不会被Internet协会或它的继承者或它的下属机构废除。
   本文档和包含在其中的信息以"As is"提供给读者，Internet社区和Internet工程任务
组不做任何担保、解释和暗示，包括该信息使用不破坏任何权利或者任何可商用性担保或特
定目的。

致谢
   Internet协会当前为RFC编辑提供了资助，对此表示感谢。

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


1
RFC文档中文翻译计划