引航李老师吐血推荐：CRTP技术详解

摘要CRTP技术是报文压缩的一种技术，通过将普通IP+UDP+RTP报文压缩成小字节报文，可以极大的降低使用带宽。
前言语音数据包封装成IP格式后，其实也就添加了UDP、IP和RTP（实时传输协议）的三个报头。通常，一个语音数据包会包括20个字节的语音载荷流量和40个字节的这三个报头(采用G.729，20ms打包周期)，这样就不利于充分发挥网络的利用效率。所幸，40个字节的报头信息可以利用压缩RTP（CRTP）“压缩”成2～4个字节。因为对每个信息流而言，这些报头里面的变化其实非常小。这显然提高了数据传输效率，并且可以把G.729a呼叫（8K语音）所需的带宽从24Kbps减小到12K～14Kbps左右。
简介IP包头过长是影响其在语音网络中应用的一个重要问题，解决这一问题的方案是采用头部压缩技术CRTP（RFC2508，低速串行链路下IP／UDP／RTP数据包头的压缩）。

CRTP的主要设计目标是在不发送UDP校验和的情况下，将大多数包的IP/UDP/RTP头压缩到2个字节，在带校验和时则压缩到4个字节。这一方案的提出主要是受使用14.4kb/s和28.8kb/s拨号调制解调器发送音视频时遇到的相关问题所引起。这些链路提供全双工通信，所以协议利用了这点，尽管协议在用于单工链路时可能性能会有所下降。该方案在本地链路上往返时间(RTT)很低，从而实现性能最大化。
技术原理头部压缩技术的原理是：语音编码器生成的语音数据被逐层封装成RTP，UDP和IP包。这样的语音帧头部长度达到40个字节，但是有效载荷只有15～30个字节。这样对于一个相同的语音流来说，在连续的语音包中就有较高的冗余度。要降低这种冗余，必须使用压缩算法。CRTP可以将40字节的包头最小压缩至2字节。若用CRTP进行头部压缩，必须维护上下文信息（Context，即未压缩的在通路两端上一次发送的包头），这样，头部仅仅携带上下文信息的变化即可。但是如果发生丢包或包被损坏，接收端就无法正确地更新上下文信息。所以必须提供相应的机制去监测上下文错误并去修复它。CRTP可以发送上下文更新请求来修复上下文，但是链路上的往返时间会影响这种修复机制的效率。下图就是这种压缩标准的一个示意图。




一般来说，IP/UDP/RTP头中有一半的字节在整个连接期间保持不变，尽管每个包中总有几个字节要发生变化，但包与包之间的区别却是恒定的，也就是说二次差分为0。因此，可以在发送一次未压缩头之后，将未变化的字段从其后的压缩头中除去。其余的压缩内容来自变化字段，可以对变化的字段进行区分编码以减少压缩后的长度，以及在通常情况下根据包长度计算变化而完全删除掉的变化字段，在会话期间，这一长度由链路层协议指示。通过维护压缩与解压设备共享的未压缩头与一次差分序列，所需通信的便只有二次差分为0的指示了。在这种情况下，如果不考虑任何信息丢失，则解压设备在收到一个压缩包后可以通过将一次差分结果加到保存的未压缩头来重建原始包头。像TCP/IP头压缩为多个同时的TCP连接维护一个共享状态一样，IP/UDP/RTP压缩也应该为多个会话环境维护状态。一个会话环境是由IP源地址和目的地址、UDP源端口和目的端口、以及RTP的SSRC字段定义。解压设备可实时的对这些字段使用哈希函数来检索存储的会话环境列表。压缩包携带一个称为会话环境标识符或者CID的小整数来指示该包应该解压到哪个环境中。解压方可以使用CID直接在存储的环境列表中来进行检索。由于RTP压缩是无损压缩，它可应用于任何可从中受益的UDP通信。当然最可能的例子就是RTP包，不过也可以使用试探法来判断一个包是否为RTP包，因为即便试探法给出的答案是错的也不会造成什么损害。这样做需要对所有的UDP包执行压缩算法。

