SIP/H323トランクのCUCMコール分散メカニズム

概要

このドキュメントでは、Session Initiation Protocol(SIP)またはH.323ベースのトランクを介してコールを送信するために使用されるCUCMノードを決定するためにCisco Unified Communications Managerが使用するモード操作について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Cisco Unified Communications Manager(CUCM)の基本的なコールルーティングの概念

使用するコンポーネント

 このドキュメントの情報は、Cisco Unified Communications Manager(CUCM)8.x以降に基づくものです。

 このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

SIPトランクおよびH.323ゲートウェイは、CUCMに登録されません（MGCPゲートウェイとは異なります）。 代わりに、トランクまたはゲートウェイに接続されたデバイスプールに関連付けられたCUCMグループによって、それらのグループがアクティブになる場所が決定されます。たとえば、2つまたは3つのノードでアクティブになっている場合、コールを送信するサーバを決定するためにCUCMが使用するメカニズムは何ですか。

このドキュメントの目的は、コールルーティングの決定を行う方法と、SIPトランクまたはH.323経由の発信コールに対してロードバランシングを実現する方法を説明することです。

Callrouting Mechanism Pre-CUCM 8.5（すべてのアクティブなUnified CMノードで実行する機能を使用しない）

一般的なロジック：発信コールでは、CUCMが番号分析を行うと、コールがルートリストまたはエンドデバイスに拡張されます。  （RouteListはCUCMグループに応じて特定のノードに登録されます）

