Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) Cisco Unified CallManager Release 5.0

MeetingPlace Audio Server

MeetingPlace Audio Server（8112 または 8016）は、オーディオ会議機能のための Digital Signal Processor（DSP; デジタル シグナル プロセッサ）リソースを提供します。さらに、MeetingPlace サーバは Web、オーディオ、およびビデオ会議のスケジューリング モジュールとして機能します。MeetingPlace サーバは予約に基づいて、会議に参加できるユーザの数と会議の継続時間を制御します。

MeetingPlace H.323/SIP IP Gateway

MeetingPlace Audio Server は当初、T1/E1 トランクを介したサービス プロバイダーまたは PBX の基礎となる TDM 接続のために設計されました。既存の Cisco Unified Communications ネットワークに組み込むには、2 つのネットワークをリンクする MeetingPlace H.323/SIP IP Gateway が必要です。これは「ゲートウェイ」と呼ばれますが、ハードウェアのゲートウェイではなく、MCS サーバ上に存在するソフトウェア アプリケーションであり、MeetingPlace Audio Server と Cisco Unified CallManager の間の通信に使用されます（図14-2 を参照）。

図14-2 インターフェイスとして使用される MeetingPlace H.323/SIP IP Gateway

MeetingPlace H.323/SIP IP Gateway は、H.323 と SIP を同時にサポートします。MeetingPlace H.323/SIP IP Gateway がサポートするプロトコルの詳細については、「相互運用性プロトコル」の項を参照してください。

MeetingPlace オーディオ サーバは、TDM 接続と IP 接続の混在をサポートできます。混在環境のキャパシティは、システム内の TDM ポートと IP カード（ユーザ ライセンス）の組み合せによって異なります。

MeetingPlace H.323/SIP IP Gateway は、同じ Cisco Media Convergence Server（MCS）上で他の MeetingPlace アプリケーション（MeetingPlace Web、SMTP 電子メール、Video Integration など）と共存できますが、純粋な IP のセットアップでは、MeetingPlace H.323/SIP IP Gateway を単一の MCS 上に独立してインストールすることをお勧めします。そうすることにより、Web またはビデオの部分で何かの問題が発生した場合でも、オーディオ通信が影響を受けずに済みます。ただし、小規模な配置の場合、MeetingPlace H.323/SIP IP Gateway は MeetingPlace Web Conferencing Service と共存でき、MCS の CPU リソースをあまり使用しないので、Web 会議のパフォーマンスとキャパシティも大きな影響を受けません。

単一の MeetingPlace Audio Server を複数の MeetingPlace H.323/SIP IP Gateway に接続できます。1 つの MeetingPlace H.323/SIP IP Gateway に障害が発生し、進行中のコールがドロップされた場合は、新しいコールがセカンダリ MeetingPlace H.323/SIP IP Gateway へルーティングされます。MeetingPlace Audio Server からの発信ダイヤリングの場合、サーバはアクティビティが最小の MeetingPlace H.323/SIP IP Gateway を選択します。詳細については、「冗長性とロード バランシング」の項を参照してください。

それぞれの MeetingPlace H.323/SIP IP Gateway は、ゲートキーパーなしではサポートする Cisco Unified CallManager が 1 つだけですが、ゲートキーパーを使用すると複数の Cisco Unified CallManagers をサポートできます。それぞれの MeetingPlace Audio Server は最大で 16 の MeetingPlace H.323/SIP IP Gateways に接続し、冗長性、ロード バランシング、および複数の Cisco Unified CallManager クラスタのサポートが得られます。

1 つの Audio Server で、MeetingPlace アプリケーションがインストールされた GWSIM MCS サーバを最大 16 サポートできるので、複数の IP ゲートウェイをサポートできます（組み合された MCS アプリケーション サーバ数は 16 まで）。

（注） MeetingPlace Audio Server と MeetingPlace H.323/SIP IP Gateway の間で、Network Address Translation（NAT; ネットワーク アドレス変換）を使用しないでください。

MeetingPlace H.323/SIP IP Gateway は、次の 1 つまたは複数の方法で Cisco Unified CallManager と通信できます。

• SIP を介して、Cisco Unified CallManager が MeetingPlace H.323/SIP IP Gateway と直接通信する。

この方法を実装するには、MeetingPlace H.323/SIP IP Gateway への接続を Cisco Unified CallManager で SIP トランクとして設定します。

• H323 を介して、Cisco Unified CallManager が MeetingPlace H.323/SIP IP Gateway と直接通信する。

この方法を実装するには、MeetingPlace H.323/SIP IP Gateway への接続を Cisco Unified CallManager で H.323 ゲートウェイとして設定します。

• ゲートキーパーを介して、Cisco Unified CallManager が MeetingPlace H.323/SIP IP Gateway と通信する。

この方法では、Cisco Unified CallManager と MeetingPlace H.323/SIP IP Gateway をゲートキーパーに登録し、そのゲートキーパーがコール ルーティングを処理します。

音声会議の使用率のサイズ選定

必要な音声ユーザ ライセンスの数を計算する一般的な計算式は、次のとおりです。

MeetingPlace 音声ユーザ ライセンスの数 =

（月あたりの平均会議時間（分） + 成長係数）/ ベースライン

小数点以下の端数は整数に切り上げてください。

表14-2 は、この計算式に使用するベースラインのリストです。

たとえば、使用しているシステムの月平均使用状況が会議時間にして 528,000 分間と見積られる場合、必要なユーザ ライセンスの数は次のようになります。

MeetingPlace 音声ユーザ ライセンスの数 = 528,000 ∗ (1 + 20%) / 2500 = 254

Web 会議の使用率のサイズ選定

必要となる Web ユーザ ライセンスの数は、音声ユーザ ライセンスの合計数に対する比率、または Web 会議の使用率に関するサービス プロバイダーからの課金情報に基づいて算出できます。一般的な配置では、音声会議ライセンス数の 25% ～ 50%（25% が最も一般的）が Web 会議ライセンス数として使用されますが、音声ユーザ ライセンスと Web ユーザ ライセンスを同じ数だけ配置している企業もあります。

たとえば、音声ユーザ ライセンス数が 240 の配置では、Web ユーザがそのうちの 25% として、Web ユーザ ライセンス数を 60 とする必要があります。このシステムの場合、1 台の MCS 7845 があれば Web サービスを処理でき、最大 200 Web ユーザ ライセンスまでの増大にも対処できます。

Web 会議は、必要となる Cisco MCS 7800 シリーズ サーバの数にも直接影響を与えます。他の MeetingPlace 統合モジュールと同じ場所に置かれた 1 台の MCS 7835 は約 50 Web セッションに対応できますが、MCS 7845 は最大で約 200 Web セッションまで対応できます（ピーク時間における実際の使用方法のタイプによって異なります）。したがって、Web 会議 リソースのサイズ選定は、企業のデータ環境における全体設計やソリューションの配置にとって大変重要です。

Web 会議の使用率は、一般的に音声会議の使用率よりも速い成長率を示し、企業内の Web コラボレーションの量に依存します。Web 会議の場合は、今後 2 ～ 5 年間の成長（一般的には 1 年あたり 20% ～ 30%）を見積るようにしてください。

Video Integration と MCU のサイズ選定

MeetingPlace Video Integration はシステム全体のソフトウェア モジュールであり、ビデオ会議にユーザ ライセンスは不要です。サポートされるビデオ ユーザの数は、MCU 上で MeetingPlace が制御に使用できる H.323 ポートの数で決まります。IP/VC 3511 MCU は 15 ポート（H.323 または SCCP のどちらか一方）を備え、3540 MCU は、30、60、または 100 個のポート（H.323 か SCCP、または両方が混在）を備えています（ 表14-3 を参照）。

MeetingPlace Video Integration を使用すると、ユーザは単一の IP/VC MCU でビデオ会議をスケジューリングできます。現時点で、MeetingPlace は複数の MCU やカスケード式ビデオ会議をサポートしていません。他のサードパーティ製 MCU を配置し、MeetingPlace Video Integration ソリューションと統合されない、その他のビデオ会議アプリケーションをサポートすることもできます。

MeetingPlace Video は、システム内の 1 台の MeetingPlace Web MCS 上だけに存在できます。それが、内部と外部のどちらの Web サーバでもかまいません（ただし、どちらか一方）。ビデオ会議は、MeetingPlace Video がインストールされている Web サーバ上だけで可能になり、システム内にある他の Web サーバ上ではサポートされません。音声会議と Web 会議は、すべてのサーバ上でサポートされることに変わりありません。MeetingPlace Video Integration ソフトウェアは、Web Conferencing モジュールと同じ MCS 上に、他の MeetingPlace 統合モジュール（Outlook、Notes、Directory Services など）と一緒に存在できますが、予想される Web ユーザ ライセンスの数と Web サーバの合計数によって異なります。

このソフトウェアは 1 台の Web サーバにしか存在できないので、MeetingPlace Video ソリューションは現時点で冗長性を提供できません。

同じ Cisco Unified Videoconferencing 3540 または 3511 MCU を他の SCCP ビデオ テレフォニー エンドポイントとの MeetingPlace ビデオ統合に使用でき、単一の IP/VC 3540 MCU で ad-hoc ビデオ テレフォニー コール（SCCP 制御）と MeetingPlace H.323 会議の両方をサポートできます。そのような配置では、MCU 上のいくつかのポートをビデオ テレフォニー用の SCCP のサポートに割り当て、残りのポートで MeetingPlace 用の H.323 をサポートします。IP/VC 3511 MCU では、このデュアル モードがサポートされません。IP/VC 3511 MCU で両方のモードをサポートするには、1 台の 3511 MCU をビデオ テレフォニー用に配置し、別の 3511 MCU を MeetingPlace Video Integration 用に配置する必要があります（ 表14-3 を参照）。

MeetingPlace と IP テレフォニー コンポーネント間の接続

