自己尝试翻译，多多指教！
--------Translated by MoaKap
[RFC 3320] 信令压缩(SigComp)（一）
摘要
本文定义了信令压缩（SigComp），一种压缩应用层协议（如SIP、RTSP）消息的方案。文中给出了SigComp的体系框架、压缩条件以及SigComp消息的格式。
UDVM（通用解压缩虚拟机）提供了解压功能，对解压缩算法的运行进行了优化。UDVM能够配置检测到多种著名的压缩机的输出，例如DEFAULT（RFC1951）。
目录
1． 引言
2． 术语
3． SigComp框架
4． SigComp调度机
5． SigComp压缩机
6． SigComp状态管理机
7． SigComp消息格式
8． UDVM概述
9． UDVM指令设置
10． 安全考虑
1． 引言
在多媒体通信中使用的很多应用层协议都是基于文本的，面向宽带连接的，因此，其消息体没有针对消息大小的优化措施。例如，典型的SIP消息大小一般在几百字结到2000字节，甚至更多。
随着这些协议在2.5G、3G无线领域切换过程中的使用，巨大的消息体给通信带来了不少问题。在低速的IP连接中传输的时延显得极为重要。考虑到消息的重传，在一些消息流中要使用多样化的消息，这样呼叫建立以及呼叫质量的提升受到严重影响。SigComp提供了一种对应用层消息进行高效无损压缩的机制来减轻这个问题。
本文提出了SigComp的体系结构和条件，SigComp消息格式以及完成解压缩功能的UDVM（通用解压缩虚拟机）。
SigComp作为介于应用层和下部传输层之间的一层提出，提供对下部传输层数据的压缩。SigComp支持多种传输协议，包括TCP、UDP以及SCTP（RFC2960）。
2． 术语
应用
激活SigComp的实体，同时完成以下功能：
1 向压缩调度机提供应用消息；
2 从解压缩调度机接收解压缩后的消息；
3 决定解压后消息间的间隔；
字节码
能够被虚拟机执行的机器码
压缩机
使用特定压缩算法对应用层消息进行编码的实体，同时跟踪压缩的状态变化。压缩机负责确保其输出的消息能够被远端UDVM解压缩。
压缩调度机
接收应用层消息，激活压缩机，同时将SigComp压缩后的消息前送至远端。
UDVM循环周期
用来执行一条UDVM指令的一系列操作（最简单的UDVM指令需要一个UDVM循环周期）。
解压缩调度机
接收SigComp消息，激活UDVM同时将解压缩后的消息送至特定应用。
终端
一个应用实例，SigComp层、传输层的组合。
基于消息的传输
传输携带的数据为一组消息，以消息为单位传输。
间隔
间隔标识
SigComp
整个压缩方案，包括压缩机、UDVM、调度机和状态控制器。
SigComp消息
从压缩调度机到解压缩调度机的消息。在基于消息传输中，SigComp消息对应一个确切的消息报。在基于流的传输中，SigComp被保留的分隔符分开。
基于流的传输
携带数据进行不间断的流传输，无消息边界。
传输
在两个终端间数据的传送。
UDVM通用解压缩虚拟机
UDVM用来解压缩SigComp消息。
状态
存储的数据，通过后续的SigComp消息来恢复。
状态控制器
状态标识
3． SigComp体系结构
在SigComp结构中，压缩与解压缩在两个不同的通信终端完成。图1给出了单独的终端布局。
图1 SigComp终端的上层框架
注意，由于SigComp是作为应用层与传输层的中间层提供给具体应用的，因此，图1描述的SigComp是从传输层的角度来看的。然而如果从多跳应用层协议的角度来看，SigComp适用于每一跳。
SigComp层由下边一系列功能实体组成：
1． 压缩调度机—应用与SigComp层的交互接口。应用层向压缩调度机提供应用消息以及消息间间隔，由压缩调度机来选择激活具体的压缩机完成压缩功能，然后将压缩后的SigComp消息发送至远程终端。
2． 解压缩调度机—SigComp与应用的交互接口。解压缩调度机接收到SigComp消息后激活具体的UDVM进行解压缩，然后将解压后的消息送至应用层，如果应用层允许将该消息的状态信息保存，则回复一个间隔标识符。
3． 一个或多个压缩处理器—将应用消息转化为SigComp消息的功能实体。根据应用提供的消息间隔标识的不同，不同的压缩机将会被激活。压缩机从压缩调度机接收应用消息，压缩完成后向压缩调度机返回SigComp消息。每个压缩机会选择一种特定的压缩算法来对数据进行编码。
4． UDVM—完成SigComp消息解压缩的功能实体。在解压缩过程中UDVM能够触发状态控制器来控制当前状态或产生新的状态。
5． 状态控制器—能够存储状态和获得新状态的功能实体。状态是为避免相邻消息重复上载数据而保留的两个SigComp消息之间的信息。安全起见，在应用允许的情况下，只能创建新状态。状态的创建和恢复将在第6节进一步介绍。
当要压缩一个双向传输的应用协议，在两个方向上可以选择独立的SigComp，且这两个方向上的压缩互不影响。两个通信终端发送SigComp消息时，在每个方向上甚至可以使用不同的压缩算法。
由于SigComp结构的设计避免了不同中断消息之间的相互影响，一个SigComp中断能够解压来自同一个网络不同位置的不同终端发来的消息。这样可以避免在传输层的错误压缩消息破坏整个SigComp的执行。
3.1 应用需求
从应用层的角度来看，SigComp层作为一个新的传输层出现，其行为与原始的传输未压缩数据的传输层相似。
如何检测终端对SigComp的支持不在本文讨论范围内。
所有的SigComp消息包含一个前缀（1111 1000），这个前缀在UTF-8文本中不会出现。因此，在同一端口可以根据这个前缀来判断是应用消息还是SigComp消息。当然，应用也可以为SigComp预留新的端口。
未完待续。。。