Cisco Video/TelePresence アーキテクチャ デザイン ガイド

キャンパス内

ビデオのキャンパス内トポロジは、単一の企業サイトまたはキャンパスでビデオを提供することのみを目的としています。このトポロジ モデルは、ユーザをファシリティ間で移動させることなく、ミーティングの効率および生産性を向上させる必要のある企業に適しています。キャンパス内ビデオ導入モデルは、組織のニーズを満たすために、企業内トポロジ モデルおよび企業間トポロジ モデルとともに使用できます。図 7-1 に、単一サイト コール処理を使用したキャンパス内トポロジを示します。

図 7-1 2 つのビルでのキャンパス内導入（ビデオ エンドポイント以外のすべてを一方のビルへ）

コール処理に関しては、単一サイト コール処理モデルおよびホステッド コール処理モデルが、キャンパス内ビデオ トポロジ モデルに適しています。どちらにするかの決定は、エンドポイントの密度、ネットワーク増大計画、必要な機能、およびコストに大きく依存します。

たとえば、ホステッド ビデオ コール処理導入モデルは、低コストの投資で、機能が非常に豊富なエクスペリエンスを提供します。ただし、いくつかのローカルなマルチポイント呼フローでは、ビデオ埋め込み型ビデオ リソースがない場合や、ユーザ密度が増大するとともにキャパシティが不足したために帯域とコストの関係が重大なファクタになっている場合に、メディア ストリームが構外に転送される必要が生じることがあります。

他方、単一サイト コール処理モデルには高い初期投資がかかります。これは、機能を利用するためにハードウェアやソフトウェアのライセンスが必要なためです。それでも、単一サイト コール処理モデルでは、導入後の低コストでのユーザ数増大が可能です。

企業内

ビデオの企業内トポロジでは、同じ企業内の複数のサイトで、WAN を介してビデオ アプリケーションを使用することができます。企業内導入モデルは、従業員が社内ミーティングのために頻繁に遠距離まで出張する必要がある企業に適しています。企業内にビデオを導入すると、出張時間の節約と豊富な機能によるコラボレーションによって生産性が向上するだけでなく、出張旅費も削減できます。また、出張の必要がなくなるので、通常従業員のワーク ライフ バランスが改善されます。

企業内トポロジで複数のサイトにまたがるビデオを可能にするには、快適なビデオ エクスペリエンスを提供するため、高速な WAN リンクを利用する必要があります。WAN リンクのダイメンショニングの詳細については、「拡張性とパフォーマンス」を参照してください。

図 7-2 に、複数サイト コール処理導入モデルを使用する企業内トポロジを示します。

図 7-2 複数のサイトへの分散型 Multi-Site Cisco Unified Communications Manager の導入

企業内導入では、複数サイト コール処理導入モデルまたはホステッド コール処理導入モデルを使用することができます。2 つのコール処理モデルのどちらにするかを決定する際は、キャンパス内の導入と同じ考慮事項が該当します。

企業間（Business-to-Business（B2B））

企業間ネットワーク導入モデルは、企業内のビデオ エンドポイントを接続するだけでなく、企業内のビデオ エンドポイントが別の企業内のシステムに発呼できるようにします。企業間モデルは、複数の企業間の接続を含むようにキャンパス内モデルや企業内モデルを拡張したものです。これは Business-to-Business（B2B）ビデオ導入モデルとも呼ばれます。

企業間モデルは、柔軟性が最も高く、従業員が社内および社外ミーティングのために頻繁に遠距離まで出張する必要がある企業に適しています。企業内モデルが企業にとって持つメリットのほかに、B2B トポロジ導入モデルでは、従業員が、関連する出張の時間および費用のコストをかけずに、高度な顧客関係を維持することができます。

図 7-3 に、企業間トポロジおよび単一サイト コール処理を使用してコミュニケーションを行っている 2 つの企業を示します。

図 7-3 各企業で単一サイト コール処理を使用した企業間（B2B）導入

3 つのコール処理導入モデルはすべて企業間導入モデルと連携でき、キャンパス内導入および企業内導入と同じ考慮事項が該当します。

単一サイト コール処理