MeetingPlace を IP テレフォニー ネットワークに接続するときは、必ず次のようにしてください。

• スイッチ ポートおよび MeetingPlace コンポーネントを、手動で 100 MB 全二重または 1000 MB 全二重に設定する。

• MeetingPlace の各コンポーネントを物理的に同じ場所に置く。

• MeetingPlace インフラストラクチャと他の IP テレフォニー製品との間に冗長ネットワーク接続を構築し、WAN に障害が発生しても確実に機能するようにする。

Quality of Service（QoS）

ここでは、MeetingPlace に関連する次の QoS メカニズムについて説明します。

• 「トラフィック分類」

• 「コール アドミッション制御と帯域幅プロビジョニング」

• 「ジッタ」

トラフィック分類

トラフィックの分類は、輻輳したネットワークにおける音声品質にとって非常に重要です。音声パケットは、分類またはデータ パケットと区別する必要があり、高いプライオリティで処理される必要があります。音声トラフィックには、ソース位置でマーキングされるものもあれば、ネットワークのエントリ ポイントのできるだけ近くでの分類が必要なものもあります。

MeetingPlace Audio Server のトラフィック分類には、次の特性があります。

• レイヤ 2 Class of Service（CoS; サービス クラス）のマーキングをサポートしない。

• レイヤ 3 音声シグナリングのマーキングをサポートしない。

• Real-Time Transport Protocol（RTP）パケットのソースでのマーキングをサポートする（有効な場合のみ）。

MeetingPlace Audio Server では、次のいずれかのレイヤ 3 の設定を RTP パケットに適用できます。

• IP 優先順位

• Type of Service（ToS; タイプ オブ サービス）

• Differentiated Services Code Point（DSCP、または DiffServ）

（注） IP 優先順位の設定は DSCP 値よりも優先されます。したがって、DSCP 設定を使用する場合は、IP 優先順位と ToS の設定値を手動で unused に設定する必要があります。DSCP フィールドに必要な値を設定し、IP 優先順位と ToS を 0 に設定した場合、RTP トラフィックは MeetingPlace Audio Server からマーキングされません。

MeetingPlace Audio Server の内部には、音声シグナリング トラフィックをそのソース位置でマーキングするメカニズムが存在しません。すべての MeetingPlace コンポーネント間のトラフィックは、ネットワークに入るとすぐにマーキングされる必要があります。MeetingPlace コンポーネント間のトラフィックは通常、Gateway System Integrity Manager（GWSIM）アプリケーションからのもので、このアプリケーションは MCS 7800 シリーズ サーバ上にロードされ、常に MeetingPlace 統合ソフトウェア モジュール（Web、Outlook、Notes、Video など）と組み合されています。このトラフィックが WAN を経由するときは、このトラフィックに他の音声シグナリング トラフィックと同じプライオリティが与えらる必要があります。

他のデバイスと整合性のあるパケット マーキングを使用するようにしてください。詳細については、 「ネットワーク インフラストラクチャ」 の章を参照してください。

コール アドミッション制御と帯域幅プロビジョニング

MeetingPlace Audio Server および他の MeetingPlace コンポーネントは、独自のコール アドミッション制御メカニズムを持っていません。MeetingPlace Audio Server は、すべてのポートまたはリソースを使い果たすまで、IP コールまたは会議の要求を受け入れることができます。その結果、十分な帯域幅が使用可能でない場合は、所定のリンクを経由するすべてのオーディオ ストリームの音声品質が劣化する可能性があります。

WAN リンクなど、帯域幅に制限のあるリンクを含んだ配置では、コール アドミッション制御を実装する必要があります。コール アドミッション制御の詳細については、 「ネットワーク インフラストラクチャ」 の章を参照してください。

音声とビデオのレートとコーデックの選択

音声

音声だけの会議では、音声コール用に選択される音声コーデックが、Cisco Unified CallManager でのリージョンの設定によって異なります。Cisco Unified CallManager のリージョン設定で指定されたコーデックは、MeetingPlace Audio Server の設定対象である音声コーデックと一致している必要があります。最も一般的に使用されるコーデックは、G.711 A-law または mu-law と G.729 です。MeetingPlace は、両方のタイプのコーデックをサポートしますが、デフォルトでは G.711 だけが有効になります。G.729 サポートも必要な場合は、Audio Server の初期設定時に有効にする必要があります。

ビデオ

Cisco Unified CallManager Release 5.0 は、H.261、H.263、および H.264 コーデックをサポートしています。ビデオ会議の場合、ビデオ レートを次の場所で設定できます。

• MCU サービス ビュー

• Cisco Unified CallManager リージョン

• MeetingPlace ユーザ プロファイル

MeetingPlace ユーザ プロファイルでの最大ビデオ レートは、384 kbps に設定されます。Cisco Unified CallManager リージョン設定で指定されたビデオ レートは、要求された帯域幅、または MCU か MeetingPlace のユーザ プロファイル内で設定されたビデオ レートが、リージョン設定を超えた場合にのみ有効になります。

たとえば、次のようなビデオ帯域幅の設定を考えてみます。

• Cisco Unified CallManager リージョン：512 kbps

• MCU サービス ビュー：384 kbps

• MeetingPlace ユーザ プロファイル：256 kbps

この場合、ビデオ ユーザが MCU にダイヤルインして会議に参加すると、選択されるビデオ レートは 384 kbps となり、MCU サービス ビューでの設定に対応したものになります。MeetingPlace ユーザ プロファイル内のビデオ帯域幅設定は、MeetingPlace Video がコール フローに含まれていないため、有効にはなりません。

ユーザへの発信ダイヤリングでは、MeetingPlace Video アプリケーションは、そのユーザの MeetingPlace ユーザ プロファイル内のビデオ帯域幅値（256 kbps）を MCU に渡します。MCU は、その値を自分のサービス ビュー値（384 kbps）と比較し、低い方の帯域幅値（この例では 256 kbps）をビデオ会議用として選択し、コール要求を Cisco Unified CallManager ビデオ テレフォニー エンドポイントまたは H.323 ビデオ エンドポイントへ伝達します。コール用として選択されるビデオ帯域幅は、ビデオ エンドポイントによって異なります。Skinny Client Control Protocol（SCCP）ビデオ エンドポイントでは、帯域幅は MCU サービス ビューおよび Cisco Unified CallManager リージョンでのビデオ レート設定に従って選択されます（この例では 384 kbps が選択されます）。ただし、H.323 ビデオ エンドポイントでは、帯域幅が 3 つのビデオ レート設定値のすべてに基づいて選択されます（この例では 256 kbps が選択されます）。

図14-4 に、ビデオ帯域幅の選択アルゴリズムを示します。

図14-4 ビデオ帯域幅の選択アルゴリズム

Cisco Unified CallManager のリージョン帯域幅設定（この例では 512 kbps）が有効になるのは、MCU または MeetingPlace Video アプリケーションがリージョン設定より大きな帯域幅（この例では 512 kbps 超）を要求し、エンドポイントがビデオ会議にダイヤルインしたときだけです。エンドポイント ユーザが接続に発信ダイヤル機能を使用した場合は、MeetingPlace プロファイルの帯域幅設定が使用されます。

MeetingPlace Web セッションのネットワーク使用率

MeetingPlace Web セッションは、次の量のネットワーク トラフィックを生成します。

• 参加者は最初に約 1 MB のデータをダウンロードし、セキュリティの注意事項への同意を求められ、ブラウザを閉じてリセットする。

• 各参加者は、会議の開始時に 0.5 ～ 0.75 MB のデータをダウンロードする。

• 平均使用量のベースラインは、参加者あたり約 600 Bytes/秒である。

• アプリケーション モードでは、プレゼンターがビューを変更したときに送信されるデータの量は、表示されるカラーとグラフィックの量によって異なる。その場合、次の一般的なガイドラインを適用できます。

–複雑度が低いプレゼンテーションは、参加者あたり約 10 kB のデータを送信する。

–複雑度が中程度のプレゼンテーションは、参加者あたり約 50 kB のデータを送信する。

–複雑度が高いプレゼンテーションは、参加者あたり約 430 kB のデータを送信する。

–ほとんどのプレゼンテーションは、低から中の範囲である。

Cisco Unified MeetingPlace Web Conferencing は、帯域幅が使用可能であれば 24 ビット カラーを送信し、低速接続の場合は 8 ビット カラーに自動的に低減します。その判断は、まず高いレートで伝送を試み、データが大幅に遅延するか失われる場合にレートを低くするという方法で自動的に行われます。

ジッタ

パケット遅延の変動はジッタと呼ばれ、音声品質に深刻な影響を及ぼす場合があります。ジッタ バッファは、ネットワーク遅延の変動を吸収します。MeetingPlace Audio Server には、ジッタ バッファを設定するための次のパラメータがあります。

• Jitter Buffer Minimum Size：ジッタ バッファは変化するジッタ値に自動的に適応しますが、このパラメータでジッタ バッファの最小値が定義されます。

• Jitter Buffer Optimization：この値は、ネットワーク ジッタに対するジッタ バッファの応答速度を制御します。

ほとんどの場合、これらのパラメータのデフォルト値は変更しないでください。これらの値は、音声品質の問題が実際に発生してから調整します。

ドメイン ネーム システム（DNS）

MeetingPlace Audio Server は、内部で DNS をサポートしていません。実装内にあるすべての MeetingPlace Audio Server コンポーネントと MCS コンポーネントに、静的 IP アドレスを割り当てることをお勧めします。Audio Server は、他のサーバへのアクセスに IP アドレスを使用しようとします。MeetingPlace のコンポーネント（MeetingTime System Administration クライアントなど）は、ホスト名を使用して MeetingPlace Audio Server に接続する場合があります。また、MeetingPlace のコンポーネントは、ホスト名を使用して他の Cisco Unified Communications 製品と通信する場合もあります。

ネットワーク タイム プロトコル（NTP）