为了避免将来无谓地重试，大多数压缩设备在实现时都要维护数据流的一个“拒绝缓存”来记录那些多次作为RTP包尝试而压缩失败的包。压缩失败往往意味着潜在的RTP包头中一些在多数时间应保持恒定字段却发生了变化，如负载类型字段。即便其它类似的字段都保持不变，为了避免耗尽所有的可用会话环境，一个SSRC字段不断改变的包流也应放入拒绝缓存。拒绝缓存可通过源IP地址和目的IP地址以及UDP端口对进行索引，而SSRC字段因为可能发生变化不能用来作为索引。当RTP压缩失败，IP和UDP头仍然可以被压缩。分片后不是初始片的IP包和长度不够容纳一个完整UDP头的包都不能作为FULL_HEADER发送。另外，没有容纳至少12字节UDP数据的包也不能用于创建RTP环境。如果这样的包作为FULL_HEADER包发送，它后面可以跟随COMPRESSED_UDP包，但不能跟随COMPRESSED_RTP包。
压缩字段在IPv4包头中只有总长度，包ID和校验和字段会发生改变。因为在链路层已经提供了长度，这里总长度是冗余的，同时由于CRTP必须依靠链路层实现良好的错误检测（如PPP的CRC），头校验和也可以省略掉。于是只剩下了包ID，而在假定没有IP分片的情况下它也不参加通信。不过为了保持无损压缩，包ID的变化也将被传输。对每个包而言，包ID通常每次加1或者一个很小的整数值。
由于在IP层和链路层均有相应字段，UDP头中的长度字段也是冗余的。如果选择不产生UDP校验和则UDP的校验和字段为常数0。否则必须对校验和进行交互通信以保证无损压缩。一个重要原则就是为需要的应用程序维护端到端的错误检测。
在RTP头中，作为特定环境标识的一部分，给定的环境的SSRC标识符是恒定不变的。对大多数包而言，只有顺序号和时间戳是因包而异的。如果没有包丢失或者乱序，顺序号应按步进值1逐包改变。对音频包，时间戳应按采样周期增加。对于视频，时间戳在每帧的第一个包是发生改变，而在后面该帧的其它包中保持不变。如果每个视频帧只占据一个包，且视频帧按照恒定的速率产生，则帧与帧之间时间戳的变化也是恒定的。注意到每当这种情况出现，顺序号和时间戳字段的二次差分均为0，所以下一个包头的相应字段值可通过前一个未压缩包头的该字段加上存在会话环境一次差分值得到。当二次差分不为0时，变化量通常也要远小于字段中所有位的数目，所以可通过对新的一次差分进行编码并传输该编码来达到压缩的目的，不用传输绝对值。

一个音频会话峰(talkspurt)中M位将在第一个包中设置，而一个视频帧中M位在最后一个包中设置。如果它作为一个常量字段则每次变化都要发送整个RTP头，如此会造成压缩效率明显下降。因此，压缩头中的一位将明确地携带M位。如果包通过RTP混合器流动，特别是音频数据，则CSRC列表和CC记数将发生改变。但CSRC列表将在会话峰期间保持不变，所以它只需在发生变化时才发送。
压缩协议压缩协议必须维护一个状态牢靠的压缩方和解压方的共享信息集合。对每个IP/UDP/RTP报文流有一个单独的通过源地址IP、目的地址IP、UDP端口对和RTP SSRC字段组合定义的会话环境。要维护的会话环境数目可通过双方协商而定。每个环境通过一个8位或者16位的标识符来标识，具体范围要根据协商的环境数量决定，所以最大值为65536。未压缩和压缩的包都必须携带环境ID和一个4位的用来检测包通信中丢失的顺序号。每个环境都有自己的顺序号空间，所以单个包的丢失只会影响到一个环境。
每个环境共享的信息包括如下项目：
l
完整的IP, UDP和RTP头，对最后一个由压缩方发送或者解压方重建的包，可能还包括CSRC表。
l
IPv4 ID字段的一次差分结果，当收到环境中的一个未压缩IP头时初始化为1，每次收到一个压缩包中的delta IPv4 ID字段时更新。
l
RTP时间戳字段的一次差分结果，当收到环境中的一个未压缩IP头时初始化为0，每次收到一个压缩包中的delta RTP时间戳字段时更新。
l
最后一个4位顺序号，用来检测双方通信时的包丢失情况。
l
IPv6 UDP包的非差分编码当前产生号。对于IPv4，如果没有使用下面定义的COMPRESSED_NON_TCP包类型，则产生号可设置为0。
l
一个经过双方协商，可选的环境相关的delta编码表。

为了在不同的压缩和解压方之间进行通信，本协议依靠链路层为除IP包外的四种新的包格式提供指示：
FULL_HEADER – 传送未压缩IP头和任何用来在解压方为特定环境建立未压缩头部状态的后续头和数据。FULL_HEADER包也携带了8或16位的会话环境标识符和4位的顺序号用来建立双方的同步。
COMPRESSED_UDP – 传送压缩到6字节或更少字节(如禁用UDP校验和则通常为2字节)的IP和UDP头，后面是任何未压缩形式的后续头(可能为RTP)和数据。当RTP头的常量字段有所不同时才使用包类型。RTP包头包括一个会变化的SSRC字段值，所以可能重定义会话环境。
COMPRESSED_RTP – 表示RTP头和IP及UDP头一起压缩。该头的大小可以是2个字节，或者当需要传送变化时更多一些。当二次差分值(至少在通常的常量字段)为0时使用包类型。它包括delta编码，它是为了能在未压缩RTP头发送后并当改变发生时对于那些变化字段建立一次差分队列。
CONTEXT_STATE – 一种由解压方发送给压缩方的特殊包，用来传输已经或者可能已经失去同步的环境ID。该包仅通过点到点链路发送，所以它不需要IP头。
总结压缩RTP（CRTP）技术可以减小IP、UDP、RTP的包头大小，极大的节省了带宽，提高了传输效率。许多路由器在低速链路上已经支持了该项技术，并且可以达到线速转发，对转发性能和时延几乎没有什么影响。在带宽资源紧张的环境中可以部署CRTP。