目錄

簡介

必要條件

需求

採用元件

背景資訊

CUCM 8.5之前的呼叫路由機制（不使用運行於所有活動的Unified CM節點功能）

使用案例1:IP電話註冊到節點1。未配置路由清單。

使用案例2:註冊到節點1的IP電話。註冊到節點2的RouteList。

用例3:註冊到節點1的IP電話。註冊到節點2的RouteList。

結論

負載平衡

Callrouting Mechanism Post-CUCM 8.5（在所有使用中的Unified CM節點功能上運行）

SIP中繼 — 在所有節點和路由本地規則上運行

路由清單 — 在所有節點和路由本地規則上運行

簡介

本文檔介紹Cisco Unified Communications Manager用來確定哪些CUCM節點用於通過會話發起協定(SIP)或基於H.323的中繼傳送呼叫的運作方式。

必要條件

需求

思科建議您事先瞭解以下主題：

- 思科統一通訊管理器(CUCM)基本呼叫路由概念

採用元件

本檔案中的資訊是根據思科整合通訊管理員(CUCM)8.x及更新版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

SIP中繼和H.323網關不向CUCM註冊（與MGCP網關不同）。 相反，與連線到中繼或網關的裝置池相關聯的CUCM組將確定這些裝置處於活動狀態的位置。例如，如果它們在2或3個節點上處於活動狀態，則CUCM使用什麼機制來決定在哪台伺服器上發出呼叫。

本文檔的目的是解釋如何做出呼叫路由決策，以及如何通過SIP中繼或H.323實現出站呼叫的負載均衡。

CUCM 8.5之前的呼叫路由機制（不使用運行於所有活動的Unified CM節點功能）

一般邏輯：對於出站呼叫，一旦CUCM通過數字分析，它將呼叫擴展到RouteList或終端裝置。  （RouteList註冊到特定節點，具體取決於CUCM組）

RouteList控制元件標識裝置清單並查詢裝置管理器。

裝置管理器提供裝置進程ID(PID)(例如：(2,100,25,45)，在此示例中，裝置在節點2上處於活動狀態)

RouteList控制元件檢查裝置的狀態（目標裝置處於活動狀態、空閒或忙碌狀態），並將呼叫擴展到中繼或網關。

由於SIP中繼/H.323網關可以在多個節點上處於活動狀態，現在的問題是裝置管理器選擇哪個節點作為活動PID?

這些用例場景進一步說明了這一點：

使用案例1:IP電話註冊到節點1。未配置路由清單。

在此，SIP中繼在節點1和4上處於活動狀態。

- 一般邏輯保持不變，CUCM會在註冊電話的節點1上進行數字分析。由於未配置RouteList，因此路由模式直接與SIP中繼關聯。

- 節點1上的CUCM查詢節點1上的裝置管理器。

- 裝置管理器(DM)始終首先檢查本地表，如果存在本地表，則返回本地裝置，以避免不必要的群集間通訊/流量。

在這種情況下，SIP中繼在註冊電話的節點1上處於活動狀態，因此CUCM會延長來自節點1的呼叫（每次）。 此處不應用隨機邏輯，並且不存在負載平衡，因為每次呼叫都是從節點1進行擴展。

使用案例2:註冊到節點1的IP電話。註冊到節點2的RouteList。

在此，SIP中繼在節點2和4上處於活動狀態。

- 在數字分析(DA)結果之後，CUCM節點1將呼叫擴展到節點2中的RouteList控制元件。

- 節點2上的RouteList Control查詢節點2上的裝置管理器。

- DM始終首先檢查本地表，如果存在本地裝置，則返回本地裝置，在這種情況下，SIP中繼是節點2的本地裝置。

因此，無論電話註冊在哪裡，由於RouteList註冊到節點2，而Sip中繼在同一節點上處於活動狀態，因此所有呼叫都是來自節點2的源呼叫。同樣，不應用隨機邏輯。

用例3:註冊到節點1的IP電話。註冊到節點2的RouteList。

在此，H323網關在節點1和4上處於活動狀態。

- 在DA結果之後，節點1上的CUCM將呼叫擴展到節點2上的RouteList控制。

- 節點2上的RouteList控制元件查詢節點2上的裝置管理器。

- 裝置管理器(DM)始終首先檢查本地表，然後返回本地裝置無。

- 裝置管理器查詢RemoteTable，並發現節點1和4上的H.323網關處於活動狀態。

它應用隨機邏輯，並隨機將主動PID賦給RouteList控制。由於是在節點1和4之間隨機傳送的，因此在CUCM中呼叫是負載均衡的。

結論

CUCM檢查SIP中繼/H.323網關是否在與呼叫裝置相同的節點上處於活動狀態。如果是，則它始終使用本地節點發出呼叫。

如果SIP中繼/H.323網關與呼叫裝置不在同一節點上處於活動狀態，則它會隨機從中繼/裝置處於活動狀態的節點進行源。