MeetingPlace Audio Server は、NTP を使用してクロックをネットワーク タイム サーバと同期します。MeetingPlace Audio Server は、最大 3 台の NTP サーバで設定できます。MeetingPlace の Windows ベースのコンポーネントは、w32time.exe サービスを使用して NTP クライアントまたはサーバとして機能できます。すべてのコンポーネントでクロックが同期されるように、企業ネットワーク全体で NTP サーバを 1 台だけ使用することを強くお勧めします。

非武装地帯（DMZ）の要件

DMZ に配置された MeetingPlace コンポーネントにより、外部ユーザは会議にアクセスできます。外部ユーザが Web 会議にアクセスできるようにするには、独立した MeetingPlace Web サーバを DMZ に配置することもできます。その場合でも、内部ユーザは内部 MeetingPlace Web サーバを使用して非公開の会議を行えます。

DMZ 配置では、内部ユーザが完全な Web アクセスおよび MeetingPlace 機能（スケジューリング、検索、参加、添付ファイルへのアクセス、および記録）を使用できるのに対し、外部ユーザは会議への参加だけを許可されます。会議が開始されると、内部ユーザは外部 Web サーバに転送されます。

図14-5 は、このタイプの配置を示しています。

図14-5 外部ユーザ用の DMZ がある MeetingPlace Web 会議

DMZ 内の MeetingPlace コンポーネントが、ファイアウォールなどのセキュリティ ポリシーによって内部 MeetingPlace コンポーネントから分離されている場合は、統合が正しく機能するように、そのファイアウォールで特定の TCP ポートまたは UDP ポートを開く必要があります。

DMZ から内部ネットワークにポートを開く必要はありませんが、内部ネットワークから DMZ に次のポートを開く必要があります。

• TCP 80 または 443（Web 会議用）

• TCP 5003（双方向、Audio Server と Web サーバの間の通信用）

• TCP 5005（添付ファイルと記録用）

• TCP 1503（Microsoft NetMeeting 用、省略可能）

• TCP 1627（Web 会議のパフォーマンス向上用、省略可能）

DMZ とインターネットとの間では、次のポートが開かれます。

• TCP 80 または 443

• TCP 1503（Microsoft NetMeeting 用、省略可能）

• TCP 1627（Web 会議のパフォーマンス向上用、省略可能）

DNS サービスは、次の理由から分割する必要があります（1 台は内部 DNS サーバ、もう 1 台は外部 DNS サーバ）。

• 使いやすさ：1 回のクリックだけで、内部と外部のユーザが会議に参加できます。

• セキュリティ：外部ユーザは内部ネットワークに関する情報にアクセスできません。

• パフォーマンスの向上：この配置では、外部 DNS サーバに内部要求の負荷がかかりません。

内部 DNS サーバは社内ネットワークの内部からの照会だけを解決し、外部 DNS サーバは、会社のドメインの公的にアドレス指定可能なエンティティを保持します。各 DNS サーバは、URL と IP アドレスの両方をマップする必要があります。

（注） IP アドレスがデータに組み込まれているため、MeetingPlace Audio Server と他の MeetingPlace コンポーネントとの間では、NAT はサポートされません。

表14-4 は、MeetingPlace Audio Server とそのコンポーネントが使用するすべての TCP ポートと UDP ポートを示しています。

IP ネットワーク

ここでは、MeetingPlace コンポーネントを IP ネットワークと統合するために使用されるプロトコルについて説明します。次のタイプのプロトコルがあります。

• 「MeetingPlace Audio Server がサポートするプロトコル」

• 「その他の MeetingPlace コンポーネントがサポートするプロトコル」

MeetingPlace Audio Server がサポートするプロトコル

MeetingPlace Audio Server は、次のプロトコルまたはアプリケーションを使用して IP 通信システムに統合されます。

GWSIM

Gateway System Integrity Manager（GWSIM）は、MeetingPlace Audio Server とそのコンポーネントの間のインターフェイスとして機能する専用アプリケーションです。Cisco Unified MeetingPlace GWSIM はクライアント/サーバ アーキテクチャに基づいており、リモート MeetingPlace コンポーネントと情報を交換する手段が提供されます。MeetingPlace Audio Server は、System Integrity Manager（SIM）を使用してすべての会議情報を管理します。SIM は IP ネットワークを使用して、MeetingPlace コンポーネント上にインストールされた GWSIM エージェントとの間で、すべてのシグナリングおよび会議情報を交換します。この通信には TCP ポート 5001 および 5003 を使用するシスコ専用のプロトコルが使用され、一般的に GWSIM 通信と呼ばれます。

Real-time Transport Protocol（RTP）

MeetingPlace Audio Server は、エンドポイント（IP Phone、IP/VC MCU など）への直接的なリアルタイム オーディオの伝送に UDP を使用します。RTP に最も一般的に使用されるコーデックは、G.711 と G.729 ですが、MeetingPlace Audio Server は G.722、G.723、G.726、G.728、GSM、GSM-EFR、および QCELP もサポートします。Audio Server は、デフォルトでは RTP に G.711 コーデックだけを使用できるように設定されます。ただし、コマンドライン インターフェイスを使用すると、このデフォルトを必要なコーデックに変更できます。

MeetingPlace Audio Server で H.323 と SIP をサポートするには、MeetingPlace H.323/SIP IP Gateway を使用する必要があります。

その他の MeetingPlace コンポーネントがサポートするプロトコル

ここでは、MeetingPlace Audio Server 以外の MeetingPlace コンポーネントと IP 通信ネットワークとの統合に使用されるプロトコルについて説明します。

H.323

H.323 ネットワークを MeetingPlace と統合すると、機能が豊富な会議ソリューションが得られます。すでに述べたように、MeetingPlace Audio Server は H.323 をネイティブでサポートするわけではないので、H.323 プロトコルをサポートするには MeetingPlace H.323/SIP IP Gateway が必要です。Cisco Unified MeetingPlace H.323/SIP IP Gateway は H.323 をサポートし、ネットワーク内にあるその他の H.323 エレメントと直接通信します。これにより、Audio Server を使用した会議が可能になります。

MeetingPlace H.323/SIP IP Gateway は、H.323 を使用して Cisco Unified CallManager または Cisco Unified CallManager Express と直接統合されます。MeetingPlace H.323/SIP IP Gateway が同時に処理できる H.323 コールの数は、Audio Server の最大 IP ポート制限で決まります。オプションとして、ゲートキーパーを Cisco Unified CallManager または CallManager Express に統合し、アドレス解決と帯域幅制御に使用することもできます。

MeetingPlace H.323/SIP IP Gateway は次の TCP ポートと UDP ポートを、ここに示した目的に使用します。

• H.323

–H.225 用のコール セットアップは、静的 TCP ポート 1720 を使用します。

–H.245 用のコール セットアップは、アドレス範囲 1024 ～ 65535 の TCP ポートをランダムに使用します。

–RTP 音声ストリームは、5000 ～ 65535 の範囲の UDP ポートをランダムに使用します。

• ゲートキーパー

–Registration Admission Status（RAS）用に静的 UDP ポート 1719 が必要です。

（注） MeetingPlace H.323/SIP IP Gateway は、H.323 Fast Start をサポートしません。ただし、着信 H.323 fast-start コールを受信した場合でも、そのコールは通常の H.323 シグナリング手順を使用して完了します。

図14-6 は、MeetingPlace with Cisco Unified CallManager と CallManager Express の相互運用性を示しています。

図14-6 H.323 を使用した Cisco Unified CallManager と CallManager Express との統合

SIP

MeetingPlace H.323/SIP IP Gateway は、Session Initiation Protocol（SIP）ネットワークを Cisco Unified MeetingPlace Audio Server に相互接続する機能も備えています。MeetingPlace H.323/SIP IP Gateway は、SIP プロキシ サーバまたは SIP ゲートウェイと直接統合され、SIP メッセージを GWSIM メッセージに変換します。その結果、SIP エンドポイントは MeetingPlace Audio Server を会議に使用できます。

Cisco Unified CallManager Release 5.0 以降では、Cisco Unified CallManager 上の SIP トランクを使用して、MeetingPlace H.323/SIP IP Gateway と直接統合できます。Cisco Unified CallManager と MeetingPlace H.323/SIP IP Gateway との間で SIP トランクを使用するには、次の 3 つの重要な要件があります。

• メディア ターミネーション ポイント（MTP）を使用する必要があります。

• 静的に有効にされた MTP が必要なため、G.711 コーデックだけがサポートされます。

• UDP Transport を使用する必要があり、TCP はサポートされません（UDP Transport を使用して別個の SIP セキュリティ プロファイルを作成する必要があります）。

MeetingPlace H.323/SIP IP Gateway は次の UDP ポートを、SIP に使用します。

• コール セットアップは静的 UDP ポート 5060 を使用します。

• RTP 音声ストリームは、5000 ～ 65535 の範囲の UDP ポートをランダムに使用します。

図14-7 は、MeetingPlace と Cisco Unified CallManager との相互運用性を示しています。

図14-7 SIP 統合

（注） MeetingPlace H.323/SIP IP Gateway は、H.323 接続と SIP 接続を同時にサポートできます。

XML アプリケーション

MeetingPlace Audio Server はオーディオ通信だけを処理できます。ビデオ会議をサポートするには、IP/VC Multipoint Control Unit（MCU; マルチポイント コントロール ユニット）と直接統合される外部 MeetingPlace Video アプリケーションが必要です。Cisco Unified MeetingPlace Video Integration は、TCP ポート 3336 を介した XML メッセージングを使用して Cisco Unified Videoconferencing MCU と通信します。

図14-8 は MeetingPlace と IP/VC MCU との相互運用性を示しています。

図14-8 ビデオ統合

公衆電話交換網（PSTN）

Cisco Unified MeetingPlace Audio Server は、デジタル（T1 か E1）またはアナログのトランクを使用して、公衆網に直接接続するか、または PBX を介して接続します。また、MeetingPlace Audio Server には、音声ゲートウェイに接続した Cisco Unified CallManager を介して、公衆網からも到達可能です。

