オンプレミス導入環境での Cisco Collaboration 12.0 エンタープライ ズ向け

はじめに

このプリファード アーキテクチャでは、インターネットとクラウドベース サービス（Webex など）を利用することが、ソリューションの重要な側面となっています。つまり、コラボレーション インフラストラクチャの一部は、マネージド エンタープライズ ネットワーク外部のクラウド内に置かれることになります。企業のオフィスを接続するためのオプションも多岐にわたり、リモート サイトとモバイル ユーザがマネージド専用回線で直接 MPLS に接続するという選択肢から、たとえば Dynamic Multipoint VPN（DMVPN）などのテクノロジーを使用してインターネット経由で接続するという選択肢まであります。C：図 8-2では、クラウド サービスを使用するマネージド（QoS 対応）ネットワーク内の従来のオンプレミス コラボレーション ソリューションと、インターネットなどのアンマネージド（QoS 非対応）ネットワーク上に配置されたサイトをまとめています。オンプレミス リモート サイトは、管理者が QoS でコラボレーション メディアとシグナリングの優先順位を設定できるマネージド ネットワークを経由して接続されます。他のリモート サイトとブランチは、インターネットを経由して企業に接続します。この場合、コラボレーション メディアとシグナリングの優先順位を設定することはできないか、サイトからの発信に対してのみ優先順位を設定できます。また、多くのさまざまなモバイル ユーザとテレワーカーも、インターネットを経由してオンプレミス ソリューションに接続します。このように、企業をリモート サイト、家庭、モバイル ユーザならびに他のビジネスや消費者を結ぶソースとしてインターネットを統合する場合、帯域幅管理とユーザ エクスペリエンスに大きな影響が及びます。

C：図 8-2 マネージド ネットワークとアンマネージド ネットワーク

ここでは、Cisco ビデオ エンドポイントでスマート メディア手法を利用し、エンドツーエンドの QoS アーキテクチャを構築し、帯域幅を管理するための最新の設計と導入推奨事項とベスト プラクティスに従って、利用可能なネットワーク リソースとコラボレーション メディアが経由する各種のネットワークに基づいて最高のユーザ エクスペリエンスを実現するための戦略を紹介します。

コラボレーション メディア

ここでは、音声ストリームとビデオ ストリームの特性と、パケットの損失、遅延、ジッターが発生したとしても高品質のビデオを実現できるよう Cisco ビデオ エンドポイントで採用しているリアルタイム メディア手法とスマート メディア手法について説明します。

音声とビデオの違い

音声とビデオは同様のものとして見なされることがよくあります。どちらもリアルタイム プロトコル（PTP）アプリケーションではあるものの、それ以上の類似点はありません。通常、各パケットのサイズとレートは固定されているため、音声は適切に動作すると考えられています。ビデオ フレームは複数のパケットに広がり、グループとして移動します。1 つのパケットが失われると、P フレームが無駄になり、1 つの P フレームが無駄になると、永続的なアーティファクトが生成されるため、通常、ビデオには音声よりも厳密な損失要件があります。ビデオは非対称です。音声も非対称ですが、通常は対称です。ミュートの場合でも、IP Phone は同じサイズのフローを送受信します。

ビデオでは、平均リアルタイム パケット サイズが増え、ネットワークのトラフィック プロファイルを素早く変更する可能性があります。計画的に行わないと、ネットワーク パフォーマンスに悪影響を与える可能性があります。C：図 8-3 に、一定期間中に送信された一連の音声パケットとビデオ パケットの違いを示します。

C：図 8-3 音声とビデオの違い

C：図 8-3 に示されているように、オーディオ パケットはすべて同じサイズで、まったく同じ間隔で送信されることから、非常にスムーズなストリームになっています。一方、ビデオは一定の間隔で大量のパケットを送信し、フレームごとに大きく異なります。C：図 8-3 に、I フレームと P フレームを比較した場合の、パケット数とパケット サイズの違いを示します。音声と比較すると、非常にバースト性のあるメディア ストリームに変換されます。C：図 8-4 に示されているバースト性は、HD ビデオ ストリームの一定期間にわたる帯域幅プロファイルを表しています。I フレームの送信時にはバーストが大きくなることに注目してください。

C：図 8-4 帯域幅の使用：高解像度ビデオ コール

C：図 8-4 に、720p、30 fps、および 1920 kbps（1792 kbps ビデオ + 128 kbps のオーディオ）で転送された HD ビデオ コールを示します。赤い線は、通話期間中の平均ビット レートを示します。

オーディオとビデオは両方とも UDP で転送され、パケット損失と遅延の影響を受けやすくなっているという点では同様ですが、ネットワーク要件とプロファイルについてかなりの違いがあります。C：図 8-5 に示されているように、オーディオのビット レートは一定であり、ビデオと比べると密度が低くなっています。また、最小ビット レート オーディオ コーデックと最大ビット レート コーデックの 1 つを比較しても、運用範囲の比率は 1:6 と狭くなっています。一方、ビデオのビット レートは可変（バースト性がある）であり、オーディオと比べると高密度です。また、運用範囲も 1:40 と広くなっています（15 fps で 250p、最大 60 fps で 1080p）。

C：図 8-5 ビデオ トラフィック要件とプロファイル

ここでの要点は、オーディオとビデオは、転送およびパケット損失と遅延による影響という点では似ていますが、ネットワークで帯域幅要件を管理するために採用する手法は大きく異なることです。また、ビデオはコラボレーション エクスペリエンス全体に関連しますが、オーディオが重要です。たとえば、ビデオ通話中にネットワークの停止や他のネットワーク関連のイベントによってビデオが失われたり、ビデオ品質が損なわれたりしたとしても、オーディオが失われていない限り通信を継続できます。これは、PA での帯域幅管理に極めて重要な概念です。

「スマート」メディア テクニック（メディアの復元力とレート調整）

管理者が組織全体にパーベイシブ ビデオを導入する際に必然的に直面する問題は、ワイドエリア ネットワーク（WAN）のボトルネック エリアでは、最繁時にビデオのロードを処理するために必要な帯域幅が不足することです。この問題を踏まえると、ビデオに正しく優先順位を付けることが重要となります。優先順位付けで目的とするのは、ビデオのパケット損失によってオーディオが影響されないようにすること、そして輻輳中に帯域幅の使用量を管理できるよう、特定のタイプのビデオでビデオ レート アダプテーションを利用できるようにすることです。メディアの復元力およびレート アダプテーション手法を使用すれば、マネージド ネットワークおよびアンマネージド ネットワークで輻輳やパケット損失が発生したとしても、最適化されたビデオ エクスペリエンスを実現できます。ただし、それだけではありません。これらの手法を QoS と組み合わせた戦略として使用することで、エンドポイントでは、輻輳またはパケット損失の発生時にはビット レートを下げて帯域幅の使用量を削減できるとともに、最繁時以外の時間帯には最大限のビデオ品質を達成するためにビット レートを上げて帯域幅の使用量を増やすことができます。したがって、この方法を取ることによって、組織はパーベイシブ ビデオを導入することが可能になります。

あらゆる Cisco ビデオ エンドポイントには、ネットワークの輻輳の回避、パケット損失からの回復、ネットワーク リソースの最適化に対応するさまざまなスマート メディア手法が使用されています。Cisco ビデオ エンドポイントで使用されているスマート メディア手法には、具体的には以下のものがあります。

• メディア復元力手法

–エンコーダ ペーシング

–段階的なデコーダの更新（GDR）

–修復機能を備えた長時間参照フレーム（LTRF）

–前方誤り訂正（FEC）

• レート アダプテーション

メディア復元力手法

このプリファード アーキテクチャでは、Cisco ビデオ エンドポイントに対して次のメディア復元力手法をサポートしています。

• エンコーダ ペーシング

エンコーダ ペーシングは、パケットを可能な限り均等に分散して帯域幅のバーストのピークを抑制するために使用される単純な手法です。

• 段階的なデコーダの更新（GDR）

GDR は、多数のフレームで画像を徐々にリフレッシュして、よりスムーズでバースト性の低いビット ストリームを提供する手法です。

• 長時間参照フレーム（LTRF）

長時間参照フレーム（LTRF）とは、エンコードとデコーダに保管される参照フレームのことです。この参照フレームを使用することで、ビデオ エンドポイントはパケット損失の際に、ネットワーク パスでより少ない帯域幅を使用して、損失したフレームをより効率的に再送信できるようになります。

• 前方誤り訂正（FEC）

前方誤り訂正（FEC）では、所定のアルゴリズムを使用して、転送される情報に冗長性を与えます。この冗長性により、受信側では、メッセージのいずれかの箇所でエラーが発生した場合でもそれが一定数であれば、送信側に追加データを要求することなく、そのエラーを検出し訂正することができます。FEC では、受信側でエラーを訂正する場合、データの再送信を要求するためのリバース チャネル（RTCP など）は必要ありませんが、その代わりとして、より高い転送チャネル帯域幅（より多くのパケットの送信）が常に必要となります。FEC では最も重要なデータ（通常は修正 P フレーム）が保護されます。これにより、それらのフレームは受信側で確実に受信されます。エンドポイントでは、帯域幅が 768 kbps を下回る場合 FEC は使用されません。また、1.5% 以上のパケット損失が発生していない場合も FEC は適用されません。通常、FEC の有効性はエンドポイントによりモニタリングされます。FEC が有効でない場合は、エンドポイントにより FEC の実行が中止されます。

レート アダプテーション

レート アダプテーション（別名、ダイナミック ビット レート調整）は、使用できる可変帯域幅に合わせてコール レートを調整します。これにより、パケット損失の状況に基づいてビデオ ビット レートの速度が上下します。エンドポイントは、受信側から受け取ったメッセージにパケット損失が発生したことが示されているとビット レートを下げ、パケット損失が減少すると、ビット レートを上げます。

自動調整ビデオ ネットワーク、優先順位付けされたオーディオ、状況対応型ビデオ

自動調整ビデオ ネットワーク、優先順位付けされたオーディオ、状況対応型ビデオは、いずれも QoS の概念であり、QoS 戦略でもあります。自動調整ビデオ ネットワークでは、適切なプロビジョニングおよび QoS と併せ、前述のスマート メディア手法とレート アダプテーションを利用します。これにより、ネットワーク内のビデオ帯域幅が十分に利用されていない間は、ビデオ エンドポイントでビデオ解像度が最大化されるようにするとともに、最繁時にはビット レートのアダプテーションまたはスロットリングを行って、より多くのビデオ フローに対応できるようにします。

音声のみのコールのオーディオとビデオ コールに含まれるオーディオの両方に対してオーディオ優先順位付けを適用すると、ネットワーク内のすべてのオーディオに優先順位が付けられることになります。したがって、ビデオ キューでパケット損失が発生したとしても、その影響は及びません。あらゆるタイプのコラボレーション メディアに含まれる音声に優先順位を付けると、重度の輻輳が発生している間にビデオでパケット損失が発生し、その損失に応じて調整する場合でも、オーディオ ストリームにはパケット損失の影響が及ぶことなく、ユーザのオーディオが中断されません。音声のみのコールのオーディオとビデオ コールに含まれるオーディオの両方に優先順位付けるという手法は、音声コールとビデオ コールを常に同じ QoS でマーキングしていた従来のモデルからのパラダイム シフトです。

状況対応型ビデオを使用すると、ビデオ エンドポイントのグループをマーキングするビデオ クラスを戦略的に低くして、これらのビデオ エンドポイントが使用可能な帯域幅を状況に応じて使用できるようになります。つまり、ネットワークがアイドル状態で、より多くの帯域幅を使用できる場合は、ビデオ解像度を最適化し、逆にネットワークの最繁時に輻輳が発生している間は、優先順位が高いビデオ クラスよりも積極的にビデオ速度を下げるということです。この状況対応型ビデオの概念を優先順位付けされたオーディオと組み合わせることで、許容可能なビデオ エクスペリエンスが維持され、状況対応型ビデオ コールの音声メディアの品質が低下しないようになります。インターネットなどのアンマネージド ネットワークは QoS 対応ではなく、パケット損失に関して何の保証もないことから、この手法が適用されるのは当然、マネージド ネットワークです。それでも、メディア復元力とレート アダプテーションのメカニズムでは、アンマネージド ネットワークで配信されるメディアもパケット損失、遅延、ジッターに際して最大限の品質を保てるよう試みます。

