Cisco Unified Communications システム リリース 8.x SRND
コール アドミッション制御
コール アドミッション制御
発行日;2012/12/18 | 英語版ドキュメント(2012/07/30 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 39MB) | フィードバック

目次

コール アドミッション制御

この章の新規情報

コール アドミッション制御の原理

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

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

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

コール アドミッション制御のアーキテクチャ

UnifiedCM の静的ロケーション

ロケーションおよびリージョンの設定

UnifiedCM によるロケーションおよびリージョンのサポート

CiscoIOS ゲートキーパー ゾーン

リソース予約プロトコル(RSVP)を使用した Unified Communications アーキテクチャ

リソース予約プロトコル(RSVP)

RSVP の原理

MPLS ネットワークにおける RSVP

WAN ルータでの RSVP と QoS

RSVP のアプリケーション ID

CiscoIOS の機能

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

RSVP の帯域幅のプロビジョニング

UnifiedCM で使用する RSVP 帯域幅の値の計算

Cisco IOSアプリケーション ID サポートの設定

RSVP および集中型呼処理を使用した呼制御トラフィック用のプロビジョニング

UnifiedCM の RSVP 対応ロケーション

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

Cisco RSVP Agent の登録

RSVP ポリシー

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

RSVP アプリケーション ID と UnifiedCM

RSVP SIP プレコンディション

SIP プレコンディションの概要

Unified Communications Manager および RSVP SIP プレコンディション

Unified CM の相互運用性と機能の考慮事項

Cisco IOS ゲートウェイと Unified CME

Service Advertisement Framework(SAF)および Call Control Discovery(CCD)

Cisco Unified SIP Proxy の考慮事項

Adaptive Security Appliance(ASA)の考慮事項

コール アドミッション制御の設計上の考慮事項

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

集中型の UnifiedCM 配置

分散型の UnifiedCM 配置

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

集中型の UnifiedCM 配置

分散型の UnifiedCM 配置

単純な MPLS トポロジ

集中型の UnifiedCM 配置

分散型の UnifiedCM 配置

汎用トポロジ

集中型の UnifiedCM 配置

分散型混在呼処理配置

TelePresence ビデオの相互運用性アーキテクチャに関するコール アドミッション制御の設計上の推奨事項

サポートされる CAC 配置シナリオと設計上の考慮事項

ロケーション CAC の設計上の考慮事項と推奨事項

設計に関する推奨事項

設計上の考慮事項

RSVP CAC の設計上の考慮事項と推奨事項

設計に関する推奨事項

設計上の考慮事項

UnifiedCM Session Management Edition の配置に関するコール アドミッション制御の設計上の推奨事項

ロケーション CAC を使用する CAC ドメインを管理する Session Management Edition

ロケーション CAC を使用する CAC ドメインを管理するリーフ クラスタ

クラスタ間トランク上のロケーションベースのコール アドミッション制御

クラスタ間トランクを介した QSIG パス置換

RSVP 配置での UnifiedCM Session Management Edition

RSVP SIP プレコンディション サポートのないリーフ クラスタを使用した Session Management Edition の設計

SIP プレコンディション サポートのあるリーフ クラスタを使用した Session Management Edition の設計

混合リーフ クラスタを使用した Session Management Edition の設計(SIP プレコンディション サポートのありとなし)

RSVP Agent のための複数クラスタによる単一プラットフォームの共有

コール アドミッション制御の設計上の推奨事項

コール アドミッション制御

コール アドミッション制御機能は、すべての IP テレフォニー システム(特に IP WAN 経由で接続された複数のサイトで構成されるシステム)に不可欠なコンポーネントです。コール アドミッション制御の機能と必要性をわかりやすく説明するために、図 11-1 の例について考えます。

図 11-1 コール アドミッション制御が必要な理由

 

図 11-1 の左側で示すように、従来の TDM ベースの PBX は、回線交換ネットワークの一部として動作します。このネットワークでは、回線はコールがセットアップされるたびに確立されます。このため、レガシー PBX がPSTN または他の PBX に接続されている場合は、一定数の物理トランクを設定する必要があります。PSTN または他の PBX 宛てのコールをセットアップする必要があるとき、PBX は、使用可能なトランクの中からトランクを選択します。使用可能なトランクがない場合、コールは PBX によって拒否され、発信者にはネットワーク ビジー信号が聞こえます。

次に、図 11-1 の右側に示している IP テレフォニー システムについて考えます。このシステムは、パケット交換ネットワーク(IP ネットワーク)を基盤としているため、IP テレフォニー コールをセットアップするために回線を確立する必要はありません。サンプリング音声を含んでいる IP パケットが、他のタイプのデータ パケットとともに、IP ネットワーク経由でルーティングされるだけです。音声パケットは、Quality of Service(QoS)を使用してデータ パケットと区別されますが、帯域幅リソースは、特に IP WAN リンクでは無限ではありません。このため、ネットワークの管理者が、一定量の「優先」帯域幅を各 IP WAN リンク上の音声トラフィック専用として割り当ててください。ただし、設定した帯域幅がすべて使用される状態になった場合は、IP テレフォニー システムで以後のコールを拒否して、IP WAN リンク上のプライオリティ キューのオーバーサブスクリプションを防止する必要があります。オーバーサブスクリプションが発生すると、すべての音声コールで品質が低下します。この機能はコール アドミッション制御と呼ばれ、IP WAN を利用したマルチサイト配置で良好な音声品質を保証するために不可欠なものです。

エンド ユーザ エクスペリエンスの満足度を維持するには、コール アドミッション制御機能を常にコール セットアップ段階で実行する必要があります。このようにすることで、ネットワーク リソースを使用できない場合に、エンド ユーザにメッセージを表示したり、異なるネットワーク(PSTN などの)を通じてコールを再ルーティングしたりすることができるようになります。

この章では、次の主要トピックについて説明します。

「コール アドミッション制御の設計上の推奨事項」

この項では、この章で説明する原理とメカニズムにすでに精通している読者向けに、コール アドミッション制御に関する主なベスト プラクティス、推奨事項、および注意事項の概要を示します。

「コール アドミッション制御の原理」

この項では、IP ベースのテレフォニー システムにおけるコール アドミッション制御の 2 つの基本的な方法である、トポロジ対応とトポロジ非対応のコール アドミッション制御について説明します。

「コール アドミッション制御のアーキテクチャ」

この項では、Cisco Unified Communications システムのさまざまなコンポーネント、たとえば Cisco Unified Communications Manager ロケーション、Cisco IOS ゲートキーパー、RSVP、RSVP SIP プレコンディションなどで使用できるコール アドミッション制御メカニズムについて説明します。

「コール アドミッション制御の設計上の考慮事項」

この項では、上の項で説明したメカニズムを適用し、組み合わせる方法について、IP WAN のトポロジ(単純なハブアンドスポーク、2 層ハブアンドスポーク、MPLS、またはその他のトポロジ)に基づいて、および採用する Cisco Unified Communications Manager 配置モデルに基づいて示します。

この章の新規情報

表 11-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 11-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明箇所
改訂日

TelePresence ビデオの相互運用性

「TelePresence ビデオの相互運用性アーキテクチャに関するコール アドミッション制御の設計上の推奨事項」

2012 年 4 月 30 日

Cisco Unified Communications Manager Session Management Edition

「Unified CM Session Management Edition の配置に関するコール アドミッション制御の設計上の推奨事項」

2011 年 8 月 31 日

Cisco Unified Border Element および RSVP SIP プレコンディション

「Cisco Unified Border Element および RSVP SIP プレコンディション」

2010 年 11 月 15 日

Cisco IOS における RSVP コール アドミッション制御機能の拡張

「Cisco IOS の機能」

2010 年 11 月 15 日

Extension Mobility Cross Cluster; クラスタ間のエクステンション モビリティ

「クラスタ間のエクステンション モビリティのアーキテクチャおよび考慮事項」

2010 年 4 月 2 日

相互運用性

「Unified CM の相互運用性と機能の考慮事項」

2010 年 4 月 2 日

リソース予約プロトコル(RSVP)

「リソース予約プロトコル(RSVP)を使用した Unified Communications アーキテクチャ」

2010 年 4 月 2 日

RSVP のアプリケーション ID

「RSVP アプリケーション ID と Unified CM」

2010 年 4 月 2 日

Service Advertisement Framework(SAF)および Call Control Discovery(CCD)

「Service Advertisement Framework(SAF)および Call Control Discovery(CCD)」

2010 年 4 月 2 日

SIP プレコンディション

「RSVP SIP プレコンディション」

2010 年 4 月 2 日

コール アドミッション制御の原理

すでに述べたように、コール アドミッション制御は、IP ベースのテレフォニー システムの呼処理エージェントの機能です。したがって理論上は、IP ベースのテレフォニー システムと同じ数のコール アドミッション制御メカニズムが存在する可能性があります。しかし、ほとんどの既存のコール アドミッション制御メカニズムは、次の 2 つの主なカテゴリのいずれかになります。

トポロジ非対応コール アドミッション制御:呼処理エージェント内の静的設定に基づくもの

トポロジ対応コール アドミッション制御:使用可能なリソースに関する呼処理エージェントとネットワーク間の通信に基づくもの

次の項では、トポロジ非対応コール アドミッション制御の原理とその制限について分析し、次にトポロジ対応コール アドミッション制御の原理を示します。

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

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

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

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

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

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

 

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

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

 

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

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

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

現在の企業ネットワークでは、ハイ アベイラビリティは共通の要件であり、そのために IP WAN ネットワーク接続に冗長性が求められることがあります。

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

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

 

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

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

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

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

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

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

 

図 11-5 の最初の例で、拠点オフィス A は通常、最大 10 の同時コールが可能になるよう、低遅延キューイング(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 テレフォニー システムは、ネットワークで検知された輻輳に基づくフィードバック メカニズムで、従来のトポロジ非対応コール アドミッション制御を拡張します。これにより、音声品質が低下した場合、コールが強制的に PSTN 経由になります。呼処理エージェントはコールの確立後に実行されることと、輻輳が発生している正確な場所を認識しないという理由から、この方法はまだ真のトポロジ対応コール アドミッション制御と同等ではありません。この章の最初に述べたように、効果的に運用するには、コールをセットアップする前にコール アドミッション制御を実行する必要があります。


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

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

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

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

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

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

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

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

 

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

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

 

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

RSVP は独自のルーティングを実行しません。その代わりに、基礎となるルーティング プロトコルを使用して、予約要求を伝送すべき場所を特定します。トポロジの変更に対応するためにルーティングのパスが変化すると、RSVP は、自身の予約を予約が存在する新しいパスに合せて調整します。

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

RSVP PATH メッセージは、通過する RSVP 対応ルータの出口 IP アドレスを記録します。PATH メッセージの情報は、RSVP RESV メッセージを同じルートで返信するために使用されます。このメカニズムのため、CE と PE 間の WAN リンクにルーティング可能な IP アドレスがないと、RSVP 予約は失敗します。

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

コール アドミッション制御のアーキテクチャ

Cisco Unified Communications システムには、コール アドミッション制御機能を実行する複数のメカニズムがあります。この項では、次のカテゴリに従って、すべてのメカニズムの設計と設定のガイドラインについて説明します。

トポロジ非対応メカニズム

「Unified CM の静的ロケーション」

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

トポロジ対応メカニズム

「Unified CM の RSVP 対応ロケーション」

「RSVP SIP プレコンディション」

Unified CM の静的ロケーション

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

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

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

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

IP Phone

CTI ポート

H.323 クライアント

CTI ルート ポイント

カンファレンス ブリッジ

保留音(MoH)サーバ

ゲートウェイ

トランク

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

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

表 11-2 静的ロケーション アルゴリズムが要求する帯域幅

コールのビット レート
静的ロケーションの帯域幅の値

G.711 音声コール(64 Kbps)

80 kbps

G.729 音声コール(8 Kbps)

24 kbps

128 kbps ビデオ コール

128 kbps

384 Kbps ビデオ コール

384 kbps

512 Kbps ビデオ コール

512 kbps

768 Kbps ビデオ コール

768 kbps

コーデックおよび静的ロケーション帯域幅値のリストについては、次の Web サイトで入手可能な『 Cisco Unified Communications Manager System Guide 』の「 Call Admission Control 」の項の帯域幅計算情報を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

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


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


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

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


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


ロケーションおよびリージョンの設定

ロケーションは、リージョンとともに、ネットワーク リンクの特性を定義します。リージョンではリンクで使用する圧縮またはビット レートのタイプ(8 kbps または G.729、64 kbps または G.722/G.711 など)を定義し、ロケーションではリンクに使用できる帯域幅の容量を定義します。システム内の各デバイスを(デバイス プールを使用して)リージョンに割り当て、(デバイス プールまたはデバイス自体に直接設定した値を使用して)ロケーションに割り当てます。

Unified CM では、 ロケーション を設定することにより、次の要素を定義できます。

物理的なロケーション(支社など)。

WAN 内のロケーションとの間でやり取りされる音声コールおよび FAX コールに利用できる帯域幅。Unified CM では、ロケーションベースのコール アドミッション制御にこの帯域幅値が使用されます。

WAN 内のロケーションとの間でやり取りされるコールに利用できるビデオ帯域幅。Unified CM では、ロケーションベースのコール アドミッション制御にこの帯域幅値が使用されます。

ロケーション間の RSVP コール アドミッション制御の設定 (可能な設定は、[No Reservation]、[Optional]、[Optional (Video Desired)]、[Mandatory]、および [Mandatory (Video Desired)] です)。

Unified CM では、 リージョン を設定することにより、次の要素を定義できます。

リージョン内コールに使用する最大オーディオ ビット レート設定(Max Audio Bit Rate)

リージョン間コールに使用する最大オーディオ ビット レート設定(Max Audio Bit Rate)

リージョン内コールおよびリージョン間コールに使用するビデオ コールの最大ビット レート設定(音声を含む)(Max Video Call Bit Rate(Includes Audio))

リージョン間コールのリンク損失タイプ(可能なリンク損失タイプは [Low Loss] および [Lossy] です)。

Unified CM によるロケーションおよびリージョンのサポート

Cisco Unified Communications Manager は、Cisco MCS-7845 サーバで 2000 のロケーションと 2000 のリージョンをサポートします。最大 2000 のロケーションおよびリージョンを配置するには、[Clusterwide Parameters] >([System] > [Location and Region])および [Clusterwide Parameters] >([System] > [RSVP])の設定メニューで次のサービス パラメータを設定する必要があります。

Default Intraregion Max Audio Bit Rate

Default Interregion Max Audio Bit Rate

Default Intraregion Max Video Call Bit Rate (Includes Audio)

Default Interregion Max Video Call Bit Rate (Includes Audio)

Default Intraregion and Interregion Link Loss Type

リージョンを追加するときは、[Max Audio Bit Rate] と [Max Video Call Bit Rate] の値として [Use System Default] を選択してください。RSVP コール アドミッション制御を使用している場合は、[RSVP Setting] パラメータにも [Use System Default] を選択します。

個々のリージョンおよびロケーションについてこれらの値をデフォルトから変更すると、サーバの初期化とパブリッシャのアップグレードにかかる時間に影響します。合計 2000 のリージョンと 2000 のロケーションを使用する場合、そのうち最大 200 のリージョンおよびロケーションでデフォルト以外の値を使用するように変更できます。合計 1000 以下のリージョンおよびロケーションを使用する場合、そのうち最大 500 のリージョンおよびロケーションでデフォルト以外の値を使用するように変更できます。 表 11-3 は、これらの制限を要約したものです。

 

表 11-3 デフォルト以外の値を使用できるリージョンおよびロケーションの数

デフォルト以外の値を使用するリージョンおよびロケーションの数
リージョンの最大数
ロケーションの最大数

0 ~ 200

2000

2000

200 ~ 500

1000

1000


) [Max Audio Bit Rate] は、音声コールと FAX コールの両方に使用されます。リージョン間コーデックとして G.729 を使用する場合、FAX コールには T.38 FAX リレーを使用してください。WAN で FAX パススルーを使用する場合は、[Interregion Max Audio Bit Rate] をデフォルト値から 64 kbps(G.722 または G.711)に変更するか、デフォルト値でない 64 kbps(G.722 または G.711)ビット レートを使用する各ロケーションに FAX マシンのリージョンを追加します(表 11-3 内の制限に従います)。



) 使用している MCS モデルに関係なく、多数のリモート サイトを包含する設計には、Unified CM クラスタのスケーラビリティ(リージョン、ロケーション、ゲートウェイ、メディア リソースなど)に影響する可能性ある相互依存変数が多数存在するため、シスコ代理店またはシスコのシステム エンジニアが常に Cisco Unified Communications Sizing Tool(http://tools.cisco.com/cucst)を使用して、それらの設計をすべて検証する必要があります。サイジング ツールを使用して、設計基準を満たすために必要なサーバまたはクラスタの正確な台数を決定します。


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

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

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

使用可能な Cisco IOS ゲートキーパー プラットフォームおよび各プラットフォームでサポートされている機能のリストを見るには、次の Web サイトで入手可能な『 Cisco IOS H323 Gatekeeper Data Sheet 』を参照してください。

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps4139/data_sheet_c78_561921.html

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

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

ゲートキーパーの設定の詳細については、次の Web サイトから入手可能な『 Cisco IOS H.323 Configuration Guide 』を参照してください。

http://www.cisco.com/en/US/docs/ios/voice/h323/configuration/guide/15_0/vh_15_0_book.html

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

表 11-4 さまざまなコール ビット レートにおけるゲートキーパーの帯域幅設定

コールのビット レート
ゲートキーパーの帯域幅の値

G.711 音声コール(64 Kbps)

128 kbps

G.729 音声コール(8 Kbps)

16 kbps

128 kbps ビデオ コール

256 kbps

384 Kbps ビデオ コール

768 kbps

512 Kbps ビデオ コール

1024 kbps

768 Kbps ビデオ コール

1536 kbps


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


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

図 11-10 Cisco IOS Gatekeeper の bandwidth コマンドの例

 

すべてのコールが G.711 コーデックを使用する音声専用コールであるとすると、図 11-10 に示すコンフィギュレーション コマンドについて、次のことがいえます。

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 つのアクティブなコールが存在できます。

リソース予約プロトコル(RSVP)を使用した Unified Communications アーキテクチャ

ここでは、リソース予約プロトコル(RSVP)をコール アドミッション制御メカニズムとして実装するさまざまな Unified Communications アーキテクチャを取り上げます。RSVP の紹介とプロトコル アーキテクチャの概要、RSVP と Quality of Service の概念、アプリケーション ID、およびインフラストラクチャ設計上の考慮事項と推奨事項の概要から始めます。

次に、単一クラスタ Unified CM 環境での Unified CM RSVP 対応ロケーションについて説明します。具体的には、関与するコンポーネントとそのコンポーネントのプロビジョニング、Unified CM による RSVP ポリシーとアプリケーション ID の使用、および静的ロケーションに基づいてコール アドミッション制御から移行するための推奨戦略を取り上げます。

続いて、分散型呼処理アーキテクチャについて説明します。RSVP SIP プレコンディションの説明から始まり、その機能の概要と、その機能が Unified CM、Unified CME、SIP-TDM Cisco IOS ゲートウェイなどさまざまな呼制御アプリケーション間で RSVP レイヤおよび呼制御レイヤを同期する仕組みについて説明します。次に、機能の注意事項や設計の推奨事項と考慮事項を含め、RSVP SIP プレコンディションに関して各呼制御アプリケーションを詳しく説明します。

リソース予約プロトコル(RSVP)

リソース予約プロトコル(RSVP)は、異種ネットワークにわたってエンドツーエンドの QoS を動的にセットアップするための、実質上最初の業界標準プロトコルです。RSVP は IP を基盤として機能し、IETF によって RFC 2205 で最初に導入されました。RSVP を使用すると、アプリケーションがネットワーク帯域幅を動的に予約できます。RSVP を使用すると、ネットワークを流れるデータ フローに関して、アプリケーションが一定レベルの QoS を要求できます。分散型ネットワークに対応し、動的に機能する性質を持っているため、RSVP はあらゆるネットワーク トポロジにわたって帯域幅を予約できます。つまり、音声コールとビデオ コールにトポロジ対応コール アドミッション制御を提供できます。

この項では、RSVP プロトコルの原理と、このプロトコルと WAN のインフラとの対話を中心に、特に QoS について説明します。RSVP に基づくコール アドミッション制御の目的とメカニズムについては、この章の他の項で説明します。

この項では、次のトピックを扱います。

「RSVP の原理」

「MPLS ネットワークにおける RSVP」

「WAN ルータでの RSVP と QoS」

「RSVP のアプリケーション ID」

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

RSVP の原理

RSVP は、ネットワーク全体で、指定されたデータ フローのリソース予約を行います。RSVP 予約は単方向です。このため、2 つの RTP ストリームを含む単一の音声コールでは、各 RTP ストリームに 1 つずつの 2 つの RSVP 予約が生成されます。リソース予約は、データ フローの発信元デバイスと宛先デバイス間でシグナリング メッセージを交換することで作成され、メッセージはパスに沿って介在するルータにより処理されます。RSVP シグナリング メッセージは、IP ヘッダーのプロトコル番号が 46 に設定されている IP パケットで、既存のルーティング プロトコルに従ってネットワーク内でルーティングされます。

パス上のすべてのルータで RSVP をサポートする必要はありません。このプロトコルは、RSVP に対応していないノードでは透過的に動作するように設計されています。各 RSVP 対応ルータで、RSVP プロセスがシグナリング メッセージを代行受信し、帯域幅リソースを「予約」するために、データ フローに含まれるルータの発信側インターフェイスの QoS マネージャと対話します。パスの任意の場所で、使用可能なリソースがそのデータ フローには不十分な場合、ルータは予約要求を発信したアプリケーションに、失敗を示す信号を返します。

RSVP シグナリングの原理は、図 11-11 に示す例で説明できます。この図では、デバイス 1(IP アドレス 10.10.10.10)からデバイス 2(IP アドレス 10.60.60.60)に流れるデータ ストリーム用に、アプリケーションがネットワーク リソースを予約しようとします。

図 11-11 RSVP Path と Resv メッセージ フローの例

 

次の手順では、図 11-11 の例に示すように、単一データ フローとしての RSVP シグナリング プロセスついて説明します。

1. デバイス 1 にあるアプリケーションが Path という RSVP メッセージを発信します。このメッセージは、予約を要求するデータ フローと同じ宛先 IP アドレス(10.60.60.60)に送信され、IP ヘッダーの「router alert」オプションがオンにされて送信されます。Path メッセージには、特に次のオブジェクトが含まれています。

「session」オブジェクト。宛先 IP アドレス、プロトコル番号、および UDP/TCP ポートで構成され、RSVP 対応ルータでデータ フローを識別するために使用します。

「sender T-Spec」(トラフィック仕様)オブジェクト。予約が要求されたデータ フローの特性を示します。T-Spec は基本的に、特定のコーデックを使用するコール フローに必要な最大 IP 帯域幅を定義します。T-Spec は通常、データ フローの平均ビット レート、ピーク レート、およびバースト サイズの値を使用して定義されます。T-Spec については、この章の後半で詳しく説明します。

「P Hop」(以前のホップ)オブジェクト。Path メッセージを最後に処理したルータ インターフェイスの IP アドレスが含まれます。この例では、P Hop は最初にデバイス 1 で 10.10.10.10 に設定されます。

2. 「router alert」オプションによって、Path メッセージは RSVP 対応ルータ(図 11-11 の 10.20.20.20)の CPU が代行受信し、RSVP プロセスに送信されます。RSVP は、このデータ フローのパス状態を作成し、Path メッセージに含まれる session オブジェクト、sender Tspec オブジェクト、および P Hop オブジェクトの値を格納します。次に、P Hop 値を発信インターフェイスの IP アドレス(この例では 10.20.20.20)で置き換えて、メッセージをダウンストリームに転送します。

3. 同様に、次の RSVP 対応ルータ(図 11-11 の 10.30.30.30)の CPU が Path メッセージを代行受信します。パス状態を作成し、P Hop 値を 10.30.30.30 に変更した後、このルータもメッセージをダウンストリームに転送します。

4. 次に、Path メッセージは、RSVP 非対応ルータ(図 11-11 の 10.40.40.40)に到達します。このルータでは RSVP が有効でないため、このメッセージは他の IP パケットと同様に、追加の処理やメッセージ オブジェクトの内容の変更は行われずに、既存のルーティング プロトコルに従ってルーティングされます。

5. その結果、Path メッセージは RSVP 対応ルータ(10.50.50.50)に転送され、ここでメッセージが処理され、対応するパス状態が作成され、メッセージがダウンストリームに転送されます。このルータで記録される P Hop には、ネットワーク パスの最後の RSVP 対応ルータの IP アドレス(この例では 10.30.30.30)がまだ含まれていることに注意してください。

6. デバイス 2 の RSVP 受信側は、P Hop 値が 10.50.50.50 の Path メッセージを受信します。ここで、Resv というメッセージを発信することによって、実際の予約が開始されます。このため、RSVP は受信側開始プロトコルと呼ばれます。Resv メッセージは、セッションのデータ フローの逆方向のパスに従って、予約要求を受信側から送信側にホップごとに伝達します。各ホップでの Resv メッセージの IP 宛先アドレスは、パス状態から取得した直前のホップ ノードの IP アドレスです。したがって、この例では、デバイス 2 は宛先 IP アドレスが 10.50.50.50 の Resv メッセージを送信します。Resv メッセージには、特に次のオブジェクトが含まれています。

「session」オブジェクト。データ フローの識別に使用します。

「N Hop」(ネクスト ホップ)オブジェクト。メッセージを生成したノードの IP アドレスが含まれます。この例では、N Hop は最初にデバイス 2 で 10.60.60.60 に設定されます。

7. 10.50.50.50 の RSVP 対応ルータがこのデータ フローの Resv メッセージを受信すると、受信した session オブジェクトを使用してパス状態情報と照合され、次の基準に基づいて予約要求を受け入れることができるかどうかが確認されます。

ポリシー制御:このユーザやアプリケーションが、この予約要求を行えるかどうか。

アドミッション制御:関連する発信インターフェイスに、この予約要求を満たせるだけの帯域幅リソースがあるかどうか。

8. この例では、10.50.50.50 でポリシー制御とアドミッション制御の両方が成功したとします。つまり、このセッションのパス状態の Tspec で提供される帯域幅は、発信インターフェイス(データ フローと同じ方向で、デバイス 1 からデバイス 2)で予約され、対応する「予約状態」が作成されるものとします。次に、10.50.50.50 のルータは、このセッションの P Hop に格納されている宛先 IP アドレス(10.30.30.30)にユニキャスト IP パケットとして送信することによって、Resv メッセージをアップストリームに送信できます。N Hop オブジェクトも、値 10.50.50.50 に更新されます。

9. 次に、Resv メッセージは、10.40.40.40 の RSVP 非対応ルータを通過します。ここでは、他の IP パケットと同様に、宛先 10.30.30.30 にルーティングされます。このメカニズムによって、RSVP シグナリングは、RSVP に対応していないノードが含まれる異種ネットワークで機能します。

10. 10.30.30.30 の RSVP 対応ルータは、Resv メッセージを受信し、ステップ 7 および 8 で説明したメカニズムに従って処理します。このホップでも、ポリシー制御およびアドミッション制御が成功したとします。帯域幅が発信インターフェイスで予約され、Resv メッセージが前のホップ(この例では 10.20.20.20)に送信されます。

11. 10.20.20.20 のルータで同様の処理が行われた後、Resv は最終的に RSVP 送信側のデバイス 1 に到達します。これによって、要求元のアプリケーションに対して、エンドツーエンド予約が確立され、ネットワークのすべての RSVP 対応ルータで、帯域幅がこのデータ フロー用に確保されたことが示されます。

この例では、2 つの主な RSVP シグナリング メッセージである Path と Resv がネットワークを通過し、予約を確立する方法を示しました。RSVP 標準では、エラー状態、予約失敗、およびリソースの解放を扱うその他のメッセージがいくつか定義されています。特に、ResvErr メッセージは、要求されたリソースがネットワーク上のいずれかでポリシー制御またはアドミッション制御によって予約できなかったことを示すために使用されます。たとえば、図 11-11 のノード 10.50.50.50 でアドミッション制御が失敗した場合、このノードは失敗の原因を示す ResvErr メッセージをデバイス 2 に送信して、アプリケーションがこの通知を受け取ります。

もう 1 つの RSVP プロトコルの重要な点として、ソフト状態アプローチの採用があります。これは、同一の Path メッセージと Resv メッセージを送信することによって、ネットワーク上でセッションごとにパス状態と予約状態をアプリケーションで定期的にリフレッシュする必要があるという意味です。あるセッションについて、一定の時間、ルータがリフレッシュ メッセージを受信しない場合、対応する状態が削除され、予約されたリソースが解放されます。これによって、RSVP は動的に、リンク障害によるネットワーク トポロジの変更またはルーティングの変更に対応できます。予約では、単純に、ルーティング プロトコルの決定に従って新しいルートのフローが開始され、古いルートの予約はタイムアウトして最終的に削除されます。

MPLS ネットワークにおける RSVP

一部の MPLS サービス プロバイダー ネットワークでは、カスタマー エッジ(CE)とプロバイダー エッジ(PE)間のリンクで使用する IP アドレスは、その他の MPLS ネットワークには配布されません。そのため、サブネットは PE にローカルにとどまり、PE を越えてアドバタイズされることはありません(これらが一意ではなく、他の場所でも再利用されるためです)。これにより、RSVP メッセージの P Hop(以前のホップ)値がネットワーク内で不明であるため、RSVP が RSVP メッセージを転送できない状況が発生します。図 11-12 は、このタイプの状況を示しています。

図 11-12 P Hop 上書きしない MPLS 上での RSVP

 

図 11-12 は、企業ネットワークとサービス プロバイダーの MPLS ネットワークを示しています。CE1 と CE2 は RSVP 対応、PE1 と PE2 は RSVP 非対応です。RSVP Path メッセージには P Hop オブジェクトが含まれています。このオブジェクトは、すべての RSVP ホップで書き直されます。これは、CE1 が以前の RSVP ホップ(または P Hop)であることを示すために、RSVP ルータ(たとえば、CE1)が Path メッセージを、次の RSVP ルータ(たとえば、CE2)に送信できるようにするためです。この情報は、対応する Resv メッセージをホップバイホップでアップストリームの送信側に転送するために CE2 によって使用されます。

Cisco IOS では、RSVP ルータは、常に P Hop アドレスを Path メッセージを送信する出力インターフェイスの IP アドレスに設定します。一部の CE1 の IP アドレスが到達可能であるにもかかわらず、その出力インターフェイスの IP アドレスが、リモートの RSVP ルータ CE2 から到達できない場合があります。その結果、CE2 によって生成された対応する Resv メッセージが CE1 に到達しないため、予約が確立されなくなります。

コールが A1 から A2 に発信されると、A1 は RSVP セッションをセットアップしようとして、Path メッセージを CE1 に送信することで開始します。A1 は、発信インターフェイスの IP アドレス(この場合、10.10.10.10)の Path メッセージ内の P Hop オブジェクトを取り込みます。次に、CE1 は、Path メッセージを受信し、それを処理し、対応するパス状態を作成し、その出力インターフェイスの IP アドレス(171.70.48.5)を持つメッセージの P Hop フィールドを更新します。このアドレスは、ルーティング可能な IP アドレスではないため、Path メッセージをダウンストリームに転送します。この Path メッセージは、サービス プロバイダーのネットワークを通り抜け、CE2 によって処理されます。Path メッセージを受信した後、CE2 は、P Hop オブジェクトの IP アドレス(CE1 の出力インターフェイスの IP アドレス)を記録し、Path メッセージをダウンストリームの A1 に転送します。A1 は、Path メッセージを記録および処理して、RSVP メッセージを CE2 に発信します。CE2 は、RSVP メッセージを処理し、それ自身の RSVP メッセージをアップストリームの CE1 に送信します。ただし、CE2 がこの Resv メッセージに対して応答する場合、CE2 は CE1 から受信した Path メッセージから以前に記録した IP アドレスに送信しようとします。この IP アドレス(171.70.48.5)は CE2 からルーティングできないので、Resv メッセージは失敗し、この結果予約試行は失敗します。

この動作を解決するため、Cisco IOS Release 12.4(20)T には Previous Hop Overwrite(以前のホップの上書き)という機能を導入しています。P Hop の上書きは、カスタマーの VPN で到達可能なルータ上の他のインターフェイスからの IP アドレスを含む Path メッセージ内の Hop オブジェクトを CE が取り込むメカニズムです。この方法で、Resv メッセージは送信側に戻る経路を見つけ、予約を確立できます。P Hop の上書きメカニズムは、図 11-13 に示されています。

図 11-13 Cisco IOS 12.4(20)T における RSVP P Hop の上書き機能

 

RSVP(TSpec)におけるデータ フロー特性の説明

RSVP は、音声またはビデオだけに限らず、レイヤ 2 テクノロジーの広範囲にわたる任意のトラフィック フローの Quality of Service(QoS)の要求をサポートするように設計されました。このような処理を実現するために、RSVP は、QoS を要求しているトラフィック フローを詳細に記述して、中間ルータが正しくアドミッションを決定できるようにする必要があります。

RSVP セッションのデータ フローの帯域幅の要件は、Path メッセージに含まれる TSpec(トラフィック仕様)の送信側によって特性が設定され、Resv メッセージの受信側によって送信される RSpec(予約仕様)にミラーリングされます。TSpec は、ネットワークを経由して、すべての中間ルータと宛先エンドポイントに転送されます。中間ルータはこのオブジェクトを変更せず、オブジェクトは最終受信者へ無変更のまま送信されます。

TSpec オブジェクトには、次の要素が含まれています。

AverageBitRate(kbps)

BurstSize(バイト)

PeakRate(バイト)

オーディオ TSpec

オーディオ フローでは、TSpec の計算が次の測定値を指定します。

AverageBitRate(kbps):IP オーバーヘッドを含む

BurstSize(バイト):この値は、バースト内のパケットのサイズにパケット数を掛けて算出されます。オーディオ フローでは、バーストは通常 1 ~ 2 を指定します。

PeakRate(バイト):ピーク レート(バイト単位)は、エンドポイントが任意の時間に送信する最大バイト/秒を指します。オーディオ ストリームの場合と同様に、バーストが小さい場合、ピーク レートは tokenRate の 1.1(または 1.2)倍として計算できます。

コールが応答されたときに、帯域幅予約を上方に調整するのを回避するために、Cisco Unified CM は、各リージョン コーデックに対する最大帯域幅をコール セットアップ時間で予約します。次に、Unified CM は、コールが応答されたときに、接続された当事者のメディア能力に基づく帯域幅を変更または調整します。

Unified Communications 対応 RSVP の詳細については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager System Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html


) この項では、RSVP の原理とメカニズムの概要を中心に説明しています。プロトコルの動作および拡張の詳細、完全なメッセージ形式、および他のプロトコルとの対話については、http://www.ietf.org で入手可能な RSVP に関する多くの RFC ドキュメントを参照してください。