RouteListコントロールは、デバイスのリストを識別し、デバイスマネージャに照会します。
デバイスマネージャがデバイスのプロセスID(PID)(例：(2,100,25,45)。この例では、デバイスはノード2でアクティブです。

ルートリストコントロールは、デバイスのステータス（ターゲットデバイスがアクティブ、アイドル、ビジー）をチェックし、トランクまたはゲートウェイにコールを拡張します。

SIPトランク/H.323ゲートウェイは複数のノード上でアクティブにできるため、デバイスマネージャによってアクティブPIDとして選択されているノードが次のうちどれか？

次のユースケースのシナリオは、この点をさらに明らかにします。

使用例1:ノード1に登録されたIP Phone。ルートリストが設定されていません。

このSIPトランクでは、ノード1と4がアクティブです。

• 一般的なロジックは変わりませんが、CUCMは電話機が登録されているノード1で番号分析を行います。RouteListが設定されていないため、ルートパターンはSIPトランクに直接関連付けられます。
  
  
• ノード1のCUCMは、ノード1のデバイスマネージャに照会します。
  
  
• Device Manager(DM)は必ず最初にローカルテーブルをチェックし、ローカルデバイスがある場合はローカルデバイスを返して、クラスタ間の不要な通信/トラフィックを回避します。

この場合、電話機が登録されているノード1でSIPトランクがアクティブであるため、CUCMはノード1から（毎回）コールを拡張します。 ランダムなロジックはここでは適用されず、どの場合でもノード1からコールが拡張されるため、ロードバランシングは行われません。

使用例2:ノード1に登録されたIP Phone。ノード2に登録されたルートリスト。

このSIPトランクでは、ノード2および4でアクティブです。

• 番号分析(DA)の結果、CUCMノード1はノード2のRouteList Controlにコールを拡張します。
  
  
• ノード2のRouteList Controlは、ノード2のデバイスマネージャに照会します。
  
  
• DMは常に最初にローカルテーブルをチェックし、ローカルデバイスがある場合はローカルデバイスを返します。この場合、SIPトランクはノード2に対してローカルです。

その結果、電話機が登録されている場所に関係なく、RouteListはノード2に登録され、Sipトランクは同じノードでアクティブであるため、すべてのコールはノード2から発信されます。ここでも、ランダムロジックは適用されません。

使用例3:ノード1に登録されたIP Phone。ノード2に登録されたルートリスト。

このH323ゲートウェイは、ノード1および4でアクティブです。

• DAの結果、ノード1のCUCMはノード2のRouteListコントロールにコールを拡張します。
  
  
• ノード2のRouteListコントロールは、ノード2のデバイスマネージャに照会します。
  
  
• Device Manager(DM)は常に最初にローカルテーブルをチェックし、ローカルデバイスnoneを返します。
  
  
• Device ManagerはRemoteTableを検索し、ノード1と4でH.323ゲートウェイがアクティブであることを確認します。

ランダムロジックを適用し、アクティブなPIDをRouteListコントロールにランダムに与えます。ノード1と4の間でランダムに送信されるため、コールはCUCMでロードバランシングされます。

結論

CUCMは、SIPトランク/H.323ゲートウェイが発信側デバイスと同じノードでアクティブであるかどうかを確認します。その場合、ローカルノードを使用してコールを送信します。
SIPトランク/H.323ゲートウェイが発信側デバイスと同じノードでアクティブでない場合、トランク/デバイスがアクティブなノードからランダムにソースが送信されます。

注：発信側デバイスは、電話機またはルートリストのいずれかです。 ルートパターンがルートリストと一致する場合、発信側はルートリストです。ルートパターンがSIP/H.323デバイスに直接関連付けられている場合、発信側が電話機になります。

ロード バランシング

ロードバランシングを実現する場合は、SIP/H.323ゲートウェイが関連付けられているCUCMノードとRouteListまたは電話機を同じノード上で両方ともアクティブな場合、ローカルノード（常に）からコールが送信されます。

つまり、SIPトランク/H.323ゲートウェイは、ルートリストまたは電話機が登録されているノードでアクティブにならないように設定する必要があります。

CUCMバージョン8.6以降では、CUCMは両方のRouteList/SIPトランクに対してすべてのアクティブなUnified CMノードで実行するという新機能を導入しました。     

これは、発信コールを効率的にロードバランシングし、クラスタ内で交換される信号数を減らすもう1つの方法です。

Callrouting Mechanism Post-CUCM 8.5（使用されているすべてのアクティブなUnified CMノードで実行）

CUCM 8.5以降では、シスコはSIPトランクとルートリストに新しい機能を導入しました。この機能は、すべてのアクティブなunified CMノードで実行します。これにより、基本的にsipトランクの依存関係とそれらに割り当てられたCUCMグループのルートリストが削除されます。これは、sipトランクとの間でコールを発信および終端するCUCMサーバを3つ以上使用できることを意味します。

SIPトランク：すべてのノードで実行され、ルートローカルルール

SIPトランクでRun on all Active Unified CM Nodesオプションをオンにすると、Unified CMはクラスタ内のすべてのコール処理サブスクライバでSIPトランクデーモンのインスタンスを作成し、SIPトランクコールを任意のコール処理サブスクライバで送受信できます。（この機能を使用する前に、Unified CMグループを使用してトランクごとに最大3つのノードを選択できます）。

[すべてのアクティブなUnified CMノードで実行(Run on all Active Unified CM Nodes)]を有効にすると、発信SIPトランクコールは、着信コール（電話機やトランクなど）を受信したのと同じノードから発信されます（ルートローカルルールに基づく）。 [Run on all Active Unified CM Nodes]機能は、トランククのUnified CM Group設定を上書きします。

SIPトランクの場合、ルートローカルルールの動作方法は次のとおりです。

発信SIPトランクコールの場合、登録済みの電話機または着信トランクからのコールがUnified CMノードに着信すると、Unified CMは、選択した発信トランクのインスタンスが、着信コールが着信した同じノードに存在するかどうかを確認します。その場合、Unified CMはこのノードを使用して発信トランクコールを確立します。

SIPトランク上のすべてのアクティブなUnified CMノードで実行を有効にするには、この機能を使用すると、クラスタ内の任意のコール処理ノードから発信コールを発信および受信できるため、強く推奨されます。すべてのアクティブなUnified CMノードで実行すると、発信SIPトランクを介して確立される前に、同じクラスタ内の呼処理ノード間でコールが設定されないようにすることもできます。

すべてのUnified CM SIPトランクと同様に、トランクに関連付けられたSIPデーモンは、トランクの宛先アドレスフィールドに定義されたIPアドレスを持つエンドシステムからの着信コールのみを受け入れます。

同じ宛先への複数のSIPトランクが同じ呼処理ノードを使用している場合、トランクごとに一意の着信ポート番号と宛先ポート番号を定義して、各トランクを一意に識別できるようにする必要があります。

ルートリスト：すべてのノードおよびルートローカルルールで実行

これは特にSIPトランク機能ではありませんが、すべてのノードでルートリストを実行すると、ルートリストとルートグループのトランクに利点があります。すべてのノードでルートリストを実行すると、ルートローカルルールを使用してクラスタ内コール設定の不要なトラフィックを回避することで、アウトバウンドコールの分散が改善されます。

ルートリストの場合、ルートローカルルールの動作方法は次のとおりです。

ルートリスト（および関連するルートグループとトランク）を使用する発信コールでは、登録済みの電話機または着信トランクからのコールがルートリストインスタンスを持つノードに到達すると、Unified CMは選択した発信トランクのインスタンスがルートリストと同じノードにに存在するかどうかを確認します。その場合、Unified CMはこのノードを使用して発信トランクコールを確立します。

• ルートリストとトランクの両方でRun on all Active Unified CM Nodesが有効になっている場合は、発信コールの分配は、着信コールが到達するノードによって決定されます。
  
  
• 選択したアウトバウンドトランクがすべてのノードで実行されるのではなくUnified CMグループを使用する場合、Unified CMは、選択したアウトバウンドトランクのインスタンスが着信コールが着信する同じノードに存在する場合にルートローカルルールを適用します。
  
  
• トランクのインスタンスがこのノードに存在しない場合、Unified CMは（クラスタ内の）コールを、トランクがアクティブなノードに転送します。
  
  
• ルートリストで[すべてのアクティブなUnified CMノードで実行(Run on all Active Unified CM Nodes)]が有効になっていない場合、ルートリストのインスタンスは、クラスタ内の1つのノード（ルートリストのUnified CMグループのプライマリノード）でアクティブになります。
  
  
• 選択した発信トランクがルートリストのUnified CMグループのプライマリノードでもアクティブな場合、ルートローカルルールが適用され、すべての発信トランクコールがこのノードから発信されるため、最適でない発信コールの分配が行われます。

すべてのルートリストとSIPトランクで[すべてのアクティブなUnified CMノードで実行(Run on all Active Unified CM Nodes)]を有効にすることを強く推奨します。