デジタル トランク

Cisco Unified MeetingPlace は、次の各項で説明するように、T1 および E1 のデジタル トランクをサポートしています。

T1

Cisco Unified MeetingPlace は、T1 デジタル トランク用に次のプロトコルをサポートしています。

• T1-CAS（ループ スタート、ウィンク スタート、またはグラウンド スタート）

• T1-PRI（AT&T PRI、Nortel PRI、または Bell PRI）

T1 Smart Blade は、公衆網または PBX から直接接続された T1 をサポートします。マルチアクセス ブレード（MA-4 または MA-16）は、PBX または公衆網への T1-PRI または E1-PRI デジタル接続をサポートします。デジタル回線用のフレーム構成は、Extended Superframe（ESF; 拡張スーパーフレーム）または D4 フレーミングが可能です。デジタル回線には、Binary 8-Zero Substitution（B8ZS）または Alternate Mark Inversion（AMI; 交互マーク反転）コーディングを使用できます。

（注） ESF フレーム構成と B8ZS コーディングを使用するようにしてください。

通常、デジタル接続には E&M またはグラウンド スタート（GST）シグナリングが用意されています。E&M シグナリング用に設定された T1 回線上では、MeetingPlace は Direct Inward Dial（DID/DDI; ダイヤルイン）または Dialed Number Identification Service（DNIS; 着信番号識別サービス）の着信番号情報だけを受信できます。MeetingPlace は着信番号情報を使用して、発信側を会議へ直接接続するか、発信側がアクセスできる MeetingPlace サービスを判別します。

Cisco Unified MeetingPlace は、フラクショナル T1 サービスもサポートします。

E1

Cisco Unified MeetingPlace は、E1 デジタル トランク用に次のプロトコルをサポートしています。

• Euro-ISDN（ETSI 300-102）

• QSIG（ECMA バージョン）：チャネルには 1 ～ 30 の番号が付きます。

• QSIG（ETSI バージョン）：チャネルには 1 ～ 15 および 17 ～ 31 の番号が付きます。

（注） Cisco Unified MeetingPlace システムは、E1-PRI プロトコルだけをサポートします。E1-CAS プロトコルはサポートしません。

それぞれの E1 プロトコルは、シグナリング オプションのソフトウェア設定が可能です。シグナリング オプションは、PBX または公衆網スイッチ上に設定されたオプションと一致している必要があります。

（注） MeetingPlace Audio Server 上ではプロトコルの混在がサポートされません。ただし、IP ポートと組み合せた場合は除きます。たとえば、Cisco Unified MeetingPlace Audio Server では、同じシステム上に T1 ポートと E1 ポートの両方を設定できませんが、T1（PRI または CAS）ポートと IP ポートを設定したり、E1 ポートと IP ポートを設定したりすることはできます。また、Cisco Unified MeetingPlace Audio Server では、同じシステム上に T1-CAS ポートと T1-PRI ポートの両方を設定することはできません（表14-5 ～表14-7 を参照）。

詳細については、『 Getting Started Guide for Cisco Unified MeetingPlace Audio Server 』および『 Configuration Guide for Cisco Unified MeetingPlace Audio Server 』を参照してください。どちらも次の Web サイトから入手可能です。

http://www.cisco.com/univercd/cc/td/doc/product/conf/mtgplace/index.htm

オーディオ会議

MeetingPlace Audio Server 用としては、次の 2 つのプラットフォームがあります。

• Cisco Unified MeetingPlace 8106 Audio Server

–最大 480 の IP ポート（増分の単位は 24 または 30 ユーザ ライセンス）

–最大 536 の T1-CAS ポート（増分の単位は 24 ユーザ ライセンス）

–最大 480 の T1-PRI ポートまたは E1 ポート（増分の単位は 24 ユーザ ライセンス）

• Cisco Unified MeetingPlace 8112：最大 960 の IP ポートをサポート

–最大 960 の IP ポート（増分の単位は 24 または 30 ユーザ ライセンス）

–最大 1152 の T1-CAS ポート（増分の単位は 24 ユーザ ライセンス）

–最大 960 の T1-PRI ポートまたは E1 ポート（増分の単位は 24 ユーザ ライセンス）

同時会議の最大数は、ポート数を 2 で割った数になります。サーバは、1 つの会議あたり最大 550 セッション（参加者）をサポートします。ただし、最大で 3 台の Audio Server にカスケード接続することにより、1 つの会議で合計 1650 オーディオ セッションを確立できます。

コール フロー

メディア ストリームが MeetingPlace Audio Server と IP Phone の間を直接流れる場合、メディア要求（シグナリング）は、MeetingPlace Audio Server に代わって MeetingPlace H.323/SIP IP Gateway で処理されます。図14-9 は着信コールのコール フロー、図14-10 は発信コールのコール フローをそれぞれ示しています。

図14-9 Cisco Unified CallManager と統合された MeetingPlace のオーディオ ダイヤルイン コール フロー

図14-10 Web インターフェイスからのオーディオ発信ダイヤル コール フロー

会議のタイプ

MeetingPlace は、次に示す 2 つの主要なタイプのオーディオ会議をサポートしています。

• 標準の（スケジュール済み）会議

この種の会議をスケジューリングするときは、会議 ID、参加者数など、会議のパラメータを指定できます。参加者が参加すると、メイン会議に直接接続されます。即時会議は、リソース予約の点では基本的にスケジュール会議で、唯一の違いは開始時間です（将来ではなく、すぐに開始されます）。

• 予約なしの会議

すべてのプロファイル ユーザは、電話機から予約なしの会議を開始できます（機能が有効な場合）。ユーザは、プロファイル ID とパスワードを使用してサイン インする必要があり、それによって会議が開始されます。データベースには、誰が会議を開始したのかに関する情報も格納されます。

予約なしモードは、システム全体のパラメータとユーザ グループ パラメータの両方です。システム全体に対してオンし、特定のエンド ユーザ セットに対してオフすることができますが、その逆はできません。このパラメータは、参加者が会議に参加したときに再生されるプロンプトを変更します。

両方のタイプの会議が同じ MeetingPlace Audio Server 上に存在でき、同じ会議ポート プールを共有します。予約なしモードを有効にしても、標準タイプの会議を同時にスケジューリングする機能は影響を受けません。ただし、予約なし会議では、自動的にユーザのプロファイル番号が会議 ID として設定されます。したがって、予約なしモードを有効にした場合、ユーザ プロファイル番号は予約済みとなり、手動で標準スケジュール会議用の会議 ID として割り当てることができなくなります。

ポート管理

MeetingPlace Audio Server は、次のタイプのポートを提供します。

• アクセス ポート

スケジューリング、参加、および記録済み会議の受信用に予約されています。

• 会議ポート

会議で使用中または予約済みのポートです。会議ポートは、次のタイプの特殊用途ポートも含んでいます。

–非常用ポートは、自動転送の処理用に予約されている会議ポートです。このポートは常にシステムで予約され、会議参加者が会議中に連絡窓口または係員に連絡して支援を受けたり、システム管理者が会議にダイヤルインできるようになっています。

–フローティング ポートは、予期しなかった会議参加者を処理するために設定されます。このポートは特定の会議用に固定されず、すでに満杯の会議に追加参加者が出たときに不足を補います。

• 過剰予約ポート

このポートは、物理的に存在しません。スケジュール済み会議では、予約されていても未使用のポートが存在するのが一般的であるという前提に基づいて、実際に使用可能な数よりも多くのポートをスケジューリングできるようにするために設定されるソフトウェア ポートです。このポートは物理的には存在しないので、設定可能な数に制限はありません。

スケジューリング

オーディオ会議は、次のインターフェイスでスケジューリングすることができます。

• MeetingPlace Web ユーザ インターフェイス（UI）

• Email Calendar Integration（Outlook または Lotus Notes）

• MeetingTime クライアント

• Cisco Unified IP Phone XML Service

オーディオ会議のカスケード化

会議のカスケード化は、 マルチサーバ会議 とも呼ばれます。この機能は、さまざまな MeetingPlace システムの間に仮想リンクを提供し、各サーバ上のユーザが同じ会議に参加しているかのように通信できます。ユーザがマルチサーバ会議をスケジューリングするときは、プライマリ サーバ上の Web スケジュールを使用して、会議に必要なセカンダリ サーバを選択します。会議の開始時に、プライマリ サーバは各セカンダリ サーバにコールを発信します。セカンダリ サーバは、参加者がシステムにダイヤルインした場合と同じように、プライマリ サーバを会議に追加します。

1 つの会議に対して、最大 3 台の Audio Server をカスケードできます。

すべての MeetingPlace Audio Server 上にある NTP サーバが、すべてのサーバ間で時刻を同期するように設定することをお勧めします。

マルチサーバ会議の詳細については、次の Web サイトで入手可能な『 Administrator's Guide for Cisco Unified MeetingPlace Audio Server 』を参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/conf/mtgplace/index.htm

ビデオ エンドポイントを使用したオーディオ専用会議へのダイヤルイン

ビデオ エンドポイントは、MeetingPlace Audio Server に直接ダイヤルインすることにより、オーディオ専用会議に参加できます。MeetingPlace は、エンドポイントからのアウトオブバンドとインバンドの両方の DTMF 番号をサポートします。Web サーバから発信ダイヤル機能を使用する場合、ユーザはオーディオ エンドポイントの電話番号ボックスにビデオ エンドポイントの内線番号を入力する必要があります。

ヒント Polycom H.323 デバイスの場合、ユーザが最初に # キーを押すと、画面に小さな電話機キーパッドが表示されます。Polycom デバイスはインバンド DTMF 番号を送信します。この番号は、G.711 コーデックを使用しているときにのみ機能します。

Web 会議

Web 会議には、次の MeetingPlace コンポーネントが関係します。

