Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) Cisco Unified CallManager Release 5.0

トポロジ非対応コール アドミッション制御

トポロジ非対応コール アドミッション制御とは、IP WAN で接続されたリモート サイトとの間の同時コール数を制限することを目的とし、コール処理エージェントまたは IP ベースの PBX 内の静的設定に基づくメカニズムです。

図9-2 に示すように、このようなメカニズムのほとんどは、一般に企業 IP WAN に接続される地理上の支店に対応する、論理的な「サイト」エンティティの定義に依存しています。

各支店にあるすべてのデバイスを対応するサイト エンティティに割り当てた後に、管理者がそのサイトを宛先または発信元とするコールの許容最大数（または帯域幅の最大量）を設定するのが一般的です。

新しいコールの確立が必要になるたびに、コール処理エージェントは発信エンドポイントおよび終端エンドポイントが属するサイトをチェックし、（関係する両サイトのコール数または帯域幅の量に関して）コールに利用できるリソースがあるかどうか確認します。チェックが成功した場合、そのコールは確立され、両サイトのカウンタが減少します。チェックに失敗した場合、コール処理エージェントは事前に設定されたポリシーに基づいてコールの処理方法を決定できます。たとえば、発信者のデバイスにネットワーク ビジー信号を送信したり、公衆網接続を通じて再ルーティングを試行します。

図9-2 トポロジ非対応コール アドミッション制御の原理

トポロジ非対応のコール アドミッション制御メカニズムは静的設定に依存しているため、一般に比較的単純な IP WAN トポロジのネットワークだけに配置できます。実際、このようなメカニズムのほとんどでは、図9-3 に示すような単純なハブアンドスポーク トポロジまたは単純な MPLS ベースのトポロジ（MPLS サービスがサービス プロバイダーによって提供される場合）が必要です。

図9-3 トポロジ非対応コール アドミッション制御に適したドメイン

図9-3 に示すようなハブアンドスポーク ネットワークまたは MPLS ベースのネットワークで、各スポーク サイトはコール処理エージェント内の「サイト」に割り当てられ、その「サイト」のコール数または帯域幅の量は、そのスポークを IP WAN に接続する IP WAN リンク上の音声またはビデオ（あるいはその両方）に利用可能な帯域幅と一致するように設定されます。

スポーク サイトからハーブ サイトへの冗長リンクと、2 つのスポーク サイトを直接接続するリンクがないことに注意してください。次の項では、トポロジ非対応コール アドミッション制御で、このようなリンクが問題を発生させる理由について説明します。

トポロジ非対応コール アドミッション制御の制限

現在の企業ネットワークでは、高可用性は共通の要件であり、そのために IP WAN ネットワーク接続に冗長性が求められることがあります。

代表的な企業ネットワークにおける IP WAN トポロジについて考えると、純粋なハブアンドスポーク トポロジの前提を複雑にする数多くの特性があることがわかります。図9-4 は、このようなネットワーク特性のいくつかを 1 つの図にまとめたものです。すべての特性が一度に現れるのは大規模な企業ネットワークだけですが、多くの IP WAN ネットワークでも最低 1 つの特性が存在していることがよくあります。

図9-4 代表的な企業ネットワークのトポロジ特性

「コール アドミッション制御の設計」の項で説明するように、複雑なネットワーク トポロジにトポロジー非対応コール アドミッション制御メカニズムを適用できる場合がありますが、この方法を利用できる場合と、実現できる動作に関して制限があります。たとえば、冗長性がネットワーク要件となっている IP WAN を通じてハブ サイトに接続される支店サイトの単純なケースについて考えます。一般的に、冗長性は次のいずれかの方法で実現できます。

• IP WAN へのプライマリ リンクとバックアップ リンクを備えた 1 台のルータ

• ロード バランシング設定で 2 つのアクティブな WAN リンクを備えた 1 台のルータ

• それぞれが IP WAN に接続され、ロード バランシングされたルーティングを行う 2 つのルータ プラットフォーム

図9-5 の例では、プライマリ リンクとバックアップ リンクを備えた 1 台のルータの場合と、2 つのアクティブなロード バランシング リンクを備えた 1 台のルータの場合に、トポロジ非対応コール アドミッション制御メカニズムを適用しようとしています（2 つのルータ プラットフォームの場合のコール アドミッション制御に対する影響は、後者の例と同じです）。

図9-5 デュアル リンクが存在する場合のトポロジ非対応コール アドミッション制御

図9-5 の最初の例で、支店 A は通常、最大 10 の同時コールが可能になるよう、Low Latency Queuing（LLQ; 低遅延キューイング）帯域幅がプロビジョニングされたプライマリ リンクを通じて、IP WAN に接続されます。このプライマリ リンクに障害が発生した場合、小さい方のバックアップ リンクがアクティブになり、IP WAN への接続を維持します。ただし、このバックアップ リンクの LLQ 帯域幅は、最大 2 つの同時コールだけが可能なようにプロビジョニングされています。

この支店にトポロジ非対応コール アドミッション制御メカニズムを配置するには、コール処理エージェントで「サイト」A を定義し、一定のコール数（または帯域幅の量）を設定する必要があります。サイト A の最大値として 10 コールを使用する場合、プライマリ リンクの障害時にバックアップ リンクにオーバーランが発生し、すべてのアクティブなコールで音声の品質が低下する可能性があります。これに対して、最大値を 2 コールにした場合、プライマリ リンクがアクティブなときは、残りの 8 コールに対してプロビジョニングされた帯域幅を使用できません。

次に、IP WAN に接続する 2 つのアクティブなリンクを備えた支店 B について考えます。各リンクは、最大 10 の同時コールが可能なようにプロビジョニングされ、ルーティング プロトコルは各リンク間のロード バランシングを自動的に実行します。この支店にトポロジ非対応コール アドミッション制御メカニズムを配置する場合、コール処理エージェントで「サイト」B を定義し、一定のコール数（または帯域幅の量）を設定する必要があります。支店 A の場合と同様に、2 つのリンクの容量を増強し、サイト B の最大値として 20 コールを使用する場合、一方のリンクの障害時に、もう一方のリンクで LLQ のオーバーランが発生する可能性があります。たとえば、リンク #2 に障害が発生した場合、サイト B を宛先または発信元とする 20 の同時コールが引き続き可能です。これらのコールは、すべてリンク #1 を通じてルーティングされるようになるため、オーバーランが発生し、すべてのコールで音声品質が低下します。これに対して、最大 10 の同時コールでサイト B を設定した場合、（両方のリンクが動作している）通常の条件では、使用可能な LLQ 帯域幅が十分に活用されなくなります。

上記の 2 つの単純な例は、実際の企業ネットワークでの IP WAN 帯域幅のプロビジョニングが非常に複雑で、コール処理エージェント内の静的に設定されたエントリにまとめられない場合があることを示しています。このようなネットワークでトポロジ非対応コール アドミッション制御を配置すると、管理者は推測をしたり、回避策を取ったり、最適ではないネットワーク リソースの使用を許容したりする必要があります。

単純なハブアンドスポークに従わないネットワーク トポロジが存在する場合にコール アドミッション制御を提供する最適な方法は、次の項で説明するようにトポロジ対応コール アドミッション制御を実装することです。

（注） 一部の IP テレフォニー システムは、ネットワークで観察された輻輳に基づくフィードバック メカニズムで、従来のトポロジ非対応コール アドミッション制御を拡張します。これにより、音声品質が低下した場合、コールが強制的に公衆網経由になります。コール処理エージェントはコールの確立後に実行されることと、輻輳が発生している正確な場所を認識しないという理由から、この方法はまだ真のトポロジ対応コール アドミッション制御と同等ではありません。この章の最初に述べたように、効果的に運用するには、コールをセットアップする前にコール アドミッション制御を実行する必要があります。

トポロジ対応コール アドミッション制御

トポロジ対応コール アドミッション制御とは、IP WAN リンクを通じた同時コール数を制限することを目的とするメカニズムであり、任意のネットワーク トポロジに適用でき、またトポロジの変更にも動的に適応できます。

このような目的を達成するには、トポロジ対応コール アドミッション制御は、コール処理エージェント（または IP ベースの PBX）とネットワーク間のネットワーク リソースの可用性に関するリアルタイム通信を利用する必要があります。ネットワークは分散エンティティであるため、リアルタイムの通信にはシグナリング プロトコルが必要です。

Resource Reservation Protocol（RSVP; リソース予約プロトコル）は、アプリケーションが IP ネットワークを通じて動的に帯域幅を予約できるようにするための、最初の重要な業界標準シグナリング プロトコルです。RSVP を使用すると、アプリケーションはネットワークを通じたデータ フロー（音声コールなど）のために一定の帯域幅を要求し、実際のリソースの可用性に基づいて予約結果の通知を受け取ることができます。

音声コールまたはビデオ コールのためのコール アドミッション制御の特定のケースで、IP ベースの PBX は、2 つのリモート サイト間でコール セットアップ プロセスを RSVP 予約と同期し、予約の結果に基づいてルーティングの決定を行います。分散型ネットワークに対応し、動的に機能する性質を持っているため、RSVP はあらゆるネットワーク トポロジにわたって帯域幅を予約できます。つまり、本格的なトポロジ対応コール アドミッション制御メカニズムを提供します。

RSVP がネットワークで帯域幅予約を実行する方法の基本的な原理を理解するために、図9-6 に示す簡単な例について考えます。この例では、メッセージ交換とプロトコルの動作自体については説明しません。機能によってもたらされる結果を中心に説明します。RSVP メッセージ交換の詳細については、「RSVP の原理」を参照してください。

図9-6 に示すネットワークの各ルータ インターフェイスで、RSVP が有効になっているとします。円で囲まれた数値は、各インターフェイス上に残っている使用可能な RSVP 帯域幅の量を表しています。

図9-6 RSVP の原理を示すためのサンプル ネットワーク

ここで、RSVP 対応のアプリケーションが、2 つのデバイス間でのデータ ストリーム用に一定の帯域幅を予約するとします。このシナリオを図9-7 に示します。この図では、デバイス 1 からデバイス 2 への個々のデータ ストリームで、24 Kbps の帯域幅を要求することを示しています。

図9-7 予約が成功する RSVP シグナリング

ここでは、図9-7 について説明します。

• RSVP は、自身ではルーティングを実行しません。代わりに、下層で機能しているルーティング プロトコルを使用して、予約要求の宛先を決定します。トポロジの変更に対応するためにルーティングのパスが変化すると、RSVP は、自身の予約を予約が存在する新しいパスに合せて調整します。

• RSVP プロトコルは、デバイス 1 からデバイス 2 へのパスにあるすべての RSVP 対応ルータ上で、使用可能な帯域幅リソースを確認することによって、エンドツーエンドの予約を確立しようとします。図9-7 に示すように、RSVP メッセージがネットワークを進んでいくとき、発信側ルータ インターフェイスでは、使用可能な RSVP 帯域幅が 24 Kbps ずつ減分されます。

• 使用可能な帯域幅がすべての発信側インターフェイスで十分にあり、この新しいデータ ストリームを受け付けることができる場合は、予約が成功し、アプリケーションに通知されます。

• RSVP 予約は単方向です。この例では、予約はデバイス 1 からデバイス 2 に向かって確立され、逆方向については確立されません。音声会議やビデオ会議などの双方向アプリケーションがある場合は、各方向について 1 つずつ、2 つの予約を確立する必要があります。

• RSVP は、RSVP をサポートしないルータ ノードでは透過的に動作します。RSVP に対応しないルータがパスに存在していても、それらのルータは単に RSVP メッセージを無視して、他の IP パケットと同様に渡すだけであり、予約を確立することは可能です（プロトコルのメッセージと動作の詳細については、「RSVP の原理」を参照してください）。ただし、エンドツーエンドでの QoS を確保するには、この RSVP 非対応のルータが制御するリンク上で、帯域幅の輻輳が発生しないようにする必要があります。

デバイス 1 とデバイス 2 の間で予約が正常に確立された後に、別のアプリケーションがデバイス 3 とデバイス 4 の間で 24 Kbps の予約を要求したとします（図9-8 を参照）。

図9-8 予約が成功しない RSVP シグナリング

ここでは、図9-8 について説明します。

• RSVP プロトコルは、デバイス 3 からデバイス 4 へのパスにあるすべての RSVP 対応ルータ上で、使用可能な帯域幅リソースを確認することによって、エンドツーエンドの予約を確立しようとします。図9-8 に示すように、RSVP メッセージがネットワークを進んでいくとき、発信側ルータ インターフェイスでは、使用可能な RSVP 帯域幅が 24 Kbps ずつ減分されます。

• この例では、R6 に対する R5 の発信側インターフェイス上に、この新しいデータ ストリームを受け付けるための使用可能な帯域幅が十分にありません。このため、予約は失敗し、アプリケーションに通知されます。パスに含まれている各発信側インターフェイス上の使用可能な RSVP 帯域幅は、以前の値に戻されます。

• 次にどのように処理するかは、アプリケーションが決定します。データの転送を放棄することも、何らかの方法で QoS 保証のないベストエフォート型トラフィックとして送信することもできます。

ここで、前の項で紹介した二重接続される支店 A および B の例に、RSVP に基づくトポロジ対応コール アドミッション制御方法を適用できます。

図9-9 に示すように、支店 A には 10 コール用にプロビジョニングされた LLQ を備えるプライマリ リンクと、2 つのコールだけを許容するバックアップ リンクがあります。この方法で RSVP は、RSVP 帯域幅が LLQ 帯域幅と一致するように、両方のルータ インターフェイスで設定されます。支店 A は、他の支店を宛先または発信元とするすべてのコールの RSVP 予約を要求するために、コール処理エージェント内でも設定されます。これで、コールは、ルーティング プロトコルによって決定されるパスに自動的に従う RSVP 予約の結果に基づいて、許可または拒否されるようになります。通常の条件下では（プライマリ リンクがアクティブな場合）、最大 10 コールが許容されます。プライマリ リンクの障害時には、最大 2 コールだけが許容されます。

ポリシーは、一般にコール アドミッション制御に障害が発生した場合の動作を決定するために、コール処理エージェント内で設定できます。たとえば、コールを拒否したり、公衆網を通じて再ルーティングしたり、異なる DSCP マーキングでのベストエフォート コールとして IP WAN を通じて送信したりすることができます。

図9-9 デュアル リンクのトポロジ対応コール アドミッション制御

