主頁(yè)（http://www.130131.com）：VoLTE專項(xiàng)提升簡(jiǎn)易案例分析-語(yǔ)音質(zhì)量提升

VoLTE用戶發(fā)起多方通話失敗（一）

【問題現(xiàn)象】

用HTC/三星/華為終端發(fā)起多方通話失敗。

【問題分析】

多方通話的用例使用了三個(gè)HTC的終端，其中一個(gè)作為主叫用戶，向另外兩個(gè)用戶發(fā)起通話會(huì)議。HTC主叫終端發(fā)起會(huì)議請(qǐng)求的頭域?yàn)閟ip:mmtel@conf-factory.ims.mnc007.mcc460.3gppnetwork.org，與網(wǎng)絡(luò)側(cè)配置的頭域不符，因此MTAS回了SIP/2.0 606 Not Acceptable。愛立信網(wǎng)絡(luò)側(cè)配置的頭域正確應(yīng)為：<sip:conference@gd.chinamobile.com>。 所以需要協(xié)調(diào)網(wǎng)絡(luò)側(cè)或者終端側(cè)修改會(huì)議請(qǐng)求的頭域。

【問題解決】

為了適配HTC終端，在udc，dns和mats都做了會(huì)議請(qǐng)求頭域的修改。修改完之后通話會(huì)議可以正常建立。

呼叫建立時(shí)延較大（二）

【問題現(xiàn)象】

測(cè)試結(jié)果統(tǒng)計(jì)發(fā)現(xiàn)，呼叫建立時(shí)延達(dá)到4秒以上，達(dá)不到預(yù)期。

【問題分析】

1.分析時(shí)延較長(zhǎng)的ims以及ue的log，每一條SIP消息在IMS核心網(wǎng)中從T側(cè)到O側(cè)、或O側(cè)到T側(cè)均有幾十或幾百毫秒的傳輸時(shí)延，導(dǎo)致整個(gè)呼叫時(shí)延增加了1~2秒。目前該問題未能復(fù)現(xiàn)，還在定位根本原因，可能導(dǎo)致核心網(wǎng)延時(shí)問題的原因初步考慮如下：

一方面可能是IP網(wǎng)絡(luò)承載設(shè)備的時(shí)延導(dǎo)致另一方面可能是網(wǎng)元的維護(hù)排障手段對(duì)處理器、內(nèi)存等資源占用帶來的影響（如App Trace的開啟）

2.INVITE請(qǐng)求和主叫收到183之間的初始呼叫建立時(shí)延有時(shí)長(zhǎng)達(dá)接近2秒，經(jīng)分析可能原因：被叫Paging/Service Request流程中有時(shí)候會(huì)增加幾百毫秒時(shí)延，根據(jù)UE log初步分析發(fā)現(xiàn)終端表現(xiàn)不穩(wěn)定導(dǎo)致時(shí)延差異。

【問題解決】

重新測(cè)試之后，呼叫建立時(shí)延變成2.5秒左右；

弱覆蓋區(qū)域發(fā)生RRC連接重建（三）

【問題現(xiàn)象】

高通外場(chǎng)測(cè)試時(shí)發(fā)現(xiàn)在發(fā)生RRC連接重建時(shí)UM的專用承載根本沒有建立，有的時(shí)候UM專用承載在另一條RRCConnectionReconfiguration中下發(fā)，導(dǎo)致掉話

【問題分析】

按照華為的實(shí)現(xiàn)，如果是eNB內(nèi)重建，按照36.331的要求，應(yīng)該是僅重建SRB就可以了，其他DRB的上下文都沒有變化，所以也不需要更新。

如果是eNB間重建，會(huì)一次把多個(gè)承載都建起來。協(xié)調(diào)EPC同時(shí)定位，EPC有參數(shù)用于在連接態(tài)下收到Message Type為Initial UE message的Service Request、TAU Request消息或是Ue發(fā)起的Imsi Detach消息時(shí)，控制USN9810是否刪除GBR承載。EPC后續(xù)打開該參數(shù)測(cè)試，看問題是否還存在 。

【問題解決】

DWORD_EX6的BIT28設(shè)置為1 USN9810保留GBR承載

【問題后續(xù)建議】

在配置指導(dǎo)中說明對(duì)協(xié)議版本要求。