附註：呼叫裝置可以是電話或RouteList。 如果Route模式與RouteList匹配，則主叫方是RouteList。如果路由模式直接與SIP/H.323裝置關聯，則主叫方是電話。

負載平衡

如果要實現負載均衡，則不建議將RouteList或電話與SIP/H.323網關關聯的CUCM節點共置，即如果它們都在同一節點上處於活動狀態，則呼叫將從本地節點發出（始終）。

換句話說，需要配置SIP中繼/H.323網關，使其在註冊RouteList或電話的節點上處於非活動狀態。

從CUCM 8.6版開始，CUCM為兩個RouteList/SIP中繼引入了一項新功能，稱為Run on all active Unified CM Nodes。

這是對出站呼叫進行高效負載均衡並減少集群內交換訊號數量的另一種方式。

Callrouting Mechanism Post-CUCM 8.5（在所有使用中的Unified CM節點功能上運行）

在CUCM 8.5及更高版本中，思科在SIP中繼和路由清單中引入了一項新功能，稱為在所有活動的unified CM節點上運行。這基本上刪除了sip中繼和分配給它們的CUCM組上的路由清單的依賴關係。這意味著您可以擁有三台以上的CUCM伺服器，這些伺服器發起和終止來自sip中繼的呼叫。

SIP中繼 — 在所有節點和路由本地規則上運行

如果在SIP中繼上選中Run on all Active Unified CM Nodes選項，則Unified CM會在集群內的每個呼叫處理訂戶上建立SIP中繼後台程式的例項，從而允許在任何呼叫處理訂戶上發起或接收SIP中繼呼叫。（在此功能之前，通過使用Unified CM組，每個中繼最多可以選擇三個節點。）

啟用「在所有活動Unified CM節點上運行」後，出站SIP中繼呼叫源自接收入站呼叫（例如，來自電話或中繼）的同一節點（基於路由本地規則）。 在所有活動Unified CM節點上運行功能會覆蓋中繼的Unified CM組配置。

對於SIP中繼，這是路由本地規則的運行方式：

對於出站SIP中繼呼叫，當註冊電話或入站中繼的呼叫到達Unified CM節點時，Unified CM會檢查所選出站中繼的例項是否存在於入站呼叫到達的同一節點上。如果是，Unified CM使用此節點建立出站中繼呼叫。

強烈建議在SIP中繼上啟用Run on all Active Unified CM Nodes，因為此功能允許從集群內的任何呼叫處理節點發起和接收出站呼叫。在所有Active Unified CM節點上運行時，還可以避免在同一集群內的呼叫處理節點之間設定呼叫，然後再通過出站SIP中繼建立。

與所有Unified CM SIP中繼一樣，與中繼關聯的SIP守護程式僅接受來自終端系統的入站呼叫，這些終端系統的IP地址在中繼的目標地址欄位中定義。

當到達同一目的地的多個SIP中繼使用相同的呼叫處理節點時，每個中繼必須定義唯一的傳入埠號和目的地埠號，以允許唯一地標識每個中繼。

路由清單 — 在所有節點和路由本地規則上運行

雖然這並非具體的SIP中繼功能，但在所有節點上運行路由清單可為路由清單和路由組中的中繼帶來好處。在所有節點上運行路由清單通過使用路由本地規則來避免不必要的集群內呼叫設定流量，從而改善出站呼叫分佈。

對於路由清單，這是路由本地規則的運行方式：

對於使用路由清單（以及關聯的路由組和中繼）的出站呼叫，當來自註冊電話或入站中繼的呼叫到達具有路由清單例項的節點時，Unified CM會檢查所選出站中繼的例項是否存在於與路由清單相同的節點上。如果是，Unified CM使用此節點建立出站中繼呼叫。

- 如果路由清單和中繼都啟用了在所有活動Unified CM節點上運行，則撥出呼叫分佈由入站呼叫到達的節點決定。

- 如果所選出站中繼使用Unified CM組而不是在所有節點上運行，則如果所選出站中繼的例項存在於入站呼叫到達的同一節點上，則Unified CM將應用本地路由規則。

- 如果此節點上不存在中繼例項，則Unified CM會將呼叫（在集群內）轉發到中繼處於活動狀態的節點。

- 如果路由清單未啟用Run on all Active Unified CM Nodes（在所有活動Unified CM節點上運行），則路由清單例項在集群內的一個節點（路由清單的Unified CM組的主節點）上將處於活動狀態。

- 如果所選出站中繼在路由清單的Unified CM組的主節點上也處於活動狀態，則會應用路由本地規則，從而導致非最佳出站呼叫分配，因為所有出站中繼呼叫均源自此節點。

思科強烈建議在所有路由清單和SIP中繼上啟用在所有活動Unified CM節點上運行。