図9-9 の右側に示すように、2 つのロード バランシング リンクを通じて IP WAN に接続される支店 B にも、同様の考慮事項が該当します。RSVP は、LLQ 設定と一致する帯域幅の値（この場合は、10 コールに対して十分な帯域幅）で、2 つのルータ インターフェイスのそれぞれで有効になります。支店 B は、他の支店との間のコール用に RSVP 予約を要求するため、コール処理エージェント内でも設定されます。このときも、コールはルーティング プロトコルが決定するパスに沿って、使用可能な実際の帯域幅に基づいて許可または拒否されるようになります。したがって、2 つのリンクを通じた完全に均等なロード バランシングの場合、（両方のリンクが動作している）通常の条件下で最大 20 コールを許容できます。2 つのリンクのいずれかに障害が発生した場合は、最大 10 コールだけが許容されます。

10 を超えるコールがアクティブなときに 2 つのリンクのいずれかに障害が発生した場合、一部のコールは新しいパスでの予約の再確立に失敗します。この時点で、コール処理エージェントは通知を受け、設定されたポリシーに基づいて対応することができます（追加のコールをドロップしたり、ベストエフォート コールとして再マーキングします）。

要するに、トポロジ対応コール アドミッション制御によって、管理者は任意のネットワーク トポロジでコール品質を保護し、トポロジの変更に自動的に適応し、すべての状況の下でネットワーク リソースを最適に使用することができます。

MPLS ネットワークの特別な考慮事項

コール アドミッション制御の点から見ると、ネットワークの「ハブ」での RSVP のサポートに関して、MPLS に基づくネットワークは従来のレイヤ 2 WAN サービスに基づくネットワークとは異なっています。従来のレイヤ 2 WAN は、ほとんどの場合、RSVP への参加を有効にできる企業管理のルータから構成されます。MPLS ネットワークではネットワーク全体（クラウド）が「ハブ サイト」であるため、RSVP を有効にするための企業管理のハブ ロケーションは存在しません（詳細については、「単純な MPLS トポロジ」を参照してください）。したがって、MPLS 環境でトポロジ対応コール アドミッション制御を提供するには、RSVP のサポート用にネットワークの Customer Edge（CE）デバイスを設定する必要があります。

RSVP は CE で有効にする必要があるため、この機器の制御は重要です。この機器が企業で管理されていない場合、サービス プロバイダーに問い合せて、WAN インターフェイスで RSVP が有効になっているかどうか、およびその実装で RSVP アプリケーション ID などの高度な機能がサポートされるかどうかを確認する必要があります。

RSVP メッセージは、RSVP 非対応 MPLS クラウドを透過的に通過するため、エンドツーエンドの RSVP 機能で問題は生じません。CE WAN インターフェイスで RSVP を設定すると、そのプライオリティ キューにオーバーランが発生しなくなります。RSVP 予約は単方向であるため、RSVP が MPLS クラウドで有効になっていない場合、Provider Edge（PE）ルータでプライオリティ キューを保護するには、次の規則に従う必要があります。

• メディア ストリームを両方向で同じサイズにする。

• メディアを対称的にルーティングする。

MPLS ネットワークがこれらの規則に従っていない場合は、RSVP を実装する前にシスコのアカウント チームにお問い合せください。

Cisco Unified CallManager の静的ロケーション

Cisco Unified CallManager では、集中型コール処理配置において、コール アドミッション制御を実装するために、「静的ロケーション」と呼ばれている単純なメカニズムを取り入れています。Cisco Unified CallManager でデバイスを設定するときは、そのデバイスをロケーションに割り当てることができます。各ロケーションとの間のコールに対しては、特定の帯域幅が割り当てられます。Cisco Unified CallManager で設定するロケーションは、仮想ロケーションであり、実際の物理ロケーションではありません。Cisco Unified CallManager は、デバイスの物理的なロケーションを認識しません。このため、デバイスをある物理ロケーションから別のロケーションに移動する場合は、システム管理者がロケーション設定を手動でアップデートして、Cisco Unified CallManager がそのデバイスの帯域幅割り当てを正しく計算できるようにする必要があります。各デバイスは、デフォルトでは Hub_None ロケーションに配置されます。ロケーション Hub_None は、デフォルトで設定される特別なロケーションで、無制限の音声およびビデオの帯域幅が割り当てられます。ロケーション Hub_None は削除できません。支店ロケーションにあるデバイスが Hub_None ロケーションに設定されている場合、その支店デバイスが宛先または発信元となっている電話コールはすべて、コール アドミッション制御の対象となりません。

Cisco Unified CallManager では、各ロケーションに対して音声およびビデオの帯域幅プールを定義できます。ロケーションの音声帯域幅とビデオ帯域幅が Unlimited に設定されている場合、そのロケーションでは帯域幅を無限に使用できるため、そのロケーションが宛先または発信元となる音声コールとビデオ コールは、Cisco Unified CallManager ではすべて許可されます。帯域幅の値が有限のキロビット/秒（Kbps）に設定されている場合は、アクティブになっているすべてのコールで使用されている合計帯域幅が、その設定値以下になっている場合に限り、Cisco Unified CallManager は、そのロケーションで入出力されるコールを許可します。ロケーションのビデオ帯域幅を None に設定した場合、このロケーションが宛先または発信元となるすべてのビデオ コールは拒否されます。ただし、このロケーションの内部でやり取りされるビデオ コールには影響しません。

ビデオ コールの場合、ビデオ ロケーションの帯域幅については、コールのビデオ部分と音声部分の両方を考慮に入れる必要があります。したがって、ビデオ コールの場合、帯域幅が音声帯域幅プールから差し引かれることは一切ありません。

ロケーションでメンバーシップを指定できるデバイスには、次のものがあります。

• IP Phone

• CTI ポート

• H.323 クライアント

• CTI ルート ポイント

• コンファレンス ブリッジ

• Music On Hold（MoH）サーバ

• ゲートウェイ

• トランク

静的ロケーションのコール アドミッション制御メカニズムでは、通話中のコール タイプ変更も考慮に入れる必要があります。たとえば、サイト間でビデオ コールを確立する場合、Cisco Unified CallManager は、それぞれのロケーションから適切なビデオ帯域幅を差し引きます。このビデオ コールが、ビデオ非対応のデバイスに転送する過程で音声専用コールに変更された場合、Cisco Unified CallManager は割り当てた帯域幅をビデオ プールに戻し、適切な帯域幅を音声プールから割り当てます。音声からビデオに変更されるコールについては、これとは逆の帯域幅割り当て変更が発生します。

表9-1 に、さまざまなコールのタイプ（ビットレート）において静的ロケーション アルゴリズムが要求する帯域幅を示します。音声コールでは、Cisco Unified CallManager は、メディア ビット レートにレイヤ 3 オーバーヘッドを加えて計算します。たとえば、G.711 音声コールは、ロケーションの音声帯域幅プールから割り当てられた 80 kbps を消費します。ビデオ コールでは、Cisco Unified CallManager は、音声ストリームとビデオ ストリームの両方に対して、メディア ビット レートだけを計算します。たとえば、384 kbps の速度のビデオ コールに対して、Cisco Unified CallManager はビデオ帯域幅プールから 384 kbps を割り当てます。

図9-10 では、使用可能な音声帯域幅 256 Kbps およびビデオ帯域幅 384 Kbps を指定した、ロケーション Branch 1 の設定を示しています。Branch 1 は、最高 3 つの G.711 音声コール（コールごとに 80 Kbps）、または 10 個の G.729 音声コール（コールごとに 24 Kbps）、または両方のコールの組み合せ（256 Kbps を超えないこと）をサポートできます。このロケーションでは、使用されているビデオ コーデックおよび音声コーデックに応じて、さまざまな数のビデオ コールをサポートすることもできます。たとえば、384 kbps の帯域幅を要求する 1 つのビデオ コール、またはそれぞれ 128 kbps の帯域幅を要求する 3 つのビデオ コールをサポートできます。

図9-10 Cisco Unified CallManager におけるロケーションの定義

コール アドミッション制御は、同じロケーション内のデバイス間のコールには適用されません。

あるロケーションから他のロケーションにコールが発信されると、Cisco Unified CallManager は、両方のロケーションから適切な帯域幅を差し引きます。たとえば、2 つのロケーション間の G.729 コールによって、Cisco Unified CallManager は、両方のロケーションで使用可能な帯域幅から 24 kbps を差し引きます。コールが完了すると、Cisco Unified CallManager は、帯域幅を差し引かれたロケーションに帯域幅を戻します。いずれかの支店ロケーションで十分な帯域幅がない場合、コールは Cisco Unified CallManager によって拒否され、発信者はネットワーク ビジー トーンを受け取ります。発信側デバイスが、ディスプレイを備えた IP Phone である場合、そのデバイスには、「Not Enough Bandwidth」というメッセージも表示されます。

サイト間コールがコール アドミッション制御によって拒否された場合、Cisco Unified CallManager は Automated Alternate Routing（AAR）機能を使用して、公衆網接続を通じて宛先にコールを自動的に再ルーティングできます。AAR 機能の詳細については、「Automated Alternate Routing」を参照してください。

（注） AAR が呼び出されるのは、帯域幅が不足しているために、ロケーション ベースのコール アドミッション制御によってコールが拒否される場合だけです。IP WAN が使用不可の場合や、接続に関するその他の問題によって着信側デバイスが Cisco Unified CallManager に登録されない状態になった場合には、AAR は呼び出されません。このような場合、コールは着信側デバイスの Call Forward No Answer フィールドで指定されている宛先に転送されます。

Cisco IOS ゲートキーパー ゾーン

Cisco IOS ゲートキーパーは、Cisco Unified CallManager、Cisco Unified CallManager Express、レガシー PBX に接続されている H.323 ゲートウェイなどのデバイス間で、コール ルーティングとコール アドミッション制御を提供できます。H.323 Registration Admission Status（RAS）プロトコルを使用してこれらのデバイスと通信し、コールをネットワークにルーティングします。

ゲートキーパーのコール アドミッション制御は、ポリシーベースの方式であり、使用可能なリソースの静的設定を必要とします。ゲートキーパーは、ネットワーク トポロジを認識しないので、単純なハブアンドスポーク トポロジに制限されます。トポロジの詳細な例については、「コール アドミッション制御の設計」の項を参照してください。

Cisco 2600、2800、3600、3700、3800、および 7200 シリーズのルータはすべて、ゲートキーパー機能をサポートします。冗長性、ロード バランシング、および階層コール ルーティング用に、さまざまな方法で Cisco IOS ゲートキーパーを設定できます。ここでは、ゲートキーパー機能のコール アドミッション制御の面を中心に説明します。冗長性とスケーラビリティに関する考慮事項については、「ゲートキーパーの設計上の考慮事項」を参照してください。コール ルーティングに関する考慮事項については、「ゲートキーパーを使用する Cisco IOS でのコール ルーティング」を参照してください。

Cisco IOS ゲートキーパーのコール アドミッション制御機能は、ゲートキーパーの「ゾーン」の概念に基づいています。ゾーンは、エンドポイント、ゲートウェイ、マルチポイント コントロール ユニット（MCU）などの、ゲートキーパーに登録される H.323 デバイスの集合です。アクティブになることができるゲートキーパーは、ゾーンごとに 1 つのみです。1 つのゲートキーパーには、ローカル ゾーンを 100 個まで定義できます。ローカル ゾーンは、当該のゲートキーパーがアクティブに処理しているゾーンです。つまり、このゾーンに割り当てられている H.323 デバイスは、すべて当該ゲートキーパーに登録されます。

複数のゲートキーパーを同一ネットワークに配置している場合、ゾーンがローカル ゾーンとして設定されるのは、1 つのゲートキーパー上のみです。他のゲートキーパーでは、このゾーンはリモート ゾーンとして設定されます。この設定によって、あるゾーンが宛先になっているコールを、そのゾーンを「所有」しているゲートキーパー（つまり、そのゾーンがローカル ゾーンとして設定されているゲートキーパー）に転送するようにゲートキーパーに指示しています。

ゲートキーパーで許可されるコールの数を管理する、つまりコール アドミッション制御機能を利用するには、 bandwidth コマンドを使用します。このコマンドにはいくつかのオプションがありますが、この機能と密接に関連するのは次のオプションです。

• interzone オプションによって、特定のローカル ゾーンで送受信されるすべてのコールの帯域幅の量を制御します。

• total オプションによって、特定のローカル ゾーンを宛先または発信元とするすべてのコール、そのローカル ゾーン内のすべてのコールの帯域幅の量を制御します。

• session オプションによって、特定のローカル ゾーンのコール 1 件あたりの帯域幅の量を制御します。

• remote オプションによって、すべてのリモート ゾーンで送受信される帯域幅の総量を制御します。

すべてのアクティブなコールに対してゲートキーパーによって差し引かれる帯域幅の値は、レイヤ 2、IP、および RTP のオーバーヘッドを除いた、コールのビットレートの倍です。たとえば、64 Kbps を使用する G.711 音声コールは、ゲートキーパーでは 128 Kbps と認識され、384 Kbps のビデオ コールは 768 Kbps と認識されます。 表9-2 に、一般に利用されているいくつかのコールビットレートにおいて、ゲートキーパーが使用する帯域幅の値を示します。

（注） コール ARQ（アドミッション要求）に対する帯域幅計算には、RTP ヘッダー圧縮（cRTP）やその他のトランスポートのオーバーヘッドは含まれません。インターフェイス キューのプロビジョニング方法の詳細については、「帯域幅のプロビジョニング」を参照してください。

実際のネットワークでの bandwidth コマンドの利用方法を深く理解するために、図9-11 に示す例について考えます。

図9-11 Cisco IOS ゲートキーパーの bandwidth コマンドの例

すべてのコールが G.711 コーデックを使用する音声専用コールであるとすると、図9-11 に示す設定コマンドについて、次のことがいえます。

• 1 回のコールに対してゾーン A で任意のデバイスによって要求される帯域幅の最大量は、128 kbps です。つまり、64 kbps よりも高いビットレートのコーデックを使おうとするコールは拒否されます。

• ゾーン A のデバイスに関係するすべてのコール（ゾーン内、またはその他のゾーンとの間）で使用される帯域幅の最大量は、384 kbps です。つまり、ゾーン A のデバイスに関係する最大 3 つのアクティブなコールが存在できます。

• ゾーン B のデバイスとその他のゾーンのデバイス間のすべてのコールによって使用される帯域幅の最大量は、256 kbps です。つまり、ゾーン B のデバイスと、ゾーン A、C、および D のデバイスの間には、最大 2 つのアクティブなコールが存在できます。

• ゲートキーパー GK 1 で登録されたデバイスと、その他のゲートキーパーで登録されたデバイスとの間のすべてのコールで使用される帯域幅の最大量は、512 kbps です。つまり、ゾーン A およびゾーン B のデバイスと、ゾーン C および ゾーン D のデバイスの間には、最大 4 つのアクティブなコールが存在できます。

