rfc2198.txt

RFC文档

                      0 1 2 3 4 5 6 7
                     +-+-+-+-+-+-+-+-+
                     |0|   Block PT  |
                     +-+-+-+-+-+-+-+-+
   最后一个头之后就是数据块，存储顺序和头的排列顺序相同。数据块之间不需要填充或
者使用其它分隔，一般不需要32位对齐。如此选择仍是为了在损失一定额外解码时间的情况
下降低带宽负担。
   编码的选择应该反映其对带宽的需求。冗余编码所占带宽应远远小于主编码所占带宽：
然而该原则也有些例外，即如果主编码本身带宽就很小，且需要很高的处理能力，则往往使
用主编码的拷贝来作为冗余。即便如此，冗余编码绝不能比主编码的所占带宽高。
   一般情况下没必要使用多级冗余。在某些需要多级冗余情况下，每层的带宽需求都要明
显低于前一级。
4. 局限性
   RTP标志位并非是为冗余数据块而保留的。因此，如果主数据丢失（其中包括标志位），
则标志位也会同时丢失。但我们认为它并不会造成什么大麻烦：因为即使标志位同冗余信息
一起传输也有丢失的可能，所以在编写应用程序时应该充分考虑到这些。
   另外，CSRC信息也不是为冗余数据保留的。冗余音频包RTP头中CSRC数据只同主数据有关。
由于CSRC数据相对较少发生变化，因此我们建议需要此信息的应用程序可假定RTP头中的
CSRC数据能够用于重建冗余数据。
5. 同SDP的关系
   使用冗余负载时必须将其绑定到一个动态负载类型。这一过程可以通过带外机制来实现，
不过更通用一些的办法就是利用SDP[6]协议来进行关于绑定的通信。SDP定义了一套机制用
于将动态负载类型绑定到特定的编解码器、采样率、和多个使用"rtpmap"属性的通道。下面
就是一个使用RTP视听框架[3]的例子：
       m=audio 12345 RTP/AVP 121 0 5
       a=rtpmap:121 red/8000/1
   上例说明一个RTP音频流正在使用负载类型121（一个动态负载类型）,0（PCM u-law）和
5(DVI)。“rtpmap”属性用于将负载类型121绑定到编解码器"red"，表示该编解码器是一个
冗余帧，采样率8KHz，且是单声道的。当与SDP一同使用时，术语"red"表示本文中所讨论的
冗余格式。
   为此我们规定了PCM和DVI的附加格式。因此接收端必须为使用这些格式做好准备。这一
规定意味着在缺省情况下发送方可以发送冗余，也可以发送PCM或DVI。但对于冗余负载，我
们顺带提出这点意味着只能使用PCM或DVI作为冗余编解码。注意到"m="字段中的定义的附加
负载格式本身也可能是动态负载类型，而一旦如此，就需要一些附加属性"a="来描述这些动
态负载类型。
   接收一个冗余流所需的一切就是如此。不过要发送一个冗余流，发送方得知道建议使用
的主编码和第二编码（如tertiary）。该信息对于冗余格式是明确的，并通过使用附加属
性"fmtp"来指定,该属性传达了格式特定的信息。一个会话目录并不解析fmtp属性的值，而
仅仅是将它转交给媒体工具。为了冗余性，我们定义了RTP负载格式的格式参数列表，通过
斜线"/"分隔开。
   完整的例子如下：
       m=audio 12345 RTP/AVP 121 0 5
       a=rtpmap:121 red/8000/1
       a=fmtp:121 0/5
   上例说明发送方缺省模式为冗余，其中PCM作为主编码，而DVI作为第二编码。除非该编
码已在媒体行("m=")中指定为有效，否则不能在fmtp属性中指定编码。
 6. 安全性考虑
