变 。因此为了避免当SSRC字段改变时用光环境槽,很有必要明了这些非RTP的UDP包流(由于
该字段是用来标识特定RTP环境的一部分) 。每一个这样的流都可以拥有一个环境,但编码
器只在环境中设置一个标志来表示SSRC字段的变化可被忽略,且将发送COMPRESSED_UDP包而
非COMPRESSED_RTP包 。
4.与分片的交互
为了减少延迟,在连接RTP头时使用分片的方法对大的非实时包进行分割,以便答应小的
实时包能利用分割间隙进行发送 。由于这样的交错发送会改变解压器的接收到的包顺序,导
致错误出现,我们在此均假定这些大数据包对于压缩器到解压器的通道是旁路的 。头压缩对
大数据包而言并不重要,因为其开销所占比重较小 。
假如有些来自RTP会话环境的包被选中参加分片(主要取决于大小),而另一些不参加分
片,则可能造成乱序的现象出现 。这将导致压缩效率的下降,因为在顺序空间中这些被分割
的大包会被当作是丢失 。但是,由于RTP顺序号将在接收方被正确重建且答应应用程序进行
重排序,所以暂时的乱序也不会造成过于严重的问题 。就象链路层自己能检测到的链路错误
一样,分片机制使用顺序信息检测到的链路错误可以通过一个CONTEXT_STATE消息指示给压
缩器 。
环境ID字节位于COMPRESSED_RTP头的最前面,假如这样可行并经过协商,可以把该字节
分派给分片层 。由于压缩器可以强制分配环境ID,其值可设置为和分片层中的环境标识符一
致 。
5.压缩协商
在特定链路上使用IP/UDP/RTP压缩属于链路层协议的功能 。所以要为具体协议单独定义
协商方式,如为PPP[4] 。下面是可能要协商的项:
? 环境ID的大小 。
? 环境中包头栈的最大值 。
? 一个对delta值解码的环境相关表 。
6.致谢
很多朋友都为本压缩方案的设计和相关问题的解决付出了努力 。1996年3月,Scott
Petrack在落山矶的AVT工作组发起了关于RTP头压缩的讨论 。CarstenBormann开发了低速链
路上带传输控制的压缩体系结构,同时对于本文描述的方案也作出了一些非凡贡献 。David
Oran独立开发了一个基于本文类似思想的Note,并建议使用PPP多链路协议进行分片 。Mikael
Degermark在把本方案同IPv6压缩框架进行集成方面作出了贡献 。
7.参考文献
[1]Schulzrinne,H.,Casner,S.,Frederick,R.andV.Jacobson,"RTP:
ATransportProtocolforreal-timeapplications",RFC1889,
January1996.
[2]Jacobson,V.,"TCP/IPCompressionforLow-SpeedSerialLinks",
RFC1144,February1990.
[3]Degermark,M.,Nordgren,B.andS.Pink,"HeaderCompressionfor
IPv6",RFC2507,February1999.
[4]Simpson,W.,"ThePoint-to-PointProtocol(PPP)",STD51,RFC
1661,July1994.
[5]Hoffman,D.,Fernando,G.,Goyal,V.andM.Civanlar,"RTP
PayloadFormatforMPEG1/MPEG2Video",RFC2250,January1998.
8.安全性考虑
由于加密会消除本压缩方案所试图实现的冗余性,所以为了在低带宽链路上完成操作我们考
虑可能要放弃加密 。不过对于那些需要压缩数据而不是包头的情况,RTP已经规定了另一种可选
的加密方法,它只压缩RTP负载而将包头保持明文 。这样压缩依然可以使用 。
一个有问题的或是恶意的压缩器可能使解压器重组的包同原始包不一致却有有效的IP,IDP,
RTP头,甚至有效的UDP校验和 。这样的破坏可通过端到端认证和完整性机制(它不会受到压缩的
影响)检测出来 。认证头中的恒定部分可通过[3]所描述的方法进行压缩 。
本协议在发送CONTEXT_STATE控制包时没有执行任何认证 。有权访问压缩器和解压器之间链路
推荐阅读
- PPP协议:关于在点到点链路上进行多协议包传送的建议
- PPP会话终结
- PPP链路工作过程
- PPP链路操作
- 2 低速串行链路上的TCPIP头部压缩
- 2 TCP/IP详解学习笔记-数据链路层(编写中)
- PPP 链路质量监控
- BGP协议建立连接及使用ISDN备份卫星链路
- 在串行线路上传输IP数据报的非标准协议
- 串行线路IP 尾部封装和SLIP