• 「MeetingPlace Web サーバ」

• 「SQL データベース」

MeetingPlace Web サーバ

MeetingPlace Web アプリケーションは、主に次のような機能を提供します。

• MeetingPlace Web ユーザ インターフェイス

この機能は、スケジューリング、会議室、会議コントロール、リファレンス センター、およびアカウント管理を提供します。

• MeetingPlace Web 会議

この機能は、コラボレーション、ホワイトボード、アプリケーション共有、ファイル アップロードなどを提供します。

• オーディオ ファイルの変換

MeetingPlace Web は、オーディオ サービス オプション付きでインストールされた場合、最初に MeetingPlace の音声（.mpv）ファイルを .wav 形式に変換します。その後、Windows Media（.wma）、RealAudio（.ra または .rm）、MP3 など、それ以外のサポートされているオーディオ形式に変換することもできます。そのようなファイルは、ダウンロードして他のアプリケーション（カスタム Web サイトや CD など）から使用可能にすることができます。

• 同期オーディオ Web 記録

オプションの音声および Web 記録がシステム上で有効な場合は、.wav ファイルを MeetingPlace Web で使用し、同期オーディオ/Web 記録を作成できます。

MeetingPlace Web は、Media Convergence Server（MCS）と IIS サービスが稼働している必要があり、MeetingPlace 8100 Audio Server マスター データベースと自動的に同期する Microsoft SQL データベースを使用します。

Cisco MCS 7835 サーバは最大 50 までの同時ユーザ セッションをサポートし、MCS 7845 は、最大 200 までの同時ユーザ セッションをサポートしますが、1 つの会議あたり 150 ユーザ セッションという制限があります。さらに、アプリケーション共有には 100 の同時 Web 会議という制限や、単一の Web サーバ上のプレゼンテーション モードには 150 までという制限もあります（プレゼンテーション モードにはアップロードされたプレゼンテーションが含まれ、そのプレゼンテーションは JPEG 形式に変換されて、それぞれ参加者が Web 会議に参加すると、ローカル ブラウザのキャッシュに個別にダウンロードされます）。

100 を超える Web 会議ユーザ ライセンスの配置では、Microsoft Desktop Engine（MSDE）2000 を使用しないでください。スケジューリングと Web 会議のための同時接続が 8 つまでに制限されているためです。SQL 2000 が必須となり、お客様が用意する必要があります。大規模なインストレーション（500 を超えるユーザ ライセンス）では、専用のサーバで SQL 2000 を実行してください。

キャパシティとロード バランシングの点でパフォーマンスを向上するには、MeetingPlace Web サーバをいくつかのクラスタにグループ化します。MeetingPlace Web クラスタは、最大で 6 つの Web サーバを内部構成または外部構成でサポートできます。

（注） シスコまたはサードパーティ製の Web バランシング製品を、MeetingPlace ソリューションと組み合せて使用しないでください。MeetingPlace Web には正しい Web バランシング機能が製品に組み込まれており、他のバランサーはこのアプリケーションとの組み合せで機能しません。

クライアントは、HTTP または HTTP over Secure Socket Layer（HTTPS）を介して MeetingPlace Web に接続できます。MeetingPlace Web サーバ上では、次の宛先ポートが使用されます。

• TCP ポート 5003 は、GWSIM を介して MeetingPlace Audio Server と通信するために使用されます。

• TCP ポート 5005 は、添付ファイルと記録に使用されます。

• TCP ポート 80 または 443 は、スケジューリングと Web ページの表示に使用されます。

• TCP ポート 1627（開いていない場合はポート 80 を通じたトンネル）または 443 は、そのサーバに Secure Socket Layer（SSL）が配置されていると、Web 会議に使用されます。MeetingPlace Web サーバに配置するには、SSL 認証を用意する必要があります。

SQL データベース

Web サーバ上の Microsoft SQL データベースには、プロファイル情報と会議情報が格納されます。会議情報のタイプは、Web サーバが内部（すべての内部および外部会議を収容）か外部（外部会議だけを収容）かによって異なります。プライマリ データベースは、Audio Server 上に置かれます。会議がスケジューリングされると、その会議情報は該当する Web サーバにもコピーされます。これにより、すべての要求が Audio Server を通過しなくても、特定の機能を容易に実行できるようになります。

MeetingPlace 5.3 からは、データベースに次のデータが含まれます。

• キャッシュされた MeetingPlace データ

• Web サーバ/サイトの設定データ

• Microsoft Outlook および Lotus Notes が、新規の短い Click-To-Attend リンクを長いリンクに変換するために使用するテーブル

• Web ユーザ インターフェイスで使用される英語および各国語のほとんどの文字列

• システム管理者がカスタマイズした文字列

• WebPoll とその結果

Microsoft Outlook と Lotus Notes は、データベースを直接には使用しません。Click-To-Attend リンクを格納するように MeetingPlace Web に要求してから、そのリンクを使用して会議に参加します。

MeetingPlace Video は、SQL データベースをまったく使用しません。

（注） Cisco Security Agent は、現時点ではすべての MeetingPlace サーバに対してサポートされているわけではありませんが、シスコ認定のウィルス保護プログラムはサポートされています。

会議のタイプ

MeetingPlace Web アプリケーションは、次のタイプの Web 会議をサポートします。

• オープン フォーラム会議

各参加者は、同様に話したり聞いたりすることができます。

• 講義形式の会議

大部分の参加者はデフォルトで聴取者として参加でき、1 人または複数の指定された話者が存在します。聴取者は、会議中に話すことができません。

• 即時会議

この会議は、デフォルトのシステム パラメータを使用してスケジューリングされます。このスケジューリング方式では、ユーザが独自の会議パラメータを指定することは許可されません。

• 予約なしの会議

このタイプの会議では、前もってリソースを予約したり会議 ID を割り当てる必要がありません。このタイプの会議を開始するには、事前に MeetingPlace Audio Server を予約なしモードに設定する必要があります。予約なし会議の参加者は、会議の議長が会議にログインするまで待合室に入れられます。待合室内の参加者が互いに話すことはできません。

• 連続会議

常時使用可能な連続会議を（MeetingTime クライアントで）設定できるのは、システム管理者だけです。この会議ポートはこの会議専用であり、オーディオ システムのスケジューリング タスクから使用することはできません。

• すべてのポートを予約

この機能は、システム管理者が、MeetingPlace Audio Server 上のすべてのポートをビジーアウトして、メンテナンス時間帯を提供するために使用します。

Web 会議のカスケード化

Web 会議をカスケード化することはできません。すべての参加者が同じ MeetingPlace Web サーバ上にいる必要があります。

セグメント化会議

外部ユーザがインターネット経由で Web 会議に参加できるようにする場合は、非武装地帯（DMZ）に別の外部 MeetingPlace Web サーバを配置することをお勧めします。この配置により、ファイアウォールの内側で内部ネットワークの機密を保護できます。このタイプの配置の詳細については、「非武装地帯（DMZ）の要件」を参照してください。

ビデオ会議

MeetingPlace ソリューションは H.323 と SIP の両方をサポートしますが、現時点ではビデオ会議に H.323 ビデオ エンドポイントだけがサポートされ、会議が MCU で処理されます。MeetingPlace で作成されるビデオ会議は、すべて H.323 会議になるため、MeetingPlace Video Integration では MCU 上に H.323 リソースが必要です。このソリューションでは、MeetingPlace が制御アプリケーションの役割を担い、MCU が実リソースを提供してブリッジ処理を行います。MeetingPlace Audio Server 上のオーディオ専用参加者と通信するために、音声リンクが MCU と Audio Server の間に確立され、MCU 上のビデオ会議に参加する 1 人のオーディオ参加者として動作します。

MeetingPlace が MCU を制御するようになると、すべての H.323 ポートが制御され、MCU 上で会議を直接作成できなくなります。MeetingPlace は、H.323 ポートの可用性を確認するため、定期的に確認を行います。

MCU が SCCP 会議にもリソースを割り当てるように設定されている場合、Cisco Unified CallManager はそのリソースを使用して、SCCP ad-hoc ビデオ会議をセットアップできます。

音声リンク

ビデオ エンドポイントが会議に参加すると、 音声リンク と呼ばれる特殊リンクが MeetingPlace Audio Server と MCU の間に確立されます。これは、MeetingPlace Audio Server から MCU 上のビデオ会議にダイヤルインするオーディオ参加者として機能します。会議のオーディオ エンドポイントがすべて MeetingPlace Audio Server に接続するのに対し、ビデオ エンドポイントはすべて MCU に接続します。それらは、音声リンクを介して互いに通信します。音声リンクは、最初のビデオ参加者が会議に参加するまで確立されません。最初のビデオ ユーザが会議に参加した時点で、MCU は MeetingPlace Video アプリケーションに信号を出し、それによって MeetingPlace Audio サーバが MCU への音声リンクを開始します。

同じ Audio Server にさまざまな E.164 番号を使用する複数の MeetingPlace H.323/SIP IP Gateway が存在する場合は、その E.164 番号をすべて MeetingPlace Video 設定ページに入力する必要があります。使用される E.164 番号は、Audio Server が発信ダイヤリング用に選択した MeetingPlace H.323/SIP IP Gateway によって決まります。MeetingPlace Video アプリケーションは、どの番号が選択されたかに関係なく、Audio Server の可能なすべての E.164 番号を認識して、音声リンクを受け入れる必要があります。

音声専用エンドポイントのない純粋なビデオ会議でも、すべての MeetingPlace 機能を利用するためには、2 つのシステムを接続する音声リンクが必要です。音声リンクは MeetingPlace Audio Server のいくつかの高度な機能、たとえば、ビデオ会議の Web 部分やオーディオ部分の記録とスケジューリングなどをサポートしているためです。

ビデオ記録は、MeetingPlace Video Integration ではサポートされません。MeetingPlace を使用すると、ビデオ会議のオーディオ部分と Web 部分を記録できます。サードパーティの記録システムを使用してビデオ セッションを記録することもできます。