WAN ルータでの RSVP と QoS

RSVP は、長い間 Cisco ルータでサポートされていましたが、このマニュアルで推奨するほとんどの設定は、Cisco IOS Release 12.2(2)T で最初に導入された RSVP Scalability Enhancements 機能に基づいています。

各 Cisco IOS ルータ インターフェイス上で、次の Cisco IOS コマンドをインターフェイス コンフィギュレーション モードで発行すると、RSVP を有効にし、RSVP で制御できる帯域幅の最大量を定義できます。

ip rsvp bandwidth [interface-kbps] [single-flow-kbps]
 

interface-kbps パラメータには、RSVP が所定のインターフェイス上で予約できる帯域幅の上限を指定します。 single-flow-kbps パラメータには、予約 1 つあたりの帯域幅の上限を指定します(要求している帯域幅がこれより大きいフローは、インターフェイス上に使用可能な帯域幅がある場合でも拒否されます)。


) ルータ インターフェイスで RSVP を有効にすると、そのルータで RSVP に対応していないその他のすべてのインターフェイスが、RSVP メッセージをドロップします。RSVP メッセージのドロップを防ぐには、RSVP シグナリングが通過すると予想されるすべてのインターフェイスで RSVP を有効にします。インターフェイスでコール アドミッション制御を使用しない場合は、帯域幅の値をインターフェイス帯域幅の 75% に設定します。


Cisco IOS では、2 つの異なるモデルに従って運用するように RSVP を設定できます。RFC 2210 で記述されている統合サービス(IntServ)モデル、および RFC 2998 で記述されている統合サービス/ディファレンシエーテッド サービス(IntServ/DiffServ)モデルです。どちらの RFC ドキュメントも、次の IETF Web サイトで入手できます。

http://www.ietf.org

図 11-14 に、Cisco IOS ルータから見た、これらの 2 つのアプローチの相違点を示します。

図 11-14 2 つの RSVP 運用モデル:IntServ と IntServ/DiffServ

 

IntServ モデル

図 11-14 の左側に示すように、IntServ モデルの RSVP には、コントロール プレーンとデータ プレーンの両方が関係します。コントロール プレーンでは、RSVP が予約要求を許可または拒否します。データ プレーンでは、データ パケットを分類し、RSVP メッセージに含まれているトラフィック記述に基づいてポリシングし、適切なキューに入れます。RSVP が実行する分類は、送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、およびプロトコル番号を構成している、5 つのタプルに基づいています。このモデルでは、ルータを通過するすべてのデータ パケットを RSVP で代行受信して、RSVP でこの 5 タプルを検査し、確立済みの予約と一致するかどうかを検索できるようにする必要があります。一致が見つかった場合は、その予約のトラフィック仕様に従って、パケットが RSVP によってスケジューリングされ、ポリシングされます。

図 11-15 で示すように、IntServ モデルを Low Latency Queuing(LLQ)と組み合わせる場合、使用可能な帯域幅が RSVP と事前定義済みの LLQ キューで分割されます。RSVP は、RSVP 予約された帯域幅への入力基準を制御します。ポリシー マップは、事前定義済みキューの入力基準を制御します。

図 11-15 IntServ モデルと LLQ の組み合わせ

 

Cisco IOS ルータで IntServ 運用モデルを使用するには、インターフェイス コンフィギュレーション モードで次のコマンドを使用します。

ip rsvp resource-provider wfq [interface | pvc]
no ip rsvp data-packet classification
 

これらのコマンドがアクティブになっている場合、RSVP は、新しい予約を許可または拒否するとき、 ip rsvp bandwidth コマンドで定義した帯域幅上限に加えて、使用可能な実際の帯域幅リソースも基準にします。たとえば、bandwidth ステートメントを持つ LLQ クラスが存在する場合は、RSVP 予約に割り当てることのできる帯域幅プールから、それらの量が減分されます。LLQ クラスは、設定すると帯域幅を静的に割り当てます。これに対して、RSVP は、予約要求を受信するまでは帯域幅を一切割り当てません。このため、LLQ クラスに割り当てられることが ない 使用可能インターフェイス帯域幅を適度に確保して、予約要求を受信したときに RSVP が使用できるようにしておくことが重要です。

リンクで QoS メカニズムに割り当てることができる合計最大帯域幅はリンク速度の 75% なので、リンク帯域幅の 33% を RSVP で許可されるフローに予約するには、LLQ クラスに割り当てる帯域幅がリンク帯域幅の(75 - 33)= 42% を超えないようにする必要があります。

このモデルでは、各種キューへのパケットの割り当てを RSVP が制御します。このため、次の Cisco IOS コマンドをインターフェイス コンフィギュレーション モードで使用すると、データ フロー T-Spec 値に基づくプライオリティ キュー(PQ)にフローを配置するかどうかを RSVP に通知するメカニズムを定義できます。

ip rsvp pq-profile [r [b [p-to-r]]]
 

Cisco IOS RSVP は、RSVP TSpec パラメータ r b 、および p-to-r を使用して、シグナリングの対象になっているフローが PQ 処理を必要とする音声フローかどうかを判定します。これらのパラメータは、次の値を表しています。

r = トラフィックの平均レート(単位:バイト/秒)

b = フローの最大バースト(単位:バイト)

p-to-r = ピーク レートと平均レートの比率(単位:%)

特定のフローに関して RSVP TSpec メッセージで指定されているトラフィック特性が、Cisco IOS コマンドのパラメータ以下である場合、RSVP はフローを PQ に入れます。このコマンドにパラメータを指定しない場合は、一般に利用されている音声コーデック(G.711)の最大値である、次の値がデフォルトとして使用されます。

r = 12,288 バイト/秒

b = 592 バイト

p-to-r = 110%

IntServ/DiffServ モデル

図 11-14 の右側に示すように、IntServ/DiffServ モデルの RSVP では、アドミッション制御を実行するコントロール プレーンだけが関係し、データ プレーンは関係しません。つまり、コール アドミッション制御機能は、スケジューリング機能およびポリシング機能とは独立しています。スケジューリングとポリシングは、事前定義済みのクラス マップ、ポリシー マップ、およびサービス ポリシーに従って、Low Latency Queuing(LLQ; 低遅延キュー)アルゴリズムによって実行できます。

このため、IntServ/DiffServ モデルでは、すでに QoS にディファレンシエーテッド サービス アプローチを使用しているネットワークに対して、RSVP コール アドミッション制御を追加できます。RSVP は、事前に設定された帯域幅量に基づいてコールを許可または拒否しますが、実際のスケジューリングは、各パケットの DSCP 値など、既存の LLQ 基準に基づいています。

図 11-16 に示すように、使用可能な帯域幅全体(リンク速度の 75%)を LLQ クラスに割り当てることができます。これが現在、一般的に行われている割り当てです。ポリシー マップは、各キューに許可されるトラフィックを定義します。RSVP は通常、優先トラフィック用に定義されている帯域幅の量までのフローを許可するように設定されますが、このモデルでは、RSVP がスケジューリングを調整しないため、事前定義済みのプライオリティ キューを超えて RSVP で許可されるトラフィックがドロップされたり、より低い優先度のキューにマッピングし直されたりする可能性があることに注意してください。

優先トラフィックを送信するすべてのアプリケーションが RSVP 対応の場合は、RSVP 帯域幅がプライオリティ キューのサイズと一致するように設定できます。一方、図 11-16 に示すように、優先トラフィックを送信する必要がある RSVP 未使用アプリケーション(Unified CM スタティック ロケーション、ゲートキーパーなど)がある場合は、非 RSVP メカニズムで制御される優先トラフィックと RSVP で制御される優先トラフィックの間で、プライオリティ キューが分割されます。非 RSVP アドミッション制御と RSVP アドミッション制御のメカニズムを組み合わせた場合は、プライオリティ キューでオーバーサブスクリプションが発生しないように、割り当てられた量を超える帯域幅を使用しないでください。

図 11-16 RSVP との LLQ 帯域幅割り当て

 

Cisco IOS ルータで IntServ/DiffServ 運用モデルを使用するには、インターフェイス コンフィギュレーション モードで次のコマンドを使用します。

ip rsvp resource-provider none
ip rsvp data-packet classification none
 

これらのコマンドがアクティブになっている場合、RSVP は、 ip rsvp bandwidth コマンドで定義された帯域幅上限だけに基づいて新しい予約を許可または拒否します。インターフェイス上で使用可能な実際の帯域幅リソースは考慮されません。許可された RSVP フローは、RSVP 以外の他のすべてのトラフィックと同じスケジューリング規則(たとえば、LLQ クラスとポリシー マップ)に従います。このため、RSVP 対応トラフィックを適切な DSCP 値を使用してマーキングし、対応する PQ または CBWFQ キューの帯域幅は、RSVP 対応トラフィックと他のすべてのトラフィックの両方に対応できるように設定することが重要です。

この運用モデルでは、RSVP はスケジューリング機能を制御しないため、 ip rsvp pq-profile コマンドは非アクティブです。

RSVP のアプリケーション ID

アプリケーション ID(app-id)は、RSVP メッセージのポリシー要素に挿入可能な RSVP オブジェクトです。このオブジェクトは、RFC 2872 で説明されています。このポリシー オブジェクトは、アプリケーションを識別し、RSVP 予約要求に関連付けるために役立ちます。これによって、パスのルータは、アプリケーション情報に基づいて適切な決定ができます。

RSVP は、音声とビデオなど複数のアプリケーションのサポートに使用されるため、app-id が必要です。

app-id を使用しないと、RSVP でインターフェイスごとに設定できる帯域幅の値が 1 つだけになります。RSVP は、この帯域幅の上限に達するまで、要求を許可します。要求は区別されず、帯域幅が要求されているアプリケーション タイプも認識されません。その結果、RSVP が 1 つのタイプのアプリケーションだけに対応する要求を許可することで、許可されている帯域幅を使い切ってしまい、これによって、帯域幅が使用できずに後続のすべての要求を拒否してしまう可能性があります。この場合、少数のビデオ コールが原因で、すべてまたはほとんどの音声コールが許可されないことがあります。たとえば、1000 ユニットを RSVP に割り当てた場合に、RSVP が 2 つの 384 kbps ビデオ コールで帯域幅のほとんどを使い切ってしまい、音声コール用の帯域幅がほとんど残らない可能性があります。

この問題は、個別のアプリケーションまたはトラフィック クラスごとに、個別の帯域幅上限を設定すると解決できます。アプリケーションごとに帯域幅を制限するには、アプリケーション帯域幅制限と対応する RSVP ローカル ポリシーをルータ インターフェイスに適用する必要があります。また、適切な帯域幅制限に対して許可できるように、アプリケーションを各予約要求フラグに割り当てる必要があります。

app-id は単一の情報ではなく、複数の可変長文字列になっています。RFC 2872 で説明されているように、オブジェクトには次の属性を含めることができます。

アプリケーションの ID(APP)。この属性は必須です。

グローバル一意識別情報(GUID)。これはオプションです。

アプリケーションのバージョン番号(VER)。この属性は必須です。

サブアプリケーション ID(SAPP)。任意の数のサブアプリケーション要素を含めることができます。これはオプションです。

次に、例を示します。

APP = AudioStream

GUID = CiscoSystems

VER = 5.0.1.0

SAPP =(指定なし)

Unified CM がアプリケーション ID を使用する方法の詳細については、「RSVP アプリケーション ID と Unified CM」を参照してください。

Cisco IOS の機能

この項では、Cisco Unified CM 8.5 以降のリリースを使用した配置の設計に利用される新しい Cisco IOS の機能について説明します。これらの機能は、Cisco IOS Release 15.1(3)T で新しく追加されており、利用するには正しいバージョンの Cisco IOS を使用することが重要です。

RSVP 入力コール アドミッション制御

「RSVP の原理」の項で説明しているように、RSVP プロトコルでソース デバイスが宛先デバイスと通信するために要求するリソースが予約されます。この予約は単方向です。ソース デバイスは、要求されているリソースをアドバタイズするパス メッセージを送信します。パス メッセージを受信した後、宛先デバイスは予約メッセージによって応答します。RESV メッセージは、ソース デバイスと宛先デバイスの間の中間ノードをホップバイホップ(RSVP のみが認識するホップ)で通過し、これらのノードが要求されているフローにリソースを割り当て可能かを判断します。予約は宛先デバイスの方向にダウンストリームしながら発信インターフェイス(ストリームの方向に関する出力)のみのリソースに対しチェックされます。

次のシナリオでは、RESV メッセージは、予約されたリソースに対してソース デバイスと宛先デバイス間の通信が保証されたことを示すものではありません。

2 つの RSVP 認識ルータ間の非対称リンク

図 11-17 では、パス メッセージは RSVP 非認識クラウドに 10 MB リンクを使用して入力され、RSVP 非認識クラウドから 1 MB リンクに出力されます。サイト 1 からサイト 2 へのストリームの流れでは、サイト 1 での RSVP 認識ルータの出力インターフェイスのみが考慮されます。ダウンストリームであるサイト 2 での 1 MB リンクは、予約の際は考慮されません。多くのシナリオでは、これは問題にはなりません。すべてのコールにはストリームが 2 つあり、反対方向のストリーム(サイト 2 からサイト 1 へ)にはサイト 2 RSVP 認識ルータの帯域幅が予約されるためです。

図 11-17 RSVP 認識ルータ間の非対称リンク

 

ロード バランシング対応顧客機器(CE)などの非対称ルーティング パス

図 11-18 では、音声コール(2 ストリームで各方向について 1 つずつ)が RSVP エージェント A と RSVP エージェント B の間で確立されます。A から B への方向のストリームは WAN 1 を経由するフローで、もう 1 つの B から A への方向のストリームは WAN 2 を経由するフローです。これは、非対称ルーティング コールと呼ばれ、サービス プロバイダーからのロード バランシングに対応した二重接続ネットワークで一般的です。RSVP が、RSVP を認識しない WAN ネットワークへの出力インターフェイスのみを考慮している場合、たとえばサービス プロバイダー クラウドの場合のように、WAN のプロビジョニングされた帯域幅が、トラフィックがロード バランスされたときにオーバーランする可能性があります。

図 11-18 ロード バランシング対応二重接続顧客機器(CE)向けの非対称ルーティング

 

前述のシナリオによって示された制限を克服し、RFC 2205 に準拠するには、Cisco IOS Release 15.1(3)T でサポートされている入力コール アドミッション制御機能を使用します。入力コール アドミッション制御で、RSVP 要求の予約を、出力のみではなく、ルータへの入力での帯域幅プールに対して検証できます (図 11-19 を参照)。出力帯域幅の検証は通常どおり機能しています。

図 11-19 RSVP 入力コール アドミッション制御

 

RSVP VPN トンネルのサポート

Dynamic Multipoint Virtual Private Network(DMVPN; Dynamic Multipoint バーチャル プライベート ネットワーク)では、GRE トンネル、IPsec 暗号化、および Next Hop Resolution Protocol(NHRP)を組み合わせることにより IPsec VPN を拡張および縮小できます。RSVP VPN トンネル機能は、次の種類の構成をサポートしています。

手動で構成された総称ルーティング カプセル化(GRE)トンネルおよび multipoint Generic Routing Encapsulation(mGRE; マルチポイント総称ルーティング カプセル化)トンネル上での RSVP

IPsec 保護モードでの、手動で構成された GRE トンネルおよび mGRE トンネル上での RSVP

