压缩协商

11.4.1概述

在注册过程中UE和P-CSCF已经就基本压缩能力进行了协商（见10.9节），因此，两个UE及其P-CSCF之间的所有请求和响应都是以压缩形式传递的。

本例中我们仅仅介绍在会话建立过程中压缩参数是如何设置的，并且只关注TheresaUE和她的P-CSCF之间的压缩。Tobias的情况与之完全相同。

11.4.2初始请求的压缩

我们假设Theresa已经在她的S-CSCF处注册了一个"包含comp=SigComp参数的联系地址，因此，当TheresaS-CSCF作为SIP注册服务器并重写INVITE请求的URI（参见11.3.3.5）时，将包含这个参数。

INVITEsip:[5555::5:6:7:8]:1006;comp=SigCompSIP/2.0

当P-CSCF收到这个请求后，它根据请求URI将其路由到TheresaUE,由于包含了comp=SigComp参数，它将使用压缩格式发送该请求。除此之外，P-CSCF还会：

•  在Via消息头中自己的条目中增加comp=SigComp参数，这样Theresa就会把对INVITE请求的所有响应都按压缩方式发送。

•  在Record-Route消息头中自己的条目中增加comp=SigComp参数，这样Theresa就会把本对话中所有后续请求都按压缩方式发送。

我们的INVITE请求现在如下所示：

INVITE sip:[5555::5:6:7:8]:1006;comp=SigCompSIP/2.0

Via:SIP/2.0/UDPpcscf2.home2.hu:1511;comp=SigComp;lr;

Via:SIP/2.0/UDPscscf2.home2.hu;

Via:SIP/2.0/UDPicscfl.home2.hu;

Via:SIP/2.0/UDPscscfl.homel.fr;

Via:SIP/2.0/UDPpcscfl.visitedl.fi;

Via:Sip/2.0/UDP[5555::l:2:3:4]:1357;

Record-Route:<sip:pcscf2.home2.hu:1511;comp=SigComp;lr>

Record-Route:<sip:scscf2.home2.hu;lr>

Record-Route:<sip:scscfl.homeLfr;lr>

Record-Route:<sip:pcscfl.visitedl.fi;lr>

Contact:<sip:[5555::l:2:3:4]:1357;comp=SigComp>

11.4.3响应的压缩

当Theresa UE为INVITE请求生成183（会话进行中）响应时，它会在Contact头中放入自己的IP地址和comp=SigComp参数。基于该条目，所有后续的请求都可以从TheresaP-CSCF路由到她的UE。

TheresaUE还保存Record-Route消息头，任何时候当UE发出后续请求时（例如PRACK或BYE请求），它将使用压缩方式，因为Record-Route消息头最顶端的条目中包含压缩参数。

TheresaUE将183（会话进行中）响应发给P-CSCF,并且由于Via头中有comp=SigComp参数，因此响应消息也是压缩的。

SIP/2.0183 Session in Progress

Via:SIP/2.0/UDPpcscf2.home2.hu:1511;comp=Sig Comp;lr

Via:SIP/2.0/UDPscscf2.home2.hu

Via:SIP/2.0/UDPicscn.home2.hu

Via:SIP/2.0/UDPscscfl.homel.fr,

Via:SIP/2.0/UDPpcscfl.visitedl.fi

Via:Sip/2.0/UDP[5555::l:2:3:4]:1357

Record-Route:<sip:pcscf2.home2.hu:1511;comp=SigComp;lr>

Record-Route:<sip:scscf2.home2.hu;lr>

Record-Route:<sip:scscfl.homel.fr;lr>

Record-Route:<sip:pcscfl.visitedl.fi;lr>

Contact:<sip:[5555::l:2:3:4]:1006;comp=SigComp>

从11.3.4.2节中我们看到，P-CSCF会重写Record-Route消息头中自己的条目，从中删除它的受保护的服务器端口。与此同时，它还把压缩参数也删掉，因为它希望从UE发出来的请求是压缩的，而非从S-CSCF发出的。

SIP/2.0183 Session in Progress

Via:SIP/2.0/UDPscscf2.home2.hu

Via:SIP/2.0/UDPicscfl.home2.hu

Via:SIP/2.0/UDPscscfl.homel.fr,

Via:SIP/2.0/UDPpcscfl.visitedl.fi

Via:Sip/2.0/UDP[5555::l:2:3:4]:1357

Record-Route:<sip:pcscf2.home2.hu;lr>

Record-Route:<sip:scscf2.home2.hu;lr>

Record-Route:<sip:scscfl.home1.fr;lr>

Record-Route:<sip:pcscfl.visitedl.fi;lr>

Contact:vsip:[5555::1:2:3:4]:1006;comp=SigComp>

11.4.4后续请求的压缩

当183（会话进行中）响应到达Tobias UE之后，它会发出同一对话中的PRACK请求。这个PRACK的请求URI被设置为183（会话进行中）响应中Contact头中的地址，里面也包含了压缩参数。

PRACK sip:[5555::5:6:7:8]:1006;comp=SigCompSIP/2.0

Theresa的P-CSCF收到这个PRACK请求后，仍然是根据请求URI将其发往TheresaUE,并且由于包含了压缩参数因此采用了压缩方式。P-CSCF再次在PRACK的Via头中添加了comp=SigComp参数，这样Theresa发给它的200(OK)响应便也会采用压缩方式。

按照上述过程，次对话中在UE和P-CSCF之间的所有请求和响应将全部采用压缩方式。

11.4.5相关标准

comp参数的定义参见：

[RFC3486]：CompressingtheSessionInitiationProtocol(SIP)。