Cisco Unified CallManager の RSVP 対応ロケーション

Cisco Unified CallManager Release 5.0 では、リソース予約プロトコル（RSVP）に基づくトポロジ対応コール アドミッション制御メカニズムが導入されました。このプロトコルは、すべてのネットワーク トポロジに適用可能で、従来のハブアンドスポーク トポロジの制限を緩和します。Cisco RSVP Agent は Cisco IOS の機能であり、Cisco Unified CallManager が RSVP ベースのコール アドミッション制御を実行できるようにするものです。Cisco RSVP Agent 機能は、Cisco IOS Release 12.4（6）T で導入され、Cisco 2600XM、2691、3700 シリーズ、2800 シリーズ、および 3800 シリーズの Integrated Services Routers プラットフォームで使用できます。

Cisco RSVP Agent は、Cisco Unified CallManager で、メディア ターミネーション ポイント（MTP）または RSVP をサポートするトランスコーダ デバイスのいずれかとして登録されます。エンドポイント デバイスが帯域幅の予約を必要としてコールを行う場合、Cisco Unified CallManager は、帯域幅を予約するためのエンドポイントに対するプロキシとして機能する Cisco RSVP Agent を呼び出します。

図9-12 は、Cisco Unified CallManager とさまざまなその他のデバイス間で使用されるシグナリング プロトコルと、特定のロケーションで WAN を通じたコールのために関連付けられる RTP ストリームを示しています。WAN を通じたすべてのコールで、Cisco Unified CallManager は、ローカル Cisco RSVP Agent にメディア ストリームを送信するようエンドポイント デバイスに指示します。このローカル Cisco RSVP Agent は、リモート ロケーションにある Cisco RSVP Agent への RSVP 予約と同期された別のコール レッグを発信します。図9-12 は、次のシグナリング プロトコルを示しています。

• Skinny Client Control Protocol（SCCP）による Cisco Unified CallManager への Cisco RSVP Agent の登録

• SCCP または Session Initiation Protocol（SIP）による Cisco Unified CallManager への IP Phone の登録

• Media Gateway Control Protocol（MGCP）、SIP、または H.323 プロトコルによる Cisco Unified CallManager への公衆網ゲートウェイの登録

図9-12 RSVP をサポートするロケーションのプロトコル フロー

図9-13 は、Cisco Unified CallManager クラスタ内の代表的な Cisco RSVP Agent 配置を示しています。これには、中央サイト、支店 1、および支店 2 の 3 つのロケーションが含まれます。3 つのロケーションを接続する IP WAN は、任意のトポロジ タイプにすることができ、ハブアンドスポーク トポロジに制限されません。メディア パスで RSVP 予約を必要とする 2 つのロケーション間のコールに対して、Cisco RSVP Agent のペアが、Cisco Unified CallManager から動的に呼び出されます。Cisco RSVP Agent は、Cisco RSVP Agent と同じロケーションにある IP Phone の RSVP 予約を行うためにプロキシとして動作します。たとえば、支店 1 の電話機 A が中央サイトの電話機 E をコールする場合、RSVP 予約が、支店 1 ロケーションと中央サイト ロケーションの Cisco RSVP Agent 間で確立されます（図9-13 の赤線）。

このコールのメディア ストリームに対しては、3 つのコール レッグがあります。第 1 のコール レッグは電話機 A と支店 1 の Cisco RSVP Agent との間、第 2 のコール レッグは支店 1 と中央サイトの Cisco RSVP Agent との間、第 3 のコール レッグは中央サイトの Cisco RSVP Agent と電話機 E との間です。同様に、支店 1 の電話機 B が、支店 2 の電話機 D をコールした場合、RSVP 予約が支店 1 と支店 2 の Cisco RSVP Agent 間で確立されます。この場合、2 つの支店ロケーション間のコールのメディア ストリームは、中央サイト経由で送信されません。静的ロケーションに基づき、コール アドミッション制御を使用して、従来のハブアンドスポーク トポロジを通じて行われるコールとは異なっています。

（注） RSVP 対応ロケーションおよび Cisco RSVP Agent を使用すると任意の WAN トポロジがサポートされますが、これらはロケーションに対するデバイスの静的な割り当てに基づいています。つまり、ある物理的なサイトから別のサイトにデバイスを移動するたびに、Cisco Unified CallManager の設定を更新する必要があります。

図9-13 Cisco RSVP Agent の概念

Cisco RSVP Agent のプロビジョニング

Cisco RSVP Agent 機能には、Cisco IOS Release 12.4（6）T および Cisco Unified Survivable Remote Site Telephony ライセンス、または Cisco Multiservice IP-to-IP Gateway ライセンス付きの Integrated Voice and Video Services イメージが必要です。同時コール（セッションとも呼ばれる）に対するその容量は、次の要因によって変化します。

• ソフトウェアベースの MTP 機能では、ルータ プラットフォームおよび相対的な CPU 負荷によってセッション容量が決まる（ 表9-3 を参照）。

• ハードウェアベースの MTP およびトランスコーダの機能では、使用可能な DSP の数によってセッション容量が制限される（DSP のサイズ選定の考慮事項については、「メディア リソース」を参照してください）。

ソフトウェアベースの MTP 機能に関して、 表9-3 は、Cisco RSVP Agent 専用のルータおよび 75% の CPU 利用率を基準としたセッション容量のガイドラインを示しています。これらの数値は、Cisco IOS Release 12.4（6）T に適用されるもので、大まかなガイドラインとみなす必要があります。特定のサービス、設定、トラフィック パターン、ネットワーク トポロジ、ルーティング テーブル、およびその他の要因の異なる組み合せは、特定の配置のパフォーマンスに著しい影響を与え、サポートされる同時セッション数が減少することがあります。実稼働環境でマルチサービス ルータを配置する前に、慎重に計画および検証試験を行うことをお勧めします。

（注） Cisco RSVP Agent が Cisco Unified Survivable Remote Site Telephony ライセンスで配置される場合、サポートされるセッション数は（表9-3 に示すように）ルータのパフォーマンスとライセンス権で決まります。Cisco RSVP Agent が Cisco Multiservice IP-to-IP Gateway ライセンスで配置される場合、サポートされるセッション数はルータのパフォーマンスだけで決まります。

Cisco RSVP Agent は、デバイス プール、メディア リソース グループ（MRG）、およびメディア リソース グループ リスト（MRGL）の設定の組み合せでエンドポイント デバイスに関連付けることができます。Cisco RSVP Agent は MRG に含めることができ、MRG は MRGL の要素になることができます。MRGL は、直接またはデバイス プールを通じてエンドポイント デバイスに割り当てることができます。図9-14 に示すように、MRGL-支店 1 は、直接または Device Pool-Branch 1 から IP Phone に関連付けることができます。一般に、エンドポイント デバイスがメディア リソースの一意のセットを要求する場合は、エンドポイント デバイス MRGL を直接割り当てます。それ以外の場合は、エンドポイント デバイスが配置されているデバイス プールに MRGL を割り当てます。

図9-14 IP Phone への MRGL の割り当て

Cisco Unified CallManager は、MTP、トランスコーダ、会議リソース、および Annunciator など、その他の従来のメディア リソースを割り当てるのと同じ方法で、Cisco RSVP Agent を割り当てます。

他の従来のメディア リソースと同じ MRG で、Cisco RSVP Agent を設定しないようにしてください。設定すると、コールが RSVP に関係しない場合であっても、MTP デバイスを必要とするコールに Cisco RSVP Agent が割り当てられます。

図9-15 は、Cisco RSVP Agent ロード バランシングが MRG および MRGL 設定によって実装される様子を示しています。同じ MRG 内のすべての Cisco RSVP Agent に対して、Cisco Unified CallManager は、ラウンドロビン方式で Cisco RSVP Agent に対してロード バランシングおよび割り当てを行います。

図9-15 Cisco RSVP Agent のロード バランシング

図9-15 に示すように、MRG-1 の両方の Cisco RSVP Agent が使用可能な場合、最初のコールに対して Agent-1 が選択され、2 番目のコールに対して Agent-2 が選択されます。MRG-1 でいずれの Cisco RSVP Agent も使用できない場合、Cisco Unified CallManager はコールに適した Cisco RSVP Agent が見つかるまで、MRG-2、MRG-3、および残りの MRG の検索を試行します。MRG に明示的に含まれていない Cisco RSVP Agent は、デフォルトで Null MRG に含まれています。Null MRG は常に MRGL 設定の最後の MRG として黙示的に含まれていますが、Cisco Unified CallManager Administration には表示されません。Null MRG の Cisco RSVP Agent は、Cisco Unified CallManager クラスタの任意のエンドポイント デバイスからアクセスできます。したがって、常に MRG で Cisco RSVP Agent を設定することをお勧めします。Cisco Unified CallManager のメディア リソース割り当てプロセスおよび関連するベスト プラクティスの詳細については、「メディア リソース」を参照してください。

Cisco RSVP Agent の登録

Cisco RSVP Agent は、RSVP をサポートする MTP またはトランスコーダ デバイスとして、Cisco Unified CallManager に登録されます。Cisco RSVP Agent は、MTP デバイスとして登録する場合、トランスコーディング機能をサポートしません。トランスコーディング機能をサポートするには、Cisco RSVP Agent をトランスコーダ デバイスとして Cisco Unified CallManager に登録する必要があります。

登録のスイッチオーバーとスイッチバック

プライマリ Cisco Unified CallManager に障害が発生した場合、Cisco RSVP Agent はセカンダリ Cisco Unified CallManager にスイッチオーバーします。プライマリ Cisco Unified CallManager が障害から回復すると、Cisco RSVP Agent はプライマリ Cisco Unified CallManager に登録をスイッチバックします。Cisco RSVP Agent 登録のスイッチオーバーとスイッチバックを設定するには、次のコマンドを使用します。

• switchover method immediate は、プライマリ Cisco Unified CallManager サーバの障害が検出されたら、すぐにセカンダリ Cisco Unified CallManager サーバに登録をスイッチオーバーすることを指定します。使用可能な DSP リソースは、スイッチオーバーが完了するとすぐに、新しいコールで利用できるようになります。

• switchback method guard timeout 7200 コマンドは、プライマリ Cisco Unified CallManager が障害から回復した後の登録のスイッチバック メカニズムを指定します。このコマンドを設定すると、Cisco RSVP Agent は最後のアクティブなコールの切断後に、プライマリ Cisco Unified CallManager への登録の正常なスイッチバックを開始します。保護タイマーの期限内に登録の正常なスイッチバックが開始されない場合、Cisco RSVP Agent は即時のスイッチバック メカニズムを使用してすぐに Cisco Unified CallManager に登録します。保護タイマーのデフォルト値は 7200 秒で、60 ～ 172800 秒の範囲で静的に設定できます。

• ゲートウェイ設定モードでの timer receiver-rtp コマンドは、RSVP 予約のための RTP クリーンアップ タイマーを定義します。障害が発生した場合、既存のコール用の RSVP 予約は、RTP クリーンアップ タイマーの期限が切れるまで有効です。このタイマーのデフォルト値は、1200 秒です。このタイマーは可能な最小値である 180 秒に設定することをお勧めします。

最大セッション サポート

Cisco RSVP Agent は、Cisco RSVP Agent ルータに搭載されるソフトウェアベースのリソース（CPU）とハードウェアベースのリソース（DSP）に基づく、コールまたはセッションの最大数をサポートしています。 dspfarm profile 設定モードの maximum sessions コマンドは、Cisco RSVP Agent が処理できるコールの最大数を指定します。Cisco RSVP Agent は、この設定に基づいてセッション容量を Cisco Unified CallManager に通知します。セッションの最大数は、コールが Cisco RSVP Agent を通過するごとに 1 つずつ減少します。カウンタが 0 になると、Cisco RSVP Agent には使用可能なリソースがないと見なされ、Cisco Unified CallManager はそれ以降のコールでその Cisco RSVP Agent をスキップします。

図9-16 は、2 つの Cisco RSVP Agent がある支店サイトを示しています。Cisco RSVP Agent は WAN ルータと共存し、Cisco RSVP Agent の冗長性は、同じ MRGL の別の MRG に 2 つの Cisco RSVP Agent を割り当てることによって実現されます。MRG-1 の Agent-1 が使用できないか、セッション容量を超えている場合、Cisco Unified CallManager は支店 1 を宛先または発信元とする RSVP コールのために、MRG-2 に Agent-2 を割り当てようとします。Agent-1 の容量に達したときに Agent-2 が選択されるようにするには、Cisco RSVP Agent の WAN インターフェイスで設定する ip rsvp bandwidth でサポートされるコール数と正確に一致するセッションの最大数を設定することをお勧めします。この例では、両方の Cisco RSVP Agent を maximum sessions 1 に設定する必要があります。この推奨事項は、WAN を経由するすべてのコールが同じタイプのコーデックを使用し、WAN 経由のコール数を正確に計算できることを前提としています。このコール数は、使用可能な RSVP 帯域幅をコールごとに必要な帯域幅で割ることによって計算します。

（注） セッションの最大数が ip rsvp bandwidth 設定でサポートされるコール数よりも大きい場合でも、Cisco Unified CallManager はそのコールを Cisco RSVP Agent に送りますが、使用可能な帯域幅がないため RSVP 予約は失敗します。Cisco Unified CallManager は、コール アドミッション制御失敗の通常の処理に従います（コールを拒否するか、AAR 機能を呼び出します）。

図9-16 Cisco RSVP Agent での最大セッションの設定

パススルー コーデック

パススルー コーデックを使用すると、Cisco IOS Enhanced MTP デバイスは、ストリームのメディア エンコーディングを認識していなくても、エンドポイントから受信した RTP メディア ストリームを終端することができます。つまり、メディア ストリームの UDP パケットは、デコードされずに MTP を通過します。この方法により、MTP は、Cisco Unified CallManager で定義されるすべての音声、ビデオ、およびデータのコーデックをサポートできます。MTP はメディア ストリームをデコードしないため、パススルー コーデックは暗号化（SRTP）メディア ストリームでも使用できます。実際にビデオおよび SRTP メディア ストリームが MTP を使用するには、パススルー コーデックをサポートする必要があります。パススルー コーデックで設定した場合、Cisco RSVP Agent はパケットの IP/UDP ヘッダーのソース IP アドレスを独自の IP アドレスで置き換えて、パケットを通過させます。

Cisco RSVP Agent は、次のすべての条件が満たされる場合にだけ、パススルー コーデックを使用します。