状況対応型ビデオは、優先順位付けオーディオによって自動調整ビデオ ネットワークに付加価値を与える最適な導入オプションですが、自動調整ビデオ ネッワークの機能には必須ではありません。

コラボレーション用の QoS アーキテクチャ

サービス品質（QoS）により、メディア エンドポイントおよびアプリケーションの遅延、パケット損失、ジッターの削減し、信頼性のある高品質な音声とビデオを実現します。QoS は、音声、ビデオ、データ ネットワークの透過的なコンバージェンスをサポートするのに必要な基本的ネットワーク インフラストラクチャ テクノロジーを提供します。インタラクティブ アプリケーション（特に音声およびビデオ アプリケーション）の増加に伴い、多くの場合、ネットワークのリアルタイム サービスが求められます。これらのリソースは限られているため、効率的かつ効果的に管理する必要があります。優先リソースのフロー数に制限がない場合は、これらのリソースがオーバーサブスクライブされるため、すべてのリアルタイム トラフィック フローの品質が低下し、最終的には役に立たなくなります。「スマート」メディアの手法、QoS、およびアドミッション制御により、リアルタイム アプリケーションとその関連メディアが、これらのアプリケーションにプロビジョニングされたネットワークおよび帯域幅をオーバーサブスクライブしないようにします。QoS に関連するこれらのスマート メディアの手法と、必要に応じたアドミッション制御は、リアルタイム メディアを非リアルタイム ネットワーク トラフィックから保護し、ネットワークをオーバーサブスクリプションから保護して、音声とビデオのアプリケーションのエンド ユーザ エクスペリエンスの潜在的な品質低下を回避するための強力なツール セットです。

識別と分類

QoS の信頼と適用

QoS の適用は、リアルタイムの音声またはビデオ エクスペリエンスに必要不可欠です。ネットワークで QoS（分類、優先順位付け、およびキューイング）を適切に処理しないと、リアルタイム メディアに過度の遅延またはパケット損失が発生する可能性があり、リアルタイム メディア フローの品質が低下します。QoS の適用のパラダイムでは、信頼の問題と信頼境界が同様に重要です。信頼とは、エンドポイントまたはデバイスがトラフィックに QoS マーキング（レイヤ 2 CoS またはレイヤ 3 IP DSCP）を適用してネットワークを引き続き通過できるようにすることを許容すること、またはこのマーキングを「信頼」することです。信頼境界は信頼するネットワーク内の場所です。これはネットワーク内のあらゆる場所で設定できますが、LAN アクセス入力や WAN エッジ、または必要に応じてその両方など、ネットワーク エッジで信頼を適用することをお勧めします。

信頼には主に 3 つのカテゴリがあります。

• 信頼できないデバイス — 安全でないPC、Mac、あるいは Jabber クライアント、IP 電話、およびデスクトップエンドポイントを実行する携帯モバイル。
• 信頼されている ：信頼されているデバイスとしては、セキュアな PC およびサーバ、ビデオ会議エンドポイント、アナログ/ビデオ会議ゲートウェイ、PSTN ゲートウェイ、Cisco Unified Border Element、信頼されているアプリケーション サーバ、および他の同様のデバイスが挙げられます。
• 条件付きで信頼できる ：条件付きで信頼できるデバイスには、一般に、Cisco Discovery Protocol（CDP）をサポートするエンドポイントが含まれます。Cisco Room システム、IP 電話、デスクトップ フォンは CDP をサポートしていますが、PA では、これらのデバイスを条件付きで信頼できるデバイスとして扱いません。

PA では、信頼されているスイッチ ポートと信頼されていないスイッチ ポートが使用されますが、条件付きで信頼できるポートは使用されません。PA では次の理由により、条件付きの信頼は推奨されません。

• スイッチの多様性による複雑さ：さまざまなスイッチ タイプで条件付きの信頼を有効にすると、アーキテクチャが複雑化することになります。古いタイプのスイッチの中にはデフォルトで信頼しないものがある一方、新しいタイプのスイッチはデフォルトで信頼するためです。しかも、信頼を有効にするコマンドと、信頼を適用するプロセスは、プラットフォームによって異なります。
• さらに重要な点として、IP フォンとデスクトップ エンドポイントの PC ポートでは、レイヤ 3 DSCP 再マーキングを使用できません。これらのエンドポイントはレイヤ 2 CoS 再マーキングのみに対応します。この点に加え、DSCP レベルでは PC トラフィックを正しく再マーキングできないことから、PA ではアクセス リストを使用して IP フォンとデスクトップ エンドポイントを再マーキングすることが推奨される手法となります。
• 限られた数のポートを信頼されているポートとして指定するよりも、すべてのスイッチ ポートに直接マッピングする単一の ACL を使用したほうが管理が容易になります。

C：図 8-6 に、PA で使用する信頼のタイプと、信頼されているデバイスおよび信頼されていないデバイスを示します。

C：図 8-6 プリファード アーキテクチャでの信頼境界

分類とマーキング

ここでは、エンドポイントの分類とマーキングについて説明します。

すべての Cisco エンドポイントは、Unified CM から DSCP マーキングを取得します。Unified CM では、CallManager サービスのサービス パラメータ（[クラスタ全体のパラメータ（システム - QoS）（Clusterwide Parameters (System - QOS)）]）と SIP デバイスにのみ適用される SIP プロファイルの 2 つの場所にエンドポイントの QoS 設定が保存されます。QoS 設定の SIP プロファイル設定は、サービス パラメータ設定を上書きします。これにより、Unified CM の管理者はエンドポイント グループの異なる QoS ポリシーを設定することができます。エンドポイント登録時に、Unified CM は、この QoS 設定を TFTP 経由で設定ファイルとしてエンドポイントに転送します。この設定ファイルには、QoS パラメータと、他の多くのエンドポイント固有のパラメータが含まれます。ビデオのエンドポイントには、QoS の観点から 2 つのカテゴリが提供されています。 ルーム システム エンドポイント （電話名でテレプレゼンスがあるエンドポイント、通常はルームシステムまたは Webex Room シリーズ、また Webex DX80 等の大規模なデスクトップ ビデオ エンドポイント）、そしてルームシステム以外のビデオ エンドポイント（以下 デスクトップ エンドポイント ）があります。

C：表 8-2 に、プリファード アーキテクチャのエンドポイントとその分類を記載します。

C：図 8-7 では、シスコのビデオ エンドポイントの 2 つのカテゴリが DSCP を取得する方法について示します。これらのカテゴリは、QoS とコール アドミッション制御（CAC）にのみ適用されます。

C：図 8-7 シスコのエンドポイントによる DSCP の取得方法

設定ファイルは、設定時に CallManager サービス パラメータまたは SIP プロファイルの QoS パラメータと統合され、登録時にエンドポイントに送信されます。次に、エンドポイントは、エンドポイントのカテゴリに応じて、メディア ストリームの各タイプに正しい DSCP パラメータを使用します。 C：表 8-3 に、DSCP パラメータ、エンドポイントのタイプ、ストリームの DSCP マーキングを決定するコール フローのタイプを記載します。

信頼されているコア デバイスおよびアプリケーション

エンドポイントと同じく、コラボレーション ポートフォリオに含まれるデバイスとアプリケーションは、メディア ストリームとシグナリング ストリームを発信および終端します。これらの信頼されているアプリケーションがメディアとシグナリングの QoS マーキングを透過的に渡すには、アプリケーション自体だけでなく、アプリケーションが接続先とするスイッチにも適切な設定が必要になります。

信頼されているコア デバイスおよびアプリケーションは次のとおりです。

• Cisco Unified Communications Manager と IM and Presence サービス
• Cisco Expressway
• Cisco Unity Connection
• Cisco Meeting Server
• Cisco IOS SIP ゲートウェイと Cisco Unified Border Element

これらのエンドポイントとアプリケーション サーバを接続するスイッチ ポート上で、DSCP 信頼が有効であることを必ず確認してください。通常、新しい Cisco スイッチのすべてで、デフォルトで QoS DSCP 信頼が有効になっていますが、一部のスイッチ プラットフォームではデフォルトで DSCP を信頼しないため、各スイッチ プラットフォームを確認して、この QoS 信頼が有効かどうかを確認してください。

エンドポイントとクライアント

エンドポイントでは、パケットのスイッチ入力時の DSCO マーキングを、ネットワーク アクセス コントロール リスト（ACL）を使用して再マーキングする必要があります。これは、コラボレーション メディアと SIP シグナリングが適切にマーキングされること、そして他の PC データ トラフィックがベスト エフォートの DSCP（DSCP 0）としてマーキングされるか、または企業で規定する QoS データ ポリシーに応じてマーキングされることを確実にするためです。

この場合に使用する手法では、UDP と TCP ポートなどの特定のプロトコル ポートに応じて識別可能なメディアとシグナリング ストリームをマッピングし、ネットワーク アクセス リストを使用して、そのプロトコル ポート範囲に応じたシグナリングとメディア ストリームの QoS を再マーキングします。Cisco Jabber クライアント（Cisco Jabber for Windows、Cisco Jabber for Mac OS、Cisco Jabber for iPhone、Cisco Jabber for iPad、Cisco Jabber for Android）はメディアとシグナリングにポート範囲を割り当てる際に、すべて同じように動作することから、この手法はすべての Cisco Jabber クライアントに適用されます。Cisco Jabber クライアントとは異なり、IP フォン、8800 シリーズの IP およびビデオ フォン、そして PC ポートを搭載した DX シリーズには、DSCP ならびに UDP ポートに対する追加のマッチング手段が必要となります。その理由は、IP フォンとビデオ エンドポイントはオーディオとビデオの両方に同じ UDP ポート範囲を使用するため、オーディオとビデオを区別するには、UDP ポート範囲と DSCP の両方に対するマッチングを行い、メディア トラフィックを適切に識別できるようにしなければならないためです。

この概念はシンプルです。ネットワーク アクセス レイヤの装置（スイッチ）内でアクセス リストを使用して、UDP ポート範囲と DSCP のマッチングを基にメディア ストリームとシグナリング ストリームを識別した上で、適切な DSCP 値に再マーキングするようにスイッチを設定します。この手法は簡単に実装でき、広範に導入することができます。ただし、これは 100% セキュアな手段ではないことに注意してください。この PA では、ネットワークへの適切なアクセスを確保するとともに、オペレーティング システム（OS）関連の QoS 設定をユーザが改ざんできないよう、Jabber に使用する PC や Mac 上の OS をセキュリティで保護するために、他のセキュリティ対策を実装することを前提としています。

C：図 8-8 に、ネットワーク アクセス コントロール リスト（ACL）を使用して、識別可能なメディアとシグナリング ストリームを Jabber クライアントの DSCP にマッピングする方法を示します。

C：図 8-8 エンドポイントのマーキング

C：例 8-1 C：図 8-8 に示されている信頼されていないエンドポイントに対する ACL ベースの QoS ポリシー切り替え

• Jabber クライアント

–UDP ポート範囲 3xxx に一致 –> DSCP EF として再マーキング

–UDP ポート範囲 5xxx に一致 –> DSCP AF42 として再マーキング

–TCP ポート 5060 または 5061 に一致 –> DSCP CS3 として再マーキング

• IP フォンとビデオ エンドポイント

–UDP ポート範囲 17xxx と DSCP EF に一致 –> DSCP EF として再マーキング

–UDP ポート範囲 17xxx と DSCP AF41 に一致 –> DSCP AF41 として再マーキング

–TCP ポート 5060 または 5061 に一致 –> DSCP CS3 として再マーキング

• 汎用マッチング

–残りのトラフィックをマッチングし、デフォルトのクラス マップを使用して DSCP を 0（ベスト エフォート（BE））として設定