MeetingPlace Video

MeetingPlace Video は MCS 上にインストールされるアプリケーションで、MCU に対する会議の承認者として機能します。MCU は、ビデオ会議の作成要求または既存のビデオ会議への追加参加者の承認要求を受信すると、その要求を MeetingPlace Video へ送って承認を受けます。

1 つの MeetingPlace Video アプリケーションは、1 つの MeetingPlace Web サーバとだけ通信できます。また、MeetingPlace Web 5.3 を実行するマシン上にインストールされている必要があります。MeetingPlace Audio Server に複数の MeetingPlace Web サーバが接続している場合、MeetingPlace Video をインストールしたり、有効にしたりすることができる Web サーバは 1 つだけです。それ以外の MeetingPlace Web サーバは、ユーザにビデオ機能を提供できません。

ファイアウォールの外側のユーザにビデオ機能が必要な場合は、DMZ に置かれた Web サーバ上で MeetingPlace Video を有効にする必要があります。外部ユーザ用の Web コラボレーションはインターネット経由でサポートされますが、現時点では、外部の電話およびビデオ参加者が公衆網（または ISDN）を使用して、Cisco Unified CallManager に接続されたゲートウェイ、または MeetingPlace に直接接続されたゲートウェイにアクセスすることが前提になっています。

DMZ で稼働する MeetingPlace Video がある場合は、外部ビデオ会議だけをスケジューリングできます。内部ビデオ会議のスケジュール要求は失敗します。

ビデオ ポート要求で会議がスケジューリングされた場合、その会議の Web 会議は、MeetingPlace Video アプリケーションがインストールされた MeetingPlace Web サーバ上で行われます。

MCU の設定

Cisco Unified MeetingPlace ビデオ会議機能は、Cisco Unified Videoconferencing MCU と統合できます。MCU は、MeetingPlace がサードパーティ エージェントとして会議のスケジューリングと管理を制御することを許可するように設定されている必要があります。MCU の会議管理設定の中で、 External conference authentication policy が Authorize に設定されている必要があります。

着信コールは、次のいずれかの方法で MCU にルーティングできます。

• Cisco Unified CallManager 経由

Cisco Unified CallManager で、MCU サービス プレフィックスのルート パターンを MCU に直接ルーティングするように設定します（ゲートウェイとして定義）。

• ゲートキーパー経由

Cisco Unified CallManager で、MCU サービス プレフィックスのルート パターンをゲートキーパーへの H.225 トランクにルーティングするように設定します。

MCU からの発信コールでは、次の理由から常にゲートキーパーが必要です。

• MCU 上で定義された H.323 サービス コードは、発信者が会議にダイヤルインするときにコールがゲートキーパーにルーティングされるように、ゲートキーパーに登録されている必要があります。

• ゲートキーパーはアドレス解決のために必要です。MCU 自体は H.323 ビデオ端末からのアドレスを解決しないためです。

MCU は、ゲートウェイまたは MCU としてゲートキーパーに登録できます（図14-11 を参照）。通常、MCU はゲートウェイとして登録されますが、MeetingPlace の場合は、MCU を MCU として登録してください。MCU をゲートウェイではなく MCU として登録すると、MCU の動作が端末に近くなり、サービス プレフィックスが E.164 番号としてゲートキーパーに登録されます。

図14-11 MCU をゲートキーパーに登録する 2 つの方法

MeetingPlace に使用する MCU には、一意のサービス コード（プレフィックス）を設定する必要があります。プロトコルは、H.323 にする必要があります。サービス プレフィックスは、ビデオ会議コールが MCU にルーティングされるように、Cisco Unified CallManager のルート パターンで設定されたプレフィックスと同じにする必要があります。詳細については、「ビデオ会議のコール フロー」を参照してください。

MeetingPlace Video では、少なくとも 1 つの会議ビューが、指定されたサービス コードになっている必要があります。また、そのビューは単一パネルのビューの必要があります。管理者は、Voice-Activated（VA; 音声起動）と Continuous-Presence（CP; 連続表示）の表示モードを切り替える MeetingPlace Web オプションを利用できるように、2 番目のビューを提供できます（CP モードを実行する場合は、Enhanced Media Processor モジュールを使用することをお勧めします）。2 番目のビューは、マルチパネル ビューの必要があります。

Enhanced Media Processor（EMP）の要件

Cisco Unified Videoconferencing Enhanced Media Processor（EMP）は、強力な DSP リソース モジュールであり、MCU 上にインストールして、より複雑なコンピューティングと処理を行うことができます。EMP は、ほとんどのビデオ会議機能（H.323 の場合の Continuous-Presence または Voice-Activated）に必須のものではありませんが、最新の MeetingPlace Video ソフトウェアに高い品質を提供できるので、強くお勧めします。

SCCP ビデオ デバイス上で Continuous-Presence を実行するには、常に EMP が必須です。MCU から見ると、会議は SCCP 会議ではなく H.323 会議になります。

（注） MeetingPlace ビデオ統合は、Cisco Unified Videoconferencing MCU プラットフォーム上の速度整合モジュールと Data Collaboration Server をサポートしません。

ポート管理

MeetingPlace Video は、次のタイプのポートを提供します。

• ビデオ会議ポート

このポートは、MCU 上のサービス コードの設定に基づいて動的に割り当てられます。MeetingPlace Video はリソース（ビデオ ポートと会議の最大数）が MCU 内で変更されたかどうかを定期的に検証し、それに応じて MeetingPlace Audio Server を更新します。

• ビデオ フローティング ポート

このポートは、ビデオ会議ポートのプールから割り当てられます。システム管理者は、最初にスケジューリングされた以上の数のビデオ ポートを必要とする会議に、多数のビデオ ポートを予約できます。音声リンクを活用するには、最小数のフローティング ポートが必要です。このフローティング ポートの最小数を計算する公式は、次の Web サイトで入手可能な『 Administrator's Guide for Cisco Unified MeetingPlace Video Integration 』に記載されています。

http://www.cisco.com/univercd/cc/td/doc/product/conf/mtgplace/video/53/index.htm

• ビデオ過剰予約ポート

このポートは、物理的に存在しません。スケジュール済み会議では、予約されていても未使用のポートが存在するのが一般的であるという前提に基づいて、実際に使用可能な数よりも多くのポートをスケジューリングできるようにするために設定されるソフトウェア ポートです。このポートは物理的には存在しないので、設定可能な数に制限はありません。

スケジューリング

MeetingPlace ビデオ会議をスケジューリングできるのは、次のインターフェイスだけです。

• Web インターフェイス

• Outlook または Notes のインターフェイス

• MeetingTime

現在のところ、Voice User Interface はビデオ スケジューリング機能をサポートしていません。

ビデオ会議は、最初のビデオ参加者が会議に参加するまでセットアップされません。ユーザが会議に参加中に、ビデオ リソースを取得することはできません。会議は事前にスケジューリングされているか、予約なしの会議であることが必要です。

ビデオ会議は、MCU 上で定義された指定サービス コードを使用して作成されます。MeetingPlace ビデオ統合に許可されるサービス コードは 1 つだけです。そのサービス コードによって、すべての MeetingPlace ビデオ会議の動作とデフォルト パラメータが制御されます。

作成される個々の会議のダイヤルイン番号は一意で、次の形式になります。

指定サービス コード （MCU で設定） + 会議 ID （MeetingPlace が割り当て）

即時会議と予約なし会議のどちらも作成できます。

ビデオ会議への参加

ビデオ エンドポイントは、次のいずれかの方法で会議に参加できます。

• MeetingPlace からの発信ダイヤル

ユーザは最初に、MeetingPlace Web または MeetingPlace Outlook から会議に参加します。エンドポイント アドレスはユーザのプロファイルの一部であり、ビデオ エンドポイント アドレス ボックスに表示されます。次に、ユーザがクリックすることで、MeetingPlace がビデオ エンドポイントへ発信ダイヤルします。これは、ビデオ エンドポイントが会議に参加するための簡単な方法です。

• MCU へのダイヤル

ダイヤルする番号は、「スケジューリング」の項で説明している形式になります。この方法は、オーディオ専用エンドポイントでの一般的なユーザ操作と異なっています。MeetingPlace Audio Server へのダイヤルインとは異なり、ビデオ ユーザに対して会議 ID の入力が求められません。現在のところビデオ会議は認証を使用していないので、次の特性を持つ会議ではビデオ ダイヤルインが許可されません。

–パスワードの必要な会議

–招待専用またはプロファイル専用の会議（公開の誰でも参加できる会議以外）

これらのタイプの会議では、ユーザは MeetingPlace Web インターフェイスまたは Outlook から参加します。

ビデオ会議の場合のビデオ エンドポイントへの発信ダイヤリングは、自動ではありません。会議をスケジューリングするときにエンドポイントを定義できないためです。会議が開始された後で、ユーザはプロファイル（電話番号）をクリックして発信ダイヤルします。

会議のタイプ

すべてのビデオ会議は、次のいずれかのタイプを使用して毎回作成されます。

• 標準の予約済み会議またはスケジュール済み会議

• 連続会議

スケジュール済み会議と同様に、ビデオ会議は最初のビデオ ユーザが会議に参加すると作成されます。ビデオ会議は、会議全体（オーディオとビデオ）が MeetingPlace プラットフォームから打ち切られるまで終了しません。Audio Server と MCU との間の音声リンクは、最後のビデオ参加者が会議から切断してから 5 分後に終了します。

• 即時会議（予約なしの会議が有効でないシステム）

MeetingPlace で予約なしモードが有効にされていない場合でも、現在の会議数と使用中のビデオ ポート数が MCU 内のキャパシティを超えていない限り、ユーザは Web インターフェイスを介して即時タイプの会議を開始できます。

• 予約なしの会議

