信令压缩（SigComp）

对于IMS而言，空中接口上SIP消息进行缩能力十分重要。信令压缩(SigComp）工作原理已在3.17节中介绍。本节介绍UE和P-CSCF如何告知对方它们支持SigComp并且都愿意启用它。

P-CSCF和IMSUE都必须支持SIP信令压缩(SigComp）,但不是必须启用。因此，它们需要一种机制来表达它们是否愿意使用信令压缩。

[RFC3486]定义了一个新的URI参数“comp”，可以被UE或SIP代理(在IMS中只能是P-CSCF）设置为“comp=SigComp”来表达它们愿意收发某些压缩后的SIP消息。

TobiasUE在初始REGISTER请求中就已经向P-CSCF表明它是否愿意启用信令压缩。P-CSCF在401(未授权）响应中给出类似的指示。由于这两个SIP消息都是没有保护的，因此此时UE和P-CSCF都不会为信令压缩创建状态(容器，compartment）：这是为了确保防止因恶意用户强制P-CSCF预留海量的不必要的信令压缩容器而导致P-CSCF过负荷，比如想对P-CSCF发起拒绝服务(DOS）攻击的恶意用户。

只有在UE和P-CSCF之间建立IPsecSA(见10.7节）后，才会创建状态(容器）。

10.9.2指示是否愿意使用SigComp

“comp”参数可以设置成：

• 由UE在REGISTER请求的Contact消息头中设置——这意味着UE愿意接受以自己为目的地、采用压缩形式的初始请求，因为发往UE的初始请求都是根据UE注册的Contact地址来进行传送的。

• 由UE在任何其他的初始请求的Contact消息头，或对初始请求的第一个响应中的Contact消息头中设置——这意味着UE愿意接受该对话的所有后续请求都采用压缩形式，因为后续请求是根据初始请求中(从请求发起侧）或初始请求的第一个响应中(从请求终结侧）的Contact消息头中的地址进行传送的。

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

• 由P-CSCF在发往UE的Record-Route消息头中自己的条目中设置——这意味着P-CSCF愿意接受该对话的后续请求都采用压缩形式，因为发往SIP代理的后续请求是根据Route消息头(由Record-Route消息头产生）中的条目进行传送的。

• 由P-CSCF在任何请求的Via消息头中设置——这意味着P-CSCF愿意接受所有对这个请求的响应都采用压缩形式，因为响应是根据相关请求中Via消息头进行传送的。

10.9.3注册过程中comp=SigComp参数

UE发送的初始REGISTER请求中包含以下与压缩有关的信息：

REGISTERsip:homel.fr SIP/2.0

Via:SIP/2.0/UDPsip:[5555::l:2:3:4];comp=SigComp;branch=0uetb

Route:sip:[5555::a:b:c:d];Ir

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

Via消息头包含了comp=SigComp参数，指示UE愿意接受对于该请求的所有响应都采用压缩形式。因此，P-CSCF可以按照压缩形式发送401(未授权）响应,但是它不应该由此就创建一个状态(即一个容器）。

Contact消息头也出现了comp=SigComp参数，这个参数将包含在UE所接收到的每个初始请求中，因为S-CSCF会将每一个初始请求的请求-URI(指向sip:tobias@homel.fr）替换为已注册的联系地址(即sip:[5555:l:2:3:4]:1357;comp=SigComp）。

来自P-CSCF的401(未授权）响应不会包含任何关于P-CSCF执行信令压缩能力的进一步信息。在首次注册之前发现的P-CSCF地址(见10.3节）中不会见到comp=SigComp参数。由于只有在下一跳地址中设置了comp=SigComp参数时，SIP消息才会采用压缩形式，因此UE不会向P-CSCF发送任何压缩格式的初始请求。

后续请求(例如ACK、PRACK,UPDATE和BYE）可以按压缩形式发送，由于从UE到P-CSCF的路由遵循P-CSCF的Record-Route条目(见11.3.2节），其中P-CSCF可以设置comp=SigComp参数。从UE到P-CSCF的响应也是同样，因为它们是根据P-CSCF的Via消息头条目进行传送的，其中P-CSCF也进行了设置。

虽然要求使用comp参数来指示是否采用了压缩，但3GPP TS 24.229并未明确要求指示初始消息是否采用了压缩格式。这样就存在一种可能性，即UE只要按照压缩形式发送所有初始请求就可以，因为P-CSCF无论如何也要支持SigComp。

于是UE将comp=SigComp参数添加在之前发现的P-CSCF地址中。这样它就可以按压缩形式发送第二个REGISTER请求。

REGISTERsip:homel.frSIP/2.0

Via:SIP/2.0/UDPsip:[5555::l:2:3:4];comp=SigComp;branch=luetb

Route:sip:[5555::a:b:c:d];7531;Ir;comp=SigComp

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

这个REGISTER请求是按照顶部Route消息头进行传送，其中包含了P-CSCF地址和comp=SigComp参数。由于该参数已经存在，因此UE可以按压缩的方式发送请求。

该REGISTER请求的200(OK）响应将根据Via消息头从P-CSCF发往UE,由于UE也包含了comp=SigComp参数，因此P-CSCF也将采用压缩的方式发送。

10.9.4其他请求中comp=SigComp参数

关于如何处理除REGISTER以外的其他请求中的comp=SigComp参数，参见11.4节。

10.9.5相关标准

comp参数定义于［RFC3486］:CompressingtheSessionInitiationProtocol(SIP）。

10.10.1P-Access-Network-1nfo

P-Access-Network-Infb消息头是3GPP特有的消息头，用于向IMS网络指示UE正通过哪种接入技术附着到IMS上。在我们的例子中所使用的接入技术是GPRS,它还包含小区全球ID(CGI）,标志用户所处的位置。

TobiasUE在其发送的每个请求(包括ACK和CANCEL请求）和每个响应(包括对CANCEL请求的响应）中包含P-Access-Network-Infb消息头，但必须是当该请求具有完整性保护时(即通过SA发送，见10.7节）。

因此，该消息头首次发送是在第二个REGISTER请求中，在UE收到401(未授权）响应之后。该消息头如下所示：

REGISTERsip:homel.frSIP/2.0

P-Access-Network-Infb:3GPP-UTRAN-TDD

     ;utran-cell-id-3gpp=234151D0FCE11

Tobias的S-CSCF从每个请求或响应中删除P-Access-Network-Infb消息头，然后转发给下一个实体。该规则的惟一例外是：当AS与S-CSCF处于同一个信任域时(见10.5.10节)。

当一个紧急呼叫的INVITE请求中包含P-Access-Network-Infb消息头时，P-CSCF和S-CSCF可以从Cell-ID中判断出离用户最近的应急中心而进行联络。在撰写本章时，3GPP标准化工作组仍然在讨论IMS紧急呼叫的细节。未来会有更多的应用使用这个消息头中所包含的信息。

10.10.2P-Visited-Network-lD

P-Visited-Network-ID消息头向Tobias的归属网络指示他正在漫游的网络的标志。TobiasUE当前所附着的P-CSCF添加了该消息头。S-CSCF用该消息头中的信息检查与拜访网络间的漫游协议。

在本例中，假设Tobias正在芬兰漫游(见9.1节)，并附着到虚构的芬兰运营商MustaKissa。由于P-CSCF也是由该运营商提供，它在每个发往Tobias归属网络的REGISTER请求中增加一个P-Visited-Network-ID消息头，该消息头中有一个字符串，用于S-CSCF识别拜访网络。

REGISTERsip:homel.frSIP/2.0

P-Visited-Network-ID:"KaunisMustaKissa"

10.10.3相关标准

3GPP特定的SIP消息头定义于[RFC3455]:PrivateHeader (P-Header)Extensionsto the Session Initiation Protocol(SIP)for the 3rd-Generation Partnership Project(3GPP)。