エンドポイントが送受信するデータとシグナリングは他にもあります（ICMP、DHCP、TFTP、BFCP、LDAP、XMPP、FECC、CTI など）。このようなトラフィックの QoS 値は、トラフィックのタイプに応じた企業のベスト プラクティスに従う必要があります。この手順を行わないと、メディアと SIP シグナリング以外のすべてのトラフィックの DSCP は、この設定でのクラスのデフォルトによって BE（DSCP 0）に設定されます。DSCP に基づくマッチングでマーキングしたトラフィックを通過させてから、DSCP を同じ値に再マーキングするか、エンドポイントが通信に使用するプロトコルごとに TCP および UDP ポートを使用することを推奨します。

Cisco Jabber クライアントの QoS

前述したように、この方法では、IP アドレス、プロトコル、プロトコル ポート範囲に応じて Jabber クライアントからのさまざまなストリームを特定することで、メディアとシグナリングを分類します。いったん特定されると、シグナリングとメディア ストリームは、対応する DSCP で分類および再マーキングできます。プロトコル ポート範囲は Unified CM で設定し、デバイス登録時に使用するエンドポイントに転送されます。次にネットワークをアクセス コントロール リスト（ACL）経由で設定し、IP アドレス、プロトコル、プロトコル ポート範囲に応じてトラフィックを分類し、前のセクションで説明したように、適切な DSCP で分類したトラフィックを再マーキングできます。

Cisco Jabber は、UDP プロトコル ポート範囲に応じて識別可能なメディア ストリームおよび TCP プロトコル ポート範囲に応じて識別可能なシグナリング ストリームを提供します。Unified CM では、エンドポイントのシグナリング ポートは SIP セキュリティ プロファイルで設定しますが、メディア ポート範囲は Unified CM の管理ページの SIP プロファイルで設定します。

メディア ポート範囲の場合、すべてのエンドポイントおよびクライアントは、SIP プロファイル パラメータの [メディア ポートの範囲（Media Port Ranges）] を使用して、メディアで使用される UDP ポートを取得します。デフォルトでは、メディア ポート範囲は [オーディオおよびビデオ用コモンポートの範囲（Common Port Range for Audio and Video）] で設定します。設定ファイルで Jabber クライアントにこのポート範囲が割り当てられると、Jabber クライアントはポート範囲を半分に分割し、オーディオとビデオの両方のコールのオーディオ ストリームに前半の範囲を使用し、ビデオ コールのビデオ ストリームに後半の範囲を使用します。C：図 8-9 でこれについて説明します。

C：図 8-9 メディアとシグナリングのポート範囲：共通

Jabber では、[メディアポートの範囲（Media Port Ranges）] > [オーディオとビデオのポート範囲の分割（Separate Port Range for Audio and Video）] の設定も使用できます。この設定では、Unified CM の管理者は、C：図 8-10 に示すように連続しないオーディオとビデオ ポートの範囲を指定できます。

C：図 8-10 メディアとシグナリングのポート範囲：分割

注意 セキュリティ警告：ネットワーク レベルで QoS 分類に識別可能なメディア ストリームを使用すると、信頼モデルがアプリケーション自体に拡張されることは ありません。目的のアプリケーションのストリームに優先順位を付けること以外に、同じ識別基準（メディア ポート範囲）を使用するように他のアプリケーションを潜在的に設定できるため、ネットワークの優先順位付けを実現できる 可能性があります。この目的外のトラフィックはコール アドミッション制御やネットワークのプロビジョニングで考慮されないため、リアルタイムの会話全体に深刻な影響を与える可能性があります。このことから、メディア ストリームを識別するには、できるだけ限られたポート範囲を使用することが推奨されます。

---

この手法を使用する場合、オーディオ トラフィック クラス（EF）として再マーキングされるこれらのビデオ コールのオーディオ部分、およびビデオ トラフィック クラス（AF4）に再マーキングされるビデオ部分が、状況に応じてネットワーク内でプロビジョニングされるようにすることが重要です。C：図 8-11 に、オーディオ トラフィックをプライオリティ キュー（PQ）に入れ、ビデオ トラフィックをクラスベースの重み付け均等化キュー（CBWFQ）に入れる例を示します。PQ と CBWFQ の組み合わせは、低遅延キューイング（LLQ）とも呼ばれます。Cisco Jabber エンドポイントでは、ポート範囲を使用して音声のみのコールのオーディオとビデオ コールに含まれるオーディオを区別することはできないため、この手法を使用するすべてのオーディオは EF として再マーキングされることに注意してください。音声のみのコールのオーディオとビデオ コールに含まれるオーディオをサポートするには、PQ を適切にプロビジョニングすることが重要です。C：図 8-11 に、このプロビジョニングの例を示します。ネットワーク内でキューイングとスケジューリングをプロビジョニングする際の設計および導入に関する推奨事項については、「WAN キューイングとスケジューリング」を参照してください。

C：図 8-11 ネットワークでの Jabber QoS のプロビジョニング

RFC 3551 に準拠して、RTCP がエンドポイントで有効な場合は、次に大きな奇数のポートが使用されます。たとえば、ポート 3500 で RTP ストリームを確立するデバイスは、ポート 3501 で同じストリームの RTCP を送信します。RTCP のこの機能は、すべての Jabber クライアントにも当てはまります。RTCP はほとんどのコール フローに共通しており、ストリームの統計情報用として一般的に使用され、ビデオ コールのオーディオとビデオを同期して適切なリップシンクを実現します。ほとんどの場合、ビデオおよび RTCP は、エンドポイント自体または電話の共通プロファイル設定で有効または無効にできます。

分類とマーキングでのネットワークの活用

エンドポイントで作成された識別可能なメディアおよびシグナリング ストリームに基づいて、トラフィック クラスを作成し、それらのクラスに応じてパケットを再マーキングするには、共通ネットワーク QoS ツールを使用できます。

これらの QoS メカニズムは、アクセス レイヤ（アクセス スイッチ）などの異なるレイヤで適用できます。これは、ディストリビューション、コア、またはサービスの WAN エッジのエンドポイントおよびルータ レベルに最も近いレイヤです。分類および再マーキングの実行場所に関係なく、エンドツーエンドの Per-Hop Behavior を実現するために DSCP を使用することをお勧めします。

前述したように、Cisco Unified CM により、SIP エンドポイントで利用されるポート範囲は、SIP プロファイルで設定できます。一般的なルールとして、少なくとも 100 ポート（たとえば、3000 ～ 3099）のポート範囲であれば、ほとんどのシナリオには十分です。各種の音声ポート、ビデオ ポート、および関連する RTCP ポート（RTCP はポート範囲の奇数のポートで動作します）に対応できるだけのポート数があり、それらのポートを使用するデバイスのオペレーティング システムで、ポート コリジョンの原因となるような他のアプリケーションとのポート競合がない限り、これよりも小さいポート範囲を設定するこもできます。

アクセス レイヤ（レイヤ 2 定義）

トラフィックの分類にアクセス レイヤを使用する場合、ネットワークへのトラフィックの入力時に分類が行われるため、入力に合わせてフローが識別されます。QoS ポリシーが WAN と LAN 内にも適用される環境では、すべてのアップストリーム コンポーネントが、処理時にトラフィック マーキングを使用できます。入力時の分類により、各種エンドポイントに応じてさまざまな方法を使用できます。

ネットワークのアクセス レイヤで QoS ポリシーを設定すると、大量のデバイスの設定が必要になる場合があるため、新たな運用上のオーバーヘッドが発生する可能性があります。QoS ポリシー設定は、テンプレートを通じてアクセス レイヤの各種スイッチ全体で標準化する必要があります。設定導入ツールを使用すると、手動設定の負担を軽減できます。PA ではこのプロセスを簡素化するために、各種のスイッチング プラットフォームで単一の ACL グループを使用できるようになっています。

ディストリビューション/コア/サービスの WAN エッジ（レイヤ 3 定義）

QoS マーキングが行われる場所は、レイヤ 3 のルート設定済み境界にあります。キャンパス ネットワークでは、レイヤ 3 は、アクセス、ディストリビューション、コア、またはサービス WAN エッジ レイヤでもかまいません。推奨される手法は、アクセス レイヤで分類して再マーキングを適用した上で、ネットワークのディストリビューションとコアを介して信頼し、最後に必要に応じて WAN エッジで再分類して再マーキングすることです。小規模なネットワーク（レイヤ 3 スイッチング コンポーネントを導入していない支店など）の場合、QoS マーキングは WAN エッジ ルータで適用できます。レイヤ 3 では、QoS ポリシーがレイヤ 3 ルーティング インターフェイスに適用されます。ほとんどのキャンパス ネットワークでは、VLAN インターフェイスですが、ファスト イーサネットまたはギガビット イーサネット インターフェイスの場合もあります。C：図 8-12 に、ネットワーク内の場所（アクセス、ディストリビューション、コア、または WAN エッジ）に応じて、さまざまなタイプの信頼が適用されるネットワークの領域を示します。

C：図 8-12 信頼と適用：ネットワーク内の場所

エンドポイントの識別と分類の考慮事項と推奨事項

以下に、設計と導入に関する考慮事項と推奨事項をまとめます。

• DSCP マーキングは IP レイヤにエンドツーエンドで適用され、レイヤ 2 マーキングよりも詳細で拡張性に優れているため、可能な限り DSCP マーキングを使用してください。
• できるだけエンドポイントの近くにマーキングします。LAN スイッチ レベルがお勧めです。
• Cisco Jabber クライアントで使用するメディア ポート数を最小限に抑える場合、最小範囲として 100 個のポートを使用することが推奨されます。これは、RTCP、オーディオとビデオ用の RTP、BFCP、デスクトップ共有セッションのセカンダリ ビデオ用の RTP など、すべてのストリームに十分なポートを割り当て、同一コンピュータ上の他のアプリケーションと重複しないようにするためです。
• QoS ポリシーに、他の関連するコラボレーション トラフィックが再マーキング対象として含まれるようにします。再マーキング対象になっていないと、これらすべてのトラフィックに値 0（ベスト エフォート（BE））が設定されます。

WAN キューイングとスケジューリング

「識別と分類」で説明したように、Unified CM ではビデオ エンドポイントのタイプと、それぞれのメディア ストリームを区別することができます。このため、ネットワーク管理者はネットワーク内で、エンドポイントのタイプによってビデオを異なる方法で処理できます。PAで推奨される方法は、JabberクライアントにはAF 42 DSCPマーキングを使用し、すべてのデスクトップおよびルームシステムのビデオエンドポイントにはAF 41を使用することです。これらの値は、RFC 4594 に準拠しています。別の方法として、すべてのビデオ エンドポイントで AF41 を使用することもできます。ただし、この方法を取ると、ビデオ エンドポイントの状況対応型クラスによってもたらされる利点がなくなり、同じクラスが設定されたすべてのビデオ エンドポイントが平等にビデオ帯域幅を取得しようと争うことになります。

PA のキューイングおよびスケジューリング手法（単一のビデオ キュー）

PA では、統合コラボレーション メディアおよびデータ ネットワーク全体で各種のビデオを管理するために、ドロップ確率が異なる複数の DSCP で単一のレートベースのキューを使用します。このアプローチでは、WAN のビデオ トラフィックのスケジューリングに対して単一のビデオ キューを設定し、そこに AF41 と AF42 を使用して 2 つの AF4 ドロップ確率を設定します。この場合、AF42 のドロップが優先され、AF41 よりも高い確率でドロップされます。階層型廃棄優先のこのサービス クラスを使用する単一のビデオ キューでは、あるクラスのビデオがキュー内の帯域幅を使用していない場合、キューの残りの帯域幅を他のビデオ クラスで使用できることが前提となります。このアプローチでは、輻輳が発生している間、ビデオ専用に予約された帯域幅をビデオ キューだけが使用できるようになります。デュアル レートベースのビデオ キューといった他のアプローチは、あるキューからの余剰ビデオ帯域幅をインターフェイス上のすべてのキューに均等に割り当てるという、準最適な方法です。

