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 進行修改。