信令压缩

信令压缩

在《中国电信IMS网络SIP协议总体技术要求》仅提出移动终端需要支持信令压缩功能，针对IAD类型的终端设备并没有明确说明。

信令压缩作用于UE与P-CSCF之间，标准定义了一个新的URI参数“comp”，可以被UE或P-CSCF设置为“comp=SigComp”来表达它们愿意转发压缩的SIP消息。

“comp”参数可以作如下设置：

• 由UE在 Register请求的Contact消息头中设置，这意味着UE愿意接受以自己为目的地的初始请求采用压缩形式，因为发往UE的初始请求通常都是按照UE注册后的contact地址来进行路由的。

• 由UE在任何其他的初始请求或对于初始请求的第一个响应中的Contact消息头中设置，这意味着UE愿意接受该对话的所有后续请求采用压缩形式。因为后续请求是按照初始请求或初始请求的第一个响应中的Contact消息头中的地址进行路由的。

• 由UE在任何请求的Via消息头中设置，这意味着UE愿意接受对于这个请求的所有响应采用压缩形式，因为响应是按照相关的请求中的via消息头进行路由的。

• 由P-CSCF在发往UE的record-route消息头中自己的条目中设置，这意味着P-CSCF愿意接受该对话的后续请求采用压缩形式，因为发往P-CSCF的后续请求都是按照ROUTE消息头中的条目进行路由的。

• 由p-cscf在任何请求的via消息头中设置，这意味着P-CSCF愿意接受对于这个请求的所有响应采用压缩形式，因为响应是按照相关请求中的VIA消息头进行路由的。

1）初始请求的压缩

我们假设UE已经注册到S-CSCF上，在S-CSCF上记录了UE的地址包含comp=SigComp参数。

因些，s-cscf向UE转发呼叫时，将重写Invite请求的URI为：

INVITEsip: 1.1.1.1;comp=SigCompSIP/2.0

当P-CSCF收到这个请求后，它根据请求URL将其路由到UE，由于包含了comp=SigComp参数，它将使用压缩格式发送该请求。另外，P-CSCF还会做如下处理：

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

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

INVITEsip: 1.1.1.1;comp=SigComp SIP/2.0
Via:SIP/2.0/UDP pcscf.ims.test;comp=SigComp;lr;brach=xxxx
Record-Route:

2）响应的压缩

当UE为invite请求回应183响应时，它会将自己的IP地址放在Contact头域，同时包含comp=SigComp参数，希望P-CSCF后续到UE的请求都经过压缩处理。

Record-Route消息头被UE保存，用于UE后续向P-CSCF发送请求使用，同时该头域包含comp=SigComp属性，因此UE后续向P-CSCF发送的请求都需要经过压缩处理。

UE将183响应发给P-CSCF，由于Via头域含有comp=SigComp属性，因些响应消息经过压缩处理。

SIP/2.0183 Session Progress

Via:SIP/2.0/UDP pcscf.ims.test;comp=SigComp;lr;brach=xxxx
Record-Route:
Contact:1.1.1.1;comp=SigComp>

3）后续请求的压缩

当183响应到达远端后，UE会在同一对话发出一个PRACK请求。这个PRACK请求在经过S-CSCF后，URI被设置为183响应中的Contact头域地址，里面也包含了压缩参数。

PRACKsip: 1.1.1.1;comp=SigComp SIP/2.0

P-CSCF收到PRACK请求后，仍然根据请求URI将消息转发到UE，由于包含了压缩参数，因此进行压缩处理。P-CSCF再次在PRACK的VIA 头中添加comp=SigComp属性，希望UE发出的200响应也进行压缩处理。

上述描述仅介绍了信令压缩的信令协商流程，具体压缩机制的实现细节没有去了解，如果以后有同事对这方面有兴趣，可以自行查找相关资料了解压缩机制的实现原理。

参考资料

《中国电信IMS网络SIP协议总体技术要求》

《IMS-移动领域的IP多媒体概念和服务》