単一サイト コール処理モデルでは、コール処理は単一サイトのみを処理し、コール処理エージェントは処理されるエンドポイントと同じロケーションに存在します。コール処理エージェントとエンドポイントの距離は、その遠近に関係なく、LAN の速度のリンクで処理する必要があります。単一サイト モデルは、中規模の企業および政府機関に適しています。これらの組織は、1 つのサイトに存在し、基本的なビデオ コール処理ニーズがありますが、ネットワークが爆発的に増大しているか、ユーザ密度が非常に高いため、ホステッド ソリューションの帯域とコストの比率がひどく高くなっています。図 7-4 に、単一サイト コール処理を使用したキャンパス内トポロジを示します。

図 7-4 2 つのビルでのキャンパス内導入（ビデオ エンドポイント以外のすべてを一方のビルへ）

複数サイトコール処理

複数サイト コール処理モデルでは、すべてのコール処理エージェントが同じロケーションに存在してもかまいません（集中型複数サイト コール処理）。あるいは、ユーザ密度が高いか、またはサービスがきわめて重要なためにバックアップが必要な場合には、複数のロケーションに分散することもできます。

同じコール処理エージェント クラスタ内では、複数サイト コール処理は、集中型または分散型複数サイト コール処理モデルを使用して、さまざまなトポロジ（例、ハブ アンド スポーク トポロジおよび複数ハブ アンド スポーク トポロジ）を処理することができます。図 7-5 に分散型コール処理モデルを示します。このモデルでは、複数サイト コール処理導入により、コール処理サービスのための大規模な分散型コール処理モデル（複数ハブ アンド スポーク）に応じて、大きな集中サイトおよび複数のリモート サイトまたは支社サイト、ならびにホーム オフィス サイトまたは小さな支社が処理されています。

図 7-5 分散型複数サイト コール処理

複数サイト コール処理モデルに含まれる別の導入では、クラスタ化されたコール処理エージェントが、クラスタ間のコール ルーティングを集約するためだけに導入されたコール処理素を介して、他のクラスタ化されたコール処理エージェントと通信できます。集約コール処理エンティティの導入は、すべてのコール処理クラスタ間のフル メッシュ接続を実装しなくても済むというメリットがあります。その代わりに、さまざまなリーフ クラスタが相互に通信する際には集約コール処理要素と連携します。階層を作成し、ソリューション全体のキャパシティを増大できるよう正しくダイヤル プランを作成した場合は、新しいリーフ クラスタを追加したときでも、リーフ クラスタでのダイヤル プランの更新は必要ありません。

図 7-6 に、複数サイト集約コール処理導入の 2 つの例を示します。1 つは Cisco Unified Communications Manager Session Management Edition（SME）を使用している例で、もう 1 つは Cisco TelePresence Video Communication Server（VCS）をディレクトリ ゲートキーパーとして使用している例です。

図 7-6 複数サイト集約コール処理導入の 2 つの例

（注） H.323 ゲートキーパーではクラスタ（代替ゲートキーパー）の概念は使用できますが、H.323 ゲートキーパーは自己決定のコール ルーティング エンティティであるため、単一のゲートキーパーも、上記の議論においてはクラスタ化されたコール処理エージェントとみなされます。

ホステッド コール処理サービスとしてのビデオ

ホステッド導入モデルは、クラウドによって提供および管理されるサービスのことです。このサービスは、所有コスト（投資額）が低く、機能豊富なエクスペリエンスを提供する点で魅力的です。ホステッド ビデオ ソリューションは、中堅および中小企業をターゲットとし、それらの企業にエンタープライズ グレードのビデオを低コストで導入できるようにします。また、ホステッド ソリューションによっては、ビジネスが成長しても元の投資対象を維持できる移行パスが用意されています。

この導入モデルでは、コール処理要素以外のものもしばしば構外に配置されるため、いくつかのマルチポイント コール フロー シナリオではビデオ ストリームを構外に転送する必要があります。そのような場合、サービス ロケーションのユーザ密度が高いと、帯域を広くしてそれらを処理する必要が生じます。

コール処理トポロジとビデオ エンドポイントの選択ガイドライン

ビデオ ネットワークを導入または拡張するために適切な要素と導入モデルを選択することは、目的の機能、パフォーマンス、および拡張性を確実に実現するうえで有益です。それどころか、ビデオ ネットワーク用に不適切な要素やモデルを選択すると、組織が必要とする機能を実現するのに高コストの変更が必要となる場合もあります。