• コールに関与する 2 つのエンドポイント デバイスの音声コーデック能力が一致し、リージョン設定により同一のコーデックの使用がコールに対して許可されている。つまり、コールにトランスコーダ デバイスを挿入する必要はありません。

• MTP Required が、いずれのエンドポイント デバイスに対しても設定されていない。

• すべての中間リソース デバイスが、パススルー コーデックをサポートしている。

（注） Cisco RSVP Agent が MTP デバイスとして登録され、トランスコーダ デバイスをコールに挿入する必要がある場合、Cisco RSVP Agent の dspfarm MTP プロファイルで設定されるコーデックは、Cisco Unified CallManager Administration で設定されるリージョン間コーデックと一致している必要があります。たとえば、G.729 コーデックが Cisco Unified CallManager Administration で設定されるリージョン間コーデックの場合は、dspfarm MTP プロファイルでも G.729 コーデックを設定する必要があります。

次の例は、Cisco 2800 IOS プラットフォーム上の Cisco RSVP Agent 設定を示しています。

RSVP ポリシー

Cisco Unified CallManager は、ロケーション ペアごとに異なる RSVP ポリシーを適用できます。RSVP ポリシーは、Cisco Unified CallManager Administration で設定できます。RSVP ポリシーでは、RSVP 予約試行が失敗した場合に、Cisco Unified CallManager がコールを許可するかどうかが定義されます。次の RSVP ポリシー設定は、任意の 2 つのロケーション間で設定できます。

• No Reservation

RSVP 予約試行は行われず、静的ロケーション コール アドミッション制御だけが、Cisco Unified CallManager で実行されます。

• Mandatory

Cisco Unified CallManager は、音声ストリームに対する（コールがビデオ コールの場合はビデオ ストリームに対する）RSVP 予約が成功するまで、終端エンドポイント デバイスを呼び出しません。

• Mandatory (Video Desired)

ビデオ ストリームの予約はできないが、音声ストリームの予約に成功した場合、ビデオ コールは音声専用コールとして処理できます。

• Optional (Video Desired)

音声ストリームとビデオ ストリームの両方に対して予約が得られなかった場合、コールはベストエフォートの音声専用コールとして処理できます。Cisco RSVP Agent は、ベストエフォートとしてメディア パケットを再マーキングします。

• Use System Default

ロケーション ペアの RSVP ポリシーが、クラスタ全体の RSVP ポリシーと一致します。デフォルトのクラスタ全体の RSVP ポリシーは、No Reservation です。Cisco Unified CallManager Administration でデフォルトの RSVP ポリシーを変更するには、 System > Service Parameters > Cisco Unified CallManager Service > Default Inter-location RSVP Policy を選択します。

（注） Optional (video desired) ポリシーでは、RSVP 予約が失敗しただけでなく、Cisco RSVP Agent も使用できない場合にだけ、IP WAN コールをベストエフォートとして処理できます。この場合、Cisco Unified CallManager は、ベストエフォートとしてトラフィックを再マーキングするように SCCP デバイスおよび MGCP デバイスに指示します。しかし、H.323 デバイスと SIP デバイスではこの再マーキングを行うことができないため、デフォルトの QoS マーキングでトラフィックの送信が続けられます。後者の場合にプライオリティ キューのオーバーサブスクリプションを防ぐため、IP WAN ルータで Access Control List（ACL; アクセス コントロール リスト）を設定し、ソース IP アドレスが Cisco RSVP Agent のアドレスの場合に、DSCP EF または AF41 とマークされたパケットだけを許可することをお勧めします。

図9-17 では、クラスタ全体の RSVP パラメータのデフォルト設定と推奨設定の両方を示しています。RSVP ポリシーは、 Mandatory または Mandatory (Video Desired) に設定することをお勧めします。これらの設定では、帯域幅の予約とコールの音声品質が保証されます。クラスタ全体の RSVP ポリシーを設定するための最も効率的な方法としては、Cisco CallManager Service Service Parameter Configuration のクラスタ全体の RSVP パラメータに Default Inter-location RSVP Policy を設定し、ロケーション設定の RSVP 設定を Use System Default のままにします。

図9-17 クラスタ全体の RSVP パラメータの設定

クラスタ全体の RSVP パラメータ設定には、 Mandatory RSVP mid call error handle option という名前のサービス パラメータがあります。RSVP ポリシーを Mandatory または Mandatory (Video Desired) に設定した場合、このパラメータは Cisco Unified CallManager がコール中の RSVP 予約試行の失敗に基づいて既存の RSVP を処理する方法を指定します。コール中の RSVP 予約試行は、WAN の障害後にネットワークのコンバージェンスや、既存の音声専用コールがビデオ コールになることなどでトリガーされることがあります。ネットワークのコンバージェンスでは、Cisco RSVP Agent は、新たにコンバージされたパスを通じてメディア ストリームの送信が開始されるだけでなく、新しいパスを通じて新しい RSVP 予約も試行されます。

Mandatory RSVP mid call error handle option のデフォルト設定は、 Call Becomes Best Effort です。デフォルト オプションの設定では、Cisco Unified CallManager はコール中の RSVP 予約試行が失敗しても既存のコールを保持しますが、RTP ストリームはベストエフォートとしてマークされます（DSCP 0）。このパラメータは、 Call Fails Following Retry Counter Exceeded オプション付きで設定することをお勧めします。このオプションを設定すると、Cisco Unified CallManager は RSVP 予約試行が一定の試行回数を超えて失敗し続けた場合に、コールを切断します。再試行カウンタのデフォルト値は 1 です。これは RSVP Mandatory mid-call retry counter サービス パラメータで定義され、 RSVP retry timer のデフォルト値は 60 秒です。再試行カウンタと再試行タイマーの両方のサービス パラメータを、デフォルト値で設定することをお勧めします。両方のパラメータをデフォルト値に設定すると、Cisco Unified CallManager はコール中の RSVP 再試行が失敗した場合に、60 秒待機してからそのコールを切断します。この 60 秒間は、RSVP 予約が存在せず、RTP ストリームはベストエフォートとしてマーキングされるため、音声品質が低下することがあります。

静的ロケーションから RSVP コール アドミッション制御への移行

この項の例では、従来の静的ロケーション コール アドミッション制御から RSVP ベースのコール アドミッション制御メカニズムに移行するためのベスト プラクティスを示します。

図9-18 では、静的ロケーション コール アドミッション制御メカニズムによるコール処理の集中型配置を示しています。Hub_None ロケーションや 3 箇所の支店など、Cisco Unified CallManager クラスタには 4 つのロケーションがあります。説明を簡単にするために、この例で使用する帯域幅は音声ストリームの帯域幅だけを示しています。 表9-4 と 表9-5 は、256 kbps の帯域幅で静的にプロビジョニングされるすべての支店ロケーションと、 Unlimited の帯域幅でプロビジョニングされる Hub_None ロケーションを示しています。ロケーションの任意のペア間の RSVP 設定は Use System Default で設定され、クラスタ全体の RSVP 設定はデフォルト値 No Reservation で設定されます。

図9-18 静的ロケーションでのコール アドミッション制御の設定

RSVP ベースのコール アドミッション制御に移行するには、ロケーションを一度に 1 つずつ移行することをお勧めします。たとえば、支店 1 が最初に移行するロケーションの場合は、次の手順に従います。

• 支店 1 ロケーションで Cisco RSVP Agent を設定し、支店 1 の MRG および MRGL に割り当てて、支店 1 の IP Phone に関連付けます。

• Hub_None ロケーションで別の Cisco RSVP Agent を設定し、Hub_None ロケーションを含む残りの 3 つのロケーションのすべての IP Phone に関連付けられた MRG および MRGL に、Cisco RSVP Agent を含めます。Cisco RSVP Agent を、Null MRG または支店 1 MRG に含めないでください。含めると、支店 1 の IP Phone が Hub_None ロケーションで Cisco RSVP Agent を使用して、RSVP 予約を行う可能性があります。

• 支店 1 の帯域幅を Unlimited に設定します。

• 支店 1 とその他の任意のロケーション間の RSVP 設定を Mandatory に設定します。たとえば、支店 1 と支店 2 の IP Phone 間のコールに対して、音声ストリームは Hub_None ロケーションを通じたヘアピンのままになります。支店 1 ロケーションと Hub_None ロケーション間の最初のコール レッグに対して、RSVP 予約は、支店 1 と Hub_None の Cisco RSVP Agent 間に行われます。Hub_None ロケーションと支店 2 ロケーション間の 2 番目のコール レッグに対して、Cisco Unified CallManager は、支店 2 ロケーションの帯域幅の可用性をチェックすることにより、静的ロケーションに基づくコール アドミッション制御を実行します。

表9-6 と 表9-7 は、支店 1 での移行後のロケーションの帯域幅と RSVP ポリシー設定を示しています。

表9-8 と 表9-9 は、クラスタ全体の移行後のロケーションの帯域幅と RSVP ポリシー設定を示しています。クラスタ全体の移行が完了すると、サイト間のコールでは 2 つの Cisco RSVP Agent 間で RSVP 予約を直接行う必要があり、音声ストリームは帯域幅予約パスを通じて転送されます。

次の手順を使用すると、支店 2 および支店 3 を RSVP コール アドミッション制御に移行できます。

• 支店 2 ロケーションで Cisco RSVP Agent を設定し、支店 2 の IP Phone に関連付けられた支店 2 の MRG および MRGL に割り当てます。Hub_None ロケーションの Cisco RSVP Agent が支店 2 の IP Phone からアクセスされなくなるように、Hub_None ロケーションの Cisco RSVP Agent を支店 2 の MRG から削除してください。

• 支店 2 の帯域幅を Unlimited に設定します。

• 支店 2 とその他の任意のロケーション間の RSVP 設定を Mandatory に設定します。

• 支店 3 ロケーションで Cisco RSVP Agent を設定し、支店 3 の IP Phone に関連付けられた支店 3 の MRG および MRGL に割り当てます。Hub_None ロケーションの Cisco RSVP Agent が支店 3 の IP Phone からアクセスされなくなるように、Hub_None ロケーションの Cisco RSVP Agent を支店 3 の MRG から削除してください。

• 支店 3 の帯域幅を Unlimited に設定します。

• 支店 3 とその他の任意のロケーション間の RSVP 設定を Mandatory に設定します。

RSVP アプリケーション ID

RSVP アプリケーション ID は、Cisco Unified CallManager が音声トラフィックとビデオ トラフィックの両方に識別子を追加できるようにするメカニズムです。これにより、Cisco RSVP Agent は、受け取った識別子に基づいていずれかのトラフィックに個別の帯域幅制限を設定できます。ネットワークに RSVP アプリケーション ID を配置するには、Cisco RSVP Agent ルータおよび Cisco Unified CallManager Release 5.0 で、Cisco IOS Release 12.4（6）T 以降を使用する必要があります。RSVP アプリケーション ID 文字列は、クラスタ全体の RSVP パラメータ設定の 2 つのサービス パラメータ（ RSVP Audio Application ID と RSVP Video Application ID ）で設定できます。

Cisco Unified CallManager は SCCP を使用して、RSVP アプリケーション ID を Cisco RSVP Agent に伝達します。Cisco RSVP Agent も、RSVP シグナリング メッセージ（RSVP Path メッセージや Resv メッセージなど）に RSVP アプリケーション ID を挿入し、ダウンストリームまたはアップストリームの RSVP ルータにこれらのメッセージを送信します。

RSVP アプリケーション ID は、静的ロケーション モデルとは異なるモデルを使用して、音声トラフィックおよびビデオ トラフィックの帯域幅を分離します。静的ロケーションでは、ビデオ コールの音声ストリームとビデオ ストリームはどちらもビデオ帯域幅カウンタから差し引かれます。RSVP アプリケーション ID を使用する場合、音声ストリームは音声帯域幅プールから差し引かれ、ビデオ ストリームはビデオ帯域幅プールから差し引かれます。コール アドミッション制御モデルのこの変更により、音声コール用に一定の帯域幅を予約し、プライオリティ キューで使用可能なすべての帯域幅を使用できるようになりました。このため、ビデオ コールが行われていない場合に、音声コール用にすべての使用可能な帯域幅を使用できます。プライオリティ キューに使用可能な帯域幅が十分にある場合、オプションとしてビデオ用のコールを有効にできます。ビデオ対応コールが消費できる帯域幅の量に制限を設定できますが、音声コールが使用可能なすべての帯域幅を消費している場合は、ビデオ コールを発信できないことがあります。RSVP アプリケーション ID、RSVP ポリシー、および LLQ の設定方法の詳細については、「RSVP のアプリケーション ID」を参照してください。

RSVP 機能のある Cisco IOS Gatekeeper および IP-to-IP ゲートウェイ

シスコのマルチサービス IP-to-IP ゲートウェイ（IP-IP ゲートウェイまたは IPIPGW とも呼ばれます）を使用すると、Cisco Unified CallManager クラスタ間、H.323 ゲートウェイ間、またはこれらの 2 者間の IP WAN 接続に関して、ハブアンドスポーク トポロジにおける制約を緩和できます。

Cisco IOS 機能が、IP ネットワーク間で H.323 Voice over IP（VoIP）コールおよびビデオ会議コールを使用するためのメカニズムを提供します。IP-IP ゲートウェイの主な目的は、管理ドメインを通過する VoIP コールとビデオ コールにコントロール ポイントと境界を提供することです。このゲートウェイは、PSTN-to-IP ゲートウェイとほぼ同じ機能を実行しますが、公衆網レッグと IP コール レッグの代わりに、通常は 2 つの IP コール レッグに加入します。

企業の IP Communications 環境において、IP-IP ゲートウェイが備える最も興味深い機能は、このゲートウェイを通過する各コールのための RSVP 予約を生成できることです。「トポロジ対応コール アドミッション制御」の項で説明しているように、RSVP は、トポロジ対応型のコール アドミッション制御メカニズムを提供するためのネットワーク ベース シグナリング プロトコルです。トポロジがハブアンドスポークである必要はなく、任意のネットワーク トポロジで機能します。

結果として、コール フローに 2 つの IP-IP ゲートウェイを挿入し、両者間で RSVP を有効にすることで、任意の IP WAN トポロジ上でコール アドミッション制御を実行できます。図9-19 に、2 つのサイト A と B による基本的な例を示します。それぞれ Cisco Unified CallManager クラスタがあり、任意のトポロジを持つ IP WAN を通じて接続されています。各サイトには IP-IP ゲートウェイも配置されており、2 つの Cisco Unified CallManager クラスタは、すべてのサイト間コールを、ローカル IP-IP ゲートウェイを指しているトランクを通じてルーティングするように設定されています。サイト A とサイト B の間でコールがセットアップされると、次のイベントが発生します。