DMVPN 環境での、GRE トンネルおよび mGRE トンネル(IPsec 保護および IPsec 非保護)上での RSVP

DMVPN および RSVP VPN トンネル機能の詳細については、次の Web サイトで入手可能な『 Cisco IOS Quality of Service Solutions Configuration Guide, Release 15.1 』を参照してください。

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/15_1/qos_15_1_book.html

柔軟な帯域幅のインターフェイスでの RSVP

「RSVP の原理」の項で説明しているように、RSVP 帯域幅がインターフェイスで設定されている場合、そのインターフェイスに対する帯域幅の値は固定されます。これにより、Multi-Link PPP、ATM IMA、FRF12、Gigabit EtherChannel(GEC; ギガビット EtherChannel)などの柔軟なインターフェイス(またはバンドル インターフェイスとしても知られています)に問題が発生します。この問題とは、スタティックな RSVP 帯域幅量をリンクのバンドルを含む柔軟な帯域幅のインターフェイスで設定すると、1 つまたは複数のリンクに障害が発生して合計帯域幅が低下した場合に RSVP 帯域幅は固定のままになるという問題です。つまり、RSVP 帯域幅と柔軟なインターフェイス帯域幅の合計との比率が設定した値と等しくならなくなり、柔軟な帯域幅のインターフェイスのオーバーサブスクリプションの原因になることがあります。

Low Latency Queuing(LLQ; 低遅延キューイング)により、すでにプライオリティ キューおよびクラスベースでは比率の実装が可能です。したがって、柔軟な帯域幅のインターフェイスに適用すると、LLQ パラメータは、パラメータが設定されているインターフェイスと連動して変化します。

柔軟な帯域幅のインターフェイス機能で、 ip rsvp bandwidth コマンドが拡張され、インターフェイス帯域幅の比率の設定ができるようになります。これにより、RSVP 帯域幅をインターフェイス帯域幅と並行的に変更でき、1 つのリンクにバンドルされている複数の物理リンクから構成されるインターフェイスに適用できます。

ネットワークまたはサービス プロバイダーに、バンドルされた WAN インターフェイスを利用したサイトを持つ企業の顧客の場合、この機能により完全な動作時間中は RSVP コール アドミッション制御で帯域幅の使用率を完全に最大化でき、一方で、リンク障害中は同じ比率のバンドルの帯域幅を直接使用できます。

図 11-20 および 図 11-21 に、柔軟な帯域幅のインターフェイスで RSVP を使用する場合の例を示します。

図 11-20 合計帯域幅が 10 MB の柔軟な帯域幅のインターフェイス

 

図 11-21 合計帯域幅が 5 MB まで低下した柔軟な帯域幅のインターフェイス

 

柔軟な帯域幅のインターフェイスでの RSVP の使用の詳細については、次の Web サイトで入手可能な『 Cisco IOS Quality of Service Solutions Configuration Guide, Release 15.1 』を参照してください。

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/15_1/qos_15_1_book.html

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

Unified CM と組み合わせて RSVP を IP WAN に配置する場合は、次の設計上のベスト プラクティスに従います。

次のいずれかの条件に該当する場合は、IntServ/DiffServ モデルを採用することを推奨します。

IP WAN インターフェイスのプライオリティ キュー(PQ)に入るトラフィックは、RSVP 対応トラフィックだけである。

PQ に入る RSVP 未使用トラフィックは、アウトオブバンドのコール アドミッション制御メカニズム(Unified CM ロケーションや Cisco IOS ゲートキーパーなど)によって、すべて確定的に一定量に制限される。

プライオリティ キュー帯域幅のレイヤ 2 のオーバーヘッドを考慮すると、すべての PQ トラフィックが RSVP 対応の場合、 ip rsvp bandwidth コマンドで指定した値と priority コマンドで指定した値は一致する必要があります。

ルータの 1 つ以上のインターフェイスで RSVP を有効にする場合は、RSVP メッセージがドロップされないように、RSVP シグナリングが通過すると考えられるすべてのインターフェイスでも RSVP を有効にする必要があります。インターフェイスでコール アドミッション制御を使用しない場合は、帯域幅の値をインターフェイス帯域幅の 75% に設定します。

一部の PQ トラフィックが RSVP 非対応の場合は、 ip rsvp bandwidth コマンドとアウトオブバンド コール アドミッション制御メカニズムで指定した値の合計が、 priority コマンドで指定した帯域幅値を超えないようにする必要があります。

音声コールおよびビデオ コールで使用する最大帯域幅を制限する必要がある場合は、RSVP アプリケーション ID のサポートを有効にします。アプリケーション ID のサポートは、Cisco IOS Release 12.4(6)T で導入されました。

WAN リンクの両側のルータの WAN インターフェイスなど、ネットワークの両端で RSVP を有効にします。

速度が異なる冗長リンクなど、可能性があるすべての WAN 輻輳ポイントで RSVP を有効にします。

ロードバランスされた MPLS WAN リンクで対称ルーティングがない場合、入力コール アドミッション制御が設定されているか確認してください(「RSVP 入力コール アドミッション制御」を参照)。

ほとんどの Catalyst スイッチング プラットフォームでは、現在、RSVP を使用できません。

RSVP の帯域幅のプロビジョニング

ここでは、RSVP だけに関係する帯域幅のプロビジョニングについて説明します。帯域幅のプロビジョニング全般の詳しい説明については、「帯域幅のプロビジョニング」を参照してください。

Unified CM で使用する RSVP 帯域幅の値の計算

Unified CM が Cisco RSVP Agent にコール フローの初期予約を行うよう指示する時点では、コールに関係するエンドポイントは、コーデック能力を完全には交換していません。この情報がないため、Unified CM がトラフィック フローの記述方法を決定するには、リージョン設定に依存する必要があります。トラフィック フローのサイズは、コーデック ビット レートとサンプリング レート(パケット/秒)の関数です。リージョン設定に最大コーデック ビット レートは含まれていますが、サンプリング レートは記述されていません。音声コーデックの優先サンプリング レートは、クラスタ全体の次のサービスパラメータで定義されています。

Preferred G722 millisecond packet size:デフォルトは 20 ms

Preferred G711 millisecond packet size:デフォルトは 20 ms

Preferred G729 millisecond packet size:デフォルトは 20 ms

ただし、コーデックのサンプリング レートはコールごとにネゴシエートされ、1 つ以上のエンドポイントでサポートされないために、優先設定が使用されないことがあります。呼び出し後の失敗の原因となる、能力が完全に交換された後で予約サイズが増加することを防ぐには、この初期予約をコーデックの最悪のケース(最小パケット サイズを使用した最大コーデック ビット レート)に対応したものにします。エンドポイント間でメディア能力が交換されると、予約は正しい帯域幅割り当てに修正されます。ほとんどの場合、デフォルトのサンプリング レートが使用され、結果として予約が削減されます。


) Unified CM は、RSVP 予約に SRTP オーバーヘッドまたはレイヤ 2 オーバーヘッドを含めません。RSVP T Spec 帯域幅の値と比較する場合、レイヤ 3 IP RSVP 帯域幅のステートメントは、任意の SRTP トラフィックを考慮する必要があり、SRTP トラフィックが存在する場合は、レイヤ 2 プライオリティ キューの値も余分にプロビジョニングする必要があります (表 3-10 および表 3-11 を参照)。


音声ベアラ トラフィック

音声コーデックが G729 に設定されているリージョン間コール。G.729 を使用して接続。

初期要求:40 kbps。最悪ケースのシナリオの 10 ms を使用。

更新後の要求:24 kbps。優先サンプル サイズの 20 ms を使用。

音声コーデックが G.728/iLBC の最大値に設定されているリージョン間コール。iLBC を使用して接続。

初期要求:48 kbps。最悪ケースのシナリオの 10 ms の G.728 を使用。

更新後の要求:31.2 kbps。優先サンプル サイズの 20 ms を持つ iLBC 使用。

音声コーデックが G711 に設定されているリージョン間コール。G.711 を使用して接続。

初期要求:96 kbps。最悪ケースのシナリオの 10 ms を使用。

更新後の要求:80 kbps。優先サンプル サイズの 20 ms を使用。

ビデオ ベアラ トラフィック

オーディオ ストリームと同様に、ビデオ ストリームの初期予約も、予約の時点でエンドポイントのコーデック能力が完全にはネゴシエートされていないため、リージョン設定に依存します。ビデオ コールのリージョン設定には、オーディオ ストリームの帯域幅が含まれます (詳細については、「IP ビデオ テレフォニー」を参照してください)。オーディオ ストリームには独自の予約があるため、最終的なビデオ ストリームの予約は、リージョン設定から音声コーデックのビット レートを減算した値になります。ただし、これらのコーデックは完全にはネゴシエートされていないため、ビデオ ストリーム予約は、オーディオ ストリームがないという前提で、最悪のケースのシナリオで行われます。エンドポイント間でメディア能力が交換されると、予約は正しい帯域幅割り当てに修正されます。

ビデオは本質的にバースト性が高いため、ストリーム要件にオーバーヘッドを追加する必要があります (詳細については、「音声ベアラ トラフィック」を参照してください)。Unified CM は、次のように、ストリーム帯域幅を使用してオーバーヘッドの計算方法を決定します。

ストリームが 256 kbps 未満の場合は、オーバーヘッドが 20% になる。

ストリームが 256 kbps 以上の場合は、オーバーヘッドが 7% になる。

音声コーデックが G.729 で、ビデオ設定が 384 kbps のリージョン間ビデオ コールの場合

初期要求:384 ∗ 1.07 = 410 kbps

更新後の要求:(384 - 8) ∗ 1.07 = 402 kbps

音声コーデックが G.711 で、ビデオ設定が 384 kbps のリージョン間ビデオ コールの場合

初期要求:384 ∗ 1.07 = 410 kbps

更新後の要求:(384 - 64) ∗ 1.07 = 342 kbps

設定の推奨事項

初期予約は実際のパケット フローよりも大きくなるため、必要なコール数に対応するには、RSVP 帯域幅および LLQ 帯域幅を多めにプロビジョニングする必要があります。

N コールの RSVP 帯域幅をプロビジョニングする場合、N 番めのコールが許可されるように、N 番めの値を最悪のケースの帯域幅にすることを推奨します。

次に、例を示します。

4 つの G.729 ストリームをプロビジョニングする場合

(3 ∗ 24) + 40 = 112 kbps

4 つの G.711 ストリームをプロビジョニングする場合

(3 ∗ 80) + 96 = 336 kbps

4 つの 384 kbps ビデオ ストリーム(G.729 オーディオ)をプロビジョニングする場合

(3 ∗ (384 - 8) + 384) ∗ 1.07 = 1618 kbps

4 つの 384 kbps ビデオ ストリーム(G.711 オーディオ)をプロビジョニングする場合

(3 ∗ (384 - 64) + 384) ∗ 1.07 = 1438 kbps

Cisco IOS アプリケーション ID サポートの設定

RSVP アプリケーション ID 機能のサポートは、Cisco IOS Release 12.4(6)T で導入されました。次の例では、このリリース以降が必要です。

プライオリティ キューの組み合わせ

Unified CM によるアプリケーション ID サポートの実装で許可される機能(プライオリティ キューで使用可能なすべての帯域幅を音声コールで消費可能にする機能)を利用するために、音声とビデオのプライオリティ キューを分離するという以前の推奨事項を変更する必要があります。(「RSVP アプリケーション ID と Unified CM」を参照してください)。この機能を使用するには、音声とビデオの両方の一致基準を 1 つのクラスマップに組み合わせる必要があります。音声トラフィックまたはビデオ トラフィックのいずれかが一致することが要件になるため、次のように、クラスマップの一致基準 match-all の代わりに match-any を使用する必要があります。

class-map match-any IPC-RTP
match ip dscp ef
match ip dscp af41 af42
 

音声トラフィックとビデオ トラフィックの両方をサポートするように、プライオリティ キューを設定します。次の設定例では、リンク帯域幅の 33% がプライオリティ キューに割り当てられます。

policy-map Voice-Policy
class IPC-RTP
priority percent 33
 

アプリケーション ID から RSVP ポリシー ID へのマッピング

RSVP ローカル ポリシーによって、アプリケーション ID を基に予約を制御するメカニズムが提供されます。アプリケーション ID は、 ip rsvp policy identity コマンドで、RSVP ローカル ポリシーにマッピングされます。RSVP ローカル ポリシー ID はグローバルに定義され、コマンドにより、各インターフェイスで使用できます。各 ID には、アプリケーション ID と照合するために定義された 1 つのポリシー ロケータがあります。

ユーザができるだけ柔軟にアプリケーション ポリシー ロケータとローカル ポリシーを照合できるように、RSVP ローカル ポリシー コマンドライン インターフェイス(CLI)は、Unix 形式の正規表現によるポリシー ロケータに対するアプリケーション ID 一致基準を受け付けます。ボーダー ゲートウェイ プロトコル(BGP)など、既存の Cisco IOS コンポーネントの CLI では、正規表現が常に使用されます。Cisco IOS で正規表現を使用する方法の詳細については、次のマニュアルを参照してください。

Access and Communication Servers Command Reference

http://www.cisco.com/en/US/docs/ios/11_0/access/command/reference/arbook.html

Using Regular Expressions in BGP

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094a92.shtml

Regex Engine Performance Enhancement

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gt_rexpe.html

デフォルトの Unified CM アプリケーション ID を照合するための RSVP ポリシー ID

ip rsvp policy identity rsvp-video policy-locator .*VideoStream.*
ip rsvp policy identity rsvp-voice policy-locator .*AudioStream.*
 

インターフェイスの RSVP ローカル ポリシー

アプリケーション ID サポートを設定するかどうかにかかわらず、RSVP をサポートするインターフェイスでは、 ip rsvp bandwidth <値> コマンドを設定する必要があります。この値は、アプリケーション ID サポートの有無にかかわらず、そのインターフェイス上での 1 つの RSVP 予約または RSVP 予約の合計を超えることはできません。予約がローカル ポリシー チェックをパスした場合、予約の前に、インターフェイスの RSVP 帯域幅チェックにパスする必要があります。

アプリケーション ID に基づくローカル ポリシーは、 ip rsvp policy local identity コマンドでインターフェイスに適用されます。

ポリシー ロケータ値と一致する予約については、ローカル ポリシーによって次の機能を実行できます。

その予約がグループまたは単一の送信者として予約できる最大帯域幅の定義

RSVP メッセージを転送するかどうか

RSVP メッセージを受け入れるかどうか

グループまたは送信者が予約できる最大帯域幅の定義

たとえば、Serial T1 でビデオ帯域幅の量を 384 kbps に制限するには、次のコマンドを使用します。

interface Serial0/0/1:0
ip rsvp bandwidth 506
ip rsvp policy local identity rsvp-video
maximum bandwidth group 384
forward all
 

catch-all ローカル ポリシーというデフォルト ローカル ポリシーもあります。このローカル ポリシーは、リンクで設定されているその他の RSVP ローカル ポリシーと一致しなかったすべての RSVP 予約と一致します。デフォルト ローカル ポリシーは、アプリケーション ID のタグ予約、またはタグなしトラフィックとして処理するアプリケーション ID のタグ予約と照合するために使用できます。

次の例は、「Cisco Unified CM でのアプリケーション ID の使用方法」で説明したモデルを使用する音声コールとビデオ コールの両方をサポートします。音声コールには 352 kbps の帯域幅が保証され、ビデオ コールは 154 kbps の帯域幅に制限されます。音声コールは、使用可能な RSVP 帯域幅のすべてを使用できます。

interface Serial0/0/1:0
ip address 10.2.101.5 255.255.255.252
service-policy output Voice-Policy
ip rsvp bandwidth 506
ip rsvp data-packet classification none
ip rsvp resource-provider none
ip rsvp policy local identity rsvp-voice
maximum bandwidth group 506
forward all
ip rsvp policy local identity rsvp-video
maximum bandwidth group 154
forward all
ip rsvp policy local default
no accept all ! Will not show in the configuration
no forward all ! Will not show in the configuration
 

この例では、アプリケーション ID を持たない RSVP 予約を受信したとき、またはアプリケーション ID が 2 つの設定済みオプションと一致しない RSVP 予約を受信したときに、予約が失敗します。この設定は、RSVP トラフィックが Unified CM で制御される Cisco RSVP Agent からだけ発信される場合に機能します。ただし、IP-IP ゲートウェイを経由するクラスタ間 RSVP トラフィックがある場合、または Unified CM 以外のコントローラからの RSVP メッセージがこのリンクを通過する場合は、予約を受け付けて転送するデフォルト ローカル ポリシーを設定し、このポリシーで最大帯域幅の値を設定する必要があります。複数の RSVP ローカル ポリシーを使用すると(ポリシーの合計が RSVP インターフェイス帯域幅より大きい場合)、RSVP 帯域幅をオーバーサブスクリプションにすることは可能ですが、予約は先着順になります。

RSVP および集中型呼処理を使用した呼制御トラフィック用のプロビジョニング

ここでは、集中型呼処理配置で RSVP をコール アドミッション制御メカニズムとして使用する場合に、呼制御トラフィック用に帯域幅をプロビジョニングする方法について説明します。RSVP を使用しない場合の帯域幅プロビジョニング全般については、「集中型呼処理を使用した呼制御トラフィック用のプロビジョニング」を参照してください。

RSVP を使用するコールに関する考慮事項

コール アドミッション制御で RSVP を使用するシステムでは、WAN を経由する IP コールが発生したときに、Unified CM と支店の Cisco RSVP Agent の間に追加の SCCP 呼制御トラフィックが発生します。関連する帯域幅を計算するには、次の公式を使用します。

帯域幅(bps)=(21 ∗ CHW)∗ (支店内の IP Phone とゲートウェイの数)

CHW は、異なる支店の IP Phone 間のコールや、異なるサイトにあるゲートウェイを通過するコールなど、IP WAN を経由する電話機あたりの毎時のコール数を表します。たとえば、20 台の電話機があり、電話機あたり毎時 10 コールが発生するサイトで、コールの 20% が IP WAN を経由する場合、CHW = 2 です。そこで、公式は(21∗2)∗20 = 840 bps になります。

この公式で求めた帯域幅を電話呼制御に必要な帯域幅に追加します。

Unified CM の RSVP 対応ロケーション

Cisco Unified CM は、リソース予約プロトコル(RSVP)に基づくトポロジ対応コール アドミッション制御メカニズムを備えています。RSVP は、すべてのネットワーク トポロジに適用可能で、従来のハブアンドスポーク トポロジの制限を緩和します。Cisco RSVP Agent は Cisco IOS の機能であり、Unified CM が RSVP ベースのコール アドミッション制御を実行できるようにするものです。Cisco RSVP エージェントをサポートする Cisco IOS プラットフォームについては、次の Web サイトで入手可能な『 Cisco RSVP Agent Data Sheet 』を参照してください。

http://www.cisco.com/en/US/partner/products/ps6832/products_data_sheets_list.html

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

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

Skinny Client Control Protocol(SCCP)による Unified CM への Cisco RSVP Agent の登録

SCCP または Session Initiation Protocol(SIP)による Unified CM への IP Phone の登録

メディア ゲートウェイ コントロール プロトコル(MGCP)、SIP、または H.323 プロトコルによる Unified CM へのPSTN ゲートウェイの登録

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

 

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

このコールのメディア ストリームに対しては、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 トポロジがサポートされますが、これらはロケーションに対するデバイスの静的な割り当てに基づいています。つまり、ある物理的なサイトから別のサイトにデバイスを移動するたびに、Unified CM の設定を更新する必要があります。デバイス モビリティを使用すると、デバイスを新しい物理的なサイトに移動したときに、サイト固有のデバイス設定情報を自動的に更新できます。詳細については、「デバイス モビリティ」の項を参照してください。


図 11-23 Cisco RSVP Agent の概念

 

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

同時コール(セッションとも呼ばれる)に対する Cisco RSVP Agent の容量は、次の要因によって変化します。

ソフトウェアベースの MTP 機能では、ルータ プラットフォームおよび相対的な CPU 負荷によってセッション容量が決まる ( http://www.cisco.com/en/US/products/ps6832/products_data_sheets_list.html で入手可能な『 Cisco RSVP Agent Data Sheet 』を参照)。

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

サポート対象プラットフォーム、要件、および容量の詳細については、次の Web サイトで入手可能な『 Cisco RSVP Agent Data Sheet 』を参照してください。

http://www.cisco.com/en/US/products/ps6832/products_data_sheets_list.html

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

Cisco RSVP Agent の登録

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

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

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

sccp ccm group
switchover method immediate
switchback method guard timeout 7200
!
gateway
timer receive-rtp 180
 

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

switchback method guard timeout 7200 コマンドは、プライマリ Unified CM が障害から回復した後の登録のスイッチバック メカニズムを指定します。このコマンドを設定すると、Cisco RSVP Agent は最後のアクティブなコールの切断後に、プライマリ Unified CM への登録の正常なスイッチバックを開始します。保護タイマーの期限内に登録の正常なスイッチバックが開始されない場合、Cisco RSVP Agent は即時のスイッチバック メカニズムを使用してすぐに Unified CM に登録します。保護タイマーのデフォルト値は 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 は、この設定に基づいてセッション容量を Unified CM に通知します。セッションの最大数は、コールが Cisco RSVP Agent を通過するごとに 1 つずつ減少します。カウンタが 0 になると、Cisco RSVP Agent には使用可能なリソースがないと見なされ、Unified CM はそれ以降のコールでその Cisco RSVP Agent をスキップします。

図 11-24 は、2 つの Cisco RSVP Agent がある支店サイトを示しています。Cisco RSVP Agent は WAN ルータと共存し、Cisco RSVP Agent の冗長性は、同じ MRGL の別の MRG に 2 つの Cisco RSVP Agent を割り当てることによって実現されます。MRG-1 の Agent-1 が使用できないか、セッション容量を超えている場合、Unified CM は支店 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 設定でサポートされるコール数よりも大きい場合でも、Unified CM はそのコールを Cisco RSVP Agent に送りますが、使用可能な帯域幅がないため RSVP 予約は失敗します。Unified CM は、コール アドミッション制御失敗の通常の処理に従います(コールを拒否するか、AAR 機能を呼び出します)。


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

 

パススルー コーデック

パススルー コーデックを使用すると、Cisco IOS Enhanced MTP デバイスは、ストリームのメディア エンコーディングを認識していなくても、エンドポイントから受信した RTP メディア ストリームを終端できます。つまり、メディア ストリームの UDP パケットは、デコードされずに MTP を通過します。この方法により、MTP は、Unified CM で定義されるすべての音声、ビデオ、およびデータのコーデックをサポートできます。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 プロファイルで設定されるコーデックは、Unified CM Administration で設定されるリージョン間コーデックと一致している必要があります。たとえば、G.729 コーデックが Unified CM Administration で設定されるリージョン間コーデックの場合は、dspfarm MTP プロファイルでも G.729 コーデックを設定する必要があります。


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

interface Loopback0
ip address 10.11.1.100 255.255.255.255
!
sccp local Loopback0
sccp ccm 20.11.1.50 identifier 1 priority 1 version 8.0
sccp ccm 20.11.1.51 identifier 2 priority 2 version 8.0
sccp
!
sccp ccm group 1
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 1 register RSVPAgent
switchover method immediate
switchback method guard timeout 7200
!
dspfarm profile 1 mtp
codec pass-through
codec g729ar8
rsvp
maximum sessions software 100
associate application SCCP
 

RSVP ポリシー

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

No Reservation

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

Mandatory

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

Mandatory (Video Desired)

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

Optional (Video Desired)

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

システム デフォルトの使用(Use System Default)

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


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


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

図 11-25 クラスタ全体の RSVP パラメータの設定

 

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

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

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

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

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

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

 

表 11-5 図 11-26 の例でのロケーションと帯域幅の設定

ロケーション名
帯域幅

Hub_None

Unlimited

支店 1

256 kbps

支店 2

256 kbps

支店 3

256 kbps

表 11-6 図 11-26 の例での RSVP ポリシー

ロケーション ペア
ポリシー

任意

任意

No Reservation

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 番めのコール レッグに対して、Unified CM は、支店 2 ロケーションの帯域幅の可用性をチェックすることにより、静的ロケーションに基づくコール アドミッション制御を実行します。

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

表 11-7 支店 1 への移行後のロケーションと帯域幅の設定

ロケーション名
帯域幅

Hub_None

Unlimited

支店 1

Unlimited

支店 2

256 kbps

支店 3

256 kbps

表 11-8 支店 1 への移行後の RSVP ポリシー

ロケーション ペア
ポリシー

支店 1

任意

Mandatory

その他すべてのロケーション

その他すべてのロケーション

No Reservation

表 11-9 表 11-10 は、クラスタ全体の移行後のロケーションの帯域幅と 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] に設定します。

表 11-9 移行の完了後のロケーションと帯域幅の設定

ロケーション名
帯域幅

Hub_None

Unlimited

支店 1

Unlimited

支店 2

Unlimited

支店 3

Unlimited

表 11-10 移行完了後の RSVP ポリシー

ロケーション ペア
ポリシー

任意

任意

Mandatory

RSVP アプリケーション ID と Unified CM

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

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

Cisco Unified CM でのアプリケーション ID の使用方法