包含冗余数据的RTP包从属于RTP规范[2]以及任何适用的RTP框架（如[3]）所讨论的安
全性考虑。这意味着媒体流的安全性要通过加密来达到。对冗余数据进行加密可通过下面两
种方法实现： 
     1.对整个流进行加密，所有的参与者都必须拥有密钥才可进行解密。在这种情况下，
加密采用通常的方式来进行，无须什么特别的操作。
2.流的一部分和其余部分以不同的密钥进行加密。采用这种方式，最后一个包的冗余
拷贝就无法进行发送，因为已经没有后续包能采用正确的密钥进行加密。类似的限制也出现
于使能和禁止加密的过程中。
从两者中具体选择哪种方式进行加密是编码者的问题，而解码者应可以无须修改而对任
何一种形式进行解密。
音频流的低带宽冗余对于解决包丢失的保护问题是一种很有效的方法，与此同时，应用
设计者也应该注意到，大量冗余数据会造成网络拥塞的增加和加剧包丢失现象，这将使采用
冗余数据试图解决的包丢失问题变得更糟。在最极端的情况下，还会导致网络拥塞过度，甚
至形成拒绝服务攻击。
7. 示例
   一个RTP音频数据包，包括一个DVI4(8KHz)主编码块和一个单独的8KHz LPC编码的冗余
块，两者长度均为20ms。参照RTP视听框架[3]所定义，如下所示：
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X| CC=0  |M|      PT     |        主数据顺序号		   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       主编码时间戳					           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     同步源标识(SSRC)符		     			   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| block PT=7  |       时间戳偏移          |     块长度        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| block PT=5  |                                               |
   +-+-+-+-+-+-+-+-+                                               +
   |                                                               |
   +                LPC 编码冗余数据 (PT=7)                        +
   |                (14 bytes)                                     |
   +                                               +---------------+
   |                                               |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   |                                                               |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +                                                               +
   |                DVI4 编码主数据 (PT=5)                         |
   +                (84 bytes, not to scale)                       +
   /                                                               /
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +                                               +---------------+
   |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8. 作者地址
   Colin Perkins/Isidor Kouvelas/Orion Hodson/Vicky Hardman
   Department of Computer Science
   University College London
   London WC1E 6BT
   United Kingdom
   EMail:  {c.perkins|i.kouvelas|o.hodson|v.hardman}@cs.ucl.ac.uk
   Mark Handley
   USC Information Sciences Institute
   c/o MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, USA
   EMail:  [e-mail]
   Jean-Chrysostome Bolot/Andres Vega-Garcia/Sacha Fosse-Parisis
   INRIA Sophia Antipolis
   2004 Route des Lucioles, BP 93
   06902 Sophia Antipolis
   France
   EMail:  {bolot|avega|sfosse}@sophia.inria.fr
9. 参考文献
   [1] V.J. Hardman, M.A. Sasse, M. Handley and A. Watson; Reliable
   Audio for Use over the Internet; Proceedings INET'95, Honalulu, Oahu,
   Hawaii, September 1995.  http://www.isoc.org/in95prc/
   [2] Schulzrinne, H., Casner, S., Frederick R., and V. Jacobson, "RTP:
   A Transport Protocol for Real-Time Applications", RFC 1889, January
   1996.
   [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
   with Minimal Control", RFC 1890, January 1996.
   [4] M. Yajnik, J. Kurose and D. Towsley; Packet loss correlation in
   the MBone multicast network; IEEE Globecom Internet workshop, London,
   November 1996
   [5] J.-C. Bolot and A. Vega-Garcia; The case for FEC-based error
   control for packet audio in the Internet; ACM Multimedia Systems,
   1997
   [6] Handley, M., and V. Jacobson, "SDP: Session Description Protocol
   (draft 03.2)", Work in Progress.
   [7] Bradner, S., "Key words for use in RFCs to indicate requirement
   levels", RFC 2119, March 1997.
RFC2198  RTP Payload for Redundant Audio Data     用于冗余音频数据的RTP负载格式


1
RFC文档中文翻译计划