• サイト A の Cisco Unified CallManager が、サイト A の IP-IP ゲートウェイに向かう H.323 トランク（図中のコール レッグ 1）を通じてコールをセットアップします。

• サイト A の IP-IP ゲートウェイが、サイト B の IP-IP ゲートウェイに向かう別のコールを確立しようとしますが、まず RSVP を使用して、IP WAN パスに沿って帯域幅リソースを確保します。

• RSVP 予約が成功すると、2 つの IP-IP ゲートウェイ間にコール レッグ 2 が確立されます。

• サイト B の IP-IP ゲートウェイが、サイト B の Cisco Unified CallManager クラスタに向かう別のコール（図中のコール レッグ 3）を生成します。

図9-19 RSVP コール アドミッション制御のための IP-to-IP ゲートウェイの簡単な例

図9-19 の例は、Cisco Unified CallManager クラスタ間のすべてのコールが、IP-IP ゲートウェイ ペアを通じてルーティングされる単純なシナリオです。しかし、多くの実稼働環境では、このアプローチは十分にスケーラブルで柔軟なものとは言えません。このような場合は、Cisco IOS ゲートキーパーを使用することで、Cisco Unified CallManager クラスタ、H.323 ゲートウェイ、H.323 ビデオ会議エンドポイント、IP-IP ゲートウェイの間に幅広い通信オプションを配置できるようになります。

（注） この項で説明した IP-IP ゲートウェイ関係のシナリオは、すべて複数の Cisco Unified CallManager クラスタ間のコールに関するものです。同じ Cisco Unified CallManager クラスタに登録されているエンドポイント間で、コールに IP-IP ゲートウェイを挿入することはお勧めしません。同じ Cisco Unified CallManager クラスタに登録されているエンドポイント間の RSVP ベースのコール アドミッション制御については、「Cisco Unified CallManager の RSVP 対応ロケーション」を参照してください。

中継ゾーン（Via-Zone）ゲートキーパー

従来の Cisco IOS ゲートキーパー機能は、「中継ゾーン」ゲートキーパーという概念を通じて、IP-IP ゲートウェイに対応するように拡張されました。中継ゾーン ゲートキーパーがレガシー ゲートキーパーと異なっている点は、コール ルーティングでの LRQ メッセージと ARQ メッセージの使用方法です。中継ゾーン ゲートキーパーを使用しても、通常のゲートキーパー機能を維持したまま、追加機能によって拡張されます。レガシー ゲートキーパーは、着信する LRQ を着信番号に基づいて検査します。具体的には、LRQ の destinationInfo 部分にある dialedDigits フィールドを検査します。中継ゾーン ゲートキーパーは、着信番号を検査する前に LRQ の発信地点を検査します。LRQ が、中継ゾーン ゲートキーパーのリモート ゾーン設定にリストされているゲートキーパーから送信されている場合、ゲートキーパーは、ゾーンのリモート設定に invia キーワードまたは outvia キーワードが含まれているかどうかを確認します。設定にこれらのキーワードが含まれている場合、ゲートキーパーは新しい中継ゾーン処理を使用します。含まれていない場合は、従来の処理を使用します。

ARQ メッセージの場合、ゲートキーパーは宛先ゾーンに outvia キーワードが設定されているかどうかを調べます。 outvia キーワードが設定されていて、 outvia キーワードを使用して命名されているゾーンがゲートキーパーに対してローカルである場合は、そのゾーンの IP-IP ゲートウェイがポイントされている ACF が返され、コールは IP-IP ゲートウェイに転送されます。 outvia キーワードを使用して命名されているゾーンがリモートである場合、ゲートキーパーは、ロケーション要求をリモート ゾーンのゲートキーパーではなく outvia ゲートキーパーに送信します。 invia キーワードは、ARQ の処理では使用されません。

図9-20 に、IP-IP ゲートウェイと中継ゾーン ゲートキーパーを Cisco Unified CallManager クラスタおよびレガシー ゲートキーパーと連携するように使用して、コール ルーティングとコール アドミッション制御を提供する方法の例を示します。このシナリオには、次の考慮事項が適用されます。

• サイト A の Cisco Unified CallManager クラスタは、サイト A のゲートキーパーを使用して、コールをクラスタ間で直接ルーティングする。

• サイト A のゲートキーパーは、サイト B の E.164 番号に転送されるすべてのコールを、サイト A の中継ゾーン ゲートキーパーに送信する。

• サイト A の中継ゾーン ゲートキーパーは、サイト A のゲートキーパーを発信元または宛先とするすべてのコールに対して、IP-IP ゲートウェイを挿入する。

• サイト A の IP-IP ゲートウェイは、コールをサイト B の IP-IP ゲートウェイに送信する前に、RSVP 予約を試行する。

• サイト B の Cisco Unified CallManager クラスタ、ゲートキーパー、および IP-IP ゲートウェイは、サイト A のそれぞれと同様の方法で設定されている。

図9-20 中継ゾーン ゲートキーパーを使用した RSVP のための IP-to-IP ゲートウェイ

設計上のベスト プラクティス

IP-IP ゲートウェイを Cisco Unified CallManager と連携するように配置して、IP WAN で RSVP コール アドミッション制御を使用できるようにする場合は、次に示す設計上のベスト プラクティスに従ってください。

• 1 つ以上の IP-IP ゲートウェイを通じて、他の Cisco Unified CallManager クラスタとの音声通信またはビデオ通信用に Cisco Unified CallManager のトランクを設定する場合は、ゲートキーパー制御 H.225 トランクを使用します。Cisco IOS Release 12.4（6）T 以降および Cisco Unified CallManager Release 4.1 以降を使用すると、IP-IP ゲートウェイを通じた保留と保留解除、転送、会議などの補足サービスを呼び出すための MTP リソースが不要になります。相互運用性を確保するには、次の項目を設定する必要があります。

–Cisco Unified CallManager Administration のトランク設定ページで、 Media Termination Point required フィールドをオフ（デフォルト設定）のままにして、 Wait for Far End H.245 Terminal Capability Set フィールドもオフにします。

–Cisco Unified CallManager Administration の Cisco Unified CallManager に関する Advanced Service Parameters ページで、 Send H225 User Info Message フィールドを H225 Info For Call Progress Tone に設定します。

–補足サービスを呼び出す場合に Cisco Unified CallManager との相互運用性を確保するには、IP-IP ゲートウェイで次の Cisco IOS コマンドを設定します。

• 一部の配置では、プロキシ機能を提供し、エンドポイント デバイスに代わってシグナリング ストリームおよびメディア ストリームを終端させるために、MTP リソースが優先されます。MTP リソースが必要な場合は、クラスタ間トランクを介してコールするときに IP WAN 帯域幅の使用が増大するのを避けるために、IP-IP ゲートウェイと同じサイトに MTP リソースを配置することをお勧めします。これらの MTP リソースは、ソフトウェア ベース（Cisco MCS サーバや Cisco IOS ルータなど）でも、ハードウェア ベース（Cisco コミュニケーション メディア モジュールを備えた Catalyst 6500 や、NM-HDV ネットワーク モジュールを備えた Cisco IOS ルータなど）でもかまいません。使用できる MTP リソースの完全なリストについては、「メディア リソース」の章を参照してください。ただし、MTP を使用すると、コールが持続しているすべての期間にわたって、メディア パケットは最初の MTP リソースを通じて転送されます。以後にコール転送が発生した場合は、ヘアピンが発生する可能性があります。 Media Termination Point required オプションが H.225 トランクでオフになっている場合、ビデオ コールは IP-IP ゲートウェイを通じてクラスタ間で確立されないことに注意してください（MTP はビデオ コールをサポートしていないため）。

• すべてのクラスタ間コールで IP-IP ゲートウェイを使用する場合にだけ、Cisco Unified CallManager で H.323 ゲートウェイとして IP-IP ゲートウェイを設定します。この場合でも、IP-IP ゲートウェイはゲートキーパーを使用してリモートの宛先を解決することができます。

• クラスタ間コールの解決、およびクラスタ間コールを IP-IP ゲートウェイを通じてルーティングするか、直接ルーティングするかの判定にゲートキーパーを使用する場合は、Cisco Unified CallManager にゲートキーパー制御のクラスタ間トランクを設定します。このアプローチでは、より柔軟でスケーラビリティのある配置になります。

• IP-IP ゲートウェイ上の CallManager 3.3(2) 以降との互換性があるのは、Cisco IOS Release 12.3(1) 以降です。Cisco IOS Release 12.4(6)T 以降を使用することをお勧めします。

• ゲートキーパーと中継ゾーン ゲートキーパーの機能は、それぞれ別のルータ プラットフォーム上で実行して、分離します。各 IP-IP ゲートウェイに対して、専用の中継ゾーン ゲートキーパーを配置する必要があります。

• 中継ゾーン ゲートキーパー機能と IP-IP ゲートウェイ機能は、同じルータ プラットフォーム上で実行（共存）することができます。ただし、「冗長性」の項で説明しているスケーラビリティの要件に注意してください。

• 同じ Cisco Unified CallManager クラスタに制御されているエンドポイント間では、コールに IP-IP ゲートウェイを使用しないでください。

• 同じ Cisco Unified CallManager クラスタに制御されているエンドポイント間では、トポロジ対応コール アドミッション制御を提供するために RSVP 対応ロケーションを使用します。

• IP-IP ゲートウェイに対して RSVP 予約を有効にする場合は、ダイアル ピア設定で次のオプションを使用します。

この設定を行うと、各音声コールまたはビデオ コールに対して、IP-IP ゲートウェイは遅延保証付きのサービスを使用して RSVP 予約を要求します。要求された QoS と許容可能な QoS の両方がこの RSVP サービスを指定している場合、コールが成功するためには RSVP 予約が必須になります（予約を確立できない場合はコールが失敗します）。設定の詳細については、「設定のガイドライン」を参照してください。

冗長性

冗長性とスケーラビリティを実現するには、複数の IP-IP ゲートウェイを同じ中継ゾーン ゲートキーパーおよび同じ中継ゾーンに登録します。中継ゾーン ゲートキーパーは、ラウンドロビン アルゴリズムを使用して、同じ中継ゾーンに含まれているすべての IP-IP ゲートウェイに着信コールを自動的に分配します。

IP-IP ゲートウェイに障害が発生すると、そのゲートウェイは中継ゾーン ゲートキーパーへの登録を失います。ゲートキーパーは、使用可能リソースのリストからそのゲートウェイを削除します。

IP-IP ゲートウェイに対して、最大負荷しきい値を手動で設定することもできます。ある IP-IP ゲートウェイで回線の使用率が一定の割合を超えると、そのゲートウェイは新しいコールの処理用としては選択されなくなり、回線の使用率が一定の割合を下回ると、再び使用可能になります。このように設定するには、次の Cisco IOS コマンドを使用します。

• IP-IP ゲートウェイ上：

• ゲートキーパー上：

これらのコマンドの詳細については、次の Web サイトで入手できる Cisco IOS コマンド解説資料を参照してください。

http://www.cisco.com

設定のガイドライン

ここでは、図9-21 に示したネットワーク ダイアグラムに基づく簡単な設定例を示します。この項は、詳細なコマンド リファレンス ガイドを意図したものではなく、一般的な配置シナリオに役立つガイドラインをまとめたものです。IP-IP ゲートウェイおよび中継ゾーン ゲートキーパーを設定する方法の詳細については、次の Web サイトで入手可能な、シスコ マルチサービス IP-to-IP ゲートウェイのオンライン ドキュメントで説明しています。

http://www.cisco.com

図9-21 中継ゾーン ゲートキーパーを使用した IP-IP ゲートウェイの設定例

図9-21 に示すネットワークでは、サイト A に内線番号 1 xxx のクラスタ A1 と、内線番号 2 xxx のクラスタ A2 の 2 つの Cisco Unified CallManager クラスタが存在しているとします。サイト B にも、内線番号 3 xxx のクラスタ B1 と、内線番号 4 xxx のクラスタ B2 の 2 つの Cisco Unified CallManager クラスタが存在します。

次の各項に、サイト A にあるデバイスに関連する設定を示します。サイト A の内部でやり取りされるコールは、（サイト A のレガシー ゲートキーパーを使用して）Cisco Unified CallManager クラスタ間で直接ルーティングされるのに対して、サイト B に向かうコールは、2 つの IP-IP ゲートウェイを通じて（それぞれのレガシー ゲートキーパーと中継ゾーン ゲートキーパーを使用して）ルーティングされます。

Cisco Unified CallManager

クラスタ A1 とクラスタ A2 は、どちらもゲートキーパー制御クラスタ間トランクを使用します。これは、MTP を必要とせず、サイト A のレガシー ゲートキーパーを指すクラスタ間トランク（ICT）です。

[34]XXX ルート パターンは、ゲートキーパーおよび IP-IP ゲートウェイを通じてサイト B のクラスタに到達するために、ルート リストおよびルート グループを通じて ICT を指しています。

他のルート パターン（クラスタ A1 の 2XXX とクラスタ A2 の 1XXX）は、ルート リストおよびルート グループを通じて ICT を指すことで、クラスタ A1 と A2 がゲートキーパーを通じて互いに通信できるようにしています。

レガシー ゲートキーパー

サイト A のレガシー ゲートキーパーは、クラスタ A1 と A2 の間ではコールを直接ルーティングし、サイト B に向かうコール（内線番号 3 xxx と 4 xxx ）については、すべてサイト A の中継ゾーン ゲートキーパーに送信します。例9-1 に、関連する設定を示します。

例9-1 サイト A のレガシー ゲートキーパー設定

中継ゾーン ゲートキーパー

サイト A の中継ゾーン ゲートキーパーは、サイト B の Cisco Unified CallManager クラスタ（内線番号 3 xxx と 4 xxx ）に向かうコールをサイト B の中継ゾーン ゲートキーパーに送信し、サイト B で発着信されるコールに使用される IP-IP ゲートウェイを呼び出します。サイト A のクラスタに向かうコールは、サイト A のレガシー ゲートキーパーにルーティングされ、IP-IP ゲートウェイは呼び出されません。例9-2 に、関連する設定を示します。

例9-2 サイト A の中継ゾーン ゲートキーパー設定

例9-2 に示す設定には、次の考慮事項が適用されます。

• B-VIAGK リモート ゾーンに関連するコマンドラインの invia キーワードと outvia キーワードが、このゾーンの中継ゾーン ゲートキーパーの処理をアクティブにします。つまり、B-VIAGK リモート ゾーンが宛先または発信元となるすべてのコールについて、中継ゾーン ゲートキーパーは、A-VIAGK ローカル ゾーンに登録されている IP-IP ゲートウェイ リソースを呼び出します。