Unified CM には次に挙げる 2 つのクラスタ全体のサービス パラメータがあり、RSVP を使用して音声コール予約およびビデオ コール予約にタグ付けするためのアプリケーション ID を定義できます。

RSVP Audio Application ID(デフォルトは AudioStream)

RSVP Video Application ID(デフォルトは VideoStream)

図 11-27 に、Unified CM がどのように RSVP で音声コールおよびビデオ コールにアプリケーション ID をタグ付けするかを示します。

図 11-27 Unified CM と RSVP アプリケーション ID

 

音声コールにタグ付けする方法

RSVP ポリシーを使用してロケーション間の音声コールを作成すると、オーディオ ストリームの予約に RSVP Audio Application ID のタグが付きます。

ビデオ コールにタグ付けする方法

RSVP ポリシーを使用してロケーション間でビデオ コールを発信すると、オーディオ ストリームとビデオ ストリームの両方の予約に RSVP Video Application ID のタグが付きます。ビデオ コールでは、音声とビデオの両方が Video Application ID に関連付けられます。


) この機能は Cisco Unified CM 8.0 で新たに導入されたもので、静的ロケーション モデルに似たモデルを使用して、音声トラフィックとビデオ トラフィックの帯域幅を分けるようになっています。静的ロケーションでは、ビデオ コールの音声ストリームとビデオ ストリームはどちらもビデオ帯域幅カウンタから差し引かれます。Unified CM 8.0 で RSVP アプリケーション ID を使用すると、同じロジックが適用され、ビデオ コールのオーディオ ストリームとビデオ ストリームがビデオ帯域幅アプリケーション ID から差し引かれます。


RSVP アプリケーション ID の設計上の考慮事項とベスト プラクティス

AudioStream Application ID は、音声専用コールのオーディオ ストリームに使用されます。

VideoStream Application ID は、ビデオ コールのオーディオ ストリームとビデオ ストリームの両方に使用されます。

アプリケーション ID は、現時点ではテレプレゼンス ビデオなどのさまざまなビデオ タイプを区別しません。RSVP セッションのすべてのビデオが、Video Application ID とビデオ DSCP 値でマーキングされます。

Unified CM には現在、シグナリング ストリームおよびメディア ストリームのアプリケーション ID と DSCP 値の両方の設定が別々に用意されています。これらの値は別々に管理されますが、互いに連動して動作するように設定されているため、デフォルト値を使用することを推奨します。

ビデオ エスカレーションが発生すると、オーディオ ストリームの RSVP 予約が Video Application ID および設定済みの DSCP 値(デフォルトでは PHB AF41)で再許可されます。十分な帯域幅がないためにオーディオ ストリームの再許可が失敗した場合、Video Application ID プールへの予約が成功するまで、オーディオ ストリームは Video Application ID 付きでベストエフォート型として続行します。

ビデオ デエスカレーションが発生すると、オーディオ ストリームの RSVP 予約が Audio Application ID および設定済みの DSCP 値(デフォルトでは PHB EF)で再許可されます。十分な帯域幅がないためにオーディオ ストリームの再許可が失敗した場合、Audio Application ID プールへの予約が成功するまで、オーディオ ストリームは Audio Application ID 付きでベストエフォート型として続行します。

アプリケーション ID 付きのビデオ エスカレーションの例

音声専用コールは AudioStream Application ID 付きでセットアップされ、ストリームの DSCP は PHB 値 EF に設定されます。コールをビデオへとエスカレーションすると、ビデオ ストリームが VideoStream Application ID 付きでセットアップされます。ビデオ ストリーム予約が失敗した場合、コールは AudioStream Application ID 付きの音声専用コールのままとなります。一方、ビデオ ストリーム予約が成功した場合は、オーディオ ストリームが AudioStream Application ID から VideoStream Application ID へと再許可されます。再許可が成功すると、ビデオ ストリームとオーディオ ストリームのどちらでも、VideoStream Application ID が PHB 値 AF41 に設定されます。再許可が失敗すると、ビデオ ストリームでは VideoStream Application ID が PHB 値 AF41 に設定され、オーディオ ストリームでは VideoStream Application ID が PHB 値 0 に設定されます(ビデオ失敗時の DSCP 値)。

RSVP SIP プレコンディションを使用した分散 Unified CM 環境でのビデオのエスカレーションとデエスカレーションについては、「RSVP SIP プレコンディションを使用した Unified CM ビデオ コール」を参照してください。

RSVP SIP プレコンディション

RSVP SIP プレコンディションは、RFC 3312 および RFC 4032 に規定されている SIP プレコンディションに基づいています。RSVP SIP プレコンディションにより、シスコ呼処理製品は Quality of Service レベルをネゴシエートし、RSVP プロトコルを使用してコール アドミッション制御を実行できます。RSVP SIP プレコンディションという用語は、ポリシー情報要素、つまりプレコンディションを SIP シグナリングで受け渡して Quality of Service(QoS)ポリシーをネゴシエートすることを識別するために使用します。実際の RSVP メッセージは、SIP トランクで通知されません。ポリシー関連の情報要素だけが通知されます。RSVP メッセージは、RSVP Agent または RSVP 対応ルータによって伝送されます。このように SIP プレコンディションを使用すると、Unified CM クラスタで実施される RSVP Quality of Service ポリシーのネゴシエーションが Unified CM Express および SIP-TDM Cisco IOS ゲートウェイへと拡大されて、このようなさまざまな呼制御アプリケーション間で RSVP レイヤおよび呼制御レイヤを同期できるようになります。

SIP プレコンディションの概要

上記のように、SIP プレコンディションを使用すると、呼制御アプリケーション間で RSVP ポリシー情報をネゴシエートできます。これにより、呼制御アプリケーション間でリソース予約のために RSVP レイヤを同期し、コールのセットアップと確立のために呼制御レイヤを同期できます。

また、SIP シグナリングでのプレコンディションという概念により、独立した呼制御アプリケーション間に「ゴースト呼び出し音」と呼ばれるものが発生しないようにすることもできます。発信者間にメディアを確立するために必要なリソースを予約せずに着信側を呼び出すと、セッション確立時にゴースト呼び出し音が発生することがあります。ゴースト呼び出し音を最小限に抑えるためには、着信側を呼び出す前に、セッションのネットワーク リソースを予約する必要があります。ただし、ネットワーク リソースを予約するには、着信側から頻繁に IP アドレス、ポート、およびセッション パラメータを学習する必要があります。この情報は、SIP でオファーとアンサーを初めて交換したときに取得されます。この交換の際には通常、電話機の呼び出し音が鳴って、ループ ジレンマが発生します。つまり、初期のオファー/アンサー交換を実行しないとリソースを予約できず、リソース予約を実行しないと初期のオファー/アンサー交換を行えません。

RSVP SIP プレコンディションは、オファーで導入するセッションに関して SIP プレコンディションまたは制約を設定して、このジレンマを解決します。オファーの受信者はアンサーを生成しますが、ユーザに警告せず、セッション確立も続行しません。プレコンディションが満たされているときにだけ次の処理に進みます。この情報は、リソース予約の確認などのローカル イベントか、または発信側が送信した新たなオファーを通して取得できます。

図 11-28 に、このような SIP プレコンディションが汎用 SIP シグナリング コール フローでどのように機能するかを示します。

図 11-28 コール エージェント間での SIP と RSVP

 

図 11-28 では、SIP ユーザ エージェント(SIP UA 1)が、SIP INVITE メッセージを送信して、コールを開始しています。セッション記述プロトコル(SDP)の SIP INVITE にはプレコンディションが含まれており、これにより発信側の IP アドレスおよびポート番号が識別されます。プレコンディションは現在の QoS ポリシー(a=curr:qos)および目的の QoS ポリシー(a=des:qos)を要求します。この例では、SIP UA 1 は SIP UA 2 に INVITE を送信して、音声回線用の現在の QoS ポリシーを none に設定し、目的の QoS ポリシーを mandatory e2e sendrecv に設定します。これにより、コールをオファーする(エンド デバイスの呼び出し音を鳴らす)前に、RSVP 予約が必須であることが受信側に伝えられます。SIP UA 2 は INVITE を受信すると、183 SESSION PROGRESS メッセージで応答します。その結果、SDP により、送信されたプレコンディションへの応答が求められます。この例では、SIP UA 2 は、現在の QoS ポリシーを none 、目的の QoS ポリシーを mandatory e2e sendrecv 、さらに設定済みの QoS ポリシー(a=conf:qos)を e2e recv としてそれぞれ送信して、要求を受信したことと、RSVP を使用して予約を開始することを示します。この時点で、両ユーザ エージェントとも、RSVP をネゴシエートして、SDP の記述どおりにメディアの帯域幅を予約します。この予約が成功すると、UA は最新の QoS ポリシー前提条件で互いを更新し、エンド ユーザの呼び出し音を鳴らしてコールを続行します。例では、SIP UA 2 は 180 RINGING メッセージで応答し、コールは通常の確立を続行できます。予約が失敗した場合、どちらの SIP UA も着信側の呼び出し音を鳴らさずにコールを終了できます。これにより、「ゴースト呼び出し音」が鳴る条件を回避できます。

Unified Communications Manager および RSVP SIP プレコンディション

Unified CM の RSVP SIP プレコンディションにより、分散型 Unified CM 配置でクラスタ間コール アドミッション制御を機能させることができます。Unified CM に RSVP SIP プレコンディションを配置する場合は、RSVP SIP プレコンディションを有効にする前に、ローカル RSVP 対応ロケーションベースのコール アドミッション制御を完全に機能させることを推奨します。また、このアプローチは移行目的にも推奨します。クラスタ内 RSVP コール アドミッション制御を有効にする方法の詳細については、「Unified CM の RSVP 対応ロケーション」を参照してください。

RSVP SIP プレコンディションには、ローカル RSVP とエンドツーエンド RSVP の 2 つの設定モードがあります。これらのモードは、[Unified CM Administration] ページの SIP トランク プロファイルに設定します。

ローカル RSVP

ローカル RSVP は、別々のクラスタにある 2 つの RSVP Agent 間での予約をサポートしません。クラスタごとに 2 つの RSVP Agent を使用します。クラスタを接続するトランクを越えて RSVP を使用することはありません。これは、SIP トランク プロファイルのデフォルト設定です。

図 11-29 に、分散型 Unified CM 配置でのローカル RSVP を示します。

図 11-29 分散型 Unified CM 配置でのローカル RSVP

 

図 11-29 では、X はクラスタ 1 のエンドポイントを示し、Y はクラスタ 2 のエンドポイントを示し、ICT1 と ICT2 はそれぞれクラスタ 1 とクラスタ 2 に設定されたクラスタ間トランクを示します。それぞれのデバイスに関連付けられた RSVP Agent も示しています。このシナリオでは、Cisco Unified CM クラスタ 1 が AgentBr1 と AgentHQ1 間の予約を制御し、Cisco Unified CM クラスタ 2 が AgentBr2 と AgentHQ2 間の予約を制御します。

エンドツーエンド RSVP

クラスタ間を SIP トランクで接続すると、エンドツーエンド RSVP 設定が使用可能になります。エンドツーエンド RSVP は、RSVP Agent 間の接続全体で RSVP を使用し、クラスタごとに RSVP Agent を 1 つだけ使用します。

図 11-30 に、Unified CM でのエンドツーエンド RSVP を示します。

図 11-30 エンドツーエンド RSVP

 

図 11-30 では、X はクラスタ 1 のエンドポイントを示し、Y はクラスタ 2 のエンドポイントを示し、ICT1 と ICT2 はそれぞれクラスタ 1 とクラスタ 2 に設定されたクラスタ間トランクを示します。それぞれのデバイスに関連付けられた RSVP Agent も示しています。このシナリオでは、Cisco Unified CM が AgentBr1 と AgentBr2 間に直接エンドツーエンド RSVP 接続を確立します。

RSVP SIP プレコンディションおよびローカル RSVP へのフォールバック

SIP トランク プロファイルで [Fall back to local RSVP] を設定して、エンドツーエンド RSVP からローカル RSVP にフォールバックするように Unified CM を設定できます。このフォールバックが発生するのは、SIP トランクの着信側が SIP 420 応答(Bad Extension)を返して、着信側がプレコンディションを認識していないことを示したときだけです。SIP 580 応答(Precondition Failed)などの応答が返されたときには、フォールバックは発生しません。コールの確立中に SIP 420(Bad Extension)応答でエンドツーエンド RSVP SIP プレコンディションが失敗した場合には、Unified CM はローカル RSVP を呼び出します。この動作が目的にかなう場合は、RSVP Agent 関連付けを記載したメディア リソース グループ リストを SIP クラスタ間トランクに割り当てる必要があります。ローカル RSVP へのフォールバックを設定しない場合、トランクまたはゲートウェイをもう 1 つ設定していると、Unified CM はルート グループおよびルート リストを使用してそのトランクまたはゲートウェイへとたどります。トランクまたはゲートウェイを設定していないと、コールは失敗します。

この機能は、1 つの SIP トランクが複数の宛先で終端する設計、両方の SIP プレコンディションがサポートされる設計、および両方の SIP プレコンディションがサポートされない設計に使用できます。たとえば、Unified Proxy Server を使用する例を考えてみます。SIP プロキシに対して SIP トランクが 1 つ設定されており、宛先として返されるのは SIP プレコンディションを認識する着信側クラスタか、または SIP プレコンディションを認識しない着信側クラスタまたは SIP サーバとなっています。この場合、SIP トランクが 1 つだけであるため、そのトランクが RSVP SIP プレコンディションで有効になってフォールバックが有効になります。着信側が SIP プレコンディションを認識しない場合には、フォールバック モードの SIP トランクに RSVP Agent を関連付けることができます。そのため、SIP 420 メッセージ(Bad Extension)が受信され、フォールバックが発生すると、SIP プレコンディションなしで新たな SIP INVITE が送出されます。SIP プレコンディションをサポートしている場合は、「SIP プレコンディションの概要」で説明するとおりに、コールの処理が進められます。

ローカル RSVP フォールバックを有効にすることは推奨 しません 。その代わり、宛先に到達するルートを別に設定してください。ローカル ルート グループや同じような機能を使用して、RSVP コール アドミッション制御に失敗したコールを発信側デバイスにローカルなゲートウェイに再ルーティングし、コールがPSTN を経由できるようにすることを推奨します。

ロケーションベースのコール アドミッション制御から RSVP SIP プレコンディションへの移行

ロケーションベースのコール アドミッション制御から RSVP SIP プレコンディションに移行するときは、「静的ロケーションから RSVP コール アドミッション制御への移行」の項で説明している移行の推奨事項にまず従うことが重要です。ローカル RSVP コール アドミッション制御へのローカルな静的ロケーション コール アドミッション制御の移行が完了すると、SIP クラスタ間トランクで RSVP SIP プレコンディションを有効にできます。

RSVP SIP プレコンディションを有効にするには、次の手順が必要です。


ステップ 1 各クラスタに SIP クラスタ間トランクを設定し、他のクラスタにつなぎます。

ステップ 2 SIP クラスタ間トランクをそれぞれ独自のロケーションに配置します。すべてのデバイスが SIP クラスタ間トランク ロケーションとは別のロケーションにあり、どのデバイスにも [Mandatory] または [Mandatory (Video Desired)] のロケーション間 RSVP ポリシーがある必要があります。ロケーション間ポリシーによって、プレコンディションの SIP トランク経由で送信される RSVP ポリシーが決まります ( 表 11-11 を参照。SIP オーディオとビデオのプレコンディション属性に対応する Unified CM ロケーション間ポリシーの一覧があります)。

ステップ 3 SIP クラスタ間トランクのロケーション内 RSVP ポリシーを [Mandatory] または [Mandatory (Video Desired)] に設定します。指定したロケーションのロケーション間 RSVP ポリシーを自らに設定して、ロケーション内 RSVP ポリシーを実現します。これは同じ SIP クラスタ間トランク上のクラスタにコールを転送する場合に必要であり、そうすると転送が失敗しません。

ステップ 4 各 Unified CM クラスタで SIP クラスタ間トランクの SIP プロファイルを設定します。そのためには、[RSVP Over SIP] [E2E]、[Fall back to local RSVP] フィールドを好みの値、[SIP Rel1XX Options] を [Send PRACK if 1XX contains SDP] にそれぞれ設定します。


 


) SIP トランク設定の場合、RSVP SIP プレコンディションで IPv6 はサポートされません。したがって、IPv6 有効化チェックボックス [Enable ANAT for early offer calls] は、RSVP SIP プレコンディションではサポートされないためオフにします。



) Unified CM をエンドツーエンド RSVP 用に設定した場合、SIP トランクでは [MTP Required] チェックボックスと [Use TRP] チェックボックスが無視されます。


上で説明したように、RSVP SIP プレコンディション機能を使用すると、Unified CM エンドポイントはクラスタを越えて直接 RSVP Agent 間予約を確立できます。図 11-31 に、RSVP SIP プレコンディションを使用したコールの発信に関与するコンポーネントを示します。

図 11-31 RSVP SIP プレコンディション、分散型 Unified CM 配置デュアル クラスタ設計

 

図 11-31 に、RSVP SIP プレコンディションが有効で代表的なデュアル クラスタ配置を示します。この配置には、中央サイト 1、支店 1、中央サイト 2、支店 2 の 4 つのロケーションが含まれています。4 つのロケーションを接続する IP WAN は、任意のトポロジ タイプにすることができ、ハブアンドスポーク トポロジに制限されません。メディア パスで RSVP 予約を必要とする 2 つのクラスタ間のコールに対して、Cisco RSVP Agent が、各 Unified CM クラスタから動的に呼び出されます。Cisco RSVP Agent は、Cisco RSVP Agent と同じロケーションにある IP Phone の RSVP 予約を行うためにプロキシとして動作します。たとえば、支店 1 の電話機 1 が支店 2 の電話機 2 をコールすると、支店 1 ロケーションの Cisco RSVP Agent と支店 2 ロケーションの Cisco RSVP Agent との間に RSVP 予約(図 11-31 の赤線で示した部分)が確立されます。これは、単一クラスタ RSVP 対応ロケーション ソリューションのメディア ストリーム セットアップに似ています。異なるのは、SIP トランクが 2 つの Unified CM クラスタ間で RSVP ポリシー ネゴシエーションを渡して、それぞれの電話機に関連付けられたクラスタ ロケーションごとに RSVP Agent を 1 つだけ割り当てるようにしている点です。

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

この同じコールのシグナリングに対しては、5 つのコール レッグがあります。第 1 のコール レッグは電話機 1 と Unified CM クラスタ 1 との間、第 2 のコール レッグは支店 1 の Cisco RSVP Agent と Unified CM クラスタ 1 との間、第 3 のコール レッグは Unified CM クラスタ 1 と Unified CM クラスタ 2 との間、第 4 のコール レッグは Unified CM クラスタ 2 と支店 2 の Cisco RSVP Agent との間、最後の第 5 のコール レッグは Unified CM クラスタ 2 と電話機 2 との間です。

図 11-31 では、クラスタ 1 支店 1 の電話機 1 がクラスタ 2 支店 2 の電話機 2 をコールします。電話機と Unified CM との間のコール シグナリングは SCCP または SIP であり、Unified CM 間のシグナリングは RSVP SIP で RSVP SIP プレコンディション機能が有効になります。電話機 1 が電話機 2 へのコールを開始すると、電話機 1 のメディア リソース グループおよびリストにある RSVP Agent に基づいて、クラスタ 1 サーバが RSVP Agent を電話機 1 に割り当て、SIP プレコンディション(RSVP ポリシー)を使用してコールを SIP トランク経由でクラスタ 2 に送信します。クラスタ 2 への SIP INVITE でアドバタイズされるプレコンディションは、電話機 1 のロケーションとクラスタ 1 の SIP トランク間に設定されたロケーション間ポリシーから派生したものです。そのため、クラスタ 1 ではロケーション支店 1 とロケーション HQ との間のロケーション間ポリシーを [Mandatory (Video Desired)] に設定します。Unified CM ポリシーの詳細については、「RSVP ポリシー」を参照してください。このロケーション間ポリシーによって、クラスタ 2 に発信される SIP INVITE のポリシー セットが決まります。この時点で、クラスタ 2 がクラスタ 1 から SIP INVITE を受信します。プレコンディションは [Mandatory] に設定されています。次に、クラスタ 2 は、自身のメディア リソース グループおよびリストに基づいて、RSVP Agent を電話機 2 に割り当て、さらにクラスタ 2 の SIP トランクと支店 2 の電話機 2 との間に設定されたロケーションを確認します。このポリシーも [Mandatory] であると、クラスタ 2 は 183 SESSION PROGRESS メッセージで応答し(このあとに PRACK が続きます)、支店 1 と支店 2 の 2 つの RSVP Agent 間で RSVP ネゴシエーションを開始します。コール予約のネゴシエートが正常に完了すると、RSVP Agent がそれぞれのクラスタにその旨通知し、SIP シグナリングが呼び出し段階へと進みます。

表 11-11 に、Unified CM ロケーション間ポリシーと、対応する SIP オーディオ/ビデオ プレコンディション属性との比較を示します (Unified CM RSVP ポリシーの詳細については、「RSVP ポリシー」を参照してください)。

 

表 11-11 Unified CM RSVP ポリシーと対応する SIP プレコンディション

Unified CM RSVP ポリシー
SIP プレコンディション(音声コール)
SIP プレコンディション(ビデオ コール)

No Reservation

audio = none

audio = none
video = none

Optional (Video desired)

audio = optional

audio = optional
video = optional

Mandatory

audio = mandatory

audio = mandatory
video = mandatory

Mandatory (Video desired)

audio = mandatory

audio = mandatory
video = optional

RSVP SIP プレコンディションを使用した Unified CM ビデオ コール

Unified CM は、RSVP SIP プレコンディションを使用して、Unified CM クラスタ全体でビデオ エスカレーションおよびデエスカレーションをサポートします。進行中の音声専用コールがビデオにエスカレーションするか、またはビデオ ストリームが音声専用コールに追加されると、ビデオ エスカレーションが発生します。デエスカレーションはこれとは逆で、ビデオ コールが音声専用コールにダウングレードすることです。

RSVP SIP プレコンディションを使用してクラスタ全体でビデオ エスカレーションおよびデエスカレーションをサポートするため、Unified CM は SIP セッション記述プロトコル(SDP)内の SIP プレコンディションで 2 つのメディア回線(M 回線)を通知します。1 つはオーディオ ストリーム用で、もう 1 つはビデオ ストリーム用です。音声とビデオ用にそれぞれ別のメディア回線を用意すると、SIP シグナリングに各ストリーム独自の RSVP ポリシーおよびステータスを確保できます。Unified CM ではオーディオ ストリームとビデオ ストリームに独自のプレコンディション属性が用意されているため、RSVP ポリシーを容易にプレコンディションにマッピングできます。この機能により、Unified CM はオーディオ ストリーム予約の正常完了ステータスを渡す一方で、同時に [Mandatory (Video Desired)] のポリシーによるビデオ ストリーム予約の失敗ステータスも渡すことができるため、コール全体を拒否するのではなくコールをビデオ コールから音声専用コールにダウングレードできます。

RSVP SIP プレコンディションのために予約されるビデオ帯域幅は、リージョン ペア間に設定された値となります。この場合は、エンドポイントのリージョンと SIP クラスタ間トランク リージョンです。ビデオ チャネルの確立後に、ビデオ帯域幅が調整されます。リージョン ペア間の 2 つのエンドポイントでネゴシエートする際に想定されるビット レート以上のビデオ帯域幅にすることを推奨します。

コール中のビデオ エスカレーションの場合、ビデオ ストリームはビデオ帯域幅が予約されたあとにだけセットアップされます。

ビデオ コールの保留/保留解除中、保留音に接続しつつ、ビデオと音声の帯域幅が引き続き予約されます。

転送など他の付加サービスの場合、オーディオ ストリームのセットアップ完了後に、Unified CM はビデオ予約およびビデオ ストリーム セットアップをトリガーします(これは、遅延ビデオ エスカレーションとも呼ばれます)。

例 11-1 遅延ビデオ エスカレーション:RSVP SIP プレコンディションを使用した音声専用からビデオ コールへのコールの転送

クラスタ A のビデオ デバイス A が、RSVP SIP プレコンディションを有効にして SIP トランク経由でクラスタ B のオーディオ デバイス B をコールします。コールは音声コールとしてセットアップされ、そのオーディオ ストリームが AudioStream Application ID および PHB(Per Hop Behavior)値 EF とともに音声プールに割り当てられます。

デバイス B が、クラスタ B のビデオ デバイス C にコールを転送します。A と C 間のオーディオ ストリームが、まず AudioStream Application ID および PHB 値 EF とともに音声プールに確立されます。

オーディオ メディア接続が正常に完了したあとにだけ、A と C との間に遅延ビデオ エスカレーションが発生します。ビデオ ストリームは、VideoStream Application ID とともにビデオ プールに割り当てられます。ビデオ ストリーム割り当てが失敗した場合、コールは AudioStream Application ID および PHB 値 EF 付きの音声専用コールのままとなります。ビデオ ストリーム予約が成功した場合、オーディオ ストリームは VideoStream Application ID とともに音声プールからビデオ プールに再許可されます。再許可が成功すると、ビデオ ストリームとオーディオ ストリームで VideoStream Application ID が PHB 値 AF41 に設定されます。一方、再許可が失敗すると、ビデオ ストリームでは VideoStream Application ID が PHB 値 AF41 に設定され、オーディオ ストリームでは VideoStream Application ID が PHB 値 0 に設定されます(ビデオ失敗のベストエフォート値)。