以下の項で、ビデオ ネットワーク用に要素および導入モデルを選択するための一般的ガイドラインを示します。

• 「コール処理モデルとコール処理エージェントの選択ガイドライン」

• 「エンドポイントの選択ガイドライン」

• 「ビデオ ネットワークの設計上の考慮事項」

呼シグナリング プロトコルの選択の詳細については、「IP ビデオ ソリューションでのコール制御プロトコルと IPv6」の章を参照してください。

コール処理モデルとコール処理エージェントの選択ガイドライン

適切なコール処理エージェントとその導入モデルおよびトポロジを選択するには、導入の設計フェーズで組織の要件に加えて以下の点を考慮することが重要です。

• 導入の成功基準としての使用目的を実現するためには、どの機能が必要か。例、SIP、SRTP、BFCP、または IPv6 ビデオ サポート。

• ビデオ エンドポイントは処理が必要なネットワークにすでに導入されているか。新しく選択したコール エージェントによるサービスが必要な以前のビデオ エンドポイント、および以前のビデオ ネットワークとの相互作用などに対する要件があるか。

• 導入に含める以前のビデオ要素がある場合、それはどのプロトコルを使用しているか、または使用できるか。例、マルチプロトコル エンドポイント（SIP および H.323）あるいはシングルプロトコル エンドポイント。

• コール制御プロトコルは選択されているか。選択されていない場合、特定のコール制御プロトコルに依存する機能はあるか。たとえば、H.239 は H.323 とともにのみ使用できます。

• ビデオ サービスを必要とするロケーションはどこか。そのユーザ密度はいくつか。個々のロケーションにとって冗長性はどれぐらい重要か。ユーザ密度が高いサイトごとに冗長性の用途をコール エージェントに提供すること（分散型コール処理）を推奨します。また、ユーザ密度が非常に高いと、特定のホステッド コール処理のコール フローでは、脅威（インターネット帯域利用率）となります。

• プロトコルのインターワーキングを使用するか。インターワーキングは特定の状況下でコール エージェントの配置に大きく影響します。これは、メディア ストリームが宛先に到達するためにコール処理エージェントを通過する必要が生じる場合があるためです。

• 処理する必要があるビデオ コールの最大数はいくらか。1 台の Cisco TelePresence Video Communication Server（VCS） 7.0 の非トラバーサル コール数は最大で 500 です。これを超える残りのコールを処理するには、（クラスタ内に、またはスタンドアロンで）2 台目の VCS が必要です。

これらの考慮事項とお客様の要件、製品データ シート、および製品リリース ノートを考慮することで、選択するコール処理エージェントと使用するコール処理モデルおよびトポロジが決まります。たとえば、要件にアプリケーション共有技術としての BFCP の使用と、最大 2000 コールの処理が含まれている場合は、VCS クラスタが最適な選択となります。

エンドポイントの選択ガイドライン

ジョブに適切なエンドポイントを選択することは、コール処理エージェントの選択とほぼ同じぐらい重要です。お客様の要件に加えて、以下の点が選択の決定に役立ちます。

• H.323 と SIP のどちらのコール制御プロトコルが使用されるか。

• ビデオ会議には埋め込み型ビデオ リソースは必要か。そのような場合は、Cisco TelePresence System EX90 が適した選択肢です。

• どのようなビデオ解像度フォーマットが必要か。例、HD 720p。

• 選択しようとしている特定のエンドポイントとともにコールに関与する他のエンドポイントはどれか。例、Cisco Unified IP Phone 9971。

• どのようなアプリケーション共有技術が必要か。例、BFCP over UDP。

• モビリティ要件はどのようなものか。このエンドポイントはモバイル エンドポイント（コラボレーション タブレット）になるか。

これらの考慮事項とお客様の要件、製品データ シート、および製品リリース ノートを考慮することで、選択するエンドポイントが決まります。

ビデオ ネットワークの設計上の考慮事項

ビデオ ネットワークを設計する際には、インターワーキングの影響を考えることが重要です。インターワーキングを使用する場合、選択したコール処理エージェントに応じて、メディア ストリームがコール エージェントを通過する必要が生じることがあります。このため、コール処理エージェントがコールに関係するエンドポイントからリモートにある場合は、呼がポイント間で転送されないため、インターワーキングが帯域利用率に悪影響を及ぼす可能性があります。

