低速串行链路下IP/UDP/RTP数据包头的压缩( 三 )


器在实现时可以对这些字段使用哈希函数来检索存储的会话环境列表 。压缩包携带一个称为
会话环境标识符或者CID的小整数来指示该包应该解释到哪个环境中 。解压方可以使用CID
直接在存储的环境列表中来进行检索 。
由于RTP压缩是无损压缩,它可应用于任何可从中受益的UDP通信 。当然最可能的例子就
是RTP包,不过也可以使用试探法来判定一个包是否为RTP包,因为即便试探法给出的答案是
错的也不会造成什么损害 。这样做需要对所有的UDP包或者至少对偶数端口号的包(见3.4节)
执行压缩算法 。
为了避免将来无谓地重试,大多数压缩器在实现时都要维护包流的一个“拒绝缓存”来
记录那些多次作为RTP包尝试而压缩失败的包 。压缩失败往往意味着潜在的RTP包头中一些在
多数时间应保持恒定字段却发生了变化,如负载类型字段 。即便其它类似的字段都保持不变,
为了避免耗尽所有的可用会话环境,一个SSRC字段不断改变的包流也应放入拒绝缓存 。拒绝
缓存可通过源IP地址和目的IP地址以及UDP端口对进行索引,而SSRC字段因为可能发生变化
不能用来作为索引 。当RTP压缩失败,IP和UDP头仍然可以被压缩 。分片后不是初始片的IP
包和长度不够容纳一个完整UDP头的包都不能作为FULL_HEADER发送 。另外,没有容纳至少12
字节UDP数据的包也不能用于创建RTP环境 。假如这样的包作为FULL_HEADER包发送,它后面
可以跟随COMPRESSED_UDP包但不能跟随COMPRESSED_RTP包 。
3.2RTP数据包头压缩
在IPv4包头中只有总长度,包ID和校验和字段会发生改变 。因为在链路层已经提供了长
度,这里总长度是冗余的,同时由于本压缩方案必须依靠链路层实现良好的错误检测(如PPP
的CRC[4]),头校验和也可以省略掉 。于是只剩下了包ID,而在假定没有IP分片的情况下它
也无参加通信 。不过为了保持无损压缩,包ID的变化也将被传输 。对每个包而言,包ID通常
每次加1或者一个很小的整数值 。(有些系统中包ID的增量为交换的字节数,这对压缩效率
有一些稍微的影响 。)而IPv6包头既没有包ID字段,也没有头校验和字段,只有负载长度字
段会发生变化 。
由于在IP层和链路层均有相应字段,UDP头中的长度字段也是冗余的 。假如选择不产生UDP
校验和则UDP的校验和字段为常数0 。否则必须对校验和进行交互通信以保证无损压缩 。一个
重要原则就是为需要的应用程序维护端到端的错误检测 。
在RTP头中,作为特定环境标识的一部分,给定的环境的SSRC标识符是恒定不变的 。对大
多数包而言,只有顺序号和时间戳是因包而异的 。假如没有包丢失或者乱序,顺序号应按步
进值1逐包改变 。对音频包,时间戳应按采样周期增加 。对于视频,时间戳在每帧的第一个
包是发生改变,而在后面该帧的其它包中保持不变 。假如每个视频帧只占据一个包,且视频
帧按照恒定的速率产生,则帧与帧之间时间戳的变化也是恒定的 。
注重到每当这种情况出现,顺序号和时间戳字段的二次差分均为0,所以下一个包头的相应
字段值可通过前一个未压缩包头的该字段加上存在会话环境一次差分值得到 。当二次差分不
为0时,变化量通常也要远小于字段中所有位的数目,所以可通过对新的一次差分进行编码
并传输该编码来达到压缩的目的,不用传输绝对值 。
一个音频会话峰(talkspurt)中M位将在第一个包中设置,而一个视频帧中M位在最后一个

推荐阅读