Unified CM および RSVP SIP プレコンディションのベスト プラクティスおよび設計上の考慮事項:

SIP トランクには、常にロケーション間とロケーション内の両方の RSVP ポリシーが必要です。ロケーション間ポリシーでは、着信コールと発信コールに正しい RSVP ポリシーを設定します。ロケーション内ポリシーでは、(クラスタ間の転送操作および自動転送操作のために)同じトランクにヘアピンされたコールにエンドツーエンド RSVP ポリシーを確保します。

[Mandatory] または [Mandatory (Video Desired)] の RSVP ポリシーを設定することを推奨します。これらの設定では、帯域幅の予約とコールの音声品質が保証されます。

SIP トランク プロファイルで [SIP Rel1XX Options] フィールドを [Send PRACK if 1XX contains SDP] に設定することを推奨します。RSVP SIP プレコンディション操作には SIP PRACK メッセージが必要ですが、1XX メッセージが SDP を含む場合にかぎられます。

RSVP SIP プレコンディションの配置での各クラスタの設定をソリューション全体で標準化して、RSVP Agent だけでなく WAN 全体で使用する RSVP クラスタ サービス パラメータ、ロケーション間ポリシー、およびコーデックを同じものにします。コールの確立を試行しているときに、クラスタ間で機能または設定に不整合がないようにすることが重要です。

Unified CM で RSVP SIP プレコンディションを使用している場合、次のガイドラインおよび制限の下、クラスタ間でシェアド ラインへの終端がサポートされます。

クラスタ間でシェアド ラインへのコールを設定するとき、発信側デバイスの RSVP Agent とシェアド ライン デバイスに最初に割り当てられた RSVP Agent との間で RSVP 予約が発生します (これは、プログラミングで制御できません)。別のロケーションでこのシェアド ラインを使用する他のすべてのデバイスは RSVP Agent を割り当てるだけで、予約を確立することはありません。

シェアド ラインのデバイスが 1 つ以上存在する各ロケーションに RSVP Agent を 1 つ割り当てます。

最初に割り当てた RSVP Agent があるデバイスがコールに応答するデバイスである場合、コールの確立が実行され、他のロケーションの他のシェアド ライン デバイスに割り当てた RSVP Agent が解放されます。

予約を確立していないデバイスがコールに応答した場合、発信側デバイスの RSVP Agent と応答したデバイスに割り当てられた RSVP Agent との間で、オプションの RSVP ポリシーを使用して新しい予約が開始されます。RSVP Agent は、予約が正常に完了するまでコール期間中予約の確立を続けます。コールがオプションのポリシーの制約下にある間、[Mandatory RSVP mid call error handle option] [Call becomes best effort](デフォルト)に設定され、予約が成功するまで 2 つのデバイス間のメディア ストリームがベストエフォート型にマーキングされます。予約が成功すると、メディアは Per Hop Behavior(PHB)値 EF(音声)または AF41(ビデオ)に再マーキングされます。

最初に割り当てた RSVP Agent があるデバイスで、必須のポリシーによる RSVP 予約が失敗した場合、そのデバイスでもそのロケーションにあるどのデバイスでも呼び出し音が鳴りません。ただし、他のすべてのロケーションにあるシェアド ライン デバイスでは呼び出し音が鳴ります。

上のシェアド ライン制限に基づいて、シェアド ラインを同じロケーション内のデバイス グループに制限することを推奨します。

Unified CM で RSVP SIP プレコンディションを使用している場合、次のガイドラインおよび制限の下、モバイル コネクト宛先(リモート接続先)への終端がサポートされます。

ローカル RSVP:発信側デバイス、ゲートウェイ、またはトランクからリモートとなるデバイス、ゲートウェイ、またはトランクへのリモート接続先には、シェアド ラインのサポートで述べたように同じ規則を適用します。

エンドツーエンド RSVP:単一回線でつながるリモート接続先では、複数の RSVP SIP プレコンディションの宛先を指さないようにします。Unified CM は、リモート接続先につながる回線ごとに RSVP SIP プレコンディション コールを 1 つだけサポートします。

MoH サーバが保留側(別の相手を保留中のユーザ)と同じロケーションにある場合、初期予約が再利用され、新しい予約は確立されません。

保留/保留解除機能で RSVP SIP プレコンディションを使用すると、エンドポイント間および RSVP Agent 間でメディア ストリームが遮断されるものの、予約は確保されます。

sRTP は RSVP SIP プレコンディションに対応しており、メディア セットアップ中と RSVP 予約後にネゴシエートされます。プレコンディション段階では、Unified CM は RTP/SAVP および暗号属性を通知しません。

T.38 は RSVP SIP プレコンディションに対応しており、T.38 FAX 転送をサポートする SIP、H.323、MGCP の各エンドポイントからネゴシエートされます。Unified CM は、リージョン間音声帯域幅(エンドポイントと SIP クラスタ間トランクとの間)を使用して、初期予約をネゴシエートします。コールの確立後および T.38 の切り替え時に、帯域幅の使用量がまだ設定されていない場合は 80 kbps に再調整されます。

制限:リージョン間ビット レートを 80 kbps 未満に設定した場合は、T.38 の切り替え後に、RSVP 予約が 80 kbps に再調整されます。このことが原因で、新たに調整した帯域幅を予約できない場合には障害が発生することがあります。このような場合、切り替え後に予約が失敗しても、コールの処理が継続されます。Unified CM が SIP クラスタ間トランクでこの障害を通知しないためです。

前述の理由から、RSVP SIP プレコンディションを使用して T.38 FAX を配置するときは、RSVP SIP プレコンディションが有効になっている T.38 エンドポイントとクラスタ間トランクとの間のリージョン間オーディオ ビット レートとして 80 kbps を使用することを推奨します。

保留/保留解除、転送、会議などの付加サービスで RSVP SIP プレコンディションをサポートするには、保留音サーバ、Annunciator、カンファレンス ブリッジなどのメディア リソースそれぞれのデバイス プールのメディア リソース グループ リスト(MRGL)にローカル RSVP Agent を割り当てる必要があります。


) 保留/保留解除、転送、会議などの付加サービスのさまざまなコール フローで、数種類のメディア リソースが RSVP SIP プレコンディション コールに投入されます。カンファレンス ブリッジ、保留音サーバ、Annunciator などのメディア リソースでも、他のデバイスが RSVP SIP プレコンディションまたは RSVP 対応ロケーション コールに呼び出されるときと同じく、RSVP Agent 関連付けが必要になります。このようなメディア リソースは、設定済みのデバイス プールに関連付けられたメディア リソース グループ リストから RSVP リソースを取得します。


クラスタ間のエクステンション モビリティのアーキテクチャおよび考慮事項

Extension Mobility Cross Cluster(EMCC; クラスタ間のエクステンション モビリティ)を使用すると、あるクラスタのユーザが別のクラスタの IP Phone にログインできます。クラスタ間のエクステンション モビリティの機能、ハイ アベイラビリティ、およびスケーラビリティの詳細については、「クラスタ間のエクステンション モビリティ(EMCC)」を参照してください。EMCC 機能はコール アドミッション制御にも当てはまることであるため、この項で取り上げます。また、「クラスタ間のエクステンション モビリティ(EMCC)」で取り上げている情報を理解していることが前提となります。

EMCC 配置では、RSVP SIP プレコンディションを使用した RSVP 対応ロケーションというのが、唯一サポートされるコール アドミッション制御の形式となります。静的ロケーションベースのコール アドミッション制御はサポートされず、EMCC 環境では機能しません。

EMCC および RSVP 対応環境

RSVP 対応ロケーション(単一クラスタまたはクラスタ内の場合)または RSVP SIP プレコンディション(分散型クラスタまたはクラスタ間の場合)を使用した Unified CM RSVP 対応配置では、IP Phone に代わって RSVP シグナリングを実施するために、Unified CM がローカル RSVP Agent をコール フローに呼び出す必要があります。これを EMCC 環境で実現するには、Unified CM クラスタ間で呼制御情報を渡して、リモートからログインした EMCC ユーザが RSVP でクラスタ内とクラスタ間の両方のコールを発信できるようにします。

EMCC 配置には、任意のログインまたは登録操作用に常に 2 つのクラスタがあります。EMCC ユーザ側から見ると、これはホーム クラスタと Visiting クラスタになります(図 11-32 を参照)。ホーム クラスタは、ユーザが元々所有するクラスタで、ユーザ情報が格納されます。Visiting クラスタは、電話機が元々所有するクラスタで、クラスタ間をローミングする EMCC ユーザのログイン先であり、デバイス情報が格納されます。

ユーザが Visiting クラスタの電話機(Visiting 電話機)にログインすると、その電話機が直接 EMCC ユーザのホーム クラスタに登録されます。その後、そのユーザおよび Visiting 電話機から発信されるすべてのコールが、ホーム クラスタの呼制御から発信されます。このため、ホーム クラスタが Visiting 電話機を管理し、Visiting 電話機に EMCC ローミング デバイス プールを提供します (EMCC ローミング デバイス プールの詳細については、「クラスタ間のエクステンション モビリティ(EMCC)」を参照してください)。

ホーム クラスタは、必要に応じて RSVP Agent に代わって Visiting クラスタに要求を送ります。その際、(特に SIP REFER メッセージでは)2 つのクラスタ間で EMCC 対応 SIP トランクが使用されます。Visiting クラスタから RSVP Agent への要求が発生するのは、エンドポイントからのコールに RSVP Agent が必要であるとホーム クラスタが判断したときだけです。ホーム クラスタは、(EMCC ローミング デバイス プールの)Visiting 電話機のロケーションと(着信側デバイス、ゲートウェイ、またはトランクの)着信側のロケーションとの間のロケーション間 RSVP ポリシーを基にその判断を下します。

RSVP ポリシーが決まると、Visiting 電話機の Visiting クラスタから RSVP Agent への要求が発生します。RSVP Agent へのこの要求で、ホーム クラスタはデバイス名(sep xxxxxxxxxxxx )を送信して、Visiting クラスタがデバイス名を検索して(デバイス自体またはデバイス プールに関する MRGL から)RSVP Agent を特定できるようにします。ホーム クラスタは、RSVP Agent を Visiting 電話機に関連付けるための情報を入手すると、ローカル RSVP コール(クラスタ内の RSVP 対応ロケーション)または RSVP SIP プレコンディション コール(クラスタ間)を確立するための手順を開始できます。

図 11-32 に、SIP 対応トランク経由で RSVP を使用した EMCC コールに関与する各種コンポーネント間のシグナリング接続およびメディア接続を示します。

図 11-32 SIP 対応トランク経由で RSVP を使用した EMCC コール

 

ベスト プラクティス

EMCC ローミング デバイス プール ロケーションと他のすべてのロケーションとの間のロケーション ポリシーを [Mandatory (Video Desired)] に設定します。

RSVP 対応ロケーションベースのコール アドミッション制御を機能させてから、EMCC で RSVP SIP プレコンディションを使用できるようにします。

EMCC ユーザがログインできる IP Phone には、ローカル RSVP Agent を関連付ける必要があります。

Unified CM の相互運用性と機能の考慮事項

ここでは、Unified CM と Cisco IOS ゲートウェイと Unified CME との相互運用性の考慮事項について説明します。

Cisco IOS ゲートウェイと Unified CME

Cisco IOS SIP/TDM ゲートウェイと Cisco Unified Communication Manager Express(Unified CME)のどちらも、RSVP SIP プレコンディションをサポートします。このサポートにより、SIP シグナリングで RSVP ポリシーを通知して、Unified CM と Cisco IOS SIP/TDM ゲートウェイまたは Unified CME との間に音声専用コールを確立できます。

Cisco IOS での SIP RSVP 機能および SIP/TDM Cisco IOS ゲートウェイおよび Unified CME で RSVP SIP プレコンディション機能を使用する際の制約事項の詳細については、次の Web サイトで入手可能な『 Cisco IOS SIP Configuration Guide 』を参照してください。

http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/12_4t/sip_12_4t_book.html

RSVP 配置で Cisco IOS ゲートウェイと Unified CME との相互運用性を確保するときに、Unified CM には 2 つの設定モードがあります。MGCP、H.323、および SIP コール シグナリングをサポートするローカル RSVP と、SIP シグナリングだけをサポートするエンドツーエンド RSVP です。Cisco IOS ゲートウェイと Unified CME との相互運用性を確保するときに、Unified CM はどちらの動作方法もサポートできます。ただし、どちらの方法を使用するにしても、以降の項で説明するように、いくつか検討すべき事項があります。

Cisco IOS ゲートウェイおよび Unified CME での Unified CM とローカル RSVP

ローカル RSVP モードでは、Unified CM は MGCP、H.323、または SIP コール シグナリング プロトコル対応の Cisco IOS TDM ゲートウェイとの相互運用性、および H.323 または SIP 対応の Unified CME との相互運用性をサポートします。このモードでは、Unified CM はゲートウェイを宛先または発信元としてコールが確立されると RSVP Agent を Cisco IOS TDM ゲートウェイに割り当てます。また、プレコンディションおよび RSVP ポリシーを Cisco IOS TDM ゲートウェイに通知しません。これは、Unified CM での MGCP、H.323、および SIP のデフォルト設定です。

図 11-33 に、Unified CM のローカル RSVP と、Cisco IOS TDM ゲートウェイおよび Unified CME との統合を示します。

図 11-33 Unified CM のローカル RSVP と、Cisco IOS TDM ゲートウェイおよび Unified CME との統合

 

利点

このモデルには、次の利点があります。

多種多様な Cisco IOS ゲートウェイ シグナリング プロトコル(MGCP、H.323、SIP)のサポート。

SIP と SCCP Unified CME の両方のエンドポイントのサポート。

Unified CM の RSVP ポリシーおよびアプリケーション ID の集中管理。

コール転送や自動転送の付加サービス シナリオでは、Cisco IOS TDM ゲートウェイで MGCP を使用すると、メディア パスが最適化されます。ローカル システム(Cisco IOS TDM ゲートウェイ)からコールが転送または自動転送された場合、メディアとシグナリングの両方とも終了したあと、転送または自動転送側に対して再確立されます。

欠点

このモデルには、次の欠点があります。

RSVP Agent セッションを使用します(ソフトウェアまたはハードウェアによるセッション。どちらになるかは、セッション トランスコーディングなどの機能とセッション要件によって決まります)。

転送および自動転送付加サービス シナリオでは、Cisco IOS TDM ゲートウェイおよび Unified CME で H.323 と SIP を統合した場合、メディア パスが最適化されません。つまり、ローカル システム(Cisco IOS TDM ゲートウェイまたは Unified CME)からのコール転送または自動転送により、メディアとシグナリングの両方ともローカル システムにヘアピンされて、二重に帯域幅を消費することになります。

この方法では、「Unified CM の RSVP 対応ロケーション」の項で説明するように、クラスタ内コール アドミッション制御が機能します。

Cisco IOS ゲートウェイおよび Unified CME での Unified CM とエンドツーエンド RSVP または RSVP SIP プレコンディション

エンドツーエンド RSVP モードでは、Unified CM は RSVP SIP プレコンディション シグナリングを使用して、Cisco IOS ゲートウェイおよび Unified CME との相互運用性をサポートします。このモードでは、Unified CM は RSVP Agent を割り当てません。Cisco IOS ゲートウェイまたは Unified CME は、ネイティブに RSVP をサポートします。この方法は、Cisco Integrated Services Router(ISR)での RSVP Agent ソフトウェア セッションの使用率を削減します。

図 11-34 に、Unified CM と、Cisco IOS TDM ゲートウェイまたは Unified CME との RSVP SIP プレコンディション統合を示します。

図 11-34 Unified CM と、Cisco IOS TDM ゲートウェイまたは Unified CME との RSVP SIP プレコンディションの統合

 

利点

このモデルには、次の利点があります。

RSVP SIP プレコンディションのサポート。

SIP Cisco IOS TDM ゲートウェイまたは Unified CME に RSVP Agent リソースを使用しません。

欠点

このモデルには、次の欠点があります。

SCCP Unified CME エンドポイントだけをサポートします。

SIP トランク実装だけをサポートします。

転送および自動転送付加サービス シナリオでは、メディア パスが最適化されません。つまり、ローカル システム(SIP Cisco IOS TDM ゲートウェイまたは Unified CME)からのコール転送により、メディアとシグナリングの両方ともローカル システムにヘアピンされて、二重に帯域幅を消費することになります。

Unified CM と SIP Cisco IOS TDM ゲートウェイおよび Unified CME との相互運用に関する設計の考慮事項

ローカル RSVP とエンドツーエンド RSVP のどちらかの配置を選択するときは、次の基準に基づいて最適なオプションを判断してください。

目的のコール シグナリング プロトコル(H.323、MGCP、または SIP)。ダイヤル プラン、PBX 相互運用性、コール シグナリング機能など、コール アドミッション制御の範囲外の数多くの要件に基づいて判断します。

ローカル システム(SIP Cisco IOS TDM ゲートウェイおよび Unified CME)からリモートの宛先へのコールの転送および自動転送に必要な付加サービス。たとえば、コールを WAN 経由で中央のボイス メッセージ環境に転送する場合に、これらのサービスが必要になります。

ソリューションの管理。RSVP ポリシーおよびアプリケーション ID の集中管理と分散管理のどちらかを選択します。

リソース使用率。RSVP Agent セッションとネイティブ RSVP の使用率を比較検討します。セッション数によっては専用のプラットフォームが必要になることがあり、その場合 SIP Cisco IOS TDM ゲートウェイまたは Unified CME にセッションを確立できません。

RSVP SIP プレコンディションをサポートする SIP Cisco IOS TDM ゲートウェイまたは Unified CME を指す SIP トランクを Unified CM に設定する場合、トランクには常にロケーション間とロケーション内の両方の RSVP ポリシーを設定します。ロケーション間ポリシーでは、着信コールと発信コールに正しい RSVP ポリシーを設定します。ロケーション内ポリシーでは、(転送および自動転送操作のために)同じトランクにヘアピンされたコールにエンドツーエンド RSVP ポリシーを確保します。

Unified CM では、単一クラスタに設定されたすべての Cisco IOS TDM ゲートウェイおよび Unified CME に適用できるロケーションを 1 つ別途設定することを推奨します。そのロケーションでは、他のすべてのロケーションとともに、ロケーション間 RSVP ポリシー セットを [Mandatory] または [Mandatory (Video Desired)] に設定します。このような環境で RSVP SIP プレコンディションを正しく機能させるには、RSVP ポリシーが必要です。


) SIP Cisco IOS TDM ゲートウェイと物理的に同じ LAN にある IP Phone でも、自身のロケーションと SIP トランク上のロケーションとの間に RSVP ポリシーが必要です。このため IP Phone に RSVP Agent リソースが使用されますが、RTP ストリームがローカルのままであるため WAN の帯域幅が差し引かれません。


Unified CM に設定した RSVP ポリシーを Cisco IOS TDM ゲートウェイに設定したポリシーと一致したものにします。SIP Cisco IOS TDM ゲートウェイまたは Unified CME に対して RSVP 予約を有効にする場合は、 ダイヤル ピア 設定で次のオプションを使用します。

req-qos guaranteed-delay audio
acc-qos guaranteed-delay audio
 

この設定を行うと、各音声コールに対して、SIP Cisco IOS TDM ゲートウェイは遅延保証付きのサービスを使用して RSVP 予約を要求します。要求された QoS と許容可能な QoS の両方がこの RSVP サービスを指定している場合、コールが成功するためには RSVP 予約が必須になります(予約を確立できない場合はコールが失敗します)。

Unified CM に設定したアプリケーション ID を Cisco IOS TDM ゲートウェイおよび Unified CME に設定したアプリケーション ID と一致したものにします。

SIP プレコンディションとともに設定した適切なダイヤル ピアが使用されるように、着信と発信のダイヤル ピアを正確に一致させます。詳細については、次の Web サイトで入手可能な『 Cisco IOS SIP Configuration Guide 』を参照してください。

http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/12_4t/sip_12_4t_book.html

Cisco Unified Border Element および RSVP SIP プレコンディション

Cisco Unified Communications システムの 8.5 以降のリリースでは、Cisco Unified Border Element は音声のみのコールで RSVP SIP プレコンディションをサポートしています。このサポートにより、企業は非 RSVP 呼制御アプリケーションを RSVP SIP プレコンディション インフラストラクチャと統合するために Unified Border Element を使用できます。呼制御の非 RSVP 側では、Unified Border Element は H.323 と SIP 両方との統合をサポートしています。コールの RSVP 側では、SIP と RSVP を一緒に使用して Unified CM、Unified CME、および SIP-TDM Cisco IOS ゲートウェイなどの RSVP プレコンディション呼制御と統合できます。図 11-35 はこのタイプのインターワーキングを示しています。

図 11-35 SIP トランクを介した RSVP での Cisco Unified Border Element

 

呼制御の非 RSVP 側の SIP 統合では、Unified Border Element でアーリー オファーまたはディレイド オファーのいずれかがサポートされます。また、H.323 統合では、Fast Start または Slow Start のいずれかがサポートされます。呼制御の RSVP SIP プレコンディション側では、呼制御アプリケーションを介して RSVP ポリシーをネゴシエートするのに必要なプレコンディションを提供するため、SIP アーリー オファーが常に送信されます。したがって、RSVP SIP プレコンディションは常にアーリー オファーです。

詳細については、次の Web サイトで入手可能な『 Cisco IOS SIP Configuration Guide 』を参照してください。

http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/12_4t/sip_12_4t_book.html

Service Advertisement Framework(SAF)および Call Control Discovery(CCD)

Cisco Service Advertisement Framework(SAF)を使用すると、ネットワーク アプリケーションで IP ネットワーク内のネットワーク サービスに関する情報をアドバタイズしたり検出したりできます。Call Control Discovery(CCD; 呼制御ディスカバリ)は SAF を使用して、Unified CM、Unified CME などの呼制御エージェントによってホストされる内部 Directory Number(DN; ディレクトリ番号)の可用性に関する情報を配布および維持します。また、CCD は、これらの内部ディレクトリ番号にPSTN から到達できるようにする対応した番号プレフィックスも配布します(「To PSTN」プレフィックス)。

ここでは、RSVP SIP プレコンディションの配置に関係する SAF CCD について説明します。Service Advertisement Framework および呼制御ディスカバリの詳細については、「ネットワーク インフラストラクチャ」「Unified Communications の配置モデル」「ダイヤル プラン」の各章を参照してください。

SAF CCD と RSVP SIP プレコンディションが連携して動作するため、移動、追加、および変更の動的なダイヤル プランと複雑なマルチホーム多層ネットワーク向けのトポロジ対応コール アドミッション制御方式を容易に管理できます。これにより、静的なゲートキーパー インフラストラクチャを動的に置換して、ネットワークの変更に応じたダイヤル プラン解決およびコール アドミッション制御を実現できます。

SAF CCD が RSVP SIP プレコンディション コール アドミッション制御と連携して動作するため、予約が失敗しても宛先に到達するための代替ルートを確保できます。この機能は、呼制御ディスカバリ自動PSTN フェールオーバーと呼ばれます。

呼制御ディスカバリ自動PSTN フェールオーバー

SAF CCD は、特定のコールに対して IP ルートを 1 つだけ選択できるという点で、標準のコール ルーティングとは異なります。一方、標準のコール ルーティングでは、ルート リストおよびルート グループを使用して、単一のコールに複数の IP パスを定義し、連続して試行できます。SAF 学習ルートを使用してコールを発信する場合、次のオプションを選択できます。

選択した IP パスを取得して、着信番号に到達します。

IP パスが使用できない場合、PSTN プレフィックスを使用して、着信番号と、発信側デバイスの Automatic Alternate Routing(AAR; 自動代替ルーティング)Calling Search Space(CSS; コーリング サーチ スペース)を変更し、PSTN 経由でコールをルーティングします。

SAF 学習ルートで RSVP SIP プレコンディションを使用し、予約が成功した場合、RSVP を使用して IP パスに確立する通常の手順どおりにコールが確立されます。ただし、IP ルートでの予約が失敗し、Precondition Failure or Reservation Failure(SIP メッセージ 580)または Precondition Unsupported(SIP メッセージ 420)のコール終了原因コードが返された場合は、CCD 自動PSTN フェールオーバーが発生します (フェールオーバーは、次に説明するように、他のコール終了原因コードで発生することもあります)。CCD 自動PSTN フェールオーバーは、コール アドミッション制御障害のために SAF CCD IP ルートが失敗すると発生するという点で、自動代替ルーティング(「Automated Alternate Routing」を参照)に似ています。AAR も同じく、クラスタ内コール アドミッション制御の障害時に発生します。ただし、CCD 自動PSTN フェールオーバーは、コール アドミッション制御とは別のルーティング障害でも発生することがあるという点で、AAR とは異なります。コールがアラート段階に入る前に学習パターンへのコールが失敗し、コール終了原因コードが通常のコールのクリア、ユーザ ビジー、宛先故障、番号未割り当て、またはジオロケーション不一致以外のものであると、CCD 自動PSTN フェールオーバーが発生します。

