终端问题分析情况详解

目前市场上VoLTE终端型号较多，所有型号VoLTE终端问题的发现和定位不易实现。对市场占比较高、用户数多的终端进行测试已定位的问题共涉及39款不同的终端，其中主流终端iPhone、华为Mate8、三星S6/S7都存在部分问题，如图9-50所示。

主流厂商服务能力强，终端问题能够及时地在新版本的推动中改进、解决，但终端市场还有大量市场份额较小的非主流终端。测试中非主流终端发现的问题数量更多，占总数的81%，且问题种类多，涉及各种终端问题，需要逐步推动解决，如图9-51所示。

图9-50 终端问题占比

终端问题定位举例：

问题1：CS用户呼叫VoLTE用户无应答前转接通后无声问题。

2G/3G用户A呼叫VoLTE用户B，B归属中兴VoLTE核心网，用户B无应答（或遇忙或不可及）前转到CS用户C，C接通后，A上还是显示拨号中，能听到C用户的声音，但C用户听不到A用户的声音，单通。

经分析，发现是AS发送UPDATE后同一时间收到200OK及UPDATE，信令跟踪显示，收到UPDATE在前，200OK在后，顺序反了。再结合MGCF上的顺序，发现MGCF的顺序是正确的。之所以MGCF发送顺序正确，而AS上顺序不对，是由于网络时延或抖动造成的。

进行测试，并抓取CSCF、AS、MGCF涉及网元及手机Log进行信令分析。

上述场景下呼叫流程经过网元：用户A所在端局触发B用户的被叫锚定流程，前插码通过关口局送给MGCF，MGCF送给I-CSCF，I-CSCF找到B用户所在S-CSCF，S-CSCF触发B用户的业务送给AS，呼叫B，B振铃后不接，无应答前转到C，由于C号码为CS域用户，所有S-CSCF会将呼叫送给MGCF出局到关口局。

图9-51 非主流终端问题分布

1）根据上述现象，说明呼转成功，C号码已经振铃，依次查看各网元信令，发现在CSCF发送呼转号码C的invite后，一直没有收到C号码的180振铃及200OK（invite）消息，如图9-52所示。

图9-52 网元信令流程

2）根据这个线索，继续查看MGCF的信令，发现确实如此，收到C号码过来的ACM和ANM后，没有向CSCF转发180振铃及200OK（invite）消息，如图9-53所示。

图9-53 MGCF信令流程1

3）定位问题出在MGCF上，继续向上分析，发现MGCF收到UPDATE（51行）后同一时间发送了200OK（UPDATE）及新的UPDATE（54行），但没有收到UPDATE（54行）对应的200OK，如图9-54所示。

图9-54 MGCF信令流程2

4）根据MGCF发送的UPDATE（54行），顺序查找各网元信令，找到AS收到（68行）UPDATE，但没有发出200OK，如图9-55所示。

图9-55 网元信令流程

5）问题转向AS，经分析，发现是AS发送UPDATE后同一时间收到200及UPDATE，信令跟踪显示，收到UPDATE在前，200OK在后，顺序反了。再结合MGCF上的顺序（见图9-54），发现MGCF的顺序是正确的。

6）原因分析：只有MGCF发送顺序正确，而AS上顺序不对，是由于网络时延或抖动造成的。

7）在MGCF上修改到CSCF局向的参数（延迟发送SIP证实消息定时器时长），如图9-56所示。目的是在收到UPDATE，发送200OK后，延迟50ms再发送新的UPDATE，以避免网络延迟造成的乱序。

图9-56 MGCF上修改到CSCF局向的参数

修改参数后，重新测试验证，问题解决，如图9-57所示。

图9-57 修改参数后信令流程

问题2：三星S7与华为Mate8视频呼叫过程中自动切换至语音后，Mate8无法重新发起视频呼叫。

华为Mate8在与三星S7终端进行视频通话的过程中，如果将Mate8通话界面切换至后台，等待几秒钟后视频通话会自动切换成语音通话（通话并未中断），此时Mate8想重新发起视频呼叫，点击视频呼叫图标后，S7收不到视频呼叫的申请，Mate8则始终保持在“等待对方接受邀请”的界面。同样条件下，如果是S7再次发起视频呼叫，则Mate8可以正常收到视频呼叫请求。

从核心网跟踪的信令来看，主叫Mate8呼叫切换到后台后，是被叫三星终端发起INVITE切换到语音通话，并且三星发起的切换消息和正常手动切换语音的消息不同，多了资源预留流程。

核心网分析如图9-58所示。(www.xing528.com)

图9-58 Mate8视频呼叫信令流程

15：24 Mate8发起视频呼叫。

15：25 Mate8把呼叫切到后台。

15：25 Mate8自动切到语音通话。

Mate8把呼叫切换到后台时，核心网没有收到任何消息，但是切换到语音是被叫三星S7发起的，消息中多了资源预留流程。S7自动切换至语音通话消息如图9-59所示。

S7手动切换至语音消息如图9-60所示。

15：26 Mate8再次发起视频呼叫，S7无相应提示。

图9-59 三星S7切换至语音通话

图9-60 三星S7语音通话信令流程

15：27 Mate8挂机。

从核心网信令中看，切换至语音通话后，核心网一直没有收到Mate8发起的视频呼叫请求，直到15：27：32，Mate8挂断电话，呼叫结束，如图9-61所示。

图9-61 核心网信令流程

从核心网信令中看，华为Mate8将视频通话切换到后台之后，会引起三星S7自动发起中断视频通话。与S7手动中断视频通话不同，这种情况下华为Mate8无法再次发起视频呼叫，核心网也收不到Mate8发起视频呼叫的消息。

判断为华为Mate8与三星S7存在协议问题，不能排除华为或三星终端与异厂家终端存在协议匹配问题，此类问题很可能会影响到用户感受，需终端厂家对问题做进一步分析，未来也需要对终端协议制定相应的规范。

问题3：VoLTE用户语音呼叫中切换视频通话不接40s后释放呼叫问题。

VoLTE用户A拨打VoLTE用户B，语音通话过程中，A或B发起切换视频请求，如果对方不接受切换视频请求，则约40s后整个呼叫被释放。

进行测试，并抓取CSCF、AS涉及网元及手机Log进行信令分析。

CSCF信令分析，发现被叫AS给被叫CSCF发了BYE消息，被叫CSCF将BYE消息发给了被叫SBC，最后发送至终端，如图9-62所示。

图9-62 CSCF信令流程

该BYE消息由被叫AS信令网元产生，如图9-63所示。

图9-63 AS信令流程

被叫AS产生BYE消息的原因：当一方发起视频请求后，被叫AS发送re-invite消息到终端后，终端不接，定时器就超时释放。该定时器查询结果如图9-64所示，设置值为40 s，与测试现象吻合。

图9-64 定时器查询结果

定时器超时释放的依据如下协议描述：

RFC 3261 SIP：Session Initiation Protocol June 2002

If a UA receives a non-2xx final response to a re-INVITE，the sessionparameters MUST re-main unchanged，as if no re-INVITE had been issued.Note that，as stated in Section 12.2.1.2，if the non-2xx finalresponse is a 481（Call/Transaction Does Not Exist），or a 408（Request Time-out），or no response at all is received for the re-INVITE（that is，a timeout is returned by the IN-VITE clienttransaction），the UAC will terminate the dialog.

根据协议（RFC3261）中的描述，终端不响应就是要终结呼叫，目前SIP里没有定义在对话内取消一个请求的办法。