この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
帯域幅管理とは、コラボレーション ソリューション内の音声とビデオ対応エンドポイント、クライアント、およびアプリケーションのすべてで、エンドツーエンドの最高のユーザ エクスペリエンスを実現することです。この章では帯域幅管理の包括的なアプローチについて説明します。帯域幅管理では、エンドツーエンドのサービス品質(QoS)アーキテクチャ、コール アドミッション制御、ビデオ レート アダプテーション、復元力メカニズムを導入し、マネージドおよびアンマネージド ネットワークでパーベイシブ ビデオを展開する際に最高のユーザ エクスペリエンスを実現します。
始めに、コラボレーション メディアの説明、音声とビデオの違い、ネットワークに与える影響について説明します。次に、信頼されているエンドポイントと信頼されていないエンドポイント、クライアント、アプリケーションのコラボレーション メディアとシグナリングを識別および分類する方法について説明し、コラボレーションのエンドツーエンドの QoS アーキテクチャについても説明します。WAN キューイングとスケジューリングの戦略、帯域幅のプロビジョニングとアドミッション制御についても解説します。
(注) ネットワーク インフラストラクチャの章では、LAN および WAN の QoS の基礎について説明します。この章を確認し、その概念について十分理解することが重要です。この章は、それらの概念を理解していることを前提としています。
表 13-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
|
|
|
---|---|---|
コラボレーション環境は絶えず進化し、アプリケーションとネットワークの 2 つの領域が大きく変化しています。Unified Communications が初めて導入されたときは、メディアが通過するネットワーク全体で管理者がサービス品質(QoS)を実装できる、完全なマネージド ネットワークに接続されている IP Phone とルーム システム エンドポイントなど、主に固定ハードウェア エンドポイントから構成されていました。時間の経過に合わせて、インターネットと WebEx などのクラウドベース サービスを使用できるようになり、コラボレーション インフラストラクチャの一部はマネージド ネットワーク外およびクラウド内に配置できるようになりました。また、オフィス接続オプションも進化しています。企業は、Cisco Expressway 経由で直接接続されたインターネット、または Dynamic Multipoint VPN(DMVPN)などの技術を経由したインターネット上のリモート サイトとモバイル ユーザを相互接続しています。図 13-1では、クラウド サービスを使用するマネージド(QoS 対応)ネットワーク内の従来のオンプレミス コラボレーション ソリューションと、インターネットなどのアンマネージド(QoS 非対応)ネットワーク上に配置されたサイトをまとめています。オンプレミス リモート サイトは、管理者が QoS でコラボレーション メディアとシグナリングの優先順位を設定できる MPLS マネージド ネットワークを経由して接続されます。他のリモート サイトとブランチは、コラボレーション メディアとシグナリングの優先順位を設定できるまたはサイトからの発信に対してのみ優先順位を設定できる場合、インターネットを経由して企業に接続します。また、多くのさまざまなモバイル ワーカーおよびテレワーカーも、インターネットを経由してオンプレミス ソリューションに接続します。そのため、企業、リモート サイト、家庭、モバイル ユーザ、他のビジネス、消費者を結ぶソースとしてインターネットは普及し、帯域幅管理およびユーザ エクスペリエンスに大きな影響を与えています。
図 13-1 マネージド ネットワークとアンマネージド ネットワーク
新しい技術および動向とは、エンドポイントとユーザ エクスペリエンスの進化、大量のコラボレーション デバイスとオプションを意味しています。企業は、ハウジングの単一目的型シングル メディア通信デバイスから多目的型マルチメディア オプションに移行しています。これは、 Bring Your Own Device(BYOD) などの動向にも明確に表れています。ユーザは会社に自分の高性能なコンパクト モバイル デバイスを持ち込み、インスタント メッセージ、ビデオ コラボレーション、会議機能、デスクトップ共有機能などのコラボレーション技術を業務プロセスに導入しているため、業務プロセスの協調性と効率性が改善されています。
コラボレーション メディアは、固定シングル ストリームで固定ビット レートの音声とビデオ ストリームに接続したポイントツーポイントまたはマルチポイント ブリッジから、さまざまなデバイスと相互接続するマルチポイント ブリッジ全体でカスケードされたマルチレイヤで適応型ビット レートのビデオ セッションに大幅に進化しました。図 13-2 はこの進化を示しています。
コラボレーション ソリューションで現在積極的に適用されているその他の傾向および技術は、次のとおりです。
マネージド ネットワークとアンマネージド ネットワークのこのような進化、新しいエンドポイント、ユーザ エクスペリエンス、新しい技術と動向には、次のような課題があります。
この章では、利用可能なネットワーク リソースに基づいて最高のユーザ エクスペリエンスを実現できるように、Cisco ビデオ エンドポイントでのスマート メディア技術の活用、エンドツーエンドの QoS アーキテクチャの構築、最新デザインと導入推奨事項および帯域幅管理のベスト プラクティスの活用に関する戦略について説明します。ネットワーク コラボレーション メディアのタイプが強制的に通過するようになりました。
このセクションでは、Cisco ビデオ エンドポイントが、パケットの損失、遅延、ジッターに直面しながらも高品質のビデオを実現するために導入するリアルタイム メディア技術とスマート メディア技術を使用した音声ストリームとビデオ ストリームの特性について説明します。
ビデオは企業のトラフィック ミックスの主要コンポーネントです。ストリーミング ビデオと事前に配置したビデオの両方がネットワークに影響を与え、パフォーマンス全体にも大きく影響します。ビデオ データグラムの構造とネットワークに配置する際の要件を理解すると、ネットワーク管理者がメディア対応ネットワークを実装する場合に役立ちます。
ビデオの説明にはさまざまな属性を使用できます。たとえば、ビデオは、リアルタイムまたは録画、ストリーミングまたは事前配置、高解像度または低解像度に分類できます。ネットワーク負荷は、送信されるビデオのタイプによって異なります。録画、事前配置、低解像度のビデオはファイル転送とほとんど同じですが、リアルタイム ストリーミング ビデオには高性能ネットワークが必要です。一般的なビデオ アプリケーションの多くはこのどこかに当てはまります。このため、リアルタイム ストリーミング ビデオ アプリケーションはパブリック インターネット上で適切に動作できます。ネットワークおよびメディア エンコーダの調整は、IP ネットワークでビデオを導入する際の重要な側面です。
ビデオ コーデックは、過去 15 年間にわたって進化を続けています。現在のコーデックは、強力な処理能力を使用してストリーミング サイズを適切に最適化します。一般的な手順は、元の MPEG1 標準規格のリリースからほとんど変わっていません。画像は、ブロックにグループ化されたピクセルのマトリックスから構成されます。ブロックはマクロ ブロックにまとめられます。マクロ ブロックの 1 行が 1 つのスライスです。スライスは画像を形成し、画像は画像グループ(GOP)にまとめられます。
各ピクセルには、赤、緑、青のコンポーネントがあります。エンコーディング プロセスでは、RGB を luma と 2 色のカラー コンポーネント(一般には YCrCb と呼ばれる)に分けることから始まります。エンコーディングではわずかな色情報は無視され、後で補間されます。YCrCb 形式になると、各コンポーネントは変換に進みます。変換は元に戻すことができ、データが圧縮されることはありません。その代わり、効率的な量子化と圧縮を実現できるように、データは異なる方法で表されます。データの細部を補完するには、量子化が使用されます。品質を設定するには、この補完が使用されます。品質を下げると、圧縮率が上がります。量子化の後、共通ビットをバイナリ コードで置き換えて、無損失圧縮を適用します。画像の各マクロ ブロックがこのプロセスを通過すると、ビットの基本的なストリームが生成されます。このストリームは、PES(Packetized Elementary Stream)と呼ばれる 188 バイトのパケットにスライスされます。次に、このストリームは IP パケットにロードされます。IP パケットには 1,500 バイトの MTU が含まれ、PES パケットは 188 バイトに固定されているため、1 つの IP パケットに収めることができる PES は 7 つのみです。生成された IP パケットは 1,316 バイトで、ヘッダーは含まれません。その結果、IP フラグメンテーションの問題はありません。一般的なパケット数は 45 ~ 65 ですが、高解像度ビデオのすべてのフレームの基本ストリーム パケットをすべて伝送するのに必要な IP パケット数は 100 になることがあります。量子化および画像の複雑性は、伝送に必要なパケット数を決定する上で重要な要因となります。消失情報の見積りには、前方誤り訂正を使用できます。ただし多くの場合、複数の IP パケットが連続して消失します。このため、フレームの復元がほぼ不可能になります。正常に送信されたパケットは使われない帯域幅を表します。新しいフレームを要求するには RTCP を使用できます。有効な最初のフレームがないと、後続フレームが正しくデコードされません。
最新世代のビデオ コーディングは、H.264、MPEG4 パート 10、および Advanced Video Coding(AVC)の 3 つの名前で知られています。以前のコーデックと同様に、H.264 は空間的かつ時間的圧縮を使用します。空間的圧縮は、これまでに説明したようにビデオの単一フレームで使用します。これらのタイプのフレームは I フレームと呼ばれています。I フレームは GOP の最初の画像です。時間的圧縮は、後続フレーム間の情報がほとんど変わらない点を利用します。拡大率を変更したり、カメラを移動したりすると、ほぼすべてのピクセルが変化しますが、変化は移動が原因です。ベクトルはこの移動を表すために使用され、ブロックに適用されます。カメラの旋回と同じように、すべてのピクセルが一緒に移動したとエンコーダが判断した場合は、グローバル ベクトルが使用されます。さらに、発生するエラーを微調整するために、差分信号が使用されます。H.264 では可変ブロック サイズが有効で、¼ ピクセル相当に動きをコーディングできます。デコーダはこの情報を使用して、現在のフレームが前のフレームと比べてどのように表示されるかを決定します。動きのベクトルとエラー信号を含むパケットは P フレームと呼ばれます。通常、P フレームが失われると、後続フレームに組み込まれるアーティファクトが発生します。アーティファクトが長期間発生する場合、その原因は P フレームの消失の可能性があります。
図 13-3 は基本的な仕組みを示します。
1. I フレーム(イントラコード化画像)は静止画像としてエンコードされた画像全体で、パケットのグループとして送信されます。このフレームは他のフレームを参照しません。デコーダで画像全体を生成するのに必要なのはこのフレームのみです。この場合、画像は山をハイキングする小さなハイカーです。
2. 次に P フレーム(予測画像)が送信されます。これは前にエンコードしたフレーム(この場合は I フレーム)に基づくフレームです。I フレームとの差異のみがエンコードされます。デコーダはこれらの差異を取得し、すでにある I フレームにこの差異を適用します。この場合、小さなハイカーが丘を登っています。小さなハイカーとその動きのみが最後の I フレームから変化するため、この P フレームは非常に小さくなり、送信するパケットおよび帯域幅は少なくなります。
3. 次の P フレームが送信され、最後の P フレームの予測が送信されます。ステップ 2 の P フレームと同様に、この P フレームでは、丘を登るハイカーの最後の動きとこの新しい動きとの差異を示します。前の画像からの変化量が大きくなるまで、この一連の操作は継続するため、新しい I フレームが必要になります。
H.264 は B フレームも実装します。このタイプのフレームには、P フレーム間の情報が含まれます。つまり、B フレームの情報を使用する前に、次の P フレームが到着するまで B フレームを保持する必要があります。B フレームは H.264 のどのモードでも使用されません。エンコーダは最適なフレーム タイプを決定します。通常、I フレームよりも P フレームが多くなります。ラボの分析では、TelePresence の I フレームは通常 64 K バイト長(1,316 バイトで 50 パケット)で、P フレームの平均は 8 K バイト長(900 バイトで 9 パケット)です。I フレームが大きくなるため、P フレームと比較してビット レートに急激に上昇します。
多くの場合、音声とビデオは従兄弟のような関係と考えられています。両方ともリアルタイム プロトロコル(RTP)アプリケーションですが、同じ点はこれだけです。通常、各パケットのサイズとレートは固定されているため、音声は適切に動作すると考えられています。ビデオ フレームは複数のパケットに広がり、グループとして移動します。1 つのパケットが失われると、P フレームが無駄になり、1 つの P フレームが無駄になると、永続的なアーティファクトが生成されるため、通常、ビデオには音声よりも厳密な損失要件があります。ビデオは非対称です。音声も非対称ですが、通常は対称です。ミュートの場合でも、IP Phone は同じサイズのフローを送受信します。
ビデオでは、平均リアルタイム パケット サイズが増え、ネットワークのトラフィック プロファイルを素早く変更する可能性があります。計画的に行わないと、ネットワーク パフォーマンスに悪影響を与える可能性があります。図 13-4 では、一定の時間送信される一連の音声パケットとビデオ パケットの差異を示します。
図 13-4 から分かるように、音声パケットは同じサイズで、正確に同間隔で送信され、非常にスムーズなストリームです。一方、ビデオは一定の間隔で大量のパケットを送信し、フレームごとに大きく異なります。図 13-4 では、I フレームと P フレームを比較した場合の、パケット数とパケット サイズの差異を示します。音声と比較すると、非常にバースト性のあるメディア ストリームに変換されます。図 13-5 では、HD ビデオ ストリームの帯域幅プロファイルを段階的に示します。I フレームの送信時にはバーストが大きくなることに注意してください。
図 13-5 では、1,920 kbps で 720p30 の HD ビデオ コール(1,792 kbps ビデオ + 128 kbps 音声)を示します。このグラフはビデオ帯域幅(L3 オーバーヘッドを含む)を表し、赤色の線は平均ビット レートを示します。
音声とビデオの両方とも UDP 経由で転送され、損失と遅延の影響を受けやすいですが、それぞれのネットワーク要件とプロファイルは大きく異なります。音声のビット レートは一定で、ビデオと比較して密度が低いです。また、最小ビット レート オーディオ コーデックと最大ビット レート コーデックの 1 つを比較しても、運用範囲の比率は 1:6 と狭いです。一方、ビデオのビット レートは可変(バースト性がある)で、音声と比較して密度が高いです。また、運用範囲は 1:40 と広いです(15 fps で 250p と 60 fps で 1080p)。図 13-6 では、これらの差異の一部を示します。
注意すべき重要な点は、音声とビデオは、転送、および損失と遅延の影響については似ていますが、ネットワークにおけるそれぞれの帯域幅要件の管理については大きく異なります。また、ビデオはコラボレーション エクスペリエンス全体に関連し、音声が重要であることにも注意してください。たとえば、ネットワークの停止または他のネットワーク関連イベントにより、ビデオがビデオ コール中に失われた場合、音声がこの停止中に失われなければ、通信は継続できます。QoS の分類とマーキングのようなコラボレーション設計のネットワーク要件を考える場合、これは重要な概念になります。
送信側ステーションはビデオ解像度を決定するため、ネットワークの負荷も決まります。これは、ビデオの表示に使用するモニタのサイズとは関係ありません。負荷を推定するのに、ビデオを調査するのは信頼性のある方法ではありません。一般的な高解像度形式は、720i、1080i、1080p などです。高解像度に加えて、HTTP(または一部で HTTPS)および SSL( 表 13-2 を参照)でトンネリングされることの多い低解像度のビデオも急増しています。一般的な解像度には、CIF(352x288)と 4CIF(704x576)があります。これらの数値は、DCT(22x18)と(44x36)マクロ ブロックでそれぞれ使用される、16x16 マクロ ブロックの整数値として選択されています。
|
|
|
---|---|---|
解像度がネットワーク負荷に与える影響は、一般的に係数の二乗です。画像の大きさが 2 倍のときは、4 倍の帯域幅が必要になります。また、カラー サンプリング、量子化、およびフレーム レートも、ネットワークのトラフィック量に影響を与えます。標準レートは 30 フレーム/秒(fps)ですが、これは AC 電源の周波数に基づいて選択した任意の値です。ヨーロッパでは、従来のアナログ ビデオは 25 fps です。シネプレックス向けの映画は 24 fps で撮影されています。フレーム レートが下がるにつれて、ネットワークの負荷も少なくなりますが、動きの臨場感は低下します。ビデオが 24 fps を超えても、動きが大幅に改善されることはありません。
また、エンコーダの高性能化も、ビデオの負荷に大きく影響します。H.264 エンコーダは、最適なエンコード方法を決定するときに優れた柔軟性を発揮するため、最適な方法を決定するときに複雑になります。たとえば、MPEG4.10 では、エンコーダが周辺ピクセルに応じて最適なブロック サイズを選択できます。効率的なエンコードはデコードよりも難しく、送信者がネットワークの負荷を判断するため、通常の低コストのエンコーダは高性能なエンコーダよりも多くの帯域幅を必要とします。リアルタイム CIF ビデオの H.264 コーディングではすべてを使用しますが、専用のメディア プロセッサを装着しないと、最も強力なラップトップの CPU 使用率は 90 % になります。
表 13-3 から 表 13-5 では、エンドポイントと解像度に基づいた帯域幅の平均使用範囲を示します。次の表では、一般的な TelePresence エンドポイントおよびデスクトップ ビデオ エンドポイントの解像度に基づいた帯域幅範囲の例のみを示します。対象のエンドポイントに関連する最新の数値については、最新の製品マニュアルを参照してください。
|
|
|
|
|
||||
---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
1.TelePresence エンドポイントの詳細については、https://www.cisco.com/c/dam/en/us/products/collateral/collaboration-endpoints/tested_bandwidth_whitepaperx.pdf で入手可能な帯域幅使用に関するホワイト ペーパーを参照してください。 |
|
|
---|---|
2.DX シリーズの詳細については、https://www.cisco.com/c/en/us/support/collaboration-endpoints/desktop-collaboration-experience-dx600-series/products-maintenance-guides-list.html で入手可能な最新版の『Cisco DX Series Administration Guide』を参照してください。 |
|
|
---|---|
3.Jabber の詳細については、https://www.cisco.com/c/en/us/support/unified-communications/jabber-windows/products-installation-guides-list.html で入手可能な最新版の『Cisco Jabber Deployment and Installation Guide』を参照してください。 |
ブロードキャスト ビデオは、マルチキャストで提供される帯域幅節減の活用に役に立ちます。これは長年にわたり、多くのネットワークに導入されています。マルチキャストの最近の改善により、ネットワークへの導入が簡単になりました。マルチキャストは今後も使用されますが、すべての状況で使用されるわけではありません。マルチポイント TelePresence など、一部のアプリケーションはビデオの複製専用の MCU を使用します。MCU は、どの参加者が各送信者を表示するかについて判断することができます。また、MCU は表示されていない送信者を抑制することもできます。
MPEG4 は MPEG2 と同じ転送を使用します。PES は IP にロードされる 188 バイト データグラムで構成されます。ビデオ パケットは RTP/UDP/IP または HTTP(S)/TCP/IP にロードできます。
UDP 経由のビデオは、マルチメディア会議や TelePresence などの専用リアルタイム アプリケーションで使用されます。この場合、RTCP チャネルは受信者から送信者に対して設定できます。これを使用すると、ビデオ セッションを管理できます。RTCP を使用すると、I フレームを要求したり、送信者に機能を報告したりできます。UDP および RTP はそれぞれ多重チャネルの手段を提供します。通常、音声およびビデオは異なる UDP ポートを使用しますが、RTP ペイロード タイプも固有です。ディープ パケット インスペクション(DPI)をネットワークで使用すると、現在のビデオ音声のタイプを特定できます。また、H.264 ビデオは、ビデオの多重レイヤに関するメカニズムも提供しています。
ジッターおよび遅延はすべての IP ネットワーク内に存在します。ジッターは遅延の変動です。一般的に遅延は、インターフェイスのキューイングが原因で発生します。ビデオ デコーダで再生バッファを使用すると、ネットワーク内のジッターを抑えることができます。このバッファの深さには制限があります。浅すぎると、廃棄されてしまいます。深すぎると、ビデオが遅延するため、TelePresence などのリアルタイム アプリケーションで問題が発生する場合があります。再生バッファが深いことの多い廃棄パケットを処理するために別の制限があります。RTCP を使用して新しい I フレームを要求する場合、再同期化のときに多くのフレームがスキップされます。その結果、失われたパケットが見つかった場合に与える影響よりも、廃棄パケットがビデオの品質低下に与える影響のほうが若干大きくなります。ほとんどのコーデックがダイナミック再生バッファを使用します。
この追加負荷を適切に考慮して計画しないと、ビデオはネットワークのパフォーマンスに大きな影響を与える場合があります。この章は、管理者が企業ネットワークでリアルタイム ビデオを管理する場合に役立ちます。
シスコの企業向けビデオ エンドポイントは過去数年間で大きく進化しました。シスコのすべてのビデオ エンドポイントでは多くのメディアの復元力手法を使用して、ネットワークの輻輳の回避、パケット損失からの回復、ネットワーク リソースの最適化を行います。このセクションでは、シスコのビデオ エンドポイントで使用されている次のスマート メディアの手法についてします。
パケット数は、フレーム タイプ(I または P)と必要なパケットの数に応じて変化します。つまり、始まり、途中、または最後で 33 ミリ秒間隔のパケットのバーストが発生します。これにより、パケットがネットワークを流れると、帯域幅が急激に上昇します。エンコーダ ペーシングは、帯域幅のバーストのピークをスムーズにするために、33 ミリ秒間隔でパケットを可能な限り均等に分散する簡単な手法です。図 13-7 はこの手法を示します。
図 13-7 上部のグラフは、エンコーダ ペーシングを使用せずにネットワーク上を流れるパケットを示し、下部のグラフはエンコーダ ペーシングを使用した場合を示しています。各フレームが 33 ミリ秒間隔でネットワーク上でパケット化されるため、エンドポイント パケット スケジューラは、単一間隔でパケットを可能な限り均等に分散します。大きな I フレームは、2 つまたは 3 つのフレーム間隔に「分ける」必要があり、エンコーダはビット レート範囲内に収めるために 1 つまたは 2 つのフレームをスキップすることがあります。このため、同じ期間での帯域幅使用率のピークが分散されます。
GDR は、エンコードされたビット ストリームの開始点または更新を提供します。GDR は、多数のフレームで画像を徐々にリフレッシュして、よりスムーズでバースト性の低いビット ストリームを提供する方法です。
新しい I フレームではトラフィックのバーストが起こるため、特に会議の切り替え時に輻輳が発生します。I フレーム パケットが 1 つ廃棄されると、フレーム全体を再送信する必要があります。図 13-8 で示すように、Gradual Decoder Refresh は N フレームに対して「内部的」にエンコードした画像データを拡散します。GDR フレームには、「内部的」なマクロブロックの部分と予測したマクロブロックの部分が含まれます。GDR のすべてのフレームを受信したら、デコーダは画像を完全に更新できます。
図 13-8 Gradual Decoder Refresh(GDR)
長時間参照フレーム(LTRF)は、エンコーダおよびデコーダが別の方法で明示的な信号を受信するまで、エンコーダおよびデコーダに保存される参照フレームです。(H.264 では最大 15 LTRF がサポートされます。)通常(LTRF 未使用時)、パケットの損失後、エンコーダ/デコーダの再同期化には内部フレームが使用されます。
LTRF は、エンコーダとデコーダの再同期化の代替手法として、通常の内部フレームよりも優れています。通常、エンコーダは LTRF を一定の間隔で挿入し、それと同時にその LTRF を 1 つ以上を保存するようにデコーダに指示します(図 13-9 を参照)。
修正 P フレームは、参照として正しくデコードされた以前の LTRF を使用します。修正 P フレームは、損失フレームまたはその参照フレームに応じて使用されます。確認 LTRF がデコーダで適切に受信されていると分かっているため、デコーダが修正 P フレームを適切にデコードできる場合は、同期状態に戻ることが確認されています。
図 13-9 から分かるように、LTRF は、アクティブ フィードバック メッセージを使用して、エンコーダとデコーダの同期を維持します。エンコーダは、長時間参照フレーム(H.264 標準の一部)として特定の同期ポイントで未処理のフレームを保存するようにデコーダに指示します。デコーダは「バック チャネル」(RTCP)を使用して LTRF を確認します。フレームが失われると、エンコーダは、新しい I フレームの代わりに、最後に同期した LTRF に基づいて修正 P フレームを作成するため、帯域幅が保存されます。
前方誤り訂正(FEC)では、所定のアルゴリズムを使用して、転送される情報に冗長性を付与します(図 13-10 を参照)。この冗長性により、受信側では、メッセージのいずれかの箇所でエラーが発生した場合でもそれが一定数であれば、送信側に追加データを要求することなく、そのエラーを検出し訂正することができます。FEC では、受信側でエラーを訂正する場合、データの再送信を要求するためのリバース チャネルは必要ありませんが、その代わりとして、より高い転送チャネル帯域幅が常に必要となります。FEC では最も重要なデータ(通常は修正 P フレーム)が保護されます。これにより、それらのフレームは受信側で確実に受信されます。エンドポイントでは、帯域幅が 768 kbps を下回る場合 FEC は使用されません。また、1.5 % 以上のパケット損失が発生していない場合も FEC は適用されません。通常、FEC の有効性はエンドポイントによりモニタリングされます。FEC が有効でない場合は、エンドポイントにより FEC の実行が中止されます。
図 13-10 から分かるように、FEC により、同期化が失われることなく、デコーダは一定量のパケット損失から復元できます。これは、損失の多い環境で「重要」なフレームを保護するために、さまざまなレベル( N データ パケットごとの X FEC パケットなど)で適用できます。修正コードには、基本(バイナリ XOR)または高度(Reed-Solomon)があります。帯域幅の使用ではトレードオフが増えているため、非バースト損失に最適です。
レート調整またはダイナミック ビット レート調整は、使用できる可変帯域幅に合わせてコール レートを調整します。これにより、パケット損失の状況に基づいてビデオ ビット レートの速度が上下します(図 13-11 を参照)。パケット損失が減少すると速度が上昇します。一部のエンドポイントでは、RTCP を介して送信側プロアクティブ方式が使用されます。この場合、送信側では常に RTCP レシーバー レポートの確認が行われ、その内容に従ってビット レートが調整されます。その他のエンドポイントでは、受信側方式が使用され、コール シグナリング(H.323 フロー制御、TMBRR、SIP Re-invite)または RTCP メッセージ内の明示的な要求を介して調整されます。
図 13-11 から分かるように、受信側は長時間にわたって遅延とパケット損失を観察し、RTCP レシーバ レポート(RR)を使用して信号を返します。このレポートにより、送信側は、ネットワークの状況に合わせてビット レートを調整します(ビット レートの速度の上下)。
|
|
|
|
|
---|---|---|---|---|
サービス品質(QoS)により、メディア エンドポイントおよびアプリケーションの遅延、パケット損失、ジッターの削減し、信頼性のある高品質な音声とビデオを実現します。QoS は、音声、ビデオ、データ ネットワークの透過的なコンバージェンスをサポートするのに必要な基本的なネットワーク インフラストラクチャ技術を提供します。インタラクティブ アプリケーション(特に音声、ビデオ、およびイマーシブ アプリケーション)の増加に伴い、多くの場合、ネットワークのリアルタイム サービスが求められます。これらのリソースは限られているため、効率的かつ効果的に管理する必要があります。優先リソースのフロー数に制限がない場合は、これらのリソースがオーバーサブスクライブされるため、すべてのリアルタイム トラフィック フローの品質が低下し、最終的には役に立たなくなります。「スマート」メディアの手法、QoS、およびアドミッション制御により、リアルタイム アプリケーションとその関連メディアが、これらのアプリケーションにプロビジョニングされたネットワークおよび帯域幅をオーバーサブスクライブしないようにします。QoS に関連するこれらのスマート メディアの手法と、必要に応じたアドミッション制御は、リアルタイム メディアを非リアルタイム ネットワーク トラフィックから保護し、ネットワークをオーバーサブスクリプションから保護して、音声とビデオのすべてのアプリケーションの潜在的な品質低下を回避するための強力なツール セットです。
アドミッション制御と QoS は相互に補完します。アドミッション制御には QoS が必要ですが、QoS はアドミッション制御がなくても導入できます。この章の後半では、アドミッション制御と QoS との関係について詳しく説明します。
図 13-12 は、この章で使用する QoS の手法について示しています。この手法は次のフェーズで構成されており、このセクションの後半で詳しく説明します。
このフェーズでは、信頼されているエンドポイントおよび信頼されていないエンドポイントに対するメディアとシグナリングの識別に関する信頼と手法の概念について説明します。信頼されているエンドポイントと信頼されていないエンドポイントの両方のネットワーク全体に、エンドツーエンドの適切な Per-Hop Behavior を使用してメディアとシグナリングを提供するために、識別したトラフィックを適切な DSCP にマッピングするプロセスが含まれます。
このフェーズは、一般的な WAN のキューイングとスケジューリング、各種キューイング、およびコラボレーション メディアとシグナリングが WAN への出力で正しくキューイングするための推奨事項で構成されています。
このフェーズでは、ネットワークでの帯域幅のプロビジョニング、およびエンドポイント グループが使用する最大ビット レートの測定について説明します。また、コール アドミッション制御を必要なネットワーク領域に実装することもできます。
このフェーズは、ネットワークでの音声とビデオの適切な操作および管理に必要不可欠ですが、この章では説明しません。これらの作業の詳細については、ネットワーク管理の章を参照してください。
図 13-12 コラボレーション用の QoS アーキテクチャの要素
このセクションでは、信頼されているエンドポイントおよび信頼されていないエンドポイントに対するメディアとシグナリングの識別に関する信頼と手法の概念について説明します。信頼されているエンドポイントと信頼されていないエンドポイントの両方のネットワーク全体に、エンドツーエンドの適切な Per-Hop Behavior を使用してメディアとシグナリングを提供するために、識別したトラフィックを適切な DSCP にマッピングするプロセスが含まれます。
QoS の適用は、リアルタイムの音声、ビデオ、またはイマーシブ ビデオ エクスペリエンスに必要不可欠です。ネットワークで QoS(分類、優先順位付け、およびキューイング)を適切に処理しないと、リアルタイム メディアに過度の遅延またはパケット損失が発生する可能性があり、リアルタイム メディア フローの品質が低下します。QoS の適用のパラダイムでは、信頼の問題と信頼境界が同様に重要です。信頼は、トラフィックの QoS マーキング(レイヤ 2 CoS またはレイヤ 3 IP DSCP)を許可または「信頼」し、ネットワークを介して継続できるエンドポイントまたはデバイスを示しています。信頼境界は信頼するネットワーク内の場所です。これはネットワーク内のあらゆる場所で設定できますが、LAN アクセス入力や WAN エッジ、または必要に応じてその両方など、ネットワーク エッジで信頼を適用することをお勧めします。WAN エッジはトラフィック入力の別の分野で、サービス プロバイダーはネットワーク(サービス プロバイダー ネットワーク)全体の使用方法についてトラフィックを再度マーキングすることがあります。このため、エンドツーエンドの企業ネットワーク全体の継続性を確保するために、トラフィックを再度マーキングして適切な値に戻すことが重要です。
Cisco IP Phone およびビデオ エンドポイントを使用したシスコのコンバージド ネットワークでは、Cisco Discovery Protocol(CDP)を使用して IP Phone を検出するようにスイッチを設定できます。その後は、IP Phone またはビデオ エンドポイントのスイッチ ポートに接続された PC のマーキングを信頼していなくても、Cisco IP Phone およびビデオ エンドポイントが送信するパケットの DiffServ コード ポイント(DSCP)マーキングをスイッチは信頼できます。これは条件付き信頼と呼ばれます。Cisco IP Phone のみが許可され(音声 VLAN と呼ばれる)、そのパケット マーキングがスイッチによって信頼され、変更されていないネットワークを介して送られる、保護された VLAN では一般的です。一般的に、信頼されていないクライアント(PC や Mac など)が通常配置された VLAN(データ VLAN と呼ばれる)から配信されるトラフィックは信頼しません。通常、データ VLAN またはネットワーク内の同等の領域にあるデバイスから配信されるパケットは、ベスト エフォート(IP DSCP 0)に再マーキングされます。
信頼の観点から、エンドポイントには次の 3 つの主なカテゴリがあります。
図 13-13 では、次の 3 つのタイプのデバイスについて説明します。
信頼境界は、管理上技術的に実現可能なエンドポイントのできるだけ近くに設定する必要があります。推奨事項は、スイッチで信頼を設定し、コラボレーション メディアとシグナリング用の音声 VLAN を使用し、コラボレーション以外のデータ トラフィック用のデータ VLAN を使用するためのものです。レイヤ 2 アクセス設計の詳細については、キャンパス アクセス レイヤを参照してください。
信頼境界が確立されると、QoS の適用はデバイスの 2 つのカテゴリ(信頼されていると信頼されていない)に分類されます。このセクションは、信頼されているデバイスと信頼されていないデバイスの分類およびマーキングについて説明します。
信頼されているエンドポイントおよび条件付きで信頼されているエンドポイントの場合、スイッチへの入力パケットの DSCP マーキングは信頼されており、出力で同じ値に再び書き換えられます。図 13-14 では、信頼されているエンドポイントの音声、ビデオ、信号トラフィックのマーキング、およびそのマーキングを信頼しているスイッチについて示します。
信頼されているポートまたは条件付きで信頼されているポートで設定されたシスコのスイッチの場合、スイッチは、CoS を使用して DSCP にマッピングするか、または元の DSCP を使用して、この DSCP を送信パケットの IP ヘッダー DSCP にマッピングします。図 13-15 では、レイヤ 2(CoS)およびレイヤ 3(DSCP)の受信パケット マーキングを示します。信頼のタイプには、信頼されている(CoS 信頼または DSCP 信頼)または信頼されていないがあります。内部スイッチ パケット上書きプロセスは、CoS 信頼または DSCP 信頼に基づいています。
図 13-15 には、マルチレイヤ スイッチング(MLS)コマンドのほんの一例が示されています。MLS プラットフォームには、Cisco 2960、3560、および 3750 シリーズ スイッチ プラットフォームがあります。現在出荷されている他のすべてのスイッチ プラットフォーム(Cisco 3650、3850、4500、6500、および 6800 シリーズ スイッチ プラットフォームなど)の信頼はデフォルトで有効になっています。
図 13-15 では、次の 3 つのイベントを示しています。
1. CoS 5 および DSCP 46 とマーキングされたパケットは、信頼されていないポートで受信されます。0(BE)の内部 DSCP を使用して、送信パケット CoS および DSCP を 0 に書き換えます。
2. CoS 5 および DSCP 46 とマーキングされたパケットは、信頼されているポート(CoS 信頼)で受信されます。CoS-to-DSCP マッピング テーブルで参照が実行され、CoS 5 が内部 DSCP 40 にマッピングされます。40 の内部 DSCP を使用して、送信パケット CoS を 5 に、DSCP を 40 に書き換えます。CoS-to-DSCP マッピング テーブルにはデフォルト値が設定されていますが、静的 CoS-to-DSCP マッピングに変更することができます。たとえば、CoS 5 は DSCP 46 にマッピングできます(EF)。
3. CoS 5 および DSCP 46 とマーキングされたパケットは、信頼されているポート(DSCP 信頼)で受信されます。46(EF)の内部 DSCP を使用して、送信パケット CoS を 5 に、DSCP を 46(EF)に書き換えます。
CDP 対応 Cisco IP Phone、Cisco CTS、Cisco IP Video Surveillance カメラ、Cisco Digital Media Player(Jabber などのソフトウェア クライアントとは対照的)の場合、CDP の条件付き信頼を使用し、ネットワークを介して信頼されているエンドポイントのマーキングを転送することをお勧めします。Cisco IP Phone を信頼するように選択した場合は、IP Phone がレイヤ 2 で PC トラフィックのみを再マーキングできるため、CoS を信頼する必要があります。信頼されているエンドポイントは、Unified CM から DSCP マーキングを取得します。エンドポイントの DSCP は、[クラスタ全体のパラメータ(システム:QoS)(Clusterwide Parameters (System - QoS))] の Unified CM サービス パラメータで設定されます。
Unified CM では、CallManager サービスのサービス パラメータと SIP デバイスにのみ適用される SIP プロファイルの 2 つの場所にエンドポイントの QoS 設定が保存されます。QoS 設定の SIP プロファイル設定により、サービス パラメータ設定が上書きされます。これにより、Unified CM の管理者はエンドポイント グループの異なる QoS ポリシーを設定することができます(帯域幅管理の設計例を参照)。エンドポイント登録時、Unified CM は、この QoS 設定を TFTP 経由で設定ファイルとしてエンドポイントに転送します。この設定ファイルには、QoS パラメータと、他の多くのエンドポイント固有のパラメータが含まれます。QoS のために、ビデオ エンドポイントには 2 つのカテゴリがあります。TelePresence エンドポイント(電話タイプ名で TelePresence のエンドポイント)と、このマニュアル内で「UC ビデオ エンドポイント」と呼ばれている他のすべての TelePresence 以外のビデオ エンドポイントです。図 13-16 では、シスコのビデオ エンドポイントの 2 つのカテゴリが DSCP を取得する方法について示します。これらのカテゴリは QoS とコール アドミッション制御にのみ適用されることに注意してください(Telepresence イマーシブ ビデオの Enhanced Location CACを参照)。
図 13-16 シスコのエンドポイントによる DSCP の取得方法
図 13-16 に示されている [ビデオコールのオーディオ部分の DSCP(DSCP for Audio Portion of Video Calls)] および [TelePresence コールのオーディオ部分の DSCP(DSCP for Audio Portion of TelePresence Calls)] のパラメータは、すべてのビデオ エンドポイントでは現在サポートされていません。これらのパラメータをサポートするエンドポイントのタイプについては、 表 13-8 を参照してください。
設定ファイルは、設定時に CallManager サービス パラメータまたは SIP プロファイルの QoS パラメータと統合され、登録時にエンドポイントに送信されます。次に、エンドポイントは、エンドポイントのカテゴリに応じて、メディア ストリームの各タイプに正しい DSCP パラメータを使用します。 表 13-7 に、DSCP パラメータ、エンドポイントのタイプ、ストリームの DSCP マーキングを決定するコール フローのタイプの一覧を示します。
|
|
|
|
---|---|---|---|
○5 |
|||
ビデオ:ビデオ コールの音声とビデオ ストリーム。ただし、エンドポイントは [ビデオコールのオーディオ部分の DSCP(DSCP for Audio Portion of Video Calls)] パラメータをサポートします。 |
|||
ビデオコールのオーディオ部分の DSCP(DSCP for Audio Portion of Video Calls)6 |
|||
イマーシブ ビデオ:イマーシブ ビデオ コールの音声とビデオ。ただし、エンドポイントは [TelePresence コールのオーディオ部分の DSCP(DSCP for Audio Portion of TelePresence Calls)] パラメータをサポートします。 |
|||
TelePresence コールのオーディオ部分の DSCP(DSCP for Audio Portion of TelePresence Calls) 3 |
4.マルチレベルのプライオリティおよびプリエンプション(MLPP)の DSCP 設定について、このドキュメントでは説明しません。MLPP 設定および QoS 設定の詳細については、最新版の『System Configuration Guide for Cisco Unified Communications Manager』を参照してください。 5.TelePresence ビデオ エンドポイントの中で、DX シリーズ エンドポイントのみが [音声コールの DSCP(DSCP for Audio Calls)] と対応する [TelePresence コールのオーディオ部分の DSCP(DSCP for Audio Portion of TelePresence Calls)] をサポートします。ただし、エンドポイントが CE ソフトウェアを実行している場合に限ります。 6.このパラメータは、すべてのビデオ エンドポイントでは現在サポートされていません。このパラメータをサポートするエンドポイントのタイプについては、表 13-8 を参照してください。 |
|
|
|
---|---|---|
○7 |
||
○8 |
||
CE 8.x ソフトウェア シリーズ(DX70、DX80、SX シリーズ、MX シリーズ G2、MX700、MX800) |
||
次の新機能とシステム全体の機能が原因により、現在の DSCP のデフォルト値が推奨値であるとは限りません。この詳細については、帯域幅管理の設計例で説明します。
信頼されていないエンドポイントの場合、スイッチ入力のパケットの DSCP マーキングは信頼されておらず、0(BE)に書き換えられます。図 13-17 では、音声、ビデオ、信号トラフィックをマーキングする信頼されていないエンドポイントと、送信パケットのこの値を書き換えるスイッチを示します。
図 13-17 信頼されていないエンドポイントの再マーキング
一般的に、PC、Mac、または携帯型モバイル デバイスでユーザが設定できるマーキングの信頼はお勧めしません。ユーザは自分のトラフィックをマーキングする場合(OS の管理権限を持つ場合)、プロビジョニングされた QoS ポリシーを悪用できます。たとえば、EF の DSCP がネットワークでプロビジョニングされている場合、PC ユーザはすべてのトラフィックを EF にマーキングするように設定できるため、ネットワーク プライオリティ キューをハイジャックしてリアルタイム以外のトラフィックを処理できます。このように悪用すると、企業全体のリアルタイム アプリケーションのサービス品質を簡単に台無しにできる可能性があります。一方、Windows 環境のグローバルポリシーオブジェクトなど、PC の QoS マーキングを一括で管理するように企業のコントロールをまとめると、PC のマーキングを信頼することも可能です。OSX が動作する Mac および携帯型モバイル クライアントの場合、マーキングを信頼するかどうかという問題が残ります。この方法については、「QoS の信頼、分類、マーキングでのオペレーティング システムの使用」セクションで説明します。一般的なルールでは、個人のコンピューティング デバイスは信頼しませんが、トラフィックを再マーキングする方法が必要です。
Jabber などのソフトウェア クライアントからのメディアおよびシグナリング ストリームが、適切に分類およびマーキングされるようにするため、信頼とは異なる方法が必要です。ある方法では、UDP と TCP ポートなどの特定のプロトコル ポートに応じて識別可能なメディアとシグナリング ストリームをマッピングし、ネットワーク アクセス リストを使用して、そのプロトコル ポート範囲に応じたシグナリングとメディア ストリームの QoS を再マーキングします。この方法は、メディアとシグナリング ポート範囲の割り当て時、Cisco Jabber クライアントがすべて同じように動作するため、すべての Cisco Jabber クライアントに適用されます。この方法は、パケット DSCP 再マーキングを実現するためのアクセス リストに応じたポリシーを作成するネットワークの使用から、Windows OS 自体(ここでは Jabber for Windows クライアントのみ適用)を使用したネットワーク内の PC のマーキングの信頼までカバーします。
また、信頼の問題のため、Cisco Jabber クライアントで QoS を簡単に実現できる方法として最も幅広く導入および推奨されています。Jabber クライアントには、Cisco Jabber for Windows、Cisco Jabber for Mac OS、Cisco Jabber for iPhone、Cisco Jabber for iPad、および Cisco Jabber for Android があります。
この概念はシンプルです。PC からのトラフィックがすべて信頼できるわけでないため、UDP ポート範囲に応じたメディアとシグナリング ストリームを特定し、それらを適切な値に再マーキングするために、ネットワーク アクセス レイヤ装置でアクセス リストが使用されます。この手法は実装が簡単で、幅広く導入できますが、安全な方法ではありません。
図 13-18 では、ネットワーク アクセス コントロール リスト(ACL)を使用した、DSCP への識別可能なメディアとシグナリング ストリームのマッピングを示します。
図 13-18 DSCP への UDP/TCP ポート範囲のマッピング
図 13-18 では、次の Jabber クライアントの ACL ベースの QoS ポリシー例を示します。
(注) 次のアクセス コントロール リストの例は、Cisco Common Classification Policy Language(C3PL)に基づいています。C3PL をサポートしていないシスコ デバイスまたは C3PL の更新済みコマンドに対して同じポリシーを実現するには、特定のスイッチまたはルータの設定ガイドを参照してください。この設定は、モジュール型 QoS CLI-MQC、マルチレイヤ スイッチング(MLS)、および C3PL などの現在出荷されているすべてのスイッチに適用できます。
前述したように、この方法では、IP アドレス、プロトコル、プロトコル ポート範囲に応じて Jabber クライアントからのさまざまなストリームを特定することで、メディアとシグナリングを分類します。いったん特定されると、シグナリングとメディア ストリームは、対応する DSCP で分類および再マーキングできます。プロトコル ポート範囲は Unified CM で設定し、デバイス登録時に使用するエンドポイントに転送されます。次にネットワークをアクセス コントロール リスト(ACL)経由で設定し、IP アドレス、プロトコル、プロトコル ポート範囲に応じてトラフィックを分類し、前述の適切な DSCP で分類したトラフィックを再マーキングできます。
Cisco Jabber は、UDP プロトコル ポート範囲に応じて識別可能なメディア ストリームおよび TCP プロトコル ポート範囲に応じて識別可能なシグナリング ストリームを提供します。Unified CM では、エンドポイントのシグナリング ポートは SIP セキュリティ プロファイルで設定しますが、メディア ポート範囲は Cisco Unified CM の管理ページの SIP プロファイルで設定します。
メディア ポート範囲の場合、すべてのエンドポイントおよびクライアントは、SIP プロファイル パラメータの [メディアポートの範囲(Media Port Range)] を使用して、メディアで使用される UDP ポートを取得します。デフォルトでは、メディア ポート範囲は [オーディオおよびビデオ用コモンポートの範囲(Common Port Range for Audio and Video)] で設定します。Jabber クライアントが Config ファイルでこのポート範囲を受け取ると、ポート範囲を半分に分割し、オーディオとビデオの両方のコールのオーディオ ストリームに下半分を使用し、ビデオ コールのビデオ ストリームに上半分を使用します。[メディアポートの範囲(Media Port Range)] > [オーディオおよびビデオ用コモンポートの範囲(Common Port Range for Audio and Video)] の設定を使用する場合、Jabber はビデオ UDP ポート範囲にビデオ コールのオーディオを配置しません。図 13-19 でこれについて説明します。
Jabber は、[メディアポートの範囲(Media Port Range)] > [オーディオとビデオのポート範囲の分割(Separate Port Range for Audio and Video)] の設定も使用できます。この設定では、Unified CM の管理者は、図 13-20 に示すように連続しないオーディオとビデオ ポートの範囲を設定できます。
UDP ポート範囲の割り当てに関する Jabber クライアントの動作が原因で、QoS マーキングで Enhanced Locations Call Admission Control(EL-CAC)の帯域幅削減を適切にマッピングできないことがあります。CAC は音声プールからオーディオ専用コールの帯域幅を削減しますが、ビデオ コールのオーディオとビデオの両方の帯域幅がビデオ プールから削減されます。アドミッション制御ロジックに一致させるには、音声専用コールのオーディオ ストリームを EF としてマーキングする必要がありますが、ビデオ コールのオーディオとビデオの両方のストリームは AF41 とマーキングする必要があります。Cisco Jabber クライアントおよび UDP ポート範囲を使用して識別可能なメディア ストリームをマッピングする場合、音声専用コールのオーディオとビデオ コールのオーディオを区別することはできません。そのため、この手法は QoS のみを実現する場合に効果的です。したがって、EF としてオーディオを送信する Jabber クライアントからのビデオ セッションのオーディオを考慮するには、EF トラフィックのプライオリティ キューをオーバープロビジョニングするか、または代わりの DSCP を使用することをお勧めします。帯域幅管理の設計例では、いくつかの方法について説明します。
この手法を使用する場合、オーディオ トラフィック クラス(EF)に再マーキングされるこれらのビデオ コールのオーディオ部分、およびビデオ トラフィック クラス(AF4)に再マーキングされるビデオ部分が、状況に応じてネットワーク内でプロビジョニングされるようにすることが重要です。図 13-21 では、プライオリティ キュー(PQ)へのオーディオ トラフィックの配置、およびクラスベースの重み付け均等化キュー(CBWFQ)へのビデオ トラフィックの配置の例を示します。Cisco Jabber エンドポイントのポート範囲で音声専用コールのオーディオとビデオ コールのオーディオを識別することはできないため、この手法を使用するオーディオはすべて EF と再マーキングされます。音声専用とビデオ コールの音声部分をサポートするには、PQ を適切にプロビジョニングすることが重要です。図 13-21 では、このプロビジョニングの例を示します。ネットワーク内でキューイングとスケジューリングをプロビジョニングするときの設計および導入に関する推奨事項については、WAN キューイングとスケジューリングを参照してください。
図 13-21 ネットワークでの Jabber QoS のプロビジョニング
RFC 3551 に準拠して、RTCP がエンドポイントで有効な場合は、次に大きな奇数のポートが使用されます。たとえば、ポート 3500 で RTP ストリームを確立するデバイスは、ポート 3501 で同じストリームの RTCP を送信します。RTCP のこの機能は、すべての Jabber クライアントにも当てはまります。RTCP はほとんどのコール フローに共通しており、ストリームの統計情報用として一般的に使用され、ビデオ コールのオーディオとビデオを同期して適切なリップシンクを実現します。ほとんどの場合、ビデオおよび RTCP は、エンドポイント自体または電話の共通プロファイル設定で有効または無効にできます。
Jabber クライアントで作成した識別可能なメディアおよびシグナリング ストリームに基づいて、共通ネットワーク QoS ツールを使用して、これらのクラスに従ってトラフィック クラスを作成し、パケットを再マーキングできます。
これらの QoS メカニズムは、アクセス レイヤ(アクセス スイッチ)などの異なるレイヤで適用できます。これは、ディストリビューション、コア、またはサービスの WAN エッジのエンドポイントおよびルータ レベルに最も近いレイヤです。分類および再マーキングの実行場所に関係なく、エンドツーエンドの Per-Hop Behavior を実現するために DSCP を使用することをお勧めします。
前述したように、Cisco Unified CM により、SIP エンドポイントで利用されるポート範囲は、SIP プロファイルで設定できます。一般的なルールとして、ポート範囲が最小 100 ポート(たとえば、3000 ~ 3099)あれば、ほとんどのシナリオで足ります。さまざまなオーディオ、ビデオ、および関連する RTCP ポートに十分なポートを割り当てられるのであれば、範囲を狭く設定することができます(RTCP は範囲内で奇数のポート上で実行されます)。
(注) SCCP 音声専用エンドポイントが導入されたネットワークで Jabber クライアントを導入する場合、SCCP エンドポイントは、音声専用コールに対して設定不可能なハードコードされた範囲(16384 ~ 32767)を使用します。このため、SIP デバイスのメディア ポート範囲を変更しない場合は、SCCP 音声専用コールが SIP ビデオ対応エンドポイント コールと同じ範囲上で実行されます。SCCP を使用するように設定されたエンドポイントでコラボレーション ソリューションを導入する場合、16384 ~ 32767 の範囲外にある Jabber クライアントのメディア ポート範囲を設定することをお勧めします。3000 ~ 4999 のビデオ対応 Jabber クライアントと 3000 ~ 3999 の音声専用 Jabber クライアントの上記の例は、SCCP エンドポイントの重複を回避するのに非常に役立ちます。
重複を回避するための推奨事項は、他の SIP ベースのビデオ エンドポイントにも適用されます。SCCP ベースのオーディオ エンドポイント範囲での重複を回避するには、SIP ベースのビデオ エンドポイントを、SCCP ベースのオーディオ ポート範囲(16384 ~ 32767)または Jabber クライアント メディア ポート範囲で重複しないポート範囲に割り当てる必要もあります。
トラフィックの分類にアクセス レイヤを使用する場合、ネットワークへのトラフィックの入力時に分類が行われるため、入力に合わせてフローが識別されます。QoS ポリシーが WAN と LAN 内にも適用される環境では、すべてのアップストリーム コンポーネントが、処理時にトラフィック マーキングを使用できます。入力時の分類により、各種エンドポイントに応じてさまざまな方法を使用できます。IP Phone などの物理的なエンドポイントは、Cisco Discovery Protocol(CDP)または Link Layer Discovery Protocol-Media Endpoint Discovery(LLDP-MED)のようなメカニズムを使用して信頼関係を確立することができます。デバイスが信頼済みと識別されると、そのデバイスから受信する QoS マーキングはネットワーク全体で信頼されます。
ネットワークのアクセス レイヤで QoS ポリシーを設定すると、大量のデバイスの設定が必要になる場合があるため、新たな運用上のオーバーヘッドが発生する可能性があります。QoS ポリシー設定は、テンプレートを通じてアクセス レイヤの各種スイッチ全体で標準化する必要があります。設定導入ツールを使用すると、手動設定の負担を軽減できます。
QoS マーキングが行われる場所は、レイヤ 3 のルート設定済み境界にあります。キャンパス ネットワークでは、レイヤ 3 は、アクセス、ディストリビューション、コア、またはサービス WAN エッジ レイヤでもかまいません。信頼境界を構築し、アクセスで分類および再マーキングすることをお勧めします。次に、ネットワークのディストリビューションとコア経由で信頼し、WAN エッジで最終的に再分類および再マーキングします。レイヤ 3 スイッチング コンポーネントを導入していない支店などの小規模なネットワークの場合、QoS マーキングは WAN エッジ ルータで適用できます。レイヤ 3 では、QoS ポリシーがレイヤ 3 ルーティング インターフェイスに適用されます。ほとんどのキャンパス ネットワークでは、VLAN インターフェイスですが、ファスト イーサネットまたはギガビット イーサネット インターフェイスの場合もあります。図 13-22 では、ネットワーク内の場所(アクセス、ディストリビューション、コア、および WAN エッジ)に関連して、さまざまなタイプの信頼が適用されるネットワークの領域を示します。
Cisco Jabber クライアントの QoS の信頼で別の方法を使用すると、アプリケーションが実行されるオペレーティング システムが、アプリケーションの要求に応じてメディアとシグナリングの QoS をマーキングできます。この方法の利点は、ネットワーク オペレータがオペレーティング システム自体に QoS の信頼モデル拡張して、次に QoS マーキングを「信頼」し、ネットワークを介してそのマーキングを送れるようにネットワークを設定できることです。これは、企業が QoS 信頼を Windows PC、Mac OS、携帯型デバイスに拡張する際の一般的な方法ではありません。それは、この方法では、認証されたアプリケーション通信のトラフィックだけでなく、デバイスのトラフィックをすべて信頼するためです。このようなアプリケーションをこれらのデバイスにインストールして使用すると、プライオリティ QoS が「ハイジャック」され、QoS 導入の本来の目的が失われることがあります。管理上のグローバル ポリシーを介して、管理者は、OS が不要なアプリケーションまたは設定を受け入れないように、Windows OS など、一部のオペレーティング システムまたはユーザ アクセス コントロールを管理できます。このような場合、QoS 信頼でこの方法の使用が許可される場合があります。
Windows 7 および 8 オペレーティング システムでは、特定のポリシーを設定する必要があります。Mac OS、Apple iOS、および Android デバイスでは、OS は、特定のポリシーを設定する必要はなく、アプケーションの要求時にネイティブにマーキングします。
次のセクションでは、Cisco Jabber クライアントと、各オペレーティング システムがアプリケーションの QoS 分類とマーキングに対してどのように機能するかについて説明します。これらのセクションで説明する内容はすべて、レイヤ 2 サービス クラス(CoS)ではなく、レイヤ 3 DSCP マーキングに関連しています。
Microsoft Windows 7 と Windows 8 では異なる手法が採用されています。オペレーティング システムによる QoS マーキングでは、Microsoft のセキュリティ強化が原因で、ユーザ アカウント制御(UAC)により、通常のアプリケーションが IP パケットの DSCP マーキングを設定できません。これはセキュリティ上の問題と見なされます。QoS/DSCP マーキングの許可に推奨されるオプションでは、グループ ポリシー オブジェクト(GPO)と呼ばれる Microsoft グループ ポリシーを使用して、特定のアプリケーションがプロトコル数およびポート範囲に基づいてトラフィックをマーキングできるようにします。このマニュアルですでに説明したように、Cisco Jabber で作成された識別可能なトラフィック ストリームを GPO とともに使用すると、Windows オペレーティング システムが特定のアプリケーション(CiscoJabber.exe など)で送信されたトラフィックをマーキングするように指示できます。すべての GPO と同様に、QoS GPO を設定できるのは管理者のみであるため、GPO によって許可されたアプリケーションのみが、オペレーティング システムを経由して QoS をマーキングできます。
ほとんどの企業のネットワーク管理者は、PC など、データ VLAN のデバイスの QoS マーキングを信頼しません。通常、データ VLAN のトラフィックはすべて、アクセス レイヤの入力で DSCP が 0(ベスト エフォート)に再マーキングされ、次に、UCP ポート範囲またはプロトコルなどの他の基準に基づいた DSCP に再マーキングされます。非常に厳格な OS ポリシーおよびネットワーク アクセス ポリシーを持つ一部の企業は、完全に制御できるオペレーティング システムのマーキングを信頼することがあります。この場合、Windows 7 または 8 のオペレーティング システムが Cisco Jabber クライアントなどの特定のアプリケーションの QoS トラフィックをマーキングできるようにすることで、QoS GPO に利点があります。
Cisco Jabber for Windows を導入する企業で、QoS 信頼のこのレベルを提供する場合、この方法を選択することもできます。
GPO は、オペレーティング システムが、プロトコル、ポート、およびアプリケーションの実行可能ファイルに基づいて、特定のアプリケーションの QoS をマーキングできるようにするネットワーク アクセス リストに非常に類似しています。図 13-23 では、Jabber for Windows を使用した Windows 7 および 8 での QoS 再マーキングのプロセスについて説明します。
図 13-23 で説明しているプロセスは、IP アドレス範囲(または任意のアドレス)、プロトコル(UDP)、およびポート範囲(オーディオは 3000 ~ 3999、ビデオは 4000 ~ 4999)を定義する QoS グループ ポリシーから始まります。一度設定して OS に適用したら、Jabber for Windows クライアントは登録時に Unified CM からその設定をダウンロードし、SIP プロファイル メディア ポート範囲として共通を適用します。そこから、Jabber for Windows クライアントがコールを行う場合、Unified CM から提供されるメディア ポート範囲します。ただし、Windows OS に適用された GPO はそのポリシーを適用し、UDP ポート 3000 ~ 3999 からオーディオのメディア トラフィックを取得して EF に再マーキングし、UDP ポート 4000 ~ 4999 から取得して AF41 に再マーキングします。トラフィックが OS に残らないため、パケットには適用したマーキングが含まれます。これらのマーキングを信頼し、ネットワーク経由で送れるかはネットワーク次第です。図 13-23 では、メディア ポート範囲について SIP プロファイルで非連続ポート範囲として分割ポートを使用する場合の類似した GPO も示します。
Cisco Jabber for Mac は、オペレーティング システムに対して DSCP QoS マーキングをネイティブに要求し、特定のポリシーを設定せずにトラフィックをマーキングします。
Cisco Jabber for iPad および Cisco Jabber for iPhone は、オペレーティング システムに対して DSCP QoS マーキングをネイティブに要求し、特定のポリシーを設定せずにトラフィックをマーキングします。
Cisco Jabber for Android は、オペレーティング システムに対して DSCP QoS マーキングをネイティブに要求し、特定のポリシーを設定せずにトラフィックをマーキングします。
レイヤ 3 DSCP の値にレイヤ 4 ポート範囲の識別可能なメディアおよびシグナリング ストリームをマッピングすると、Cisco Jabber クライアントに QoS を導入できます。Jabber クライアントでネットワーク アクセス コントロール リスト(ACL)またはオペレーティング システムを使用して、PC、Mac、または携帯型デバイスの QoS マーキングを信頼してネットワーク経由で送信すると、識別可能なメディアおよびシグナリング ストリームをマッピングできます。ネットワークの ACL 方式は OS の信頼方式を上書きするだけで、すべてのオーディオの再マーキングを強制し、信頼方式の使用目標を放棄するため、両方の方式を組み合わせることはお勧めしません。
QoS に関するシスコの推奨事項は、ビデオについて過去数年間で少し変化しています。従来のビデオは、デスクトップ ビデオとイマーシブ TelePresence ビデオの 2 種類に分類されています。識別と分類セクションで説明されているように、Unified CM はこれらのエンドポイントのビデオ エンドポイント タイプとビデオ ストリームを区別できます。このため、ネットワーク管理者は、これら 2 種類のエンドポイントのビデオを別々に処理できます。従来、推奨 DSCP マーキングは、デスクトップ ビデオには AF41、TelePresence ビデオ(イマーシブ ビデオ)には CS4 が割り当てられています。これらの値は RFC 4594 に準拠しています。図 13-24 では、WAN での分類およびスケジューリングの一般的な手法について説明します。この識別と分類の手法は長年にわたり導入されていますが、これら 2 つのクラスのトラフィックが、Cisco IOS のクラスベースの重み付け均等化キューなど、レートベースのキューを分離するために適用される場合には欠点があります。
(注) このセクションでは、WAN の Quality of Service(QoS)セクションで詳細に説明している、Cisco IOS の異なるキューイングとスケジューリング技術について解説します。ここでは技術を十分に理解していることを前提として、これらの技術のいくつかについて説明し、その内容は Cisco IOS のさまざまなキューイングとスケジューリングのメカニズムを使用する際のベスト プラクティスおよび推奨事項に焦点を当てます。
WAN 内のトラフィックのスケジューリングとキューイングに関するこの手法では、音声コールのオーディオは EF とマーキングされ、PQ がこのトラフィックに割り当てる帯域幅に関する厳格なポリサーを使用して、プライオリティ キュー(PQ)に配置されます。ビデオ コールは、デスクトップ タイプ ビデオ用の AF41 クラスと、TelePresence ビデオ(イマーシブ)用の CS4 クラスの 2 つのクラスに分けられます。これらのクラスはそれぞれ個別のクラスベースの重み付け均等化キューに分けれます。
ビデオ コールのオーディオ部分に関連する、この手法のその他の考慮事項は次のとおりです。
– ビデオ コールのオーディオとビデオ ストリームに同一の DSCP
デフォルトでは、ビデオ コールのオーディオとビデオの両方とも同じ DSCP 値がマーキングされます。その結果、オーディオとビデオ ストリームの両方が、ビデオ キューの輻輳で均等に影響を受けます。ビデオのパケット損失が発生すると、パケット損失が発生しなくなるまで、ビデオ エンドポイントがレート調整を許容レベルまで下げるときに、ビデオ品質が少し低下する場合があります。オーディオは一定のビット レート メディアであり、ビデオと同じレート調整機能はありません。そのためオーディオの場合、この低下は、ビデオ キューのパケット損失がなくなるまで、ユーザが通信できなくなることを意味します。オーディオへの影響は、ビデオへの影響よりもユーザ エクスペリエンスに大きな影響があります。ビデオが影響を受けている場合、ビデオのパケット損失が発生しても、ユーザは会議や会話を継続することができます。両方のメディアの特性に関する詳細については、音声とビデオを参照してください。
– これまで、ビデオ コールのオーディオおよびビデオ ストリームでは、2 つのストリーム間で大きな遅延差が生じないようにするため、同じ DSCP 値がマーキングされていました。そうしないと、ビデオ エンドポイントはオーディオとビデオを適切に同期できませんでした。すべてのシスコ エンドポイントに RTCP を実装することで、RTCP がビデオ コールのオーディオとビデオ間の同期化を適切に実行するため、心配する必要がなくなりました。当然ですが、これにはビデオ エンドポイントで RTCP を有効にする必要があります。
– メディア ストリームの識別は、信頼されていないエンドポイントおよびクライアントには困難です。前述のように、エンドポイントまたはクライアントが信頼されていない場合は、別の方法で識別する必要があります。アクセス リストなどの別の方法では、多くの場合、ビデオ コールのオーディオから音声専用コールのオーディオを区別し、2 種類のオーディオを別々に分類することは困難です。そのため、両方の種類のコールのオーディオすべてを単一の DSCP 値でマーキングする必要があります。これにより、包括的な手法を作成できますが、マーキングがさらに難しくなります。
統合したコラボレーション メディアおよびデータ ネットワーク全体での複数の種類のビデオの管理では、廃棄率の異なる複数の DSCP を持つ単一レートベースのキューを使用することを新たにお勧めします。WAN のビデオ トラフィックをスケジューリングするこの新しい手法では、単一のビデオ キューを、AF41、AF42、および AF43 を使用して 2 または 3 の AF4 廃棄率に設定します。この場合、AF43 の廃棄優先度または廃棄率は AF42 よりも高く、AF42 の廃棄優先度または廃棄率は AF41 よりも高くなります。階層型廃棄優先のこのサービス クラスを持つ単一のビデオ キューの前提は、あるクラスのビデオがキュー内の帯域幅を使用していない場合、キューの残りの帯域幅を他の DSCP で使用できるというものです。これにより、2 つの異なるレートベースのキューの CS4 TelePresence ビデオおよび AF41 デスクトップ ビデオを使用した以前のキューイング手法の最適ではない帯域幅使用率の主な欠点の 1 つが解決されます。
最適化されたビデオ帯域幅使用率に関する多くの異なる戦略は、階層型 DSCP 廃棄率を使用するこの単一ビデオ キューに基づいて設計することができます。単一クラスベースの重み付け均等化キュー(CBWFQ)で AF41 と AF42 の 2 つの DSCP 値を持つ、TelePresence ビデオとデスクトップ ビデオの 2 種類の同じビデオを使用すると、この新しい QoS キューイング手法の例を簡単に説明できます。図 13-25 に、このアプローチを示します。
図 13-25 では、音声コールのオーディオは EF とマーキングされ、PQ がこのトラフィックに割り当てる帯域幅に関する厳格なポリサーを使用して、プライオリティ キュー(PQ)に配置されます。ビデオ コールは、TelePresence ビデオの AF41 とデスクトップ ビデオの AF42 の 2 つのクラスに分けられます。重み付けランダム早期検出(WRED)で CBWFQ を使用すると、管理者は、AF41 に対して AF42 の廃棄優先度を調整できるため、キューがいっぱいになって輻輳が発生したとき、AF42 パケットが AF41 よりも高い確率でキューから廃棄されます。WRED の機能の詳細については、WAN の Quality of Service(QoS)を参照してください。
この例では、すべてのビデオに対して DSCP ベースの WRED と単一 CBWFQ を使用する管理者が、輻輳時のパケット損失から、別の種類のビデオ(デスクトップ)よりも、ある種類のビデオ(TelePresence ビデオ)を保護する方法について説明します。この「単一」ビデオ キュー手法では、デュアル ビデオ キュー手法とは異なり、ある種類のビデオがキューの帯域幅を使用していない場合、他の種類のビデオが、必要に応じてキューの帯域幅全体の完全なアクセス権を得られます。これは、パーベイシブ ビデオの導入を考える際の重要なポイントです。
上記の単一ビデオ キューの例では、あるクラスと別のクラスの CBFWQ が同じである場合、あるクラスのビデオの未使用帯域幅を、別のクラスのビデオがすべて使用できる方法についてのポイントを簡単に説明しています。これにより、デュアル ビデオ キュー手法の欠点の 1 つが解決されます。ただし、これにより、ビデオ コールのオーディオ部分の他の考慮事項が解決されるわけではありません。前述のとおり、2 つの主な欠点があります。
これらの問題を解決する戦略とは、すべてのオーディオがソリューション全体で完全優先転送(EF)の単一の値でマーキングされるようにすることです。この方法では、オーディオ ストリームが音声専用コールまたはビデオ コールに関連付けられるかどうかに関係なく、常に同じ単一の値にマーキングされます。この方法では、ビデオ コールのオーディオの優先順位はビデオよりも上位になるため、ビデオ キューでパケット損失の対象にはなりません。また、Jabber クライアントなどの信頼されていないデバイスでの識別問題も解決します。クライアントのマーキングはネットワーク アクセス レイヤで信頼されないため、ネットワークで音声専用コールのオーディオ ストリームとビデオ コールのオーディオを区別する効果的な方法はありません。そのため、すべてのオーディオが同じ単一の値でマーキングされるこの新しいモデルに移行すると、ネットワークの優先順位付けおよびトラフィックの処理が簡単になります。
(注) 信頼されているエンドポイントが DSCP を取得する方法、ビデオのオーディオ部分または TelePresence エンドポイントに DSCP を設定する方法、この差別化をサポートするエンドポイントに関する詳細については、信頼されているエンドポイントを参照してください。また、信頼されていないエンドポイントとクライアントでは、Jabber クライアントに DSCP を設定する方法についても説明します。
ソリューション全体でこれを総合的に実現するのは、すべてのオーディオを EF の DSCP にマーキングするのに必要ないくつかの条件次第です。
– [True]:Cisco Unified CM は、ビデオ コールのオーディオとビデオの帯域幅割り当てを個別のプールに分けます。ビデオ コールのオーディオ部分の帯域幅割り当てはオーディオ プールから差し引かれ、ビデオ コールのビデオ部分はビデオ プールから差し引かれます。
– [False]:Cisco Unified CM は従来の動作を適用します。ビデオ コールのオーディオとビデオの帯域幅割り当てをビデオ プールから差し引きます。これがデフォルトの設定です。
ビデオのすべてのオーディオを EF にマーキングする際のアドミッション制御機能の詳細については、音声プールからのすべてのオーディオの差し引きの ELCAC セクションを参照してください。
組織全体でビデオを広範囲に導入しようとする場合、帯域幅の一般的な制約により、利用可能な帯域幅および最繁時のビデオ コールの数に基づいて、一日の最繁時に実現できるビデオ解像度のレベルが決定されます。この問題を解決するために、コラボレーション メディアの識別および分類に関する戦略を考慮しながら DSCP ベースの WRED を持つ単一のビデオ キューを使用して、ビデオの種類を状況対応型ビデオに限定します。
状況対応型ビデオとは、任意の時点で利用可能な WAN 帯域幅リソースに応じて、最適な品質を実現したビデオを示します。これを実現するには、いくつかの要件を満たす必要があります。
帯域幅をプロビジョニングし、適切なビット レートがさまざまなエンドポイント グループ間でネゴシエートされるようにすることは、帯域幅管理の重要な側面です。Unified CM 環境では、ビット レートは Unified CM 経由でネゴシエートされます。リージョンの概念を使用し、特定のコール フローの最大オーディオ ビット レートおよび最大ビデオ ビット レートを設定します。ここでは、ビデオおよび TelePresence の最大ビット レートに注目します。
Unified CM のロケーション(Enhanced Locations Call Admission Controlを参照)は、 リージョン とともに、コール フローの特性を定義します。リージョンは、2 つのデバイス間で使用される圧縮とビット レートの種類(8 kbps または G.729、64 kbps または G.722/G.711 など)を定義します。ロケーション リンクは、デバイス間のパスで利用可能な帯域幅の容量を定義します。システム内の各デバイスおよびトランクを(デバイス プールを使用して)リージョンに割り当て、(デバイス プールまたはデバイス自体に直接設定した値を使用して)ロケーションに割り当てます。
デバイス グループの最大ビデオ ビット レート(ビデオ解像度)を管理するリージョン マトリックスを作成すると、特定のデバイス グループがネットワーク帯域幅を過剰に使用しないようにすることができます。リージョン マトリックスを作成するためのガイドラインは次のとおりです。
リージョン設定の詳細については、Enhanced Locations Call Admission Controlを参照してください。
表 13-9 では、4 つのデバイス グループについて最大ビデオ ビット レートのリージョン マトリックスの例を示します。
(注) 表 13-9 は、デバイスのグループ化方法と、デバイス グループ間の通常の解像度に適した最大ビット レートのほんの一例です。
|
|
|
|
|
---|---|---|---|---|
|
||||
|
||||
|
||||
|
表 13-9 の 4 つのグループは次のとおりです。
– オーディオ コーデック設定は共有されるため、複数のビデオ コールで異なるオーディオ コーデックを使用する必要がある場合は、新しいリージョンを設定する必要があります。たとえば、音声専用デバイスが WAN 上の G.729 オーディオ コーデックを、LAN 上の G.711 または LAN G.722 を使用する場合、ビデオ デバイスは G7.11 または G.722 を常に使用しますが、音声専用エンドポイントおよびビデオ エンドポイントはリージョンを共有できません。そのため、各サイトはデバイス グループごとにリージョンが必要になります。サイト数 = N で、ビテオ リージョン グループ数 = 4 + 音声専用リージョン グループのため、N*4 が必要なリージョン数になります。設定サポート用に Prime Collaboration のプロビジョニング ツールまたは一括管理ツールを使用します。
– リージョン内とリージョン間の両方のコールと音声専用コールに対して単一のオーディオ コーデックを使用する場合、サイトごとのリージョンは不要の可能性があります。オーディオとビデオの両方のエンドポイントで、音声専用コールまたはビデオ コールに WAN と LAN を経由した G.711 または G.722 を使用する場合、音声専用 IP Phone およびビデオ エンドポイントは同じリージョンを使用します。
– [リージョン内のデフォルトの最大ビデオ コール ビット レート(オーディオ含む)(Default Intraregion Max Video Call Bit Rate (Includes Audio))]:768 に設定します。リージョン内のコールに対してデバイスの最大ビデオ ビット レート機能を 768 kbps に設定します。
– [リージョン間のデフォルトの最大ビデオ コール ビット レート(オーディオ含む)(Default Interregion Max Video Call Bit Rate (Includes Audio))]:768 に設定します。リージョン間のコールに対してデバイスの最大ビデオ ビット レート機能を 768 kbps に設定します。
– [リージョン内のデフォルトの最大イマーシブ ビデオ コール ビット レート(オーディオ含む)(Default Intraregion Max Immersive Video Call Bit Rate (Includes Audio))]:12000 に設定します。リージョン内のコールに対してデバイスの最大ビデオ ビット レート機能を 12,000 kbps に設定します。
– [リージョン間のデフォルトの最大イマーシブ ビデオ コール ビット レート(オーディオ含む)(Default Interregion Max Video Call Bit Rate (Includes Audio))]:12000 に設定します。リージョン間のコールに対してデバイスの最大ビデオ ビット レート機能を 12,000 kbps に設定します。
– デフォルト設定以外に、各ビデオ エンドポイント グループに対して 1 つずつ、4 つのリージョンを設定する必要があります。
コール アドミッション制御機能は、特に複数のサイトが IP WAN 経由で接続され、オーディオ コールとビデオ コールで使用可能な帯域幅リソースが制限されている場合、コラボレーション システムの重要なコンポーネントとなります。コール アドミッション制御の機能と必要性をわかりやすく説明するために、図 13-26 の例について考えます。
図 13-26 の左側で示すように、従来の TDM ベースの PBX は、回線交換ネットワークの一部として動作します。このネットワークでは、回線はコールがセットアップされるたびに確立されます。このため、レガシー PBX が PSTN または他の PBX に接続されている場合は、一定数の物理トランクを設定する必要があります。PSTN または他の PBX 宛てのコールをセットアップする必要があるとき、PBX は、使用可能なトランクの中からトランクを選択します。使用可能なトランクがない場合、コールは PBX によって拒否され、発信者にはネットワーク ビジー信号が聞こえます。
次に、図 13-26 の右側に示している IP 接続 Unified Communications システムについて考えます。このシステムは、パケット交換ネットワーク(IP ネットワーク)を基盤としているため、IP テレフォニー コールをセットアップするために回線を確立する必要はありません。サンプリング音声を含んでいる IP パケットが、他のタイプのデータ パケットとともに、IP ネットワーク経由でルーティングされるだけです。音声パケットは、Quality of Service(QoS)を使用してデータ パケットと区別されますが、帯域幅リソースは、特に IP WAN リンクでは無限ではありません。このため、ネットワークの管理者が、一定量の「優先」帯域幅を各 IP WAN リンク上の音声トラフィック専用として割り当ててください。ただし、設定した帯域幅がすべて使用される状態になった場合は、IP テレフォニー システムで以後のコールを拒否して、IP WAN リンク上のプライオリティ キューのオーバーサブスクリプションを防止する必要があります。オーバーサブスクリプションが発生すると、すべての音声コールで品質が低下します。この機能はコール アドミッション制御と呼ばれ、IP WAN を利用したマルチサイト配置で良好な音声品質とビデオ品質を保証するために不可欠なものです。
エンド ユーザ エクスペリエンスの満足度を維持するには、コール アドミッション制御機能を常にコール セットアップ段階で実行する必要があります。このようにすることで、ネットワーク リソースを使用できない場合に、エンド ユーザにメッセージを表示したり、異なるネットワーク(PSTN などの)を通じてコールを再ルーティングしたりすることができるようになります。
ここでは、Enhanced Location Call Admission Control と呼ばれる Cisco Unified Communications Manager で使用可能なコール アドミッション制御のメカニズムについて説明します。Cisco IOS ゲートキーパー、RSVP、および RSVP SIP プレコンディションの詳細については、次の Web サイトから入手可能な『 Cisco Unified Communications System 9.0 SRND 』の「 Call Admission Control 」の章を参照してください。
https://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/cac.html
ここでは、IP WAN トポロジに基づいて Enhanced Location Call Admission Control を適用する例を示します。
ここでは、Cisco Unified CM に基づいて Enhanced Location Call Admission Control の設計と設定のガイドラインを提供します。
Cisco Unified CM では、Enhanced Location Call Admission Control(ELCAC)を提供し、複数のクラスタが同じ物理サイトのデバイスを同じ WAN アップリンクを使用して管理している、複雑な WAN トポロジと、Unified CM の分散型配置でのコール アドミッション制御をサポートします。Enhanced Location CAC 機能はイマーシブ ビデオもサポートし、管理者は TelePresence などのイマーシブ ビデオ コールに対してコール アドミッションを他のビデオ コールと別に制御することができます。
より複雑な WAN トポロジをサポートするために、Unified CM はロケーション ベースのネットワーク モデリング機能を実装しています。これは、発信側と着信側の間のマルチ ホップ WAN 接続をサポートする機能を Unified CM に提供します。このネットワーク モデリング機能は、段階的にマルチ クラスタの分散型 Unified CM 配置をサポートするように強化されました。これは、クラスタ全体で同じロケーションに割り当てられた帯域幅を予約、解放、および調整するためにクラスが相互に通信できるようにすることによって、管理者が効果的にクラスタ間の場所を「共有」することが可能になります。また、管理者は イマーシブ ビデオ帯域幅 と呼ばれる [ロケーション(Location)] 設定に新しいフィールドを割り当てることによって、TelePresence などのイマーシブ ビデオ コールの帯域幅を個別にプロビジョニングできます。
ツールを使用して、Enhanced Location CAC を管理し、トラブルシューティングすることができます。CAC の拡張機能と設計は、この章で詳しく説明していますが、トラブルシューティング、およびサービスアビリティ ツールは個別の製品マニュアルで説明します。
Enhanced Location CAC はモデル ベースのスタティック CAC メカニズムです。Enhanced Location CAC では、「ルーテッド WAN ネットワーク」をモデリングするロケーションとリンクを設定するのに、Unified CM で管理インターフェイスを使用する必要があります。このモデルは、WAN ネットワーク トポロジがエンドツーエンドの音声、ビデオ、およびイマーシブ コールに対するエンドポイント グループ間のメディアをどのようにルーティングするのかを表します。ネットワークをモデル化するために Unified CM は設定インターフェイスおよびサービスアビリティ インターフェイスを提供しますが、まだ再ルーティングしているネットワーク障害とネットワーク プロトコルを考慮しない「静的」CAC メカニズムです。したがって、モデルは、WAN ネットワーク トポロジが変更されたらアップデートする必要があります。Enhanced Location CAC もコール指向であり、帯域幅の差し引きはストリームごとではなくコールごとであるため、片方向のストリームのビットレートが反対方向のビットレートよりも高いようなメディア フローの場合、必ず高い方のビットレートに対して差し引かれます。また、単方向メディア フロー アラウンドは双方向メディア フローであるかのように差し引かれます。
管理者がロケーションとリンクを使用してネットワーク モデルを構築できるように、Enhanced Locations CAC は次の設定コンポーネントを組み込みます。
Unified CM は、ロケーションの概念を使用して物理的なサイトを表し、エンドポイント、ボイス メッセージ ポート、トランク、ゲートウェイなどのメディア デバイスとの関連付けを作成します。これは、デバイス自体に直接設定した値、デバイス プール、またはデバイス モビリティを通じて行われます。Unified CM は、 links と呼ばれる新しいロケーション設定パラメータも使用します。リンクはロケーションを相互接続し、ロケーション間で利用可能な帯域幅を定義するために使用されます。リンクは論理的に WAN リンクを表します。ここでは、ロケーションおよびリンクおよびその使用方法について説明します。
ロケーション設定自体は、リンク、ロケーション間の帯域幅パラメータ、および RSVP ロケーションの設定の 3 つの主要部分で構成されます。Enhanced Location CAC に対する RSVP ロケーションの設定は、RSVP 実装にのみ適用されるため、ここでは考慮されません。設定では、ロケーション間の帯域幅パラメータが Show によって [詳細を表示(Show advanced)] リンクの選択で非表示または表示される間、リンク帯域幅パラメータが最初に表示されます。
ロケーション間の帯域幅パラメータは、管理者が音声、ビデオ、およびイマーシブの 3 つのコール タイプの帯域幅割り当てを設定することができます。これらは、トラフィックの量を、指定されたロケーション内およびロケーションとの間で制限します。どのデバイスでもコールを発信または受信すると、帯域幅がそのコール タイプに適用可能な帯域割り当てから差し引かれます。この機能により管理者は、LAN または中継ロケーションで使用される帯域幅の量を制限することができます。ギガビット LAN で構成される現在ほとんどのネットワークでは、これらの LAN 帯域幅を制限する原因がほとんどないか、まったくありません。
リンク帯域幅パラメータは、管理者が「隣接ロケーション」(つまり、その間で設定されたリンクがあるロケーション)間の音声、ビデオ、およびイマーシブ コール用にプロビジョニングされた帯域幅を特徴付けることができます。この機能により管理者にマルチ ホップ WAN ネットワークをモデル化するロケーションの組み合わせのストリングを作成する機能を提供します。これに図解するために、図 13-27 に示すように 4 つの物理的なサイトを接続する単純な 3 ホップ WAN トポロジを検討します。このトポロジでは、San Jose と Boulder 間、Boulder と Richardson 間、および Richardson と RTP 間のリンクを作成します。たとえば、San Jose から Boulder へのリンクの作成時、逆のリンク(Boulder から San Jose)も存在することに注意してください。したがって、管理者はいずれかのロケーション設定のページから一度だけペア リンクを作成する必要があります。図 13-27 の例では、3 つの各リンクは同じ設定で、重みが 50、音声帯域幅が 240 kbps、ビデオ帯域幅が 500 kbps、イマーシブ帯域幅が 5000 kbps(または 5 Mbps)です。
コールが San Jose と RTP の間で確立されると、Unified CM は、2 つのデバイス間のリージョン ペアによって決定される要求されたコールの帯域幅を計算し(ロケーション、リンクとリージョンの設定を参照)、2 地点間の有効なパスを確認します。つまり、Unified CM は 2 地点間のパスを構成するリンクと場所を確認し、各リンクと(該当する場合)パスの各場所からそれに応じて帯域幅を差し引きます。ロケーション内の帯域幅も、ロケーションのいずれかが無制限以外の帯域幅値を設定した場合はパスに沿って差し引かれます。
2 地点間で複数のパスが使用可能である場合に、重みがリンクだけで設定可能で、特定のパスの選択を強制する機能を提供します。複数のパスが設定されている場合、累積重みに基づいて 1 つだけが選択され、このパスが 有効なパス と呼ばれます。この重みはスタティックであり、有効なパスを動的に変更されません。図 13-28 は San Jose、Boulder および Seattle の 3 地点間のリンクで設定された重みを示しています。
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 はロケーション内のすべてのコール、および中継ロケーション(計算パス内にあるが、パス内の発信または着信ロケーションではないロケーション)としてロケーションを使用するすべてのコールをトラッキングします。
ビデオ コールでは、ビデオ ロケーションの帯域幅は、ビデオ コールの音声およびビデオ部分の両方を考慮に入れます。したがって、ビデオ コールの場合、帯域幅が音声帯域幅プールから差し引かれることは一切ありません。同じことがイマーシブ ビデオ コールにも適用されます。
ロケーションでメンバーシップを指定できるデバイスには、次のものがあります。
Enhanced Location Call Admission Control メカニズムでは、通話中のコール タイプ変更も考慮されます。たとえば、サイト間でビデオ コールを確立する場合、Unified CM は、パスのそれぞれのロケーションおよびリンクから適切なビデオ帯域幅を差し引きます。このビデオ コールが、ビデオ非対応のデバイスへの転送の結果、音声のみのコールに変更された場合、Unified CM はビデオ プールに割り当てられた帯域幅を返却し、同じパスに沿って音声プールから適切な帯域幅を割り当てます。音声からビデオに変更されるコールについては、これとは逆の帯域幅割り当て変更が発生します。
表 13-10 に、さまざまなコールのタイプ(ビット レート)において静的ロケーション アルゴリズムが要求する帯域幅を示します。音声コールでは、Unified CM はメディア ビット レートに IP および UDP オーバーヘッドを加えてカウントします。たとえば、G.711 音声コールは、ロケーションとリンクのオーディオ帯域幅割り当てから差し引かれた 80 kbps(64k ビット レート + 16k IP/UDP ヘッダー)を消費します。ビデオ コールでは、Unified CM は、音声ストリームとビデオ ストリームの両方に対して、メディア ビット レートだけを計算します。たとえば、384 kbps のビット レートのビデオ コールに対して、Unified CM はビデオ帯域幅割り当てから 384 kbps を割り当てます。
|
|
---|---|
コーデックおよびロケーションとリンクの帯域幅値のリストについては、次の Web サイトで入手可能な『 Cisco Unified Communications Manager System Guide 』の「 Call Admission Control 」の項の帯域幅計算情報を参照してください。
https://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 は、ロケーションおよびあるロケーションから他のロケーションへのリンクの有効なパスから適切な帯域幅を差し引きます。例として図 13-27 を使用すると、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 機能の詳細については、自動代替ルーティングを参照してください。
(注) AAR は、有効なパスに沿ってネットワーク帯域幅が不足しているために、Enhanced Location Call Admission Control によってコールが拒否される場合のみ、呼び出されます。IP WAN が使用不可の場合や、接続に関するその他の問題によって着信側デバイスが Unified CM に登録されない状態になった場合には、AAR は呼び出されません。このような場合、コールは着信側デバイスの [Call Forward No Answer] フィールドで指定されている宛先に転送されます。
デバイス間のビデオ コールが CAC に失敗した場合にビデオ デバイスを [ビデオコールをオーディオとして再試行(Retry Video Call as Audio)] にイネーブルにできることも注意すべき点です。このオプションは、Unified CM のビデオ エンドポイントの設定ページで設定され、コールを受信するビデオ エンドポイントまたはトランクに適用できます。一部のビデオ エンドポイントは、デフォルトでは [ビデオコールをオーディオとして再試行(Retry Video Call as Audio)] がイネーブルにされ、エンドポイントで設定できないことにも注意する必要があります。
ロケーションは、リージョンとともに機能してロケーションおよびリンクに有効なパス上でコールの特性を定義します。リージョンはデバイス間で使用される圧縮のタイプまたはビット レート(8 kbps または G.729、64 kbps または G.722/G.711 など)を定義し、ロケーション リンクはデバイス間の有効なパスで使用可能な帯域幅の量を定義します。システム内の各デバイスを(デバイス プールを使用して)リージョンに割り当て、(デバイス プールまたはデバイス自体に直接設定した値を使用して)ロケーションに割り当てます。
Unified CM では、ロケーションを設定することにより、次の要素を定義できます。
– 音声帯域幅:ロケーション デバイスから設定された隣接した場所に行われる音声および FAX コールの WAN リンクで使用可能な帯域幅の量。Unified CM は、Enhanced Location Call Admission Control にこの帯域幅値を使用します。
– ビデオ帯域幅:ロケーション デバイスから設定された隣接した場所に行われたビデオ コール用の WAN リンクで使用可能なビデオ帯域幅の量。Unified CM は、Enhanced Location Call Admission Control にこの帯域幅値を使用します。
– イマーシブ ビデオ帯域幅:ロケーション デバイスから設定された隣接した場所に行われた TelePresence コールの WAN リンクで使用可能なイマーシブ帯域幅の量。Unified CM は、Enhanced Location Call Admission Control にこの帯域幅値を使用します。
– 音声帯域幅:ロケーション内のデバイスから行われる音声および FAX コールの LAN で使用可能な帯域幅の量。Unified CM は、Enhanced Location Call Admission Control にこの帯域幅値を使用します。
– ビデオ帯域幅:ロケーション内のデバイスから行われるビデオ コールの LAN で使用可能なビデオ帯域幅の量。Unified CM は、Enhanced Location Call Admission Control にこの帯域幅値を使用します。
– イマーシブ ビデオ帯域幅:ロケーション内のデバイスから行われる TelePresence コールの LAN で使用可能なイマーシブ帯域幅の量。Unified CM は、Enhanced Location Call Admission Control にこの帯域幅値を使用します。
Cisco Unified Communications Manager は、クラスタごとに 2,000 のロケーションと 2,000 のリージョンをサポートします。最大 2,000 のロケーションおよびリージョンを配置するには、[クラスタ全体のパラメータ(Clusterwide Parameters)] >([システム(System)] > [ロケーションとリージョン(Location and Region)])および [クラスタ全体のパラメータ(Clusterwide Parameters)] >([システム(System)] > [RSVP])の設定メニューで次のサービス パラメータを設定する必要があります。
リージョンを追加するときは、ビデオ コールの最大オーディオ ビット レートと最大セッション ビット レートの値として [システム デフォルトの使用(Use System Default)] を選択してください。
個別のリージョンに応じてデフォルト値からこれらの値を変更すると、サーバ初期化とパブリッシャー アップグレードの時間に影響を与えます。合計 2,000 のリージョンと 2,000 のロケーションを使用する場合、最大 200 リージョンでデフォルト以外の値を使用するように変更できます。合計 1,000 以下のリージョンおよびロケーションを使用する場合、最大 500 リージョンでデフォルト以外の値を使用するように変更できます。 表 13-11 は、これらの制限を要約したものです。
|
|
|
---|---|---|
(注) [最大オーディオビットレート(Max Audio Bit Rate)] は、音声コールと FAX コールの両方に使用されます。リージョン間コーデックとして G.729 を使用する場合、FAX コールには T.38 FAX リレーを使用してください。WAN で FAX パススルーを使用する場合、オーディオ プリファレンス リストを使用して、音声のみのコールには G.729、FAX コールには G.711 を使用します。
Location Bandwidth Manager(LBM)は、サービスアビリティ Web ページから管理し、Enhanced Location CAC 帯域幅の機能すべてを担当する Unified CM 機能サービスです。LBM は、Unified CM サブスクライバ ノードまたはクラスタの専用の Unified CM ノードのスタンドアロン サービスとして実行できます。クラスタで Enhanced Location CAC を有効にするには、LBM の 1 つ以上のインスタンスが各クラスタで実行される必要があります。ただし、Cisco CallManager サービスも実行しているクラスタ内の各サブスクライバ ノードで LBM を実行することを推奨します。
LBM サービスは、従来のロケーション CAC のみをサポートする以前のリリースから Cisco Unified CM をアップグレードすると、デフォルトで有効です。新規インストールの場合、LBM サービスは手動でアクティブにする必要があります。
初期化中に LBM は、ロケーションの音声、ビデオ、およびイマーシブ帯域幅値などのデータベース、ロケーション内の帯域幅データ、ロケーションごとのリンク音声、ならびにイマーシブ帯域幅の値と重みからローカル ロケーション情報を読み取ります。リンク データを使用して、クラスタ内の各 LBM は、あるロケーションから他のすべてのロケーションまでのパスのローカル アセンブリを作成します。これは、 アセンブルされたトポロジ と呼ばれます。クラスタでは、各 LBM は同じデータにアクセスし、初期化中にアセンブルされるトポロジと同じローカル コピーを作成します。
実行時、LBM は、ロケーションとリンクのローカルで組み立てられたトポロジの計算されたパスの予約を適用し、クラスタ内の他の LBM に予約を複製します。クラスタ間の Enhanced Location CAC が設定され、アクティブになると、LBM は他のクラスタにアセンブルされたトポロジを複製するように設定できます(詳細についてはクラスタ間の Enhanced Location CACを参照してください)。
デフォルトでは、Cisco CallManager サービスはローカル LBM サービスと通信しますが、この通信を管理するために LBM グループを使用できます。LBM グループは Unified CM の呼制御の冗長性を作成するために、アクティブなスタンバイ LBM を提供します。図 13-29 は LBM の冗長性を示します。
図 13-29 Location Bandwidth Manager の冗長性
図 13-29 は 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 にフェールオーバーします。この例を使用して、LBM グループ設定の仕組みを説明します。これは推奨設定ではありません(以下の推奨事項を参照)。
LBM は、動作している CallManager サービスによって処理されるコールすべての要求の処理に直接関係しているため、LBM の最適な機能を確保するために次のシンプルな設計推奨事項に従うことが重要です。
推奨設定は、Cisco CallManager サービス(呼処理)で LBM 共存を実行することです。LBM サービスの冗長性が必要な場合、特定の LBM をオーバーサブスクライブしないことが重要です。また、LBM が特定の導入でプライマリおよびセカンダリにすぎないようにすることも重要です。つまり、障害シナリオでは複数の CallManager サービスの負荷を LBM にかけないようにし、通常の動作時にかける負荷は 1 つの CallManager サービスのみにします。LBM グループを使用すると、共存 LBM をプライマリとして、別のローカル(同一 LAN 上の)LBM をセカンダリとして、最後にサービス パラメータをフェールセーフ メカニズムとして設定し、この CallManager サービスによって処理されたすべてのコールが失敗しないようにすることができます。これらの推奨事項にはさまざまな理由があります。LBM は、動作している CallManager サービスの呼処理負荷に直接関係しているため、LBM の負荷を特定するのは困難です。遅延には考慮事項もあります。LBM が CallManager サービスからオフボックスになるとすぐに、CallManager サービスで処理されるコールすべてのパケット化と処理によって遅延が発生します。呼処理遅延を組み合わせると、呼び出し状態に対して特定のコール フローの許容不可能なレベルに総遅延量が増えるため、ユーザ エクスペリエンスが低下する可能性があります。これらの設計推奨事項を順守すると、総呼処理遅延が削減されます。
(注) LBM で複数の Cisco CallManager サービスをバックアップすることをお勧めします。LBM が共存 CallManager サービスの負荷を処理し、別の CallManager サービスが失敗したと仮定すると、これは単一の LBM 上にある 2 つの呼処理サーバの負荷に相当します。
Unified CM には、管理者がビデオと TelePresence コールのオーディオ帯域幅を音声プールから差し引く機能が追加されました。ELCAC は音声とビデオ CAC プールが表示するキューを確実に保護するために適切な DSCP 設定を使用するため、Unified CM がビデオ プールから帯域幅を差し引く方法を変更するには、ビデオ コールのオーディオ ストリームの DSCP をオーディオ専用コールのオーディオ ストリームと同じようにマーキングする必要があります。アドミッション制御と QoS の整合に関する詳細については、ビデオ コールのオーディオに関する考慮事項を参照してください。
Unified CM でこの機能をイネーブルにするには、CallManager サービスのコール アドミッション制御セクションで、サービス パラメータ [ビデオ コールのオーディオ プールからオーディオ帯域幅を差し引く(Deduct Audio Bandwidth from Audio Pool for Video Call)] を [True] に設定します。デフォルト設定は [False] であり、デフォルトでは、Unified CM はビデオ プールからビデオ コールのオーディオとビデオの両方のストリームを差し引きます。
クラスタ間の Enhanced Location CAC は、複数のクラスタにわたるネットワーク モデリングの概念を拡張します。クラスタ間の Enhanced Location CAC では、各クラスタは、ロケーションとリンク上でローカルに設定されたトポロジを管理し、LBM クラスタ間のレプリケーション ネットワーク内にある他のリモート クラスタにこのローカル トポロジを伝播します。リモート クラスタのトポロジを受け取ると、LBM は独自のローカル トポロジにこれを再構成し、グローバル トポロジを作成します。このプロセスによって、グローバル トポロジはすべてのクラスタ間で同じになり、エンドツーエンド CAC に対する企業ネットワーク トポロジの全体的視野を各クラスタに提供します。図 13-30 は、単純なハブアンドスポーク ネットワーク トポロジを持つグローバル トポロジの概念を例として示します。
図 13-30 単純なハブアンドスポーク ネットワークのグローバル トポロジの例
図 13-30 はクラスタ 1 とクラスタ 2 の 2 つのクラスタを示し、それぞれにローカルに設定されたハブアンドスポーク ネットワーク トポロジがあります。クラスタ 2 は Loc_21、Loc_22 および Loc_23 へのリンクで Hub_None を設定し、クラスタ 1 は Loc_11 および Loc_12 へのリンクで Hub_None を設定しました。クラスタ間の Enhanced Location 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 クラスタ間のレプリケーション グループ による設定で指定されます。クラスタ内の任意の LBM ロールの割り当てを、クラスタ間のレプリケーション グループ設定のハブまたはスポークのロールに変更することもできます(LBM ハブ グループ設定の詳細については、 https://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html で入手可能な Cisco Unified Communications Manager の製品マニュアルを参照してください)。
LBM クラスタ間のレプリケーション グループでは、ブートストラップ LBM の概念もあります。ブートストラップ LBM は、他のすべての LBM ハブに、フル メッシュのハブ レプリケーション ネットワークを作成するために必要な接続の詳細を提供する LBM ハブです。ブートストラップ LBM は、すべての LBM ハブが持つことができるロールです。すべての LBM ハブが 1 つの LBM ハブを指す場合、その 1 つの LBM ハブが他のすべての LBM ハブに相互に接続する方法を伝えます。各レプリケーション グループは、最大 3 つのブートストラップ LBM を参照できます。
LBM のハブ グループが各クラスタに設定されると、指定 LBM ハブはフル メッシュのクラスタ間のレプリケーション ネットワークを作成します。図 13-31 は、クラスタ間のレプリケーション ネットワークを形成するために 3 つのクラスタ(リーフ クラスタ 1、リーフ クラスタ 2 および Session Management Edition(SME)クラスタ)の間に設定された LBM のハブ グループによるクラスタ間のレプリケーションのネットワーク構成を示します。SME クラスタは例としてのみ使用され、この特定の設定には必要ありません。SME クラスタは、エンドポイント登録を処理する別の通常のクラスタである可能性があります。
図 13-31 3 つのクラスタのクラスタ間レプリケーション ネットワークの例
図 13-31 では、各クラスタから 2 つの LBM がクラスタの LBM のハブとして指定されます。これらの LBM ハブは、クラスタ間の LBM レプリケーション ネットワークを形成します。各 LBM クラスタ間のレプリケーション グループに設定されたブートストラップ LBM は、SME_1 および SME_2 と見なされます。SME クラスタからのこれら 2 つの LBM ハブは、クラスタ間 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 ハブ
– LBM クラスタ間のレプリケーション グループごとに最大 3 つのブートストラップ LBM ハブを表示できます
– クラスタ間 LBM のレプリケーション ネットワークの一部として他のリモート ハブと直接通信します
– クラスタのローカル LBM のハブと直接通信し、ローカル LBM のハブを介してリモート LBM のハブと間接的に通信します
– LBM は各クラスタから送信元および受信者を選択して、LBM メッセージを最適化します。
– クラスタの LBM の送信者と受信者は、最も小さい IP アドレスによって決まります。
– リモート クラスタからメッセージを受信する 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 アップリンクを使用するいくつかのクラスタを使用することがあるため、同じロケーションは、各クラスタのローカル デバイスにそのロケーションを関連付けるために各クラスタに設定する必要があります。独自のトポロジを管理するクラスタがある場合もありますが、これらのトポロジは、特定のロケーションにおいて相互接続されるため、これらのロケーションを各クラスタ間の共通ロケーションとして設定する必要が生じます。そうすることで、グローバル トポロジが作成されている際に、クラスタでは、各クラスタで共通の相互接続ロケーションとリンクを持ち、各リモート トポロジをともに効果的にリンクさせることができるようになります。図 13-32 はトポロジをリンクすることを示し、各クラスタが共有する共通トポロジを示します。
図 13-32 グローバル トポロジを作成する共通のロケーションとリンクの使用
図 13-32 では、クラスタ 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 へのリンクの設定が必要です。また、図 13-33 で示されているように、Regional 1 および Regional 2 を DC の代わりに、すべてのクラスタで設定された共通ロケーションにすることができます。
図 13-33 異なる共通ロケーションを使用する代替トポロジ
クラスタからクラスタへのトポロジ マッピングのキーは、トポロジを相応に相互接続するように少なくとも 1 つのクラスタに別のクラスタの共通ロケーションがあることを確認します。
シャドウ ロケーション は、Enhanced Location CAC がクラスタ間で機能するために必要な、ロケーションの名前、ビデオ トラフィック クラス(後述)などの、Enhanced Location CAC 情報を他のものに渡すように SIP トランクをイネーブルにするために使用されます。クラスタ全体でこのロケーション情報を渡すためには、SIP クラスタ間トランク(ICT)は「シャドウ」ロケーションに割り当てる必要があります。シャドウ ロケーションは他の場所へのリンクを持つことができないため、帯域幅はシャドウ ロケーションと別のロケーションの間で予約できません。Hub_None に関連付けられたように、シャドウ ロケーションに割り当てられた SIP ICT 以外のいずれかのデバイスが処理されます。SIP ICT 以外のデバイスがシャドウ ロケーションに行きついたら、帯域幅の差し引きは Hub_None 内にあるようにそのデバイスから行われ、ロケーションおよびリンク設定に応じてさまざまな影響を受けるため、これを理解することは重要です。
SIP ICT は Enhanced Location CAC で有効になっている場合、SIP Call-Info ヘッダーによって情報を渡します。これにより、発信側と着信側のクラスタは、ロケーションの帯域幅の差し引きをエンドツーエンドで処理できるようになります。図 13-34 は、渡された情報に関する 2 クラスタと一部の詳細の間のコールの例を示します。これは、ロケーション情報をクラスタからクラスタに渡す方法、また帯域幅の差し引きを行う方法を単に示します。
図 13-34 SIP を介してクラスタ間で渡されるロケーション情報
図 13-34 では、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 Location CAC がイネーブルになり、LBM のレプリケーション ネットワークが設定されている場合、すべてのクラスタがネットワーク ビューを複製します。指定したロケーションおよびリンク管理のクラスタには、ロケーション、リンクおよび帯域幅の値を持つグローバル トポロジ全体があります。これらの値は、複製されると最も制限的になるため、すべてのクラスタで使用されます。この設計によって、多数の共通のロケーションが複数のクラスタ間で必要な配置の設定オーバーヘッドが軽減されます。
– 1 つのクラスタをクラスタ管理(ロケーションとリンクを管理するために選択したクラスタ)として選択する必要があります。
企業内のすべてのロケーションは、このクラスタに設定されます。
すべてのロケーションとリンクの帯域幅値と重みは、このクラスタで管理されます。
– 企業内の他のすべてのクラスタは、デバイスへの関連付けに必要なロケーション のみ を設定する必要があります。ロケーション間のリンクを設定しては なりません 。このリンク情報は、クラスタ間の Enhanced Location CAC が有効な場合に管理クラスタから取得されます。
– クラスタ間の Enhanced Location CAC が有効な場合、すべてのロケーションとリンクは管理クラスタから複製され、LBM は最小で、最も限定的な帯域幅と重み値を使用します。
図 13-35 は、3 つのリーフ クラスタのロケーションおよびリンクの管理クラスタとして Cisco Unified Communications Manager Session Management Edition(SME)について説明します。
(注) 前述のように、クラスタはロケーションとリンクの管理クラスタとして機能できます。この例では、SME はロケーションとリンクの管理クラスタです。
図 13-35 ロケーションおよびリンクの管理クラスタとしての SME の例
図 13-35 では 3 つのリーフ クラスタがあり、それぞれは、リージョン ロケーションおよびリモート ロケーションだけにデバイスがあります。SME にはロケーションおよびリンクで設定されているグローバル トポロジ全体があり、クラスタ間 LBM の複製は 4 つのすべてのクラスタの間でイネーブルです。SME がロケーションとリンク トポロジの全体を設定するため、すべてのロケーションが共通のロケーションですが、この例ではロケーションを共有するクラスタはありません。SME ではグローバル トポロジ全体が設定されていますが、リーフ 1、リーフ 2 とリーフ 3 は、デバイスやエンドポイントに関連付ける必要があるロケーションだけを設定することに注意してください。クラスタ間レプリケーション後に、すべてのクラスタはグローバル トポロジを持つようになります。
– LBM のハブのレプリケーション ネットワークの全ハブのハブ連絡先情報を複製する 3 つのリモート ハブのメンバーを定義するために使用されます
– LBM は、LBM のハブのグループに割り当てられる場合のハブです。
TelePresence エンドポイントがデスクトップから会議室といった広範囲に多様なコラボレーション エクスペリエンスを提供できるようにするため、Enhanced Location CAC には、TelePresence イマーシブ ビデオ コールに CAC を提供するサポートが含まれています。ここでは、TelePresence イマーシブ ビデオ CAC をサポートする Enhanced Location CAC の機能について説明します。
[ビデオコールトラフィッククラス(Video Call Traffic Class)] は、すべてのエンドポイントに割り当てられた属性で、エンドポイントまたはトランクのビデオ分類タイプを確認するために SIP トランクでイネーブルにもできます。これは、Unified CM が、さまざまなコール フローをイマーシブまたは、デスクトップ ビデオ、またはその両方として分類し、ビデオ帯域幅またはイマーシブ帯域幅、またはその両方の適切なロケーションやリンク帯域幅の割り当てから、それに応じて差し引くことを可能にします。TelePresence エンドポイントには、エンドポイントに割り当てられた イマーシブ の設定不可能な [ビデオコールトラフィッククラス(Video Call Traffic Class)] があります。SIP トランクは、SIP トランク コールの帯域幅予約を差し引きするためにデスクトップ、イマーシブ、または混合ビデオとして分類できます。他のエンドポイントおよびトランクにはすべて、 デスクトップ ビデオ の設定不可能な [ビデオコールトラフィッククラス(Video Call Traffic Class)] があります。エンドポイントおよびトランクの分類の詳細は、次の項で説明します。
TelePresence イマーシブ エンドポイントは CS4 の DSCP 値のメディアをデフォルトで表示し、デスクトップ ビデオ エンドポイントは推奨される QoS 設定によって AF41 のメディアをデフォルトで表示します。Cisco エンドポイントの場合、これは、設定可能な Unified CM QoS サービス パラメータの [ビデオ コールの DSCP(DSCP for Audio Calls)] および [TelePresence コールの DSCP(DSCP for TelePresence Calls)] によって実現されます。Cisco TelePresence エンドポイントは、Unified CM に登録されている場合、設定ファイルをダウンロードし、[TelePresence コールの DSCP(DSCP for TelePresence Calls)] の設定に QoS 設定を適用します。Unified Communications ビデオ対応エンドポイントは、Unified CM に登録されている場合、設定ファイルをダウンロードし、[ビデオ コールの DSCP(DSCP for Audio Calls)] の設定に QoS 設定を適用します。すべてのサードパーティ製ビデオ エンドポイントは、エンドポイントの手動設定自体を必要とし、静的に設定され、コール タイプによって QoS マーキングを変更しないことを意味します。したがって、正しい DSCP に Enhanced Location CAC の帯域割り当てを一致させることが重要です。Unified CM は、 デスクトップ の [ビデオコールトラフィッククラス(Video Call Traffic Class)] を持つデバイスのビデオ帯域幅のロケーションとリンクの割り当てからデスクトップ ビデオ コールを差し引くことによって、これを実現します。エンドツーエンド TelePresence イマーシブ ビデオ コールは、 イマーシブ の [ビデオコールトラフィッククラス(Video Call Traffic Class)] を持つデバイスまたはトランクのイマーシブ ビデオ帯域幅のロケーションとリンクの割り当てから差し引かれます。これによって、エンドツーエンド デスクトップ ビデオとイマーシブ ビデオ コールが正しくマーキングされ、コール アドミッション制御に正しくカウントできます。デスクトップ デバイスと TelePresence イマーシブ デバイス間のコールでは、帯域幅はビデオ帯域幅とイマーシブ ビデオ帯域幅の両方のロケーションとリンクの割り当てから差し引かれます。
Cisco TelePresence エンドポイントには イマーシブ の固定された設定不可能な [ビデオコールトラフィッククラス(Video Call Traffic Class)] があり、Unified CM でイマーシブとして識別されます。テレプレゼンス エンドポイントはデバイス タイプによって Unified CM に定義されます。デバイスを Unified CM に追加する場合、一般的なシングル スクリーンおよびマルチスクリーンのルーム システムがあるため、デバイス タイプの名前が TelePresence のデバイスは イマーシブ に分類されます。Unified CM のエンドポイントの機能を確認する別の方法として、Cisco Unified Reporting Tool に移動し、[システムレポート(System Reports)] > [Unified CM 電話機能リスト(Unified CM Phone Feature List)] を選択します。機能ドロップダウン リストで [TelePresence デバイスのイマーシブビデオサポート(Immersive Video Support for TelePresence Devices)] を、製品ドロップダウン リストで [すべて(All)] を選択します。ここには、 イマーシブ に分類されているデバイス タイプがすべて表示されます。他のすべてのエンドポイントは、設定不可能なイマーシブ属性が不足しているため、[ビデオコールトラフィッククラス(Video Call Traffic Class)] が デスクトップ に固定されています。
帯域予約はビデオ コールのエンドポイントの分類によって決定され、 表 13-12 に示されるようにロケーションおよびリンクの帯域幅プールから帯域幅を差し引きます。
|
|
|
---|---|---|
SIP トランクは、SIP トランク コールの帯域幅予約を差し引きするためにデスクトップ、イマーシブ、または混合ビデオとして分類できます。分類は発信側デバイス タイプと SIP トランクの Video Call Traffic Class によって決定されます。SIP トランクは、SIP プロファイルのトランク固有の情報によって次のように設定できます。
SIP トランクはこれらの 3 つの分類のいずれかに分類でき、ビデオまたは TelePresence マルチポイント コントロール ユニット(MCU)、固定ロケーションのビデオ デバイス、従来のロケーション CAC をサポートする Unified CM クラスタ、または Cisco TelePresence System Video Communications Server(VCS)を分類する場合に主に使用されます。
帯域予約はエンドポイントの分類およびビデオ コールの SIP トランクの分類によって決定され、 表 13-13 に示されるようにロケーションおよびリンクの帯域幅プールから帯域幅を差し引きます。
|
|
|
---|---|---|
デフォルトでは、イマーシブ エンドポイントまたはデスクトップ エンドポイントからのすべてのビデオ コールは、ロケーションおよびリンクのビデオ帯域幅プールから差し引かれます。この動作を変更するには、Unified CM の CallManager サービス パラメータの [イマーシブ ビデオ コールにビデオ帯域幅プールを使用(Use Video BandwidthPool for Immersive Video Calls)] を [False] に設定すると、イマーシブ ビデオ帯域幅の差し引きがイネーブルになります。これを有効にすると、イマーシブとデスクトップのビデオ コールが、それぞれのプールから差し引かれます。
前述したように、Unified Communications ビデオ エンドポイント(デスクトップ Video Call Traffic Class)と TelePresence エンドポイント(イマーシブ Video Call Traffic Class)の間のビデオ コールは、メディアを非対称にマーキングし、イマーシブ ビデオ CAC がイネーブルな場合、ビデオとイマーシブのロケーションおよびリンクの帯域幅プールから帯域幅を差し引きます。図 13-36 は、これについて説明しています。
図 13-36 マルチ サイト配置の Enhanced Location CAC 帯域幅の差し引きおよびメディア マーキング
次のコール フローは、Unified CM サービス パラメータの [イマーシブ ビデオ コールにビデオ帯域幅プールを使用(Use Video BandwidthPool for Immersive Video Calls)] が [False] に設定される場合の、ロケーションおよびリンクの帯域幅の差し引きの予想される動作を示します。
図 13-37 は、ロケーション L1 の TP-A とロケーション L2 TP-B 間のエンドツーエンド TelePresence のイマーシブ ビデオ コールについて説明します。エンドツーエンド イマーシブ ビデオ エンドポイントのコールは、有効なパスに沿ったロケーションおよびリンクのイマーシブ帯域幅プールから帯域幅を差し引きます。
図 13-37 エンドツーエンド TelePresence イマーシブ ビデオのコール フロー
図 13-38 は、ロケーション L1 の DP-A とロケーション L2 DP-B 間のエンドツーエンド デスクトップ ビデオ コールについて説明します。エンドツーエンド デスクトップ ビデオ エンドポイントのコールは、有効なパスに沿ったロケーションおよびリンクのビデオ帯域幅プールから帯域幅を差し引きます。
図 13-38 エンドツーエンド デスクトップ ビデオのコール フロー
図 13-39 は、ロケーション L1 のデスクトップ ビデオ エンドポイント DP-A とロケーション L2 の TelePresence ビデオ エンドポイント TP-B 間のビデオ コールについて説明します。デスクトップ ビデオ エンドポイントと TelePresence ビデオ エンドポイント間の相互運用性コールは、有効なパスに沿ってビデオとイマーシブのロケーションおよびリンクの帯域幅プールから帯域幅を差し引きます。
図 13-39 デスクトップから TelePresence ビデオへのコール フロー
図 13-40 では、1 つのデスクトップ ビデオ エンドポイントと 2 つの TelePresence エンドポイントが、TelePresence MCU を指定する イマーシブの Video Traffic Class で設定した SIP トランクをコールします。エンドツーエンド イマーシブであるコールのイマーシブのロケーションおよびリンクの帯域幅プールから、およびデスクトップからイマーシブへのコールのビデオとイマーシブのロケーションおよびリンクの帯域幅プールから有効なパスに沿って帯域幅が差し引かれます。
図 13-40 MCU を使用したビデオ会議のコール フロー
図 13-41 は、有効なパスに沿ったロケーションおよびリンクのイマーシブ帯域幅プールから帯域幅を差し引く、クラスタ全体でエンドツーエンド イマーシブ ビデオ コールを説明します。
図 13-41 クラスタ間のエンドツーエンド TelePresence ビデオのコール フロー
図 13-42 は、有効なパスに沿ったロケーションおよびリンクのビデオ帯域幅プールから帯域幅を差し引きする、クラスタ間のエンドツーエンド デスクトップ ビデオ コールについて説明します。
図 13-42 クラスタ間のエンドツーエンド デスクトップ ビデオ コールのコール フロー
図 13-43 は、クラスタ全体で TelePresence エンドポイントをコールするデスクトップ ビデオ エンドポイントを示します。このコールは、有効なパスに沿ってロケーションおよびリンクのビデオとイマーシブ帯域幅の両方のプールから帯域幅を差し引きます。
図 13-43 クラスタ間のデスクトップから TelePresence ビデオへのコール フロー
Unified CM で音声またはビデオ コールをネゴシエートすると、複数の異なるストリームがコールに関係するエンドポイント間で確立されます。コンテンツ共有のあるビデオ コールの場合、これにより、8 つ(またはそれ以上)もの単方向ストリームが生じる可能性があります。音声のみのコールの場合は、通常、最低でも 2 つのストリームが各方向に生成されます。ここでは、ネットワークでの帯域幅使用率と、Unified CM がアドミッション制御帯域幅アカウンティングでこれに対処する方法を説明します。
– オーディオ(音声のみのコール):RTP ビット レートと IP、および UDP ヘッダーのオーバーヘッド
– イマーシブ(Cisco TelePresence エンドポイントによるビデオ コール):RTP ビット レートのみ
– 帯域幅の差し引きは二方向 RTP ストリームに対して行われ、対称的にルーティングされると想定されます(両方のストリームが同じパスを介してルーティングされる)。たとえば、80 kbps の G.711 音声コールは全二重ネットワークを介した各方向で 80 kbps です。つまり、送信ペアのワイヤの 80 kbps と受信ペアのワイヤの 80 kbps で、全二重の 80 kbps と等しくなります(図 13-44 を参照)。WAN では、トラフィックがに常に対称的にルーティングされるわけではありません。WAN を介したネットワークでルーティングする際に、アドミッション制御がメディアを正しく処理するように、必要に応じてネットワーク管理者に確認してください。
– Real-Time Transport Control Protocol(RTCP)帯域幅オーバーヘッドは Unified CM 帯域幅割り当てには含まれません。これは、ネットワーク プロビジョニングに含まれる必要があります。RTCP は、ほとんどのコール フローで非常に一般的であり、ストリームに関する統計情報によく使用されます。また、リップシンクを適切に行えるように、ビデオ コールで音声を同期するためにも使用されます。場合によっては、エンドポイントで有効または無効に設定できます。RFC 3550 では、RTCP 用に追加されるセッション帯域幅の割合を 5 % に固定することが推奨されます。これは、RTCP セッションの場合、関連する RTP セッションの最大 5 % までであることが一般的であることを意味します。したがって、ネットワークで帯域幅使用率を計算する場合は、RTP セッションごとに RTCP のオーバーヘッドを追加する必要があります。たとえば、RTCP が有効な状態で G.711 音声コールが 80 kbps である場合、RTP と RTCP の両方に対してセッションごとに最大 84 Kbps を使用します(RTCP のオーバーヘッドは 4 kbps)。この計算は Enhanced Location CAC の差し引きには含まれませんが、ネットワーク プロビジョニングには含まれる必要があります。
(注) ただし、別の DiffServ コード ポイント(DSCP)にこのトラフィックを再マーキングする方法があります。たとえば、RTCP では奇数の UDP ポートを使用し、RTP は偶数の UDP ポートを使用します。このため、UDP ポート範囲に基づいて分類できます。Network-Based Application Recognition(NBAR)を使用し、RTP ヘッダー [ペイロード タイプ(Payload Type)] フィールドに基づいて分類と再マーキングを行うこともできます。NBAR の詳細については、https://www.cisco.com を参照してください。ただし、エンドポイント マーキングがネットワークで信頼されている場合、RTCP オーバーヘッドは音声 RTP と同じ QoS クラス内のネットワークでプロビジョニングする必要があります(デフォルト マーキングは EF)。また、RTCP は RTP と同じマーキングを使用してエンドポイントでマークされることにも注意してください。デフォルトで、これは EF です(RTCP も EF とマークされます)。
図 13-44 RTCP が有効に設定された基本的な音声のみのコール
図 13-44 には、2 つのデスクトップ ビデオ電話が音声のみのコールに確立されています。このコール フローでは 4 つのストリームはネゴシエートされます。つまり、単一の二方向矢印によって記述される 2 つのオーディオ ストリームと、同様に二方向矢印で示されている 2 つの RTCP ストリームです。このコールについて、Location Bandwidth Manager(LBM)は、デスクトップ電話 DP-A と DP-B の間で確立されたコールのロケーション L1 と ロケーション L2 間から 80 kbps(ビット レート + IP/UDP のオーバーヘッド)を差し引きます。RTCP が有効なネットワークのレイヤ 3 で消費される実際の帯域幅は、このセクションの前半で説明したように、80 kbps ~ 84 kbps の間です。
図 13-45 には、2 つのデスクトップ ビデオ電話がビデオ コールに確立されています。このコール フローでは 8 つのストリームがネゴシエートされます。つまり、2 つのオーディオ ストリーム、2 つの音声関連 RTCP ストリーム、2 つのビデオ ストリーム、および 2 つのビデオ関連 RTCP ストリームです。この図でも、両方向矢印を使用して 2 つの単方向ストリームが表されます。この特定のコールは、64 kbps の G.711 音声、および 960 kbps のビデオを持つ 1024 kbps です(ビデオ コールの音声およびビデオ割り当てのみに対するビット レート)。この場合、LBM はデスクトップ電話 DP-A と DP-B の間で確立されたビデオ コールのロケーション L1 と L2 の間から 1024 kbps を差し引きます。RTCP は、ネットワークによるマーキングまたは再マーキングの方法に応じたプロビジョニングを考慮する必要のあるオーバーヘッドです。
図 13-45 RTCP が有効に設定された基本的なビデオ コール
図 13-46 は、プレゼンテーション共有のあるビデオ コールの例です。これは、ネットワーク上で使用される帯域幅と比較すると、関連付けられたストリーム数と帯域幅の割り当てがより複雑なコールであるため、ネットワークでプロビジョニングする必要があります。図 13-46 は、プレゼンテーション共有に関して Binary Floor Control Protocol(BFCP)を有効にし、RTCP を有効にしているビデオ コールを示しています。Cisco TelePresence System EX、MX、SX、C、および Profile シリーズなど、SIP が有効に設定されているすべてのテレプレゼンス多目的またはパーソナル エンドポイントは同じように機能します。
図 13-46 RTCP および BFCP が有効なビデオ コールとプレゼンテーション共有
2 つのビデオ エンドポイント間でビデオ コールが確立されている場合、音声およびビデオ ストリームが確立され、ネゴシエートされたレートに応じて帯域幅が差し引かれます。Unified CM はリージョンを使用してコールに対する最大ビット レートを決定します。たとえば、最高の詳細度が 1 秒あたり 30 フレーム(fps)で 1080p の Cisco TelePresence System EX90 の場合、リージョン間でネゴシエートされるレートは 6.5 Mbps に設定する必要があります。このシナリオで使用する EX90s は、このセッションに対して約 6.1 Mbps を要します。エンドポイントがセッション中にプレゼンテーション共有を開始すると、BFCP はエンドポイント間でネゴシエートされ、新しいビデオ ストリーム間はエンドポイント設定に応じて 5 fps または 30 fps のいずれかで有効になります。このような場合、エンドポイントはメインのビデオ ストリームをスロットル ダウンして、プレゼンテーション ビデオを組み込み、セッション全体が、割り当てられた 6.5 Mbps の帯域幅を超えてセッション全体が使用しないようにできます。このため、プレゼンテーション共有の有無にかかわらず、平均帯域幅使用量は変わりません。
(注) 通常、プレゼンテーション ビデオ ストリームはプレゼンテーションを表示している 1 人以上のユーザの方向で単方向です。
お互いの間でコールをネゴシエーションする Cisco TelePresence System 500、1000、3000、および TX9000 シリーズなどのテレプレゼンス イマーシブおよびオフィス エンドポイントは、プレゼンテーション共有用のビデオがメインのビデオ セッションに割り当てられたもの以上の追加帯域幅であるため、Enhanced Location CAC から差し引かれないという点で少し異なる動きをします。図 13-47 は、これについて説明しています。
図 13-47 RTCP および BFCP が有効なビデオ コールとプレゼンテーション
図 13-47 では、テレプレゼンス イマーシブ ビデオ エンドポイントがビデオ コールを確立し、プレゼンテーション共有を有効にしています。LBM はメインの音声およびビデオ セッション用に 4 Mbps をコール用のイマーシブ プールから差し引き、ビデオがエンドポイント間に確立されます。プレゼンテーション共有がアクティブ化されると、2 つのエンドポイントが BFCP を交換し、エンドポイントの設定に基づいて一方向で 5 fps または 30 fps でプレゼンテーション ビデオ ストリームをネゴシエーションします。5 fps で、使用される平均帯域幅は追加帯域幅オーバーヘッドの 500 kbps です。この帯域幅は、ビデオ コールに割り当てられた 4 Mbps 以上であり、ネットワークでプロビジョニングされる必要があります。30 fps で、プレゼンテーション ビデオの平均ビット レートは約 1.5 Mbps です。
(注) Cisco TelePresence System エンドポイントは、Telepresence Interoperability Protocol(TIP)を使用して、各方向で 2 つの音声およびビデオ RTP ストリームにマルチスクリーンと音声を多重化します。このため、回線上の実際のストリームは図に示されているものと異なる場合がありますが、プレゼンテーション ビデオ用の追加帯域幅オーバーヘッドの概念は同じです。
従来のロケーション CAC のみをサポートする以前のリリースから Cisco Unified CM にアップグレードすることによって、Location CAC は Enhanced Location CAC に移行します。移行は、音声およびビデオ帯域幅のすべての以前に定義されたロケーションの帯域幅限度の取得と、ユーザ定義のロケーションと Hub_None の間のリンクへの移行で構成されます。これにより、実質的に、Unified CM ロケーション CAC の以前のバージョンがサポートするハブ アンド スポーク モデルが再作成されます。図 13-48 は、帯域幅情報の移行について説明します。
図 13-48 Unified CM アップグレード後の Location CAC から Enhanced Location CAC への移行
Enhanced Location CAC をサポートする Cisco Unified CM リリースへのアップグレード後の設定
挿入をトランスコードするために、ビット レートは接続の各レッグで異なります。図 13-49 は、これについて説明しています。
図 13-49 トランスコードのための異なるビット レートの例
デュアル スタック MTP 挿入の場合、ビット レートは各接続で異なりますが、帯域幅は IP ヘッダーのオーバーヘッドによって異なります。図 13-50 は、デュアル スタック MTP 挿入に IPv4 および IPv6 ネットワークで使用される帯域幅の違いについて説明します。
図 13-50 デュアル スタック MTP 挿入の帯域幅の違い
Enhanced Location CAC は、MTP とトランスコーダ間の帯域幅でこれらの違いを考慮しません。サービス パラメータの [ロケーション メディア リソース オーディオ ビット レート ポリシー(Locations Media Resource Audio Bit Rate Policy)] は最大帯域幅または最小帯域幅がロケーションおよびリンクのパスに沿って使用される必要があるかを決定します。最低ビット レート(デフォルト)または最高ビット レートは、帯域幅の使用量のこれらの違いを管理するために使用できます。
Enhanced Location CAC は、クラスタ間のエクステンション モビリティ(EMCC)を使用した設計をサポートしています。Unified CM は、クラスタ間のエクステンション モビリティ(EMCC)という機能によって、企業内のクラスタ間でエクステンション モビリティ ログインを実行する機能を提供します。詳細については、クラスタ間のエクステンション モビリティ(EMCC)の項を参照してください。
EMCC 設計に Enhanced Location CAC を使用すると、Visiting クラスタが Visiting 電話機のロケーションをホーム クラスタに渡します。これにより、ホーム クラスタは登録時に Visiting 電話機に正しいロケーションを関連付けることができるようになります。EMCC 設計で Enhanced Location CAC を機能させるためには、次の要件を満たす必要があります。
Enhanced Location CAC および EMCC の両方を、製品マニュアルおよびこの SRND のガイドラインに従って設計および導入することができます。必要とする他の要件や特定の設定情報はありません。
この項では、さまざまな IP WAN トポロジに対して、コール アドミッション制御メカニズムを適用する方法について説明します。Unified CM Enhanced Location CAC のネットワーク モデル化のサポートによって、Unified CM は単純なハブ アンド スポークまたは MPLS トポロジのサポートに制限されませんが、現在はクラスタ間の拡張ロケーションとともに、Unified CM 配置モデルのほとんどのネットワーク トポロジをサポートできます。Enhanced Location CAC は依然としてネットワークを参照しない静的に定義されたメカニズムであるため、ネットワークの変更がアドミッション制御に影響するたびに、管理者は適宜 Unified CM をプロビジョニングする必要があります。これは、ネットワーク障害が発生し、メディア ストリームがネットワークの異なるパスを取る場合などに RSVP などのネットワーク対応のメカニズムが、その間隔を埋めてネットワークの動的変化をサポートできる場合です。これは、ロード バランシングされた二重またはマルチホーム WAN アップリンク、あるいは不等サイズのプライマリおよびバックアップ WAN アップリンクがある設計の場合がよくあります。
Enhanced Location CAC がどのように機能するか、および Enhanced Location CAC の設計および配置方法について確認するには、Unified CM Enhanced Location Call Admission Controlの項を参照します。
ここでは、いくつかの一般的なトポロジを調べ、それらのトポロジを管理するために Enhanced Location CAC を設計する方法について説明します。
図 13-51 は、各リモート サイトに単一の WAN アップリンクがある単純なデュアル データセンター WAN ネットワーク設計について説明します。データセンターは、データ トラフィック用に余裕を持ってプロビジョニングされた高速 WAN 接続を介して相互接続します。
図 13-51 デュアル データセンター WAN ネットワーク
通常、リモート サイトからデータセンターへのこれらの WAN アップリンクは、ロードバランシングされているかプライマリ/バックアップ設定にあり、これらのシナリオを処理するスタティック CAC メカニズム用の制限方法があります。Enhanced Location CAC のこのマルチパス トポロジを設定できますが、重みのメトリックが変更されるまで 1 つのパスだけが有効なパスとして計算されてスタティックのままになります。このタイプのネットワーク トポロジをサポートする、よりよい方法は、2 つのデータセンターを Enhanced Location CAC の 1 つのデータセンターまたはハブ ロケーションとして設定し、各リモート サイト ロケーションに対して単一リンクを設定することです。図 13-52 は、Enhanced Location(E-L)CAC のロケーションとリンクのオーバーレイについて説明します。
図 13-52 デュアル データセンターの Enhanced Location CAC のトポロジのモデル
リモート ロケーションへのリモート デュアルまたはより多くのリンクを持つリモートのデュアル データセンターに関する次の設計上の推奨事項は、ロードバランシング WAN 設計、プライマリ/バックアップ WAN 設計の両方に適用されます。
Enhanced Location CAC ネットワークのモデルでマルチ プロトコル ラベル スイッチング(MPLS)の Any-to-Any 接続タイプのクラウドを設計する場合、1 つのロケーションは MPLS クラウドとして動作できます。このロケーションに関連付けられているデバイスはありませんが、このクラウドにアップリンクを持つすべてのサイトには、ロケーションに設定されたリンクがあります。このように、MPLS クラウドは、他のリモート ロケーションに複数の可変サイズの帯域幅 WAN アップリンクを相互接続するための中継ロケーションとして機能します。ここでは、多数の異なる MPLS ネットワークおよびその同等のロケーションとリンクのモデルを示します。
図 13-53 では、Hub_None は、サーバ、エンドポイントおよびデバイスが配置され、エンドポイントとデバイスだけ配置されているリモート ロケーションがあるキャンパス ロケーションを相互接続する中継ロケーションとして動作する MPLS クラウドを表します。リモート ロケーションから Hub_None への各リンクは、音声、ビデオ、およびイマーシブ メディア用に割り当てられた WAN アップリンクの帯域幅に従ってサイジングできます。
図 13-54 は、サーバ、エンドポイントおよびデバイスが配置され、エンドポイントとデバイスだけ配置されているリモート ロケーションがあるキャンパス ロケーションを相互接続する中継ロケーションとして動作する 2 つの MPLS クラウドを示します。キャンパスは、両方のクラウドにも接続されています。リモート ロケーションから MPLS クラウドへの各リンクは、音声、ビデオおよびイマーシブ メディア用に割り当てられた WAN アップリンクの帯域幅に従ってサイジングできます。この設計は、各地理的ロケーションで異なるプロバイダーからの個別の MPLS クラウドを持つ、大陸間にまたがる企業で一般的です。
図 13-55 は、各サイトが各クラウドへの 1 の接続を持ち、等コストのロード バランシングされた方法またはプライマリ/バックアップ シナリオで MPLS クラウドを使用する、異なるプロバイダーから複数の MPLS クラウドを示します。どちらの場合でも、この設計は、1 つのロケーションが両方のクラウドを表して単一リンクが 2 つの最低容量のリンクを表すデュアル データセンター設計と同等です。
図 13-55 デュアル MPLS クラウドに接続されたリモート サイト
ここでは、Enhanced Location CAC、およびビデオの展開を設計する際に Quality of Service(QoS)に適用できる設計上の考慮事項と推奨事項について説明します。
アドミッション制御と QoS は相互に補完し、多くの場合は共存します。オーディオとビデオのエンドポイント、音声とビデオのゲートウェイ、音声メッセージ、会議など、最新のシスコ製品サービスは、IP DiffServ コード ポイント(IP DSCP)に基づいてネイティブ QoS パケット マーキングをすべてサポートします。ただし、Jabber for Windows クライアントは、Windows オペレーティング システムが、アプリケーション、IP アドレス、および UDP/TCP ポート範囲を使用するグループ ポリシー オブジェクト(GPO)を使用して DSCP のトラフィックをマーキングする必要があるため、他のクライアントと同じようにネイティブ マーキング機能に厳密に従うことはありません。グループ ポリシー オブジェクトは、トラフィックをマーキングする機能という点で、ネットワーク アクセス リストと非常に類似した機能です。
QoS を使用しないと、許可されたトラフィックが許可されていないトラフィックまたは他のトラフィックの分類よりも上位を求めるネットワーク リソースを使用できるように、ネットワークがメディアの優先順位を付けられないため、QoS はアドミッション制御に必要不可欠です。Unified CM では、QoS の CallManager サービス パラメータに主な 5 つの QoS 設定があります。これらは、エンドポイント メディア分類に適用可能で、イマーシブおよびデスクトップで分類されたエンドポイント(Telepresence イマーシブ ビデオの Enhanced Location CACの項を参照)が、イマーシブまたはデスクトップのビデオ分類に基づいたメディアに対して異なる QoS マーキングも設定できるようにします。 表 13-14 では、デフォルト設定および Per-Hop Behavior(PHB)相当とともに、主な 5 つの DSCP 設定を示します。
[音声コールの DSCP(DSCP for Audio Calls)] 設定は、オーディオ専用コールを発信するデバイスに使用されます。[ビデオ コールの DSCP(DSCP for Audio Calls)] 設定は、「デスクトップ」に分類されるデバイスのオーディオとビデオのトラフィックに使用されます。[TelePresence コールの DSCP(DSCP for TelePresence Calls)] は、「イマーシブ」に分類されるデバイスのオーディオとビデオのトラフィックに使用されます。[ビデオコールのオーディオ部分の DSCP(DSCP for Audio Portion of Video Calls)] および [TelePresence コールのオーディオ部分の DSCP(DSCP for Audio Portion of TelePresence Calls)] がビデオ エンドポイントのサブセットに現在適用可能で、分類に基づいてビデオ コール タイプを使用するビデオ コールのオーディオ部分のみを区別します。詳細については、信頼されているエンドポイントの項を参照してください。
Telepresence イマーシブ ビデオの Enhanced Location CACの項で説明したように、Cisco Unified CM E-LCAC には、他のビデオ コールと別に TelePresence コールのアドミッション制御を実行する機能があります。E-LCAC は、エンドポイントと SIP トランクを「イマーシブ」または「デスクトップ」に分類することでこの機能を実行します。このように分類すると、イマーシブに分類されたデバイスおよびトランクの個別のイマーシブ帯域幅プールから帯域幅を差し引く機能が Unified CM に付与されます。デフォルトでは、LBM は、分類に関係なくビデオ帯域幅プールからビデオをすべて差し引きます(Unified CM's CallManager サービス パラメータ [イマーシブ ビデオ コールにビデオ帯域幅プールを使用(Use Video BandwidthPool for Immersive Video Calls)] を [True] に設定)。
また、デフォルトでは、イマーシブと分類されたすべてのエンドポイントの DSCP が CS4 に設定されており(DSCP 32:[TelePresence コールの DSCP(DSCP for TelePresence Calls)])、デスクトップ エンドポイントの DSCP は AF41 に設定されています(DSCP 34:[ビデオ コールの DSCP(DSCP for Audio Calls)])。QoS および E-LCAC のデフォルト設定は DSCP を区別しますが、同じ E-LCAC 帯域幅プールからすべてのビデオを差し引きます。図 13-56 では、QoS と E-LCAC 帯域幅プールの関連性、およびイマーシブとデスクトップに分類されたデバイスのデフォルト設定を示します。
図 13-56 CAC 帯域幅プールのデフォルト QoS 設定
[TelePresence コールの DSCP(DSCP for TelePresence Calls)] はイマーシブ分類で、[ビデオ コールの DSCP(DSCP for Audio Calls)] はデスクトップ分類です。
ビデオの Enhanced Location CAC を設計する場合は、この項に示す設計上の推奨事項と考慮事項に従ってください。
次の設計上の推奨事項は、Enhanced Location CAC を使用するビデオ ソリューションに適用されます。
– UC エンドポイントのみを配置し、TelePresence エンドポイントを配置しないサイトの場合、着信 CS4 とマークされたトラフィックに対応し、CS4 とマークされたメディアの QoS 処理を行うために、着信 WAN QoS 設定で CS4 DSCP クラスが AF41 QoS トラフィック クラスに追加されていることを確認します。
– UC TelePresence エンドポイントのみを配置し、UC エンドポイントを配置しないサイトの場合、着信 AF41 とマークされたトラフィックに対応し、AF41 とマークされたメディアの QoS 処理を行うために、着信 WAN QoS 設定で AF41 DSCP クラスが CS4 QoS トラフィック クラスに追加されていることを確認します。
イマーシブ ビデオ コールに Enhanced Location CAC を展開すると、イマーシブに分類されたエンドポイントがデスクトップに分類されたエンドポイントに接続された場合に相互運用可能なコールが、デフォルトで非対称にマーキングされるため、DSCP のマーキングが両方の QoS クラスに与える影響を考慮します。
TelePresence ビデオの相互運用可能なコールの DiffServ コード ポイント(DSCP)QoS マーキングは、非対称です。UC エンドポイントには AF41 が使用され、TelePresence エンドポイントには CS4 が使用されます。AF41 と CS4 は Unified CM でのデフォルト設定であり、これらのデフォルトの変更は、ネットワーク インフラストラクチャの QoS 設定と整合している必要があります(該当する場合)。TelePresence エンドポイントは、ビデオ コールを DSCP 値 CS4 でマークします。これは、デフォルトの [TelePresence コールの DSCP(DSCP for TelePresence Calls)] 設定と整合性が取れています。UC エンドポイントは、コールを DSCP 値 AF41 でマークします。これは、デフォルトの [ビデオ コールの DSCP(DSCP for Audio Calls)] 設定と整合性が取れています。図 13-57 に、メディア マーキングと帯域幅アカウンティングを示します。
図 13-57 Enhanced Location CAC を使用したマルチサイト配置での帯域幅の差し引きとメディア マーキング
TelePresence および UC で相互運用可能なビデオ コールに対する Enhanced Location CAC は、図 13-57 に示されるように、ビデオとイマーシブのロケーションおよびリンクの帯域幅プールから帯域幅を差し引きます。これは、QoS で分類されたストリームの両方のタイプが、エンドポイント間のパスの両方向においてメディアに必要な帯域幅を確保するよう設計されたことによります。
Enhanced Location CAC は、AF41 クラス トラフィックと CS4 クラス トラフィックの両方の双方向メディアに対応します。ただし、非対称にマークされたフローでは、AF41 クラスの十分に割り当てられたビット レートは一方向で使用されますが、他方向で使用されません。一方の方向では、完全な割り当て済みビット レートは CS4 にマーキングされます。これは、追加の帯域幅消費というわけではなく、単に各 QoS クラスのネットワークでのマーキングおよびキューイングの相違です。この方式の帯域幅アカウンティングでは、各方向の各フローを保護する必要があります。
TelePresence ビデオ(CS4)が Unified Communications ビデオ(AF41)とは別個にネットワーク パス上でプロビジョニングされ、TelePresence の大部分がスケジューリングされており、コールのスケジューリングが制御されて TelePresence の使用率が決定論的である環境の場合、ロケーションとリンクのイマーシブ ビデオ帯域幅を [無制限(unlimited)] に設定して、二重帯域幅 CAC が計算されるのを回避できます。これにより、TelePresence 間のコールが常にスムーズに行き来し、アドミッション制御の影響を受けないようにしつつ、デスクトップ ビデオ、および TelePresence とデスクトップ間のビデオ コールがアドミッション制御の影響を受けず、ビデオ帯域幅割り当てで対処されるようになります。
Enhanced Location CAC と TelePresence の相互運用可能なコールのコール フローの詳細については、Telepresence イマーシブ ビデオの Enhanced Location CACを参照してください。
Unified CM Session Management Edition(SME)は通常、複数の Unified CM クラスタ、サードパーティ製 UC システム(IP および TDM ベースの PBX)、PSTN 接続、および集中型 UC アプリケーションを相互接続するために使用され、また、ダイヤル プランおよびトランク集約にも使用されます。次に、Enhanced Location CAC で Unified CM SME を配置する場合に従うべき推奨事項と設計上の考慮事項のリストを示します。Unified CM SME の詳細については、コラボレーションの配置モデルの章を参照してください。
図 13-58 ロケーションおよびリンクの管理クラスタとしての Unified CM SME
図 13-58 は、ロケーションおよびリンクの管理クラスタとしての SME について説明しています。ロケーションおよびリンクのグローバル トポロジ全体は SME で設定および管理され、リーフ クラスタは、エンド デバイスに関連付ける必要があるロケーションだけをローカルに設定します。クラスタ間 Enhanced Location CAC がイネーブルで、ロケーションおよびリンクが複製される場合、各リーフ クラスタは SME からグローバル トポロジを受信します。これを自らの設定済みのトポロジの上にオーバーレイし、コール アドミッション制御にグローバル トポロジを使用します。これは、複数のクラスタ間での設定およびロケーション/リンク管理を簡素化し、クラスタ間の設定ミスの可能性を少なくします。設計および展開の詳細については、ロケーションおよびリンク管理クラスタの項を参照してください。
図 13-59 は、クラスタ間 Enhanced Location CAC が 1 つ以上のリーフ クラスタでイネーブルにされている場合(右)、および 1 つ以上のリーフ クラスタが従来のロケーション CAC のみをサポートする Unified CM のバージョンを実行している場合(左)の SME デザインについて示しています。この種類の展開では、従来型のロケーション CAC で管理されるロケーションを、Enhanced Location CAC で有効なクラスタ間での共通または共有のロケーションとすることはできません。リーフ 1 は、従来型のハブ アンド スポークに設定され、デバイスがさまざまなリモート サイトで管理されています。クラスタ間 Enhanced Location CAC をイネーブルにしている SME および他のリーフ クラスタは、E-L CAC モデル化トポロジで示されるように、グローバル トポロジを共有します。Leaf1_Hub は、リーフ 1 トポロジのハブを表しており、SIP または H.323 クラスタ間トランクに割り当てられた SME のユーザ定義のロケーションです。これにより、リーフ 1 と Leaf1_Hub との間のコールの帯域幅を SME が差し引きできるようになります。このように、リーフ 1 は従来型のロケーション CAC でリモート ロケーションを管理し、一方で SME とリーフ 2 は Enhanced Location CAC のロケーションとリンクを管理します。
図 13-59 Enhanced Location CAC およびリーフ クラスタの従来のロケーション CAC を使用する SME の設計
Cisco Expressway のモバイルとリモート アクセス機能は、VPN を使用しない Unified CM へのインターネット ベースのデバイスの登録を提供します。別名、VPN-less エンタープライズ アクセスとして知られています。これにより、企業ネットワークにアクセスできるようにオペレーティング システム全体がアプリケーションをホストする必要なく、エンドポイントまたはクライアント アプリケーションが Unified CM に安全に登録されるようになります。ここでは、Enhanced Location Call Admission Control(ELCAC)を使用してモバイルおよびリモート アクセスを配置する推奨事項と設計上の考慮事項を示します。モバイルとリモート アクセスの詳細については、VPN-less 企業アクセスの項を参照してください。
Cisco Expressway の VPN-less モバイルとリモート アクセス ソリューションでは、この機能をサポートするエンドポイントは、VPN を使用せずに Cisco Expressway 配置を介して Unified CM に登録できます。Cisco Expressway C および Expressway E サーバは、それぞれがハイ アベイラビリティの冗長性を備えて配置されます。Expressway E はファイアウォールからインターネット(外側)とファイアウォールから企業(内側)間の DMZ に配置されますが、Expressway C は企業内に配置されます。図 13-60 に、この配置を示します。また、次のメディア フローを示しています。
1. お互いをコールするインターネットベースのエンドポイントでは、図 13-60 のエンドポイント B と C の間に示されるように、メディアは Expressway E と Expressway C を経由してルーティングされ、インターネットに戻されます。
2. 内部エンドポイントをコールするインターネットベースのエンドポイントでは、図 13-60 のエンドポイント A と C の間に示されるように、メディアは Expressway E と Expressway C を流れます。
図 13-60 VPN-less アクセス用の Cisco Expressway の配置
同じ企業内で VPN-less アクセス用の Cisco Expressway を複数配置する場合、1 つの Expressway ペアを介して登録されるインターネットベースのエンドポイントが別の Expressway ペアを介して登録されるインターネットベースのエンドポイントをコールすることで、メディアが企業を経由してルーティングされます。これは、図 13-61 のエンドポイント D とエンドポイント C 間のコールに示されます。両方がインターネットから登録されますが、2 つの異なる Expressway ペアを経由します。メディア フローは、エンドポイントが同じ Unified CM クラスタまたは異なる Unified CM クラスタに登録されているかどうかに関係なく同じになります。
図 13-61 複数の Cisco Expressway ペアの配置でのメディア フロー
図 13-62 は、企業を通過するメディア フローの帯域幅のトラッキングを統合しながら、アドミッション制御なしでメディアがインターネット上を流れることを拒否しないロケーションとリンクの設定例を示します。
図 13-62 リモートとモバイル アクセスのロケーションとリンク
図 13-62 に、3 つの主要なサイト(RTP、BLD、および SJC)で構成される ELCAC の展開例を示します。これらのサイトはすべて MPLS プロバイダーに接続されるため、それぞれに MPLS クラウドへの別個の WAN 接続があります。帯域幅リンクがネットワーク トポロジにマッピングする音声コールおよびビデオ コールに限定された状態で、企業ロケーションが MPLS と呼ばれるロケーションに直接リンクされるように、適宜ロケーションとリンクが作成されます。企業内にあるとき、デバイスは 3 つのサイトの 1 つに置かれるため、関連付けられたロケーションを持ちます。これらの各サイトには、Unified CM に登録されるインターネットベースのエンドポイントの VPN-less リモートおよびモバイル アクセス用の Cisco Expressway ソリューションがあります。新しい 3 つのロケーションは、RTP_INET、BLD_INET、および SJC_INET の名前で各 Expressway ソリューション サイトに対して 1 つずつ、インターネットベースのデバイスに設定されます。これらの 3 つのロケーションは、Expressway ペアを介してインターネットから Unified CM に登録されるデバイスのロケーションであることから、「インターネット ロケーション」と表現されます。これらのロケーションは、直接のリンクで相互接続されません。これは、Expressway 間のコールが企業を経由してルーティングされ、MPLS クラウドを介して流されるからです。その代わりに、このようなインターネット ロケーションには、関連付けられた企業ロケーションへのリンクがあります。たとえば、RTP_INET には RTP へのリンク、BLD_INET には BLD へのリンクなどがあります。インターネット ロケーションと企業ロケーション間のこれらのリンクは、[無制限(unlimited)] の帯域幅に設定されている必要があります。
前述のように、Cisco Expressway 配置の Enhanced Location CAC には、デバイス モビリティと呼ばれる Unified CM の機能を使用する必要があります(この機能の詳細については、デバイス モビリティの項を参照してください)。エンドポイントでデバイス モビリティを有効にすると、Unified CM は、デバイスが Cisco Expressway を介して登録されたときや企業内で登録されたときを認識できるようになります。またデバイス モビリティを使用すると、企業とインターネット間をローミングするときに、Unified CM がアドミッション制御をデバイスに提供できるようになります。デバイス モビリティは、エンドポイントが Expressway C の IP アドレスを使用して Unified CM に登録されるときを認識することによりこれを実行し、Unified CM が適切なインターネット ロケーションを関連付けます。ただし、エンドポイントが他の IP アドレスで登録されている場合、Unified CM は、デバイスに直接設定されている(またはデバイスに直接設定されたデバイス プールから)企業ロケーションを使用します。この機能が作用するために企業全体にわたってデバイス モビリティを配置する必要がないことに注意してください。Unified CM のデバイス モビリティ設定は Expressway の IP アドレスでのみ必要となり、この機能を必要とするデバイス(つまり、インターネット経由で登録するデバイス)上だけでこの機能が有効にされます。図 13-63 は、デバイスのモビリティ設定の概要を示します。これは ELCAC がインターネットベースのデバイスで機能するためのデバイス モビリティの最小設定要件ですが、企業内の同一のエンドポイントのモビリティをサポートするために、デバイス モビリティを設定することができます(詳細については、デバイス モビリティの項を参照してください)。
図 13-63 デバイスのモビリティ設定とロケーションの関連付け
図 13-63 は、図 13-62 で説明された ELCAC の展開例に対するデバイス モビリティの簡易バージョンを示します。Expressway C サーバの IP アドレスは、デバイスのモビリティ情報に設定されています。この例では、3 つのサイト(RTP、BLD、および SJC)のそれぞれに Expressway C サーバの冗長ペアがあります。RTP_EXP1_DMI および RTP_EXP2_DMI は、RTP Expressway C サーバのサーバ IP アドレスでそれぞれ設定されています。これらの 2 つは、ロケーション RTP_INET が設定されている RTP_EXP_DP と呼ばれる新しいデバイス プールに関連付けられます。各サイトが同様に設定されます。この設定では、任意のデバイスが RTP_EXP1_DMI または RTP_EXP2_DMI のデバイス モビリティ情報に対応する IP アドレスで Unified CM に登録されるデバイス モビリティで有効にされている場合、RTP_EXP_DP デバイス プール、そして RTP_INET ロケーションに関連付けられます。
上記の設定では、インターネット ベースのデバイスが Expressway を介して Unified CM に登録される場合、Expressway C の IP アドレスを使用して登録されます。次に、Unified CM は、デバイス モビリティ情報に設定された IP アドレスを使用して、デバイス プールとこのデバイス プールに関連するインターネット ロケーションを関連付けます。図 13-64 に、このプロセスを示します。
図 13-64 Expressway IP アドレスに基づいたデバイス プールとロケーションの関連付け
図 13-64 では、クライアントは RTP の Expressway を介して Unified CM に登録します。シグナリングが RTP の Expressway C で変換されるため、デバイスは Expressway C の IP アドレスを使用して登録されます。デバイ スプール RTP_EXP_DP は、この IP アドレスに基づいてデバイスに関連付けられます。RTP_EXP_DP プールは RTP_INET ロケーションで設定されているため、そのロケーションがデバイスに関連付けられます。そのため、デバイスが Expressway に登録されると、デバイス モビリティを介して正しいロケーションの関連付けを取得します。エンドポイントが企業に移動する場合、静的ロケーションの設定に戻ります。また、たとえばエンドポイントが SJC の別の Expressway に移動する場合、デバイス モビリティを介して正しいロケーションの関連付けを取得します。
ここでは設計例を示し、本章で説明したすべての側面について取り上げます。識別と分類、WAN キューイングとスケジューリング、プロビジョニングとリソース管理、帯域幅割り当てのガイドラインについて、各項目の例で詳細に説明します。
企業例 #1 は、広範囲の地域にユーザを持ち、本社にはデータ センター(DC)が設置され、あらゆる規模(約 500 人、50 人、15 人)の支社が複数あり、各支店にはそれぞれ 5 人のユーザがいる大企業です。ネットワーク図を簡略化するため、これらのサイトのカテゴリ(HQ、大、小、事務所)をテンプレートとして使用し、同様のユーザとエンドポイントの密度を持つ各サイトに応じた帯域幅の考慮事項を決定します。図 13-65 では、各サイト タイプについて説明します。この企業は、ビデオのために Jabber を導入し、ユーザが会議でビデオ端末にアクセスできるようにしています。TelePresence ビデオ会議リソースは HQ の DC に配置されています。IP Phone は音声専用通信用です。ビデオ エンドポイントには、Jabber クライアント、コラボレーション デスクトップ エンドポイント(DX シリーズ)、およびルーム エンドポイント(MX、プロファイル、および SX シリーズ)を使用しています。大規模なサイトには、IX シリーズなどのイマーシブ TelePresence ユニットが用意されています。
IT 部門は、企業例 #1 の各サイト タイプに応じた WAN エッジの帯域幅要件の決定を任されています。次に要件を一覧で表示し、QoS の適用方法と、帯域幅、キューイング、アドミッション制御の要件の決定方法について説明します。
Jabber エンドポイントは信頼されておらず、データ VLAN 内に配置されています。アクセス レイヤ スイッチでシグナリングおよびメディアを再マーキングするには、特定の UDP ポート範囲が使用されます。この場合、Unified CM の設定には、共通メディアおよび 3000 ~ 4999 のシグナリング ポート範囲を使用するすべての Jabber クライアント専用の SIP プロファイルを使用します。これにより、すべての Jabber エンドポイントが、3000 ~ 3999 の ソース UDP ポートをオーディオ ストリームとして、4000 ~ 4999 をビデオ ストリームとして使用するように設定されます。5060 のデフォルト SIP ポートは SIP シグナリング(SIP セキュリティ プロファイルで設定)に使用されます。図 13-66 でこれについて説明します。
図 13-66 信頼されていない(Jabber)エンドポイント QoS
管理者は、次の DSCP 値に UDP ポートを再マーキングするデータ VLAN にアクセス スイッチの ACL を作成します。
Jabber エンドポイントの場合、Jabber SIP プロファイルでデフォルトの QoS 値も変更することをお勧めします。何らかの理由で、Jabber クライアントの QoS がワイヤレス ルータまたは他の有線ルータ経由で信頼されている場合は、信頼されている QoS と ACL で 再マーキングされた QoS との間で信頼された値の一貫性が適切に確保されます。そのため、Jabber クライアント用の SIP プロファイルの QoS パラメータは、 表 13-15 に示すように設定する必要があります。
|
|
|
---|---|---|
TelePresence コールのオーディオ部分の DSCP(DSCP for Audio Portion of TelePresence Calls) |
表 13-15 の構成時の設定は、何らかの理由で、トラフィックが信頼されているネットワーク パスを流れているのに、信頼されていないネットワーク パス内の UDP ポート範囲を介して再マーキングされない場合、Jabber クライアントのビデオが AF42 に設定されるようにします。ビデオ コールのオーディオ部分の DSCP は、AF41 のデフォルト設定のままです。これは単に、UDP ポート範囲を使用するネットワーク経由で信頼されているまたは再マーキングされているか、Jabber エンドポイント間で一貫して設定するようにするためです。
信頼されているエンドポイントの場合、Cisco Discovery Protocol(CDP)が使用され、IP Phone およびビデオ エンドポイントの QoS は、アクセス スイッチで設定された条件付き信頼メカニズムを使用して信頼されます。この設定では、Unified CM デフォルト システム設定として、音声専用コールのオーディオに EF、ビデオ コールのオーディオとビデオに AF41、TelePresence のオーディオとビデオに CS4、シグナリングに CS3 を使用します。そのため、TelePresence エンドポイントの QoS がその設定に従って調整されるようにするには、管理者が、SIP プロファイルで信頼されているエンドポイントについて、Unified CM の QoS デフォルト設定を変更する必要があります。
図 13-67 では、アクセス スイッチの条件付き信頼(CDP ベース)およびパケット マーキングを示します。
管理者は、次に分類されるように、IP Phone およびビデオと TelePresence エンドポイントの条件付き QoS 信頼ですべてのアクセス スイッチを設定します。
また、管理者は、 表 13-16 の値を使用する SIP プロファイルで信頼されているエンドポイントに対して、Unified CM の QoS デフォルト設定を変更する必要もあります。
|
|
|
---|---|---|
TelePresence コールのオーディオ部分の DSCP(DSCP for Audio Portion of TelePresence Calls) |
WAN エッジの入力に到着する特定の DSCP 値を持つパケットは、アクセス レイヤで信頼されているか、またはアクセス スイッチで信頼されていない場合は適宜再マーキングされていることが予想されます。入力のフェールセーフ プラクティスとして、アクセス レイヤで再マーキングできなかった信頼されていないトラフィックは、WAN エッジで再マーキングすることが重要です。QoS は LAN で重要ですが、WAN では最も重要です。ルータは入力トラフィックが信頼されていると見なすため、ビジネス要件およびユーザ エクスペリエンスに応じた適切な QoS ポリシーを設定することが重要です。WAN エッジの再マーキングは、ルータへの入力インターフェイスで常に実行されます。キューイングおよびスケジューリングは出力インターフェイスで実行されます。次に、WAN 入力 QoS ポリシーと出力キューイング ポリシーの例を示します。図 13-68 では、設定と再マーキングのプロセスを説明します。
図 13-68 では、ネットワークの信頼されている領域と信頼されていない領域の両方から送られるパケットは、前述の信頼方法または UDP ポート範囲に一致する簡単な ACL を経由し、適切な DSCP マーキングを使用して識別および分類されます。この ACL は、IP アドレスと、マーキング範囲を細かに制限する他のいくつかの属性にも細部にわたって一致する可能性があることに注意してください。
図 13-68 ルータ入力 QoS ポリシー プロセス例:ステップ 1
図 13-68 ~ 図 13-73 では、入力 QoS ポリシーの一致基準および DSCP 再マーキングについて説明します。このプロセスには、図に示された次のステップが含まれます。
1. ステップ 1 で、パケットがルータ入力インターフェイスに到着し、入力サービス ポリシーで設定されます(図 13-69)。
2. ステップ 2 で、policy-map は 4 つのクラスのトラフィックで設定され、次の適切な DSCP を設定します。VOICE = EF、PRIORITIZED-VIDEO = AF41、OPPORTUNISTIC-VIDEO = AF42、SIGNALING-SIP = CS3(図 13-69)。
3. ステップ 3 で、これらの各クラスは match-any 基準で設定されている同じ名前の class-map に一致します(図 13-69)。この [いずれかに一致(match-any)] 基準の場合、プロセスはトップダウン方式で開始され、policy-map ステートメントの各クラスに従って最初に一致した基準が実行されます。
図 13-69 ルータ入力 QoS ポリシー プロセス例:ステップ 1~3
4. ステップ 4 で、class-map ステートメントの最初の行が解析されます。これは Unified CM の識別と分類セクションに設定されている UDP ポートに一致する ACL です。ACL 基準(プロトコルとポート範囲)が一致する場合は、対応する policy-map ステートメントで設定されているとおりにトラフィックがマーキングされます(図 13-70)。図 13-68 のポリシーに従って、Jabber Audio は AF41 とマーキングされ、Jabber Video は AF42 とマーキングされることに注意してください。
図 13-70 ルータ入力 QoS ポリシー プロセス例:ステップ 4
5. ステップ 5 で、最初のステートメントに一致しないトラフィックは class-map 内の次の match ステートメント、 match dscp に移動します(図 13-71)。トラフィックが DSCP と単純に一致する場合、DSCP はすでに一致したものと同じ値に再び設定され、policy map ステートメントで設定されたかのようになります。この場合、ルータは単純に DSCP に一致し、DSCP を同じ値にリセットします。これはサーバおよびアプリケーションから WAN ルータに入ってくる信頼された DSCP の catch-all 設定です。
図 13-71 ルータ入力 QoS ポリシー プロセス例:ステップ 5
(注) これは、モジュラ QoS CLI(MQC)に基づいた QoS 入力マーキング ポリシー例です。MQC をサポートするシスコ ルータで同様のポリシーを実現する方法と、更新されたコマンドについては、特定ルータ設定ガイドを参照してください。
6. ステップ 6 で、トラフィックは 3 つのキュー(VOICE と呼ばれる Priority Queue、VIDEO と呼ばれる CBWFQ、SIGNALING と呼ばれる CBWFQ)が作成された出力サービス ポリシーによってキュー登録およびスケジューリングされた送信インターフェイスに移動します。これについて図 13-72 および図 13-73 に示します。これは、この出力キューイング ポリシーが、アクセス スイッチや WAN ルータ入力インターフェイスへの入力で発生するネットワーク マーキングとして DSCP のみに基づいている点を強調しています。これは、一致基準およびキューを説明するための単なる例であり、WRED 機能は含まれていません。WRED の詳細については、WAN キューイングとスケジューリングの項を参照してください。
図 13-72 ルータ出力キューイング ポリシー プロセス例:ステップ 6
7. ステップ 7 で、トラフィックが class-map 一致ステートメントと一致します(図 13-73)。EF とマーキングされたトラフィックはすべて VOICE PQ に送られ、AF41 と AF42 のトラフィックは VIDEO CBWFQ に、CS3 のトラフィックは SIGNALING CBWFQ に送られます。
図 13-73 ルータ出力キューイング ポリシー プロセス例:ステップ 7
(注) これは、Cisco Common Classification Policy Language(C3PL)に基づいた出力キューイング ポリシー例です。C3PL をサポートするシスコ ルータで同様のポリシーを実現する方法と、更新されたコマンドについては、特定のルータの設定ガイドを参照してください。
ここでは、インターフェイス キューイングについて説明します。図 13-74 では、CBWFQ で使用される音声 PQ、ビデオ CBWFQ、および WRED のしきい値について説明します。
– 信頼されているエンドポイントからのビデオ コールのオーディオとビデオのストリームには AF41
– Jabber クライアントからのすべてのコールのオーディオ ストリームには AF41
– Jabber クライアントからビデオ コールのビデオ ストリームには AF42
図 13-74 キューイングとスケジューリングのコラボレーション メディア
重み付けランダム早期検出(WRED)の最小および最大しきい値は、Video CBWFQ でも設定されます。WRED のしきい値の設定方法を説明するため、インターフェイスはキューの深さが 256 パケットで設定されていると仮定します。次に、上述のガイドラインに従って、AF42 および AF41 の WRED の最小しきい値および最大しきい値が、図 13-75 の説明とおりに設定します。
図 13-75 WRED のしきい値を持つビデオ CBWFQ の例
ここでは、各サイト タイプのキューに対してアドミッション制御およびプロビジョニング帯域幅を指定します。
前述のとおり、このような場合、アドミッション制御をビデオ帯域幅の管理には使用しませんが、その代わり、PQ がオーバーサブスクライブされないようにするために、オーディオ トラフィックの管理には使用します。これは音声専用コールです。
図 13-76 では、さまざまなコール フロー、それに対応するオーディオとビデオ ストリーム、そのダイレクト先のキューについて説明します。
図 13-76 の例では、次の設定を使用します。
– 比率は、デスクトップ ビデオ エンドポイントの帯域幅使用率に適用されます。
– Jabber ビデオ コールは、ビデオ ルーム システムで使用されていない帯域幅を使用できます。
– 輻輳の発生時、Jabber コールのビデオ ストリームでは、WRED が低下するため、ビデオ ビット レートが動的に下がります。
図 13-77 の帯域幅割り当ては、この企業例 #1 だけに基づいたガイドラインです。コラボレーション トラフィックのさまざまな共通クラスで利用可能な帯域幅の割合について説明しています。帯域幅のプロビジョニングは使用率に大きく依存しており、それぞれの展開と、各サイトで割り当てられるユーザ ベースごとに異なることを理解することが重要です。次の例では、帯域幅のプロビジョニングに使用するプロセスを説明します。帯域幅のプロビジョニング後、最適なユーザ エクスペリエンスに必要な最高の帯域幅のプロビジョニングと割り当てを維持するには、帯域幅の監視および再調整が常に必要です。
ここでは、各サイト(中央、大規模支社、小規模支社、営業所)と、各クラスのユーザ数と利用可能な帯域幅に基づいてクラスごとにプロビジョニングされたリンク帯域幅について説明します。これらの値は、レイヤ 3 以上用に計算された帯域幅に基づいていることに注意してください。そのため、リンク タイプ(イーサネット、フレーム リレー、MPLS など)に依存しているレイヤ 2 のオーバーヘッドは含まれていません。レイヤ 2 のオーバーヘッドの詳細については、ネットワーク インフラストラクチャの項を参照してください。
図 13-78 で示すように、中央サイトには次の帯域幅要件があります。
– イマーシブ エンドポイント:2 Mbps ∗ 1 コール = 2 Mbps
– ビデオ エンドポイント:1.2 Mbps ∗ 30 コール ∗ 0.2 = 7.2 Mbps
– TelePresence Servers:1.5 Mbps ∗ 40 コール ∗ 0.5 = 30 Mbps
– 55 Mbps – (2 Mbps + 7.2 Mbps + 30 Mbps) = Jabber メディア用 15.8 Mbps
576p で 18 Jabber ビデオ コール、または 288p で 50
イマーシブ エンドポイントは最繁時に応じて決定されます。あるエンドポイントで WAN 経由のコールがあるとします。会議コールは TelePresence サーバでローカルに終了するため、これはポイントツーポイント コールになります。最頻時の最悪のシナリオを考慮することが重要です。
ビデオ エンドポイントの WAN 使用率は 20 %(∗0.2)に指定されます。1.2 Mbps での有効な総コール数は 30 で、エンドポイントの数に基づいています。ただし、WAN 経由のアクティブ コールの WAN 使用率が 20 % しかないとすると、アクティブ ローカル コールと比較して、WAN 使用レートは 7.2 Mbps 以上になります。
TelePresence Server では、リモート サイトにあるエンドポイントのさまざまな解像度の平均を考慮して、平均ビット レートは 1.5 Mbps に指定されます。その場合、TelePresence Server は、最大 40 コール(ローカルとリモート)をサポートできます。このコールの 50 %(0.5 倍)は、WAN 経由で転送される TelePresence コールの半分に対応し、残りの半分はローカル エンドポイント用です。
さらに、Jabber コールが 15.8 Mbps の場合、576p で 18 コールや 288p で 50 コールなど幅広く対応します。このことから、Jabber ビデオ コールが帯域幅に応じて利用できることがわかります。15.8 Mbps 以上で多くの Jabber ビデオ コールが発生すると、パケット損失が起こり、すべての Jabber クライアントでビット レートが下方調整されます。これは、新しいコールが追加されても損失レートは低く、ユーザ エクスペリエンスに明確な影響を与えない非常に軽微なプロセスなのか、パケットの即時損失が発生した場合に Jabber ビデオに多大な影響を与えるかのどちらかです。新しいビデオ コールが追加されるときの予想パケット損失レートは、この状況対応型ビデオのユーザ エクスペリエンスが中断されるレベルを決定するのに役立ちます。
図 13-79 で示すように、大規模支店サイトには次の帯域幅要件があります。
– ビデオ エンドポイント:1.2 Mbps ∗ 6 コール = 7.2 Mbps
– 18.7 Mbps – 7.2 Mbps = 11.5 Mbps(Jabber メディア用)
576p で 13 Jabber ビデオ コール、または 288p で 36
図 13-80 で示すように、小規模支店サイトには次の帯域幅要件があります。
– ビデオ エンドポイント:1.2 Mbps * 2 コール = 2.4 Mbps
– 4 Mbps – 2.4 Mbps = 1.6 Mbps(Jabber メディア用)
576p で 2 Jabber ビデオ コール、または 288p で 5
営業所ブロードバンド インターネット接続(5 Mbps)帯域幅の計算
図 13-81 で示すように、営業所サイトには次の帯域幅要件があります。
制限付き WAN リンクを使用する大規模支店(ビデオに対応する Enhanced Locations CAC)
低速 WAN リンクを持つ特定の支店サイトでは、ビデオ キューのオーバープロビジョニングは実現不可能です(図 13-82 を参照)。ELCAC は、ビデオ コールがリンク帯域幅をオーバーサブスクライブしないように、ビデオのこれらのロケーション リンクに適用できます。このテンプレートでは、サイト固有のリージョン設定を使用して、ビデオ エンドポイントおよび Jabber クライアントで使用される最大帯域幅を制限する必要があります。また、Jabber ユーザがサイト間でローミングする場合には、デバイス モビリティも必要になることに注意してください。
(注) 音声専用 Jabber コールの帯域幅は「音声」ELCAC から差し引かれますが、(AF41 にマーキングされているため)ビデオ キューに影響します。ビデオ ELCAC 帯域幅とビデオ キュー サイズの差分を調整します。
図 13-82 制限付き WAN リンクを使用する大規模支店(ビデオに対応する Enhanced Locations CAC)
図 13-82 の説明のとおり、制限付き WAN リンク(10 Mbps)の大規模支店サイトには次の帯域幅要件があります。
– 有効な使用方法:576p(768 kbps)で 2 コール + 288p(320 kbps)で 5 コール = 3,136 kbps
– ビデオ コールの Unified CM ロケーション リンク帯域幅:3.2 Mbps(L3 帯域幅)
– L2 オーバーヘッド、バースト性、AF41 とマーキングされた Jabber オーディオ専用コールのために帯域幅を確保する
企業例 #2 は、広範囲の地域にユーザを持ち、本社にはデータ センター(DC)が設置され、あらゆる規模(約 500 人、50 人、15 人)の支社が複数あり、各支店にはそれぞれ 5 人のユーザがいる大企業です。ネットワーク図を簡略化するため、これらのサイトのカテゴリ(HQ、大、小、事務所)をテンプレートとして使用し、同様のユーザとエンドポイントの密度を持つ各サイトに応じた帯域幅の考慮事項を決定します。図 13-83 では、各サイト タイプについて説明します。この企業は、ビデオのために Jabber を導入し、ユーザが会議でビデオ端末にアクセスできるようにしています。TelePresence ビデオ会議リソースは HQ の DC に配置されています。IP Phone は音声専用通信用です。ビデオ エンドポイントには、Jabber クライアント、コラボレーション デスクトップ エンドポイント(DX シリーズ)、およびルーム エンドポイント(MX、プロファイル、および SX シリーズ)を使用しています。大規模なサイトには、IX シリーズなどのイマーシブ TelePresence ユニットが用意されています。
(注) 企業例 #2 のすべてのエンドポイント(信頼済みと非信頼)では、すべてのオーディオ(音声専用コールとビデオ コール)を EF にマーキングし、Jabber ビデオを AF41 または AF42 にマーキングするように設定されている点で、企業例 #2 は企業例 #1 と大きく異なります。また、企業例 #2 は、オーディオ部分のビデオ キューの保護に Enhanced Locations CAC も使用しています。Cisco Collaboration System Release(CSR)12.x には、ビデオ プールからすべてのオーディオを差し引くことができる機能があります。詳細については、Enhanced Locations Call Admission Controlの項を参照してください。
IT 部門は、企業例 #2 の各サイト タイプに応じた WAN エッジの帯域幅要件の決定を任されています。次に要件を一覧で表示し、QoS の適用方法と、帯域幅、キューイング、アドミッション制御の要件の決定方法について説明します。
Jabber エンドポイントは信頼されておらず、データ VLAN 内に配置されています。企業例 #2 では、アクセス レイヤ スイッチでシグナリングおよびメディアを再マーキングするのに特定の UDP ポート範囲を使用します。この場合、Unified CM の設定には、個別のメディアおよび 3000 ~ 3999 のオーディオ用と 5000 ~ 5999 のビデオ用のシグナリング ポート範囲を使用するすべての Jabber クライアント専用の SIP プロファイルを使用します。セキュア SIP シグナリング ポート 5061 は、Secure SIP シグナリング ポートとして使用されます。図 13-84 でこれについて説明します。
図 13-84 信頼されていない(Jabber)エンドポイント QoS
管理者は、次の DSCP 値に UDP ポートを再マーキングするデータ VLAN にアクセス スイッチの ACL を作成します。
Jabber エンドポイントの場合、Jabber SIP プロファイルでデフォルトの QoS 値も変更することをお勧めします。これは、何らかの理由で QoS がワイヤレス ルータ経由または他の方法で「信頼されている」場合、適切な「信頼されている」値が再マーキング値と同じになるようにするためです。そのため、SIP プロファイルの QoS パラメータは、 表 13-17 に示すように設定する必要があります。
|
|
|
---|---|---|
TelePresence コールのオーディオ部分の DSCP(DSCP for Audio Portion of TelePresence Calls) |
表 13-17 の設定により、何らかの理由で Jabber クライアントのオーディオとビデオが信頼され、アクセス スイッチで UDP ポート範囲経由で再マーキングされない場合、Jabber クライアントのオーディオは EF に設定され、ビデオは AF42 に設定されます。これは単に、Jabber エンドポイント間で設定の一貫性を確保するためです。
信頼されているエンドポイントの場合、Cisco Discovery Protocol(CDP)が使用され、IP Phone およびビデオ エンドポイントの QoS は、アクセス スイッチで設定された条件付き信頼メカニズムを使用して信頼されます。すべてのエンドポイントのオーディオすべてが EF に設定されるように、デフォルト設定を変更する必要があります。この場合、Unified CM の設定には、ビデオ コールと TelePresence コールのオーディオをそれぞれ EF に変更する SIP プロファイルを使用します。
図 13-85 では、アクセス スイッチの条件付き信頼(CDP ベース)およびパケット マーキングを示します。
管理者は、次に分類されるように、IP Phone およびビデオと TelePresence エンドポイントの条件付き QoS 信頼ですべてのアクセス スイッチを設定します。
管理者は、 表 13-18 に記載された DSCP 値を使用して、信頼されているエンドポイントの Unified CM の SIP プロファイルを設定します。
|
|
|
---|---|---|
TelePresence コールのオーディオ部分の DSCP(DSCP for Audio Portion of TelePresence Calls) |
WAN エッジの入力に到着する特定の DSCP 値を持つパケットは、アクセス レイヤで信頼されているか、またはアクセス スイッチで信頼されていない場合は適宜再マーキングされていることが予想されます。入力のフェールセーフ プラクティスとして、アクセス レイヤで再マーキングできなかった信頼されていないトラフィックは、WAN エッジで再マーキングすることが重要です。QoS は LAN で重要ですが、WAN では最も重要です。ルータは入力トラフィックが信頼されていると見なすため、ビジネス要件およびユーザ エクスペリエンスに応じた適切な QoS ポリシーを設定することが重要です。WAN エッジの再マーキングは、ルータへの入力インターフェイスで常に実行されます。キューイングおよびスケジューリングは出力インターフェイスで実行されます。次に、WAN 入力 QoS ポリシーと出力キューイング ポリシーの例を示します。図 13-86 では、設定と再マーキングのプロセスを説明します。
図 13-86 では、ネットワークの信頼されている領域と信頼されていない領域の両方から送られるパケットは、前述の信頼方法または UDP ポート範囲に一致する簡単な ACL を経由し、適切な DSCP マーキングを使用して識別および分類されます。この ACL は、IP アドレスと、マーキング範囲を細かに制限する他のいくつかの属性にも細部にわたって一致する可能性があることに注意してください。
図 13-86 ルータ入力 QoS ポリシー プロセス例:ステップ 1
図 13-87 では、ポリシー一致基準および DSCP 再マーキングについて説明します。このプロセスには、図に示された次のステップが含まれます。
1. パケットがルータ入力インターフェイスに到着し、入力サービス ポリシーで設定されます(図 13-87)。
2. policy-map は、適切な DSCP を設定するトラフィックの 4 つのクラスで設定されます。EF の DSCP を設定する VOICE、AF41 の DSCP を設定する PRIORITIZED-VIDEO、AF42 の DSCP を設定する OPPORTUNISTIC-VIDEO、CS3 の DSCP を設定する SIGNALING-SIP(図 13-87)です。
3. 各クラスは、[いずれかに一致(match-any)] 基準、DSCP 一致、ACL 一致が設定された同名の class-map と一致します。この [いずれかに一致(match-any)] 基準の場合、プロセスはトップダウン方式で、最初に一致した基準が実行され、次に policy-map ステートメントの各クラスに従って DSCP を設定します。[すべてに一致(match-all)] はもう 1 つの方法で、すべての基準に一致する必要があります。つまり、DSCP および ACL と一致します。ただし、マーキングされたトラフィック または マーキングされていないトラフィックのいずれかを再マーキングするための機能ではありません。
図 13-87 ルータ入力 QoS ポリシー プロセス例:ステップ 1~3
4. ステップ 4 で、class-map ステートメントの最初の行が解析されます。これは Unified CM の識別と分類セクションに設定されている UDP ポートに一致する ACL です。ACL 基準(プロトコル、ポート範囲、および場合により DSCP)が一致する場合は、対応する policy-map ステートメントで設定されているとおりにトラフィックがマーキングされます(図 13-88)。図 13-86 のポリシーに従って、Jabber Audio は EF とマーキングされ、Jabber Video は AF42 とマーキングされることに注意してください。
図 13-88 ルータ入力 QoS ポリシー プロセス例:ステップ 4
5. ステップ 5 で、最初のステートメントに一致しないトラフィックは class-map 内の次の match ステートメント、 match dscp に移動します(図 13-89)。トラフィックが DSCP と単純に一致する場合、DSCP はすでに一致したものと同じ値に再び設定され、policy map ステートメントで設定されたかのようになります。この場合、ルータは単純に DSCP に一致し、DSCP を同じ値にリセットします。これはサーバおよびアプリケーションから WAN ルータに入ってくる信頼された DSCP の catch-all 設定です。
図 13-89 ルータ入力 QoS ポリシー プロセス例:ステップ 5
(注) これは、Cisco Common Classification Policy Language(C3PL)に基づいた QoS 入力マーキング ポリシー例です。C3PL をサポートするシスコ ルータで同様のポリシーを実現する方法と、更新されたコマンドについては、特定のルータの設定ガイドを参照してください。
6. トラフィックは、3 つのキュー(VOICE と呼ばれる Priority Queue、VIDEO と呼ばれる CBWFQ、SIGNALING と呼ばれる CBWFQ)が作成された出力サービス ポリシーによってキュー登録およびスケジューリングされた送信インターフェイスに移動します。(図 13-90)。これは、この出力キューイング ポリシーが、アクセス スイッチや WAN ルータ入力インターフェイスへの入力で発生するネットワーク マーキングとして DSCP のみに基づいている点を強調しています。これは、一致基準およびキューを説明するための単なる例であり、WRED 機能(次の項で説明)は含まれていません。WRED の詳細については、WAN キューイングとスケジューリングの次の項を参照してください。
図 13-90 ルータ出力キューイング ポリシー プロセス例:ステップ 6
7. トラフィックが class-map 一致ステートメントと一致します。EF とマーキングされたトラフィックはすべて VOICE PQ に送られ、AF41 と AF42 のトラフィックは VIDEO CBWFQ に、CS3 のトラフィックは SIGNALING CBWFQ に送られます(図 13-91)。
図 13-91 ルータ出力キューイング ポリシー プロセス例:ステップ 7
(注) これは、Cisco Common Classification Policy Language(C3PL)に基づいた出力キューイング ポリシー例です。C3PL をサポートするシスコ ルータで同様のポリシーを実現する方法と、更新されたコマンドについては、特定のルータの設定ガイドを参照してください。
ここでは、インターフェイス キューイングについて説明します。図 13-92 では、CBWFQ で使用される音声 PQ、ビデオ CBWFQ、および WRED のしきい値について説明します。
– 信頼されているエンドポイントからのビデオ コールのオーディオ ストリームには EF
– 信頼されているエンドポイントからのビデオ コールのビデオ ストリームには AF41
– Jabber クライアントからのすべてのコールのオーディオ ストリームには EF
– Jabber クライアントからビデオ コールのビデオ ストリームには AF42
図 13-92 キューイングとスケジューリングのコラボレーション メディア
重み付けランダム早期検出(WRED)の最小および最大しきい値は、Video CBWFQ でも設定されます。WRED のしきい値の設定方法を説明するため、インターフェイスはキューの深さが 256 パケットで設定されていると仮定します。次に、上述のガイドラインに従って、AF42 および AF41 の WRED の最小しきい値および最大しきい値が、図 13-93 の説明とおりに設定します。
図 13-93 WRED のしきい値を持つビデオ CBWFQ の例
ここでは、各サイト タイプのキューに対してアドミッション制御およびプロビジョニング帯域幅を指定します。
前述のとおり、このような場合、アドミッション制御をビデオ帯域幅の管理には使用しませんが、その代わり、PQ がオーバーサブスクライブされないようにするために、オーディオ トラフィックの管理には使用します。この企業例 #2 では、Enhanced Locations CAC の音声プールは、音声専用コールとビデオ コールの両方のオーディオを許可しています。
Unified CM でこの機能をイネーブルにするには、コールした CallManager サービスのコール アドミッション制御セクションで、サービス パラメータ [ビデオ コールのオーディオ プールからオーディオ帯域幅を差し引く(Deduct Audio Bandwidth from Audio Pool for Video Call)] を [True] に設定します。デフォルト設定は [False] であり、デフォルトでは、Unified CM はビデオ プールからビデオ コールのオーディオとビデオの両方のストリームを差し引きます。このパラメータはその動作を変更するため、企業例 #2 の QoS の変更に不可欠です。
図 13-94 では、さまざまなコール フロー、それに対応するオーディオとビデオ ストリーム、そのダイレクト先のキューについて説明します。
図 13-94 の例では、次の設定を使用します。
– 比率は、デスクトップ ビデオ エンドポイントの帯域幅使用率に適用されます。
– Jabber ビデオ コールは、ビデオ ルーム システムで使用されていない帯域幅を使用できます。
– 輻輳の発生時、Jabber コールのビデオ ストリームでは、WRED が低下するため、ビデオ ビット レートが動的に下がります。
図 13-95 の帯域幅割り当ては、この企業例 #2 だけに基づいたガイドラインです。コラボレーション トラフィックのさまざまな共通クラスで利用可能な帯域幅の割合について説明しています。帯域幅のプロビジョニングは使用率に大きく依存しており、それぞれの展開と、各サイトで割り当てられるユーザ ベースごとに異なることを理解することが重要です。次の例では、帯域幅のプロビジョニングに使用するプロセスを説明します。帯域幅のプロビジョニング後、最適なユーザ エクスペリエンスに必要な最高の帯域幅のプロビジョニングと割り当てを維持するには、帯域幅の監視および再調整が常に必要です。
ここでは、各サイト(中央、大規模支社、小規模支社、営業所)と、各クラスのユーザ数と利用可能な帯域幅に基づいてクラスごとにプロビジョニングされたリンク帯域幅について説明します。これらの値は、レイヤ 3 以上用に計算された帯域幅に基づいていることに注意してください。そのため、リンク タイプ(イーサネット、フレーム リレー、MPLS など)に依存しているレイヤ 2 のオーバーヘッドは含まれていません。レイヤ 2 のオーバーヘッドの詳細については、ネットワーク インフラストラクチャの項を参照してください。
また、ビデオ コールの帯域幅のオーディオ部分が音声プールから差し引かれるようになったことにも注意してください。音声キューをプロビジョニングするときは、音声専用コールとビデオ コールの両方のオーディオ帯域幅が含まれます。これらは企業例 #1の例と同じです。唯一の違いは、企業例 #2 の場合、ビデオ コールの帯域幅のオーディオ部分は音声アドミッション制御プールから差し引かれ、オーディオ ストリームは音声キューに入ります。
図 13-96 で示すように、中央サイトには次の帯域幅要件があります。
– イマーシブ エンドポイント:2 Mbps ∗ 1 コール = 2 Mbps
– ビデオ エンドポイント:1.2 Mbps ∗ 30 コール ∗ 0.2 = 7.2 Mbps
– TelePresence Servers:1.5 Mbps ∗ 40 コール ∗ 0.5 = 30 Mbps
– 55 Mbps – (2 Mbps + 7.2 Mbps + 30 Mbps) = Jabber メディア用 15.8 Mbps
576p で 18 Jabber ビデオ コール、または 288p で 50
イマーシブ エンドポイントは最繁時に応じて決定されます。あるエンドポイントで WAN 経由のコールがあるとします。会議コールは TelePresence サーバでローカルに終了するため、これはポイントツーポイント コールになります。最頻時の最悪のシナリオを考慮することが重要です。
ビデオ エンドポイントの WAN 使用率は 20 %(∗0.2)に指定されます。1.2 Mbps での有効な総コール数は 30 で、エンドポイントの数に基づいています。ただし、WAN 経由のアクティブ コールの WAN 使用率が 20 % しかないとすると、アクティブ ローカル コールと比較して、WAN 使用レートは 7.2 Mbps 以上になります。
TelePresence Server では、リモート サイトにあるエンドポイントのさまざまな解像度の平均を考慮して、平均ビット レートは 1.5 Mbps に指定されます。その場合、TelePresence Server は、最大 40 コール(ローカルとリモート)をサポートできます。このコールの 50 %(0.5 倍)は、WAN 経由で転送される TelePresence コールの半分に対応し、残りの半分はローカル エンドポイント用です。
さらに、Jabber コールが 15.8 Mbps の場合、576p で 18 コールや 288p で 50 コールなど幅広く対応します。このことから、Jabber ビデオ コールが帯域幅に応じて利用できることがわかります。15.8 Mbps 以上で多くの Jabber ビデオ コールが発生すると、パケット損失が起こり、すべての Jabber クライアントでビット レートが下方調整されます。これは、新しいコールが追加されても損失レートは低く、ユーザ エクスペリエンスに明確な影響を与えない非常に軽微なプロセスなのか、パケットの即時損失が発生した場合に Jabber ビデオに多大な影響を与えるかのどちらかです。新しいビデオ コールが追加されるときの予想パケット損失レートは、この状況対応型ビデオのユーザ エクスペリエンスが中断されるレベルを決定するのに役立ちます。
図 13-97 で示すように、大規模支店サイトには次の帯域幅要件があります。
– ビデオ エンドポイント:1.2 Mbps ∗ 6 コール = 7.2 Mbps
– 18.7 Mbps – 7.2 Mbps = 11.5 Mbps(Jabber メディア用)
576p で 13 Jabber ビデオ コール、または 288p で 36
図 13-98 で示すように、小規模支店サイトには次の帯域幅要件があります。
– ビデオ エンドポイント:1.2 Mbps * 2 コール = 2.4 Mbps
– 4 Mbps – 2.4 Mbps = 1.6 Mbps(Jabber メディア用)
576p で 2 Jabber ビデオ コール、または 288p で 5
営業所ブロードバンド インターネット接続(5 Mbps)帯域幅の計算
図 13-99 で示すように、営業所サイトには次の帯域幅要件があります。
制限付き WAN リンクを使用する大規模支店(ビデオに対応する Enhanced Locations CAC)
低速 WAN リンクを持つ特定の支店サイトでは、ビデオ キューのオーバープロビジョニングは実現不可能です(図 13-100 を参照)。ELCAC は、ビデオ コールがリンク帯域幅をオーバーサブスクライブしないように、ビデオのこれらのロケーション リンクに適用できます。このテンプレートでは、サイト固有のリージョン設定を使用して、ビデオ エンドポイントおよび Jabber クライアントで使用される最大帯域幅を制限する必要があります。また、Jabber ユーザがサイト間でローミングする場合には、デバイス モビリティも必要になることに注意してください。
(注) 音声専用コールとビデオ コールの両方のオーディオ帯域幅は音声 CAC プールから差し引かれるため、企業例 #1 の場合のように、キューの帯域幅調整は必要がありません。
図 13-100 制限付き WAN リンクを使用する大規模支店(ビデオに対応する Enhanced Locations CAC)
図 13-100 の説明のとおり、制限付き WAN リンク(10 Mbps)の大規模支店サイトには次の帯域幅要件があります。
– 有効な使用方法:576p(768 kbps)で 2 コール + 288p(320 kbps)で 5 コール = 3,136 kbps
– ビデオ コールの Unified CM ロケーション リンク帯域幅:3.2 Mbps(L3 帯域幅)
– L2 オーバーヘッド、バースト性、AF41 とマーキングされた Jabber オーディオ専用コールのために帯域幅を確保する