CCD 自動PSTN フェールオーバーは、AAR CSS と(CCD が分配する)「To PSTN」プレフィックスを使用して、コールを再ルーティングします。これにより、管理者はローカル コール アドミッション制御で AAR コールの再ルーティングを実現するために、CCD 自動PSTN フェールオーバー用のものと同じサービス クラスを利用できます。主な違いは、CCD 自動PSTN フェールオーバーは AAR プレフィックスではなく SAF CCD 分配機能が提供するプレフィックス(「To PSTN」プレフィックス)を使用することです。

図 11-36 に、RSVP SIP プレコンディション コール アドミッション制御で障害が発生したあとの CCD 自動 PSTN フェールオーバーを示します。

図 11-36 RSVP SIP プレコンディションでの CCD 自動 PSTN フェールオーバー

 

また、SAF CCD 学習ルートによる CCD 自動PSTN フェールオーバーと、静的なルート パターンを使用したルート リストおよびルート グループ機能による再ルーティングとでは、機能に違いがあります。ルート グループおよびルート リストを指す静的なルート パターンを使用した場合、RSVP SIP プレコンディションの予約で障害が発生すると、Unified CM はルート グループおよびリストで次に設定されているトランクまたはゲートウェイにコールをルーティングします。

(SAF と静的なルート パターンを使用した)いずれの場合でも、コール アドミッション制御で障害が発生したら、コールをローカル ルート グループにルーティングすることを推奨します (ローカル ルート グループの詳細については、「ローカル ルート グループ」を参照してください)。CCD 自動PSTN フェールオーバー機能のコンストラクトでこれを実行する必要があります。発信側の AAR CSS にコーリング サーチ スペースを正しく設定することが重要です。これにより、CCD 自動フェールオーバーの際、コールはルート パターンに送信されます。ルート パターンのローカル ルート グループ機能が働き、コールはローカル ゲートウェイにルーティングされます。このルート パターンとして特にすべての CCD 自動フェールオーバー条件用の catch-all パターンを使用して、コールを発信側のローカルなゲートウェイにルーティングできます。

Cisco Unified SIP Proxy の考慮事項

Cisco Unified SIP Proxy は、ルーティングおよび SIP シグナリング正規化を集中して行える高性能かつハイ アベイラビリティのステートレスな Session Initiation Protocol(SIP)サーバです。呼制御ドメイン間で要求を転送することにより、Cisco Unified SIP Proxy は企業ネットワークおよびサービス プロバイダー ネットワーク内でセッションをルーティングできます。Cisco Unified Communications 配置での Unified SIP プロキシの主な目的は、SIP シグナリング、SIP 正規化、およびダイヤル プラン集中化を統合することです。Cisco Unified SIP Proxy とその機能の詳細については、次の Web サイトで入手可能なドキュメントを参照してください。

http://www.cisco.com/en/US/prod/collateral/modules/ps2797/data_sheet_c78-521390_ps2797_Products_Data_Sheet.html

RSVP SIP プレコンディションの環境では、Unified SIP Proxy は単にさまざまな SIP メッセージの SDP 部分に含まれるプレコンディションを伝えるだけで、プレコンディションにはいっさい変更を加えません。

Adaptive Security Appliance(ASA)の考慮事項

RSVP SIP プレコンディションを使用して、Unified CM、Unified CME、Unified SIP Proxy、Cisco IOS SIP/TDM ゲートウェイなどの Cisco Unified Communications 呼処理アプリケーション間に Cisco ASA を配置するときは、次の両方の検査が必要です。

SIP インスペクション

SIP インスペクションでは、どの Cisco SIP シグナリング製品でも SIP シグナリングが ASA を通過できるようにします。ASA はその後、さまざまな SIP メッセージの SDP に記録されている適切なメディア ピンホールを開きます。これは、ASA が RSVP Agent 間のメディア パスにあり、その RSVP Agent が帯域幅を予約中であり、かつ Unified Communications エンドポイントのメディア フローの発信元になっているときに重要です。

IP オプション検査

IP オプション検査では、RSVP Agent から RSVP Agent への RSVP シグナリングが ASA を通過できるようにします。どの RSVP メッセージでも、各パケットの IP ヘッダーに [IP Router Alert Option] を設定します。IP オプション検査で [IP Router Alert Option] を許可して、このようなパケットが ASA を通過できるようになっていないかぎり、ASA はデフォルトではこのようなパケットをドロップします。

ASA Software Release 8.3 では、RSVP SIP プレコンディション実装に固有の SIP インスペクションと IP オプション検査の両方をサポートしています。SIP シグナリングの検査や RSVP パケットの受け渡しのために ASA が必要になる RSVP SIP プレコンディションの配置では、互換性を確保するため、ASA 8.3 以降のソフトウェア リリースを使用する必要があります。

SIP 検査および IP オプション検査用に ASA を設定する方法の詳細については、次の Web サイトで入手可能な『 Cisco ASA 5500 Series Configuration Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps6120/products_installation_and_configuration_guides_list.html

コール アドミッション制御の設計上の考慮事項

ここでは、各種の Unified CM 呼処理配置モデルおよび次の IP WAN トポロジに対して、コール アドミッション制御メカニズムを適用する方法について説明します。

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

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

「単純な MPLS トポロジ」

「汎用トポロジ」

これらの項では、採用する Unified CM 配置モデルに基づいて、トポロジごとにそれぞれ別の設計考慮事項を示します。

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

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

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

 

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

フレーム リレー

ATM

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

専用回線

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

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

「集中型の Unified CM 配置」

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

「分散型の Unified CM 配置」

Unified CM クラスタまたは Cisco Unified Communications Manager Express(Unified CME)を各サイトに配置します。

集中型の Unified CM 配置

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

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

 

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

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

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

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

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

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

Unified CM は、ロケーションを 2000 箇所までサポートします。

WAN の帯域幅が十分にない場合に、PSTN を介した自動ルーティングを実行する必要があるときは、Unified CM 上で Automated Alternate Routing(AAR; 自動代替ルーティング)機能を設定します (「Automated Alternate Routing」 を参照)。

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


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


分散型の Unified CM 配置

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

 

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

フレーム リレー

ATM

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

専用回線

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

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

「集中型の Unified CM 配置」

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

「分散型の Unified CM 配置」

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

集中型の Unified CM 配置

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

図 11-41 集中型の Unified CM での 2 層ハブアンドスポーク トポロジ

 

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

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

 

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

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

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

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

各 Cisco RSVP Agent が、そのサイトのすべてのデバイスの Media Resource Group List(MRGL; メディア リソース グループ リスト)の Media Resource Group(MRG; メディア リソース グループ)に属するようにします。