また、DNS SRV レコードは通常拡張性を持たせるために使用されます（SRV レコードを使用すると、システムの統合に必要な SIP トランク数が減少する）が、コール処理エージェントは、DNS SRV レコードに対してはエンドポイント登録およびコール処理ピアリングに関して異なる方法で動作します。この動作の違いが異なるコール エージェントを統合する前に理解されていない場合に統合しようとすると、予期しない状況が発生する可能性があります。

集中型ビデオ リソース割り当て

リソースを同じロケーションに配置する合計コストがそれらを分散するコストより小さい場合は、集中型リソース割り当てを検討する必要があります。集中型リソース割り当てのフィジビリティも考慮する必要があります。たとえば、リソースの集中によりエンドポイントの状態が不適切（例、受け入れ不能なジッター）になる場合は、集中型リソース アーキテクチャが適さないシナリオがあります。

前述のように、「コール処理トポロジとビデオ エンドポイントの選択ガイドライン」の項に示したファクタは、特定のシナリオに適合する最適なアプローチを選択する決定プロセスに織り込む必要があります。たとえば、図 7-7に示すシナリオについて考えてください。本社にすべてのビデオ リソースを集中させた方が、コストが少なくて済むと考えがちですが、このようにリソースを集中すると、ハブとスポーク間の WAN リンクの帯域幅要件が増大するという副作用が生じます。また、WAN リンクで提供される帯域幅により、リモート サイトのマルチポイント会議キャパシティが制限されます。

図 7-7 集中型専用ビデオ リソース（埋め込み型リソースはなし）を含むハブ アンド スポーク ネットワーク

リモート エンドポイントがあまり多くなく、その遠いロケーションと帯域利用率により、WAN リンクで転送されるメディア ストリームが悪影響を受けないシナリオには、集中型ビデオ リソース割り当てアーキテクチャが通常最も適しています。

前のシナリオを修正したものが、リモート サイトに埋め込み型ビデオ リソースがある図 7-8のハイブリッドの例に示されています。このシナリオでは、集中型専用ビデオ リソースが使用されるのは、集中するロケーションに埋め込み型リソースがなく、ビデオ会議でビデオ エンドポイントを使用する場合か、またはビデオ会議の参加者数が、埋め込み型ビデオ リソースで処理できるキャパシティを超える場合に限ります。

図 7-8 集中型専用ビデオ リソースとリモート サイトの埋め込み型ビデオ リソースを含むハブ アンド スポーク ネットワーク

そのほかにも多くのシナリオが可能で、その場合、集中型ビデオ リソースのアプローチにはさまざまな方針や制限が適用できます。

分散型ビデオ リソース割り当て

さまざまなロケーションへの専用ビデオ リソースの分散には、いくつかのメリットがあります。その主なものは、WAN リンクの帯域幅を節約できることと、メディア ストリームに悪影響を与える可能性を減少できること（リソースの多くがローカルで終端されているため）です。ただし、分散型割り当てにはいくつかの制限もあります。たとえば、WAN リンクを通過する必要があるビデオ コールもあり、このようなストリームは WAN リンクの特性による制限を受けます。

分散型専用ビデオ リソースを導入するかどうかを決定する際には、以下の点を検討することで、ソリューションの費用対効果を最大化できます。

• ビデオ リソースのロケーションで予期されるビデオ コール使用パターンはどのようなものか。

• WAN リンクの現在の帯域幅で、ビデオ ストリームに悪影響を与えずに、リモート ロケーションで予期される使用パターンをサポートできるか。

• WAN リンクでのメディア送信の制限または副作用（存在する場合）は、意図している使用例で受け入れることができるか。

• 分散型の埋め込み型ビデオ リソースを使用することで、計画している使用例を実現できるか。

• 現在および計画のネットワーク トポロジで、ビデオ ソリューションは、分散型専用ビデオ リソースがなくても十分に拡張できるか。

さらに、専用ビデオ リソースに分散型割り当てを使用する場合は、ビデオ リソースの最適な配置場所を決定するために、コール制御要素のブリッジ選択アルゴリズムを理解することが重要です。たとえば、エンドポイントとリソースのタイムゾーンに基づいて専用ビデオ リソースを確保することができます。他の方法としては、ビデオのロケーションに基づくビデオ リソースの確保や、手動での確保があります。どの場合も、選択アルゴリズムを理解することの重要性は、ビデオ リソースを効率的に分散させるために、ストリームを最終的にどこで終端するかを理解する必要性に由来しています。

