コール アドミッション制御
コール アドミッション制御
発行日;2013/04/24 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 38MB) | フィードバック

目次

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

この章の新規情報

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

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

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

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

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

Unified CM Enhanced Locations コール アドミッション制御

ロケーション、リンク、および重みによるネットワーク モデリング

Locations Bandwidth Manager

Enhanced Locations CAC の設計および展開の推奨事項と考慮事項

クラスタ間の Enhanced Locations CAC

LBM のハブのレプリケーション ネットワーク

共通ロケーション(共有ロケーション)およびリンク

シャドウ ロケーション

ロケーションおよびリンク管理クラスタ

クラスタ間の Enhanced Locations CAC の設計および展開の推奨事項と考慮事項

TelePresence イマーシブ ビデオの Enhanced Locations CAC

Video Call Traffic Class

TelePresence エンドポイント

SIP トランク

さまざまなコール フローおよびロケーションとリンクの帯域幅プールの差し引きの例

Locations CAC から Enhanced Locations CAC へのアップグレードおよび移行

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 の登録

RTCP、BFCP および FECC ネゴシエーション用の 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)の考慮事項

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

デュアル データセンター設計

MPLS クラウド

汎用トポロジ

集中型の UnifiedCM 配置

分散型混在呼処理配置

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

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

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

設計に関する推奨事項

設計上の考慮事項

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

設計に関する推奨事項

設計上の考慮事項

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

Enhanced Locations CAC を使用する Session Management Edition

クラスタ間トランクを介した 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 Manager Enhanced Locations コール アドミッション制御、Cisco IOS ゲートキーパー、RSVP、RSVP SIP プレコンディションなどの Cisco IP Communications システムのさまざまなコンポーネントによって使用可能となるコール アドミッション制御メカニズムについて説明します。

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

ここでは、前の項で説明されているメカニズムを IP WAN トポロジに基づいて適用し組み合わせる方法を示します。

この章の新規情報

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

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

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

Enhanced Locations CAC

「Unified CM Enhanced Locations コール アドミッション制御」

2012 年 6 月 28 日

RTCP、BFCP および FECC の RSVP Agent のサポート

「RTCP、BFCP および FECC ネゴシエーション用の RSVP Agent のサポート」

2012 年 6 月 28 日

RSVP Agent コール アドミッション制御への移行

「RSVP コール アドミッション制御への移行」

2012 年 6 月 28 日

コール アドミッション制御のための WAN トポロジの例

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

2012 年 6 月 28 日

Cisco Unified Communications システム Release 9.0 向けの他のアップデート

この章の各項で説明

2012 年 6 月 28 日

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

すでに述べたように、コール アドミッション制御は、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 Enhanced Locations コール アドミッション制御」

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

トポロジ対応メカニズム

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

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

Unified CM Enhanced Locations コール アドミッション制御

Cisco Unified CM 9. x では、Enhanced Locations コール アドミッション制御(CAC)を提供し、複数のクラスタが同じ物理サイトのデバイスを同じ WAN アップリンクを使用して管理している、複雑な WAN トポロジおよび Unified CM の分散型展開でのコール アドミッション制御をサポートします。Enhanced Locations CAC 機能はイマーシブ ビデオもサポートし、管理者が TelePresence などのイマーシブ ビデオ コールに対してコール アドミッションを他のビデオ コールと別に制御することが可能です。

より複雑な WAN トポロジをサポートするために、Unified CM はロケーション ベースのネットワーク モデリング機能を実装しています。これは、発信側と着信側の間のマルチ ホップ WAN 接続をサポートする機能を Unified CM に提供します。このネットワーク モデリング機能は、段階的にマルチ クラスタの分散型 Unified CM 配置をサポートするように強化されました。これは、クラスタ全体で同じロケーションに割り当てられた帯域幅を予約、解放、および調整するためにクラスが相互に通信できるようにすることによって、管理者が効果的にクラスタ間の場所を「共有」することが可能になります。また、管理者は イマーシブ ビデオ帯域幅 と呼ばれる Locations 設定に新しいフィールドを割り当てることによって、TelePresence などのイマーシブ ビデオ コールの帯域幅を個別にプロビジョニングできます。

Enhanced Locations CAC を管理し、トラブルシューティングする複数のツールがあります。CAC の拡張機能と設計は、この章で詳しく説明していますが、トラブルシューティング、およびサービスアビリティ ツールは個別の製品マニュアルで説明します。

ロケーション、リンク、および重みによるネットワーク モデリング

Enhanced Locations CAC はモデル ベースのスタティック CAC メカニズムです。Enhanced Locations CAC では、「ルーテッド WAN ネットワーク」をモデリングするロケーションとリンクを設定するのに、Unified CM で管理インターフェイスを使用する必要があります。このモデルは、WAN ネットワーク トポロジがエンドツーエンドの音声、ビデオ、およびイマーシブ コールに対するエンドポイント グループ間のメディアをどのようにルーティングするのかを表します。ネットワークをモデル化するために Unified CM は設定インターフェイスおよびサービスアビリティ インターフェイスを提供しますが、まだ RSVP CAC などの再ルーティングしているネットワーク障害とネットワーク プロトコルを考慮しない「静的」CAC メカニズムです。したがって、モデルは、WAN ネットワーク トポロジが変更されたらアップデートする必要があります。Enhanced Locations CAC もコール指向であり、帯域幅の差し引きはストリームごとではなくコールごとであるため、片方向のストリームのビットレートが反対方向のビットレートよりも高いようなメディア フローの場合、必ず高い方のビットレートに対して差し引かれます。また、単方向メディア フロー アラウンドは双方向メディア フローであるかのように差し引かれます。

管理者は、ロケーションとリンクを使用してネットワーク モデルを構築します。Enhanced Locations CAC は次の設定コンポーネントを使用します。

ロケーション:ロケーションは LAN を表します。これは、エンドポイントを含み、または単に WAN ネットワークのモデル化に対してリンク間の中継場所として機能します。

リンク:リンクはロケーションを相互接続し、ロケーション間で利用可能な帯域幅を定義するために使用されます。リンクは論理的に WAN リンクを表し、ロケーションのユーザ インターフェイス(UI)に設定されます。

重み:重みは、ロケーションのペア間に有効なパスを構成するリンクの相対的なプライオリティを与えます。有効なパスは、帯域幅の計算に Unified CM で使用するパスであり、すべての可能なパスにある最小の累積重みが設定されます。重みは、「有効なパス」に「コスト」を提供するためにリンクで使用され、任意の 2 地点間に複数のパスがある場合にだけ該当します。

パス:パスはロケーション ペアを接続するリンクおよび中間場所のシーケンスです。Unified CM では、各ロケーションから他のすべてのロケーションへの最短パス(最小コスト)をパス計算し、パスを構築します。1 つの「有効なパス」だけがロケーションのペア間で使用されます。

有効なパス:有効なパスは最小の累積重みのパスです。

帯域割り当て:音声、ビデオ、およびイマーシブ ビデオ(TelePresence)の各トラフィック タイプ用のモデルで割り当てられる帯域幅。

Locations Bandwidth Manager(LBM):1 つ以上のクラスタで設定されたロケーションおよびリンク データからネットワーク モデルを構築する Unified CM のアクティブ サービス。ロケーションのペア間の有効なパスを決定して、各タイプのコールに対する帯域幅の可用性に基づいてロケーションのペア間のコールを許可するか決定し、そして許可された各コールの時間分の帯域幅を差し引きます(予約します)。

Locations Bandwidth Manager ハブ:固定ロケーション、リンクのデータおよびダイナミック帯域幅割り当てのデータのクラスタ間のレプリケーションに直接参加するように指定された Locations Bandwidth Manager(LBM)サービス。LBM のハブ グループに割り当てられている複数の LBM は、共通の接続を介して互いに探索し、フル メッシュ構造のクラスタ間のレプリケーション ネットワークを形成します。LBM ハブを持つクラスタ内の他の LBM サービスはクラスタの LBM のハブを介してクラスタ間のレプリケーションに間接的に参加します。

ロケーションおよびリンク

Unified CM は、ロケーションの概念を使用して物理的なサイトを表し、エンドポイント、ボイス メッセージ ポート、トランク、ゲートウェイなどのメディア デバイスとの関連付けを作成します。これは、デバイス自体に直接設定した値、デバイス プール、またはデバイス モビリティを通じて行われます。Unified CM 9. x は、 links と呼ばれる新しいロケーション設定パラメータも使用します。リンクはロケーションを相互接続し、ロケーション間で利用可能な帯域幅を定義するために使用されます。リンクは論理的に WAN リンクを表します。ここでは、ロケーションおよびリンクおよびその使用方法について説明します。

ロケーション設定自体は、リンク、ロケーション間の帯域幅パラメータ、および RSVP ロケーションの設定の 3 つの主要部分で構成されます。Enhanced Locations CAC に対する RSVP ロケーションの設定は、RSVP 実装にだけ適用するため、ここでは考慮されません。設定では、ロケーション間の帯域幅パラメータが Show によって Show advanced リンクの選択で非表示または表示される間、リンク帯域幅パラメータが最初に表示されます。

ロケーション間の帯域幅パラメータは、管理者が音声、ビデオ、およびイマーシブの 3 つのコール タイプの帯域幅割り当てを設定することができます。これらは、トラフィックの量を、指定されたロケーション内およびロケーションとの間で制限します。どのデバイスでもコールを発信または受信すると、帯域幅がそのコール タイプに適用可能な帯域割り当てから差し引かれます。この機能により管理者は、実質的に LAN または中継ロケーションで使用される帯域幅の量を制限することができます。少なくとも 100BASE-T またはギガビット LAN で構成される現在ほとんどのネットワークでは、これらの LAN 帯域幅を制限する原因がほとんどないか、まったくありません。ただし、高帯域ビデオ コールの制限の利点を受ける一部の配置があります。単純な例として、広範囲にビデオ会議端末やデスクトップ ビデオ端末が配置された企業サイトの場合があります。ユーザのコールのほとんどすべてがビデオ対応の場合、大量の 1 ~ 2 Mbps のビデオ コールが LAN で使用可能な帯域幅の大部分をどのように使用する可能性があるのかを把握するのは簡単で、管理者がビデオ コールの数をその使用可能な LAN 帯域幅のより小さな割合に制限することを検討するのも容易です。この使用率は、ビジネスの繁忙期、または特定のトラフィック レベルがピークになる 1 年の特定時期にだけ発生する可能性があることに注意してください。帯域幅制限に達するとみられるのは、ビデオ トラフィックによるオーバーサブスクリプションが LAN で発生しないようにするために必要な時間帯に限られます。そのデバイスへのビデオ コールが何らかの理由で失敗した場合にビデオ デバイスを Retry Video Call as Audio にイネーブルにできることも注意すべき点です。これは、Unified CM のビデオ エンドポイントの設定ページで設定され、コールを受信するビデオ エンドポイントまたはトランクに適用できます。一部のビデオ エンドポイントは、デフォルトでは Retry Video Call as Audio がイネーブルにされ、エンドポイントで設定できないことにも注意する必要があります。

リンク帯域幅パラメータは、管理者が「隣接ロケーション」(つまり、その間で設定されたリンクがあるロケーション)間の音声、ビデオ、およびイマーシブ コール用にプロビジョニングされた帯域幅を特徴付けることができます。この機能により管理者にマルチ ホップ WAN ネットワークをモデル化するロケーションの組み合わせのストリングを作成する機能を提供します。これに図解するために、図 11-10 に示すように 4 つの物理的なサイトを接続する単純な 3 ホップ WAN トポロジを検討します。このトポロジでは、San Jose と Boulder 間、Boulder と Richardson 間、および Richardson と RTP 間のリンクを作成します。たとえば、San Jose から Boulder へのリンクの作成時、逆のリンク(Boulder から San Jose)も存在することに注意してください。したがって、管理者はいずれかのロケーション設定のページから一度だけペア リンクを作成する必要があります。図 11-10 の例では、3 つの各リンクは同じ設定で、重みが 50、音声帯域幅が 240 kbps、ビデオ帯域幅が 500 kbps、イマーシブ帯域幅が 5000 kbps(または 5 MB)です。

図 11-10 3 WAN のホップを持つ単一リンクの例

 

コールが San Jose と RTP の間で確立されると、Unified CM は、2 つのデバイス間のリージョン ペアによって決定される要求されたコールの帯域幅を計算し(「ロケーション、リンクとリージョンの設定」を参照)、2 地点間の有効なパスを確認します。つまり、Unified CM は 2 地点間のパスを構成するリンクと場所を確認し、各リンクと(該当する場合)パスの各場所からそれに応じて帯域幅を差し引きます。ロケーション内の帯域幅も、ロケーションのいずれかが無制限以外の帯域幅値を設定した場合はパスに沿って差し引かれます。

