Dispatcher模組實現的是一個非常簡單的呼叫排程路由，dispatcher假設對端peer是正常狀態，它本身不關心對端peer的呼叫是否成功或者失敗。但是，在實際應用環境中，如果對端peer出現故障的話，使用者如果使用了排程模組的話，系統仍然需要對peer進行檢查，否則，系統對呼叫失去了控制。例如，對端媒體會議媒體伺服器出現故障，如何對其進行檢查等。那麼，OpenSIPS 的dispatcher 模組如何實現對對端peer進行檢測是一個非常重要的環節。OpenSIPS的dispatcher 模組可以透過一些幾種方式對對端peer進行檢測：

無返回訊息，例如可能是timeout 超時，peer出現故障。

對端返回1xx，例如可能是媒體伺服器沒有足夠的落地資源或者可用埠（例如，落地使用的FXO/E1埠正在被佔用）。

返回5xx訊息，peer伺服器內部錯誤

返回6xx訊息，可能是全域性網路失敗

返回4xx訊息，可能是其他能力支援問題，例如編碼轉換或者落地埠被佔用，擁塞等。

在dispatcher使用時，可以透過失敗路由檢測到指令碼對peer進行檢測，具體的cfg示例如下：

failure_ route［ds_failed］ {if（t_check_status（ “［56］［0-9］［0-9］”） ||# 對端 peer 錯誤（t_local_replied（“all”） &&t_check_status（“408”）） ||# 本地 408 錯誤 t_ check_ status（“409”） ）# 其他錯誤# 執行失效呼叫處理］

Dispatcher對對端peer的檢測完成以後，仍然需要呼叫失效處理的邏輯指令碼對失效呼叫進行二次處理，然後進行目的地狀態更新以後的呼叫。針對OpenSIPS的dispatcher（負載均衡類似）失效處理的演算法大概需要經過以下六個步驟：

透過ds_select 獲取一個初始對端peer的組順序

從路由組中選擇第一個路由peer

對可用的第一個目的地peer傳送request請求

如果檢測到失敗的話，對此peer做一個失敗標識，關閉此peer，繼續查詢下一個可用的peer

使用下一個peer，然後新增到branch中執行serial forking處理

重複第三步

根據以上流程，dispatcher的失效呼叫指令碼處理流程示例如下：

# dispatch的呼叫失效route［do_dispatching］ {if（！ds_select_dst（2，0））{ # 所有 calllD 跟蹤send_reply（503，“Servlee Unavallable”）； exit；，t_on_failure（“ds_failover”）；t relay（）；}failure route［ds_failover］{If （failure_condition） {ds_mark_dst）；  # step 3#避免下一次再次選擇此peer，標識為失敗peerIf（！ds_next_dst（））{t_reply（503，“Servlce Unavallable”）； exit；}t_on_failure（“ds fallover”）；t_relay（） #必須對前面的relay重新發出告警}}

筆者應該注意，以上的處理方式僅說明在使用dispatcher 模組時，opensips的呼叫失效的處理邏輯。mark的策略也可以做一定的調整，例如，檢測到的引數，如果達到3次以上，就標識為一個關閉的peer。另外，marked peer也可以透過一定的週期性檢測，超時設定重新啟用其檢測狀態。當然，如果使用者也可以在對端peer側來設定基於自己業務層面的呼叫失效的處理流程。例如，如果對端是一個會議系統或者其他的媒體伺服器的話，如果呼叫的終端出現異常，本身媒體伺服器端也可以設定其他的策略來執行呼叫失效，例如，設定一個分機隨行，呼叫其他的終端，或者轉入語音郵箱等方式。

OpenSIPS的dispatcher 模組可以支援多種對SIP對端peer的狀態進行探測。此功能的使用方式和drouting類似。另外，MI CLI命令可以對ds_list 執行狀態檢測，包括活動狀態，非活動狀態和正在探測狀態。MI CLI命令也可以對目的地狀態進行管理，使用者可以使用ds_set_state 進行修改。