最適化されたビデオ配信

ビデオが効率的なコラボレーション ツールであるためには、ユーザ エクスペリエンスが高品質である必要があります。ユーザ エクスペリエンスの品質を保証するには、組織の要件を満たすよう、ビデオの配信を最適化する必要があります。以下の項で、ビデオ配信を最適化する方法についてのガイドラインを示します。

• 「Quality of Service（QoS）」

• 「コンテンツ共有技術」

• 「信頼性」

Quality of Service（QoS）

ビデオの配信を最適化する最初のステップは、対象となるトラフィックを識別し、個別の QoS（Quality of Service）を適用することです。QoS により、組織は、ビジネス クリティカルなビデオ ストリームとクリティカルでないビデオ ストリームを識別するとともに、選択したトラフィック タイプのレイテンシ、ジッター、および損失を受け入れ可能な範囲に抑えるアプリケーション インテリジェンスを実現できます。また、より良いビデオ エクスペリエンスを提供するために、可能な場合は、プライオリティ キューイングを他のキューイング メカニズムの上で使用する必要があります。統合ネットワーク（TelePresence と IP ビデオ テレフォニーを統合したネットワーク）の場合、シスコではアプリケーションごとに QoS クラスを分けることを推奨します。

図 7-9 に、同じネットワーク内で複数の IP ビデオ アプリケーションと IP 音声を統合している例を示します。この例では、イマーシブ ビデオ、ビデオ会議、ビデオ オン デマンド、および Voice over IP が識別されて、推奨されている QoS マーキングが割り当てられ、必要なサービス レベルを実現して過剰なプロビジョニング、つまりキュー内でのアプリケーションのオーバーラップを回避します。

図 7-9 統合ネットワークで推奨する QoS トラフィック マーキング

ビデオ ソリューションにおける QoS の詳細については、「QoS とコール アドミッション制御」の章を参照してください。

コンテンツ共有技術

ビデオ ソリューションの一環として導入するエンドポイントに応じて、そのビデオ エンドポイントでサポートおよび必要とされるコンテンツ共有標準を考慮するとともに、それらがどのように統合され、または必要な場合は相互作用するかを考慮することが重要です。IP ビデオ ソリューションが使用するコンテンツ共有技術には、現在、Binary Floor Control Protocol（BFCP）、H.239、および自動コラボレートの 3 つがあります。コンテンツ共有機能を実現するのに、H.323 のエンドポイントは H.239 標準を使用するのに対し、SIP のエンドポイントは自動コラボレートまたは新しい標準である BFCP を使用することができます。

プレゼンテーション共有技術およびコンテンツ共有技術の詳細については、次の URL にある『 Cisco TelePresence Interoperability Deployment Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps8332/products_device_support_tables_list.html

信頼性

ビデオ対応キャンパスのパフォーマンスおよび可用性は、プロアクティブにモニタし、ネットワーク全体で測定する必要があります。障害の場合の代替パスも提供して、ビデオ ソリューションの信頼性を保証する必要があります。高可用性のネットワークを設計する方法の詳細については、次の URL にある『 Campus Network for High Availability Design Guide 』を参照してください。

http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns815/landing_cHi_availability.html

ビデオ アプリケーションのセキュリティ

ビデオ対応ネットワークは、ビデオ アプリケーションへの不正アクセスを防止するビデオ セキュリティをできれば常に組み込む必要があります。悪意のあるユーザからのスヌーピングと侵入からのトラフィックの保護と攻撃の緩和が不可欠であるとともに、悪意のあるユーザが許可されていないビデオを送信できないようにすることも必要です。ビデオ ネットワークのセキュリティを保護するには、ビデオのトラフィックを切り離すネットワーク仮想化技術から、外界には見えないトポロジのためのデータ VLAN または Session Border Controller（SBC）にあるソフトウェア クライアントでのトラスト リレー ポイント（TRP）の使用まで、さまざまな技術を使用できます。ビデオ ネットワークのセキュリティを保護する方法の詳細については、「ビデオ コミュニケーションのセキュリティ」の章を参照してください。

拡張性とパフォーマンス

