VoLTE学习笔记杂谈(9)-现网测试案例分析
提到甜点，大家第一时间想到的应该都是法国吧。德国美食在人们心中往往都是一副硬派的形象，肥美的烤猪肘子、烤香肠，再搭配上麦芽味醇厚的自酿黑啤酒，简直就是完美的享受。但是德国这个国家粗中有细，把严谨的做派沿用到甜点上，也能够诞生令人惊异的美味。VOLTE学习笔记已经连载到了第9期，这一期就给大家带来两个现网中遇到的小案例，希望能够起到抛砖引玉的作用。我们为大家提供的是开胃的小菜，主菜就需要大家不断摸索，在日常的优化工作中获取了。
我们从现网测试的一些具体案例入手尝试对一些异常现象进行分析。
以下是南京现网实测的一个主叫未接通案例，在主叫发送INVITE之前，网络侧下发了一个UPDATE消息。
协议RFC3311说明，UPDATE消息可被用来进行媒体流和码流信息的更新，有点类似于re-INVITE消息，但是区别于re-INVITE消息，UPDATE消息可以在初始的INVITE消息完成之前发送。因此可以知道这个电话是已经在通话中或者上一次的INVITE消息已经收到响应，由于被叫一端发起了UPDATE流程。紧接着，主叫又发起了一个INVITE流程，如下图所示：
由于INVITE流程不能与前一次的INVITE流程发生冲突，即之前的INVITE流程在进行中时，主被叫UE均不能发起INIVTE,因此可以认为初始的INVITE流程已经完成或者收到响应。之前来自于网络侧的UPDATE是在前一次的INVITE流程之后由网络侧或被叫UE发起的（例如，被叫UE暂时挂起）。
之后主叫UE收到了403（Forbidden）消息，Forbidden消息是服务器识别了INVITE请求，但是无法进行相应的鉴权，另外UE收到403消息后，不能重复发起re-INVITE请求，除非进行相应鉴权信息修改。(RFC 3261),同时回溯测试时间之前大约10分钟的测试log,都发现频繁重复的出现了SIP INVITE-403 FORBIDDEN-SIPACK信令，由此可以初步判定这一系列的INVITE消息应该是终端的设置造成的，并不符合标准协议流程。
这个403 Forbidden消息有可能由如下原因导致：
1、P-CSCF发起，可能是因为新的re-INVITE请求与现有对话无关；
2、S-CSCF发起，可能由于与之前存储信息不符；
3、I-CSCF发起，由于鉴权信息的不一致；
…
后续,网络侧发来SIP BYE消息,注意红线圈出的原因“SCSCF released the session because of session timer expiration”，因此，最终由于SCSCF的对于会话的周期性更新，当会话定时超时后，S-CSCF删除了对话相关的存储信息，并下发了SIP BYE。
从上述现象结合起来观察，当终端收到403 FORBIDDEN后，并不释放终端的SRB、EPS承载，因此可以看到在收到403后，RRC层依然进行着重配，测量，切换等一系列操作。
这个未接通的案例值得进一步深思，存在如下几点：
1、终端什么情况下会重复发送SIPINVITE，触发条件是什么？
2、终端收到403FORBIDDEN后是否会回复SIP ACK？
3、网络侧为什么在过程中会发UPDATE，更新的内容是什么？
4、同时，回溯之前的测试log，在两次的SIP INVITE-403 FORBIDDEN-SIP ACK之间还收到了主叫发起的注册流程，终端在什么条件下会发起注册流程？而注册请求到200ok之间还收到了网络侧的NOTIFY消息，而注册消息和NOTIFY消息的SIP Call ID还不一样。
这个case信令统计点来看容易被误判成掉线（call drop），但其实从用户感受以及结合回溯的实际信令流程来看属于未接通的的案例（callsetup failure）。
下面一个案例也是在南京现网发生的主叫未接通案例。
主叫UE发出SIP INVITE收到100 trying后，相隔一段时间后收到了网络侧下发的SERVICE_UNAVAILABLE(503)，
协议规定SERVICE_UNAVAILABLE(503)表示服务器由于负荷过载或者维护问题暂时无法处理发送请求。服务器可能会在Retry-After头域里指示客户端何时再进行请求重发尝试。如果Retry-After没有给出，那么客户端必须表现的如同收到Server Internal Error(500)响应一样。而对于Server Internal Error(500)响应的描述，一般指的是服务器处于不可预计的条件下，从而无法满足请求。客户端可以将该特定错误状况进行展示，例如该次的错误状态为'Media Bearer Lost'，一般收到500响应，可以基本断定是S-CSCF出现的问题，其中P-CSCF只是将之转发。
我们回溯一下信令发现，当主叫UE收到了100 trying后，迟迟等不到后续的183-180ringing，以及最后的SIP 200 ok,当大约10秒超时后，由RRC层先进行了了链路释放。
之后收到503后，其实已经处于RRC-IDLE状态，因此通过网络侧寻呼后又变成了连接态，其实从主叫状态经历了RRC-IDLE,之后又变成了“被叫”。随后，网络侧下发QCI1的专用承载去激活NAS ESM信令，UE反馈Accept，同时将专用承载状态置为Inactive。
这里仅仅是专用承载去激活，默认承载QCI9，QCI5还依然保留，EUTRAN侧并没有立即发起RRC释放。后续可能由于目前UE的私有设置，UE变成了一个CSFB终端，后续的信令流程就是标准的CSFB主叫流程了
结合整个流程的分析，推测出现问题是由于UE收到100 trying后没有收到后续SIP响应，因此当10秒超时后，EUTRAN下发了RRC Connection Release,这里释放掉了SRB也同时释放掉了DRB，同时EUTRAN上报核心网由于该UE不活跃（User Inactivity）触发导致MME也将EPS承载释放(这里一般由eNodeB发起，通过UE Context Release Request信令发起，通知MME将该UE的所有在S1接口建立起来的E-RAB释放掉)，这样通知IMS域媒体承载释放，也就造成了后续503的下发。问题的关键是需要明确在10秒之内为什么没有收到183-180ringing响应，这里有一种可能被叫处于CSFB状态（或者CS域），导致协商时间过长，超过了10秒。
有一个值得注意的现象，当网络侧异常释放了RRC连接，即下发了RRC Connection Release，根据协议36.331描述，UE会清空自己所有建立的RB，但是不一定会释放掉EPS Bear，因此当再收到RRC重配消息后，通过重配消息中EPS Bear ID与DRB ID的耦合，可以分别确认默认承载QCI9，QCI5以及话音的专用承载QCI1的映射情况。
未完待续，不定期更新～
张阳，英国布鲁内尔大学（Brunel Univ.）设计与工程学院电子与计算机工程博士，高级工程师，博士阶段主要进行LTE物理层、处理优化算法研究。主要从事TD-LTE/TD-SCDMA网络优化工作。曾参加中国移动无线网络优化技术高级培训，荣获优秀学员称号，参加中国移动LTE维护优化技能竞赛，荣获一等奖。长期关注跟踪一线实际优化工作，具有丰富的理论基础及实践经验。在国内外通信期刊发表学术论文数十篇，并合著有《TD-LTE无线网络优化与应用》一书。
感谢一路陪伴我们的热心粉丝，如果觉得文章还不错，可以通过扫描下面的二维码支持我们，谢谢。
网优小谈 是业内原创为主的通信技术交流平台，欢迎不同意见、新观点或建议。
支持原创，分享智慧！
投稿请发至：wirelessren@163.com