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


包中设置 。假如它作为一个常量字段则每次变化都要发送整个RTP头,如此会造成压缩效率
明显下降 。因此,压缩头中的一位将明确地携带M位 。假如包通过RTP混合器流动,非凡是音
频数据,则CSRC列表和CC记数将发生改变 。但CSRC列表将在会话峰期间保持不变,所以它只
需在发生变化时才发送 。
3.3协议
压缩协议必须维护一个状态牢靠的压缩器和解压器的共享信息集合 。对每个IP/UDP/RTP
包流都有一个单独的通过源地址IP,目的地址IP,UDP端口对和RTPSSRC字段组合定义的会
话环境 。要维护的会话环境数目可通过双方协商而定 。每个环境通过一个8位或者16位的标
识符来标识,具体范围要根据协商的环境数量决定,所以最大值为65536 。未压缩和压缩的
包都必须携带环境ID和一个4位的用来检测包通信中丢失的顺序号 。每个环境都有自己的顺
序号空间,所以单个包的丢失只会影响到一个环境 。
每个环境共享的信息包括如下项目
? 完整的IP,UDP和RTP头,对最后一个由压缩器发送或者解压器重建的包,可能还
包括CSRC表 。
? IPv4ID字段的一次差分结果,当收到环境中的一个未压缩IP头时初始化为1,每
次收到一个压缩包中的deltaIPv4ID字段时更新 。
? RTP时间戳字段的一次差分结果,当收到环境中的一个未压缩IP头时初始化为0,
每次收到一个压缩包中的deltaRTP时间戳字段时更新 。
? 最后一个4位顺序号,用来检测双方通信时的包丢失情况 。
? IPv6(见[3])UDP包的非差分编码当前产生号 。对于IPv4,假如没有使用下面定
义的COMPRESSED_NON_TCP包类型,则产生号可设置为0 。
? 一个经过双方协商,可选的环境相关的delta编码表(见3.3.4节) 。
为了在不同的压缩和解压器形式下进行通信,本协议依靠链路层为除IPv4和IPv6外的四
种新的包格式提供指示:
FULL_HEADER–传送未压缩IP头和任何用来在解压方为特定环境建立未压缩头状态
的后续头和数据 。FULL_HEADER包也携带了8或16位的会话环境标识符和4位的顺序号用来建
立双方的同步 。格式见3.3.1节 。
COMPRESSED_UDP–传送压缩到6字节或更少字节(如禁用UDP校验和则通常为2字节)
的IP和UDP头,后面是任何未压缩形式的后续头(可能为RTP)和数据 。当RTP头的常量字段有
所不同时才使用包类型 。RTP包头包括一个会变化的SSRC字段值,所以可能重定义会话环境 。
其格式在3.3.3节定义 。
COMPRESSED_RTP–表示RTP头和IP及UDP头一起压缩 。该头的大小可以是2个字节,或
者当需要传送变化时更多一些 。当二次差分值(至少在通常的常量字段)为0时使用包类型 。
它包括delta编码,它是为了能在未压缩RTP头发送后并当改变发生时对于那些变化字段建立
一次差分队列 。其格式在3.3.2中定义 。
CONTEXT_STATE–一种由解压器发送给压缩器的非凡包,用来传输已经或者可能已经
失去同步的环境ID 。该包仅通过点到点链路发送,所以它不需要IP头 。其格式在3.3.5中定
义 。
当本压缩方案作为通用头压缩框架[3]的一部分用于IPv6时,还可使用另一种包类型:
COMPRESSED_NON_TCP–无须进行差分编码传输[3]定义的压缩IP/UDP包 。假如用于
IPv4,为了能携带IPv4ID字段,它比前面所讲的COMPRESSED_UDP要多用1到2个字节 。而IPv6
没有ID字段,这种非差分压缩在包丢失时更有弹性 。
在PPP协议[4]中为这些包格式分配代码应由IANA决定 。
3.3.1.FULL_HEADER(未压缩)包格式
此处定义的FULL_HEADER和[3]中所给出的定义是一致的 。在那里有关于各种方案的

推荐阅读