導入されるビデオ アプリケーションやビデオ ユーザの増加とともに増大する帯域幅ニーズに対応するには、ネットワークの拡張性が重要になってきます。最適のパフォーマンスを維持するには、ネットワークは、高解像度ビデオ ストリームをサポートしたり、場合によっては複数の HD ビデオ ストリームを同時にサポートするよう拡張できるなど、より広い帯域にすぐに対応できる必要があります。したがって、導入するビデオ アプリケーションで生成されることが予想されるトラフィックに対し、適切にネットワークをサイジングすることが重要です。

ネットワークをサイジングする最初のステップは、エンドポイントおよびユーザの要件を把握することです。次に、会議およびポイントツーポイント コールのときのメディア フローの動作を決定します。続いて、音声およびデータのトラフィックならびに、信頼性を持たせるために必要となるバックアップ方式に関する考慮事項を追加します。図 7-10 に、本社キャンパスに 20 のイマーシブおよびデスクトップ ビデオ エンドポイントがあり、支社に 15 のその他のエンドポイントがあるシナリオの例を示します。この例で予期されている使用パターンは、次のとおりです。

• 本社のデスクトップ エンドポイントのユーザとイマーシブ エンドポイントのユーザは、ピークの発信回数が 7 回になります。

• 本社のエンドポイントは、支社との間のピーク発信/受信回数が 6 回になります。

• 本社デスクトップ エンドポイントのコールでは 1.3 Mbps を使用しているのに対し、イマーシブ エンドポイントでは 12 Mbps を使用しています。

• 支社のビデオ IP Phone では 1 Mbps、デスクトップ エンドポイントでは 1.3 Mbps、イマーシブ エンドポイントでは 12 Mbps が使用されます。

• ピーク時には、支社のユーザは最大 4 回発信し、本社との間では 6 回発信/受信（上記のとおり）します。

• 本社と支社のユーザは、サイト間で実行される 10 Mbps（連結）のデータ アプリケーションにアクセスする必要があります。

図 7-10 ビデオ対応ネットワークのキャパシティ要件の決定

上記の要件が単純化してあることは明らかです。非常に複雑なネットワークおよび導入では、要件およびサポートするアプリケーションが多くなります。しかし、前述の例の要件リストについては、以下のことを決定できます。

• 以下の最悪のシナリオを想定した場合、予想される最大の帯域利用率は、スイッチ A とスイッチ B の間のアップリンク（図 7-10 のリンク 1）ではビデオ ストリームで 49 Mbps です。

– デスクトップ ビデオ エンドポイントのローカル マルチポイント コールに 7 人のユーザが参加している場合：

7 X (1.3 Mbps) = 9.1 Mbps

– イマーシブ エンドポイント（ローカルが 3 つ、リモートが 3 つ）のマルチポイント コールに 6 人のユーザが参加している場合：

3 X (12 Mbps) = 36 Mbps

– ローカル デスクトップ エンドポイント（ローカル ビデオ IP Phone が 3 つ、リモート ビデオ IP Phone が 3 つ）のマルチポイント コールに 6 人のユーザが参加している場合：

3 X (1.3 Mbps) = 3.9 Mbps

（注） この帯域計算では、データ アプリケーションの追加帯域やその他必要な追加帯域（コール シグナリング用など）を考慮していません。LAN をダイメンショニングする前に、このような他の帯域要件を含めておく必要があります。

• 最悪のシナリオでは、以下を想定して、支社の WAN リンク（図 7-10 のリンク 5。ただし、リンク 3、4 と 6 には同じ考慮事項が該当する）でビデオ ストリーム用に 43.6 Mbps の帯域を使用します。

– 4 つのビデオ電話間でのマルチポイント コールに 4 人のユーザが参加している場合： ローカルのマルチポイント コントロール ユニット（MCU）がないため、マルチポイント コールが行われるには、すべてのストリームが本社まで転送される必要があります。

4 X (1 Mbps) = 4 Mbps

– 5 つのデスクトップ ビデオ エンドポイント、1 つのビデオ電話、3 つのローカル エンドポイント（2 つのデスクトップ ビデオ エンドポイントおよび 1 つのビデオ電話）、3 つのリモート エンドポイントの間でのマルチポイント コールに 6 人のユーザが参加している場合：

2 X (1.3 Mbps) + 1 Mbps = 3.6 Mbps

