基於OpenSIPS做注冊服務下，場景A打B，一方發起BYE掛斷后收到500，另一方無法掛斷的問題

 

最近在工作中遇到一個看似很奇怪，排除起來很費勁，但最后的解決方式又及其簡單的問題，下面我們一起來看看具體發生了什么吧！

 

一句話概括：那都是OpenSIPS  Dialog模塊的default_timeout 惹的禍（學業不精，木辦法呀……）

 

問題現象：

1. A打B，電話接通后，持續通過話5分鍾后，任意一方掛斷電話，另一方無法正常掛斷，另一方電話始終顯示正在通話中。
2. 如果通話時長在4分鍾以內，任何一方掛斷，則另一方都能正常結束。

 

運行環境：

• 　CentOS           7.6
•     OpenSIPS       2.4.2
•     FreeSWITCH  1.6.20

 

業務場景：

• OpenSIPs為分機提供注冊服務
• OpenSIPs為FreeSWITCH提供Load balance服務，將電話轉接至相應FreeSWITCH
• OpenSIPs為FreeSWITCH提供Gateway服務

    如下圖所示，9001撥打9003(分機互打)，OpenSIPs先將INVITE發送至FS，FS 再將電話通過OpenSIPS呼叫到 9003，通話過程中媒體流通過FS中轉。

        

 

 

   

問題分析：

1. 通過抓包分析，發現主被叫任意一方掛斷后，FS收到bye后，直接回給OpenSIPS 500 (Internal Server Error), 而導致OpenSIPS沒能將bye信號發給另一方電話終端
2. OpenSIPS 給FS和電話終端發OPTIONS檢測會話狀態只發4分鍾后，就不再發了，並且主被雙方可以繼續通話
3. 如果OpenSIPS關閉掉對FS的dialog會話OPTIONS檢測，FS收到BYE后，能轉發到另一方電話終端，但終端會返回500，而沒有無法返回200 OK
4. 電話呼叫四分鍾之內正常掛斷的BYE報文，跟超過4分鍾無法掛斷的BYE報文相比，構造形式完全相同（可排除BYE信令內容問題）

      SIP信令時序圖部分內容如下所示：

           

 

    下面是FreeSWITCH 收到 分機9003 發起的BYE之后的SIP報文情況：

------------------------------------------------------------------------
recv 839 bytes from udp/[10.2.32.112]:5060 at 20:13:12.270989:
   ------------------------------------------------------------------------
   BYE sip:9001@10.2.32.116:5080;transport=udp SIP/2.0
   Via: SIP/2.0/UDP 10.2.32.112:5060;branch=z9hG4bK4a88.a1534783.0
   Via: SIP/2.0/UDP 10.32.26.19:1150;branch=z9hG4bK-d87543-eb259935be711165-1--d87543-
   Max-Forwards: 69
   Contact: <sip:9003@10.32.26.19:1150;transport=udp>
   To: "9001"<sip:9001@10.2.32.112>;tag=p4v8FyNvv3S5D
   From: "9003"<sip:9003@10.2.32.112>;tag=e7553b0b
   Call-ID: NzA5YjM0OGVlM2JmMDA4NTAyZDliZmNhZWE2NjhiMDA.
   CSeq: 3 BYE
   Proxy-Authorization: Digest username="9003",realm="10.2.32.112",nonce="5f2bf37b000000d2afc1e61869246645da21b40ab086deaf",uri="sip:9001@10.2.32.116:5080;transport=udp",response="6a89ecdf3476a98ce0a89ee15ba29312",algorithm=MD5
   User-Agent: eyeBeam release 1011d stamp 40820
   Reason: SIP;description="User Hung Up"
   Content-Length: 0

   ------------------------------------------------------------------------
send 375 bytes to udp/[10.2.32.112]:5060 at 20:13:12.271131:
   ------------------------------------------------------------------------
   SIP/2.0 500 Internal Server Error
   Via: SIP/2.0/UDP 10.2.32.112:5060;branch=z9hG4bK4a88.a1534783.0
   Via: SIP/2.0/UDP 10.32.26.19:1150;branch=z9hG4bK-d87543-eb259935be711165-1--d87543-
   From: "9003"<sip:9003@10.2.32.112>;tag=e7553b0b
   To: "9001"<sip:9001@10.2.32.112>;tag=p4v8FyNvv3S5D
   Call-ID: NzA5YjM0OGVlM2JmMDA4NTAyZDliZmNhZWE2NjhiMDA.
   CSeq: 3 BYE
   Content-Length: 0

 

問題原因：

    通過上面分析，我們可以猜測這是由於OpenSIPS對dialog做OPTIONS探測引起的。仔細檢測OpenSIPS的dialog 模塊配置，我發現dialog模塊的 default_timeout = 240 (秒)。

    這就能充分解釋上面‘問題分析’中的第2點了(只發4分鍾OPTIONS)， 因為4分鍾后dialog就過期了，OpenSIPS不再發送探測包。

 

    FreeSWITCH 和 電話終端(如Yealink話機) 都遵循 SIP 協議規范，如果一通已建立的電話，在通話過程中，FS或電話終端有收到上游(如OpenSIPS)的OPTIONS探測，那么電話從接通到掛斷，都必須收到周期性的進行OPTIONS探測，

    如果超過周期時長了，FS或電話終端仍沒有收到OPTIONS探測， 那么FS和電話終端就會認為通話存在錯誤，后面在收到BYE時，就會返回 500 (Internal Server Error)。

 

 

解決辦法：

    將 OpenSIPS 的 default_timeout 值更具需要改大，如改成10800 (即3小時)，重啟OpenSIPS即可解決問題。 

loadmodule "dialog.so"
modparam("dialog", "db_mode", 1)
modparam("dialog", "dlg_match_mode", 1)
####【正確配置】
modparam("dialog", "default_timeout", 10800) # 3 hours timeout
###【錯誤配置 ：如果使用了create_dialog("Pp")，當一通電話超過 default_timout + options_pint_interval ，就會出現收到BYE的終端或FS返回500】 #modparam("dialog", "default_timeout", 240) # 4 mins             
modparam("dialog", "profiles_with_value", "caller ; callee")
modparam("dialog", "options_ping_interval", 60) # 1 mins

route{
   if (is_method("INVITE")) {
      # 對OpenSIPS上進、出兩個dialog（如主/被叫）都進行OPTIONS探測 if ( !create_dialog("Pp") ) { 
         xlog("create_dialog error : Internal Server Error");
         send_reply("500","Internal Server Error");
         exit();
      }
   }
}