基于OpenSIPS作注册服务下，场景A打B，一方发起BYE挂断后收到500，另外一方没法挂断的问题

基于OpenSIPS作注册服务下，场景A打B，一方发起BYE挂断后收到500，另外一方没法挂断的问题

 

 

最近在工做中遇到一个看似很奇怪的，排除起来很费劲，但最后的解决方式又及其简单的问题，下面咱们一块儿来看看具体发生了什么吧！

 

一句话归纳：那都是OpenSIPS  Dialog模块的default_timeout 惹的祸（学业不精，木办法呀……）

 

问题现象：

1. A打B，电话接通后，持续经过话5分钟后，任意一方挂断电话，另外一方没法正常挂断，另外一方电话始终显示正在通话中。
2. 若是通话时长在4分钟之内，任何一方挂断，则另外一方都能正常结束。

 

运行环境：

    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

        

   

问题分析：

1. 经过抓包分析，发现主被叫任意一方挂断后，FS收到bye后，直接回给OpenSIPS 500 (Internal Server Error), 而致使OpenSIPS没能将bye信号发给另外一方电话终端
2. OpenSIPS 给FS和电话终端发OPTIONS检测会话状态只发4分钟后，就再也不发了，而且主被双方能够继续通话
3. 若是OpenSIPS关闭掉对FS的dialog会话OPTIONS检测，FS收到BYE后，能转发到另外一方电话终端，但终端会返回500
4. 四分以内正常挂断的BYE报文，跟超过4分钟没法挂断的BYE报文构造形式彻底相同

      SIP信令时序图部份内容以下所示：

           

 

    下面是FreeSWITCH 收到 分机9003 发起的BYE以后的SIP报文状况：

 1 ------------------------------------------------------------------------
 2 recv 839 bytes from udp/[10.2.32.112]:5060 at 20:13:12.270989:
 3    ------------------------------------------------------------------------
 4    BYE sip:9001@10.2.32.116:5080;transport=udp SIP/2.0
 5    Via: SIP/2.0/UDP 10.2.32.112:5060;branch=z9hG4bK4a88.a1534783.0
 6    Via: SIP/2.0/UDP 10.32.26.19:1150;branch=z9hG4bK-d87543-eb259935be711165-1--d87543-
 7    Max-Forwards: 69
 8    Contact: <sip:9003@10.32.26.19:1150;transport=udp>
 9    To: "9001"<sip:9001@10.2.32.112>;tag=p4v8FyNvv3S5D
10    From: "9003"<sip:9003@10.2.32.112>;tag=e7553b0b
11    Call-ID: NzA5YjM0OGVlM2JmMDA4NTAyZDliZmNhZWE2NjhiMDA.
12    CSeq: 3 BYE
13    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
14    User-Agent: eyeBeam release 1011d stamp 40820
15    Reason: SIP;description="User Hung Up"
16    Content-Length: 0
17 
18    ------------------------------------------------------------------------
19 send 375 bytes to udp/[10.2.32.112]:5060 at 20:13:12.271131:
20    ------------------------------------------------------------------------
21    SIP/2.0 500 Internal Server Error
22    Via: SIP/2.0/UDP 10.2.32.112:5060;branch=z9hG4bK4a88.a1534783.0
23    Via: SIP/2.0/UDP 10.32.26.19:1150;branch=z9hG4bK-d87543-eb259935be711165-1--d87543-
24    From: "9003"<sip:9003@10.2.32.112>;tag=e7553b0b
25    To: "9001"<sip:9001@10.2.32.112>;tag=p4v8FyNvv3S5D
26    Call-ID: NzA5YjM0OGVlM2JmMDA4NTAyZDliZmNhZWE2NjhiMDA.
27    CSeq: 3 BYE
28    Content-Length: 0

View Code

 

问题缘由：

    经过上面分析，咱们能够猜想这是因为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 【正确配置】 #modparam("dialog", "default_timeout", 240) # 4 mins 【错误配置 ：若是使用了create_dialog("Pp")，当一同电话超过 default_timout + options_pint_interval ，就会出现终端返回500】
modparam("dialog", "profiles_with_value", "caller ; callee")
modparam("dialog", "options_ping_interval", 60) # 1 mins

route{
   if (is_method("INVITE")) {
      if ( !create_dialog("Pp") ) { # 对OpenSIPS上进出两个dialog(如主/被叫)都进行OPTIONS探测
         xlog("create_dialog error : Internal Server Error");
         send_reply("500","Internal Server Error");
         exit();
      }
   }
}