• CCM-A1 リモート ゾーンおよび CCM-A2 リモート ゾーンに関連するコマンドラインには、 invia キーワードと outvia キーワードがありません。このため、標準のゲートキーパー処理が適用され、これらのゾーンで発着信されるコールに対しては、IP-IP ゲートウェイは呼び出されません。

IP-IP ゲートウェイ

サイト A の IP-IP ゲートウェイは、サイト B の Cisco Unified CallManager クラスタ（内線番号 3 xxx と 4 xxx ）に向かう音声コールとビデオ コールについては、RSVP 予約を要求します。一方で、サイト A の Cisco Unified CallManager クラスタ（内線番号 1 xxx と 2 xxx ）に向かうコールについては要求しません。例9-3 に、関連する設定を示します。

例9-3 サイト A の IP-IP ゲートウェイ設定

例9-3 に示す設定には、次の考慮事項が適用されます。

• emptycapability コマンドは、Cisco Unified CallManager と IP-IP ゲートウェイ間の H.245 ECS を有効にして、確立されたコールに対して補足サービスを呼び出します。

• req-qos guaranteed-delay [ audio | video ] コマンドで、ダイヤルピア 10 または 15 を使用する音声コールとビデオ コールについて、IP-IP ゲートウェイが遅延保証付きの RSVP 予約を要求することを指定します。

• acc-qos guaranteed-delay [ audio | video ] コマンドで、音声コールとビデオ コールに関して許容可能な最小限の QoS レベルも、遅延保証付き RSVP 予約であることを指定します。これは、RSVP 要求が失敗した場合はコールも失敗するので、RSVP 予約を必須にすることを意味します。RSVP 予約がオプションになるように（予約が失敗した場合でもコールが成功するように）IP-IP ゲートウェイを設定するには、代わりに acc-qos best-effort [ audio | video ] コマンドを使用します。

単純なハブアンドスポーク トポロジ

図9-22 に、スター トポロジとも呼ばれる単純なハブアンドスポーク トポロジを示します。このタイプのネットワーク トポロジでは、すべてのサイト（「スポーク サイト」と呼ばれる）が、1 つの IP WAN リンクを通じて中央サイト（「ハブ サイト」と呼ばれる）に接続されます。スポーク サイト間には直接のリンクが存在しないため、スポーク サイト間の通信は、すべてハブ サイトを経由する必要があります。

図9-22 単純なハブアンドスポーク トポロジ

この項の設計上の考慮事項は、従来のレイヤ 2 IP WAN テクノロジーを使用する単純なハブアンドスポーク トポロジに適用されます。

• フレーム リレー

• ATM

• フレーム リレー/ATM 間サービス インターワーキング

• 専用回線

MPLS テクノロジーに基づいた IP WAN 配置については、「単純な MPLS トポロジ」の項を参照してください。

以降では、採用する Cisco Unified CallManager 配置モデルごとに、単純なハブアンドスポーク トポロジに関する設計上のベスト プラクティスを示します。

• 「集中型の Cisco Unified CallManager 配置」

1 つまたはそれ以上の Cisco Unified CallManager クラスタをハブ サイトに配置し、スポーク サイトには電話とゲートウェイだけを配置します。

• 「分散型の Cisco Unified CallManager 配置」

Cisco Unified CallManager クラスタまたは Cisco Unified CallManager Express を各サイトに配置します。

集中型の Cisco Unified CallManager 配置

単純なハブアンドスポーク トポロジ上にあり、集中型コール処理を使用するマルチサイト WAN 配置では、Cisco Unified CallManager の静的ロケーションを使用してコール アドミッション制御を実装します。図9-23 に、このメカニズムをこのようなトポロジに適用する方法の例を示します。

図9-23 静的ロケーションを使用した単純なハブアンドスポーク トポロジのコール アドミッション制御

コール アドミッション制御に対して静的ロケーションを使用する場合は、次のガイドラインに従ってください。

• 各スポーク サイトの Cisco Unified CallManager に対しては、個別にロケーション設定が必要です。

• 各サイトの音声コールとビデオ コールに対する帯域幅の上限を、そのサイトに使用されているコーデックのタイプに応じて、適切に設定します（帯域幅の推奨設定については、 表9-1 を参照してください）。

• 各スポーク サイトのすべてのデバイスを適切なロケーションに割り当てます。

• ハブ サイトのデバイスは、Hub_None ロケーションのままにします。

• あるデバイスを別のロケーションに移した場合、ロケーションの設定も変更します。

• Cisco Unified CallManager は、ロケーションを 500 個所までサポートします。

• WAN の帯域幅が十分にない場合に、公衆網を介した自動ルーティングを実行する必要があるときは、Cisco Unified CallManager 上で Automated Alternate Routing（AAR）機能を設定します（「Automated Alternate Routing」を参照）。

• 同じハブ サイトに複数の Cisco Unified CallManager クラスタを配置する場合は、クラスタ間トランク デバイスを Hub_None ロケーションのままにします。ダイヤル プランの解決には、ゲートキーパーを使用できます。ただし、この場合、ゲートキーパーのコール アドミッション制御は必要ありません。これは、すべての IP WAN リンクがロケーション アルゴリズムによって制御されるためです。

（注） 1 つ以上のサイトに IP WAN への二重接続があり、両方のリンクで使用可能な帯域幅を最大限に利用する場合は、「汎用トポロジ」の項で説明しているように、トポロジ対応コール アドミッション制御を配置することをお勧めします。詳細については、「トポロジ非対応コール アドミッション制御の制限」を参照してください。

分散型の Cisco Unified CallManager 配置

単純なハブアンドスポーク トポロジの分散型コール処理配置では、Cisco IOS ゲートキーパーを使用してコール アドミッション制御を実装できます。この設計では、コール処理エージェント（Cisco Unified CallManager クラスタ、Cisco Unified CallManager Express、または H.323 ゲートウェイなど）は Cisco IOS ゲートキーパーに登録し、エージェントが IP WAN コールを発信しようとするたびにゲートキーパーに照会を行います。Cisco IOS ゲートキーパーは、各コール処理エージェントを、特定の帯域幅制限があるゾーンに関連付けます。したがって、Cisco IOS ゲートキーパーは、ゾーンに出入りする IP WAN 音声コールが消費する最大帯域幅量を制限することができます。

図9-24 では、ゲートキーパーを使用したコール アドミッション制御を示しています。つまり、コール処理エージェントは、IP WAN コールを発信するときに、まずゲートキーパーに許可を要求します。ゲートキーパーが許可を与えると、コール処理エージェントは、IP WAN を介してコールを発信します。ゲートキーパーが要求を拒否する場合、コール処理エージェントは別のパス（たとえば、公衆網）を試行するか、単にコールを廃棄させることができます。

図9-24 ゲートキーパーを使用したハブアンドスポーク トポロジのコール アドミッション制御

ゲートキーパーを使用してコール アドミッション制御を配置する場合は、次のガイドラインに従ってください。

• Cisco Unified CallManager Express と H.323 ゲートウェイの混在環境の場合は、Cisco Unified CallManager で H.225 ゲートキーパー制御トランクを設定します。

• Cisco Unified CallManager クラスタだけに基づく環境の場合は、Cisco Unified CallManager でクラスタ間ゲートキーパー制御トランクを設定します。

• Cisco Unified CallManager で設定したゾーンが、そのサイトの正しいゲートキーパー ゾーンと一致するようにします。

• デバイス プールの Cisco Unified CallManager 冗長性グループにリストされている各 Cisco CallManager サブスクライバは、ゲートキーパー制御トランクをゲートキーパーに登録します（最大で 3 つまで）。

• コールは、Cisco Unified CallManager クラスタ内に登録済みのトランク間にロードバランスされます。

• Cisco Unified CallManager は、複数のゲートキーパーおよびトランクをサポートします。

• トランクをルート グループとルート リスト コンストラクトに配置すると、自動公衆網フェールオーバーを提供できます。詳細については、「ダイヤル プラン」を参照してください。

• Cisco Unified CallManager、Cisco Unified CallManager Express、または H.323 ゲートウェイをサポートしている各サイトに対するゲートキーパーのゾーンは、個別に設定します。

• bandwidth interzone コマンドをゲートキーパーに使用して、そのゲートキーパーに直接登録済みの Cisco Unified CallManager クラスタ、Cisco Unified CallManager Express サーバ、および H.323 デバイス間の帯域幅の制御を行います（コーデック タイプ別の帯域幅の設定については、 表9-2 を参照してください）。

• 1 つの Cisco IOS ゲートキーパーで、100 までのゾーンまたはサイトをサポートできます。

• ゲートキーパーの冗長性は、ゲートキーパー クラスタリング（代替ゲートキーパー）または Cisco ホットスタンバイ ルータ プロトコル（HSRP）を使用すると実装することができます。HSRP は、ソフトウェア機能セットにゲートキーパー クラスタリングが使用可能ではない場合に限り使用します。

（注） 1 つ以上のサイトに IP WAN への二重接続があり、両方のリンクで使用可能な帯域幅を最大限に利用する場合は、「汎用トポロジ」の項で説明しているように、トポロジ対応コール アドミッション制御を配置することをお勧めします。詳細については、「トポロジ非対応コール アドミッション制御の制限」を参照してください。

2 層ハブアンドスポーク トポロジ

図9-25 では、2 層ハブアンドスポーク トポロジを示しています。このタイプのネットワーク トポロジは 3 階層のサイト、つまり第 1 層ハブ サイト、第 2 層ハブサイト、およびスポーク サイトから構成されます。スポーク サイトのグループが 1 つの第 2 層ハブ サイトに接続され、各第 2 層ハブ サイトは 1 つの第 1 層ハブ サイトに接続されます。単純なハブアンドスポーク トポロジであるため、スポーク サイト間には直接のリンクが存在しません。したがって、スポーク サイト間の通信は、すべて第 2 層ハブ サイトを経由する必要があります。同様に、第 2 層ハブ サイト間には直接のリンクが存在しないため、これらのハブ サイト間の通信は、すべて第 1 層ハブ サイトを経由する必要があります。

図9-25 2 層ハブアンドスポーク トポロジ

この項の設計上の考慮事項は、従来のレイヤ 2 IP WAN テクノロジーを使用する 2 層ハブアンドスポーク トポロジに適用されます。

• フレーム リレー

• ATM

• フレーム リレー/ATM 間サービス インターワーキング

• 専用回線

MPLS テクノロジーに基づいた IP WAN 配置については、「単純な MPLS トポロジ」の項を参照してください。

以降では、採用する Cisco Unified CallManager 配置モデルごとに、2 層ハブアンドスポーク トポロジに関する設計上のベスト プラクティスを示します。

• 「集中型の Cisco Unified CallManager 配置」

1 つまたはそれ以上の Cisco Unified CallManager クラスタを第 1 層ハブ サイトに配置し、第 2 層ハブ サイトとスポーク サイトには電話とゲートウェイだけを配置します。

• 「分散型の Cisco Unified CallManager 配置」

Cisco Unified CallManager クラスタを第 1 層ハブ サイトと第 2 層ハブ サイトに配置し、スポーク サイトにはエンドポイントとゲートウェイだけを配置します。

集中型の Cisco Unified CallManager 配置

図9-26 では、2 層ハブアンドスポーク IP WAN トポロジに配置された単一の Cisco Unified CallManager 集中型クラスタを示しています。このシナリオでは、Cisco Unified CallManager クラスタを第 1 層ハブ サイトに配置し、すべての第 2 層ハブ サイトとスポーク サイトにはエンドポイントとゲートウェイだけを配置します。

図9-26 集中型の Cisco Unified CallManager での 2 層ハブアンドスポーク トポロジ

このシナリオでは、トポロジ対応コール アドミッション制御を配置する必要があります。そのため、単一の Cisco Unified CallManager クラスタにとっては、RSVP 対応ロケーションを使用することになります。図9-27 では、このメカニズムを配置する方法を示しています。

図9-27 RSVP 対応ロケーションを使用した 2 層ハブアンドスポーク トポロジのコール アドミッション制御

これらの配置には、次のガイドラインが適用されます。

• 各サイトの Cisco IOS ルータで Cisco IOS RSVP Agent 機能を有効にします。比較的小さなサイトでは、このルータは IP WAN ルータおよび公衆網ゲートウェイと一体になっていることがあり、比較的大きなサイトでは異なるプラットフォームとなっている場合があります。

• Cisco Unified CallManager で、各サイトのロケーションを定義し、すべての帯域幅の値を Unlimited のままにします。

• 各サイトにあるすべてのデバイスを該当するロケーションに割り当てます（これにはエンドポイント、ゲートウェイ、会議リソース、および Cisco RSVP Agent 自体が含まれます）。

• 各 Cisco RSVP Agent が、そのサイトのすべてのデバイスのメディア リソース グループ リスト（MRGL）のメディア リソース グループ（MRG）に属するようにします。

• Cisco CallManager サービス パラメータで、 Default inter-location RSVP Policy を Mandatory または Mandatory (video desired) に設定し、 Mandatory RSVP mid-call error handle option を Call fails following retry counter exceeded に設定します。

• 輻輳が発生する可能性のあるネットワークですべての WAN インターフェイス上の RSVP を有効にし、プライオリティ キューのプロビジョニングに基づいて RSVP 帯域幅を設定します。

• Cisco RSVP Agent が IP WAN ルータと共存していない場合、そのエージェントを WAN ルータに接続する LAN インターフェイスで RSVP を有効にします（図9-27 を参照）。

分散型の Cisco Unified CallManager 配置

2 層ハブアンドスポーク トポロジを採用していて、第 1 層ハブ サイトと第 2 層ハブ サイトに Cisco Unified CallManager がある配置にコール アドミッション制御を提供するには、図9-28 に示されているように静的ロケーションとゲートキーパー ゾーン メカニズムを組み合せて対応します。

図9-28 コール アドミッション制御にロケーションおよびゲートキーパー メカニズムを組み合せる方式

ゲートキーパー ゾーンを静的ロケーションと組み合せてコール アドミッション制御を実行する場合は、次の推奨事項に従ってください。

• ローカル Cisco Unified CallManager を使用していないサイト（つまり、スポーク サイト）には、静的ロケーションに基づくコール アドミッション制御を使用します。

• Cisco Unified CallManager クラスタ間（つまり、第 1 層ハブ サイトと第 2 層ハブ サイト間）には、ゲートキーパー ベースのコール アドミッション制御を使用します。

• ローカル Cisco Unified CallManager を使用していない各サイトには、そのサイトをサポートしている Cisco Unified CallManager クラスタ内にロケーションを設定します。

