压缩SIP消息

信令压缩(SigComp)是一种被应用层协议用来在消息发送到网络之前对其进行压缩的机制。从应用的角度看，它是应用协议和传输协议之间的一层。SigComp使用通用解压缩虚拟机(UDVM)来对消息进行解压缩。图12-1给出了SigComp在协议栈中的位置。SigComp在［RFC3320］中定义。

使用SigComp压缩的消息被称为SigComp消息。

23.1 SigComp体系

SigComp体系可分为5个实体(见图23-1),这些实体如下所述:

图23-1 SigComp体系

• 压缩器调度员——这是应用和SigComp系统之间的接口。它调用一个压缩器，该压缩器由应用使用容器(compartment)标识符来指定。压缩器调度员将返回的压缩消息转发给其目的节点。

• 解压缩器调度员——这是SigComp系统和应用之间的接口。它调用UDVM来进行消息的解压缩，然后解压缩器调度员将解压的消息传递给应用。如果应用希望解压缩器保留消息的状态，则返回一个所谓的"容器标识符

• 压缩器——该实体对应用发出或收到的消息进行压缩。它使用由容器标识符来标识的容器，已压缩的消息传递给压缩器调度员。DEFLATE是压缩算法的―个例子。

• UDVM——该实体对压缩的消息进行解压缩。每个新的SigComp消息都会调用一个新的实例。UDVM使用状态处理器来为新消息创建状态或利用一个现有的状态。

• 状态处理器——保留存在于SigComp消息之间的信息（称为消息状态），可保存和恢复状态。

23.2 容器

像会话初始化协议(SIP）中的应用一样，应用可以将相关联的消息分成组。根据信令协议的不同，这个分组操作要依照协议进行消息关联的具体方法，例如，在sip中，通过使用对话来对消息分组，或在下一跳地址可配置的情况下，对具有相同下一跳地址的消息进行分组。应用给每个容器(compartment）分配一个压缩器，并分配状态内存来存储状态信息。它还决定什么时候创建或销毁一个容器。第容器用容器标识符来惟一标识。

为已压缩的消息指定容器标识符是应用的责任。当应用收到已压缩的消息时,它替消息指定或创建容器，并将容器标识符提供给SigComp系统。

23.3  在IMS中压缩SIP消息

23.3.1SIP压缩的初始化

在注册阶段，用户设备（UE）和代理呼叫会话控制功能（P-CSCF）通过提供自己的压缩能力的细节（如内存大小、处理能力、上载状态和压缩指令，见12.13.15节）来宣布其进行压缩的意愿。由于3GPPIP多媒体子系统（IMS）中对安全有很强的要求，只有在安全联盟建立起来之后才允许进行宣告和状态创建。否则，恶意用户可能上载伪造的状态从而使压缩受到攻击。

23.3.2 压缩SIP消息

当UE或P-CSCF想发送一条压缩的SIP消息时，它会遵循［RFC3320］中描述的框架，该框架指出UE中的SIP应用应该向压缩器调度员传递一条消息。压缩器调度员调用一个压缩器，通过容器取出必要的压缩状态（容器由容器ID标识并由应用提供），并使用某个压缩算法来对消息进行编码。最后，压缩调度器将压缩消息转给传输层，以传递到远端（P-CSCF）。

压缩器需要确保远端能对生成的消息进行解压缩。可以在每个SigComp消息（即每个字节码）中都包含全部需要的信息，以实现消息的解压缩。然而，这将很大程度上降低可获得的压缩率。因此，最好是叫另一端来创建状态。这样保存在这些状态项中的信息就可以被来自相同源并具有相关性的消息访问，用于将来的SigComp解压缩，从而避免基于每个消息来上载数据。

23.3.3对压缩的SIP消息进行解压缩

当解压缩器调度员收到一条消息时，它对消息的前缀进行检查。由于所有SigComp消息都包含一个前缀（第一字节的最前面5位设为1）,因此解压缩器调度员能识别出消息是压缩过的。该前缀在UTF-8编码的文本消息中不会出现。解压缩器调度员将该消息转发给通用解压缩虚拟机（UDVM）,UDVM向状态处理器请求在之前创建的状态，并使用其提供的状态（或状态不存在，则使用消息中提供的字节码）来进行消息解压缩。在解压缩后，UDVM将已解压消息返回给解压缩器调度员，解压缩器调度员进一步将消息传给应用。