最適化されたビデオ帯域幅使用率に関する多くの異なる戦略は、階層型 DSCP 廃棄率を使用するこの単一ビデオ キューに基づいて設計することができます。ただし、PA のアプローチは、C：図 8-13 に示すとおりです。

C：図 8-13 単一ビデオ キュー手法

C：図 8-13 では、音声コールのオーディオは EF とマーキングされ、PQ がこのトラフィックに割り当てる帯域幅に関する厳格なポリサーを使用して、プライオリティ キュー（PQ）に配置されます。ビデオ コールは、優先順位付けされたビデオの AF41 と、状況対応型または Jabber ビデオの AF42 という 2 つのクラスに分けられます。重み付けランダム早期検出（WRED）で CBWFQ を使用すると、管理者は、AF41 に対して AF42 の廃棄優先度を調整できるため、キューがいっぱいになって輻輳が発生したとき、AF42 パケットが AF41 よりも高い確率でキューから廃棄されます。WRED の機能について詳しくは、最新バージョンの Cisco Collaboration SRND に記載されている「 Network Infrastructure 」のセクション「 WAN Quality of Service 」を参照してください。

上記の例には、管理者が、すべてのビデオに対して DSCP ベースの WRED と単一 CBWFQ を使用し、輻輳時のパケット損失から、特定のタイプのビデオ（優先ビデオ）を別の種類のビデオ（状況対応型ビデオを参照）に優先して保護する方法が示されています。この 単一ビデオ キュー手法 では、 デュアル ビデオ キュー手法 とは異なり、ある種類のビデオがキューの帯域幅を使用していない場合、他の種類のビデオが、必要に応じてキューの帯域幅全体の完全なアクセス権を得ることになります。パーベイシブ ビデオを導入する場合、この手法は顕著な改善をもたらします。

ソリューション全体でこの手法を実現するためには、いくつかの条件があります。すべてのオーディオの DSCP を EF としてマーキングするために必要な条件は、次のとおりです。

• 顧客機器（CE）またはサービス プロバイダー（SP）所有の WAN 機器で、AF41 と AF42 両方の QoS マーキングを含む AF4 QoS と、重み付けランダム早期検出（WRED）をサポートしている必要があります。
• すべてのオーディオの EF マーキングと併せ、Enhanced Locations Call Admission Control（ELCAC）を実装できなければなりません。ELCAC は適切な DSCP 設定に依存して、音声およびビデオ CAC プールが表すキューが保護されるようにします。ビデオ コールのオーディオ ストリームの DSCP を変更するには、ELCAC がビデオ コールの帯域幅を差し引く方法を更新する必要があります。それには、CallManager サービスのコール アドミッション制御セクションで、サービス パラメータ [ビデオ コールのオーディオ プールからオーディオ帯域幅を差し引く（Deduct Audio Bandwidth from Audio Pool for Video Call）] を [はい（True）] に設定します。このパラメータは、[はい（True）] または [いいえ（False）] に設定できます。

–[はい（True）]（推奨）：Cisco Unified CM は、ビデオ コールのオーディオとビデオの帯域幅割り当てを個別のプールに分けます。ビデオ コールのオーディオ部分の帯域幅割り当てはオーディオ プールから差し引かれ、ビデオ コールのビデオ部分はビデオ プールから差し引かれます。

–[いいえ（False）]（デフォルト）：Cisco Unified CM は従来の動作を適用します。ビデオ コールのオーディオとビデオの帯域幅割り当てをビデオ プールから差し引きます。これがデフォルトの設定です。

状況対応型ビデオ

組織全体で広範囲にビデオを導入する場合、帯域幅の一般的な制約により、利用可能な帯域幅および最繁時のビデオ コールの数に基づいて、一日の最繁時に実現できるビデオ解像度が決まります。PA ではこの課題に対処するために、ネットワークで状況に応じてビデオが処理されるエンドポイントのグループを対象に、DSCP ベースの WRED に Jabber クライアントのコラボレーション メディアの識別および分類戦略を組み合わせた単一のビデオ キューを使用します。

状況対応型ビデオは、任意の時点で利用可能な WAN 帯域幅リソースに応じて、最善のビデオ品質を実現します。これを実現するには、いくつかの要件を満たす必要があります。