Unified CM サービス パラメータで、[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 を有効にします(図 11-42 を参照)。

分散型の Unified CM 配置

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

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

 

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

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

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

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

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

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

Unified CM は、ロケーションを 2000 箇所までサポートします。

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

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


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


単純な MPLS トポロジ

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

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

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

 

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

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

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

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

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

 

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

「集中型の Unified CM 配置」

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

「分散型の Unified CM 配置」

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


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



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


集中型の Unified CM 配置

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

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

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

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

 

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


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


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

 

特定サイトに許されている帯域幅がすべて消費されてしまっている場合は、Unified CM が備えている Automated Alternate Routing(AAR; 自動代替ルーティング)機能を使用して、PSTN へ自動的にフェールオーバーさせることができます (AAR の詳細については、「Automated Alternate Routing」を参照してください)。

分散型の Unified CM 配置

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

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

 

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

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

図 11-49 クラスタ間トランク(ICT)によるマルチ クラスタ接続

 

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

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

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

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

Unified CM クラスタ内のコールには、Automated Alternate Routing(AAR; 自動代替ルーティング)機能で対応(AAR の詳細については、「Automated Alternate Routing」を参照してください)

汎用トポロジ

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

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

図 11-50 汎用トポロジ

 

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

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

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

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

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

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

多層アーキテクチャ

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

「集中型の Unified CM 配置」

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

「分散型の Unified CM 配置」

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

「分散型混在呼処理配置」

さまざまなトポロジに呼制御アプリケーションが分散します。

集中型の Unified CM 配置

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

「単一の Unified CM クラスタ」

「同じ場所にある Unified CM クラスタ」

単一の Unified CM クラスタ

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

図 11-51 汎用トポロジにおける単一の Unified CM クラスタ

 

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

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

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

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

各 Cisco RSVP Agent が、そのサイトのすべてのデバイスの Media Resource Group List(MRGL; メディア リソース グループ リスト)の Media Resource Group(MRG; メディア リソース グループ)に属するようにします。

Unified CM サービス パラメータで、[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 を有効にします。

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

この項の推奨事項は、複数の Unified CM が同じ LAN または MAN にある配置に適用されます。ただし、Unified CM クラスタが存在するサイトが低帯域幅リンクで接続されている場合には、考慮事項も同じものが有効です。仕様のため、クラスタからクラスタへのコールでは各クラスタのエンドポイントに RSVP Agent を使用します。

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

図 11-52 汎用トポロジにおける同じ場所にある Unified CM クラスタ

 

図 11-52 に示す配置には、次のガイドラインが適用されます。

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

中央サイトとリモート サイト間およびクラスタ間を流れるコール トラフィックの量に応じて、中央サイトの両クラスタの RSVP Agent とも、1 つまたは複数の Cisco Integrated Services Router(ISR)に配置することを検討してください。1 つの ISR に異なるクラスタで制御される複数の RSVP Agent をホストできます。

各 Unified CM クラスタで、各サイトのロケーションを定義し、すべての帯域幅の値を無制限のままにします。

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

各 Cisco RSVP Agent が、そのサイトのすべてのデバイスの Media Resource Group List(MRGL; メディア リソース グループ リスト)の Media Resource Group(MRG; メディア リソース グループ)に属するようにします。

Unified CM サービス パラメータで、両クラスタに [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 を有効にします。

SIP クラスタ内トランクで RSVP SIP プレコンディションを有効にします(手順については、「ロケーションベースのコール アドミッション制御から RSVP SIP プレコンディションへの移行」を参照してください)。

SIP クラスタ間トランク ロケーションと自らを含めたすべてのロケーションとの間に、[Mandatory] または [Mandatory (Video Desired)] のロケーション間 RSVP ポリシーを設定します(次のロケーション内 RSVP ポリシーを参照)。

SIP クラスタ間トランクに [Mandatory] または [Mandatory (Video Desired)] のロケーション内 RSVP ポリシーを設定します。ロケーション内 RSVP ポリシーを設定するには、ロケーションを選択し、そのロケーションのポリシーを設定します。これにより、このロケーション内のコールでは RSVP コール アドミッション制御が効率よく使用されるようになります。これは、発信元クラスタへのコールの転送または自動転送からコールがトランクにヘアピンされる場合に重要です。

中央サイト内でのクラスタ間のコールには、RSVP Agent が使用されます。これは仕様であり、付加サービスをクラスタ全体で機能させて、クラスタ全体でエンドツーエンド RSVP を保持できるようにしています。サポートできるバリエーションがいくつかあります。同じロケーションにあるクラスタに最善のコール アドミッション制御設計については、シスコ営業担当にお問い合わせください。

分散型の Unified CM 配置

RSVP SIP プレコンディションにより、汎用ネットワーク トポロジで Unified Communication Manager クラスタを分散配置した環境でコール アドミッション制御を機能させることができます。ここでは、クラスタ間での RSVP SIP プレコンディションのサポートを使用したデュアル クラスタ配置の例を示します(図 11-53 を参照)。このモデルにはハイブリッドおよびバリエーションがいくつか考えられます。これは簡単な設計の概要を示した例にすぎませんが、ベスト プラクティスおよび設計上の考慮事項を踏まえたものです。

図 11-53 分散型の Unified CM 配置

 

図 11-53 に示す配置には、次のガイドラインが適用されます。

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

各 Unified CM クラスタで、各サイトのロケーションを定義し、すべての帯域幅の値を無制限のままにします。

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

各 Cisco RSVP Agent が、そのサイトのすべてのデバイスの Media Resource Group List(MRGL; メディア リソース グループ リスト)の Media Resource Group(MRG; メディア リソース グループ)に属するようにします。

Unified CM サービス パラメータで、両クラスタに [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 を有効にします。

SIP クラスタ内トランクで RSVP SIP プレコンディションを有効にします(手順については、「ロケーションベースのコール アドミッション制御から RSVP SIP プレコンディションへの移行」を参照してください)。

SIP クラスタ間トランク ロケーションと自らを含めたすべてのロケーションとの間に、[Mandatory] または [Mandatory (Video Desired)] のロケーション間 RSVP ポリシーを設定します(次のロケーション内 RSVP ポリシーを参照)。

SIP クラスタ間トランクに [Mandatory] または [Mandatory (Video Desired)] のロケーション内 RSVP ポリシーを設定します。ロケーション内 RSVP ポリシーを設定するには、ロケーションを選択し、そのロケーションのポリシーを設定します。これにより、このロケーション内のコールでは RSVP コール アドミッション制御が効率よく使用されるようになります。これは、発信元クラスタへのコールの転送または自動転送からコールがトランクにヘアピンされる場合に重要です。

分散型混在呼処理配置

RSVP SIP プレコンディションにより、汎用ネットワーク トポロジで Unified Communications 呼制御アプリケーションを分散配置した環境でコール アドミッション制御を機能させることができます。

ここでは、サポートされている RSVP SIP プレコンディションの配置モデルのリストを示します。これらのモデルにはハイブリッドおよびバリエーションがいくつか考えられます。いずれも有効な設計の概要を示した例にすぎませんが、ベスト プラクティスおよび設計上の考慮事項を踏まえたものです (このような機能の設定の詳細については、特定の製品マニュアルを参照してください)。

図 11-54 に示す配置には、次のガイドラインが適用されます。

配置では、音声専用コールの Unified CME SCCP 統合をサポートします。

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

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

「Unified CM と SIP Cisco IOS TDM ゲートウェイおよび Unified CME との相互運用に関する設計の考慮事項」に記載されている推奨事項に従います。

図 11-54 Unified CM から Cisco IOS ゲートウェイ(TDM)および Unified CME(SCCP)

 

図 11-55 に示す配置には、次のガイドラインが適用されます。

次の Web サイトで入手可能な『 Cisco IOS SIP Configuration Guide 』に記載されている SIP Cisco IOS TDM ゲートウェイと Unified CME との相互運用性に関するガイドライン、ベスト プラクティス、制限、および制約事項に従います。

http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/12_4t/sip_12_4t_book.html

コールが失敗したり、保護されなかったりするのを避けるために、各 Unified CME または SIP Cisco IOS TDM ゲートウェイに一貫性のある RSVP ポリシーを設定します。SIP Cisco IOS TDM ゲートウェイまたは Unified CME に対して RSVP 予約を有効にする場合は、 ダイヤル ピア 設定で次のオプションを使用します。

req-qos guaranteed-delay audio
acc-qos guaranteed-delay audio
 

この設定を行うと、各音声コールに対して、SIP Cisco IOS TDM ゲートウェイは遅延保証付きのサービスを使用して RSVP 予約を要求します。要求された QoS と許容可能な QoS の両方がこの RSVP サービスを指定している場合、コールが成功するためには RSVP 予約が必須になります (予約を確立できない場合はコールが失敗します)。

アプリケーション ID を使用する場合は、ソリューションの全製品(SIP Cisco IOS TDM ゲートウェイおよび Unified CME)で一貫性を確保します。

SIP プレコンディションとともに設定した適切なダイヤル ピアが使用されるように、着信と発信のダイヤル ピアを正確に一致させます。詳細については、次の Web サイトで入手可能な『 Cisco IOS SIP Configuration Guide 』を参照してください。

http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/12_4t/sip_12_4t_book.html

図 11-55 Unified CME から Unified CME、Unified CME から Cisco IOS ゲートウェイ、および Cisco IOS ゲートウェイから Cisco IOS ゲートウェイ

 

図 11-56 に示す配置には、次のガイドラインが適用されます。

分散型呼処理配置の Unified CM の場合は図 11-54 に記載されたガイドラインに従い、Unified CME および SIP Cisco IOS TDM ゲートウェイの場合は図 11-55 に記載されたガイドラインに従います。

各 Unified CM クラスタには、一般に Cisco Unified SIP Proxy に向かうトランクが 1 つあります。そのトランクでは、RSVP SIP プレコンディション(エンドツーエンド RSVP)を有効にします。

Cisco Unified SIP Proxy への SIP トランクで RSVP SIP プレコンディションを有効にします(手順については、「ロケーションベースのコール アドミッション制御から RSVP SIP プレコンディションへの移行」を参照してください)。

IP Phone ロケーションと SIP トランク ロケーションとの間の各 Unified CM クラスタにロケーション間 RSVP ポリシーを設定します。これにより、Cisco Unified SIP Proxy への SIP トランクを経由するすべてのコールに対して SIP プレコンディションが有効になります。

RSVP SIP プレコンディションをサポートしない SIP 宛先が存在する可能性がある場合は、ローカル RSVP への RSVP SIP プレコンディションのフォールバックを SIP トランクに設定して、そのコール フロー用の RSVP Agent を割り当てます。また、RSVP SIP プレコンディション フォールバックを有効にする場合は、SIP トランクに関連付けられた RSVP Agent を物理的なサイトに配置して、そのコール フローで RSVP パスが保護されるようにします。

Unified CME および SIP Cisco IOS TDM ゲートウェイには、一般に Cisco Unified SIP Proxy に向けた SIP ダイヤル ピアが 1 つあります。次の Web サイトで入手可能な『 Cisco IOS SIP Configuration Guide 』の記載に従って、そのダイヤル ピアに RSVP SIP プレコンディション(SIP プレコンディションサポート)を設定します。

http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/12_4t/sip_12_4t_book.html

Cisco Unified SIP Proxy に関する設定、ガイドライン、ベスト プラクティス、制限、および制約事項の詳細については、次の Web サイトで入手可能なドキュメントを参照してください。

http://www.cisco.com/en/US/prod/collateral/modules/ps2797/data_sheet_c78-521390_ps2797_Products_Data_Sheet.html

図 11-56 Cisco Unified SIP Proxy 経由の RSVP SIP プレコンディションに対応したすべてのコンポーネント

 

図 11-57 に示す配置には、次のガイドラインが適用されます。

分散型呼処理配置の Unified CM の場合は図 11-54 に記載されたガイドラインに従い、Unified CME および SIP Cisco IOS TDM ゲートウェイの場合は図 11-55 に記載されたガイドラインに従います。

Service Advertisement Framework(SAF)および Call Control Discovery(CCD; 呼制御ディスカバリ)をネットワークで有効にし、配置した製品全体で機能させます。SAF 設定の詳細については、次のドキュメントを参照してください。

Cisco IOS Service Advertisement Framework Configuration Guide

http://www.cisco.com/en/US/docs/ios/saf/configuration/guide/15_0/saf_15_0_book.html

Cisco Unified Communications Manager Features and Services Guide

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

SAF 対応 SIP トランクで RSVP SIP プレコンディションを有効にします(手順については、「ロケーションベースのコール アドミッション制御から RSVP SIP プレコンディションへの移行」を参照してください)。

SAF 対応 SIP トランクで RSVP SIP プレコンディションを有効にします。RSVP SIP プレコンディションの配置の呼制御ディスカバリでは、SAF 対応 SIP トランクだけを使用します。RSVP SIP プレコンディションの配置では、SAF 対応 H.323 トランクは機能しません。

SAF 対応 SIP トランク ロケーションと自らを含めたすべてのロケーションとの間に、[Mandatory] または [Mandatory (Video Desired)] のロケーション間 RSVP ポリシーを設定します(次のロケーション内 RSVP ポリシーを参照)。これにより、SIP トランク経由で SAF ネットワークを発着するすべてのコールに対して SIP プレコンディションが有効になります。

SAF 対応 SIP トランクに [Mandatory] または [Mandatory (Video Desired)] のロケーション内 RSVP ポリシーを設定します。ロケーション内 RSVP ポリシーを設定するには、ロケーションを選択し、そのロケーションのポリシーを設定します。これにより、このロケーション内のコールでは RSVP コール アドミッション制御が効率よく使用されるようになります。これは、発信元クラスタへのコールの転送または自動転送からコールがトランクにヘアピンされる場合に重要です。

RSVP SIP プレコンディション環境で SAF 対応 SIP トランクを使用する場合は、CCD 自動フェールオーバーを有効にし、コール アドミッション制御に失敗したコールをローカル ルート グループにルーティングすることを推奨します。詳細については、「呼制御ディスカバリ自動PSTN フェールオーバー」の項と「ダイヤル プラン」の章の「ローカル ルート グループ」を参照してください。

図 11-57 Service Advertisement Framework(SAF)および Call Control Discovery(CCD; 呼制御ディスカバリ)経由の RSVP SIP プレコンディションに対応したすべてのコンポーネント

 

TelePresence ビデオの相互運用性アーキテクチャに関するコール アドミッション制御の設計上の推奨事項

ビデオの相互運用性とは、マルチポイント コントロール ユニット(MCU)を必要としない、Cisco TelePresence エンドポイント、Cisco Unified Communications ビデオ エンドポイント、およびサードパーティ製ビデオ エンドポイント間のポイントツーポイント ビデオ コールのサポートのことです。このようなコール シナリオのサポートを提供するには、サポートを検証し、設計と配置の考慮事項を決定するために、テストが必要でした。この項では、相互運用可能なビデオ コールの Quality of Service(QoS)およびコール アドミッション制御(CAC)に適用される設計上の考慮事項と推奨事項について説明します。TelePresence システムは、次のサイトで入手可能な『 Cisco TelePresence Network Systems Design Guide 』で示されているガイドラインに従って設計する必要があります。

http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns819/landing_vid_tPresence.html

この項では、Unified Communications と TelePresence のエンドポイント間でビデオの相互運用性を可能にするための設計を付加する方法について説明します。Unified Communications エンドポイントの詳細については、「Unified Communications エンドポイント」の章を参照してください。TelePresence エンドポイントの詳細については、 http://www.cisco.com/en/US/products/ps7060/index.html で入手可能な Cisco TelePresence エンドポイント製品マニュアルを参照してください。


) サードパーティ製ビデオ エンドポイントは、Cisco Unified Communications エンドポイントと同じガイドラインおよび推奨事項に従う必要があります。この項全体を通して、UC エンドポイントという用語は、サードパーティ製エンドポイントと Cisco Unified Communications エンドポイントの両方を指すために使用します。


Cisco TelePresence の現在のリリースは、TelePresence エンドポイントについて、ネットワーク帯域幅の予約またはコールごとの CAC の実行のメカニズムを提供していません。したがって、特定のサイトに配置された TelePresence 会議室の数がそのサイトで利用可能な帯域幅を超えた場合、同時に発生する TelePresence コールが多すぎ、ネットワークの QoS ポリシーによって TelePresence パケットがドロップされ始める可能性があります。その結果、そのネットワーク リンクを通過するすべてのコールでオーディオとビデオの質が低下します。既存のコール アドミッション制御技術には、ロケーションベースの CAC およびリソース予約プロトコル(RSVP)が含まれています。どちらも Cisco Unified Communications Manager(Unified CM)によって管理されますが、Cisco TelePresence エンドツーエンド コールでは推奨およびサポートされません。したがって、現在推奨されるのは、手動のキャパシティ プランニングを使用して、ネットワーク インフラストラクチャ全体で同時に発生する可能性があるすべての TelePresence コールをサポートするのに十分な帯域幅を提供することです。TelePresence ビデオの相互運用性は、UC エンドポイントおよび相互運用可能なネイティブ コールの CAC を実行するために、CAC の要件と設計上の考慮事項に対応します。

TelePresence ビデオの相互運用性を設計する前に、ロケーション CAC および RSVP CAC を理解することが重要です。この項は、TelePresence ビデオの相互運用性に関して、ロケーション CAC と RSVP の両方に対応しています。各 CAC メカニズムには固有の利点、設計上の考慮事項、および要件があります。

また、Unified CM での TelePresence ビデオの相互運用性によって、Cisco Telepresence System(CTS)エンドポイントは、CTS 以外のエンドポイントと通信できます(インストールされている CTS ソフトウェアがそのような相互運用性をサポートしている場合)。詳細については、次のサイトで入手可能な『 Interoperability Between CTS Endpoints and Other Cisco Endpoints or Devices 』のマニュアルを参照してください。

http://www.cisco.com/en/US/docs/telepresence/interop/endpoint_interop.html

サポートされる CAC 配置シナリオと設計上の考慮事項

TelePresence ビデオの相互運用性の CAC に関する設計上の考慮事項は、次の主要な配置シナリオに基づきます。

混在単一クラスタ:単一クラスタに登録された、混在する UC ビデオ エンドポイントおよび TelePresence エンドポイント

これは、TelePresence エンドポイントと UC ビデオ エンドポイントが同じクラスタに登録される単一クラスタ設計です。呼処理配置モデルは、WAN を介したクラスタリング、マルチサイト集中型呼処理、単一キャンパス設計など、任意の単一クラスタ設計にすることができます。

専用マルチクラスタ:別々の専用クラスタ上の UC ビデオ エンドポイントおよび TelePresence エンドポイント

これは、TelePresence エンドポイントが UC ビデオ エンドポイントとは異なるクラスタに登録されるマルチクラスタ設計です。呼処理配置モデルは、マルチサイト集中型またはマルチサイト分散型クラスタ設計にすることができます。このモデルは、同じ企業内に UC と TelePresence を配置するために、Cisco Unified CM 8.x のすべてのリリースでサポートされます。ただし、ビデオ MCU を使用しないポイントツーポイント ビデオ コールでの UC ビデオと TelePresence コールの相互運用性の新機能は、Unified CM 8.6 以降のリリースでのみサポートされます。

混在マルチクラスタ:マルチクラスタ分散型配置に混在する UC ビデオ エンドポイントおよび TelePresence エンドポイント

これは、マルチクラスタ設計であり、TelePresence エンドポイントは単一の Cisco TelePresence System Manager(CTS-Manager)によって処理される複数のクラスタに分散します。また、一部の TelePresence エンドポイントを UC エンドポイントと同じ Unified CM クラスタと共存させ(混在単一クラスタ モデル)、他の TelePresence エンドポイントを専用クラスタに登録し、両方のクラスタが TelePresence の単一の CTS-Manager によって処理されるという配置シナリオもあります。呼処理配置モデルは、マルチサイト、マルチクラスタ集中型、またはマルチサイト/マルチクラスタ分散型設計にすることができます。これは、専用マルチクラスタ モデルの側面を、すべてのエンドポイントが同じクラスタに登録される混在単一クラスタ モデルと組み合わせたハイブリッド モデルです。

マルチクラスタ モデルでは、Cisco Unified Communications Manager Session Management Edition(SME)もサポートされます。ただし、Session Management Edition は、マルチサイトの分散型呼処理配置モデルのバリエーションであり、一般に 1 つのフロントエンド システムを介して多数の Unified Communications システムを相互接続するために採用されるため、TelePresence ビデオの相互運用性に関して固有のガイドラインはありません。

ロケーション CAC の設計上の考慮事項と推奨事項

ロケーション CAC の設計の目標は、TelePresence エンドポイントの CAC を実行しないで UC エンドポイントの CAC を実行することです。この目標を達成するには、UC エンドポイントを、オーディオおよびビデオの帯域幅を追跡するロケーションに配置します。これは、WAN を介したメディア トラフィックがオーバーサブスクライブされないようにするためです。一方で、TelePresence エンドポイントは、無制限の帯域幅に設定されたロケーションに配置します。その結果、TelePresence トラフィックは CAC の対象ではありませんが、メディアの適切な QoS マーキングおよび WAN アップリンクの帯域幅プロビジョニングによって制御されます。

設計に関する推奨事項

次の設計上の推奨事項が、ロケーション CAC を使用する TelePresence ビデオの相互運用性ソリューションに適用されます。

TelePresence ビデオの相互運用性のロケーション CAC は、混在単一クラスタ、専用マルチクラスタ、混在マルチクラスタという 3 つの配置モデルすべてでサポートされます。

TelePresence エンドポイントは、常に、オーディオおよびビデオの帯域幅が無制限の、別の CAC ロケーション(hub_none ロケーションや同等のロケーションなど)に配置する必要があります。

UC エンドポイントと TelePresence エンドポイント間のクラスタ間コール転送および自動転送には、コール シグナリング パスを最適化して誤った帯域幅調整を回避する QSIG パス置換か、「クラスタ間トランク上のロケーションベースのコール アドミッション制御」が必要です。パス置換による QSIG トンネリングは、H.323 と SIP の両方のクラスタ間トランクで設定できます。クラスタ間トランクを介したロケーションベースのコール アドミッション制御の詳細については、 http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html にある『 Cisco Unified Communications Manager System Guide 』のコール アドミッション制御情報を参照してください。

クラスタ間トランクは、ビデオ帯域幅が無制限に設定された CAC ロケーションに関連付ける必要があり、コールの帯域幅の差し引きは、帯域幅が制限されたロケーションへのエンドポイントの関連付けから追跡されます。これは、混在マルチクラスタ配置と専用マルチクラスタ配置の両方に適用されます。

UC エンドポイントと TelePresence エンドポイント間では、ポイントツーポイント ビデオ コールのみがサポートされます。ビデオ MCU を使用できない場合、アドホック会議はサポートされません。

Cisco Unified CM 8. x では、UC ビデオ エンドポイントと TelePresence エンドポイントの DiffServ コード ポイント(DSCP)設定を区別するために、2 つの異なる、クラスタ全体の QoS サービス パラメータが使用されます。TelePresence では DSCP for Telepresence calls QoS パラメータが使用され、Cisco UC ビデオ エンドポイントでは DSCP for video calls QoS サービス パラメータが使用されます。

UC エンドポイントのみを配置し、TelePresence エンドポイントを配置しないサイトの場合、着信 CS4 とマークされたトラフィックに対応し、CS4 とマークされたメディアの QoS 処理を行うために、着信 WAN QoS 設定で CS4 DSCP クラスが AF41 QoS トラフィック クラスに追加されていることを確認します。このシナリオの詳細については、図 11-61 とそれに関連する設計上の考慮事項を参照してください。

UC TelePresence エンドポイントのみを配置し、UC エンドポイントを配置しないサイトの場合、着信 AF41 とマークされたトラフィックに対応し、AF41 とマークされたメディアの QoS 処理を行うために、着信 WAN QoS 設定で AF41 DSCP クラスが CS4 QoS トラフィック クラスに追加されていることを確認します。このシナリオの詳細については、図 11-64 とそれに関連する設計上の考慮事項を参照してください。

設計上の考慮事項

TelePresence ビデオの相互運用可能なコールのロケーション CAC を配置するときは、次の主要な要因を考慮してください。

「DSCP QoS マーキング」

「複数のサイト間でのコールの帯域幅アカウンティング」

「単一サイトでのコールの帯域幅アカウンティング」

DSCP QoS マーキング

TelePresence ビデオの相互運用可能なコールの DiffServ コード ポイント(DSCP)QoS マーキングは、非対称です。UC エンドポイントには AF41 が使用され、TelePresence エンドポイントには CS4 が使用されます。AF41 と CS4 は Unified CM でのデフォルト設定であり、これらのデフォルトの変更は、ネットワーク インフラストラクチャの QoS 設定と整合している必要があります(該当する場合)。TelePresence エンドポイントは、ビデオ コールを DSCP 値 CS4 でマークします。これは、デフォルトの DSCP for Telepresence calls 設定と整合性が取れています。UC エンドポイントは、コールを DSCP 値 AF41 でマークします。これは、デフォルトの DSCP for Video calls 設定と整合性が取れています。図 11-58 に、メディア マーキングと帯域幅アカウンティングを示します。

図 11-58 ロケーション CAC を使用したマルチサイト配置での帯域幅の差し引きとメディア マーキング

 

複数のサイト間でのコールの帯域幅アカウンティング

TelePresence ビデオの相互運用可能なコールのロケーション CAC では、図 11-58 に示すように、帯域幅は TelePresence エンドポイントのロケーションからではなく、UC エンドポイントのロケーションからのみ差し引かれます。これは、TelePresence エンドポイントが、エンドツーエンド TelePresence コールの帯域幅によって制限されないようにするための設計によるものです。AF41 QoS クラスの 1 つの側での帯域幅アカウンティングと CS4 QoS クラスのもう 1 つの側でのプロビジョニングというこの方法には、副次的な影響がいくつかあります。

ロケーション CAC は、AF41 クラス トラフィックの双方向メディアに対応します。ただし、非対称にマークされたフローでは、AF41 クラスの十分な割り当てられた帯域幅は一方向のみで使用されます。逆方向では、トラフィックは CS4 とマークされます。これは、追加の帯域幅使用量ではなく、単純にマーキングにおける違いを表します。マーキングにおけるこの違いと、TelePresence エンドポイントのロケーションではなく UC エンドポイントのロケーションでの帯域幅アカウンティングによって、次の 2 つの異なるコール シナリオで、QoS の設計上の考慮事項が発生します。

コール シナリオ 1:専用 UC サイトと共存サイト間のコール

図 11-59 に、マルチサイト配置を示します。ここでは、1 つのサイトには UC エンドポイントのみが含まれ、もう 1 つのサイトには UC エンドポイントと TelePresence エンドポイントの両方が共存しています。

図 11-59 ロケーション CAC を使用した専用 UC サイトと共存サイト間の帯域幅アカウンティング

 

1 つの CAC ロケーションに関連付けられた UC エンドポイントと別の CAC ロケーションに関連付けられた TelePresence エンドポイントが含まれたサイトがある場合、UC エンドポイントの CAC ロケーションでは、他のリモート UC エンドポイント ロケーションから TelePresence エンドポイントへのコールについて、着信 AF41 ストリームの帯域幅は差し引かれません。図 11-60 に、このケースを示します。

図 11-60 ロケーション CAC を使用した専用 UC サイトと共存サイト間の帯域幅の差し引きとメディア マーキング

 

図 11-60 の帯域幅アカウンティング エラーは回避できませんが、比較的軽微なものです。非対称の結果として、同量の CS4 帯域幅が使用されず、したがってまだ使用可能であるためです。このエラーは、CS4 および AF41 トラフィックにさまざまなパスがある状況でのみ問題となります。このケースで CS4 クラスで使用可能な帯域幅は、AF41 だけでなく、リンク上のすべてのトラフィック タイプで使用可能であることに注意する必要があります。したがって、WAN の使用が煩雑する時間に競合が AF41 クラスで発生する可能性がまだあります。

他のサイトにある TelePresence エンドポイントとのビデオ コールに参加することが予期される UC エンドポイントのみが含まれたサイトがある場合、非対称にマークされたメディアは UC のみのサイトの WAN アップリンクで予期されます。CS4 DSCP クラスが QoS で適切に処理されるようにするには、着信 WAN QoS 設定で CS4 DSCP を AF41 QoS トラフィック クラスに追加する必要があります。そうすることで、この着信 CS4 とマークされたトラフィックに対応し、適切な QoS 処理を行います。ここでは、追加される QoS トラフィック クラスに対して追加の帯域幅は必要ありません。図 11-61 に、このケースを示します。

図 11-61 ロケーション CAC を使用した専用 UC サイトと共存サイト間のコールの適切な QoS 処理のためのメディア マーキング

 

コール シナリオ 2:専用 TelePresence サイトと共存サイト間のコール

図 11-62 に、マルチサイト配置を示します。ここでは、1 つのサイトには TelePresence エンドポイントのみが含まれ、もう 1 つのサイトには UC エンドポイントと TelePresence エンドポイントの両方が共存しています。

図 11-62 ロケーション CAC を使用した専用 TelePresence サイトと共存サイト間の帯域幅アカウンティング

 

TelePresence エンドポイントと UC エンドポイントの両方が含まれるサイトで TelePresence コールが UC エンドポイント ロケーションに到達する場合、AF41 QoS クラスについて帯域幅は差し引かれますが、着信メディアは CS4 とマークされます。この CS4 トラフィックは、ローカル TelePresence エンドポイントの WAN アップリンクのプロビジョニングで対応されません。前のケースと同様に、このアカウンティング エラーも回避できませんが、比較的軽微なものです。非対称の結果として、同量の AF41 帯域幅が使用されず、したがってまだ使用可能であるためです。このエラーは、CS4 および AF41 トラフィックにさまざまなパスがある状況でのみ問題となります。この場合に AF41 クラスで使用可能な帯域幅は、CS4 だけでなく、リンク上のすべてのトラフィック タイプで使用可能であることに注意する必要があります。したがって、WAN の使用が煩雑する時間に競合が CS4 クラスで発生する可能性がまだあります。図 11-63 に、このケースを示します。

図 11-63 ロケーション CAC を使用した専用 TelePresence サイトと共存サイト間の帯域幅の差し引きとメディア マーキング

 

UC エンドポイント サイトとのビデオ コールに参加することが予期される TelePresence のみのサイトの場合、非対称にマークされたメディアは TelePresence のみのサイトの WAN アップリンクで予期されます。AF41 DSCP クラスが QoS で適切に処理されるようにするには、着信 WAN QoS 設定で AF41 DSCP を CS4 QoS トラフィック クラスに追加する必要があります。そうすることで、この着信 AF41 とマークされたトラフィックに対応し、適切な QoS 処理を行います。ここでは、追加される QoS トラフィック クラスに対して追加の帯域幅は必要ありません。図 11-64 に、このケースを示します。

図 11-64 ロケーション CAC を使用した専用 TelePresence サイトと共存サイト間のコールの適切な QoS 処理のためのメディア マーキング

 

単一サイトでのコールの帯域幅アカウンティング

UC エンドポイントと TelePresence エンドポイントが同じ物理サイト内にある場合、設計ガイドラインに従って、これらは別々の CAC ロケーションに関連付けられたままです。同じ物理サイト内の TelePresence エンドポイントと UC エンドポイント間のコールの場合、これはロケーション間コールであるため、帯域幅は UC エンドポイントの CAC ロケーションから差し引かれます。ただし、デバイスは同じ物理サイト内にあるため、メディアは WAN を通過しません。図 11-65 に、このケースを示します。

図 11-65 ロケーション CAC を使用した同じサイト内の UC エンドポイントと TelePresence エンドポイント間のコールの帯域幅の差し引きとメディア マーキング

 

これは、TelePresence エンドポイントと UC エンドポイントが同じ物理サイトまたはキャンパス内にあるときに、お互いをコールするこれらのエンドポイントのロケーション CAC の制限です。この制限は、ロケーション CAC の現在の機能と、TelePresence エンドポイントを帯域幅が無制限の別の CAC ロケーションに配置するという要件によるものです。

Session Management Edition の配置については、「ロケーション CAC を使用する CAC ドメインを管理する Session Management Edition」の項のガイドラインに従ってください。

RSVP CAC の設計上の考慮事項と推奨事項

TelePresence ビデオの相互運用性の RSVP ソリューションでは、目標は、エンドツーエンド UC エンドポイント コールと TelePresence ビデオの相互運用性コールの両方について RSVP CAC を実行することです。一方で、エンドツーエンド TelePresence コールによって RSVP(RSVP Agent)が呼び出されないようにもします。これは、現在はサポートされておらず、特定の TelePresence 機能に障害が発生する可能性があるためです。

RSVP 配置での TelePresence ビデオの相互運用性は簡単に実現でき、ロケーション CAC ソリューションよりも CAC サポートが向上します。ただし、いくつかの設計ルールと配置モデルに従います。サポートされている設計は、混在単一クラスタ設計と専用マルチクラスタ設計です。混在マルチクラスタ設計は推奨されません。これは、クラスタ間のエンドツーエンド TelePresence コールによって RSVP が呼び出されないようにし、相互運用可能なその他のすべてのポイントツーポイント コール シナリオによって RSVP が呼び出されるようにするという設定の複雑さがあるためです。

RSVP アーキテクチャおよび一般的な設計と配置の考慮事項の詳細については、「リソース予約プロトコル(RSVP)を使用した Unified Communications アーキテクチャ」の項を参照してください。この項では、RSVP に関する TelePresence ビデオの相互運用性に固有の推奨事項と考慮事項について説明するため、この項を単独で読む前に、RSVP の原理とソリューションについて理解しておくことが重要です。

設計に関する推奨事項

次の設計上の推奨事項が、コール アドミッション制御に RSVP を使用する TelePresence ビデオの相互運用性ソリューションに適用されます。

ロケーションベースの RSVP は、混在単一クラスタ設計と専用マルチクラスタ設計でサポートされています。すでに説明したように、混在マルチクラスタ設計は使用できますが、トランク、ダイヤル プラン、およびロケーションベースの RSVP ポリシーの複雑な設計が必要になります。そのため、混在マルチクラスタ設計は推奨されず、この設計上の推奨事項では取り上げません。

ローカル RSVP と RSVP SIP プレコンディションは、この章の関連する項のガイドラインに従って設計および設定されている場合は、どちらもクラスタ間コールに対してサポートされます。

RSVP を使用する TelePresence ビデオの相互運用性ソリューションを設計するときは、TelePresence から TelePresence へのコールによって RSVP が呼び出されないようにします。この機能は、現在はサポートされておらず、特定の TelePresence 機能に障害が発生する可能性があるためです。ただし、UC ビデオ エンドポイントとの間の TelePresence コールでは、RSVP を呼び出す必要があります。これを実行するには、次のようにします。

TelePresence エンドポイントは、UC エンドポイントとは別の CAC ロケーション内にあります。

TelePresence ロケーションでは、他の TelePresence ロケーションおよび固有のロケーションとのロケーション ペアリングについて、RSVP ポリシーは no reservation に設定されています。ロケーション ペアの RSVP ポリシーの詳細については、「RSVP ポリシー」の項を参照してください。

TelePresence ロケーションでは、UC ビデオ エンドポイントのロケーションとのロケーション ペアリングについて、RSVP ポリシーは mandatory または mandatory video desired に設定されています。

専用マルチクラスタ配置の場合、クラスタ間トランクに、UC エンドポイントのロケーション間および TelePresence エンドポイントのロケーション間の RSVP ポリシー ペアリングが必要です。

専用 TelePresence クラスタの場合、専用 UC エンドポイント クラスタを指すクラスタ間トランクに、 mandatory または mandatory video desired に設定された TelePresence エンドポイントとの RSVP ポリシー ロケーション ペアリングが必要です。TelePresence クラスタを指すクラスタ間トランクには、 no reservation に設定された TelePresence エンドポイントとの RSVP ポリシー ロケーション ペアリングが必要です。

専用 UC エンドポイント クラスタの場合、専用 UC クラスタと TelePresence クラスタの両方を指すクラスタ間トランクに、 mandatory または mandatory video desired に設定された UC エンドポイントとの RSVP ポリシー ロケーション ペアリングが必要です。

設計上の考慮事項

TelePresence ビデオの相互運用可能なソリューションの RSVP CAC を配置するときは、次の主要な要因を考慮してください。

RSVP が UC エンドポイントと TelePresence エンドポイントの両方の CAC を実行する

ロケーション CAC と異なり、RSVP は、TelePresence ビデオの相互運用可能なコールの TelePresence エンドポイントと UC エンドポイントの両方に対して CAC を実行します。また、エンドポイント QoS マーキングの上書きも行うので、エージェントからエージェントへの正しい QoS マーキングが行われます。図 11-66 に、この点を示します

図 11-66 RSVP CAC を使用したマルチサイト配置での帯域幅の差し引きとメディア マーキング

 

図 11-66 は、TelePresence エンドポイントと Cisco Unified IP Phone 9900 シリーズ ビデオ電話間のコールを示しています。ここでは、RSVP CAC に対して RSVP Agent が呼び出されます。2 つの重要な点を次に示します。

RSVP Agent は、RSVP Agent 間でメディアが DSCP 値 AF41 で対称的にマークされるように、RTP メディア トラフィックを再マーキングします。この値は、 DSCP for Video calls 設定と整合性が取れています。これにより、エンドポイント間で対称的にマークされた RTP トラフィックが提供されます。これは、ロケーション CAC ソリューションでは実現できません。

RSVP は、UC エンドポイントと TelePresence エンドポイントの RSVP Agent 間のメディア パスで帯域幅を差し引きます。これにより、TelePresence ビデオの相互運用性コールの両方向のオーディオ ストリームおよびビデオ ストリームに CAC が提供されます。これも、ロケーション CAC では本質的に実現できません。

混在単一クラスタ配置で同じ物理サイト内に配置されたエンドポイント間のコールに対して RSVP を使用しない

混在単一クラスタ設計を配置する場合、TelePresence エンドポイントと UC ビデオ エンドポイントは同じ Unified CM クラスタに登録され、同じ物理サイトまたはキャンパスに配置されるため、これらのデバイス間のコールに対して RSVP を使用しないことが重要です。UC エンドポイントのロケーションと TelePresence エンドポイントのロケーション間の RSVP ポリシー ロケーション ペアは、この場合は no reservation に設定する必要があります。このことを図 11-67 に示します。

図 11-67 同じサイト内の UC エンドポイントと TelePresence エンドポイント間のコールの RSVP ポリシー設定

 

図 11-67 は、同じ物理サイト内だが別々の CAC ロケーションにある TelePresence エンドポイントと Cisco Unified IP Phone 9900 シリーズ ビデオ電話を示しています。同じ物理サイトまたはキャンパス内の TelePresence エンドポイントと UC エンドポイント間のコールによって RSVP が呼び出されないように、ロケーション ペア ポリシーは no reservation に設定されています。RTP ストリーミングが非対称であることに注意してください。このことは、通常は LAN 上で重要な問題とはなりません。

異なるクラスタ内のエンドポイント間のコールに対しては RSVP が使用される

専用マルチクラスタ配置では、UC エンドポイントと TelePresence エンドポイントが同じ物理サイト内に配置されている場合でも、RSVP を呼び出す必要があります。これは RSVP Agent リソースを利用しますが、メディアは WAN アップリンクを介してルーティングされません。図 11-68 に、この点を示します。

図 11-68 RSVP CAC を使用したマルチクラスタ、単一サイト配置での帯域幅の差し引きとメディア マーキング

 

図 11-68 の RSVP Agent および WAN エッジ ルータはすべて、ここで示されているように、共存させるか分離することができます。別々のクラスタに登録された複数の RSVP Agent の共存の詳細については、「RSVP Agent のための複数クラスタによる単一プラットフォームの共有」の項を参照してください。

Session Management Edition の配置のガイドライン

Session Management Edition の配置については、「RSVP 配置での Unified CM Session Management Edition」の項に記載されている同じガイドラインに従ってください。ただし、RSVP は混在マルチクラスタ配置では推奨されないことに留意してください。

Unified CM Session Management Edition の配置に関するコール アドミッション制御の設計上の推奨事項

Cisco Unified Communications Manager Session Management Edition(SME)には、トランクツートランクの音声コールとビデオ コールを許可するために使用できるコール アドミッション制御の 2 つの主要な形式があります。1 つはロケーション コール アドミッション制御(CAC)であり、もう 1 つは RSVP 対応ロケーションを使用するリソース予約プロトコル(RSVP)です。この項では、Session Management Edition の配置に固有の設計ガイドラインとベスト プラクティスについて説明します。ロケーション CAC、ロケーションベースの RSVP、または RSVP SIP プレコンディションの基本的な機能については説明しません。次の設計ガイドラインを理解する前提条件として、この章の該当する項を理解しておくことを強く推奨します。

この項では、「CAC ドメイン」という用語は、ロケーション CAC や RSVP などの単一 CAC メカニズムにより管理されるネットワークの領域を表すために使用します。ロケーション CAC に関連する場合、CAC ドメインは単一クラスタ(リーフ クラスタまたは Session Management Edition クラスタ)によって管理されます。ロケーション CAC は単一クラスタのみを認識し、ロケーション情報はクラスタ間で通信されないためです。クラスタがクラスタ間でロケーション情報を通信することを可能にする、「クラスタ間トランクを介したロケーションベースのコール アドミッション制御」と呼ばれるメカニズムがありますが、使用範囲が限定されるため、適用される場合に特別に記述します。

ロケーション CAC を使用する CAC ドメインを管理する Session Management Edition

Unified CM Session Management Edition では、ロケーション CAC を使用して、リーフ クラスタ、サードパーティ IP PBX、および TDM ゲートウェイの代わりに限定された方法で帯域幅を管理できます。ロケーション CAC は、異なるロケーションにあるデバイス間で発信された音声およびビデオ コール用の帯域幅を 1 つのクラスタ内で追跡する、基本のスタティック CAC メカニズムです。ロケーションは、単一の WAN アップリンクが存在する物理的なサイトと同等です。ロケーション CAC では、クラスタをまたいだ通信は行われません。つまり指定されたクラスタ内にだけ適用されます。したがって、ロケーション CAC を使用したマルチクラスタ分散型 Unified CM 配置のサポートには多くの制限があります。ただし、Unified CM Session Management Edition は、メディアが、キャンパスに配置されているリーフ クラスタ デバイスから発信されるか、そこで終端するトランクまたはトランクのセットにロケーションを関連付けることでロケーション CAC を活用できます。

図 11-69 に、2 つのキャンパス サイト用の CAC ドメインを管理する Unified CM Session Management Edition の例を示します。左のキャンパス サイトで同じ場所にある 2 つのリーフ クラスタは、同じ物理キャンパスのエンドポイントとデバイスを管理します。別のリーフ クラスタは、別のキャンパス配置にあります。サイト間およびクラスタ間の発信は、処理のために Session Management Edition に送信されます。この場合、Session Management Edition クラスタには 2 つのロケーションが設定されています。リーフ クラスタ 1 と 2 の両方のトランクに関連付けられた LOCATION 1 と、リーフ クラスタ 3 のトランクに関連付けられた LOCATION 2 です。

この設計では、Unified CM Session Management Edition は、ロケーションをそれぞれのキャンパスでリーフ クラスタを指すトランクに関連付けることで、キャンパス サイトの WAN エッジ アップリンク用の CAC を管理します。

図 11-69 Unified CM Session Management Edition による 2 つのキャンパス サイト用の CAC ドメイン管理

 

リーフ 1 からリーフ 2 へのすべてのコールは、コール アドミッション制御の対象ではありません。これは、リーフ 1 とリーフ 2 のトランクが両方とも Session Management Edition 構成で同じロケーションにあるためです。リーフ 3 とリーフ 1 または 2 の間のすべてのコールは、該当するロケーションの音声またはビデオ プールから差し引かれます。

ロケーション CAC を使用する CAC ドメインを管理するリーフ クラスタ

Session Management Edition の設計では、リーフ クラスタはロケーション CAC を使用して独自の CAC ドメインを維持および管理することもできます。この場合、Session Management Edition はリーフ クラスタのアドミッション制御管理に対して透過的です。これらの設計では、ロケーション CAC が各クラスタで正しく機能するようにするために、いくつかのガイドラインに従うことが重要です。

単一の WAN エッジの帯域幅を複数のクラスタで保護することは推奨されません。これが発生する可能性があるのは、異なる Unified CM リーフ クラスタに登録されているが、同じ物理サイトに存在し、サイト間発信に同じ WAN エッジ アップリンクを利用するエンドポイントがある設計です。この場合にロケーション CAC が使用されると、各クラスタによって管理される帯域幅はクラスタ間で通信されません。そのため、このシナリオを効果的に管理する唯一の方法は、クラスタ間の WAN エッジ帯域幅を分割して、各クラスタで WAN エッジ帯域幅のそれぞれの部分を管理することです。ただし、メディアが WAN エッジを通過せず、サイトの LAN 上に残る場合に、クラスタ間コールに対して帯域幅の差し引きが発生する可能性があります。これにより、WAN エッジはオーバーサブスクライブされませんが、WAN エッジ帯域幅の使用が非効率であるため、推奨されません。

クラスタ間コールでは、コール転送または転送の場合に帯域幅の二重カウントを避けることが重要です。コールが転送されるか、発信元リーフ クラスタおよび発信元ロケーションに戻される場合がこれに該当します。このようなコール シナリオでは、転送する、または自動転送するリーフ クラスタでシグナリングがヘアピンされます。図 11-70 および図 11-71 でこのシナリオを説明します。

図 11-70 クラスタ間コールの CAC を管理するリーフ クラスタ

 

図 11-70 では、ロケーション B(ブランチ 1、クラスタ 1)のデバイスおよびロケーション F(ブランチ 2、クラスタ 2)の間でコールが確立されます。クラスタ 1 では 80 kbps がロケーション B から差し引かれ、クラスタ 2 では 80 kbps がロケーション F から差し引かれました(クラスタ間の G.711 音声コール)。Session Management Edition へのクラスタ間トランク(ICT)および Session Management Edition からリーフ クラスタへのクラスタ間トランク(ICT)は、ロケーション帯域幅が無制限(デフォルトであり設定不可)に設定されている Hub_none ロケーションに配置されていることに注意してください。ただし、シグナリングとは異なり、メディアは 2 ブランチ間で直通であるため、ロケーション CAC を使用したそれぞれのブランチの WAN エッジのみを保護することが重要です。

図 11-71 転送されたコールの CAC を管理するリーフ クラスタ

 

図 11-71 では、ロケーション F のエンドポイントは、ロケーション B(ブランチ 1、クラスタ 1)の別のエンドポイントにコールを転送します。この時点で、クラスタ 2 は、そのエンドポイントがコール シグナリング処理中ではないため、ロケーション F から帯域幅の差し引きを削除します。ただし、クラスタ 2 からクラスタ 1 への発信は、クラスタ 2 のトランクをまたいで Session Management Edition にヘアピンされ、Session Management Edition と次にクラスタ 1 の両方による発信と見なされます。したがって、この場合クラスタ 1 は、ロケーション B のエンドポイントへの発信用にさらに 80 kbps の帯域幅を差し引きます。つまり、ロケーション B の 2 つのデバイス間コールに対して、ロケーション B から合計 160 kbps の帯域幅が差し引かれることになります。この非効率なコール シグナリング パスによって、次の状況が発生します。ロケーション B の 2 つのエンドポイントにはお互いに対して確立されたメディアがあるため、実際にはメディアは WAN エッジを通過しないときに、クラスタ 1 はロケーション B のエンドポイントと Session Management Edition へのクラスタ間トランクの間で確立された 2 つの別々のコールがあると認識します。これは、コール シグナリングがクラスタ 2 でヘアピンされていることが原因です。

ロケーション CAC がリーフ クラスタで管理される場合、この帯域幅の二重カウントのシナリオを回避するには、次の 2 つの方法が効果的です。

「クラスタ間トランク上のロケーションベースのコール アドミッション制御」 Phantom ロケーション とも呼ばれます)

「クラスタ間トランクを介した QSIG パス置換」

クラスタ間トランク上のロケーションベースのコール アドミッション制御

コールがクラスタ間トランク(ICT)を介してクラスタ間で発信され、同じクラスタの同じロケーションまたはサイトにヘアピンされて戻されると、メディアは同じサイトまたはロケーション内の 2 つのエンドポイント間で交換されますが、Unified CM ロケーション コール アドミッション制御(CAC)の以前の設計では、ロケーションの帯域幅は発信コールで 1 回、着信コールで再度の 2 回差し引かれました。その結果は帯域幅使用量を正しく反映しておらず、十分な帯域幅がまだ存在していた場合に、最終的にサイトまたはロケーションへの、あるいはサイトまたはロケーションからの発信拒否の原因となっていました。

帯域幅計算の問題を解決するために、Phantom ロケーション機能によって、Unified CM はロケーション情報(ロケーション レコードおよびロケーション名のプライマリ キー ID(PKID))を独自の情報要素(IE)として、H.323 または SIP プロトコルで ICT を介して発信側と着信側の間で渡すことができます。したがって、各クラスタは ICT のロケーション情報ではなく、発着信側またはエンドポイントの正確なロケーション情報を認識します。(使用例については、図 11-72 および図 11-73 を参照してください)。

Phantom ロケーションとして指定された Unified CM ロケーションが、この種のアプリケーション用の ICT に対して作成されます。ロケーション サーバは、Phantom ロケーションに割り当てられたデバイス用の帯域幅を差し引きません。Phantom ロケーションに割り当てられた ICT などのデバイスは、クラスタをまたいで接続されたデバイスの正確なロケーションを使用します。

図 11-72 に、ロケーション B(ブランチ 1、クラスタ 1)のデバイスおよびロケーション F(ブランチ 2、クラスタ 2)の間で確立されるコールのシナリオを示します。クラスタ 1 では 80 kbps がロケーション B から差し引かれ、クラスタ 2 では 80 kbps がロケーション F から差し引かれました(クラスタ間の G.711 音声コール)。コール シグナリングがクラスタ 1 から Session Management Edition ロケーション B に送信されると、情報は情報要素内で送信され(図 11-72 のステップ 1)、この同じ情報が Session Management Edition からクラスタ 2 に再度送信されます(図 11-72 のステップ 2)。ロケーション F のデバイスに関する情報は、同じ方法で Session Management Edition を介して、クラスタ 2 からクラスタ 1 へも送信されます。この例ではロケーション B の情報のみが示されていますが、このロケーション情報交換は両方向で行われることに留意してください。

図 11-72 Phantom ロケーション CAC を使用したクラスタ間コール

 

Session Management Edition へのクラスタ間トランク(ICT)および Session Management Edition からリーフ クラスタへの ICT が、Phantom ロケーションに存在することに注意してください。Phantom ロケーションでは、ロケーション帯域幅は無制限(CAC に対して実質的に追跡されない)に設定され、ロケーション B の発信側に関するロケーション情報は ICT をまたいで送信されます。

この時点で、クラスタ 2 は Session Management Edition から受信したコールがロケーション B に関連付けられることを認識します。クラスタ 2 はこの情報のみを使用して、ICT 上のその特定コールをそのロケーション ID に関連付けて、ロケーション B に対して一切帯域幅の差し引きを処理しません。

図 11-73 に、転送されたコールのケースを示します。転送後、クラスタ 2 は ICT 上のコールをヘアピンして、クラスタ 1 にロケーション B の情報を送信します(Session Management Edition 経由。図 11-73 のステップ 3 および 4)。ロケーション B の情報は元々クラスタ 1 から受信したものです(Session Management Edition 経由。図 11-73 のステップ 1 および 2)。これにより、クラスタ 1 は、クラスタ 2 から受信する着信コールがクラスタ 1 のロケーション B のデバイスから発信されたことを認識できます。これにより、クラスタ 1 は、同じロケーションの 2 つのエンドポイントに対する 2 つのコールのために差し引かれた帯域幅を戻せるようになります。

図 11-73 Phantom ロケーション CAC を使用した転送されたコール

 

クラスタ間トランクを介したロケーションベースのコール アドミッション制御の詳細については、次のサイトで入手可能な『 Cisco Unified Communications Manager System Guide 』のコール アドミッション制御の項を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

クラスタ間トランクを介した QSIG パス置換

Unified CM リーフ クラスタ内の電話間のコール バック(通話中/無応答)などの機能を提供する以外に、QSIG はパス置換も提供します。パス置換によって、たとえばコールが発信元クラスタに戻されるときに、クラスタ間のコール シグナリングが最適化されます。このシグナリング最適化によって、未使用の帯域幅をクラスタのロケーションベースのコール アドミッション制御の帯域幅プールに返すことも可能になります。


) ジオロケーションおよび関連する論理パーティション機能は、QSIG 対応トランクではサポートされません。


図 11-74図 11-75、および図 11-76 に、さまざまなコール シナリオの QSIG パス置換を示します。

図 11-74 では、電話機 1000 が電話機 4000 に発信し、次のイベントが発生します。

シグナリング コール レッグが、1XXX クラスタから Session Management Edition を介して 4XXX クラスタへ確立されます。

コール アドミッション制御により、1XXX から 4XXX へのコールの帯域幅が差し引かれます。

RTP メディア パスが、WAN を介して 2 つの電話機間で直接確立されます。

図 11-74 クラスタ間の QSIG パス置換:最初のコール

 

図 11-75 では、電話機 4000 が電話機 1001 にコールを転送し、次のイベントが発生します。

新しいシグナリング コール レッグが、4XXX クラスタから Session Management Edition を介して 1XXX クラスタへ確立されます。

コール アドミッション制御により、4XXX から 1XXX へのコールの帯域幅が差し引かれます。

結果のメディア パスが、電話機 1000 と電話機 1001 の間で直接確立されます。

図 11-75 クラスタ間の QSIG パス置換:転送されたコール

 

図 11-76 に示すように、トロンボーン コールの QSIG パス置換によって冗長なシグナリングはクリアされ、未使用のコール アドミッション制御の帯域幅は解放されます

図 11-76 クラスタ間の QSIG パス置換:最適化されたシグナリング パス

 

Session Management Edition を使用した QSIG の配置では、QSIG アプリケーション プロトコル データ ユニット(APDU)で送信される着信者番号、発信者番号、および転送番号は、トランスレーション パターンおよびトランスフォーメーション パターンによって変更されません。QSIG 対応トランクを使用する Session Management Edition の配置の場合、QSIG APDU で送信される番号(特に着信番号。ユーザのダイヤリング動作はクラスタごとに異なる場合があるため)は、QSIG ベースの機能の提供に影響する場合があります。コール バックやパス置換などの QSIG 機能で所定のコールの着信者番号と発信者番号を使用して、それらの機能を呼び出すことができるかどうか、またそのタイミングを判断することができます。QSIG 機能呼び出しの着信者番号と発信者番号の依存性を回避するには、QSIG 機能に適用される Unified CM サービス パラメータの次の値を設定します。

クラスタ全体のパラメータ(機能:パス置換)

QSIG プロトコルでは内線番号または電話番号は渡されますが、変換または挿入された番号は渡されないため、定型ダイヤル プランを使用する Unified Communications ネットワークではパス置換などの QSIG 機能を使用します。Unified Communications ネットワークで、ダイヤル プランで一意でない電話番号(または可変のユーザ ダイヤリング手順、あるいはその両方)が使用される場合、PINX ID を使用してコールを再ルーティングする必要があります。PINX ID は、Unified Communications ネットワーク内のすべての PINX(つまり、すべての QSIG 対応 Unified Communications システム)の一意の電話番号です。パス置換機能によって、着信者番号または発信者番号の代わりに、PINX ID(設定されている場合)が使用されます。PINX ID を設定するには、Cisco Unified Communications Manager の管理ページで次のタスクを実行します。

パス置換機能の PINX ID サービス パラメータを設定します。(パス置換機能では、Cisco CallManager サービスが使用されます)。

PINX ID だけを含めるコール ピックアップ グループを作成します。

Cisco Unified Communications Manager には Path Replacement Calling Search Space サービス パラメータがあるため、連携している PINX が発信 SETUP メッセージを要求側の PINX に送信するために使用するコーリング サーチ スペースを設定できます。Path Replacement Calling Search Space サービス パラメータの値を指定しないと、要求側の PINX は、そのコールに関係しているエンド ユーザのコーリング サーチ スペースを使用します。

QSIG トランクを介したパス置換の詳細については、次のサイトで入手可能な『 Cisco Unified Communications Manager System Guide 』の IP テレフォニー プロトコルの項のパス置換情報を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

コール転送

Cisco Unified Communications Manager では、再ルーティングによるコール転送と転送スイッチングによるコール転送がサポートされます。再ルーティングによるコール転送が発生すると、発信側の PINX はコールの受信者から、コールを別のユーザに転送するための要求を受信します。Clusterwide Parameters (Feature - Forward) のデフォルト設定では、Call Forward by Forward Switching を使用します(Forward By Reroute は無効になります)。Session Management Edition の配置に対する一般的な推奨事項として、Unified Communications ネットワークに定型ダイヤル プランを使用しない場合には、転送スイッチングによるコール転送とパス置換を使用して、開始側と終端側のユーザ間のパスを最適化してください。

QSIG コール転送の詳細については、次のサイトで入手可能な『 Cisco Unified Communications Manager System Guide 』の IP テレフォニー プロトコルの項のコール転送情報を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

RSVP 配置での Unified CM Session Management Edition

Unified CM Session Management Edition を、クラスタ間で SIP プレコンディションのサポートあり、またはサポートなしの複数の RSVP 配置に配置できます。Unified Communications の設計での RSVP の概要について、および次の内容を理解する前提条件として、「リソース予約プロトコル(RSVP)を使用した Unified Communications アーキテクチャ」の項を参照してください。これには、Unified CM RSVP 対応ロケーションおよび RSVP SIP プレコンディションに関する詳細な項が含まれています。

RSVP SIP プレコンディション サポートのないリーフ クラスタを使用した Session Management Edition の設計

リーフ クラスタ内でローカルに独自の CAC サポートを維持するリーフ クラスタを使用した Unified CM Session Management Edition を配置できます。リモート サイトの独自のデバイスに対してリーフ クラスタが独自の CAC メカニズムを管理する配置であるか、またはそれらのリーフ クラスタがキャンパス配置内にあり、クラスタ内コール(リーフ クラスタ内にとどまっているコール)に CAC を必要としない配置である場合、Session Management Edition を活用して、RSVP を使用したそれらのリーフ クラスタ間の音声およびビデオ コール(クラスタ間コール)用の CAC を管理できます。これらの場合、Session Management Edition は、Cisco RSVP Agent を利用してリーフ クラスタ間でリンクをまたいだ CAC を処理しますが、リーフ クラスタがクラスタ内コール用に管理するリンクの CAC は管理しません。

要件

クラスタ内コールは、リーフ クラスタ CAC によって管理されます。

クラスタ間コールは、Session Management Edition の RSVP 対応ロケーション CAC によって管理されます。

Session Management Edition により管理されたクラスタ間コールの WAN 帯域幅を、リーフ クラスタにより管理されたクラスタ内コールの WAN 帯域幅と共有しないことを強く推奨します。同じ WAN リンクからの帯域幅が 2 つの別々の CAC メカニズムによって管理される場合、2 つの別々の CAC メカニズムはお互いを認識しないため、帯域幅の二重カウントの可能性があります。

図 11-77 に、クラスタ間接続のために Session Management Edition を介して相互に接続する異なるリージョン サイトに配置された、2 つのリーフ クラスタを示します。リーフ クラスタ 1 はロケーション CAC を使用してその CAC ドメインのリモート サイトを管理し、リーフ クラスタ 2 は RSVP を使用してその CAC ドメインのリモート サイトを管理しています。この場合、Session Management Edition は RSVP 対応ロケーションを利用し、リモート RSVP Agent を使用してリーフ クラスタ間で CAC ドメインを管理します。リモート RSVP Agent は、Session Management Edition に登録された標準の RSVP Agent であり、メディア リソース グループ(MRG)およびメディア リソース グループ リスト(MRGL)機能によってリーフ クラスタ トランクに関連付けられますが、物理的にはキャンパス サイトに配置されるかリーフ クラスタと共存するため、Session Management Edition クラスタからは「リモート」である場合があります。これらの RSVP Agent は、リーフ クラスタを相互接続し、RSVP のサポートが有効化されたヘッドエンド ネットワーク WAN にある必要があります。

図 11-77 SIP プレコンディション サポートのないリーフ クラスタを使用した Session Management Edition の配置

 

リーフ 1 とリーフ 2 の間のコール セットアップで、コール フローは次のように動作します(図 11-78 を参照)。

1. リーフ 1 によって Session Management Edition へのコールがセットアップされます。これは、H.323 または SIP クラスタ間トランクを介して実行されます。QSIG パス置換のサポートは、Unified CM 8.5 よりも前の H.323 および Unified CM 8.5 以降のリリースでの SIP に適切です。

2. Session Management Edition は、リーフ 1 からコールを受信し、2 つの RSVP Agent を割り当てます。RSVP Agent は、メディア リソース グループおよびリスト機能によってトランクに関連付けられます(図 11-77 を参照)。割り当てられたあと、RSVP Agent は、その間のパス上の帯域幅を予約します。

3. 帯域幅の要求が成功した場合、コールは Session Management Edition から、SIP または H.323 クラスタ間トランク上のリーフ 2 まで拡張されます。予約が失敗した場合、コールはリーフ 2 まで拡張されず、Session Management Edition の呼処理の設定に応じて、コールは別の場所に拡張されるか、リーフ 1 から切断されます。

図 11-78 SIP プレコンディション サポートのないリーフ クラスタを使用した Session Management Edition の配置のコール フロー

 

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

ステップ 3 でコールがリーフ 2 に拡張される場合、リーフ 2 はロケーション CAC または RSVP を、そのコール レッグに対するアドミッション制御として使用できます。図 11-78 のように RSVP を使用する場合、リーフ 2 は RSVP Agent を、Session Management Edition を指す SIP トランクに関連付け、別の RSVP Agent を着信側エンドポイントに関連付けます。

リーフ クラスタが RSVP をローカルで実行しており、SIP プレコンディションを使用していない場合、Session Management Edition のリモート RSVP Agent と、Session Management Edition に接続されたトランクに関連付けられたリーフ クラスタの RSVP Agent は、同じルーティング プラットフォーム上に共存できます。詳細については、「RSVP Agent のための複数クラスタによる単一プラットフォームの共有」を参照してください。

SIP プレコンディション サポートのあるリーフ クラスタを使用した Session Management Edition の設計

RSVP を使用して CAC ドメインを管理し、RSVP SIP プレコンディションをサポートするリーフ クラスタを使用した Unified CM Session Management Edition を配置することもできます。この場合、Session Management Edition は、SIP プレコンディションを使用したクラスタ間トランクを有効にします。また、RSVP SIP プレコンディションをリーフ クラスタからリーフ クラスタへ渡し、エンドツーエンドの RSVP Agent 配置を提供します。

要件

Unified CM 8.0 以降のリリース(可能であれば、Unified CM 8.6.1 以降)を使用するリーフ クラスタ

Unified CM RSVP 対応ロケーションを使用するリーフ クラスタによって管理されるクラスタ内コール

RSVP SIP プレコンディションをリーフ クラスタからリーフ クラスタへ渡すように設定された SIP クラスタ間トランク(ICT)を使用する Session Management Edition によって管理されるクラスタ間コール

転送および自動転送されたコールのコール シグナリングを最適化するために すべての SIP クラスタ間トランク(ICT)で有効にされたパス置換を使用する QSIG(Unified CM 8.5 以降のリリースが必要)

図 11-79 に、説明したソリューションを示します。ここでは、リーフ クラスタにクラスタ内コール用の Unified CM RSVP 対応ロケーションがあり、Session Management Edition および両方のリーフ クラスタで設定された SIP ICT が RSVP SIP プレコンディションを使用して有効になっています。Session Management Edition は SIP プレコンディションをリーフ Unified CM からリーフ Unified CM に渡し、リーフ Unified CM はそれらのプレコンディションをブランチ RSVP Agent に渡します。このようにして、エンドツーエンド RSVP 予約を複数のクラスタ境界を越えてブランチからブランチへ直接提供します。

図 11-79 SIP プレコンディション サポートのあるリーフ クラスタを使用した Session Management Edition の配置

 

混合リーフ クラスタを使用した Session Management Edition の設計(SIP プレコンディション サポートのありとなし)

Unified CM Session Management Edition は、混在環境をサポートすることもできます。1 つのトランクでは、ローカルでの RSVP および RSVP SIP プレコンディションをサポートするリーフ クラスタへのトランクで RSVP SIP プレコンディションをサポートし(図 11-80 のリーフ 2 の例を参照)、別のトランクでは、Session Management Edition は RSVP Agent を関連付け、RSVP SIP プレコンディションをサポートしないクラスタへのトランクに対して RSVP をローカルに実行します(図 11-80 のリーフ 1 を参照)。

図 11-80 混合リーフ クラスタを使用した Session Management Edition の設計(SIP プレコンディション サポートのありとなし)

 

RSVP Agent のための複数クラスタによる単一プラットフォームの共有

場合によっては、複数の Unified CM クラスタをまたいで RSVP Agent をサポートする単一のルータ プラットフォームを共有する必要がある可能性があります。この場合、複数の RSVP Agent を使用して、RSVP Agent をサポートする単一のルータ プラットフォーム(Cisco Integrated Services Router(ISR)など)を設定できます。各エージェントは別々の Unified CM クラスタに登録され、それぞれに専用のソフトウェア セッションがあります。プラットフォームごとのサポートされる RSVP Agent セッション数については、次のサイトで入手可能な『 Cisco RSVP Agent Data Sheet 』を参照してください。

http://www.cisco.com/en/US/products/ps6832/products_data_sheets_list.html

図 11-81 では、本社サイトで 2 つのリーフ クラスタと共存する Session Management Edition 配置を使用して、このことを示します。この例では、1 つのリーフ クラスタは Unified CM 7. x であり、もう 1 つのリーフ クラスタと Session Management Edition クラスタはバージョン 8.5 です。3 つのクラスタはそれぞれ、本社で 300 ソフトウェア セッションをサポートする RSVP Agent を使用して設定されており、両方のリーフ クラスタは、2 つのリモート ロケーションでそれぞれ 100 セッションをサポートする RSVP Agent 用に Cisco ISR プラットフォームを共有しています。

図 11-81 リーフ クラスタと共存する Session Management Edition(複数クラスタによる単一プラットフォームの共有)

 

コール アドミッション制御の設計上の推奨事項

ここでは、さまざまな Cisco Unified Communications Manager(Unified CM)配置でコール アドミッション制御を提供するためのベスト プラクティスについて、簡単に概要を示します。

次の推奨事項は、単一の Unified CM クラスタによる配置に適用されます。

デュアル リンクのない単純なハブアンドスポーク トポロジでは、Unified CM 静的ロケーションを使用します。ハブ サイト デバイスは Hub_None ロケーションのままにします。

デュアル リンクのないマルチプロトコル ラベル スイッチング(MPLS)トポロジでは、(中央サイトを含む)すべてのサイトのデバイスを 1 つのロケーションに割り当てて、Unified CM 静的ロケーションを使用します。

その他のトポロジでは、Unified CM RSVP 対応ロケーションを使用します。サイト間のデフォルト RSVP ポリシーには、[Mandatory] または [Mandatory (video desired)] ポリシーを推奨します。Cisco RSVP Agent 機能は、比較的小さなサイトでは IP WAN ルータで有効化されている場合もあります。また、比較的大きなサイトではスタンドアロン プラットフォームで実行される場合もあります。

次の推奨事項は、複数の Unified CM クラスタによる配置に適用されます。

デュアル リンクのない単純なハブアンドスポーク トポロジでは、Unified CM クラスタが存在するサイト間の Cisco IOS ゲートキーパー ゾーンを使用します。

Unified CM クラスタが第 1 レベルおよび第 2 レベルのハブ サイトに配置された、デュアル リンクのない 2 層ハブアンドスポーク トポロジでは、第 1 レベルと第 2 レベルのハブ サイト間のリンクに Cisco IOS ゲートキーパー ゾーンを使用し、第 2 レベルのハブ サイトとスポーク サイト間のリンクには Unified CM 静的ロケーションを使用します。

デュアル リンクのない MPLS トポロジでは、すべてのサイトを 1 つのロケーションに配置し、ゲートキーパー ゾーンなしで、Unified CM 静的ロケーションを使用します。MTP が必要な場合を除いて、クラスタ間トランクは Hub_None ロケーションのままにします。クラスタ間コール ルーティング用にはゲートキーパーを使用できますが、コール アドミッション制御では必要ありません。

それ以外のトポロジには、RSVP を使用します。