主頁（http://www.www.jjxinkai.com）：VoLTE專項提升簡易案例分析-語音質(zhì)量提升

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

【問題現(xiàn)象】

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

【問題分析】

多方通話的用例使用了三個HTC的終端，其中一個作為主叫用戶，向另外兩個用戶發(fā)起通話會議。HTC主叫終端發(fā)起會議請求的頭域為sip: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è)修改會議請求的頭域。

【問題解決】

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

呼叫建立時延較大（二）

【問題現(xiàn)象】

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

【問題分析】

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

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

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

【問題解決】

重新測試之后，呼叫建立時延變成2.5秒左右；

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

【問題現(xiàn)象】

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

【問題分析】

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

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

【問題解決】

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

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

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