2 地点間で複数のパスが使用可能である場合に、重みがリンクだけで設定可能で、特定のパスの選択を強制する機能を提供します。複数のパスが設定されている場合、累積重みに基づいて 1 つだけが選択され、このパスが 有効なパス と呼ばれます。この重みはスタティックであり、有効なパスを動的に変更されません。図 11-11 は San Jose、Boulder および Seattle の 3 地点間のリンクで設定された重みを示しています。

図 11-11 累積パスの重み

 

San Jose から Seattle は 2 つのパスがあり、1 つはロケーション間の直接リンクで、もう 1 つは Boulder ロケーション経由(San Jose/Boulder リンクと Boulder/Seattle リンク)のパスです。San Jose と Seattle 間の直接リンクで設定された重みは 50 で、リンク San Jose/Boulder および Boulder/Seattle の累積重み 60(30+30)未満です。したがって、直接リンクが、累積リンクの重みが 50 であるため有効なパスとして選択されます。

Unified CM でデバイスを設定するときは、そのデバイスをロケーションに割り当てることができます。ロケーションは、トポロジを構築するために他のロケーションへのリンクで設定できます。Unified CM で設定するロケーションは、仮想ロケーションであり、実際の物理ロケーションではありません。前述のように、Unified CM は、ネットワーク内の実際の物理トポロジを認識しません。したがって Unified CM ロケーション モデルの実際の基本ネットワーク トポロジをマッピングするには、Unified CM の物理ネットワークへの変更は手動で実行する必要があります。デバイスが 1 つの物理ロケーションから他のロケーションに移動されると、システム管理者は、Unified CM がそのデバイスとの間で正しくコールの帯域幅割り当てを計算できるように、ロケーション設定の手動アップデートを実行するかデバイス モビリティ機能を実装する必要があります。各デバイスは、デフォルトでは Hub_None ロケーションに配置されます。ロケーション Hub_None は、通常、複数のロケーションをリンクするハブとして動作し、音声、ビデオ、およびイマーシブ帯域幅の無制限のロケーション内帯域幅割り当てがデフォルトで設定されるロケーションの例です。

Unified CM は、各ロケーションおよびロケーション間のリンクに別の音声、ビデオ、およびイマーシブ ビデオの帯域幅プールを定義することができます。通常、ロケーションのロケーション内の帯域幅設定はデフォルトの 無制限 のままであるのに対し、物理的なサイト間の WAN リンクの容量に合わせて、ロケーション間のリンクは有限数のキロ ビット/秒(kbps)に設定されます。ロケーションのロケーション内の音声、ビデオ、およびイマーシブ帯域幅が 無制限 として設定されている場合、そのロケーション内のコールおよびそのロケーションを通り抜けるすべてのコール(音声、ビデオ、およびイマーシブ)に使用できる無限の帯域幅があります。一方、帯域幅の値が有限数のキロ ビット/秒(kbps)に設定されている場合、Unified CM はロケーション内のすべてのコール、および中継ロケーション(計算パス内にあるが、パス内の発信または着信ロケーションではないロケーション)としてロケーションを使用するすべてのコールをトラッキングします。

ビデオ コールでは、ビデオ ロケーションの帯域幅は、ビデオ コールの音声およびビデオ部分の両方を考慮に入れます。したがって、ビデオ コールの場合、帯域幅が音声帯域幅プールから差し引かれることは一切ありません。同じことがイマーシブ ビデオ コールにも適用されます。

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

IP Phone

CTI ポート

H.323 クライアント

CTI ルート ポイント

会議ブリッジ

保留音(MoH)サーバ

ゲートウェイ

トランク

Enhanced Locations コール アドミッション制御メカニズムでは、通話中のコール タイプ変更も考慮されます。たとえば、サイト間でビデオ コールを確立する場合、Unified CM は、パスのそれぞれのロケーションおよびリンクから適切なビデオ帯域幅を差し引きます。このビデオ コールが、ビデオ非対応のデバイスへの転送の結果、音声のみのコールに変更された場合、Unified CM はビデオ プールに割り当てられた帯域幅を返却し、同じパスに沿って音声プールから適切な帯域幅を割り当てます。音声からビデオに変更されるコールについては、これとは逆の帯域幅割り当て変更が発生します。

表 11-2 に、さまざまなコールのタイプ(ビット レート)において静的ロケーション アルゴリズムが要求する帯域幅を示します。音声コールでは、Unified CM は、メディア ビット レートにレイヤ 3 オーバーヘッドを加えてカウントします。たとえば、G.711 音声コールは、ロケーションとリンクの音声帯域幅割り当てから差し引かれる 80 kbps(64k ビット レート + L3 オーバーヘッド)を消費します。ビデオ コールでは、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

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

あるロケーションから他のロケーションにコールが発信されると、Unified CM は、ロケーションおよびあるロケーションから他のロケーションへのリンクの有効なパスから適切な帯域幅を差し引きます。例として図 11-10 を使用すると、San Jose と RTP ロケーション間の G.729 コールによって、Unified CM は、San Jose と Boulder 間、Boulder と Richardson 間、Richardson と RTP 間のリンクで使用可能な帯域幅から 24 kbps を差し引きます。コールが完了すると、Unified CM は有効なパス上でこれらの同じリンクに帯域幅を返却します。十分な帯域幅がパス上のリンクのいずれかにない場合、コールは Unified CM によって拒否され、発信者はネットワーク ビジー トーンを受信します。発信側デバイスが、ディスプレイを備えた IP Phone である場合、そのデバイスには、「Not Enough Bandwidth」というメッセージも表示されます。

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


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


ロケーション、リンクとリージョンの設定

ロケーションは、リージョンとともに機能してロケーションおよびリンクに有効なパス上でコールの特性を定義します。リージョンはデバイス間で使用される圧縮のタイプまたはビット レート(8 kbps または G.729、64 キロ ビット/秒または G.722/G.711 など)を定義し、ロケーション リンクはデバイス間の有効なパスで使用可能な帯域幅の量を定義します。システム内の各デバイスを(デバイス プールを使用して)リージョンに割り当て、(デバイス プールまたはデバイス自体に直接設定した値を使用して)ロケーションに割り当てます。

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

物理的なサイト(たとえば、ブランチ オフィス)または中継サイト(たとえば、MPLS クラウド):場所は LAN を表します。これは、エンドポイントを含み、または単に WAN ネットワークのモデル化に対してリンク間の中継場所として機能します。

隣接するロケーション間のリンク帯域幅:リンクはロケーションを相互接続し、ロケーション間で利用可能な帯域幅を定義するために使用されます。リンクは物理的なサイト間の WAN リンクを論理的に表します。

音声帯域幅:ロケーション デバイスから設定された隣接した場所に行われる音声および FAX コールの WAN リンクで使用可能な帯域幅の量。Unified CM では、Enhanced Locations のコール アドミッション制御にこの帯域幅値が使用されます。

ビデオ帯域幅:ロケーション デバイスから設定された隣接した場所に行われたビデオ コール用の WAN リンクで使用可能なビデオ帯域幅の量。Unified CM では、Enhanced Locations のコール アドミッション制御にこの帯域幅値が使用されます。

イマーシブ ビデオ帯域幅:ロケーション デバイスから設定された隣接した場所に行われた TelePresence コールの WAN リンクで使用可能なイマーシブ帯域幅の量。Unified CM では、Enhanced Locations のコール アドミッション制御にこの帯域幅値が使用されます。

ロケーション内の帯域幅

音声帯域幅:ロケーション デバイスから設定された隣接した場所に行われる音声および FAX コールの WAN リンクで使用可能な帯域幅の量。Unified CM では、Enhanced Locations のコール アドミッション制御にこの帯域幅値が使用されます。

ビデオ帯域幅:ロケーション デバイスから設定された隣接した場所に行われたビデオ コール用の WAN リンクで使用可能なビデオ帯域幅の量。Unified CM では、Enhanced Locations のコール アドミッション制御にこの帯域幅値が使用されます。

イマーシブ ビデオ帯域幅:ロケーション デバイスから設定された隣接した場所に行われた TelePresence コールの WAN リンクで使用可能なイマーシブ帯域幅の量。Unified CM では、Enhanced Locations のコール アドミッション制御にこの帯域幅値が使用されます。

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

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

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

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

リージョン内コールおよびリージョン間コールに使用する最大ビデオ コール ビット レート設定(音声を含む)(Max Video Call Bit Rate(Includes Audio))。これには、TelePresence エンドポイントに適用される場合のイマーシブ コールの最大ビット レートが含まれます。

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

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

Cisco Unified Communications Manager は、Cisco MCS-7845 サーバで 2,000 のロケーションと 2,000 のリージョンをサポートします。最大 2,000 のロケーションおよびリージョンを配置するには、[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 パラメータにも [Use System Default] を選択します。

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

 

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

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

0 ~ 200

2,000

2,000

200 ~ 500

1,000

1,000


) [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)を使用して、それらの設計をすべて検証する必要があります。サイジング ツールを使用して、設計基準を満たすために必要なサーバまたはクラスタの正確な台数を決定します。


Locations Bandwidth Manager

Locations Bandwidth Manager(LBM)は、サービスアビリティ Web ページから管理し、Enhanced Locations CAC 帯域幅の機能すべてを担当する Unified CM 機能サービスです。LBM は、Unified CM サブスクライバまたはクラスタの専用の Unified CM サーバのスタンドアロン サービスとして実行できます。クラスタで Enhanced Locations CAC を有効にするために、LBM の 1 つ以上のインスタンスが各クラスタで実行される必要があります。ほとんどのインストールについては、シスコは LBM を次のとおりに行うことを推奨します。

ロケーションおよびリンク パスのアセンブリ

アセンブリの有効なパス上の帯域幅の計算

Cisco CallManager サービス(Unified CM 呼制御)からのサービスの帯域幅要求

クラスタ間の Enhanced Locations CAC がイネーブルの場合のクラスタ内およびクラスタ間でその他の LBM への帯域幅情報の複製

設定済みのダイナミック情報をサービスアビリティに提供します

Location Real-Time Monitoring Tool(RTMT)カウンタの更新

Cisco CallManager サービスとの間の、または LBM 間の通信に使用する TCP 上での Extensible Markup Language(XML)を使用します。

LBM サービスは以前のリリースから Cisco Unified CM 9.x にアップグレードするとデフォルトでイネーブルです。新規インストールの場合、LBM サービスは手動でアクティブにする必要があります。

初期化中に LBM は、ロケーションの音声、ビデオ、およびイマーシブ帯域幅値などのデータベース、ロケーション内の帯域幅データ、ロケーションごとのリンク音声、ならびにイマーシブ帯域幅の値と重み(ロケーション間の帯域幅データ)からローカル ロケーション情報を読み取ります。リンク データを使用して、クラスタ内の各 LBM は、あるロケーションから他のすべてのロケーションまでのパスのローカル アセンブリを作成します。これは、 アセンブルされたトポロジ と呼ばれます。クラスタでは、各 LBM は同じデータにアクセスし、初期化中にアセンブルされるトポロジと同じローカル コピーを作成します。

実行時、LBM は、ロケーションとリンクのローカルで組み立てられたトポロジの計算されたパスの予約を適用し、クラスタ内の他の LBM に予約を複製します。クラスタ間の Enhanced Locations CAC が設定され、アクティブになると、LBM は他のクラスタに再構築されたトポロジを複製します(詳細については「クラスタ間の Enhanced Locations CAC」を参照してください)。

デフォルトでは、Cisco CallManager サービスはローカル LBM サービスと通信しますが、この通信を管理するために LBM グループを使用できます。LBM グループは Unified CM の呼制御の冗長性を作成するために、アクティブなスタンバイ LBM を提供します。図 11-12 は LBM の冗長性を示します。

図 11-12 Locations Bandwidth Manager の冗長性

 

図 11-12 は 5 つの Unified CM サーバを示します。UCM1 および UCM2 は専用 LBM サーバ(LBM サービスがイネーブルの場合だけ)、UCM3、UCM4 および UCM5 は Unified CM サブスクライバ(Cisco CallManager サービスがイネーブルの場合)です。LBM グループは UCM1 でアクティブとして、UCM2 でスタンバイとして設定されており、UCM3、UCM4 および UCM5 サブスクライバに適用されます。この設定は UCM3、UCM4 および UCM5 がすべての帯域幅の要求に対して UCM1 にクエリーを実行できるようになります。UCM1 が何らかの理由で失敗し、サブスクライバはスタンバイ UCM2 にフェールオーバーします。

Unified CM Cisco CallManager サービスが LBM を使用する順序は次のとおりです。

LBM グループの指定

ローカル LBM