• 各サイトの帯域幅の上限を、そのサイトに使用されているコーデックのタイプに応じて、適切に設定します（帯域幅の設定については、 表9-1 と 表9-2 を参照してください）。

• Cisco Unified CallManager に設定された各デバイスをロケーションに割り当てます。あるデバイスを別のロケーションに移した場合、ロケーションの設定も変更します。

• Cisco Unified CallManager は、ロケーションを 500 個所までサポートします。

• 各 Cisco Unified CallManager クラスタは、ゲートキーパー制御のトランクをゲートキーパーに登録します。

• ゲートキーパーでは、各 Cisco Unified CallManager クラスタに対してゾーンを設定し、 bandwidth interzone コマンドを使用して各クラスタを宛先および発信元とするコール数を制御します。

（注） 1 つ以上のサイトに IP WAN への二重接続があり、両方のリンクで使用可能な帯域幅を最大限に利用する場合は、「汎用トポロジ」の項で説明しているように、トポロジ対応コール アドミッション制御を配置することをお勧めします。詳細については、「トポロジ非対応コール アドミッション制御の制限」を参照してください。

単純な MPLS トポロジ

図9-29 では、Multiprotocol Label Switching（MPLS）テクノロジー ベースの（サービス プロバイダーからの）IP WAN を示しています。サービス プロバイダーの提供する従来のレイヤ 2 WAN サービスと MPLS ベースのサービスのデザイン上の大きな違いは、MPLS を使用すると、IP WAN のトポロジはハブアンドスポークに準拠していないということです。すべてのサイト間の接続にはフルメッシュ接続方式を採用します。

このトポロジの違いは、ネットワークを企業側での IP ルーティングという観点から見たとき、各サイトが、他のどのサイトからも IP ホップ 1 つ分しか離れていないことを意味します。したがって、他のサイトに到達するためにハブ サイトを経由する必要はありません。事実上、「ハブ サイト」という概念が存在しません。すべてのサイトが対等と見なされ、各サイトで異なっているのは、IP WAN を介して使用することのできる帯域幅の量のみです。

図9-29 サービス プロバイダーからの MPLS IP WAN、およびこれに相当するトポロジ

これまでに検討した内容に基づくと、コール アドミッション制御という観点から見たとき、MPLS に基づくサービス プロバイダー IP WAN サービスは、実質的には、ハブ サイトのないハブアンドスポーク トポロジに相当することが簡単にわかります（図9-29 を参照）。事実上、ネットワーク自体をハブ サイトと見なすことができます。企業サイトは、いずれも（本社、つまり中央サイトを含めて）スポーク サイトに相当します。このように見方を変えると、コール アドミッション制御の実行方法も異なってきます。この方法については、以降で説明します。

上で検討した内容の中で、ここで例外として言及する価値があるのは、マルチサイト配置において、MPLS ベースの WAN がフレーム リレーや ATM などの従来のレイヤ 2 テクノロジー ベースの IP WAN と共存している場合です。このようなシナリオは、実際に発生する可能性があります。たとえば、ネットワークが移行の途中段階にある場合や、企業合併などの状況が発生した場合です。

図9-30 に示すように、従来のレイヤ 2 テクノロジー（フレーム リレーなど）ベースのハブアンドスポーク IP WAN を MPLS ベースの IP WAN と統合すると、ネットワーク トポロジは単純なハブアンドスポークやフルメッシュではなく、2 層ハブアンドスポークになります。

この場合、MPLS ネットワークが第 1 層ハブ サイトを表し、MPLS 対応のフレーム リレー ハブ サイト、および MPLS ベースのサイトが第 2 層ハブ サイトを表し、フレーム リレー スポーク サイトがスポーク サイトを表します。したがって、このような配置での設計上の考慮事項については、「2 層ハブアンドスポーク トポロジ」の項を参照してください。

図9-30 MPLS サイトとフレーム リレー サイトの共存、およびこれに相当するトポロジ

以降では、採用する Cisco Unified CallManager 配置モデルごとに、MPLS ベースのトポロジに関する設計上のベスト プラクティスを示します。

• 「集中型の Cisco Unified CallManager 配置」

1 つまたはそれ以上の Cisco Unified CallManager クラスタを 1 つのサイトだけに配置し、その他のすべてのサイトにはエンドポイントとゲートウェイだけを配置します。

• 「分散型の Cisco Unified CallManager 配置」

Cisco Unified CallManager クラスタを複数のサイトに配置し、その他のすべてのサイトには、エンドポイントとゲートウェイだけを配置します。

（注） ここでは、サービス プロバイダーによって MPLS サービスが提供されている企業の配置を中心に説明します。MPLS ネットワークが企業自体によって配置される場合、次の 2 つのいずれかの条件が満たされる限り、コール アドミッション制御は効果的に実行できます。最初の条件は、MPLS ネットワークでのルーティングが、ネットワークがハブアンドスポークになるように設定されていること、2 番目の条件は、輻輳が末端部分でしか発生しないように、MPLS ネットワークの核の部分の帯域幅を非常に大きく設定していることです。

（注） 1 つ以上のサイトに IP WAN への二重接続があり、両方のリンクで使用可能な帯域幅を最大限に利用する場合は、「汎用トポロジ」の項で説明しているように、トポロジ対応コール アドミッション制御を配置することをお勧めします。ロード バランシング リンクが存在する場合は、対称的なルーティングを保証するために特に注意が必要です。詳細については、「トポロジ非対応コール アドミッション制御の制限」および 「MPLS ネットワークの特別な考慮事項」を参照してください。また、シスコのアカウント チームにお問い合せください。

集中型の Cisco Unified CallManager 配置

MPLS トポロジ上で集中型コール処理を使用するマルチサイト WAN 配置では、Cisco Unified CallManager の静的「ロケーション」を使用してコール アドミッション制御を実装します。

ハブアンドスポーク WAN トポロジ（フレーム リレー、ATM など）では、支店サイトとのリンクはすべて、中央サイトで終端します。フレーム リレーを例にすると、支店ルータからのすべての PVC（Permanent Virtual Circuits; 相手先固定接続）は、中央サイトのヘッドエンド ルータに集約されています。この例では、帯域幅に対する課金は WAN リンクの支店エンドで行われているので、中央サイドではデバイスにコール アドミッション制御を適用する必要はありません。したがって、Cisco Unified CallManager ロケーションの設定では中央サイトのデバイスのロケーションは Hub_None のままにしておきます。一方、各支店のデバイスは適切なコール アドミッション制御を受けるために各支店のロケーションに指定される必要があります。

MPLS WAN ネットワークでは、すべての支店はレイヤ 3 で隣接していると見なされるため、中央サイトに接続する必要はありません。図9-31 では、スポークツースポーク配置による 2 つの支店間のコールを説明しています。

図9-31 MPLS 配置におけるスポークツースポーク コール

また、MPLS WAN では、中央サイト WAN に接続しているリンクは支店の WAN リンクに集約していません。中央サイトに存在するすべてのデバイスは、個々のデバイスに対応するコール アドミッション制御ロケーション（つまり、Hub_None ロケーションではありません）に指定されています。したがって、このスポークツースポーク設定では支店のリンクとは無関係に、コール アドミッション制御は中央サイト リンク上で実行される必要があります（図9-32 を参照）。

（注） トランクなどの一部のデバイスはメディアを終端しないで、通常は Hub_None ロケーションのままにします。ただし、トランクで MTP が要求される場合にコール アドミッション制御のエラーを回避するためには、トランクは Hub_None 以外のロケーションに割り当てる必要があり、トランクの MRGL 内のすべての MTP は、そのロケーションに関連付けられたサイトに物理的に配置する必要があります。MTP はロケーションに直接割り当てることができず、その MTP を選択したデバイスのロケーションを継承するため、この設定が必要です。

図9-32 MPLS 配置におけるハブとのコール

特定サイトに許されている帯域幅がすべて消費されてしまっている場合は、Cisco Unified CallManager が備えている Automated Alternate Routing（AAR）機能を使用して、公衆網へ自動的にフェールオーバーさせることができます（AAR の詳細については、「Automated Alternate Routing」を参照してください）。

分散型の Cisco Unified CallManager 配置

支店ロケーションのない複数のサイトに Cisco Unified CallManager クラスタが設定されていて、どのサイト間も MPLS WAN でリンクされているマルチ サイト配置の場合は、ゲートキーパーがダイヤル プランを解決し、サイト間のコール アドミッション制御を行い、個々のサイトを異なるゲートキーパー ゾーンに格納します。この同様のメカニズムは、レイヤ 2 WAN テクノロジーをべースにしたハブアンドスポークトポロジにも適用されています（図9-33 を参照）。

図9-33 MPLS を使用した分散型配置におけるゲートキーパー コール アドミッション制御

支店サイトが必要な配置では、クラスタ間のダイヤル プランの解決にゲートキーパーを使用することもできますが、コール アドミッション制御にはゲートキーパーを使用しないことをお勧めします。

異なるクラスタに属している支店間にコールが発生した場合は、音声パスはその支店間で直接確立できるので、支店のクラスタから中央サイトへメディアを転送する必要はありません。したがって、コール アドミッション制御は各支店の WAN リンクに必要なだけです（図9-34 を参照）。

図9-34 クラスタ間トランク（ICT）によるマルチ クラスタ接続

Cisco Unified CallManager の集中型配置で見られるように、メディアを各サイトで終端するデバイス（各クラスタに対する中央サイトを含む）は、適切に設定されているロケーションに指定されている必要があります。

クラスタ間トランクで重要なことは、これは単なるシグナリング デバイスであって、クラスタ間トランクのメディアを転送する役目をもたないということです。したがって、クラスタ間トランクのロケーションの指定は、Hub_None のままにしておきます。トランクが MTP を必要とする場合は例外です。この場合は、トランクと MTP の両方を、それらが存在するサイトのロケーションに配置する必要があります。

特定のサイトに許されている帯域幅を消費してしまっている場合は、次の 2 つの方式を組み合せて、公衆網へ自動的にフェールオーバーすることができます。

• マルチ Cisco Unified CallManager クラスタに対するコールには、ルート リストおよびルートグループで対応

• Cisco Unified CallManager クラスタ内のコールには、Automated Alternate Routing（AAR）機能で対応（AAR の詳細については、「Automated Alternate Routing」を参照）

汎用トポロジ

この章の説明における汎用トポロジとは、単純なハブアンドスポーク、2 層ハブアンドスポーク、または単純な MPLS ベースのネットワークに変換できないネットワーク トポロジです。

図9-35 に示すように、汎用トポロジでは、フルメッシュの機能、ハブアンドスポークの機能、部分メッシュの機能、またはこれらのすべての組み合せを 1 つのネットワーク内で実現できます。これは、サイト間の二重接続、および 1 つのサイトから別のサイトへのマルチ パスを表すこともあります。

図9-35 汎用トポロジ

このようなネットワークは複雑な性質を持つため、RSVP に基づくトポロジ対応コール アドミッション制御メカニズムを採用する必要があります。このメカニズムは、特にトポロジの形態が次のような場合に、帯域幅を適切に制御できます。

• さまざまなハブ サイトにデュアル ホーム接続されたリモート サイト

• プライマリ/バックアップ設定またはアクティブ/アクティブ ロード バランシング設定のいずれかによる、任意の 2 つのサイト間の複数の IP WAN リンク

• 冗長ハブまたは専用接続を備えたデータ センター

• フル メッシュ構造のコア ネットワーク

• 任意の 2 つのサイト間の複数の等コスト IP パス

• 多層アーキテクチャ

以降では、採用する Cisco Unified CallManager 配置モデルごとに、汎用ネットワーク トポロジに関する設計上のベスト プラクティスを示します。

• 「集中型の Cisco Unified CallManager 配置」

1 つまたはそれ以上の Cisco Unified CallManager クラスタを特定のサイトに配置し、その他のすべてのサイトにはエンドポイントとゲートウェイだけを配置します。

• 「分散型の Cisco Unified CallManager 配置」

Cisco Unified CallManager クラスタを複数のサイトに配置し、その他のすべてのサイトには、エンドポイントとゲートウェイだけを配置します。

集中型の Cisco Unified CallManager 配置

汎用トポロジを使用した Cisco Unified CallManager の集中型配置は、次の 2 つのサブタイプに分類できます。

• 「単一の Cisco Unified CallManager クラスタ」

• 「同じ場所にある Cisco Unified CallManager クラスタ」

単一の Cisco Unified CallManager クラスタ

この項の推奨事項は、図9-36 に示すように、汎用ネットワーク トポロジで採用される単一の Cisco Unified CallManager クラスタに適用されます。

図9-36 汎用トポロジにおける単一の Cisco Unified CallManager クラスタ

このタイプの配置には、次の考慮事項が適用されます。

• Cisco Unified CallManager が存在する中央サイトなど、各サイトの Cisco IOS ルータで Cisco IOS RSVP Agent 機能を有効にします。比較的小さなサイトでは、このルータは IP WAN ルータおよび公衆網ゲートウェイと一体になっていることがあり、比較的大きなサイトでは異なるプラットフォームとなっている場合があります。

• Cisco Unified CallManager で、各サイトのロケーションを定義し、すべての帯域幅の値を Unlimited のままにします。

• 各サイトにあるすべてのデバイスを適切なロケーションに割り当てます（これにはエンドポイント、ゲートウェイ、会議リソース、および Cisco RSVP Agent 自体が含まれます）。

• 各 Cisco RSVP Agent が、そのサイトのすべてのデバイスのメディア リソース グループ リスト（MRGL）のメディア リソース グループ（MRG）に属するようにします。

• Cisco CallManager サービス パラメータで、 Default inter-location RSVP Policy を Mandatory または Mandatory (video desired) に設定し、 Mandatory RSVP mid-call error handle option を Call fails following retry counter exceeded に設定します。

• 輻輳が発生する可能性のあるネットワークですべての WAN インターフェイス上の RSVP を有効にし、プライオリティ キューのプロビジョニングに基づいて RSVP 帯域幅を設定します（「RSVP を使用するベアラ トラフィックに関する追加の考慮事項」を参照）。

• 音声コールとビデオ コールに対して個別に帯域幅をプロビジョニングする必要がある場合は、同じ WAN ルータ インターフェイス上で RSVP アプリケーション ID も設定する必要があります。

• Cisco RSVP Agent が IP WAN ルータと共存していない場合、そのエージェントを WAN ルータに接続する LAN インターフェイスで RSVP を有効にします。

同じ場所にある Cisco Unified CallManager クラスタ