– イマーシブ エンドポイント（ローカルが 3 つ、リモートが 3 つ）のマルチポイント コールに 6 人のユーザが参加している場合：

3 X (12 Mbps) = 36 Mbps

（注） この帯域計算では、データ アプリケーションに必要な追加の 10 Mbps やその他必要な追加帯域（コール シグナリング用など）を考慮していません。それらの要件も、サイジング プロセスの一部として追加する必要があります。

• 最後に、図 7-10 の MCU を処理するリンク 2 では、前の 2 つの帯域計算を考慮することで、ビデオ ストリームはピーク時に 92.6 Mbps でリンクを通過することを予想できます。

49 Mbps + 43.6 Mbps = 92.6 Mbps

（注） 徹底的に検証済みで広く使用されている一般的なルールは、10 % のバーストとレイヤ 2 からレイヤ 4 へのネットワーク オーバーヘッドを吸収するために、ビデオ帯域を 20 % 過剰にプロビジョニングすることです。また、上記の計算は、例に示されている使用パターンの最悪シナリオに基づいていますが、すべてのビデオ ユーザが同時にビデオ コールを行うケース（100 % コール実行という）は考慮していません。

要するに、ビデオ対応ネットワークのキャパシティとパフォーマンスの設計では、望ましいコール実行率や予期される使用パターンによって大幅なレイテンシを生じずに、ビデオ転送を可能にする必要があります。コールごとに必要な帯域量の決定については、ご使用のエンドポイントのマニュアルを参照してください。

スタンドアロン型 H.323 ビデオ ネットワークとの統合

H.323 は、非常に洗練されたプロトコルで、マルチベンダー SIP 要素の場合よりかなり簡単に H.323 コール処理要素との相互運用性を実現します。ただし、H.323 は対応する SIP ほどサービスが豊富ではありません。たとえば、シスコでは、通話中のスピーカーが誰になるかによって画面を切り替える機能（smart switching）を実装していますが、この機能は H.323 ネットワークではネイティブで使用可能ではありません。

可能な場合は常に、ビデオ エンドポイントのネイティブな相互作用を使用して、エンドポイントを H.323 ネットワークに直接接続します。ただし、そのようにしても、smart switching などの必要な機能が失われない場合に限ります。不可能な場合、機能の保持が重要なときや、ポイントツーポイントの相互運用性がネイティブで得られないときは、ビデオ トランスコーダまたは相互運用性対応会議ブリッジを介して H.323 エンドポイントに接続します。オーバーラップのないダイヤル プランも推奨します。その理由は、コールを実行するのに次のビデオ システムへのホップが必要であることをコール処理エージェントに示すために、ネットワーク間でさまざまなアクセス コードを使用できるからです。

図 7-11 に、マルチポイント コントロール ユニット（MCU）を使用して Cisco TelePresence System をサードパーティの H.323 スタンドアロン型ビデオ ネットワークに接続する例を示します。

図 7-11 スタンドアロン型 H.323 ネットワークの統合

スタンドアロン型 SIP ビデオ ネットワークとの統合

SIP ビデオ ネットワークは、H.323 ネットワークより機能が豊富で、すべてのエンドポイントでサポートされる場合は、非常に有益な機能を有効にすることができます。ただし、SIP は H.323 ほど洗練されていないため、それとの相互運用性は H.323 の場合より困難です。

エンドポイントが SIP 標準に厳密に準拠している場合、コール エージェントは、コール処理エージェント内で使用可能なネイティブのビデオ相互運用性機能を使用することができます。そうでない場合、ビデオ ネットワークは、ビデオ トランスコーダまたは相互運用性対応マルチポイント コントロール ユニットを使用して、相互にブリッジすることができます。

シスコでは、ビデオ ネットワーク間でオーバーラップ ダイヤル プランを使用せず、アクセス コードを使用して、ビデオ ネットワーク間をルーティングするようコール処理エージェントに指示し、桁間タイムアウトを回避することを推奨します。ダイヤル プランで Uniform Resource Identifier（URI）ダイヤルを使用する場合、シスコでは管理のしやすさから複数のドメインを使用することを推奨します。

図 7-12 に、Cisco TelePresence System と SIP 標準に基づくサードパーティ システムの統合を示します。この例では、ダイヤルのために、複数のドメインとともにネイティブの相互運用性を使用しています。

図 7-12 スタンドアロン型 SIP ネットワークとの統合