サービス パラメータ Call Treatment when no LBM available (デフォルト = allow calls

Enhanced Locations CAC の設計および展開の推奨事項と考慮事項

Locations Bandwidth Manager(LBM)は Unified CM 機能サービスです。

LBM はトポロジのモデリングおよび Unified CM 帯域幅要求のサービスを行う役割があります。

すべての LBM はクラスタ内でフル メッシュ化されています。

Enhanced Locations CAC LBM のレプリケーション ネットワークは、クラスタ内および複数のクラスタ間でモデル化されたトポロジと帯域幅割り当てを複製するために使用されます。

LBM グループの使用方法の推奨事項は、次のとおりです。

Cisco CallManager サービスが LBM と相互作用する方法を管理します(共存または専用)。

WAN またはデュアル データセンターを介したクラスタリングの展開で LBM のフル メッシュの帯域幅要件を最小化します。

共存または専用の冗長性の呼処理サイトごとに、少なくとも 2 つの LBM を配置します。

非アクティブなスタンバイ サブスクライバにアクティブな LBM をオフロードします。

現在の推奨事項は Cisco CallManager 呼処理サービスを実行している Unified CM サブスクライバで LBM サービス共存を展開する方法です。

LBM グループの推奨事項

各 Unified CM サブスクライバを実行およびアクティブ ローカル LBM を含むように設定します。

冗長 LBM グループ設定の 2 つ以上の LBM は、WAN を介したクラスタリング設計などの各呼処理サイトでアクティブにする必要があります。

アクティブ サブスクライバのロードの削減については、専用 LBM を使用するか、または 1:1 Unified CM 冗長性モデルの非アクティブ スタンバイ サブスクライバで LBM をイネーブルにします。

クラスタ間の Enhanced Locations CAC

クラスタ間の Enhanced Locations CAC は、複数のクラスタにわたるネットワーク モデリングの概念を拡張します。クラスタ間の Enhanced Locations CAC では、各クラスタは、ロケーションとリンク上でローカルに設定されたトポロジを管理し、LBM クラスタ間のレプリケーション ネットワーク内にある他のリモート クラスタにこのローカル トポロジを伝播します。リモート クラスタのトポロジを受け取ると、LBM は独自のローカル トポロジにこれを再構成し、グローバル トポロジを作成します。このプロセスによって、グローバル トポロジはすべてのクラスタ間で同じになり、エンドツーエンド CAC に対する企業ネットワーク トポロジの全体的視野を各クラスタに提供します。図 11-13 は、単純なハブアンドスポーク ネットワーク トポロジを持つグローバル トポロジの概念を例として示します。

図 11-13 単純なハブアンドスポーク ネットワークのグローバル トポロジの例

 

図 11-13 はクラスタ 1 とクラスタ 2 の 2 つのクラスタを示し、それぞれにローカルに設定されたハブアンドスポーク ネットワーク トポロジがあります。クラスタ 2 は Loc_21、Loc_22 および Loc_23 へのリンクで Hub_None を設定し、クラスタ 1 は Loc_11 および Loc_12 へのリンクで Hub_None を設定しました。クラスタ間の Enhanced Locations CAC をイネーブルにすると、クラスタ 1 は、クラスタ 2 がクラスタ 1 にするように、そのローカル トポロジをクラスタ 2 に送信します。各クラスタはリモート クラスタのトポロジのコピーを取得した後、各クラスタはオーバーレイ独自上のリモート クラスタのトポロジを自身の上にオーバーレイします。オーバーレイは、同じ名前で設定されたロケーションの一般的な場所によって実現されます。クラスタ 1、クラスタ 2 の両方に同じ名前の共通のロケーション Hub_None があるため、各クラスタは、共通の場所として Hub_None により他方のネットワーク トポロジをオーバーレイし、Hub_None がハブで Loc_11、Loc_12、Loc_21、Loc_22、および Loc_23 がすべてスポーク ロケーションであるグローバル トポロジを作成します。これは単純なネットワーク トポロジの例ですが、より複雑なトポロジは同じ方法で処理されます。

LBM のハブのレプリケーション ネットワーク

クラスタ間 LBM のレプリケーション ネットワークは指定 LBM ネットワークであり、フル メッシュを相互に作成し、ローカル クラスタのトポロジを複製します。次に、それぞれは、グローバル トポロジを作成するために、すべてのリモート クラスタのトポロジを受信します。クラスタ間のレプリケーション ネットワーク用の指定 LBM は LBM のハブと呼ばれ、クラスタ内でだけ複製する LBM は LBM のスポークと呼ばれます。LBM のハブは LBM のハブのグループによる設定で指定されます。LBM のハブのグループには、ハブのグループ メンバーおよびハブのグループの使用情報と呼ばれる 2 つの主な設定領域があります。ハブのグループ メンバーは、LBM のレプリケーション ネットワークの一部のリモート クラスタの LBM ハブです。最大 3 つのメンバーを設定できます。LBM のハブのグループ メンバーで指定されたメンバーは、クラスタ間のレプリケーション ネットワーク全体のブートストラップ サーバとして機能し、接続された他のリモート クラスタの接続の詳細を持つ各クラスタの各 LBM ハブを提供します。LBM のハブのグループの使用情報は、ローカル クラスタの LBM のハブおよびスポークで構成されます。LBM ハブのグループとの間で LBM サービスを移動すると、ハブまたはロールの役割が決定されます。(LBM のハブのグループ設定の詳細については、Cisco Unified Communications Manager の製品マニュアルを参照してください)。LBM のハブのグループが指定 LBM の各クラスタに設定されている場合、ハブはフル メッシュのクラスタ間のレプリケーション ネットワークを作成します。図 11-14 は、クラスタ間のレプリケーション ネットワークを形成するために 3 つのクラスタ(リーフ クラスタ 1、リーフ クラスタ 2 および Session Management Edition(SME)クラスタ)の間に設定された LBM のハブのグループによるクラスタ間のレプリケーションのネットワーク構成を示します。

図 11-14 3 つのクラスタのクラスタ間レプリケーション ネットワークの例

 

図 11-14 では、各クラスタから 2 つの LBM サーバはクラスタの LBM のハブとして指定されます。これらの LBM ハブ サーバは、クラスタ間の LBM レプリケーション ネットワークを形成します。各 LBM のハブのグループで設定された LBM のハブのグループ メンバーは SME_1 および SME_2 と見なされます。SME クラスタからのこれら 2 つの LBM サーバは、クラスタ間 LBM のレプリケーション ネットワーク全体の窓口として機能します。これは、各クラスタの各 LBM が SME_1 に接続し、SME_1 にローカル トポロジを複製し、SME_1 からリモート トポロジが取得されることを意味します。また、SME_1 から他のリーフ クラスタの接続情報を取得し、その他のリモート クラスタに接続し、トポロジを複製します。これは、フル メッシュのレプリケーション ネットワークを作成します。SME_1 が使用できない場合、LBM のハブは SME_2 に接続します。SME_2 が使用できない場合、リーフ クラスタ 1 LBM は UCM_A に接続し、SME クラスタが使用できない場合のバックアップ手段として、リーフ クラスタ 2 LBM は UCM_1 に接続します。これは、クラスタ間 LBM のレプリケーション ネットワークのコンポーネントを説明する設定例です。

LBM には、LBM クラスタ間のレプリケーション ネットワークに関する次の役割があります。

LBM のハブのグループ メンバー

レプリケーション ネットワークのすべての LBM のハブを相互接続するリモート ハブ サーバ

ネットワーク内のどのハブにも存在できます

ハブのグループあたり最大 3 つ表示できます

LBM ハブ サーバ(ローカル LBM)

クラスタ間 LBM のレプリケーション ネットワークの一部として他のリモート ハブ サーバと直接通信します

LBM スポーク サーバ(ローカル LBM)

クラスタのローカル LBM のハブと直接通信し、ローカル LBM のハブを介してリモート LBM のハブと間接的に通信します

LBM のハブのレプリケーション ネットワーク:帯域幅の差し引きと調整メッセージ

クラスタに複数の LBM ハブがある場合、最も低い IPv4(全体)アドレスの LBM のハブは、他のリモート クラスタへのメッセージの送信者として機能します。クラスタごとに 1 つのハブだけが、リモート クラスタにメッセージを転送します。これは、クラスタ間のレプリケーション ネットワーク内のレプリケーションのトラフィック量を制限します。

クラスタのメッセージの送信者として機能する LBM ハブは、各クラスタから 1 つの LBM のハブを選択し、その LBM にメッセージを転送します。

リモート クラスタからメッセージを受信する LBM ハブは次に、ローカル クラスタの LBM のスポークに受信メッセージを転送します。

転送されるメッセージには、メッセージのストームやループを防ぐために、受信側がすでに受信したかを確認し、2 回目に受信した場合、受信側がメッセージをドロップできるようにするための、関連付けられている一意のランダムな文字列があります。

転送されたメッセージを受信するクラスタ内の他の LBM ハブは、メッセージがリモート クラスタからの直接的なものでないため、LBM のスポークに転送しません。これで、リモート クラスタから重複メッセージを送信するハブを回避できます。

共通ロケーション(共有ロケーション)およびリンク

前述のとおり、共通ロケーションはクラスタ全体で同じ名前のロケーションです。共通ロケーションは、LBM がグローバル トポロジを作成する方法、および複数のクラスタ間で 1 つのロケーションを関連付ける方法において重要な役割を果たします。複数のクラスタ間で同じ名前のロケーションは、同じロケーションと見なされため、これらのクラスタ間では共有ロケーションです。したがって、ロケーションが複数のクラスタ間で共有されることを意味する場合、まったく同じ名前である必要があります。複製後も、LBM は、ロケーションとリンクでの設定の矛盾点について確認します。帯域幅値の不一致、または共通ロケーションとリンク間の重みはサービスアビリティで表示でき LBM は、重みの帯域幅と最小値(最低コスト)の最も厳しい値のロケーションおよびリンク パスを計算します。

共通のロケーションとリンクは、いくつかの異なる理由でクラスタ全体に対して設定できます。同じ物理サイトのデバイスを管理し、同じ WAN アップリンクを使用するいくつかのクラスタを使用することがあるため、同じロケーションは、各クラスタのローカル デバイスにそのロケーションを関連付けるために各クラスタに設定する必要があります。独自のトポロジを管理するクラスタがある場合もありますが、これらのトポロジは、特定のロケーションにおいて相互接続されるため、これらのロケーションを各クラスタ間の共通ロケーションとして設定する必要が生じます。そうすることで、グローバル トポロジが作成されている際に、クラスタでは、各クラスタで共通の相互接続ロケーションとリンクを持ち、各リモート トポロジをともに効果的にリンクさせることができるようになります。図 11-15 はトポロジをリンクすることを示し、各クラスタが共有する共通トポロジを示します。

図 11-15 グローバル トポロジを作成する共通のロケーションとリンクの使用

 

図 11-15 では、クラスタ 1 は Regional 1、Loc_11 および Loc_12 のロケーションにデバイスがありますが、グローバル トポロジの他にリンクするために、DC および Regional 1 から DC へのリンクの設定が必要です。クラスタ 2 も同様に、Regional 2、Loc_21、Loc_22 および Loc_23 にデバイスがあり、グローバル トポロジにマッピングするように DC および DC から Regional 2 へのリンクの設定が必要です。クラスタ 3 には Loc_31 だけにデバイスがあり、クラスタ 1 とクラスタ 2 のトポロジにマッピングするように DC および Loc_31 から DC へのリンクの設定が必要です。また、図 11-16 で示されているように、Regional 1 および Regional 2 を DC の代わりに、すべてのクラスタで設定された共通ロケーションにすることができます。

図 11-16 異なる共通ロケーションを使用する代替トポロジ

 

クラスタからクラスタへのトポロジ マッピングのキーは、トポロジを相応に相互接続するように少なくとも 1 つのクラスタに別のクラスタの共通ロケーションがあることを確認します。

シャドウ ロケーション

シャドウ ロケーション は、Enhanced Locations CAC がクラスタ間で機能するために必要な、ロケーションの名前、ビデオ トラフィック クラス(後述)などの、Enhanced Locations CAC 情報を他のものに渡すように SIP トランクをイネーブルにするために使用されます。クラスタ全体でこのロケーション情報を渡すためには、SIP クラスタ間トランク(ICT)は「シャドウ」ロケーションに割り当てる必要があります。「ファントムの」ロケーションと同様に、他の場所へのリンクを持つことができないため、帯域幅はシャドウ ロケーションと別のロケーションの間で予約できません。Hub_None に関連付けられたように、シャドウ ロケーションに割り当てられた SIP ICT 以外のいずれかのデバイスが処理されます。SIP ICT 以外のデバイスがシャドウ ロケーションに行きついたら、帯域幅の差し引きは Hub_None 内にあるようにそのデバイスから行われ、ロケーションおよびリンク設定に応じてさまざまな影響を受けるため、これを理解することは重要です。

SIP ICT は Enhanced Locations CAC で有効になっている場合、SIP Call-Info ヘッダーによって情報を渡します。これにより、発信側と着信側のクラスタは、ロケーションの帯域幅の差し引きをエンドツーエンドで処理することが可能となります。図 11-17 は、渡された情報に関する 2 クラスタと一部の詳細の間のコールの例を示します。これは、ロケーション情報をクラスタからクラスタに渡す方法、また帯域幅の差し引きを行う方法を単に示します。

図 11-17 クラスタ間で情報を渡すために使用するシャドウ ロケーション

 

図 11-17 では、Cluster 1 は Cluster 2 に invite を送信し、call-info ヘッダーに、一意のコール ID など、その他の関連情報間の発信側のロケーション名およびビデオ トラフィック クラスを入力します。クラスタ 2 は情報の invite を受信すると、着信側を検索し、LBM レプリケーションからのメモリ内にあるグローバル トポロジから、発信側のロケーションと着信側のロケーション間のパスで CAC 要求を実行します。これが成功すると、クラスタ 2 は予約を複製し、着信デバイスにコールを拡張し、着信側のロケーション情報によって 180 の呼び出し音をクラスタ 1 に返します。クラスタ 1 は 180 の呼び出し音を受信すると着信デバイスのロケーション名を取得し、call-info ヘッダーに渡された情報から計算された同じ固有コール ID を使用して同じ帯域幅のルックアップ プロセスを通過します。成功した場合、コール フローも継続されます。両方のクラスタは call-info ヘッダーに同じ情報を使用するため、同じ call-ID を使用して同じコールの帯域幅を差し引きするため、二重の帯域幅の差し引きを回避できます。

ロケーションおよびリンク管理クラスタ

設定のオーバーヘッドを回避するために、ロケーションおよびリンク管理のクラスタは、グローバル トポロジのすべてのロケーションおよびリンクを管理するように設定できます。他のすべてのロケーションはロケーションからデバイスへの関連付けに必要なロケーションを一意に設定し、無制限以外のリンクまたは帯域幅値を設定しません。ロケーションおよびリンク管理のクラスタは設計概念で、ロケーションおよびリンクの全体のグローバル トポロジに設定された単なるクラスタですが、LBM のレプリケーション ネットワーク上の他のクラスタはすべて、帯域幅の値が無制限で、かつリンクを設定されていないロケーションのみで構成されていることに注意すべきです。クラスタ間の Enhanced Locations CAC がイネーブルになり、LBM のレプリケーション ネットワークが設定されている場合、すべてのクラスタがネットワーク ビューを複製します。指定したロケーションおよびリンク管理のクラスタには、ロケーション、リンクおよび帯域幅の値を持つグローバル トポロジ全体があります。これらの値は、複製されると最も制限的であるため、すべてのクラスタで使用されます。この設計によって、多数の共通のロケーションが複数のクラスタ間で必要な配置の設定オーバーヘッドが軽減されます。

推奨事項

LBM のレプリケーション ネットワークの管理クラスタ

すべてのリンクおよびロケーションは管理クラスタで管理されます。

ロケーション、帯域幅値、リンクと重み

LBM のレプリケーション ネットワークの他のクラスタ

ロケーション内の帯域幅パラメータに無制限の帯域幅値を使用します。

リンクを設定しないでください。

LBM は、複製後で最小の最も限定的な帯域幅と最も小さい重み値を常に使用します。

利点

単一クラスタから企業 CAC トポロジを管理します。

クラスタが複数の共通のロケーションを共有する場合のロケーションとリンク設定のオーバーヘッドを軽減します。

クラスタ間でロケーションおよびリンクの設定の誤りを軽減します。

企業の他のクラスタは、ロケーションからデバイスやエンドポイントへの関連付けに必要なロケーションにだけ設定を必要とします。

グローバル ロケーション トポロジのモニタリングに単一のクラスタを提供します。

図 11-18 は、3 つのリーフ クラスタのロケーションおよびリンクの管理クラスタとして Cisco Unified Communications Manager Session Management Edition(SME)について説明します。

図 11-18 ロケーションおよびリンクの管理クラスタとしての SME の例

 

図 11-18 では 3 つのリーフ クラスタがあり、それぞれは、リージョン ロケーションおよびリモート ロケーションだけにデバイスがあります。SME にはロケーションおよびリンクで設定されているグローバル トポロジ全体があり、クラスタ間 LBM の複製は 4 つのすべてのクラスタの間でイネーブルです。SME がロケーションとリンク トポロジの全体を設定するため、すべてのロケーションが共通のロケーションですが、この例ではロケーションを共有するクラスタはありません。SME ではグローバル トポロジ全体が設定されていますが、リーフ 1、リーフ 2 とリーフ 3 は、デバイスやエンドポイントに関連付ける必要があるロケーションだけを設定することに注意してください。クラスタ間レプリケーション後に、すべてのクラスタはグローバル トポロジを持つようになります。

クラスタ間の Enhanced Locations CAC の設計および展開の推奨事項と考慮事項

帯域予約では予約がローカルで行われて他の LBM のレプリケーション ネットワークに複製されるため、オーバーサブスクリプションが生じる可能性があります。オーバーサブスクリプションの間に QoS 影響を回避するには、次のガイドラインに従ってください。

オーバーサブスクリプションは一時的なもので、パスのオーバーサブスクリプションになったロケーションおよびリンクを使用してコールとして自身を修正し、帯域幅をクリアおよび放棄します。

帯域幅オーバーヘッドは、ネットワーク QoS ポリシーでオーバーサブスクリプションを受け入れるように設定されます。シスコでは、適切なロケーションおよびリンクに対する各 QoS クラスの最大の帯域幅値の少なくとも 1 つのコールによる過剰プロビジョニング(音声およびビデオ)を推奨します。音声のみの実装の場合、これは 24 kbps または 80 kbps の単一のコールである場合があります。ビデオ実装の場合、シングル ビデオ コールのビット レートである可能性があります。

CAC 制限が頻繁に繁忙時にまたは一般に到達したロケーションとリンクは、QoS 帯域幅容量の過剰プロビジョニングの主要な候補です。

非常に高い最繁忙時呼完了数(BHCC)と Unified CM クラスタ間の長い遅延の場合、ロケーションおよびリンクをモニタリングして煩雑時のオーバーサブスクリプションの量を決定し、ネットワークが同量の帯域幅で過剰プロビジョニングされるようにすることを推奨します。

クラスタは、ロケーションからデバイスへの関連付けに対してロケーションをローカルに設定することを要求します。

各クラスタはすぐにネイバー ロケーションで設定されて、各クラスタのトポロジが相互接続できるようにする必要があります。これは、ロケーションとリンクの管理クラスタの配置には適用されません。

リンクは、リモート トポロジ間の相互接続ポイントを確立するように設定する必要があります。これは、ロケーションとリンクの管理クラスタの配置には適用されません。

共通のロケーションとリンクの帯域幅制限および重みの不一致は、帯域幅および重みの最小値を使用して解決されます。

クラスタ全体でのロケーションの一貫した命名は重要です。「同じロケーション、同じ名前、および、異なるロケーション、異なる名前」の方法に従ってください。

Hub_None ロケーションは各クラスタで一意であるように名前変更される必要があります。そうしないと、他のクラスタによって共通(共有)ロケーションになります。

クラスタ ID は、サービスアビリティ レポートが使用できるように各クラスタで一意である必要があります。

すべての LBM のハブはクラスタ間でフル メッシュです。

LBM のハブは、リモート クラスタのハブに通信する責任があります。

LBM のスポークは、他のリモート クラスタと直接通信することはありません。LBM のスポークはローカル LBM のハブを経由してリモート クラスタとの間でメッセージを送受信します。

LBM のハブのグループ

ハブのロールに LBM を割り当てるために使用されます

LBM のハブのレプリケーション ネットワークの全ハブのハブ連絡先情報を複製する 3 つのリモート ハブのメンバーを定義するために使用されます

LBM は、LBM のハブのグループに割り当てられる場合のハブです。

LBM は LBM のハブのグループに割り当てられていない場合、スポークになります。

クラスタに LBM のハブがない場合、または LBM のハブが実行されていない場合、クラスタは分離されて、クラスタ間 LBM のレプリケーション ネットワークに参加しません。

パフォーマンスのガイドライン

最大 2,000 のローカルに設定されたロケーション。2,000 ロケーションの制限は、ロケーションとリンクの管理クラスタにも適用されます。

クラスタ間 CAC を持つ複製された最大 8,000 の合計ロケーション

TelePresence イマーシブ ビデオの Enhanced Locations CAC

TelePresence エンドポイントがデスクトップから会議室といった広範囲に多様なコラボレーション エクスペリエンスを提供できるようにするため、Enhanced Locations CAC には、TelePresence イマーシブ ビデオ コールに CAC を提供するサポートが含まれています。ここでは、TelePresence イマーシブ ビデオ CAC をサポートする Enhanced Locations CAC の機能について説明します。

Video Call Traffic Class

Video Call Traffic Class は、すべてのエンドポイントに割り当てられた属性で、エンドポイントまたはトランクのビデオ分類タイプを確認するために SIP トランクでイネーブルにもできます。これは、Unified CM が、さまざまなコール フローをイマーシブまたは、デスクトップ ビデオ、またはその両方として分類し、ビデオ帯域幅またはイマーシブ帯域幅、またはその両方の適切なロケーションやリンク帯域幅の割り当てから、それに応じて差し引くことを可能にします。TelePresence エンドポイントには、エンドポイントに割り当てられた イマーシブ の設定不可能な Video Call Traffic Class があります。SIP トランクは、デスクトップ ビデオ、高解像度イマーシブ ビデオのどちらか、または Cisco TelePresence System Video Communications Server(VCS)などのビデオ エンドポイントの両方の分類があるシステムとして SIP プロファイルで設定できます。他のエンドポイントおよびトランクにはすべて、 デスクトップ ビデオ の設定不可能な Video Call Traffic Class があります。

TelePresence イマーシブ エンドポイントは CS4 の DSCP 値のメディアをデフォルトで表示し、デスクトップ ビデオ エンドポイントは推奨される QoS 設定によって AF41 のメディアをデフォルトで表示します。Cisco エンドポイントの場合、これは、設定可能な Unified CM QoS サービス パラメータの DSCP for Video calls および DSCP for TelePresence calls によって実現されます。Cisco TelePresence エンドポイントは、Unified CM に登録されている場合、設定ファイルをダウンロードし、 DSCP for TelePresence calls の設定に QoS 設定を適用します。Unified Communications ビデオ対応エンドポイントは、Unified CM に登録されている場合、設定ファイルをダウンロードし、 DSCP for Video calls の設定に QoS 設定を適用します。すべてのサードパーティ製ビデオ エンドポイントは、エンドポイントの手動設定自体を必要とし、静的に設定され、コール タイプによって QoS マーキングを変更しないことを意味します。したがって、正しい DSCP に Enhanced Locations CAC の帯域割り当てを一致させることが重要です。Unified CM は、 デスクトップ の Video Call Traffic Class を持つデバイスのビデオ帯域幅のロケーションとリンクの割り当てからデスクトップ ビデオ コールを差し引くことによって、これを実現します。エンドツーエンド TelePresence イマーシブ ビデオ コールは、 イマーシブ の Video Call Traffic Class を持つデバイスまたはトランクのイマーシブ ビデオ帯域幅のロケーションとリンクの割り当てから差し引かれます。これによって、エンドツーエンド デスクトップ ビデオとイマーシブ ビデオ コールが正しくマーキングされ、コール アドミッション制御に正しくカウントできます。デスクトップ デバイスと TelePresence イマーシブ デバイス間のコールでは、帯域幅はビデオ帯域幅とイマーシブ ビデオ帯域幅の両方のロケーションとリンクの割り当てから差し引かれます。

TelePresence エンドポイント

TelePresence エンドポイントには イマーシブ の固定された設定不可能な Video Call Traffic Class があり、Unified CM でイマーシブとして識別されます。

帯域予約はビデオ コールのエンドポイントの分類によって決定され、 表 11-4 に示されるようにロケーションおよびリンクの帯域幅プールから帯域幅を差し引きます。

 

表 11-4 エンドポイント タイプごとの帯域幅プールの使用

エンド ポイント A
エンド ポイント B
使用されるロケーションとリンクのプール

イマーシブ ビデオ

イマーシブ ビデオ

イマーシブ帯域幅

イマーシブ ビデオ

デスクトップ ビデオ

イマーシブ帯域幅およびビデオ帯域幅

デスクトップ ビデオ

デスクトップ ビデオ

ビデオ帯域幅

音声のみのコール

任意

音声帯域幅

SIP トランク

SIP トランクは、SIP トランク コールの帯域幅予約を差し引きするためにデスクトップ、イマーシブ、または混合ビデオとして分類できます。分類は発信側デバイス タイプと SIP トランクの Video Call Traffic Class によって決定されます。SIP トランクは、SIP プロファイルのトランク固有の情報によって次のように設定できます。

イマーシブ:高解像度イマーシブ ビデオ

デスクトップ:標準デスクトップ ビデオ

混合:イマーシブ ビデオとデスクトップ ビデオの組み合わせ

SIP トランクはこれらの 3 つの分類のいずれかに分類でき、ビデオまたは TelePresence マルチポイント コントロール ユニット(MCU)、固定ロケーションのビデオ デバイス、バージョン 9.0 よりも前の Unified CM などの Unified Communications システム、または Cisco TelePresence System Video Communications Server(VCS)を分類する場合に主に使用されます。

帯域予約はエンドポイントの分類およびビデオ コールの SIP トランクの分類によって決定され、 表 11-5 に示されるようにロケーションおよびリンクの帯域幅プールから帯域幅を差し引きます。

 

表 11-5 SIP トランクおよびエンドポイント タイプごとの帯域幅プールの使用

エンドポイント
SIP トランク
使用されるロケーションとリンクのプール

TelePresence エンドポイント

イマーシブ

イマーシブ帯域幅

TelePresence エンドポイント

デスクトップ

イマーシブ帯域幅およびビデオ帯域幅

TelePresence エンドポイント

混合

イマーシブ帯域幅およびビデオ帯域幅

デスクトップ エンドポイント

イマーシブ

イマーシブ帯域幅およびビデオ帯域幅

デスクトップ エンドポイント

デスクトップ

ビデオ帯域幅

デスクトップ エンドポイント

混合

イマーシブ帯域幅およびビデオ帯域幅

非ビデオ エンドポイント

任意

音声帯域幅

デフォルトでは、イマーシブ エンドポイントまたはデスクトップ エンドポイントからのすべてのビデオ コールは、ロケーションおよびリンクのビデオ帯域幅プールから差し引かれます。この動作を変更するには、Unified CM サービス パラメータの Use Video BandwidthPool for Immersive Video Calls False に設定すると、イマーシブ ビデオ帯域幅の差し引きがイネーブルになります。

前述したように、Unified Communications ビデオ エンドポイント(デスクトップ Video Call Traffic Class)と TelePresence エンドポイント(イマーシブ Video Call Traffic Class)の間のビデオ コールは、メディアを非対称にマーキングし、イマーシブ ビデオ CAC がイネーブルな場合、ビデオとイマーシブのロケーションおよびリンクの帯域幅プールから帯域幅を差し引きます。図 11-19 は、これについて説明します。

図 11-19 マルチ サイト配置の Enhanced Locations CAC 帯域幅の差し引きおよびメディア マーキング

 

さまざまなコール フローおよびロケーションとリンクの帯域幅プールの差し引きの例

次のコール フローは、Unified CM サービス パラメータの Use Video BandwidthPool for Immersive Video Calls False に設定される場合の、ロケーションおよびリンクの帯域幅の差し引きの予想される動作を示します。

図 11-20 は、ロケーション L1 の TP-A とロケーション L2 TP-B 間のエンドツーエンド TelePresence のイマーシブ ビデオ コールについて説明します。エンドツーエンド イマーシブ ビデオ エンドポイントのコールは、有効なパスに沿ったロケーションおよびリンクのイマーシブ帯域幅プールから帯域幅を差し引きます。

図 11-20 エンドツーエンド TelePresence イマーシブ ビデオのコール フロー

 

図 11-21 は、ロケーション L1 の DP-A とロケーション L2 DP-B 間のエンドツーエンド デスクトップ ビデオ コールについて説明します。エンドツーエンド デスクトップ ビデオ エンドポイントのコールは、有効なパスに沿ったロケーションおよびリンクのビデオ帯域幅プールから帯域幅を差し引きます。

図 11-21 エンドツーエンド デスクトップ ビデオのコール フロー

 

図 11-22 は、ロケーション L1 のデスクトップ ビデオ エンドポイント DP-A とロケーション L2 の TelePresence ビデオ エンドポイント TP-B 間のビデオ コールについて説明します。デスクトップ ビデオ エンドポイントと TelePresence ビデオ エンドポイント間の相互運用性コールは、有効なパスに沿ってビデオとイマーシブのロケーションおよびリンクの帯域幅プールから帯域幅を差し引きます。

図 11-22 デスクトップから TelePresence ビデオへのコール フロー

 

図 11-23 では、1 つのデスクトップ ビデオ エンドポイントと 2 つの TelePresence エンドポイントが、TelePresence MCU を指定する イマーシブの Video Traffic Class で設定した SIP トランクをコールします。エンドツーエンド イマーシブであるコールのイマーシブのロケーションおよびリンクの帯域幅プールから、およびデスクトップからイマーシブへのコールのビデオとイマーシブのロケーションおよびリンクの帯域幅プールから有効なパスに沿って帯域幅が差し引かれます。

図 11-23 MCU を使用したビデオ会議のコール フロー

 

図 11-24 は、有効なパスに沿ったロケーションおよびリンクのイマーシブ帯域幅プールから帯域幅を差し引く、クラスタ全体でエンドツーエンド イマーシブ ビデオ コールを説明します。

図 11-24 クラスタ間のエンドツーエンド TelePresence ビデオのコール フロー

 

図 11-25 は、有効なパスに沿ったロケーションおよびリンクのビデオ帯域幅プールから帯域幅を差し引きする、クラスタ間のエンドツーエンド デスクトップ ビデオ コールについて説明します。

図 11-25 クラスタ間のエンドツーエンド デスクトップ ビデオ コールのコール フロー

 

図 11-26 は、クラスタ間の TelePresence エンドポイントをコールするデスクトップ ビデオ エンドポイントについて説明します。このコールは、有効なパスに沿ったロケーションおよびリンクのビデオとイマーシブの両方の帯域幅プールから帯域幅が差し引きます。

図 11-26 クラスタ間のデスクトップから TelePresence ビデオへのコール フロー

 

Locations CAC から Enhanced Locations CAC へのアップグレードおよび移行

以前のリリースから Cisco Unified CM 9. x へのアップグレードによって、Locations CAC は Enhanced Locations CAC に移行します。移行は、音声およびビデオ帯域幅のすべての以前に定義されたロケーションの帯域幅限度の取得と、ユーザ定義のロケーションと Hub_None の間のリンクへの移行で構成されます。これは実質的に、Unified CM ロケーション CAC の以前のバージョンがサポートするハブ アンド スポーク モデルを再作成します。図 11-27 は、帯域幅情報の移行について説明します。

図 11-27 Unified CM アップグレード後の Locations CAC から Enhanced Locations CAC への移行

 

Cisco Unified CM 9. x へのアップグレード後の設定

LBM は、Cisco CallManager サービスを実行している各 Unified CM サブスクライバでアクティブになります。

Cisco CallManager サービスはローカル LBM と直接通信を行います。

LBM グループまたは LBM ハブ グループは作成されません。

すべての LBM サービスはフル メッシュです。

クラスタ間の Enhanced Locations CAC はイネーブルになりません。

すべてのロケーション内の帯域幅値は無制限に設定されます。

ロケーションに割り当てられる帯域幅値は、ユーザが定義したロケーションと Hub_None を接続するリンクに移行されます。

イマーシブの帯域幅は無制限に設定されます。

シャドウ ロケーションが作成されます。

Phantom ロケーションおよびシャドウ ロケーションにはリンクがありません。

MTP とトランスコーダの Enhanced Locations CAC 帯域幅調整

挿入をトランスコードするために、ビット レートは接続の各レッグで異なります。図 11-28 は、これについて説明します。

図 11-28 トランスコードのための異なるビット レートの例

 

デュアル スタック MTP 挿入の場合、ビット レートは各接続で異なりますが、帯域幅は IP ヘッダーのオーバーヘッドによって異なります。図 11-29 は、デュアル スタック MTP 挿入に IPv4 および IPv6 ネットワークで使用される帯域幅の違いについて説明します。

図 11-29 デュアル スタック MTP 挿入の帯域幅の違い

 

Enhanced Locations CAC は、MTP とトランスコーダ間の帯域幅のこれらの違いを考慮しません。サービス パラメータの Locations Media Resource Audio Bit Rate Policy は最大帯域幅または最小帯域幅がロケーションおよびリンクのパスに沿って使用される必要があるかを決定します。最低ビット レート(デフォルト)または最高ビット レートは、帯域幅の使用量のこれらの違いを管理するために使用できます。

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-6 に、一般に利用されているいくつかのコール ビット レートにおいて、ゲートキーパーが使用する帯域幅の値を示します。

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

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

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-30 に示す例について考えます。

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

 

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

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 の使用、および CM Enhanced Locations 基づいてコール アドミッション制御から移行するための推奨戦略を取り上げます。

ここでは、分散型呼処理アーキテクチャについて説明します。内容は、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-31 に示す例で説明できます。この図では、デバイス 1(IP アドレス 10.10.10.10)からデバイス 2(IP アドレス 10.60.60.60)に流れるデータ ストリーム用に、アプリケーションがネットワーク リソースを予約しようとします。

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

 

次の手順では、図 11-31 の例に示すように、単一データ フローとしての 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-31 の 10.20.20.20)の CPU が代行受信し、RSVP プロセスに送信されます。RSVP は、このデータ フローのパス状態を作成し、Path メッセージに含まれる session オブジェクト、sender Tspec オブジェクト、および P Hop オブジェクトの値を格納します。次に、P Hop 値を発信インターフェイスの IP アドレス(この例では 10.20.20.20)で置き換えて、メッセージをダウンストリームに転送します。

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