この項の推奨事項は、複数の Cisco Unified CallManager が同じ LAN または MAN にある配置に適用されます。Cisco Unified CallManager クラスタが存在するサイトが、高速リンクを通じて接続されている場合は、同じ考慮事項が有効なこともあります。ただし、そのリンクのプライオリティ キューに輻輳が発生せず、音声とビデオ用の帯域幅を無制限と見なせることが条件になります。

図9-37 では、所定のサイト（本社）にある 2 つの Cisco Unified CallManager クラスタ、およびエンドポイントとゲートウェイを持つ複数のリモート サイトの配置を示しています。これらのリモート サイトは、クラスタ 1（たとえば支店 1）またはクラスタ 2（たとえば支店 2）のいずれかによって制御されます。

図9-37 汎用トポロジにおける同じ場所にある Cisco Unified CallManager クラスタ

「単一の Cisco Unified CallManager クラスタ」に示すガイドラインに加えて、このタイプの配置では次のベスト プラクティスに従ってください。

• 各クラスタに対して、クラスタ間トランクを定義して他のクラスタとの通信を有効にします。ゲートキーパーはダイヤル プラン解決のために使用できますが、コール アドミッション制御のためには不要です。

• 中央サイト（図9-37 の例では本社）にあるすべてのデバイスで使用される同じロケーションにクラスタ間トランクを割り当てます。

• クラスタ間トランクが、MRGL を指定するデバイス プールに割り当てられるようにします。この MRGL は、中央サイトにある Cisco RSVP Agent（図9-37 のクラスタ 1 では Cisco RSVP Agent HQ 1）を含む MRG を指します。

• クラスタ内でコール アドミッション制御に障害が発生した場合に備えて、AAR 機能を使用して自動公衆網フェールオーバーを提供します。

• クラスタ間でコール アドミッション制御に障害が発生した場合に備えて、ルート リストとルート グループ コンストラクトを使用して、自動公衆網フェールオーバーを提供します。

• メディア トラフィックとシグナリング トラフィックの両方は、異なるクラスタに属する 2 つの支店サイト間のコールに対して、中央サイトを通じたヘアピンになります（図9-37 に示すように支店 1 の電話機 X と支店 2 の電話機 Y 間のコールは本社サイトを通じたヘアピンになります）。

分散型の Cisco Unified CallManager 配置

汎用ネットワーク トポロジで Cisco Unified CallManager の分散型配置にコール アドミッション制御を提供するには、関係する Cisco Unified CallManager クラスタの数によって、次の 2 つの方法が可能です。

• 「リモート Cisco RSVP Agent による方法」

このソリューションは、帯域幅に制限のある IP WAN で接続された異なるサイトに、3 つ以下の Cisco Unified CallManager クラスタが配置される場合に適用されます。

• 「IP-IP ゲートウェイによる方法」

このソリューションは、帯域幅に制限のある IP WAN で接続された異なるサイトに、任意の数の Cisco Unified CallManager クラスタが配置される場合に適用されます。

（注） 高速 IP WAN で接続されたサイトに Cisco Unified CallManager クラスタが配置される場合は、「同じ場所にある Cisco Unified CallManager クラスタ」の項にある説明のように、このシナリオを扱うことができます。ただし、IP WAN リンクのプライオリティ キューに輻輳が発生しないことが条件になります。

リモート Cisco RSVP Agent による方法

異なるサイトに 3 つ以下の Cisco Unified CallManager クラスタが配置された汎用トポロジでコール アドミッション制御を提供するには、図9-38 に示すように、「リモートの」Cisco RSVP Agent を定義することで、RSVP 対応ロケーションの概念を拡張してクラスタ間コールに対応できます。

図9-38 汎用トポロジでの分散型クラスタ用のリモート Cisco RSVP Agent による方法

（注） 簡単にするため、この項の説明は図9-38 に示すように、2 つの Cisco Unified CallManager クラスタの例に基づいています。3 つの Cisco Unified CallManager クラスタの配置については、項の末尾に注記を示しておきます。

「単一の Cisco Unified CallManager クラスタ」の項に示すガイドラインに加えて、このような配置では次のベスト プラクティスに従ってください。

• 各クラスタでは、他のクラスタとの通信を可能にする 2 つのクラスタ間トランク（ICT）を定義します。1 つは「発信」クラスタ間トランク、もう 1 つは「着信」クラスタ間トランクです。

• ダイヤル プラン解決のために（コール アドミッション制御ではなく）Cisco IOS ゲートキーパーを設定し、Cisco Unified CallManager クラスタあたり 1 つのゾーンを定義します。次の例を参考にしてください。

• 各クラスタでは、そのクラスタの通常ゾーン内のゲートキーパーに着信トランクを登録します（たとえば、クラスタ 1 の着信トランクはゾーン cluster1 に登録し、クラスタ 2 の着信トランクはゾーン cluster2 に登録します）。

• 各クラスタで、特別に作成したゾーン内のゲートキーパーに着信トランクを登録します。次の例を参考にしてください。

• 他のクラスタに対する発信コールが着信クラスタ間トランクを使用するように、Cisco Unified CallManager ダイヤル プランを設定します（たとえば、クラスタ 1 では、ルート リストとルート グループ コンストラクトを通じて発信トランクを指す 2XXX ルートを設定します）。

• 特定のクラスタを宛先とするコールがその着信トランクにルーティングされるように、ゲートキーパー ダイヤル プランを設定します。次の例を参考にしてください。

• そのサイトに配置されているすべてのデバイスと同じロケーションに着信トランクを割り当てます（たとえば、クラスタ 1 の着信トランクは本社 1 のロケーションに割り当て、クラスタ 2 の着信トランクは本社 2 のロケーションに割り当てます）。

• 新しく作成したロケーションに発信トランクを割り当てます（たとえば、クラスタ 2 に向かうクラスタ 1 の発信トランクは本社 2 に対するリモートのロケーションに割り当て、クラスタ 1 に向かうクラスタ 2 の発信トランクは本社 1 に対するリモートのロケーションに割り当てます）。

• Cisco Unified CallManager が常駐する 2 つの各サイトで、ローカル クラスタに登録された Cisco RSVP Agent のインスタンスを配置します（たとえば、本社 1 サイトに Cisco RSVP Agent HQ1 を配置し、本社 2 サイトに Cisco RSVP Agent HQ2 を配置します）。

• 該当のサイトに配置されているすべてのデバイスと同じロケーションにローカル Cisco RSVP Agent を割り当てます（たとえば、Cisco RSVP Agent HQ1 は本社 1 のロケーションに割り当て、Cisco RSVP Agent HQ2 は本社 2 のロケーションに割り当てます）。

• 各クラスタで、デバイス プールを通じて着信トランクによって使用される MRGL など、中央サイトに配置されたすべてのデバイスの MRGL に含まれる MRG にローカル Cisco RSVP Agent を割り当てます。

• Cisco Unified CallManager クラスタが存在する 2 つの各サイトで、その他の Cisco Unified CallManager クラスタに登録された Cisco RSVP Agent のインスタンスを追加します（たとえば、リモート Cisco RSVP Agent 1 はクラスタ 1 に登録され、本社 2 サイトに配置されます（このサイトにはクラスタ 2 があります）。一方、リモート Cisco RSVP Agent 2 は クラスタ 2 に登録され、本社 1 サイトに配置されます（このサイトにはクラスタ 1 があります）。

• 発信トランク用に作成されたロケーションに、これらのリモート Cisco RSVP Agent を割り当てます（たとえば、リモート Cisco RSVP Agent 1 はクラスタ 1 内の本社 2 に対するリモートのロケーションに割り当て、リモート Cisco RSVP Agent 2 はクラスタ 2 内の本社 1 に対するリモートのロケーションに割り当てます）。

• 各クラスタで、（デバイス プールを通じて）発信トランクで使用される MRGL に含まれる MRG に、リモート Cisco RSVP Agent を割り当てます。

（注） 論理的には区別されますが、リモート Cisco RSVP Agent インスタンスは、他のクラスタに登録されたローカル Cisco RSVP Agent と同じルータ プラットフォームに存在することがあります。たとえば、図9-38 で、リモート Cisco RSVP Agent 1 と Cisco RSVP Agent HQ2 が実際に同じルータ プラットフォーム上に配置されている可能性があります。また、リモート Cisco RSVP Agent 2 と Cisco RSVP Agent HQ1 についても同じことが当てはまります。

図9-38 で、支店 1 の電話機 X が支店 2 の電話機 Y にコールを発信した場合、Cisco Unified CallManager クラスタ 1 は、発信トランクを通じてゲートキーパーにそのコールをルーティングします。電話機 X は支店 1 のロケーションに割り当てられ、発信トランクは本社 2 に対するリモートのロケーションに関連付けられているため、Cisco Unified CallManager クラスタ 1 は、Cisco RSVP Agent Br 1 とリモート Cisco RSVP Agent 1 の間で IP WAN を通じて RSVP 予約を開始します（後者はクラスタ 2 とともに本社 2 に配置されています）。

次に、ゲートキーパーは、そのゾーン プレフィックス設定に基づいて、クラスタ 2 の着信トランクにコールをルーティングします。

その後、Cisco Unified CallManager クラスタ 2 は、（本社 1 のロケーションに関連付けられた）着信トランクおよび（支店 2 のロケーションに関連付けられた）電話機 Y からコールを受信し、Cisco RSVP Agent HQ2 と Cisco RSVP Agent Br 2 の間で IP WAN を通じてもう 1 つの RSVP 予約を開始します。

このコールは、4 つのコール レッグにわたって確立され、そのうち 2 つは IP WAN を通過し、RSVP に対応しています。

（注） 3 つの Cisco Unified CallManager クラスタのある配置では、同じ検討事項が適用されます。ただし、クラスタあたり 1 つの発信トランクを用意する代わりに、コールされる他の 2 つの各クラスタに対して 1 つずつ、2 つの発信トランクが必要です。同様に、各クラスタには、それぞれ他の 2 つのクラスタの一方に配置される 2 つのリモート Cisco RSVP Agent が必要です。

IP-IP ゲートウェイによる方法

前の項で説明したリモート Cisco RSVP Agent による方法の複雑さは、Cisco Unified CallManager クラスタの数とともに急速に増大します。したがって、最大 3 つのクラスタに限定されます。

異なるサイトに 4 つ以上の Cisco Unified CallManager クラスタが配置された汎用トポロジでコール アドミッション制御を提供するには、図9-39 に示すように、クラスタ内のコールに対する RSVP 対応ロケーションと、クラスタ間のコールに対する RSVP 対応 IP-IP ゲートウェイを組み合せます。

図9-39 汎用トポロジでの分散型クラスタ用の IP-IP ゲートウェイによる方法

「単一の Cisco Unified CallManager クラスタ」の項に示すガイドラインに加えて、このような配置では次のベスト プラクティスに従ってください。

• 各クラスタに対して、ゲートキーパー制御クラスタ間トランクを定義して、他のクラスタとの通信を有効にします（ゲートキーパー ゾーンはダイヤル プラン解決に使用されますが、このシナリオでコール アドミッション制御のためには必要ありません）。

• そのクラスタの中央サイトに配置されたすべてのデバイスで使用される同じロケーションにクラスタ間トランクを割り当てます。

• クラスタ間トランクが、MRGL を指定するデバイス プールに割り当てられるようにします。この MRGL は、中央サイトにある Cisco RSVP Agent（たとえば、図9-39 のクラスタ 1 では Cisco RSVP Agent HQ1）を含む MRG を指します。

• 各クラスタで、そのクラスタの中央サイトに IP-IP ゲートウェイを配置し、このゲートウェイを有効にして、IP WAN を通じた VoIP コールに RSVP を使用します。

• それぞれのゾーンを宛先または発信元とするすべてのコールに対してローカル IP-IP ゲートウェイが呼び出されるように、各クラスタで中継ゾーン ゲートキーパーとしてゲートキーパーを設定します（ゲートキーパーは、IP-IP ゲートウェイと共存する場合があることに注意してください）。

• クラスタ内でコール アドミッション制御に障害が発生した場合に備えて、AAR 機能を使用して自動公衆網フェールオーバーを提供します。

• クラスタ間でコール アドミッション制御に障害が発生した場合に備えて、ルート リストとルート グループ コンストラクトを使用して、自動公衆網フェールオーバーを提供します。

• メディア トラフィックとシグナリング トラフィックの両方は、異なるクラスタに属する 2 つの支店サイト間のコールに対して、それぞれのクラスタの中央サイトを通じたヘアピンになります（図9-39 に示すように支店 1 の電話機 X と支店 2 の電話機 Y 間のコールは本社 1 および本社 2 サイトを通じたヘアピンになります）。

（注） 論理的には区別されますが、Cisco RSVP Agent、ゲートキーパー、および IP-IP ゲートウェイは、同じルータ プラットフォームに存在することがあります。たとえば、図9-39 に示すシナリオで、IP-IP ゲートウェイ 1、ゲートキーパー 1、および Cisco RSVP Agent HQ1 は、IP-IP ゲートウェイ 2、ゲートキーパー 2、および Cisco RSVP Agent HQ2 と同様に、同じルータ プラットフォームに存在することがあります。

図9-39 で、支店 1 の電話機 X が支店 2 の電話機 Y にコールを発信した場合、Cisco Unified CallManager のクラスタ 1 は、クラスタ間トランクを通じて ゲートキーパー 1 にそのコールをルーティングします。電話機 X は支店 1 のロケーションに割り当てられ、クラスタ間トランクは本社 1 のロケーションに関連付けられているため、Cisco Unified CallManager のクラスタ 1 は、Cisco RSVP Agent Br 1 と Cisco RSVP Agent HQ1 の間で IP WAN を通じて RSVP 予約を開始します。

次に、ゲートキーパー 1 は、中継ゾーン設定に基づいて IP-IP ゲートウェイ 1 にコールをルーティングし、IP-IP ゲートウェイ 1 は、IP WAN を通じて IP-IP ゲートウェイ 2 と RSVP 予約を確立します。一方、IP-IP ゲートウェイ 2 は、ゲートキーパー 2 を通じて Cisco Unified CallManager のクラスタ 2 と通信します。

その後、Cisco Unified CallManager のクラスタ 2 は、本社 2 のロケーションに関連付けられたクラスタ間トランクから、（支店 2 のロケーションに関連付けられた）電話機 Y に向けられたコールを受信し、Cisco RSVP Agent HQ2 と Cisco RSVP Agent Br 2 の間で IP WAN を通じてもう 1 つの RSVP 予約を開始します。

このコールは、7 つのコール レッグにわたって確立され、そのうち 3 つは IP WAN を通過し、RSVP に対応しています。