• 状況対応型ビデオ エンドポイント グループを選択します。PA では、状況対応型ビデオ エンドポイントとして Jabber クライアントを使用します。
• WAN に、ドロップ優先度が AF41 および AF42 の AF4 DSCP クラス サービスで DSCP ベースの WRED を使用する単一のビデオ キューを設定するようにしてください(AF43 を使用することもできますが、PA で必要な DSCP の値は 2 つだけです）。
• AF42 を使用する状況対応型エンドポイントのビデオを識別して分類します。
• AF41 を使用する他のすべてのビデオ エンドポイントも識別して分類します。

注 エンタープライズ WAN エッジで AF42 マーキングとスケジューリングを使用できない場合は、すべて のビデオに AF41 を使用できます。その場合、この文書で AF42 に設定されている値をすべて AF41 に変更すると、状況対応型ビデオのメリットが最小限になります。AF41 マーキングだけを使用する場合、すべて のビデオが同じようにリソースを取得しようと争い、自動調整ビデオ ネットワークの使用状況に基づいて、同じようにレートを調整します。これにより、設定が簡素化されることにもなります。ただし、このドキュメントでは、Jabber を状況対応型ビデオ エンドポイントとして AF42 でマーキングするために必要な導入手順を説明します。

プロビジョニングとアドミッション制御

帯域幅をプロビジョニングし、適切なビット レートがさまざまなエンドポイント グループ間でネゴシエートされるようにすることは、帯域幅管理の重要な側面です。Unified CM 環境では、ビット レートは Unified CM を介してネゴシエートされます。Unified CM ではリージョンの概念を使用し、特定のコール フローの最大オーディオ ビット レートおよび最大ビデオ ビット レートを設定します。ここでは、ビデオ コールの最大ビット レートに注目します。

Unified CM のロケーション（拡張ロケーションのコールアドミッション制御 を参照）は、リージョンとの組み合わせで、コール フローの特性を定義します。リージョンは、2 つのデバイス間で使用される圧縮とビット レートの種類（8 kbps または G.729、64 kbps または G.722/G.711 など）を定義します。ロケーション リンクは、デバイス間のパスで利用可能な帯域幅の容量を定義します。システム内の各デバイスおよびトランクを（デバイス プールを使用して）リージョンに割り当て、（デバイス プールまたはデバイス自体に直接設定した値を使用して）ロケーションに割り当てます。

• リージョンにより、ビデオ コールの帯域幅を設定できます。リージョンのオーディオ制限により、高いビット レートのコーデックが除外される可能性があります。ただしビデオ コールでは、ビデオの制限により、ビデオの品質（解像度と転送速度）が抑制されます。
• ロケーションは、対象のリンクのすべてのコールで利用可能な総帯域幅の容量を定義します。リンク上でコールが確立すると、そのリンクで許可された総帯域幅からそのコールのリージョンの値を差し引く必要があります。

デバイス グループの最大ビデオ ビット レート（ビデオ解像度）を管理するリージョン マトリックスを作成すると、特定のデバイス グループがネットワーク帯域幅を過剰に使用しないようにすることができます。リージョン マトリックスを作成する際は、次のガイドラインが適用されます。

• 最大ビデオ ビット レート カテゴリにデバイスをまとめます。
• グループの数が少ないほど、帯域幅要件の計算が簡単になります。
• デフォルトのリージョン設定を検討し、マトリックスを簡単にして、リージョン内およびリージョン間のデフォルト値を入力します。
• 組織全体（LAN と WAN の両方）で単一のオーディオ コーデックを使用して、リージョン マトリックスを簡素化します。

リージョン設定の詳細については、「拡張ロケーションのコールアドミッション制御」を参照してください。

C：表 8-5 に、3 つのデバイス グループでのビデオ セッションの最大ビット レート リージョン マトリックスの例を示します。

注 C：表 8-5 は、デバイスのグループ化方法と、デバイス グループ間の通常の解像度に適した最大ビット レートのほんの一例です。

C：表 8-5 の例で使用されている 3 つのグループは次のとおりです。

• Video_1.5MB

これらのクライアントは、一般に、導入済みビデオ対応エンドポイントの最大規模のグループになるため、状況対応型ビデオの手法によるメリットがもたらされます。状況対応型ビデオとして分類されると、レートが最大 1,500 kbps（720p @ 30 fps）まで上がり、パケット損失に応じてレートが下方調整されます。

• Video_2.5MB

これらのデバイスは、Cisco TelePresence MX または SX シリーズなどのルーム システム、あるいは Cisco DX シリーズなどのデスクトップ エンドポイントとなります。これらのエンドポイントは、2,500 kbps の最大ビデオ ビット レートで、通常は 720p @ 30 fps に対応可能です。

• Video_20MB

このクラスは、Webex Room シリーズ、Cisco Meeting Server、MCU 等の大規模なルームシステム エンドポイント向けに、エンドポイントが最高解像度とフレーム/秒 (FPS) で実行できるように、最大 20 Mbps に設定されています。マルチスクリーン システムではより多くの帯域幅を使用し、単一画面システムで使用される帯域幅は遥かに少なくなりますが、このグループは、最大ビット レート容量を使用するデバイスに適用されます。

リージョンの設定を簡素化するには、組織全体にわたって使用する 1 つのオーディオ コーデックを基準に標準化することが重要となります。最初の考慮事項は、サイト間のオーディオ コールに低いビット レートのコーデックを使用するかどうかを決定することです。従来、企業では帯域幅管理の一環として、WAN では G.729 などの低いビット レートのコーデックを使用し、LAN や MAN 内でのコールには、ビット レートが高く、バンドの範囲がより広い G.722 などのコーデックを使用していました。通常、コールあたり 2.5 MB でビデオを導入する場合、（コールあたり 80 kbps でも）オーディオが消費する帯域幅はかなり少ないため、企業は組織全体（LAN および WAN）で、ビット レートが高く、より品質に優れたコーデック（G.722 など）を使用する傾向にあります。この決定は、リージョン マトリックスと、サイトごとのリージョンが必要であるかどうかに影響します。ここでの考え方として、リージョン内のオーディオまたはビデオのに異なるビット レートを設定する場合は、サイトごとにリージョンを設定する必要があります。このため、リージョンの設定は、次のようにサイトの数（N）にビデオ グループの数（X）を掛けた値まで増えます。

必要な平均リージョン数 = N∗X

WAN と LAN でオーディオ ビット レートを同じにする場合は、ビデオ グループのリージョンのみが必要となります（X）。

拡張ロケーションのコールアドミッション制御

コール アドミッション制御機能は、特に複数のサイトが IP WAN 経由で接続され、オーディオ コールとビデオ コールで使用可能な帯域幅リソースが制限されている場合、コラボレーション システムの重要なコンポーネントとなります。

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

Unified CM の Enhanced Locations Call Admission Control

Cisco Unified CM では、Enhanced Locations Call Admission Control（ELCAC）を提供し、複数のクラスタが同じ物理サイトのデバイスを同じ WAN アップリンクを使用して管理している、複雑な WAN トポロジと、Unified CM の分散型配置でのコール アドミッション制御をサポートします。

より複雑な WAN トポロジをサポートするために、Unified CM はロケーション ベースのネットワーク モデリング機能を実装しています。これは、発信側と着信側の間のマルチ ホップ WAN 接続をサポートする機能を Unified CM に提供します。このネットワーク モデリング機能は、段階的にマルチ クラスタの分散型 Unified CM 配置をサポートするように強化されました。これにより、クラスタ全体で同じロケーションに割り当てられた帯域幅を予約、解放、および調整するためにクラスタが相互に通信できるようにすることで、各クラスタがロケーションを「共有」することが可能になります。

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

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

管理者がロケーションとリンクを使用してネットワーク モデルを構築できるように、拡張 CAC は次の設定コンポーネントを組み込みます。

• ロケーション：ロケーションは LAN を表します。これは、エンドポイントを含み、または単に WAN ネットワークのモデル化に対してリンク間の中継場所として機能します。たとえば、MPLS プロバイダーはロケーションで表される可能性があります。
• リンク：リンクはロケーションを相互接続し、ロケーション間で利用可能な帯域幅を定義するために使用されます。リンクは論理的に WAN リンクを表し、ロケーションのユーザ インターフェイス（UI）に設定されます。
• 重み：重みは、ロケーションのペア間に有効なパスを構成するリンクの相対的なプライオリティを与えます。有効なパスは、帯域幅の計算に Unified CM で使用するパスであり、すべての可能なパスにある最小の累積重みが設定されます。重みは、「有効なパス」に「コスト」を提供するためにリンクで使用され、任意の 2 地点間に複数のパスがある場合にだけ該当します。
• パス：パスはロケーション ペアを接続するリンクおよび中間場所のシーケンスです。Unified CM では、各ロケーションから他のすべてのロケーションへの最小コスト パス（最も小さい累積的な重み）をパス計算し、さまざまなパスへのマップを構築します。1 つの「有効なパス」だけがロケーションの任意のペア間で使用されます。
• 有効パス：有効パスは、累積的な重みが最も小さいパスであり、任意の 2 つのロケーション間で常に使用される、帯域幅を考慮したパスです。
• 帯域割り当て：オーディオ、ビデオの各トラフィック タイプ用のモデルで割り当てられる帯域幅。
• Location Bandwidth Manager（LBM）：1 つ以上のクラスタで設定されているロケーションとリンク データからネットワーク モデルを組み立てる、Unified CM でのアクティブなサービス。このサービスでは、2 つのロケーション間の有効なパスを決定し、コールのタイプごとの帯域幅の可用性に基づいて 2 つのロケーション間のコールを許可するかどうかを決定し、許可された各コールの実行期間の帯域幅を差し引きます（予約します）。
• Location Bandwidth Manager ハブ：固定ロケーション、リンクのデータおよびダイナミック帯域幅割り当てのデータのクラスタ間のレプリケーションに直接参加するように指定された Location Bandwidth Manager（LBM）サービス。LBM のハブ グループに割り当てられている複数の LBM は、共通の接続を介して互いに探索し、フル メッシュ構造のクラスタ間のレプリケーション ネットワークを形成します。LBM ハブを持つクラスタ内の他の LBM サービスはクラスタの LBM のハブを介してクラスタ間のレプリケーションに間接的に参加します。

ロケーション、リンク、重み

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

ロケーション設定自体は、リンク、ロケーション間の帯域幅パラメータ、および RSVP ロケーションの設定の 3 つの主要部分で構成されます。ロケーション内の帯域幅パラメータは、デフォルトでは無制限に設定されます。ロケーション（LAN）内で帯域幅を制限する理由はほとんど、あるいはまったくないため、この設定はそのままにしておいてください。Enhanced Location CAC に対する RSVP ロケーションの設定は、RSVP 実装にのみ適用されるため、ここでは考慮されません。

リンク帯域幅パラメータは、管理者が「隣接ロケーション」（つまり、その間で設定されたリンクがあるロケーション）間の音声、ビデオ、およびイマーシブ コール用にプロビジョニングされた帯域幅を特徴付けることができます。この機能により管理者にマルチ ホップ WAN ネットワークをモデル化するロケーションの組み合わせのストリングを作成する機能を提供します。

C：図 8-14 ロケーションおよびリンク

2 つのロケーション間で複数のパスを使用できる場合、リンクに重みを設定して、特定のパスが強制的に選択されるようにすることができます。複数のパスが設定されている場合、累積重みに基づいて 1 つだけが選択され、このパスが 有効なパス と呼ばれます。この重みはスタティックであり、有効なパスを動的に変更されません。2 つの重みが同じである場合は、どちらか一方のパスがランダムに選択されます。したがって、1 つのパスだけが存在するようにするか、あるいは 1 つのパスだけに Location Bandwidth Manager（LBM）の有効パスになるような累計的な重みを持たせることが重要です。これは、マルチ クラスター環境では特に重要性が大きくなります。ほとんどの場合、デフォルトの重みを変更する必要はありませんが、2 つのロケーション間に同じ重みを持つ複数のパスが存在する場合、いずれかのパスの重みを変更して、そのパスが有効パスとして選択されるようにする必要があります。

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

統一された CM では管理者が、ロケーション間のリンクごとに別の音声およびビデオの帯域幅プールを定義することができます。PA では、音声およびビデオ帯域幅プールのみを使用します。通常、ロケーション間のリンクは、物理サイト間の WAN リンクにプロビジョニングされた、オーディオとビデオに使用可能な帯域幅の量に対応する、有限数のキロ ビット/秒（kbps）に設定されます。一部の WAN では、予期されるトラフィック量以上の量がプロビジョニングされているため、制限は不要です。帯域幅の値が有限数のキロ ビット/秒（kbps）に設定されている場合、Unified CM はロケーション内のすべてのコール、および中継ロケーション（計算パス内にあるが、パス内の発信または着信ロケーションではないロケーション）としてロケーションを使用するすべてのコールをトラッキングします。

ロケーションには、次のデバイスを設定する必要があります。

• エンドポイント
• カンファレンス ブリッジ
• ゲートウェイ
• SIP トランク
• 保留音（MoH）サーバ
• アナンシエータ（デバイス プールを使用）

C：表 8-6 に、さまざまなコール速度で必要となる帯域幅の量を記載します。すべてのオーディオ（音声のみのコールのオーディオとビデオ コールに含まれるオーディオの両方）については、Unified CM はメディア ビット レートに加え、IP と UDP のオーバーヘッドを考慮します。たとえば、G.711 または G.722 の音声コールでは、ロケーションとリンクのオーディオ帯域幅の割り当てから差し引かれた 80 kbps（64 kbps ビット レート + IP/UDP ヘッダー用の 16 kbps）が消費されます。ビデオ コールについては、Unified CM はビデオ ストリームのペイロードしか考慮しませんが（IP/UDP ヘッダーのオーバーヘッドは考慮されません）、オーディオ部分は IP および UDP オーバーヘッドを使用して計算されます。たとえば、ビット レート 384 kbps のビデオ コールで、オーディオには ビット レート 64 kbps を使用するように設定されている場合、Unified CM はビデオ帯域幅割り当てから 320 kbps を割り当て、そこからオーディオ用に 64 kbps を使用し、IP/UDP ヘッダー用の 16 kbps を加算してオーディオ プールから 80 kbps を差し引きます。同じビデオ コールで、オーディオには ビット レート 8 kbps を使用するように設定されている場合、Unified CM はビデオ帯域幅割り当てから 376 kbps を割り当て、そこからオーディオ用に 8 kbps を使用し、IP/UDP ヘッダー用の 16 kbps を加算してオーディオ プールから 24 kbps を差し引きます。

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

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

ロケーション間コールがコール アドミッション制御によって拒否された場合、Unified CM は自動代替ルーティング（AAR）機能を使用して、PSTN 接続を通じて宛先にコールを自動的に再ルーティングできます（自動代替ルーティングを参照）。

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

また、AAR はクラスタ内のエンドポイント間コールにのみ適用されます。CAC に失敗したクラスタ間のすべてのコールには、別の SIP ルーティング パスを試すためにルート グループが使用されます。

デバイス間のビデオ コールが CAC に失敗した場合、ビデオ デバイスで [ビデオ コールをオーディオとして再試行（Retry Video Call as Audio）] を有効にすることもできます。このオプションは、Unified CM のビデオ エンドポイントまたは SIP トランクの設定ページで設定され、コールを発信するビデオ エンドポイントまたはトランクに適用できます。一部のビデオ エンドポイントでは、デフォルトで [ビデオコールをオーディオとして再試行（Retry Video Call as Audio）] が有効にされて、エンドポイント上で設定可能になっていません。

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

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

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

• 物理的なサイト（たとえば、ブランチ オフィス）または中継サイト（たとえば、MPLS クラウド）：場所は LAN を表します。これは、エンドポイントを含み、または単に WAN ネットワークのモデル化に対してリンク間の中継場所として機能します。
• 隣接するロケーション間のリンク帯域幅：リンクはロケーションを相互接続し、ロケーション間で利用可能な帯域幅を定義するために使用されます。リンクは物理的なサイト間の WAN リンクを論理的に表します。

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

–ビデオ帯域幅：ロケーション デバイスから設定された隣接した場所に行われたビデオ コール用の WAN リンクで使用可能なビデオ帯域幅の量。Unified CM は、Enhanced Locations Call Admission Control にこの帯域幅値を使用します。

–イマーシブ ビデオ帯域幅：PA 構成では使用されません。

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

• 最大オーディオ ビット レート
• ビデオ コール（オーディオを含む）の最大セッション ビット レート
• イマーシブ ビデオ コール（オーディオを含む）の最大セッション ビット レート：PA 構成では使用されません。
• オーディオ コーデック プリファレンス リスト

Location Bandwidth Manager

Location Bandwidth Manager（LBM）は、サービスアビリティ Web ページから管理し、Enhanced Locations CAC 帯域幅の機能すべてを担当する Unified CM 機能サービスです。Cisco CallManager サービスも実行しているクラスタ内の各サブスクライバ ノード上で動作するように LBM を設定してください。

LBM では次の機能が実行されます。

• ロケーションおよびリンク パスのトポロジを組み合わせる
• トポロジにわたる有効なパスの計算
• Cisco CallManager サービス（Unified CM 呼制御）からのサービスの帯域幅要求
• 他の LBM への帯域幅情報の複製（C：図 8-15 を参照）
• 設定済みのダイナミック情報をサービスアビリティに提供
• Location Real-Time Monitoring Tool（RTMT）カウンタの更新

C：図 8-15 LBM のローカル レプリケーション ネットワーク

デフォルトでは、CallManager サービスは、ローカル LBM サービスと通信します。

音声プールからのすべてのオーディオの差し引き

この PA では、管理者がビデオ コールのオーディオ帯域幅を音声プールから差し引くために使用できる、新しい Unified CM 11. x 機能を使用しています。ELCAC は音声とビデオ CAC プールが表示するキューを確実に保護するために適切な DSCP 設定を使用するため、Unified CM がビデオ プールから帯域幅を差し引く方法を変更するには、ビデオ コールのオーディオ ストリームの DSCP をオーディオ専用コールのオーディオ ストリームと同じようにマーキングする必要があります。

Unified CM でこの機能をイネーブルにするには、CallManager サービスのコール アドミッション制御セクションで、サービス パラメータ [ビデオ コールのオーディオ プールからオーディオ帯域幅を差し引く（Deduct Audio Bandwidth from Audio Pool for Video Call）] を [はい（True）] に設定します。デフォルト設定は [いいえ（False）] であり、デフォルトでは、Unified CM はビデオ プールからビデオ コールのオーディオとビデオの両方のストリームを差し引きます。

マルチクラスターに関する考慮事項

この項では、次の項目について説明します。

• クラスタ内 ELCAC
• LBM のハブのレプリケーション ネットワーク
• 共通ロケーション（共有ロケーション）およびリンク
• シャドウ ロケーション
• ロケーションおよびリンク管理クラスタ

クラスタ内 ELCAC

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

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

C：図 8-16 に示されているクラスタ 1 とクラスタ 2 の 2 つのクラスタには、それぞれローカルにハブアンドスポーク ネットワーク トポロジが設定されています。クラスタ 1 の Hub_None には Loc_11 と Loc_12 へのリンクが設定され、クラスタ 2 の Hub_None には Loc_21、Loc_22、Loc_23 へのリンクが設定されています。クラスタ間の Enhanced Locations CAC が有効にされていると、クラスタ 1 はそのローカル トポロジをクラスタ 2 に送信し、クラスタ 2 もそのローカル トポロジをクラスタ 1 に送信します。各クラスタはリモート クラスタのトポロジのコピーを取得した後、各クラスタはオーバーレイ独自上のリモート クラスタのトポロジを自身のトポロジ上にオーバーレイします。オーバーレイは、同じ名前で設定されたロケーションの一般的な場所によって実現されます。クラスタ 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 のハブは、LBM クラスタ間のレプリケーション グループ による設定で指定されます。クラスタ内のいずれの LBM でも、その LBM ロールの割り当てを、クラスタ間レプリケーション グループの設定で、ハブまたはスポークのロールに変更することができます（LBM ハブ グループの設定について詳しくは、Cisco Unified Communications Manager 製品マニュアル（ https://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html ）を参照してください）。

LBM クラスタ間のレプリケーション グループでは、ブートストラップ LBM の概念もあります。ブートストラップ LBM は、他のすべての LBM ハブに、フル メッシュのハブ レプリケーション ネットワークを作成するために必要な接続の詳細を提供する LBM ハブです。ブートストラップ LBM は、すべての LBM ハブが持つことができるロールです。すべての LBM ハブが 1 つの LBM ハブを指す場合、その 1 つの LBM ハブが他のすべての LBM ハブに相互に接続する方法を伝えます。各レプリケーション グループは、最大 3 つのブートストラップ LBM を参照できます。

LBM のハブ グループが各クラスタに設定されると、指定 LBM ハブはフル メッシュのクラスタ間のレプリケーション ネットワークを作成します。C：図 8-17 に示すクラスタ間レプリケーション ネットワークの設定では、3 つのクラスタ（クラスタ 1、クラスタ 2、クラスタ 3）の間に LBM ハブ グループを設定してクラスタ間レプリケーション ネットワークを形成しています。

C：図 8-17 3 つのクラスタのクラスタ間レプリケーション ネットワークの例

C：図 8-17 では、各クラスタから 2 つの LBM がクラスタの LBM のハブとして指定されます。これにより、LBM ハブのロールに冗長性がもたらされます。これらの LBM ハブは、クラスタ間の LBM レプリケーション ネットワークを形成します。各 LBM クラスタ間のレプリケーション グループに設定されたブートストラップ LBM は、UCM_11、UCM_12 として指定されています。クラスタ 1 のこれら 2 つの LBM ハブは、クラスタ間 LBM のレプリケーション ネットワーク全体の窓口またはブートストラップ LBM として機能します。クラスタ 2 の UCM_21 とクラスタ 3 の UCM_31 はそれぞれ、プライマリが使用可能でない場合（つまり、クラスタ 1 が使用可能でない場合）、バックアップ ルートストラップ LBM ハブとして機能します。クラスタ間 LBM のレプリケーション ネットワークを確立するということは、各クラスタ内のそれぞれの LBM ハブが UCM_11 に接続して、そのローカル トポロジを複製し、リモート トポロジを取得することを意味します。また、UCM_11 から他のクラスタの接続情報を取得し、他のリモート クラスタに接続して、それぞれのトポロジを複製します。これは、フル メッシュのレプリケーション ネットワークを作成します。UCM_11 が使用できない場合、LBM ハブは UCM_12 に接続します。クラスタ 2 の LBM ハブが使用できない場合、クラスタ 2 とクラスタ 3 の LBM ハブは UCM_31 に接続し、クラスタ 3 の LBM ハブは UCM_21 に接続します。

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

• LBM ハブ（ローカル LBM）

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

• LBM スポーク（ローカル LBM）

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

• ブートストラップ LBM

–レプリケーション ネットワーク内のすべてのクラスタの LBM ハブを相互接続する LBM ハブ

–ネットワーク内の任意の LBM ハブを使用できる

–LBM クラスタ間のレプリケーション グループごとに最大 3 つのブートストラップ LBM ハブを表示できる

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

–LBM は各クラスタから送信元および受信者を選択して、LBM メッセージを最適化する

LBM ハブは、通信を暗号化するように設定することもできます。これは、クラスタ間のリンクが保護されていないネットワークに存在する可能性があるためにクラスタ間のトラフィックの暗号化が欠かせない環境に、クラスタ間 ELCAC を配置することを可能にします。暗号化されたシグナリングを LBM ハブ間に設定する方法の詳細については、次の Web サイトで入手可能な Cisco Unified Communications Manager の製品マニュアルを参照してください。

https://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html

共通ロケーション（共有ロケーション）およびリンク

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

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

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

C：図 8-18 に示されているクラスタ 2 には、リージョン 1 のロケーション Loc_11 と Loc_12 にデバイスがありますが、グローバル トポロジの他の部分にリンクするためには、DC と、リージョン 1 から DC へのリンクを設定する必要があります。クラスタ 3 も同様に、リージョン 2 の Loc_31、Loc_32、Loc_33 にデバイスがありますが、グローバル トポロジにマッピングするために、DC と、DC からリージョン 2 へのリンクを設定する必要があります。クラスタ 1 には Loc_11 にしかデバイスがないため、DC と、DC から Loc_11 へのリンクを設定して、クラスタ 2 とクラスタ 3 のトポロジにマッピングする必要があります。

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

シャドウ ロケーション

シャドウ ロケーションを使用して、Enhanced Locations CAC がクラスタ間で機能するために必要となる、ロケーションの名前をはじめとする Enhanced Locations CAC 情報を SIP トランクが渡せるようにします。クラスタ全体でこのロケーション情報を渡すためには、SIP クラスタ間トランク（ICT）を「シャドウ」ロケーションに割り当てる必要があります。シャドウ ロケーションは他の場所へのリンクを持つことができないため、帯域幅はシャドウ ロケーションと別のロケーションの間で予約できません。Hub_None に関連付けられたように、シャドウ ロケーションに割り当てられた SIP ICT 以外のいずれかのデバイスが処理されます。

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

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

推奨事項

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

• 1 つのクラスタを管理クラスタ（ロケーションとリンクを管理するために選択したクラスタ）として選択する必要があります。
• クラスタ管理は次のように設定する必要があります。

–企業内のすべてのロケーションは、このクラスタに設定されます。

–すべてのロケーションとリンクの帯域幅値と重みは、このクラスタで管理されます。

企業内の他のすべてのクラスタ:

• 企業内の他のすべてのクラスタは、デバイスへの関連付けに必要なロケーションのみを設定する必要があります。ロケーション間のリンクを設定してはなりません。このリンク情報は、クラスタ間の Enhanced Locations CAC が有効な場合に管理クラスタから取得されます。デフォルトでは、新しく追加されるロケーションと hub_none の間には、常に 1 つのリンクが設定されます。hub_none を使用しない場合、あるいは構築しているトポロジに hub_none が適切でない場合は、このリンクを削除してください。
• クラスタ間 Enhanced Locations CAC を有効にすると、管理クラスタからすべてのロケーションとリンクが複製されます。

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

利点

• 単一クラスタから企業 CAC トポロジを管理します。
• クラスタが複数の共通のロケーションを共有する場合のロケーションとリンク設定のオーバーヘッドを軽減します。
• クラスタ間でロケーションおよびリンクの設定の誤りを軽減します。
• 企業の他のクラスタは、ロケーションからデバイスやエンドポイントへの関連付けに必要なロケーションにだけ設定を必要とします。
• グローバル ロケーション トポロジのモニタリングに単一のクラスタを提供します。

C：図 8-19 に、3 つのクラスタを対象としたロケーションおよびリンク管理クラスタを示します。

注 前述のように、任意のクラスタがロケーションおよびリンク管理クラスタとして機能することができます。C：図 8-19 では、クラスタ 1 がロケーションおよびリンク管理クラスタとなっています。

C：図 8-19 ロケーションおよびリンク管理クラスタとしてのクラスタ 1 の例

C：図 8-19 に示されている 3 つのクラスタでは、それぞれリージョン ロケーションとリモート ロケーションだけにデバイスがあります。クラスタ 1 にはロケーションおよびリンクが設定されているグローバル トポロジ全体があり、クラスタ間 LBM の複製は 3 つのすべてのクラスタの間で有効です。この例でロケーションを共有するクラスタはありませんが、クラスタ 1 でロケーションとリンク トポロジ全体が設定されているため、すべてのロケーションが共通ロケーションとなります。クラスタ 2 とクラスタ 3 では、デバイスとエンドポイントを関連付けるために必要なロケーションだけを設定している一方、クラスタ 1 にはグローバル トポロジ全体が設定されていることに注意してください。クラスタ間レプリケーション後に、すべてのクラスタはロケーションとリンクからなるグローバル トポロジを使用できるようになります。

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

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

Enhanced Locations CAC の仕組みと、Enhanced Locations CAC の設計および導入の詳細については、最新バージョンの Cisco Collaboration SRND に記載されている「 Bandwidth Management 」の Enhanced Locations Call Admission Control に関する情報を参照してください。

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

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

C：図 8-20 に、各リモート サイトに単一の WAN アップリンクがある単純なデュアル データセンター WAN ネットワーク設計を示します。データセンターは、データ トラフィック用に余裕を持ってプロビジョニングされた高速 WAN 接続を介して相互接続します。

C：図 8-20 デュアル データセンター WAN ネットワーク

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

C：図 8-21 デュアル データセンターの Enhanced Locations CAC のトポロジのモデル

設計に関する推奨事項

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

• 1 つのロケーション（Hub_None）は、両方のデータセンターを表します。
• リモート ロケーションと Hub_None 間の単一リンクは、通常の状態または最高帯域幅容量のリンクの障害時にリモート サイトのアップリンクをオーバーサブスクリプションから保護します。
• リモート サイトと Hub_None 間のリンク帯域幅割り当て容量は、単一リンクの適切な Unified Communications メディア用の最低帯域幅容量と同じです。たとえば、各 WAN アップリンクが音声トラフィックによってマークされた EF の 2 Mbps をサポートできる場合、障害状態または等コスト パスのルーティングをサポートするために、リンクの音声帯域幅値は 2 Mbps 以下である必要があります。

MPLS クラウド

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

設計に関する推奨事項

• MPLS クラウドは、エンドポイントを含まなくてもロケーションを相互接続するハブとして使用されるロケーションとして設定する必要があります。
• MPLS クラウドは、他のリモート ロケーションに複数の可変サイズの帯域幅 WAN アップリンクを相互接続するための中継場所として機能します。
• デュアル MPLS クラウドへの接続を持つリモート サイトは、その接続を単一リンクとして扱い、ネットワーク障害状態時のオーバーサブスクリプションを回避するためにリンクの最低容量までサイジングする必要があります。

ビデオの導入に関するコール アドミッション制御の設計上の推奨事項

アドミッション制御と QoS は相互に補完し、多くの場合は共存します。オーディオとビデオのエンドポイント、音声とビデオのゲートウェイ、音声メッセージ、会議など、最新のシスコ製品サービスは、IP DiffServ コード ポイント（IP DSCP）に基づいてネイティブ QoS パケット マーキングをすべてサポートします。ただし、Jabber for Windows クライアントは、Windows オペレーティング システムが、アプリケーション、IP アドレス、および UDP/TCP ポート範囲を使用するグループ ポリシー オブジェクト（GPO）を使用してオペレーティング システム自体からの DSCP のトラフィックをマーキングする必要があるため、他のクライアントと同じようにネイティブ マーキング機能に厳密に従うことはありません。グループ ポリシー オブジェクトは、トラフィックをマーキングする機能という点で、ネットワーク アクセス リストと非常に類似した機能です。

QoS を使用しないと、許可されたトラフィックが許可されていないトラフィックまたは他のトラフィックの分類よりも上位を求めるネットワーク リソースを使用できるように、ネットワークがメディアの優先順位を付けられないため、QoS はアドミッション制御に必要不可欠です。エンドポイント メディア分類に適用される 5 つの主要な QoS 設定は、Unified CM の QoS 関連の CallManager サービス パラメータならびに SIP プロファイル設定で行います。 C：表 8-7 に、主な 5 つの DSCP パラメータとそれぞれのデフォルト値と推奨値、および対応する Per-Hop Behavior（PHB）のデフォルト値と推奨値を記載します。

[音声コールの DSCP（DSCP for Audio Calls）] 設定は、オーディオ専用コールを発信するデバイスに使用されます。[ビデオ コールの DSCP（DSCP for Audio Calls）] 設定は、「デスクトップ」に分類されるデバイスのオーディオとビデオのトラフィックに使用されます。 テレプレゼンスコールの DSCP（DSCP for TelePresence Calls） が、「ルームシステム」に分類されるデバイスのオーディオとビデオのトラフィックに使用されます。分類されたビデオ コールに依存する [ビデオ コールのオーディオ部分の DSCP（DSCP for Audio Portion of Video Calls）] と [TelePresence コールのオーディオ部分の DSCP（DSCP for Audio Portion of TelePresence Calls）] は、ビデオ コールのオーディオ部分だけを区別します。

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

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

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

Enhanced Locations CAC を使用する Cisco Expressway の導入に関する設計上の推奨事項

Cisco Expressway のモバイルおよびリモート アクセス（MRA）ソリューションでは、この機能をサポートするエンドポイントは、VPN を使用せずに Cisco Expressway 配置を介して Unified CM に登録できます。Cisco Expressway-C サーバと Expressway-E サーバは、それぞれがハイ アベイラビリティの冗長性を備えて導入されます。Expressway-E はファイアウォールからインターネット（外側）とファイアウォールから企業（内側）間の DMZ に導入される一方、Expressway-C は企業内に導入されます。C：図 8-22 に、この配置を示します。また、次のメディア フローを示しています。

• お互いをコールするインターネットベースのエンドポイントでは、C：図 8-22 のエンドポイント B と C の間に示されるように、メディアは Expressway E と Expressway C を経由してルーティングされ、インターネットに戻されます。
• 内部エンドポイントをコールするインターネットベースのエンドポイントでは、C：図 8-22 のエンドポイント A と C の間に示されるように、メディアは Expressway-E と Expressway-C を経由します。

C：図 8-22 Cisco Expressway モバイルおよびリモート アクセス (MRA) の導入

Cisco Expressway 導入環境での Enhanced Locations CAC では、デバイス モビリティと呼ばれる Unified CM の機能を使用する必要があります。エンドポイントでデバイス モビリティを有効にすると、Unified CM は、デバイスが Cisco Expressway を介して登録された時点、あるいは企業内で登録された時点でそれを認識できるようになります。またデバイス モビリティを使用すると、企業とインターネット間をローミングするときに、Unified CM がアドミッション制御をデバイスに適用できるようになります。エンドポイントが Expressway-C の IP アドレスを使用して Unified CM に登録された場合、デバイス モビリティでは、Unified CM が該当するインターネット ロケーションを関連付けることを認識することで、アドミッション制御を適用することもできます。ただし、エンドポイントが他の IP アドレスで登録されている場合、Unified CM は、デバイスに直接設定されている（またはデバイスに直接設定されたデバイス プールから）企業ロケーションを使用します。企業全体にわたってデバイス モビリティを導入しなくても、この機能は有効であることに注意してください。Unified CM のデバイス モビリティ設定は Expressway の IP アドレスでのみ必要となり、この機能を必要とするデバイス
（つまり、インターネット経由で登録するデバイス）上だけでこの機能が有効にされます。

展開の概要

ここではプリファード アーキテクチャの例として、広範な地理的エリアにユーザが存在する大企業を取り上げます。この企業には、データ センターが設置された本社と、大規模、小規模、および非常に小規模の支社があります。本社にはおよそ 500 人、各支社にはそれぞれ 50 人、15 人、5 人のユーザがいます。ネットワーク図を簡略化するため、これらのサイトのカテゴリ（本社、大規模支社、小規模支社、営業所）をテンプレートとして使用し、同様のユーザ数とエンドポイントの密度を持つ各サイトに応じた帯域幅の考慮事項を決定します。C：図 8-23 に、サイトのタイプごとのユーザ数とエンドポイントの数が示されています。この例での企業は、ビデオ機能を備えた Jabber を導入し、ユーザが会議でビデオ端末にアクセスできるようにしています。ビデオ会議のリソースは、中央サイト（本部）のデータセンターにあります。IP フォンは、音声のみの通信に使用します。ビデオ エンドポイントは、Jabber クライアント、コラボレーション デスクトップ エンドポイント（DX シリーズ）、ルームベースのエンドポイント（MX シリーズおよび SX シリーズ）です。セントラルサイトと大規模ブランチには、Webex Room 70 G2 も導入されています。

サイトの各タイプに応じた WAN エッジでの帯域幅要件の決定は、IT 部門に任されています。以降の各セクションでは、この要件を示し、QoS を適用し、帯域幅とキューイング要件、アドミッション制御要件を決定するための方法を説明します。

C：図 8-23 Enterprise Collaboration 向けプリファード アーキテクチャ

Enterprise Collaboration 向けプリファード アーキテクチャでの帯域幅管理の導入に伴う主要なタスクは次のとおりです。

• 識別と分類

–アクセス レイヤ エンドポイントの識別と分類

–アプリケーション サーバーのQoS

–WAN エッジの識別と分類

–WAN エッジでのキューイングとスケジューリング

• プロビジョニングとアドミッション制御

–拡張ロケーション CAC

–モバイルおよびリモート アクセス（MRA）を対象としたデバイス モビリ ティーの導入

–帯域幅割り当てのガイドライン

識別と分類

ここでは、企業全体の QoS 要件を確立します。この項では、次の項目について説明します。

• アクセス レイヤ エンドポイントの識別と分類

–エンドポイント：Jabber

–エンドポイント: デスクトップおよびルーム システム

• アプリケーション サーバーのQoS
• WAN エッジの識別と分類
• WAN エッジでのキューイングとスケジューリング

導入のこのフェーズでは、大まかに次のステップが必要になります。

1。 Jabber クライアントおよびデスクトップおよびルームシステムエンドポイントの QoS を使用して、統一された CM のエンドポイントを設定します。

2。 信頼されないエンドポイントの識別と分類に適用するアクセス レイヤ ポリシーを導入します。

3。 メディアおよび SIP シグナリングを対象としたアプリケーション サーバ QoS を設定します。

4。 コラボレーション メディアと SIP シグナリングを対象とした WAN エッジ入力時のマーキング ポリシーを導入します。

5。 コラボレーション メディアと SIP シグナリングを対象とした WAN エッジ出力キューイング ポリシーを導入します。

アクセス レイヤ エンドポイントの識別と分類

ここでは、ネットワークおよび Unified CM で、エンドポイントの QoS とメディア ポート範囲を設定します。

エンドポイント：Jabber

Jabber エンドポイントは信頼されていないエンドポイントであり、通常はデータ VLAN 内に置かれます。アクセス レイヤ スイッチでシグナリングおよびメディアの再マーキングを適用するには、特定の UDP ポート範囲を使用します。この場合、Unified CM で SIP プロファイルを設定し、すべての Jabber クライアントが [メディアとシグナリングのポート範囲：分割（Separate Media and Signaling Port Range）] の値 3000 ～ 3999（オーディオの場合）と 5000 ～ 5999（ビデオの場合）を使用するよう明示的に指定します。SIP シグナリングには SIP シグナリング ポート 5060 を使用し、セキュアな SIP シグナリングには SIP シグナリング ポート 5061 を使用します。SIP シグナリング ポートは、Unified CM の [SIP セキュリティ プロファイル（SIP Security Profile）] で設定します。C：図 8-24 に、この設定を示します。

C：図 8-24 Jabber エンドポイントの QoS

管理者は、次の DSCP 値に UDP ポートを再マーキングするデータ VLAN にアクセス スイッチの ACL を作成します。

• オーディオ：UDP ポート 3000 ～ 3999 を EF として再マーキング
• ビデオ：UDP ポート 5000 ～ 5999 を AF42 として再マーキング
• シグナリング：TCP ポート 5060 ～ 5061 を CS3 として再マーキング

Jabber の分類概要：

• すべての Jabber コールのオーディオ ストリーム（音声専用とビデオ）は EF としてマーキングされます。
• Jabber ビデオ コールのビデオ ストリームは AF42 としてマーキングされます。

Jabber エンドポイントについては、Jabber SIP プロファイルでデフォルトの QoS 値を変更することもお勧めします。これは、何らかの理由でワイヤレス ルータまたは他のネットワーク コンポーネントにより QoS が「信頼される」場合、適切な「信頼される」値が再マーキング値と同じになるようにするためです。したがって、SIP プロファイル内の QoS パラメータを C：表 8-8 に記載するように設定し、UDP ポート範囲を C：表 8-9 に記載するように設定してください。

C：表 8-8 の設定により、何らかの理由で Jabber クライアントのオーディオとビデオが信頼され、アクセス スイッチで UDP ポート範囲によって再マーキングされない場合、Jabber クライアントのオーディオは EF に設定され、ビデオは AF42 に設定されます。これは単に、Jabber エンドポイント間で設定の一貫性を確保するためです。

注 Jabber ビデオに AF42 を使用しない場合は、QoS のデフォルト システム パラメータを使用して、SIP プロファイルの QoS パラメータを [システムデフォルトの使用（Use System Default）] に設定できます。

モバイル デバイス上の Jabber については、それらのデバイス用に新しい SIP プロファイルを作成する際に、 モバイル デバイス用の標準 SIP プロファイル をコピーすることをお勧めします。モバイル デバイス用のデフォルトの標準 SIP プロファイルには、Android デバイスや Apple iOS デバイスで Jabber 登録を維持する際に推奨されるタイマー値が含まれているためです。これらのタイマーは、デュアルモードおよびタブレット Jabber クライアント デバイスに割り当てられているすべての SIP プロファイルに必要です。

注 Mac/iPad/iPhone/Android 向けの Jabber は、いずれも OS によってネイティブに DSCP でマーキングされます。ただし、Windows 向けの Jabber には、OS による DSCP 再マーキングのためにグループ ポリシー オブジェクトが必要になります。グループ ポリシー オブジェクトを使わなければ、Windows 向けの Jabber はすべてのトラフィックの DSCP を 0 としてマーキングします。このことから、Jabber には特定のポート範囲が使用され、DSCP に基づくマッチングは行われません。

エンドポイント: デスクトップおよびルーム システム

IP フォン、デスクトップ、および ルーム システム エンドポイントも、トラフィックを再マーキングする際にアクセス レイヤ スイッチ ACL に依存します。アクセス レイヤ スイッチでシグナリングおよびメディアを再マーキングするには、特定の UDP ポート範囲と DSCP を使用します。統一された CM で SIP プロファイルを設定し、すべての IP フォン、デスクトップ、およびルームシステムエンドポイントがオーディオとビデオに対して共通のメディアとシグナリングのポート範囲の値 17000 ～ 17999 を使用するように明示的に指定します。SIP シグナリングには SIP シグナリング ポート 5060 を使用し、セキュアな SIP シグナリングには SIP シグナリング ポート 5061 を使用します。SIP シグナリング ポートは、Unified CM の [SIP セキュリティ プロファイル（SIP Security Profile）] で設定します。C：図 8-25 でこれについて説明します。

C：図 8-25 デスクトップおよびルーム システム エンドポイント QoS

管理者は、アクセス スイッチ ポートで UDP ポートが次の DSCP 値に再マーキングされるようにするための ACL を作成します。

• オーディオ：UDP ポート 17000 ～ 17999 では DSCP が EF となっているオーディオを EF として再マーキング
• ビデオ：UDP ポート 17000 ～ 17999 では DSCP が AF41 となっているビデオを AF41 として再マーキング
• シグナリング：TCP ポート 5060 ～ 5061 を CS3 として再マーキング

デスクトップおよびルーム システム エンドポイントの分類の要約：

• すべてのデスクトップおよび ルーム システム エンドポイント コールのオーディオ ストリーム（音声専用とビデオ）は EF としてマーキングされます。
• デスクトップおよび ルーム システム エンドポイント ビデオ コールのビデオ ストリームは AF41 としてマーキングされます。

デスクトップおよび ルーム システム エンドポイントについては、SIP プロファイルでデフォルトの QoS 値を変更して C：表 8-10 に記載するように設定し、UDP ポート範囲を C：表 8-11 に記載するように設定してください。

エンドポイント スイッチ ポート用のスイッチ ACL ベース QoS ポリシーの例

デスクトップおよびルーム システムのエンドポイント:

• UDP ポート範囲 17xxx と DSCP EF に一致 –> DSCP EF として再マーキング
• UDP ポート範囲 17xxx と DSCP AF41 に一致 –> DSCP AF41 として再マーキング
• TCP ポート 5060 または 5061 に一致 –> DSCP CS3 として再マーキング

Jabber クライアント

• UDP ポート範囲 3xxx に一致 –> DSCP EF として再マーキング
• UDP ポート範囲 5xxx に一致 –> DSCP AF42 として再マーキング
• TCP ポート 5060 または 5061 に一致 –> DSCP CS3 として再マーキング

汎用マッチング

• 残りのトラフィックをマッチングし、デフォルトのクラス マップを使用して DSCP を
  0（ベスト エフォート（BE））として設定

注 以下に、Cisco Common Classification Policy Language（C3PL）に基づくアクセス コントロール リストの例を記載します。

前にも説明したように、エンドポイントが送受信するデータとシグナリングは他にもあります（ICMP、DHCP、TFTP、BFCP、LDAP、XMPP、FECC、CTI など）。このようなトラフィックの QoS 値は、トラフィックのタイプに応じた企業のベスト プラクティスに従う必要があります。この手順を行わないと、メディアと SIP シグナリング以外のすべてのトラフィックの DSCP は、この設定でのクラスのデフォルトによって BE（DSCP 0）に設定されることになります。DSCP に基づくマッチングでマーキングしたトラフィックを通過させてから、DSCP を同じ値に再マーキングするか、エンドポイントが通信に使用するプロトコルごとに TCP および UDP ポートを使用することを推奨します。

それには、以下の例に示されているように、AF21（トランザクション データ）である DSCP に対するマッチングを行うようにクラス マップを作成し、そのデータを AF21 に設定するようにポリシーを設定して、実質的に DSCP を同じ値で再マーキングします。これは、DSCP に対するマッチングを行って、同じ DSCP に再マーキングする一例にすぎません。

TCP ポート範囲と UDP ポート範囲を使用することもできます。エンドポイントと Unified CM 間の通信に使用する TCP ポートと UDP ポートについて詳しくは、次の URL でアクセスできる最新バージョンの『 System Configuration Guide for Cisco Unified Communications Manager 』に記載されている「 Cisco Unified Communications Manager TCP and UDP Port Usage 」を参照してください。

https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html

また、他のエンドポイント トラフィックに使用されるさまざまなプロトコルとポートを確認するには、エンドポイントの管理ガイドまたは Jabber の計画ガイドを参照してください。これらのドキュメントの例としては、以下が挙げられます。

• 『 Cisco DX Series Administration Guide 』（次の URL でアクセス）

https://www.cisco.com/c/en/us/support/collaboration-endpoints/desktop-collaboration-experience-dx600-series/products-maintenance-guides-list.html

• 『 Planning Guide for Cisco Jabber 』（次の URL でアクセス）

https://www.cisco.com/c/en/us/support/unified-communications/jabber-android/products-installation-guides-list.html

アプリケーション サーバーのQoS

ソリューション全体にわたり、メディアを発信および終端するアプリケーションと MCU のすべてに、QoS を設定します。ここでは、PA に含まれるすべてのアプリケーション サーバでのデフォルト以外の設定を取り上げます。また、同じく重要な点として、アプリケーション サーバが接続するスイッチ ポートが、サーバによって設定された QoS を信頼するようにしてください。一部のスイッチ（Cisco Catalyst 3850 シリーズなど）は、デフォルトで QoS を信頼するため、スイッチの設定を調べて、スイッチ ポートがデフォルトで信頼されるかどうかを確認し、信頼されない場合は、QoS 信頼を有効にしてください。

各種アプリケーション サーバでの QoS 設定:

• Cisco Unified CM（エンドポイト）

[システム（System）] > [サービス パラメータ（Service Parameters）] > [パブリッシャの選択（Select Publisher）] > [Cisco CallManager サービスの選択（Select Cisco CallManager Service）] > [クラスタ全体のパラメータ（システム - QoS）（Clusterwide Parameters (System - QOS)）] に移動し、QoS のデフォルト値を変更して、 C：表 8-12 に記載されている値に設定します。

• Cisco Unity Connection

[システム設定（System settings）] > [詳細設定（Advanced）] > [Telephony]

–デフォルトでは、オーディオは 46 / EF、ビデオは 46 / EF、シグナリングは 24 / CS3 に設定されています。

–ビデオを 34 / AF41 に変更します。

• Cisco Meeting Server

–Cisco Meeting Server の DSCP 設定は、コマンド ライン インターフェイス（CLI）を使用して行います。会議の章で説明しているように、DSCP の設定は、Cisco Meeting Server を設定した後に行ってください。すべての値はデフォルトで DSCP 0 に設定されるため、すべての DSCP 値を設定する必要があります。 これらの変更を適用するには、サーバの再起動が必要になります。

–コマンド ラインの値：

• Cisco Expressway

ビデオの Expressway DSCP 値は、値 AF42（DSCP 36）を使用して状況対応型ビデオとして設定されます。ソリューションで状況対応型ビデオを使用していない場合（したがって AF42 を使用していない場合）は、AF41 を代わりに使用することもできます。その他すべての値（オーディオ、シグナリング、XMPP）は、デフォルト値に設定されます。

[システム（System）] > [QoS（Quality of Service）]

–DSCP シグナリングの値：24（デフォルト）

–DSCP オーディオの値：46（デフォルト）

–DSCP ビデオの値：36 または 34（デフォルト）

–DSCP XMPP の値：24（デフォルト）

WAN エッジの識別と分類

WAN エッジでの企業からサービス プロバイダーへの出力時には、コラボレーション トラフィックにはアクセス レイヤ スイッチですでに再マーキングが適用されていることから、パケットが特定の DSCP 値で到達することが前提とされます。入力時には、アクセス スイッチからのいずれかのトラフィックが LAN 経由で信頼された場合のフェールセーフとして、アクセス レイヤで再マーキングできなかった WAN エッジのすべてのトラフィックを再マーキングすることが重要です。QoS は LAN で重要ですが、WAN では最も重要です。ルータは入力トラフィックが信頼されていると見なすため、ビジネス要件およびユーザ エクスペリエンスに応じた適切な QoS ポリシーを設定することが重要です。WAN エッジの再マーキングは、ルータへの入力インターフェイスで常に実行されます。キューイングおよびスケジューリングは出力インターフェイスで実行されます。次に、WAN 入力 QoS ポリシーと出力キューイング ポリシーの例を示します。C：図 8-26 からC：図 8-31 に、設定および再マーキング プロセスを示します。

C：図 8-26 では、エンドポイントからのパケットが識別され、信頼されているポートまたは ACL によって適切な DSCP マーキングで分類されます。スイッチド アクセス ネットワークには一般に、適切な QoS ポリシーを設定できないエリアや、コラボレーション トラフィックをベスト エフォート DSCP（BE）として再マーキングできないエリアがあります。そのため、アクセス レイヤで見逃されたトラフィックが WAN に向かう前に、キャッチオール ポリシーで対処するには、WAN 入力ポリシーが絶好の場所となります。

C：図 8-26 ルータ入力 QoS ポリシー プロセスの例：ステップ 1

C：図 8-26 からC：図 8-31 に、ポリシー一致基準および DSCP 再マーキングを示します。これらの図では、次のステップが説明されています。

1。 ステップ 1 では、入力サービス ポリシーが設定されたルータ入力インターフェイスにパケットが到着します。

2。 ステップ 2 では、4 つのトラフィック クラスが設定されたポリシー マップにより、適切な DSCP（音声 = EF、優先順位付けされたビデオ = AF41、Jabber ビデオ = AF42、シグナリング = CS3）が設定されます。

3。 ステップ 3 では、これらのクラスのそれぞれで、match-any 基準が設定された同じ名前のクラス マップをマッチングします。この match-any 基準は、プロセスがトップダウン方式で始まり、最初に一致した基準がポリシー マップ ステートメントの各クラスに応じて実行されることを意味します。

C：図 8-27 ルータ入力 QoS ポリシー プロセスの例：ステップ 1 ～ 3

4。 ステップ 4 では、クラス マップ ステートメントの最初の行が解析されます。この行は、識別と分類のセクションで Unified CM に設定された UDP ポートを（場合によっては、DSCP 値も）マッチングする ACL です。（プロトコル、ポート範囲、DSCP が）ACL 基準に一致すると、そのトラフィックは、対応するポリシー マップ ステートメントでの設定に従ってマーキングされます。

C：図 8-28 ルータ入力 QoS ポリシー プロセスの例：ステップ 4

5。 ステップ 5 では、最初のステートメントに一致しなかったトラフィックにクラス マップの次のマッチング ステートメント match dscp が適用されます。トラフィックが DSCP にだけ一致する場合、DSCP は再び、マッチングされた、ポリシー マップ ステートメントに設定されている同じ値に設定されます。この場合、ルータは単純に DSCP に一致し、DSCP を同じ値にリセットします。これはサーバおよびアプリケーションから WAN ルータに入ってくる信頼された DSCP の catch-all 設定です。

C：図 8-29 ルータ入力 QoS ポリシー プロセス例：ステップ 5

注 これは、Cisco Common Classification Policy Language（C3PL）に基づいた QoS 入力マーキング ポリシー例です。使用している特定のルータの設定ガイドを参照して、更新された C3PL コマンドがないかどうかを確認し、C3PL をサポートする Cisco ルータで同様のポリシーを設定する方法を調べてください。

6。 ステップ 6 では、トラフィックがアウトバウンド インターフェイスに到達し、そこで 3
つのキュー（VOICE という名前のプライオリティ キュー、VIDEO という名前の CBWFQ、SIGNALING という名前の CBWFQ）が作成されている出力サービス ポリシーにより、キューに入れられてスケジュールされます。C：図 8-30 からhtml#96561">C：図 8-31 に、この仕組みが示されています。ここでは、この出力キューイング ポリシーが、アクセス スイッチや WAN ルータ入力インターフェイスへの入力で発生するネットワーク マーキングとして DSCP のみに基づいている点が強調されています。これは一致基準とキューを説明する単なる例に過ぎないため、WRED 機能は含まれていません。WRED の詳細については、「WAN エッジでのキューイングとスケジューリング」を参照してください。

C：図 8-30 ルータ出力キューイング ポリシー プロセスの例：ステップ 6

 

7。 ステップ 7 では、トラフィックがクラス マップのマッチング ステートメントと照合されます。EF としてマーキングされたトラフィックはすべて VOICE PQ に送られ、AF41 および AF42 としてマーキングされたトラフィックは VIDEO CBWFQ に、CS3 としてマーキングされたトラフィックは SIGNALING CBWFQ に送られます。

C：図 8-31 ルータ出力キューイング ポリシー プロセス例：ステップ 7

 

---

注 これは、Cisco Common Classification Policy Language（C3PL）に基づいた出力キューイング ポリシー例です。使用している特定のルータの設定ガイドを参照して、更新された C3PL コマンドがないかどうかを確認し、C3PL をサポートする Cisco ルータで同様のポリシーを設定する方法を調べてください。

---

出力キューの設定例

! This section applies the policy-map classes to match media and signaling QoS.

class-map match-any VIDEO

match dscp af41

match dscp af42

class-map match-any VOICE

match dscp ef

class-map match-any SIGNALING

match dscp cs3

 

! This section configures the bandwidth for Collaboration media and SIP signaling traffic.

policy-map EGRESS-QUEUING

class VOICE

priority percent 10

class VIDEO

bandwidth percent 30

fair-queue

class SIGNALING

bandwidth percent 2

...

! This section applies the policy-map to the interface.

Router (config-if)# service-policy output EGRESS-QUEUING

! Attaches service policy to interface