故障現(xiàn)象某VoLTE（Voice over LTE，LTE語音）項目采用關(guān)閉端口方式進行VoLTE業(yè)務(wù)的容災(zāi)測試過程中，發(fā)現(xiàn)如下故障：
S-CSCF（Serving-Call Session Control Function，服務(wù)呼叫會話控制功能）有時只觸發(fā)VCCAS業(yè)務(wù)，有時只觸發(fā)MMTEL（Multimedia Telephony，多媒體電話）業(yè)務(wù)，有時兩者都不觸發(fā)，有時都能正常觸發(fā)的現(xiàn)象。
故障分析現(xiàn)場的組網(wǎng)路由情況如下：

• CSCF（Call Session Control Function，呼叫會話控制功能）對接AS時，配置了UDP/SIP LINK/SIP ROUTE/SIP ROUTESET等數(shù)據(jù)。
  
• HSS/S-CSCF配置SP/SIFC規(guī)則時，AS主機名配置的是虛擬主機名as.voltetas.hb.chinamobile.com。
  
• 用戶觸發(fā)AS時，是通過DNS（Domain Name System，域名系統(tǒng)）查詢將虛擬主機名解析成實際主機名as3.voltetas.hb.chinamobile.com/as4.voltetas.hb.chinamobile.com。
  

分析處理如下：
（1）S-CSCF到AS采用DNS查詢方式，DNS返回兩個優(yōu)先級一樣的結(jié)果，S-CSCF通過負荷分擔進行選擇。
（2）閉塞AS3的端口后開始進行呼叫測試，對測試流程進行詳細分析。

（3）綜上所述，當S-CSCF負荷分擔選擇到AS3時，觸發(fā)失敗，SCCAS觸發(fā)失敗繼續(xù)觸發(fā)MMTEL，如果MMTEL觸發(fā)失敗則整個流程失敗。
（4）既然AS3已經(jīng)是故障狀態(tài)，為什么S-CSCF還會選擇AS3進行觸發(fā)？

• 第一種解釋
  

CSCF與AS之間的鏈路啟用了自發(fā)式心跳檢測，應(yīng)該有OPTIONS心跳檢測消息，默認配置是對于可用路由，每隔20s檢測一次，如果連續(xù)三次檢測不到，則認為鏈路中斷，此時CSCF會選擇容災(zāi)的AS。
在AS剛閉塞的一分鐘內(nèi)，CSCF還是認為該AS是可用的，所以仍然會向該AS發(fā)送請求消息，收不到響應(yīng)消息后，再根據(jù)session-continue繼續(xù)觸發(fā)其他的AS。
直到一分鐘以后，CSCF才會檢測到該AS鏈路中斷，這時才會選擇容災(zāi)的AS。設(shè)備是否故障是通過檢測周期和監(jiān)測次數(shù)來實現(xiàn)的，需要一定的時間，意思是，AS側(cè)閉塞網(wǎng)口后，CSCF并不能立刻識別到AS故障。
這種解釋可以說明剛閉塞端口時（一分鐘內(nèi)），S-CSCF繼續(xù)選擇故障態(tài)AS的現(xiàn)象。但是現(xiàn)場實際測試發(fā)現(xiàn)，AS端口閉塞很長一段時間（且看到CSCF-AS之間斷鏈告警）之后，S-CSCF仍然會去選擇故障態(tài)的AS進行觸發(fā)。

• 第二種解釋
  

現(xiàn)場是采用動態(tài)容災(zāi)的方式，也就是對于AS3和AS4都是通過SRV查詢獲取到的，但是現(xiàn)場對于AS3和AS4的URI分析中又配置了靜態(tài)鏈路，這其實并不屬于完全的動態(tài)容災(zāi)，需要將AS3和AS4的URI（Uniform Resource Identifier，統(tǒng)一資源標識符）分析中的DNS查詢勾選上A查詢，并將靜態(tài)鏈路刪掉，這樣才是完全的動態(tài)容災(zāi)。
現(xiàn)場的問題是由于雖然閉塞了AS側(cè)的鏈路，但是由于CSCF到AS是采用靜態(tài)鏈路，因此并沒有影響到AS3和AS4的動態(tài)容災(zāi)主機狀態(tài)，CSCF仍然認為這兩個動態(tài)AS主機的狀態(tài)是好的。
由于兩個AS同時處理VCCAS業(yè)務(wù)和MMETEL，而在SRV查詢中兩個AS主機的權(quán)重和優(yōu)先級又完全一樣，因此CSCF在選擇上是各50%的機率選中，如果選中AS4，那么就可以正常觸發(fā)VCCAS或者MMETEL業(yè)務(wù)，如果選中AS3，那么就無法觸發(fā)，只能session-continue。
具體流程分析如下：

• 情況1
  

觸發(fā)VCCAS時通過SRV查詢到AS3和AS4，輪選選中AS3，但是發(fā)現(xiàn)鏈路不通，session-continue，觸發(fā)MMETEL，這時再查詢SRV，輪選選中AS4，于是觸發(fā)AS4的MMETEL。

• 情況2
  

觸發(fā)VCCAS時通過SRV查詢到AS3和AS4，輪選選中AS4，于是觸發(fā)AS4的VCCAS，繼續(xù)觸發(fā)MMETEL，這時再查詢SRV，輪選選中AS3，但是發(fā)現(xiàn)鏈路不通，于是沒有觸發(fā)MMETEL業(yè)務(wù)，直接導(dǎo)致被叫出局。

• 情況3
  

觸發(fā)VCCAS時通過SRV查詢到AS3和AS4，輪選選中AS3，但是發(fā)現(xiàn)鏈路不通，session-continue，繼續(xù)觸發(fā)MMETEL，這時再查詢SRV，仍然選中AS3，但是發(fā)現(xiàn)鏈路還是不通，也沒有觸發(fā)MMETEL業(yè)務(wù)，直接導(dǎo)致被叫出局。

• 情況4
  

觸發(fā)VCCAS時通過SRV查詢到AS3和AS4，輪選選中AS4，觸發(fā)VCCAS業(yè)務(wù)，之后繼續(xù)觸發(fā)MMETEL，這時再查詢SRV，仍然選中AS4，觸發(fā)MMETEL業(yè)務(wù)，最后導(dǎo)致被叫出局。
以上這四種情況分析與現(xiàn)場測試情況一致。

（5）在現(xiàn)場CSCF原配置下閉塞AS端口之后，在CSCF上使用SHOW DYNAMICDR INFO命令查詢動態(tài)容災(zāi)信息時，AS的主機組始終是正常態(tài)，AS3也始終是參與選路。
（6）通過以上分析確定現(xiàn)場問題是由于非完全動態(tài)容災(zāi)引起的。
故障處理針對現(xiàn)場非完全動態(tài)容災(zāi)的問題，修改現(xiàn)場配置如下：
（1）CSCF上確保鄰接主機中兩個AS主機啟用了“自發(fā)式”的心跳模式。
（2）CSCF上對于AS虛擬主機名的URI分析，啟用SRV查詢，并在DNS上配置同局址優(yōu)先的策略（根據(jù)源IP返回兩AS主機名及不同的優(yōu)先級）。
（3）CSCF上對于AS實際主機名的URI分析中刪除靜態(tài)路由集，啟用A查詢。
（4）CSCF上刪除與AS之間的UDP/SIP LINK/SIP ROUTE/SIP ROUTESET等數(shù)據(jù)。
按照以上進行修改后測試，AS容災(zāi)測試正常，問題解決。