このタイプの会議では、事前にビデオ ポートが予約されません。ユーザは、使用可能なビデオ会議スロットとフローティング ポートがある限り、このタイプの会議に参加できます。予約なし会議の開始前にビデオ ユーザが参加した場合、対応するビデオ会議が作成されますが、会議の主催者がオーディオ側から会議に参加するまで、そのユーザは待合室に入れられます。待機モードの間、ユーザは互いに通信できず、会議がまだ開催されていないというメッセージがユーザに表示されます。

• 講義形式の会議

この会議には、話者と聴取者という 2 つのタイプの参加者が存在します。ビデオ ユーザは、参加すると常に聴取者として扱われ、実際には自分が話者としてスケジューリングされていても、自分自身を話者として有効にする手段を持ちません。講義形式の会議に話者として参加する唯一の方法は、ビデオ参加者ではなく、オーディオ参加者として会議に参加することです。話者は会議の開始時に、参加者を待合室に入れたり（消音になり、ビデオがブロックされる）、聴取者としたり（消音になるが、画像は表示できる）、オープン フロアにしたり（オーディオとビデオを使用してすぐに通信できる）することができます。

• マルチサーバ会議

「ビデオ会議のカスケード化」の章を参照してください。

ビデオ会議のコール フロー

最初のビデオ参加者が会議に参加すると、MeetingPlace Video は MCU への XML 制御チャネルを開き、オーディオ サーバから MCU への発信ダイヤルを開始し、オーディオ会議をビデオ会議に結合します。このリンクは、両方の会議でオーディオ参加者として動作します。

図14-12 は、最初の会議参加者がビデオ会議を開始したときに、音声リンクの作成に必要なプロセスを示しています。ユーザがビデオ会議を開始できるようにするには、事前に MCU がゲートキーパーに MCU として登録されている必要があります。また、MCU が Cisco Unified CallManager 内で H.323 ゲートウェイとして定義されていることも必要です。

図14-12 ビデオ会議の開始プロセス

図14-12 は、ビデオ会議開始プロセスの次の各ステップを示しています。

1. 最初のビデオ参加者が 8151234（1234 は MeetingPlace で作成された会議 ID）をダイヤルし、そのコールが Cisco Unified CallManager にルーティングされます。

2. Cisco Unified CallManager で、コールは H.323 ゲートウェイを指すルート パターン 815XXXX と一致し、そのゲートウェイは Cisco Unified CallManager で MCU を表すように定義されています。

3. コールは MCU にルーティングされます。

4. MCU は MeetingPlace Video に許可を送信し、会議と参加者の情報を検証します。

5. また、MCU は、新規に生成された会議番号（8151234）をゲートキーパーに追加 E.164 番号として登録します。

6. MeetingPlace Video は音声リンクを作成するように Audio Server に通知します。

7. Audio Server は 8151234（MCU）にダイヤルし、ビデオ会議に参加します。

8. コールは Cisco Unified CallManager に転送され、再びこの番号の同じルート パターンと一致して、コールがルーティングされます。

9. この Audio Server からのコールは MCU にルーティングされます。

10. Audio Server と MCU の間に音声リンクが作成されます。

11. 最初のビデオ参加者用のオーディオ ストリームとビデオ ストリームが、エンドポイントと MCU との間に確立されます。

2 番目以降のビデオ参加者の場合、コール フローはステップ 1、2、3、4、11 に従います。

ビデオ発信ダイヤリングの場合、要求は MeetingPlace Video Integration から MCU に渡されます（図14-14 を参照）。エンドポイントから MCU へのダイヤルインの場合、コール フローは通常のダイヤルイン ビデオ コールのフローと同じで、MeetingPlace はユーザ認証の確認だけに関係します（図14-15 を参照）。

図14-13 ビデオ会議の開始コール フロー（音声リンク作成）

図14-14 ビデオ会議の発信ダイヤリングのコール フロー

図14-15 ビデオ会議のダイヤルインのコール フロー

ビデオ会議のカスケード化

現在のところ、ビデオを MeetingPlace の実装内で複数の MCU にカスケード化することはできません。各種の MeetingPlace システムが音声リンクを介して互いに通信している場合は、さまざまな MeetingPlace Audio Server を同じ会議用にカスケードでき、そのような会議を マルチサーバ会議 と呼びます。マルチサーバ会議では、すべての参加者は プライマリ Audio Server に関連付けられた Web サーバに存在します。ビデオ参加者が発生する可能性があるのは、使用された Web サーバにビデオ統合がインストールされている場合です。

マルチサーバ会議の詳細については、次の Web サイトで入手可能な『 Administrator's Guide for Cisco Unified MeetingPlace Audio Server 』を参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/conf/mtgplace/index.htm

Cisco Unified CallManager での動的 H.323 アドレッシング

Cisco Unified CallManager 4.0 では、H.323 クライアントは静的 IP アドレスを使用して設定されます。Cisco Unified CallManager 4.1 以降では、E.164 アドレスを使用して H.323 クライアントを設定することもできます。E.164 アドレスを使用すると、H.323 クライアントが DHCP 用に設定されている配置の場合、H.323 クライアントの管理が簡単になります。E.164 アドレッシングは中継ゾーン ゲートキーパーと連携して動作し、中継ゾーン ゲートキーパーは、すべてのコールを outvia ゾーン（Cisco Unified CallManager ゾーン）内の Cisco Unified CallManager（IP-to-IP ゲートウェイとして動作）にルーティングするように設定できます。

このように設定すると、Cisco Unified CallManager は RasAggregator トランクと呼ばれる特殊なトランクを自動的に作成し、それをゲートキーパーに登録します。名前が表すとおり、このトランクは Registration Admission Status（RAS）に使用され、Cisco Unified CallManager で定義されたすべての動的アドレスを持つ H.323 デバイスを、同じゲートキーパーに登録された 1 つの集合デバイスとして管理するために使用されます。その H.323 デバイスが関連するコールが行われると、ゲートキーパーはこの RasAggregator トランク経由で Cisco Unified CallManager と通信します。

Cisco Unified CallManager 冗長性グループと H.323 クライアント

H.323 クライアントのデバイス プール内で定義される Cisco Unified CallManager 冗長性グループは、Cisco Unified CallManager を使用したコールに影響を与え、設定に誤りがあるとコール失敗の原因になるため重要です。冗長性グループの設定には、次の規則が適用されます。

• H.323 エンドポイントがゲートキーパーではなくピアツーピア モードを使用している場合は、Cisco Unified CallManager 上でその H.323 クライアント デバイス用の冗長性グループでのリストと同じ優先順位でサブスクライバを使用するように、その H.323 クライアントを設定する必要があります。

• それぞれの Cisco Unified CallManager 冗長性グループに対して、ゲートキーパーごとに一意のゾーンを設定する必要があります。

MCU の登録

MCU をゲートウェイとしてゲートキーパーに登録すると、そのサービス プレフィックス（たとえば 85）はテクノロジー プレフィックスとして登録されます。ゲートキーパーへの着信コールが、着信番号の中に一致するテクノロジー プレフィックスを持っている場合、ゲートキーパーは最初に中継ゾーン内で、その特定のプレフィックスを使用して登録された IP-to-IP ゲートウェイを検索します。したがって、H.323 エンドポイントが MCU にダイヤルインした場合（たとえば、851234 のアクセス コードを使用）、ダイヤルされた番号はテクノロジー プレフィックスの 85 と一致しますが、コールは失敗します。IP-to-IP ゲートウェイ（Cisco Unified CallManager）は、実際にはテクノロジー プレフィックス 1# を使用して登録されているためです。

テクノロジー プレフィックスとの不要な一致を避けるため、MCU をゲートウェイではなく MCU として登録することをお勧めします。MCU を MCU として登録するとテクノロジー プレフィックスが登録されないため、そのテクノロジー プレフィックスを使用して、ゲートキーパーが IP-to-IP ゲートウェイを検出することもなくなります。

また、MCU を会議 ID の登録を行うように設定することもお勧めします。これにより、会議 ID が作成されると必ず個々の E.164 番号がゲートキーパーに登録されるようになります。

MeetingPlace

MeetingPlace はゲートウェイに 1 つの端末として登録されるので、MeetingPlace H.323/SIP IP Gateway を 1 つのゾーンに、他のすべての H.323 ビデオ エンドポイントと共に配置することができます。Cisco Unified CallManager からの RasAggregator トランクも、その同じゾーンに登録されます。

Reservationless Single Number Access（RSNA）

Reservationless Single Number Access（RSNA）機能を使用すると、ユーザ コミュニティから複数の MeetingPlace Audio Server が 1 つのサーバとして見えるようにすることができます。この機能は、主に予約なしの会議用に設計されています。この機能を使用すると、ユーザは単一の電話番号にダイヤルすることで、1 つの場所に配置された複数の Audio Server にアクセスできます。ユーザがダイヤルインして予約なし ID を入力すると、システムはコールをその会議に適したサーバに転送します。この機能では、リモート ロケーションのユーザがローカル サーバにダイヤルすることもできます。

RSNA は、REFER メソッドをサポートする SIP エンドポイントに依存しています。Cisco Unified CallManager 5.0 は REFER をサポートしているため、RSNA を実装できます。以前のバージョンの Cisco Unified CallManager は、REFER や RSNA をサポートしていませんでした。

詳細については、次の Web サイトで入手可能な MeetingPlace の製品資料を参照してください。

http://www.cisco.com/en/US/products/sw/ps5664/ps5669/tsd_products_support_series_home.html

MeetingPlace Audio Server

MeetingPlace Audio Server に障害が発生すると、進行中のコールはドロップされます。Audio Server が MeetingPlace H.323/SIP IP Gateway から到達不能の場合、MeetingPlace H.323/SIP IP Gateway はすべての着信コールをすぐに拒否します。MeetingPlace H.323/SIP IP Gateway がダウンすると、Cisco Unified CallManager は MeetingPlace H.323/SIP IP Gateway との H.323 接続を確立できなくなります。MeetingPlace Audio Server には、利用可能な自動フェールオーバー メカニズムがありません。

