从现网测试的一些具体案例入手尝试对一些异常现象进行分析。以下是**现网实测的一个主叫未接通案例，在主叫发送INVITE之前，网络侧下发了一个UPDATE消息，如图5-76所示。

图5-76 VoLTE未接通事件中的UPDATE消息

协议RFC3311说明，UPDATE消息可被用来进行媒体流和码流信息的更新，有点类似于re-INVITE消息，其区别在于UPDATE消息可以在初始的INVITE消息完成之前发送。由于被叫一端或者网络侧发起了UPDATE流程，因此可以知道这个电话已经在通话中或者上一次的IN-VITE消息收到响应。紧接着，主叫又发起了一个INVITE流程，如图5-77所示。

图5-77 UPDATE流程后主叫又发起了一个INVITE流程

由于INVITE流程不能与前一次的INVITE流程发生冲突，即之前的INVITE流程在进行中时，主被叫UE均不能再次发起INIVTE，因此可以认为初始的INVITE流程已经完成或者收到响应。之前来自于网络侧的UPDATE是在前一次的INVITE流程之后由网络侧或被叫UE发起的（例如，被叫UE暂时挂起）。

之后主叫UE收到了403（Forbidden）消息，如图5-78所示，Forbidden消息是服务器识别了INVITE请求，但是无法进行相应的鉴权发起的，另外UE收到403消息后，不能重复发起re-INVITE请求，除非进行相应的鉴权信息修改（RFC 3261）。同时回溯测试时间之前大约10 min的测试1og，都发现频繁重复的出现了SIP INVITE-403 FORBIDDEN-SIP ACK信令，由此可以初步判定这一系列的INVITE消息应该是终端的设置造成的，并不符合标准协议流程。

图5-78 UE收到403（Forbidden）消息

这个403 Forbidden消息有可能由如下原因导致：

1）P-CSCF发起，可能是因为新的re-INVITE请求与现有对话无关。

2）S-CSCF发起，可能由于与之前存储信息不符。

3）I-CSCF发起，由于鉴权信息的不一致。(www.daowen.com)

……

后续，网络侧发来SIP BYE消息，如图5-79所示，注意线圈处的原因“SCSCF re1eased the session because of session timer expiration”，由于SCSCF对会话的周期性更新导致会话定时器超时之后，S-CSCF释放会话并删除会话相关的存储信息，下发了SIP BYE。

从上述现象结合起来观察，当终端收到403 Forridden消息后，并不释放终端的SRB、EPS承载，因此可以看到在终端收到403 Forbidden消息后，RRC层依然进行着重配、测量及切换等一系列操作。

这个未接通的案例值得进一步深思，存在如下几点：

1）终端什么情况下会重复发送SIP INVITE，触发条件是什么？

2）终端收到403 Forbidden后是否会回复SIP ACK？

3）网络侧为什么在过程中会发UPDATE，更新的内容是什么？

同时，回溯之前的测试1og，在两次的SIP INVITE-403 FORBIDDEN-SIP ACK之间还收到了主叫发起的注册流程，如图5-80所示，终端在什么条件下会发起注册流程？而注册请求到200 OK之间还收到了网络侧的NOTIFY消息，而注册消息和NOTIFY消息的SIP Ca11 ID还不一样。

图5-79 网络侧下发SIP BYE消息

图5-80 UE发起注册流程IMS SIP REGISTER

从这个case信令的统计点来看容易被误判成掉线（ca11 drop），但其实从用户感受以及结合回溯的实际信令流程来看属于未接通的案例（ca11 setup fai1ure）。