4. 次に、Path メッセージは、RSVP 非対応ルータ(図 11-31 の 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-31 のノード 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-32 は、このタイプの状況を示しています。

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

 

図 11-32 は、企業ネットワークとサービス プロバイダーの 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-33 に示されています。

図 11-33 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-34 に、Cisco IOS ルータから見た、これらの 2 つのアプローチの相違点を示します。

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

 

IntServ モデル

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

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

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

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

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

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

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

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

 

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

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

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

 

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

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

 

RSVP VPN トンネルのサポート

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

手動で構成された総称ルーティング カプセル化(GRE)トンネルおよびマルチポイント総称ルーティング カプセル化(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、ギガビット EtherChannel(GEC)などの柔軟なインターフェイス(またはバンドル インターフェイスとしても知られています)に問題が発生します。この問題とは、スタティックな RSVP 帯域幅量をリンクのバンドルを含む柔軟な帯域幅のインターフェイスで設定すると、1 つまたは複数のリンクに障害が発生して合計帯域幅が低下した場合に RSVP 帯域幅は固定のままになるという問題です。つまり、RSVP 帯域幅と柔軟なインターフェイス帯域幅の合計との比率が設定した値と等しくならなくなり、柔軟な帯域幅のインターフェイスのオーバーサブスクリプションの原因になることがあります。

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

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

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

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

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

 

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

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

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-42 RSVP 対応ロケーションのプロトコル フロー

 

図 11-43 は、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-43 の赤線)。

このコールのメディア ストリームに対しては、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-43 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-44 は、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-44 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 で設定されるリージョン間ビット レートと一致している必要があります。たとえば、8 kbps(G.729)が Unified CM Administration で設定されるリージョン間ビット レートである場合、dspfarm MTP プロファイルでも G.729 コーデックを設定する必要があります。


次の例では、Cisco IOS 2900 シリーズ プラットフォームの 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 7.0+
sccp ccm 20.11.1.51 identifier 2 priority 2 version 7.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
 

RTCP、BFCP および FECC ネゴシエーション用の RSVP Agent のサポート

前述のように、RSVP Agent は、メディアをデコードしないパススルー コーデックをサポートしますが、名前が示しているように、メディアをレイヤ 3 ヘッダーの着信および再発信を通過させます。これにより、Unified CM に定義または使用されるコーデックを RSVP Agent がサポートできるようになります。次の項で説明するように、Cisco Unified CM 9.x および Cisco IOS Release 15.2.1T 以降のリリースでは、Unified CM は RTCP、BFCP、および FECC ネゴシエーションとパススルーをサポートします。

BFCP および FECC パススルー

RSVP Agent(Cisco IOS MTP およびトランスコーダ)と Unified CM は、Binary Flow Control Protocol(BFCP)および遠端カメラ制御(FECC)パススルーをサポートします。以前は、3 つのメディア ポートに制限された RSVP Agent によりメディア ポートがサポートされないため、これは不可能でした。より多くのメディア ポートをサポートすることで、BFCP および FECC ネゴシエーションは現在、RSVP Agent 経由でエンドツーエンドで動作します。図 11-45 は、RSVP Agent の BFCP および FECC のサポートについて説明します。

図 11-45 BFCP および FECC パススルーの RSVP Agent のサポート

 

Unified CM が BFCP および FECC を使用して共有するプレゼンテーションにビデオ コールをネゴシエートするとき、RSVP Agent は BFCP コントロール チャネル、FECC チャネル(ネゴシエートされる場合)、および BFCP によって制御されるプレゼンテーション共有に関連付けられるセカンド ビデオ チャネルをパススルーします。しかし、RSVP Agent はメイン ビデオ チャネルのビット レートの帯域幅だけを予約します。BFCP を使用するエンドポイントは、メイン ビデオのスピードを下げてプレゼンテーション ビデオを許可し、をメイン ビデオとプレゼンテーション ビデオがメイン ビデオへの要求を超える帯域幅を使用しないようにします。メイン ビデオ チャネルがない場合、Unified CM は BFCP を通してネゴシエートされるプレゼンテーション ビデオの帯域幅だけを予約します。後者のシナリオは非常にまれであり、通常、ネゴシエートされたメイン ビデオ チャネルができるため、RSVP Agent による帯域予約は、それに関連付けられます。

BFCP および FECC が RSVP Agent との間でネゴシエートされると、Unified CM は、ポートが使用可能であるため、RSVP Agent からポートを要求します。このポート要求は、Unified CM 要求ロジックにハードコード化されているこの要求に優先順位を持ちます。順位は次のとおりです。

1. 音声

2. メイン ビデオ

3. BFCP コントロール チャネル

4. セカンド ビデオまたはプレゼンテーション ビデオのチャネル

5. FECC チャネル

このプライオリティが始まる例は、RSVP Agent が要求されるよりも少ないポートを提供できるシナリオにあり、その場合、特定の機能がネゴシエーションから除外されます。この例では、RSVP Agent がプレゼンテーションの共有および FECC によってビデオ コール要求に 4 つのポートだけを提供できる場合です。この場合は、FECC がプライオリティで最後であるため、5 チャネルが要求されても、4 チャネルだけが使用可能であるためチャネルを取得しません。

RTCP パススルー

同様に RSVP Agent(Cisco IOS MTP およびトランスコーダ)は BFCP および FECC をサポートし、また、RTCP パススルーもサポートします。RTCP はエンドポイント間でネゴシエートされる最も使用率の高いプロトコルで、音声とビデオの同期を確認する高解像度ビデオ コールでは重要である場合があります。図 11-46 は、RTCP パススルーを使用したビデオ コールについて説明します。

図 11-46 RTCP パススルーを使用するビデオ コール

 

 

Unified CM がトランクまたはエンドポイントを介したビデオ コールをネゴシエートし、RTCP と RSVP の両方をイネーブルにすると、RSVP Agent は、各メディア ストリームの新しい RTCP チャネルを開きます。図 11-46 は、音声とビデオの両方が独立した RTCP チャネルを持つビデオ コールについて説明します。

BFCP、FECC および RTCP をサポートする Cisco IOS メディア リソース(RSVP Agent、MTP およびトランスコーダ)の機能、設計および展開の詳細については、「メディア リソース」の章を参照してください。

RSVP ポリシー

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

No Reservation

RSVP 予約試行は行われず、イネーブルの場合、Enhanced Locations のコール アドミッション制御は、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 とマークされたパケットだけを許可することを推奨します。


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

クラスタ全体の 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 ベースのコール アドミッション制御に移行するには、ネットワーク上で RSVP を設定および展開して、ブランチ ロケーションおよび Unified CM の RSVP Agent を設定および展開し、すべての RSVP 設定が完了後、Unified CM クラスタ全体の RSVP サービス パラメータの Default inter-location RSVP Policy を使用して、すべてのロケーションを直接 RSVP CAC に切り替えることを推奨します。この方法は、切り替えを行う準備が整うまで Enhanced Locations CAC を使用し続けながら、管理者がネットワーク インフラストラクチャと Unified Communications インフラストラクチャの両方で RSVP を完全に展開できます。また、設定ミスの場合に管理者が容易に Enhanced Locations CAC に切り替えることもできます。

Unified CM は最初に RSVP がイネーブルであるか確認し、次に LBM によってロケーションとリンクを確認することに注意してください。CAC メカニズムのこの同時機能は、簡単な移行と、設定に誤りがある場合 Enhanced Location CAC に戻す機能を可能にします。

RSVP と Enhanced Locations CAC の両方がイネーブルの場合にクラスタ内コールに対して発生するイベントの簡潔なリストを次に示します。

1. Unified CM は最初に、ロケーション ペア ポリシー、コール デバイスのロケーションのクラスタ全体の Default inter-location RSVP Policy をチェックします。RSVP がロケーション間でイネーブルになると、Unified CM は、コールの各デバイスの MRGL から RSVP Agent を割り当て、RSVP 予約要求を行います。

2. RSVP Agent が予約要求の結果を返すと、Unified CM は Enhanced Locations CAC がイネーブル(LBM がアクティブ)か確認します。その場合は、Unified CM は有効なパス上の LBM から帯域幅を要求します(エンドツーエンド ロケーションおよびリンク パス)。

3. LBM はパス要求の結果を返し、要求が成功した場合、コールを許可します。

4. LBM がイネーブルまたは使用可能でない場合、Unified CM は、Cisco CallManager サービス パラメータの Call Treatment When No LBM Available を確認します。このパラメータがコールを許可するように設定すると、コールは完了し、コールを拒否するように設定すると、コールは失敗します。

RSVP 移行を計画する際には、次の推奨事項に従ってください。

WAN ネットワーク インフラストラクチャで RSVP を展開します。「WAN ルータでの RSVP と QoS」の項を参照してください。

各支店ロケーションで Cisco RSVP Agent を設定し、該当する各支店の IP Phone およびデバイスに関連付けられた MRG および MRGL に各 RSVP Agent を割り当てます。支店の電話およびデバイスが、同じローカル支店にある RSVP Agent を使用することを確認します。

ロケーションの任意のペア間の各支店ロケーション RSVP が Use System Default で設定されていることを確認します。

Cisco CallManager サービス パラメータの Call Treatment When No LBM Available allow call に設定されていることを確認します。

RSVP 設定と展開が完了したら、 Default inter-location RSVP Policy の Cisco CallManager のクラスタ全体の RSVP サービス パラメータを、 No Reservation から、 Mandatory または Mandatory(Video Desired) などの目的の RSVP ポリシーに変更します。

RSVP がロケーション間のコールで実行されていることを確認した後、Cisco Location Bandwidth Manager(LBM)をディセーブルにできます。

クラスタ内の RSVP サポートが必要な場合、「Enhanced Locations のコール アドミッション制御から RSVP SIP プレコンディションへの移行」の項に示されるように SIP プレコンディション上部の RSVP をイネーブルにします。

何らかの理由で Enhanced Locations CAC に戻る必要がある場合は、Cisco CallManager サービスを実行している Unified CM サーバの LBM サービスをイネーブルにし、Cisco CallManager クラスタ全体の RSVP サービス パラメータの Default inter-location RSVP Policy No Reservation に変更します。

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-47 に、Unified CM がどのように RSVP で音声コールおよびビデオ コールにアプリケーション ID をタグ付けするかを示します。

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

 

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

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

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

RSVP ポリシーを使用してロケーション間でビデオ コールを発信すると、オーディオ ストリームとビデオ ストリームの両方の予約に RSVP Video Application ID のタグが付きます。ビデオ コールでは、音声とビデオの両方が Video Application 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-48 に、このような SIP プレコンディションが汎用 SIP シグナリング コール フローでどのように機能するかを示します。

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

 

図 11-48 では、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 mandatory e2e sendrecv の目的の QoS ポリシー、および e2e recv の設定済みの QoS ポリシー(a=conf:qos)として送信して、要求を受信したことと、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-49 に、分散型 Unified CM 配置でのローカル RSVP を示します。

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

 

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

エンドツーエンド RSVP

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

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

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

 

図 11-50 では、X はクラスタ 1 のエンドポイントを示し、Y はクラスタ 2 のエンドポイントを示し、ICT1 と ICT2 はそれぞれクラスタ 1 とクラスタ 2 に設定されたクラスタ間トランクを示します。それぞれのデバイスに関連付けられた RSVP Agent も示しています。このシナリオでは、Cisco Unified CM が Agent 支店 1 と Agent 支店 2 間に直接エンドツーエンド 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 を経由できるようにすることを推奨します。

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

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

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


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

ステップ 2 SIP クラスタ間トランクをそれぞれ独自のロケーションに配置します。すべてのデバイスが SIP クラスタ間トランク ロケーションとは別のロケーションにあり、どのデバイスにも [Mandatory] または [Mandatory (Video Desired)] のロケーション間 RSVP ポリシーがある必要があります。ロケーション間ポリシーによって、プレコンディションの SIP トランク経由で送信される RSVP ポリシーが決まります ( 表 11-7 を参照。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-51 に、RSVP SIP プレコンディションを使用したコールの発信に関与するコンポーネントを示します。

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

 

図 11-51 に、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-51 の赤線で示した部分)が確立されます。これは、単一クラスタ 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-51 では、クラスタ 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-7 に、Unified CM ロケーション間ポリシーと、対応する SIP オーディオ/ビデオ プレコンディション属性との比較を示します (Unified CM RSVP ポリシーの詳細については、「RSVP ポリシー」を参照してください)。

 

表 11-7 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 プレコンディションをサポートするには、保留音サーバ、アナンシエータ、会議ブリッジなどのメディア リソースそれぞれのデバイス プールのメディア リソース グループ リスト(MRGL)にローカル RSVP Agent を割り当てる必要があります。


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


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

クラスタ間のエクステンション モビリティ(EMCC)を使用すると、あるクラスタのユーザが別のクラスタの IP Phone にログインできます。クラスタ間のエクステンション モビリティの機能、ハイ アベイラビリティ、およびスケーラビリティの詳細については、「クラスタ間のエクステンション モビリティ(EMCC)」を参照してください。EMCC 機能はコール アドミッション制御にも当てはまることであるため、この項で取り上げます。また、「クラスタ間のエクステンション モビリティ(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-52 を参照)。ホーム クラスタは、ユーザの発信側クラスタで、ユーザ情報が格納されます。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-52 に、SIP 対応トランク経由で RSVP を使用した EMCC コールに関与する各種コンポーネント間のシグナリング接続およびメディア接続を示します。

図 11-52 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-53 に、Unified CM のローカル RSVP と、Cisco IOS TDM ゲートウェイおよび Unified CME との統合を示します。

図 11-53 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-54 に、Unified CM と、Cisco IOS TDM ゲートウェイまたは Unified CME との RSVP SIP プレコンディション統合を示します。

図 11-54 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-55 はこのタイプのインターワーキングを示しています。

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

図 11-56 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

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

この項では、さまざまな IP WAN トポロジに対して、コール アドミッション制御メカニズムを適用する方法について説明します。Unified CM Enhanced Locations CAC のネットワーク モデル化のサポートによって、Unified CM は単純なハブ アンド スポークまたは MPLS トポロジのサポートに制限されませんが、現在はクラスタ間の拡張ロケーションとともに、Unified CM 配置モデルのほとんどのネットワーク トポロジをサポートできます。Enhanced Locations CAC は依然としてネットワークを参照しない静的に定義されたメカニズムであるため、ネットワークの変更がアドミッション制御に影響するたびに、管理者は適宜 Unified CM をプロビジョニングする必要があります。これは、ネットワーク障害が発生し、メディア ストリームがネットワークの異なるパスを取る場合などに RSVP などのネットワーク対応のメカニズムが、その間隔を埋めてネットワークの動的変化をサポートできる場合です。これは、ロード バランシングされた二重またはマルチホーム WAN アップリンク、あるいは不等サイズのプライマリおよびバックアップ WAN アップリンクがある設計の場合がよくあります。

Enhanced Locations CAC がどのように機能するか、および Enhanced Locations CAC の設計および展開方法について確認するには、「Unified CM Enhanced Locations コール アドミッション制御」の項を参照します。

ここでは、いくつかの一般的なトポロジを調べ、それらのトポロジを管理するために Enhanced Locations CAC を設計する方法について説明します。

デュアル データセンター設計

図 11-57 は、各リモート サイトに単一の WAN アップリンクがある単純なデュアル データセンター WAN ネットワーク設計について説明します。データセンターは、データ トラフィック用に過剰プロビジョニングされた高速 WAN 接続を介して相互接続します。

図 11-57 デュアル データセンター WAN ネットワーク

 

通常、リモート サイトからデータセンターへのこれらの WAN アップリンクは、ロードバランシングされているかプライマリ/バックアップ設定にあり、これらのシナリオを処理するスタティック CAC メカニズム用の制限方法があります。Enhanced Locations CAC のこのマルチパス トポロジを設定できますが、重みのメトリックが変更されるまで 1 つのパスだけが有効なパスとして計算されてスタティックのままになります。このタイプのネットワーク トポロジをサポートする、よりよい方法は、2 つのデータセンターを Enhanced Locations CAC の 1 つのデータセンターまたはハブ ロケーションとして設定し、各リモート サイト ロケーションに対して単一リンクを設定することです。図 11-58 は、Enhanced Locations(E-L)CAC のロケーションとリンクのオーバーレイについて説明します。

図 11-58 デュアル データセンターの Enhanced Locations CAC のトポロジのモデル

 

設計に関する推奨事項

リモート ロケーションへのリモート デュアルまたはより多くのリンクを持つリモートのデュアル データセンターに関する次の設計上の推奨事項は、ロードバランシング WAN 設計、プライマリ/バックアップ WAN 設計の両方に適用されます。

1 つのロケーション(Hub_None)は、両方のデータセンターを表します。

リモート ロケーションと Hub_None 間の単一リンクは、通常の状態または最高帯域幅容量のリンクの障害時にリモート サイトのアップリンクをオーバーサブスクリプションから保護します。

リモート サイトと Hub_None 間のリンク帯域幅割り当て容量は、単一リンクの適切な Unified Communications メディア用の最低帯域幅容量と同じです。たとえば、各 WAN アップリンクが音声トラフィックによってマークされた EF の 2 Mbps をサポートできる場合、障害状態または等コスト パスのルーティングをサポートするために、リンクの音声帯域幅値は 2 Mbps 以下である必要があります。

MPLS クラウド

E-L CAC ネットワークのモデルでマルチ プロトコル ラベル スイッチング(MPLS)の Any-to-Any 接続タイプのクラウドを設計する場合、1 つのロケーションは MPLS クラウドとして動作できます。このロケーションに関連付けられているデバイスはありませんが、このクラウドにアップリンクを持つすべてのサイトには、ロケーションに設定されたリンクがあります。このように、MPLS クラウドは、他のリモート ロケーションに複数の可変サイズの帯域幅 WAN アップリンクを相互接続するための中継ロケーションとして機能します。ここでは、多数の異なる MPLS ネットワークおよびその同等のロケーションとリンクのモデルを示します。

図 11-59 では、Hub_None は、サーバ、エンドポイントおよびデバイスが配置され、エンドポイントとデバイスだけ配置されているリモート ロケーションがあるキャンパス ロケーションを相互接続する中継ロケーションとして動作する MPLS クラウドを表します。リモート ロケーションから Hub_None への各リンクは、音声、ビデオ、およびイマーシブ メディア用に割り当てられた WAN アップリンクの帯域幅に従ってサイジングできます。

図 11-59 単一 MPLS クラウド

 

図 11-60 は、サーバ、エンドポイントおよびデバイスが配置され、エンドポイントとデバイスだけ配置されているリモート ロケーションがあるキャンパス ロケーションを相互接続する中継ロケーションとして動作する 2 つの MPLS クラウドを示します。キャンパスは、両方のクラウドにも接続されています。リモート ロケーションから MPLS クラウドへの各リンクは、音声、ビデオおよびイマーシブ メディア用に割り当てられた WAN アップリンクの帯域幅に従ってサイジングできます。この設計は、各地理的ロケーションで異なるプロバイダーからの個別の MPLS クラウドを持つ、大陸間にまたがる企業で一般的です。

図 11-60 個別の MPLS クラウド

 

図 11-61 は、各サイトが各クラウドへの 1 の接続を持ち、等コストのロード バランシングされた方法またはプライマリ/バックアップ シナリオで MPLS クラウドを使用する、異なるプロバイダーから複数の MPLS クラウドを示します。どちらの場合でも、この設計は、1 つのロケーションが両方のクラウドを表して単一リンクが 2 つの最低容量のリンクを表すデュアル データセンター設計と同等です。

図 11-61 デュアル MPLS クラウドに接続されたリモート サイト

 

設計に関する推奨事項

MPLS クラウドは、エンドポイントを含まなくてもロケーションを相互接続するハブとして使用されるロケーションとして設定する必要があります。

MPLS クラウドは、他のリモート ロケーションに複数の可変サイズの帯域幅 WAN アップリンクを相互接続するための中継場所として機能します。

デュアル MPLS クラウドへの接続を持つリモート サイトは、その接続を単一リンクとして扱い、ネットワーク障害状態時のオーバーサブスクリプションを回避するためにリンクの最低容量までサイジングする必要があります。

汎用トポロジ

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

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

図 11-62 汎用トポロジ

 

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

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

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

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

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

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

多層アーキテクチャ

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

「集中型の Unified CM 配置」

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

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

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

集中型の Unified CM 配置

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

「単一の Unified CM クラスタ」

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

単一の Unified CM クラスタ

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

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

 

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

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

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

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

各 Cisco RSVP Agent が、そのサイトのすべてのデバイスのメディア リソース グループ リスト(MRGL)のメディア リソース グループ(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-64 では、所定のサイト(本社)にある 2 つの Unified CM クラスタ、およびエンドポイントとゲートウェイを持つ複数のリモート サイトの配置を示しています。これらのリモート サイトは、クラスタ 1(たとえば支店 1)またはクラスタ 2(たとえば支店 2)のいずれかによって制御されます。

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

 

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

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 が、そのサイトのすべてのデバイスのメディア リソース グループ リスト(MRGL)のメディア リソース グループ(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 プレコンディションを有効にします(手順については、「Enhanced Locations のコール アドミッション制御から 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-65 を参照)。このモデルにはハイブリッドおよびバリエーションがいくつか考えられます。これは簡単な設計の概要を示した例にすぎませんが、ベスト プラクティスおよび設計上の考慮事項を踏まえたものです。

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

 

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

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

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

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

各 Cisco RSVP Agent が、そのサイトのすべてのデバイスのメディア リソース グループ リスト(MRGL)のメディア リソース グループ(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 プレコンディションを有効にします(手順については、「Enhanced Locations のコール アドミッション制御から RSVP SIP プレコンディションへの移行」を参照してください)。

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

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

分散型混在呼処理配置

RSVP SIP プレコンディションにより、汎用ネットワーク トポロジで Unified Communications 呼制御アプリケーションを分散配置した環境でコール アドミッション制御を機能させることができます。

ここでは、サポートされている RSVP SIP プレコンディションの配置モデルのリストを示します。これらのモデルにはハイブリッドおよびバリエーションがいくつか考えられます。いずれも有効な設計の概要を示した例にすぎませんが、ベスト プラクティスおよび設計上の考慮事項を踏まえたものです (このような機能の設定の詳細については、特定の製品マニュアルを参照してください)。

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

配置では、音声のみのコールの Unified CME SCCP 統合をサポートします。

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

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

「Unified CM と SIP Cisco IOS TDM ゲートウェイおよび Unified CME との相互運用に関する設計の考慮事項」に記載されている推奨事項に従います。

図 11-66 Unified CM から Cisco IOS ゲートウェイ(TDM)および Unified CME(SCCP)

 

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

次の 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-67 Unified CME から Unified CME、Unified CME から Cisco IOS ゲートウェイ、および Cisco IOS ゲートウェイから Cisco IOS ゲートウェイ

 

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

分散型呼処理配置の Unified CM の場合は図 11-66 に記載されたガイドラインに従い、Unified CME および SIP Cisco IOS TDM ゲートウェイの場合は図 11-67 に記載されたガイドラインに従います。

各 Unified CM クラスタには、一般に Cisco Unified SIP Proxy に向かうトランクが 1 つあります。そのトランクでは、RSVP SIP プレコンディション(エンドツーエンド RSVP)を有効にします。

Cisco Unified SIP Proxy への SIP トランクで RSVP SIP プレコンディションを有効にします(手順については、「Enhanced Locations のコール アドミッション制御から 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-68 Cisco Unified SIP Proxy 経由の RSVP SIP プレコンディションに対応したすべてのコンポーネント

 

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

分散型呼処理配置の Unified CM の場合は図 11-66 に記載されたガイドラインに従い、Unified CME および SIP Cisco IOS TDM ゲートウェイの場合は図 11-67 に記載されたガイドラインに従います。

Service Advertisement Framework(SAF)および呼制御ディスカバリ(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 プレコンディションを有効にします(手順については、「Enhanced Locations のコール アドミッション制御から 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-69 Service Advertisement Framework(SAF)および Call Control Discovery(CCD; 呼制御ディスカバリ)経由の RSVP SIP プレコンディションに対応したすべてのコンポーネント

 

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

ビデオの相互運用性とは、マルチポイント コントロール ユニット(MCU)を必要としない、Cisco TelePresence エンドポイント、Cisco Unified Communications ビデオ エンドポイント、およびサードパーティ製ビデオ エンドポイント間のポイントツーポイント ビデオ コールのサポートのことです。ここでは、Enhanced Locations CAC の機能、および相互運用可能なビデオ コールの Quality of Service(QoS)に適用できる設計上の考慮事項と推奨事項について説明します。

この項では、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 Unified CM 9.0 以降、Cisco TelePresence ソリューションはネットワーク帯域幅を予約し、TelePresence コールのアドミッション制御を行うことができます。TelePresence ビデオの相互運用性を設計する前に Enhanced Locations のコール アドミッション制御(CAC)と RSVP CAC に精通していることが重要です。この項は、TelePresence ビデオの相互運用性に関して、Enhanced Locations 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 ビデオの相互運用性に関して固有のガイドラインはありません。

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

TelePresence ビデオの相互運用性の Enhanced Locations(E-L)CAC を設計する場合は、このセクションに示す設計上の推奨事項と考慮事項に従ってください。

設計に関する推奨事項

次の設計上の推奨事項は、Enhanced Locations(EL)CAC を使用する TelePresence ビデオの相互運用性ソリューションに適用されます。

TelePresence ビデオの相互運用性の E-L CAC は、混在単一クラスタ、専用マルチクラスタ、混在マルチクラスタという 3 つの配置モデルすべてでサポートされます。

Unified Communications ビデオと TelePresence ビデオの相互運用性を導入する場合は、Unified CM サービス パラメータの Use Video Bandwidth Pool for Immersive Video Calls false に設定されていることを確認します。これは、TelePresence コールのイマーシブ帯域幅プールをイネーブルにします。

E-L CAC では、TelePresence エンドポイントを、Unified Communications ビデオ エンドポイントと同じロケーションで管理できます。TelePresence コールが E-L CAC によって追跡されない場合は、イマーシブ ロケーションとリンクの帯域幅プールを unlimited に設定します。これにより、イマーシブに分類された TelePresence または SIP トランクで CAC が行われないようにします。TelePresence コールが E-L CAC によって追跡される場合は、イマーシブのロケーションおよびリンクの帯域幅プールを、ロケーションとリンク パスで許容されるビット レートおよびコール数に応じた値に設定します。

E-L CAC はロケーション ペアでコール アドミッション制御をエンドツーエンドで実行するため、クロス クラスタのコール転送において、エンドツーエンド E-L CAC を実行するためのパス置換の QSIG トンネリングを要求しません。ただし、コール シグナリング パスを最適化できる場合は、QSIG パス置換を使用することを推奨します。これは、複雑なコール転送または転送シナリオのコール シグナリング レッグ数を抑えられるためです。

クラスタ間 SIP トランクはシャドウ ロケーションに関連付けられている必要があります。

UC エンドポイントと TelePresence エンドポイント間では、ポイントツーポイント ビデオ コールのみがサポートされます。ビデオ MCU を使用できない場合、アドホック会議はサポートされません。

Cisco Unified CM では、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 トラフィック クラスに追加されていることを確認します。

UC TelePresence エンドポイントのみを配置し、UC エンドポイントを配置しないサイトの場合、着信 AF41 とマークされたトラフィックに対応し、AF41 とマークされたメディアの QoS 処理を行うために、着信 WAN QoS 設定で AF41 DSCP クラスが CS4 QoS トラフィック クラスに追加されていることを確認します。

設計上の考慮事項

TelePresence ビデオの相互運用可能なコールに対して Enhanced Locations CAC を導入する場合は、両方の QoS クラスの DSCP マーキングの影響を考慮します。

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-70 に、メディア マーキングと帯域幅アカウンティングを示します。

図 11-70 Enhanced Locations CAC を使用したマルチサイト配置での帯域幅の差し引きとメディア マーキング

 

TelePresence ビデオの相互運用性コールの帯域幅アカウンティング

TelePresence および UC で相互運用可能なビデオ コールに対する Enhanced Locations CAC は、図 11-70 に示されるように、ビデオとイマーシブのロケーションおよびリンクの帯域幅プールから帯域幅を差し引きます。これは、QoS で分類されたストリームの両方のタイプが、エンドポイント間のパスの両方向においてメディアに必要な帯域幅を確保するよう設計されたことによります。

Enhanced Locations CAC は、AF41 クラス トラフィックと CS4 クラス トラフィックの両方の双方向メディアに対応します。ただし、非対称にマークされたフローでは、AF41 クラスの十分に割り当てられたビット レートは一方向で使用されますが、他方向で使用されません。一方の方向では、完全な割り当て済みビット レートは CS4 にマーキングされます。これは、追加の帯域幅消費というわけではなく、単に各 QoS クラスのネットワークでのマーキングおよびキューイングの相違です。この方式の帯域幅アカウンティングでは、各方向の各フローを保護する必要があります。

Enhanced Locations CAC と TelePresence 相互運用可能なコールのコール フローの詳細については、「TelePresence イマーシブ ビデオの Enhanced Locations CAC」を参照してください。

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

TelePresence ビデオの相互運用性の RSVP ソリューションでは、目標は、エンドツーエンド UC エンドポイント コールと TelePresence ビデオの相互運用性コールの両方について RSVP CAC を実行することです。一方で、エンドツーエンド TelePresence コールによって RSVP(RSVP Agent)が呼び出されないようにもします。これは、現在はサポートされておらず、特定の TelePresence 機能に障害が発生する可能性があるためです。

RSVP 配置での TelePresence ビデオの相互運用性は簡単に実現でき、Enhanced Locations 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 を実行する

Enhanced Locations CAC と異なり、RSVP は、TelePresence ビデオの相互運用可能なコールの TelePresence エンドポイントと UC エンドポイントの両方に対して CAC を実行します。また、エンドポイント QoS マーキングの上書きも行うので、エージェントからエージェントへの正しい QoS マーキングが行われます。図 11-71 に、この点を示します

図 11-71 RSVP CAC を使用したマルチサイト配置での帯域幅の差し引きとメディア マーキング

 

図 11-71 は、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-72 に示します。

図 11-72 同じサイト内の UC エンドポイントと TelePresence エンドポイント間のコールの RSVP ポリシー設定

 

図 11-72 は、同じ物理サイト内だが別々の CAC ロケーションにある TelePresence エンドポイントと Cisco Unified IP Phone 9900 シリーズ ビデオ電話を示しています。同じ物理サイトまたはキャンパス内の TelePresence エンドポイントと UC エンドポイント間のコールによって RSVP が呼び出されないように、ロケーション ペア ポリシーは no reservation に設定されています。RTP ストリーミングが非対称であることに注意してください。このことは、通常は LAN 上で重要な問題とはなりません。

異なるクラスタ内のエンドポイント間のコールに対しては RSVP が使用される

専用マルチクラスタ配置では、UC エンドポイントと TelePresence エンドポイントが同じ物理サイト内に配置されている場合でも、RSVP を呼び出す必要があります。これは RSVP Agent リソースを利用しますが、メディアは WAN アップリンクを介してルーティングされません。図 11-73 に、この点を示します。

図 11-73 RSVP CAC を使用したマルチクラスタ、単一サイト配置での帯域幅の差し引きとメディア マーキング

 

図 11-73 の 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 つは Enhanced Locations アドミッション制御(CAC)であり、もう 1 つは RSVP 対応ロケーションを使用するリソース予約プロトコル(RSVP)です。この項では、Session Management Edition の配置に固有の設計ガイドラインとベスト プラクティスについて説明します。Enhanced Locations CAC、ロケーションベースの RSVP、または RSVP SIP プレコンディションの基本的な機能については説明しません。次の設計ガイドラインを理解する前提条件として、この章の該当する項を理解しておくことを強く推奨します。

Enhanced Locations CAC を使用する Session Management Edition

Unified CM Session Management Edition(SME)は通常、複数の Unified CM クラスタ、サードパーティ製 UC システム(IP および TDM ベースの PBX)、PSTN 接続、および集中型 UC アプリケーションを相互接続するために使用され、また、ダイヤル プランおよびトランク集約にも使用されます。次に、Enhanced Locations (E-L) CAC で Unified CM SME を展開する場合に従うべき推奨事項と設計上の考慮事項のリストを示します。Unified CM SME に関する詳細については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager Session Management Edition Deployment Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps10661/products_implementation_design_guides_list.html

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

E-L CAC をサポートするすべてのリーフ クラスタは、クラスタ間 E-L CAC を SME でイネーブルにしている必要があります。

SME は、E-L CAC のクラスタ間ハブ レプリケーション ネットワークにおける中央のブートストラップ ハブとして使用できます。詳細については、「LBM のハブのレプリケーション ネットワーク」を参照してください。

E-L CAC をサポートするリーフ クラスタへのすべてのトランクは、シャドウ ロケーションに配置された SIP トランクである必要があります。これは、E-L CAC をサポートするリーフ クラスタと SME 間のトランクで E-L CAC をイネーブルにするためです。

TelePresence ビデオの相互運用性については、「TelePresence ビデオの相互運用性アーキテクチャに関するコール アドミッション制御の設計上の推奨事項」を参照してください。

E-L CAC をサポートする Unified CM 以外のトランクまたはデバイス(例:サードパーティ製の PBX、ゲートウェイ、E-L CAC をサポートしていないリリース 9.0 より前の Unified CM クラスタ、会議ブリッジへのボイス メッセージ ポートまたはトランク、Cisco Video Communications Server など)への SME からの接続は、ファントム ロケーションまたはシャドウ ロケーション以外のロケーションで設定される必要があります。この理由はファントム ロケーションとシャドウ ロケーションの両方が非終端のロケーションであることです。つまり、ロケーションに関する情報を中継し、他のクラスタのユーザ定義のロケーションの効果的なプレースホルダとなります。ファントム ロケーションは、9.0 よりも前の Unified CM のバージョンでロケーション情報の伝送を可能にするレガシー ロケーションですが、Unified CM 9. x Enhanced Locations CAC ではサポートされません。シャドウ ロケーションは、E-L CAC をサポートする Unified CM クラスタ間トランクでエンドツーエンドを実現する特別なロケーションです。

SME は、ロケーションおよびリンクの管理クラスタとして使用できます。この例として、図 11-74 を参照してください。

SME はローカルに設定された最大 2,000 のロケーションをサポートできます。

図 11-74 ロケーションおよびリンクの管理クラスタとしての Unified CM SME

 

図 11-74 は、ロケーションおよびリンクの管理クラスタとしての SME について説明しています。ロケーションおよびリンクのグローバル トポロジ全体は SME で設定および管理され、リーフ クラスタは、エンド デバイスに関連付ける必要があるロケーションだけをローカルに設定します。クラスタ間 E-L CAC がイネーブルで、ロケーションおよびリンクが複製される場合、各リーフ クラスタは SME からグローバル トポロジを受信します。これを自らの設定済みのトポロジの上にオーバーレイし、コール アドミッション制御にグローバル トポロジを使用します。これは、複数のクラスタ間での設定およびロケーション/リンク管理を簡素化し、クラスタ間の設定ミスの可能性を少なくします。設計および展開の詳細については、「ロケーションおよびリンク管理クラスタ」の項を参照してください。

図 11-75 は、クラスタ間 E-L CAC が 1 つ以上のリーフ クラスタでイネーブルにされている場合(右)、および 1 つ以上のリーフ クラスタが 9.0 よりも前の Unified CM バージョンを実行し、従来型のロケーション CAC を実行している場合(左)の SME デザインについて示しています。この種類の展開では、従来型のロケーション CAC で管理されるロケーションを、E-L CAC 有効クラスタ間での共通または共有のロケーションとすることはできません。リーフ 1 は、従来型のハブ アンド スポークに設定され、デバイスがさまざまなリモート サイトで管理されています。クラスタ間 E-L CAC をイネーブルにしている SME および他のリーフ クラスタは、E-L CAC モデル化トポロジで示されるように、グローバル トポロジを共有します。Leaf1_Hub は、リーフ 1 トポロジのハブを表しており、SIP または H.323 クラスタ間トランクに割り当てられた SME のユーザ定義のロケーションです。これにより、リーフ 1 と Leaf1_Hub との間のコールの帯域幅を SME が差し引きできるようになります。このように、リーフ 1 は従来型のロケーション CAC でリモート ロケーションを管理し、一方で SME とリーフ 2 は E-L CAC のロケーションとリンクを管理します。

図 11-75 Enhanced Locations CAC およびリーフ クラスタの従来のロケーション CAC を使用する SME の設計

 

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

QSIG は、Unified CM リーフ クラスタ内の電話機間のコール バック(通話中/無応答時)などの機能を提供する以外に、パス置換機能も提供します。パス置換によって、たとえばコールが 1 つのクラスタから別のクラスタへ転送または自動転送されるときに、クラスタ間のコール シグナリングが最適化されます。E-L CAC を使用する場合、E-L CAC がクラスタ間のロケーションおよびリンクの適切なエンドツーエンドのパスで帯域幅を差し引くため、エンドツーエンドの QSIG パス置換は必須ではありません。それにもかかわらず、QSIG パス置換は、E-L CAC をサポートしないクラスタ間のシグナリング パスの最適化や、サポートされているサードパーティの PBX やゲートウェイに対しても、クラスタ、PBX、またはゲートウェイからの転送または自動転送ごとのトランク シグナリングのヘアピニングを避けるために有益です。クラスタ間トランク上での QSIG の詳細については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager Session Management Edition Deployment Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps10661/products_implementation_design_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-76 に、クラスタ間接続のために 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-76 SIP プレコンディション サポートのないリーフ クラスタを使用した Session Management Edition の配置

 

リーフ 1 とリーフ 2 の間のコール セットアップで、コール フローは次のように動作します(図 11-77 を参照)。

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-76 を参照)。割り当てられたあと、RSVP Agent は、その間のパス上の帯域幅を予約します。

3. 帯域幅の要求が成功した場合、コールは Session Management Edition から、SIP または H.323 クラスタ間トランク上のリーフ 2 まで拡張されます。予約が失敗した場合、コールはリーフ 2 まで拡張されず、Session Management Edition の呼処理の設定に応じて、コールは別の場所に拡張されるか、リーフ 1 から切断されます。

図 11-77 SIP プレコンディション サポートのないリーフ クラスタを使用した Session Management Edition の配置のコール フロー

 

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

ステップ 3 でコールがリーフ 2 に拡張される場合、リーフ 2 はロケーション CAC または RSVP を、そのコール レッグに対するアドミッション制御として使用できます。図 11-77 のように 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 によって管理されるクラスタ間コール

パス置換を使用する QSIG は必須ではありませんが、転送および自動転送されたコール シグナリングを最適化するために、すべての SIP クラスタ間トランク(ICT)でパス置換を使用する QSIG をイネーブルにすることを推奨します(Unified CM 8.5 以降のリリースが必要)。

図 11-78 に、説明したソリューションを示します。ここでは、リーフ クラスタにクラスタ内コール用の Unified CM RSVP 対応ロケーションがあり、Session Management Edition および両方のリーフ クラスタで設定された SIP ICT が RSVP SIP プレコンディションを使用して有効になっています。Session Management Edition は SIP プレコンディションをリーフ Unified CM からリーフ Unified CM に渡し、リーフ Unified CM はそれらのプレコンディションをブランチ RSVP Agent に渡します。このようにして、エンドツーエンド RSVP 予約を複数のクラスタ境界を越えてブランチからブランチへ直接提供します。

図 11-78 SIP プレコンディション サポートのあるリーフ クラスタを使用した Session Management Edition の配置

 

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

Unified CM Session Management Edition は、混在環境をサポートすることもできます。1 つのトランクでは、ローカルでの RSVP および RSVP SIP プレコンディションをサポートするリーフ クラスタへのトランクで RSVP SIP プレコンディションをサポートし(図 11-79 のリーフ 2 の例を参照)、別のトランクでは、Session Management Edition は RSVP Agent を関連付け、RSVP SIP プレコンディションをサポートしないクラスタへのトランクに対して RSVP をローカルに実行します(図 11-79 のリーフ 1 を参照)。

図 11-79 混合リーフ クラスタを使用した 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-80 では、本社サイトで 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-80 リーフ クラスタと共存する Session Management Edition(複数クラスタによる単一プラットフォームの共有)