障害回復

障害回復計画は、データベース、コンピューティング、およびサービスの順序正しい回復作業を規定したものです。通常、この計画では次のプロビジョニングを行います。

• 冗長性（ハードウェアの予備部品）

• データとソフトウェアのバックアップ

• 代替の緊急ロケーション

• 複数のサイトに分割された操作

MeetingPlace Network Backup Gateway と呼ばれるコンポーネントを使用すると、システム管理者は、MeetingPlace データベース（オーディオ設定ファイルとスケジューリングされた会議の情報）の複数のコピーを、Audio Server からネットワーク上の指定されたストレージ サーバに転送できます。各ファイルは、セキュリティのために暗号化されます。1 つのシステムあたり最大 3 台の Network Backup Gateway を実装できますが、データベースを転送できるのは一度に 1 台だけです。

冗長性

複数の MeetingPlace Audio Server が配置されている場合は、次のいずれかの冗長性計画を実装できます。

• シャドウ サーバ

シャドウ サーバとは冗長 MeetingPlace Audio Server のことで、プライマリ Audio Server に障害が発生するまでアクティブになりません。障害時には Command Line Interface（CLI; コマンドライン インターフェイス）を使用して、シャドウ サーバをシャドウ モードからアクティブ モードに切り替える必要があります。アクティブになったシャドウ サーバは、プロファイル情報、会議情報（過去、現在、および未来）、参加者情報など、限られた情報だけを格納できます。記録、添付ファイル、ハードウェアとネットワークの設定、および自動ソフトウェア アップグレードの各機能は使用できません。シャドウ サーバには、次のネットワーク接続要件があります。

–ラウンドトリップ遅延は 250 ms 未満である。

–パケット損失は 1% 未満である。

–最小帯域幅は 384 kbps である。

• デュアル会議サーバ

この計画では、2 台の MeetingPlace Audio Server がアクティブな実稼働サーバとなり、それぞれがもう一方にオーバーフローできます。プロファイルは、これらのサーバ間で Directory Service によって自動的に同期されます。2 台の Audio Server 間での自動フェールオーバーは 行われません 。緊急時には、会議をもう一方のサーバにアップロードする必要があり、ユーザは会議に手動で参加し直す必要があります。Cisco Unified CallManager では、1 台の MeetingPlace Audio Server に障害が発生したときに、コールがもう一方のアクティブな MeetingPlace Audio Server にルーティングされるように、ルート グループとルート リストを設定します。

• 連続会議サーバ

この計画では、事前に作成済みで常に利用可能な一連の重要な会議が、MeetingPlace Audio Server に実装されます。この配置には危機管理チームへのブラスト発信ダイヤルなどの機能があり、すべての危機管理アプリケーションに適しています。

MeetingPlace H.323/SIP IP Gateway

MeetingPlace H.323/SIP IP Gateway には、次のような冗長性とロード バランシングに関する考慮事項があります。

冗長性

MeetingPlace H.323/SIP IP Gateway に障害が発生すると、進行中のコールはドロップされます。

複数の MeetingPlace H.323/SIP IP Gateway を同じ MeetingPlace Audio Server に接続できます。ダイヤルイン冗長性は、次の方法で実装できます。

• すべての MeetingPlace H.323/SIP IP Gateway を Cisco Unified CallManager 上に設定し、同じルート グループに入れます。Cisco Unified CallManager と MeetingPlace H.323/SIP IP Gateway との間のリンクに障害が発生した場合、Cisco Unified CallManager は現行ルート グループでその次の MeetingPlace H.323/SIP IP Gateway を選択します。この方法はロード バランシングにも適用できます。

• すべての MeetingPlace H.323/SIP IP Gateway を特定のゾーンにある 1 つの H.323 ゲートキーパーに登録すると、そのゲートキーパーがフェールオーバーを処理できます。そのゲートキーパーで gw-priority を設定し、決められたプライオリティをそれぞれの MeetingPlace H.323/SIP IP Gateway で指定します。

発信ダイヤルの場合、MeetingPlace Audio Server は次のアルゴリズムを使用します。

• すべての MeetingPlace H.323/SIP IP Gateway が正しく機能し、発信ダイヤルの失敗がまったくない場合、Audio Server はビジー度の最も低いゲートウェイを発信ダイヤル用に選択し、ゲートウェイ間のロード バランシングが実現されます。

• いずれかの MeetingPlace H.323/SIP IP Gateway に障害がある場合、Audio Server はそのゲートウェイをスキップし、障害のない残りのゲートウェイ間でロード バランシングを行います。

• すべてのサーバが障害を起こしたことがある場合、Audio Server は障害発生時刻が最も古いサーバを選択し、そのゲートウェイで再び障害が発生するまで、そのゲートウェイを使用し続けます。

ロード バランシング

ダイヤルイン ロード バランシングには、冗長性の場合と同じ次の方法を使用できます。

• Cisco Unified CallManager でルート グループを使用しますが、Distribution Algorithm として Top down ではなく Circular を選択します。Cisco Unified CallManager は、発信コールをラウンドロビン方式でゲートウェイ間に分散します。

• ゲートキーパーを使用します。ロード バランシングのためには、優先ゲートウェイを指定する gw-priority を設定しないでください。その代わりに、ゲートキーパーがラウンドロビン方式で、コールをすべての登録済みゲートウェイに分散するようにしてください。

前の項で説明したように、発信ダイヤルのロード バランシングは、以前に発信ダイヤルに障害の発生したことがない MeetingPlace H.323/SIP IP Gateway 間でのみ行われます。

MeetingPlace Web

MeetingPlace Web には、次のような冗長性とロード バランシングに関する考慮事項があります。

冗長性

Web 会議中に Web 会議サーバで障害が発生した場合、すべてのユーザは会議の Web 部分から切断され、現行の Web 会議は続行不能になります。ユーザは、別のアクティブな Web サーバで Web 会議に参加し直すことができます。障害の発生したサーバ上に SQL サーバ データベースがある場合、クラスタ内のすべての Web 会議サーバが機能しなくなり、ユーザはデータベースが復元されるまで Web 会議を開催できなくなります。

ロード バランシング

MeetingPlace Web サーバをいくつかのクラスタにグループ化すると、会議要求をさまざまな Web サーバに分散するロード バランシングのパフォーマンスが向上し、処理できる会議数を増やすことができます。MeetingPlace Web クラスタには、最大で 6 つの Web サーバを内部構成または外部構成で含めることができます。

MeetingPlace WebConnect 機能を使用すると、単一の URL で複数の内部および外部 MeetingPlace システムを統合できます。複数の Audio Server にまたがるスケジューリングが可能です。最初の Audio Server に十分なキャパシティがない場合は、2 番目以降の Audio Server が順に試行されます。

Cisco Unified CallManager

Cisco Unified CallManager には、次のような冗長性とロード バランシングに関する考慮事項があります。

冗長性

Cisco Unified CallManager に障害が発生した場合、その Cisco Unified CallManager を使用した進行中の MeetingPlace コールはドロップされ、ユーザは会議に参加し直す必要があります。エンドポイントからのダイヤルインの場合、冗長性は Cisco Unified CallManager クラスタ内で設定された冗長性グループを使用して実現されます。

MeetingPlace H.323/SIP IP Gateway を通じた MeetingPlace からのアウトダイヤリングの場合、それぞれの MeetingPlace H.323/SIP IP Gateway が通信できるのは、1 つの Cisco Unified CallManager だけです。したがって、冗長性には次のガイドラインを適用できます。

• MeetingPlace H.323/SIP IP Gateway が、ゲートウェイとして直接、Cisco Unified CallManager と通信するように設定されている場合は、複数の MeetingPlace H.323/SIP IP Gateway を同じ MeetingPlace Audio Server に接続することが、冗長性を実装する唯一の方法です。

• MeetingPlace H.323/SIP IP Gateway がゲートキーパーに登録されている場合は、ゲートキーパーがフェールオーバーの状況を処理し、コールをアクティブな Cisco Unified CallManager にルーティングします。

ロード バランシング

エンドポイントから MeetingPlace へのダイヤルインの場合、コールのロード バランシングは Cisco Unified CallManager の冗長性グループとルート グループの設定によって実現されます。

MeetingPlace H.323/SIP IP Gateway を通じた MeetingPlace からのアウトダイヤリングの場合、冗長性の場合と同じガイドラインをロード バランシングにも適用できます。

MeetingPlace Video

MeetingPlace Video には、次のような冗長性とロード バランシングに関する考慮事項があります。

冗長性

MeetingPlace Video アプリケーションは、1 つの MeetingPlace 5.3 システムに 1 つだけ実装できます。MeetingPlace Video は、MeetingPlace Web 5.3 を実行しているサーバにインストールする必要があります。MeetingPlace Video は、1 つの MeetingPlace Web サーバとだけ通信します。

要求されたビデオ ポートで会議がスケジューリングされた場合、その会議の Web 会議は、MeetingPlace Video がインストールされた MeetingPlace Web サーバ上で行われます。そのサーバに障害が発生した場合、会議はサイトの管理 UI ページで設定された Load Stats Poll Period（デフォルトは 1 分間）の 5 倍の期間が経過した後、別のサーバにロール オーバーされます。ビデオ ポートがスケジューリングされた会議が別の Web サーバにロール オーバーした場合、GUI でビデオ機能は提供されません。ユーザは発信ダイヤルできなくなりますが、ダイヤルインは可能です。

ロード バランシング

MeetingPlace Video アプリケーションは、一度に 1 つしかアクティブにできないので、MeetingPlace Video にロード バランシングは存在しません。

MCU

現在のところ、MeetingPlace 5.3 ビデオ統合を使用した場合、1 つの MeetingPlace Audio Server あたり 1 つの MCU だけを実装できます。したがって、MCU に冗長性やロード バランシングはありません。