原因： 當視訊通話在正好 15 分鐘後中斷連接時，常見問題是網路（防火牆/路由器）上所配置的 TCP 超時時間小於 SIP 作業時間到期計時器。 根據 CallManager 的預設值，SIP 作業階段到期計時器設定為 1800 秒。

解決方案 ：

若要驗證此：

1. 開啟Cisco Unified Communications Manager （CM） 管理。

2. 按一下系統 > 服務參數 。
3. 在 選取伺服器和服務下 ，在 服務下拉清單方塊中，選取 Cisco Call Manager（使用中） ：

4. 尋找 SIP 作業 期到期計時器 ：

向 CUCM 註冊的所有裝置都使用此計時器。 當裝置正在與另一個遠端裝置通話時，其中一方必須重新更新會話並傳送重新 INVITE 或 UPDATE。 此重新更新必須于課程到期計時器的一半前送出（ 1800/2 = 900 秒 = 15 分鐘）。 如果未收到重新更新訊息，則通話會中斷。

檢查初始 INVITE 中的作業階段計時器。 在此時間到期之前，應該收到重新更新（INVITE/UPDATE


）：根據初始使用者代理用戶端/使用者代理伺服器 （UAC/UAS） 協商，其中一個裝置會在傳送重新 INVITE 時重新啟用會話。 若重新更新為 UAC，則通話贊助者必須負責重新更新該會話。 如果重新更新為 UAS，伺服器必須重新更新該會話。 從兩個端點收集 SIP 調試日誌並檢查這些專案：

範例： 從 A 方對 CUCM 對 B 方進行呼叫。若重新更新為 UAC（在方 A 上）及 UAS（在 B：

1 上）。     A 方必須傳送重新邀請/更新至 CUCM。
2.     CUCM 必須傳送重新邀請/更新給 B 方。
3.     B 方收到重新 INVITE，併發出 200 OK 回應該訊息。
4.     CUCM 必須傳送 200 OK 給 A 方。

如果一個裝置傳送重新 INVITE 訊息給 CUCM，CUCM 會向另一方傳送重新 INVITE。 但是，如果遠端未收到此請求，這可能是因為部分網路裝置在之間。 由於 SIP 檢查或網路設定，重新 INVITE/回應可能未到達其中一側。
如果裝置未啟動重新 INVITE，則可能是裝置有問題。 涉及 Cisco 技術協助中心 （TAC）以進一步調查。
 
在要嘗試[如果尚未執行此作業]之區域進一步配置區域中的清單上，將 Webex
：將 SIP UDP/IX 篩檢程式模式開啟 [非預設]：

並檢查 VCS-e 上的 SIP 作業階段計時器。
 
我們的預設值為 1800s [15 分鐘]，這是標準值，您將要確保防火牆上的 TCP 計時器也在這裡符合，但是您可以稍微碰一下這一點，看看是否對 VCS

有作用。這位於設定> 通訊協定> SIP ：


請注意，會話重新設定間隔（秒）設定為預設值。 您可以嘗試 3600。 但問題的實際根本原因是當 FW 認為階段課程不再使用 [案例 1]時，當 VCS 實際上認為它正常，且階段會議仍在啟動中，但該會話/埠上收不下一個或關閉的一個。並且嘗試重新使用它和呼叫接收者。[案例 2] 是 FW 會正常關閉連接，並傳送一個一般 DNS/關閉與 VCS 記錄一般通話掉線/清除，而且通話也會正常執行。 在這裡修改階段作業計時器僅控制 VCS 在無法收到任何有關通話狀態之嘗試通訊的 ACK 後放棄階段作業。
 
不過，這有助於我們更好地精確找出問題。 我們也可能需要根據此計時器的 FW 設定來降低此值。