- このマニュアルについて
- 概要
- IP テレフォニー配置モデル
- ネットワーク インフラストラクチャ
- ゲートウェイ
- Cisco Unified CallManager トランク
- メディア リソース
- Music on Hold
- コール処理
- コール アドミッション制御
- ダイヤル プラン
- 緊急サービス
- サードパーティ製のボイスメール設計
- Cisco Unity
- Cisco Unified MeetingPlace の統合
- IP ビデオ テレフォニー
- LDAP ディレクトリ統合
- IPテレフォニー移行オプション
- 音声セキュリティ
- IP テレフォニー エンドポイント
- Cisco Unified CallManager アプリケーション
- 推奨されるハードウェアと ソフトウェアの組み合せ
- 用語集
- 索引
Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) Cisco Unified CallManager Release 5.0
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月5日
章のタイトル： IP ビデオ テレフォニー
IP ビデオ テレフォニー
シスコは、IP ビデオ テレフォニー ソリューションを Cisco Unified CallManager Release 4.0 で導入しました。ビデオは Cisco Unified CallManager に完全に統合され、シスコおよびシスコの戦略パートナーから多くのビデオ エンドポイントも入手できるようになりました。Cisco Unified Video Advantage は、Cisco Unified IP Phone と同様に、簡単に配置、管理、および使用できます。
IP ビデオ テレフォニー ソリューションのコンポーネント
Cisco IP ビデオ テレフォニー ソリューションは、Cisco Unified CallManager 5.0、H.323 電話会議と Skinny Client Control Protocol（SCCP）電話会議の両方に対応する Cisco Unified Videoconferencing 3500 シリーズ Multipoint Control Unit（MCU; マルチポイント コントロール ユニット）、Cisco Unified Videoconferencing 3500 シリーズ H.320 ゲートウェイ、Cisco IOS H.323 ゲートキーパー、Cisco Unified Video Advantage、Cisco IP Video Phone 7985、Sony 社製および Tandberg 社製の SCCP エンドポイント ソリューション、および Polycom、Tandberg、Sony などのパートナーが取り扱っている既存の H.323 または SIP 準拠製品で構成されます（図15-1 を参照）。
Cisco Unified CallManager 5.0 のビデオ機能拡張
Cisco Unified CallManager Release 4.0 は、ビデオ機能と IP Telephony を統合した最初のソフトウェア リリースです。Cisco Unified CallManager Release 5.0 では、IP ビデオ テレフォニーをサポートするために、次の項目についてさらに機能が拡張されています。
•
「プロトコル」
• 「ビデオ コールの MTP およびトランスコーダ サポート」
プロトコル
Cisco Unified CallManager Release 5.0 では、SIP トランクと SIP エンドポイントのビデオ サポートが導入されました。以前のバージョンの Cisco Unified CallManager では、SIP サポートはトランキングに限られ、ビデオはサポートされていませんでした。
Cisco Unified CallManager は、多くのプロトコルをサポートします。任意のデバイスから任意の別のデバイスを呼び出すことができますが、ビデオは SCCP、H.323、および SIP デバイスでのみサポートされます。具体的には、Cisco Unified CallManager Release 5.0 において、次のプロトコルではビデオがサポートされません。
• コンピュータ/テレフォニー インテグレーション（CTI）アプリケーション（TAPI および JTAPI）
• メディア ゲートウェイ コントロール プロトコル（MGCP）
したがって、現在 Cisco Unified CallManager でサポートされるコールのタイプは、 表15-1 に示すとおりです。
|
|
|
||||
|---|---|---|---|---|---|
|
|
|
|
|
|
|
表15-2 は、現在 Cisco Unified CallManager でサポートされている音声とビデオのアルゴリズムおよびプロトコルを示しています。
ビデオ コールの MTP およびトランスコーダ サポート
Cisco Unified CallManager Release 5.0 からは、パススルー コーデックを使用して、Cisco IOS Enhanced Media Termination Point（MTP）がビデオ コールをサポートするようになりました。パススルー コーデックを使用すると、Cisco Unified CallManager が動的に挿入した MTP またはトランスコーダによってビデオ コールのビデオ ストリームを終了できます。このとき、RTP ストリームをデコードする必要はありません。
トポロジ対応ロケーション
Cisco Unified CallManager Release 5.0 からは、ロケーション間のコールで使用できる帯域幅の量を制限する方式が 2 つになりました。Cisco Unified CallManager 4.0 では、ロケーションでのビデオ コールのサポートが導入されました。具体的には、Cisco Unified CallManager 4.0 および 4.1 のロケーション オプションによって、あるロケーションと別のロケーションの間のすべてのコールに許可される合計帯域幅が定義されます。この合計帯域幅の値は、従来のハブアンドスポーク ネットワーク トポロジに十分に対応します。Cisco Unified CallManager Release 5.0 では、リソース予約プロトコル（RSVP）に基づくトポロジ対応ロケーションを使用して、2 つのサイト間のパスに十分な帯域幅があるかどうかを判断する新しいオプションが用意されています。RSVP を使用すると、複雑なトポロジに対応するホップ単位のチェックが可能になり、RSVP アプリケーション ID を使用して音声帯域幅とビデオ帯域幅を個別にサポートできます。
（注） 静的ロケーションと RSVP ベースのロケーションは、異なるモデルを使用して、音声コールとビデオ コールを区別します。詳細については、「コール アドミッション制御」を参照してください。
RSVP ベースのロケーションでは、RSVP ポリシーの概念が採用されています。多くのポリシー オプションがありますが、主に次の 2 つのカテゴリに分けられます。
• コールを完了するために、ビデオ ストリームの RSVP 予約が必須。コールは失敗するか（ビジー トーンが再生され、「Bandwidth Unavailable」メッセージが表示される）、Automated Alternate Routing（AAR）によってコールの再ルーティングが試行されます。
最初に、リージョンに設定された音声コーデックとビデオ帯域幅で、ビデオ コールの最大速度（ビット レート）が定義されます。予約要求として、最大ビット レートを使用してコールのオーディオ ストリームとビデオ ストリームの RSVP 予約が Cisco RSVP Agent から送信されます。ビデオ ストリームの RSVP 予約が失敗した場合、Cisco Unified CallManager は RSVP ポリシーの設定をチェックし、このコールの処理方法を決定します。オーディオ ストリームのポリシーが省略可能な場合、コールは音声のみとして継続します。オーディオ ストリームの RSVP ポリシーが必須の場合は、オーディオ ストリームも RSVP 予約の取得に失敗した場合を除いて、コールは音声のみとして継続します。予約に失敗した場合、コールは失敗するか（ビジー トーンが再生され、「Bandwidth Unavailable」メッセージが表示される）、Automated Alternate Routing（AAR）によってコールの再ルーティングが試行されます（トポロジ対応ロケーションの詳細については、「コール アドミッション制御」を参照してください。
（注） ビデオ優先ポリシーを使用しているときに、ビデオ予約に失敗した場合、コールは音声のみとして完了します。ただし、ユーザはビデオが失敗した原因を示す、視覚的な表示または音声によるフィードバックを受けることができません。
Administration に関する考慮事項
この項では、ビデオ テレフォニーに関係する Cisco Unified CallManager Administration の次の構成要素について説明します。
• 「リージョン」
• 「ロケーション」
• 「Wait for Far-End to Send TCS」
リージョン
リージョンを設定するときは、Cisco Unified CallManager Administration の 2 つのフィールド、Audio Codec と Video Bandwidth を設定します。オーディオ設定ではコーデック タイプを指定し、ビデオ設定では許可する帯域幅の量を指定します。ただし、表記は異なりますが、Audio Codec フィールドと Video Bandwidth フィールドは、実際には似た機能を実行します。Audio Codec フィールドは、音声のみのコールおよびビデオ コールの音声チャネルに許可される最大ビットレートを定義します。たとえば、リージョンの Audio Codec を G.711 に設定した場合、Cisco Unified CallManager はそのリージョンの音声チャネルに許可される最大帯域幅として 64 kbps を割り当てます。この場合、Cisco Unified CallManager は G.711、G.722、G.728、または G.729 を使用するコールを許可します。ただし、Audio Codec を G.729 に設定すると、Cisco Unified CallManager は、音声チャネルに許可される帯域幅の最大量として 8 kbps だけを割り当てます。また、G.728、G.711、および G.722 はすべて 8 kbps より多く帯域幅を使用するため、G.729 を使用するコールだけが許可されます。
（注） 両方のエンドポイントが G.711 と G.722 をサポートしている場合、デフォルトで、G.722 がネゴシエートされます。
（注） Audio Codec 設定は、ビデオ コールの音声チャネルにも適用されます。
Video Bandwidth フィールドは、コールのビデオ チャネルに許可される最大ビットレートを定義します。ただし、従来のビデオ会議製品での慣例に従い、このフィールドに使用する値には、音声チャネルの帯域幅も含めます。たとえば、G.711 の音声を使用する 384 kbps のコールを許可するには、Video Bandwidth フィールドに 320 kbps ではなく 384 kbps を設定します。
つまり、Audio Codec フィールドは音声のみのコールおよびビデオ コールの音声チャネルに使用する最大ビットレートを定義し、Video Bandwidth フィールドは、ビデオ コールに許可される最大ビットレート（コールの音声部分を含む）を定義します。
各デバイスは、 表15-3 で示すように、特定の音声コーデックのみをサポートするため、正しい音声コーデックの帯域幅制限を選択することが重要です（特定のエンドポイントでサポートされるコーデックの最新リストについては、そのエンドポイントの製品マニュアルを参照してください）。
|
|
|
|
|
|
|
|---|---|---|---|---|---|
表15-3 で示すように、リージョンを G.729 に設定した場合、ビデオ会議デバイスによっては、このタイプのコーデックをサポートできないものがあります。たとえば、Cisco Unified Video Advantage エンドポイントと Tandberg 社製エンドポイントとの間のコールは失敗します。または、このコールに Cisco Unified CallManager が音声変換リソースを割り当てます。
Cisco Unified CallManager Release 5.0 では、Cisco IOS Enhanced Media Termination Point に基づく音声変換リソースが導入されました。これによって、パススルー コーデックによるビデオ ストリームのサポートを継続しながら、ビデオの音声ストリームのトランスコーディングができます。パススルー コーデックは、トランスコーディングが必要なストリームには使用できないため、ビデオ ストリームにのみ使用されます。パススルー コーデックを使用するには、次の 3 つの条件をすべて満たす必要があります。
• 2 つのエンドポイント デバイスのコーデック能力が一致している。
• どちらのエンドポイントでも、 MTP Required がオフになっている。
• すべての中間リソース デバイス（MTP およびトランスコーダ）がパススルー コーデックをサポートしている。
従来のトランスコーダは、現在、パススルー機能をサポートしていません。そのため、コールは音声のみとして接続され、G.729 と G.711 の間でトランスコーディングされます。Cisco IOS Enhanced Transcoder を使用せずにこの状態を防止するには、G.711 を使用するようにリージョンを設定する必要があります。ただし、G.711 に設定されたリージョンは、2 つの IP Phone 間の音声コールにも G.711 を使用します。この場合、WAN で消費される帯域幅が増えます。
帯域幅を節約するために音声のみのコールに G.729 を使用し、ビデオ コールに G.711 を使用する場合は、G.729 をサポートしないビデオ エンドポイント用に G.711 を使用するリージョンを設定し、IP Phone 用に G.729 を使用する別のリージョンを設定する必要があります（図15-2 を参照）。この方式を使用すると、必要なリージョンの数が増えますが、望ましいコーデックと帯域幅の割り当てが得られます。
図15-2 ビデオ コールに G.711 を使用し、音声のみのコールに G.729 を使用
（注） ビデオを禁止するリージョンのペアを設定できます。このリージョン ペアにある 2 つのビデオ対応デバイスが相互に通話しようとした場合、Retry Video Call as Audio がオンになっていれば、音声のみとして接続されます。オフになっている場合は、AAR 再ルーティング ロジックが実行されます。
表15-4 は、設定例とその結果を示しています。
|
|
Audio の設定 |
|
|---|---|---|
AAR が設定されていない場合、ビデオ コールは失敗する（ビジー トーンが再生され、「Bandwidth Unavailable」メッセージが表示される）。 |
Video Bandwidth フィールドには、1 ～ 8128 kbps の値を指定できます。ただし、H.323 および H.320 ビデオ会議デバイスとの互換性を維持するために、このフィールドには常に、56 または 64 kbps の倍数の値を入力することをお勧めします。したがって、このフィールドの有効な値としては 112 kbps、128 kbps、224 kbps、256 kbps、336 kbps、384 kbps などがあります。
エンドポイントで要求されるコール速度がリージョンに設定されている帯域幅値を超えた場合、Cisco Unified CallManager は自動的に、リージョン設定で許可された値に適合するようにコールをネゴシエートします。たとえば、H.323 エンドポイントが別の H.323 エンドポイントを 768 kbps で呼び出しているが、リージョンは最大 384 kbps を許可するように設定されていたとします。発信側からの着信 H.225 セットアップ要求はコール速度として 768 kbps を提示しますが、Cisco Unified CallManager は、着信側への発信 H.225 セットアップ メッセージで、この値を 384 kbps に変更します。そのため、着信側エンドポイントは、開始するコールが 384 kbps であると認識し、このレートでコールがネゴシエートされます。発信側エンドポイントは、要求した帯域幅として 768 kbps を提示しますが、ネゴシエートされた帯域幅は 384 kbps になります。
ただし、リージョンの Video Bandwidth を「None」に設定した場合は、着信側デバイスの Retry Video Call as Audio が有効かどうかに応じて、Cisco Unified CallManager はコールを終了するか（この場合、H.225 Release Complete メッセージを発信側に送信）、音声のみのコールとして通過を許可します（「Retry Video Call as Audio」を参照）。
ロケーション
静的ロケーションを設定するときも、Cisco Unified CallManager Administration の 2 つのフィールド、Audio Bandwidth と Video Bandwidth を設定します。ただし、リージョンと異なり、静的ロケーションの Audio Bandwidth は音声のみのコールにのみ適用され、Video Bandwidth はビデオ コールの音声チャネルとビデオ チャネルの両方に適用されます。音声帯域幅とビデオ帯域幅は、別々に維持されます。これは、両方のタイプのコールが帯域幅の単一割り当てを共有すると、音声コールが使用可能な帯域幅のすべてを使用してビデオ コール用の帯域幅が残らなくなる（または、その逆になる）可能性が高いためです。また、音声とビデオの個別の帯域幅プールは、ネットワーク上のスイッチおよびルータでのキューの設定方法に対応します。通常、音声トラフィック用のプライオリティ キューと、ビデオ トラフィック用の独立したプライオリティ キューまたはクラスベース WFQ があります。詳細については、「WAN の QoS」を参照してください。
Audio Bandwidth フィールドと Video Bandwidth フィールドのどちらにも、None、Unlimited、または数値を指定する 3 つのフィールドがあります。ただし、これらのフィールドに入力する値は、2 つの異なる計算モデルを使用します。Audio Bandwidth フィールドに入力する値には、コールに必要なレイヤ 3 ～ 7 のオーバーヘッドを含める必要があります。たとえば、ロケーションとの間で単一の G.729 コールを許可する場合は、値として 24 kbps を入力します。G.711 コールの場合は、値として 80 kbps を入力します。一方、Video Bandwidth フィールドには、オーバーヘッドを含めない値を入力する必要があります。たとえば、128 kbps コールの場合は 128 kbps を入力し、384 kbps コールの場合は 384 kbps を入力します。リージョンの Video Bandwidth フィールドで使用する値と同様に、ロケーションの Video Bandwidth フィールドにも、56 kbps または 64 kbps の倍数の値を使用することをお勧めします。
たとえば、企業に 3 サイトのネットワークがあるとします。San Francisco ロケーションには、San Jose メイン キャンパスに接続された 1.544 Mbps T1 回路があります。システム管理者は、このロケーションとの間で、4 つの G.729 音声コールと 1 つの 384 kbps（または 2 つの 128 kbps）ビデオ コールを許可します。Dallas ロケーションには、San Jose メイン キャンパスに接続された 2 つの 1.544 Mbps T1 回路があります。管理者は、このロケーションとの間で、8 つの G.711 音声コールと 2 つの 384 kbps ビデオ コールを許可します。この例で、管理者は、San Francisco ロケーションと Dallas ロケーションに次の値を設定します。
|
|
|
|
|
|
エンドポイントで要求されるコール速度がロケーションに設定されている値を超えた場合、リージョンの場合とは異なり、Cisco Unified CallManager はロケーション設定で許可された値に適合するように、自動的にはコール速度をネゴシエートしません。コールは拒否されるか、音声のみのコールとして再試行されます（着信側デバイスで Retry Video as Audio 設定が有効の場合）。そのため、リージョンのビデオ帯域幅は、ロケーションのビデオ帯域幅の値よりも低い値に設定する必要があります。たとえば、2 つのリージョン（リージョン A とリージョン B）があり、これら 2 つのリージョン間のビデオ帯域幅が 768 kbps に設定されている場合、リージョン A のデバイスがビデオ帯域幅が 384 kbps に設定されているロケーションにあると、これら 2 つのリージョン間のすべてのコールが失敗するか、音声のみのコールになります（Retry Video Call as Audio の設定による）。
Retry Video Call as Audio
このチェックボックスは、Cisco Unified IP Phone 7940、7941、7960、7961、7970、7971、および Cisco IP Video Phone 7985、Sony 社製または Tandberg 社製の SCCP エンドポイント、すべての H.323 および SIP デバイス（クライアント、ゲートウェイ、およびすべてのタイプの H.323 トランク）など、ビデオをサポートするすべてのエンドポイント タイプで使用できます。このオプションがアクティブ（オン）のときに、デバイスに到達できるだけの帯域幅がない場合（たとえば、Cisco Unified CallManager リージョンまたはロケーションで、そのコールのビデオが許可されない場合）、Cisco Unified CallManager はそのコールを音声のみのコールとしてリトライします。このオプションが非アクティブ（オフ）のときは、Cisco Unified CallManager はコールを音声のみとして再試行することなく、コールを失敗させるか、Automated Alternate Routing（AAR; 自動代替ルーティング）パスが設定されている場合は可能な限り再ルーティングします。デフォルトでは、このリトライ オプションは有効（オン）です。
• ビデオを許可しないようにロケーションが設定されている。または、要求されたビデオ速度が、そのロケーションで使用可能なビデオ帯域幅を超えている。
• Cisco Unified CallManager クラスタ間のコールの場合、要求されたビデオ速度がゲートキーパーのゾーン帯域幅制限を超えている。
Retry Video Call as Audio オプションは、終端（着信側）デバイスでのみ有効です。そのため、発信側デバイスでは宛先ごとに異なるオプション（再試行または AAR）を使用できる柔軟性があります。
帯域幅の制限が原因でビデオ コールが失敗した場合、自動代替ルーティング（AAR）が有効であれば、Cisco Unified CallManager は失敗したコールをビデオ コールとして AAR の宛先に再ルーティングしようとします。AAR が有効でない場合、失敗したコールによって、発信者にビジー トーンとエラー メッセージが送信されます（図15-3 を参照）。発信側のデバイスのタイプによって、失敗したコールは次のいずれかになります。
• 発信側デバイスが LCD 画面付き SCCP エンドポイントの場合（Sony 社製または Tandberg 社製の SCCP エンドポイント、Cisco Unified IP Phone の多くのモデルなど）、発信者にはビジー トーンが聞こえ、メッセージ「Bandwidth Unavailable」がデバイスに表示されます。
• 発信側デバイスが LCD 画面なしの SCCP エンドポイントの場合（Cisco Unified IP Phone 7902 など）、発信者にはビジー トーンが聞こえます。
• 発信側デバイスが H.323 または SIP デバイス、またはゲートウェイで接続された公衆網デバイスの場合、発信者にはビジー トーンが聞こえ、Cisco Unified CallManager が適切なエラー メッセージ（Q.931 Network Congestion 原因コードなど）を H.323、SIP、または MGCP デバイスに送信します。
AAR の使用方法の詳細については、「コール アドミッション制御」の章を参照してください。
図15-4 は、非ゲートキーパー制御クラスタ間トランクを使用する、2 つのクラスタ間のコールの手順を示しています。
図15-4 非ゲートキーパー制御クラスタ間トランクを使用する 2 つのクラスタ間のコール フロー
Wait for Far-End to Send TCS
このチェックボックスは、H.323 クライアント、H.323 ゲートウェイ、H.225 ゲートキーパー制御トランクなど、すべての H.323 デバイスで使用できます。この機能は、H.323 コールの H.245 機能交換フェーズに関係します。この機能を有効にすると、Cisco Unified CallManager は、Cisco Unified CallManager が Terminal Capabilities Set（TCS; 端末機能セット）を H.323 デバイスに送信する前に、リモート H.323 デバイスが TCS を Cisco Unified CallManager に送信するまで待機します。このオプションが無効の場合、Cisco Unified CallManager は待機せず、すぐに TCS をリモート H.323 デバイスに送信します。
デフォルトでは、Wait for Far-End to Send TCS オプションが有効（オン）です。ただし、次の場合はオフ（無効）にする必要があります。
• Cisco Unified CallManager と通信する H.323 デバイスも、遠端が TCS を送信するまで待機する。
この場合、どちらの側も TCS を送信しないためデッドロックが発生し、数秒後に H.245 接続がタイムアウトします。遠端が TCS を送信するまで待機するデバイスの例としては、一部の H.323 ルーテッドモード ゲートキーパー、H.320 ゲートウェイ、H.323 プロキシ（IP-to-IP ゲートウェイ）、一部の H.323 マルチポイント コンファレンス ブリッジがあります。これらのデバイスが遠端からの TCS の送信を待機する理由は、Cisco Unified CallManager が待機する理由と同じです。TCS を他方に転送する前に、接続の両端が TCS を送信するまで待機するためです。
• クラスタ間トランクを介して別の Cisco Unified CallManager クラスタと通信している。
（注） クラスタ間トランクおよびゲートキーパー制御クラスタ間トランクでは、Wait for Far-End to Send TCS オプションは常に無効で、有効にすることはできません。
多くのシナリオで、Cisco Unified CallManager は、2 つのエンドポイント デバイス（相互に通話しようとする 2 つのクライアントなど）を接続するソフトウェア スイッチの役割を実行します。このような場合、両方のデバイスが TCS メッセージを送信するまで Cisco Unified CallManager が待機することが最良です。Cisco Unified CallManager が各デバイスの機能を認識することで、それぞれに送信する TCS に関して（特に、リージョンおよびロケーションの設定に応じて）最適な判断ができます。この場合、Wait for Far-End to Send TCS 機能は有効にする必要があります。
ただし、その他の H.323 デバイス（H.323 デバイスを H.320 デバイスに接続する H.320 ゲートウェイなど）が、複数の参加者を接続する機能を実行することもあります。また、ゲートウェイも、コールのセットアップ方法に関して最適な選択ができるように、両端が TCS メッセージを送信するまで待機します。Cisco Unified CallManager とゲートウェイの両方が、相手側から TCS が送信されるまで待機すると、デッドロックが発生します。このデッドロック状態を防止するには、Wait for Far-End to Send TCS 機能を無効（オフ）にします。
たとえば、図15-5 で示す次のコール シナリオについて考えます。
• シナリオ 1：Cisco Unified Video Advantage が H.320 エンドポイントを呼び出す。
• シナリオ 2：H.323 クライアントが H.320 エンドポイントを呼び出す。
これらのシナリオでは、どちらの場合も、Wait for Far-End to Send TCS 機能は、デフォルト設定である有効（オン）のままにします。
図15-5 Wait for Far-End to Send TCS 機能が有効（オン）のシナリオ
図15-5 のシナリオ 1 では、登録時に SCCP デバイスがメディア機能を Cisco Unified CallManager に提供しているため、Cisco Unified CallManager はすでに Cisco Unified Video Advantage クライアントの機能を認識しています。しかし、ゲートウェイがコールの H.245 フェーズで TCS を Cisco Unified CallManager に送信するまで、Cisco Unified CallManager は H.320 ゲートウェイの機能を認識しません。同様に、H.320 エンドポイントが TCS をゲートウェイに送信するまで、H.320 ゲートウェイは、Cisco Unified CallManager に送信する TCS を判断できません。この場合、H.320 エンドポイントがゲートウェイに TCS を送信し、ゲートウェイが Cisco Unified CallManager に TCS を送信し、判断に使用できる両端のエンドポイントからの TCS を Cisco Unified CallManager が受信するため、Wait for Far-End to Send TCS 機能は有効のままにしておく方が適切です。
図15-6 は、次のコール シナリオを示しています。これらのシナリオでは、Wait for Far-End to Send TCS 機能を無効にしないとコールが失敗します。
• シナリオ 1：Cisco Unified Video Advantage が、ISDN ネットワークを介してリモート クラスタにある別の Cisco Unified Video Advantage を呼び出す。
• シナリオ 2：H.323 クライアントが、ISDN ネットワークを介してリモート クラスタにある別の H.323 クライアントを呼び出す。
図15-6 Wait for Far-End to Send TCS 機能が無効（オフ）のシナリオ
図15-6 のどちらのシナリオでも、両方の Cisco Unified CallManager がゲートウェイから TCS を受信するまで待機し、両方のゲートウェイも ISDN 側からの TCS を受信するまで待機するため、デッドロックが発生します。コールは数秒後にタイムアウトし、失敗します。ユーザから見ると、発信者にはコールが進行中であることを示すリングバック トーンが聞こえ、着信側には着信コールを示す呼び出し音が聞こえます。着信側がコールに応答しようとすると、デッドロックのために H.245 フェーズが失敗し、コールは両方で切断されて失敗します。
このようなシナリオの問題の回避策としては、Cisco Unified CallManager で H.320 ゲートウェイを表すデバイスで、Wait for Far-End to Send TCS オプションを無効（オフ）にすることをお勧めします。H.320 ゲートウェイに到達するように Cisco Unified CallManager を設定した方法に応じて、このデバイスは H.225 ゲートキーパー制御トランクまたは H.323 ゲートウェイ デバイスになります。
ただし、Wait for Far-End to Send TCS オプションを無効にすると、交換された初期機能がリモート デバイスで機能しなくなることがあります。たとえば、Cisco Unified CallManager リージョンが 768 kbps ビデオに設定されていても、H.320 デバイスが 384 kbps しかサポートしないことがあります。また、選択された音声コーデックがリモート側で機能しないことがあります。この場合、初期ネゴシエートされた論理チャネルを切断し、正しい速度とコーデックで再開する必要があります。多くのレガシー H.323 および H.320 デバイスは、この状態を正しく処理せず、Cisco Unified CallManager が CloseLogicalChannel メッセージを送信して異なる値でチャネルと再ネゴシエートすると、コールを切断します。そのため、Wait for Far-End to Send TCS オプションを無効にする場所とタイミングには注意が必要です。
マルチポイント会議
3 者以上が同じビデオ コールに同時に参加するには、マルチポイント コントロール ユニット（MCU）が必要です。MCU は、次のメイン コンポーネントで構成されています。
MC は、メディア ネゴシエーション、コール シグナリング、コールに使用する MP の選択など、会議のコール セットアップと切断のすべての面を処理します。MP は、すべての音声パケットおよびビデオ パケットを処理します。MC が MP を制御し、1 つの MC で複数の MP を制御できます。MP は、ソフトウェアベースのものも、ハードウェアベースのものもあります。ソフトウェアベースの MP は、通常、高度なトランスコーディング、レート変換（複数の速度）、構成機能は実行できません。
1999 年以降、シスコは IP/VC 3500 シリーズ H.323 Multipoint Conference Unit（MCU）を提供してきました。このファミリの最初の製品は、Cisco Unified Videoconferencing 3510 です。このモデルは販売終了となり、Cisco Unified CallManager との互換性もありません。2002 年に、シスコは IP/VC 3511 および 3540 モデルを導入しました。これらのモデルは大幅に機能が改善され、古い 3510 モデルにはなかったスケーラビリティが実現されました。
2003 年、シスコは IP/VC 3511 および 3540 モデルにソフトウェア バージョン 3.2+ を導入し、Skinny Client Control Protocol（SCCP）のサポートを追加しました。SCCP サポートは、IP/VC 3510 では使用できません。また、IP/VC MCU では、次の 3 つのタイプの MP が使用できます。
• Rate Matching（RM）モジュール（IP/VC 3540 シャーシ専用のソフトウェアベースのモジュール）
• Enhanced Media Processor（EMP）（IP/VC 3540 シャーシ専用のモジュールまたは IP/VC 3511 モデルの内蔵コンポーネントとして使用できるハードウェアベースのソリューション）
Cisco Unified CallManager Release 4.0（およびそれ以降）は、SCCP、H.323、および SIP の各モードで IP/VC 3511 と 3540 モデルをサポートします。各プロトコルにはさまざまな機能が用意され、さまざまな理由で使用されます。そのため、3 つのプロトコルすべてを実行するように、これらの各 MCU が搭載されています。IP/VC 3511 は、SCCP モードまたは H.323 および SIP モードで実行するように設定できます。IP/VC 3540 モデルは、3 つのプロトコルすべてを同時に実行し、使用可能な MP リソースの合計数を 3 つの間で分け合うように設定できます。
シグナリング プロトコルに関係なく、MCU は、音声ストリームとビデオ ストリームを各参加者から受信し、これらのストリームをすべての他の参加者に、組み合せたビューで送信するという同じ基本機能を提供します。マルチポイント テレビ会議のビューには、次の 2 つのタイプがあります。
Voice-Activated 会議は、すべての参加者の音声ストリームとビデオ ストリームを取得し、主要な発言者を決定し、主要な発言者のビデオ ストリームだけをすべての他の参加者に送信します。参加者には、主要な発言者の全画面イメージが表示されます（現在の発言者には、前の主要な発言者が表示されます）。すべての参加者からの音声ストリームが混合され、全員が他の全員の発言を聞くことができますが、ビデオは主要な発言者のものだけが表示されます。
このモードを使用すると、MCU は、最も声が大きく、発言が長い会議参加者を判断して、主要な発言者を自動的に選択します。声の大きさを判断するために、MCU は各参加者の音声信号の強さを計算します。会話中に条件が変わると、MCU は自動的に新しい主要な発言者を選択し、その参加者が表示されるようにビデオを切り替えます。ホールド タイマーによって、ビデオの頻繁な切り替えが防止されます。主要な発言者になるには、指定された秒数以上発言し、他のすべての参加者よりも際立つ必要があります。
• MCU の Web ベースの会議制御ユーザ インターフェイスによる主要な発言者の手動選択
会議コントローラ（議長）は MCU の Web ページにログオンし、参加者を強調表示することで、その参加者を主要な発言者として選択できます。この処理によって音声アクティビティ検出は無効になり、議長が新しい主要な発言者を選択するか、Voice-Activated モードを再度有効にするまで、主要な発言者は固定されます。
• 参加者リストを自動的に 1 人ずつ循環するように MCU を設定
この方式を使用すると、MCU は設定された時間だけ各参加者で止まり、リスト上の次の参加者に切り替えます。会議コントローラ（議長）は、Web インターフェイスでこの機能をオンまたはオフにできます（オフにすると、Voice-Activated モードが再度有効になります）。
Continuous-Presence 会議では、一部の参加者またはすべての参加者が合成ビューで同時に表示されます。ビューには 2 ～ 16 の長方形（参加者）をさまざまなレイアウトで表示できます。各レイアウトには、長方形の 1 つを Voice-Activated にする機能があり、合成ビューに表示できる長方形の数よりも参加者の方が多い会議で役立ちます。たとえば、4 画面のビューを使用していて、コールの参加者が 5 人のとき、同時に表示される参加者は 4 人だけです。この場合、長方形の 1 つを Voice-Activated にすると、主要な発言者に応じて参加者 4 と参加者 5 をその長方形で切り替えることができます。他の 3 つの長方形に表示される参加者は固定で、すべての長方形は、会議制御 Web ベース ユーザ インターフェイスで操作できます。
（注） Continuous-Presence には、IP/VC MCU の Enhanced Media Processor（EMP）が必要です。
どちらのタイプの会議でも、MP リソースによって、MCU がサポートできるビデオ形式、トランスレーティング、およびトランスコーディング機能が決まります。エンドポイントが異なる速度で会議に接続している場合は、レート変換対応 MP が必要です。RM モジュールと EMP モジュールは、どちらも速度間のレート変換に対応しています。レート変換対応 MP が使用できない場合、MCU はすべてのエンドポイントにフローコントロール メッセージを送出し、最も遅いエンドポイントの最大受信レートに合せて転送速度を下げるように指示します。たとえば、3 人の参加者が 384 kbps の会議に接続し、4 番目の参加者が 128 kbps で参加した場合、MCU は他の 3 人の参加者にフローコントロール メッセージを送信し、128 kbps の参加者に合せて転送速度を下げるように指示します。この方式を使用すると、1 人の参加者の性能が低いことで、すべての参加者の品質が低下します。レート変換対応 MP を使用した場合、128 kbps のストリームが 384 kbps に（および、その逆に）変換され、各参加者がそれぞれの接続で許可される最大の品質を使用できます。
Continuous-Presence 会議でも、レート変換対応 MP は非常に重要です。MCU に内蔵されたソフトウェアベースの MP は、すべての入力ストリームを組み合せ、得られた組み合せを各参加者に送信します。たとえば、4 人の参加者が 384 kbps で G.711 音声を使用して Continuous-Presence 会議に接続している場合、各参加者は 320 kbps のビデオと 64 kbps の音声を MCU に転送します。MCU は 4 つの入力ビデオ ストリームを取得し、4 画面の合成ビューに組み合せます。MCU は混在する 64 kbps の音声と共に、1280 kbps のビデオを各エンドポイントに転送します。その結果、エンドポイントごとに合計 1344 kbps になります。この方式は Asynchronous Continuous Presence と呼ばれ、帯域幅要件、コール アドミッション制御メカニズム、一部のデバイスとの相互運用性に悪影響を与えることがあります。
（注） Asynchronous Continuous Presence は使用しないことを強くお勧めします。
RM モジュールまたは EMP モジュールを使用すると、MCU は各入力ストリームを組み合せる前に、合計出力帯域幅が入力帯域幅と一致するようにレート変換できます。たとえば、MCU が 4 画面のレイアウトを使用し、各参加者が 320 kbps のビデオと 64 kbps の音声を MCU に転送する場合、MCU は原則として各入力ストリームを 80 kbps にレート変換し、4 画面のビューが 320 kbps のビデオになるように組み合せ（4 ∗ 80 kbps）、混合された 64 kbps 音声とこのビデオを組み合せて、最終的な組み合せを各参加者に転送します。この方式は、Synchronous Continuous Presence と呼ばれます。すべての Continuous-Presence 会議で、Synchronous Continuous Presence モードを使用することを強くお勧めします。ただし、このモードを使用するには、各 MCU にレート変換対応 MP（RM、EMP など）が必要で、MCU のコストが上がります。
（注） MCU が内蔵された H.323 および SIP クライアントの場合、Cisco Unified CallManager は、H.323 クライアントで第 2 のコールの生成を許可しません。そのため、内蔵 MCU の機能は無効になります。
SCCP MCU リソース
すでに説明したように、Cisco Unified Videoconferencing 3511 および 3540 MCU はどちらも、これらのモデルのソフトウェア バージョン 3.2+ および Cisco Unified CallManager Release 4.0 から SCCP をサポートしています。SCCP モードで設定すると、Cisco Unified CallManager が MC 機能を提供し、MCU が MP 機能を提供します。SCCP MCU は、Cisco Unified CallManager で完全に制御されます。
SCCP MCU リソースを呼び出すのは、次のイベントだけです。
• SCCP エンドポイント（IP Phone や Tandberg 社製エンドポイントなど）のユーザが、Conf、Join、または cBarge ソフトキーを押して Ad-Hoc 会議を呼び出した。
• SCCP エンドポイント（IP Phone や Tandberg 社製エンドポイントなど）のユーザが、MeetMe ソフトキーを押して、予約なしの Meet-Me 会議を呼び出した。
これらのタイプの会議の参加者には、任意のタイプのエンドポイント（サポートされる任意のゲートウェイ タイプを介して Cisco Unified CallManager がサポートする任意のシグナリング プロトコルを使用するビデオ デバイスおよび非ビデオ デバイス）が含まれます。ただし、SCCP MCU リソースを呼び出せるのは、SCCP エンドポイントだけです。つまり、H.323 ビデオ エンドポイントは SCCP MCU リソースを呼び出せませんが、SCCP ビデオ エンドポイントがリソースを呼び出し、H.323 ビデオ参加者をコールに参加させることはできます。たとえば、SCCP エンドポイントのユーザは、Conf ソフトキーを押し、H.323 クライアントのディレクトリ番号をダイヤルして、もう一度 Conf ソフトキーを押すと、トランザクションを完了できます。H.323 クライアントは、参加者として SCCP MCU 会議に参加します。
ただし、Conf、Join、または cBarge ソフトキーで開始された Ad-Hoc 会議の場合、他の参加者が使用するシグナリング プロトコルは、保留機能および MCU に音声チャネルとビデオ チャネルを転送する機能をサポートしている必要があります。H.323 デバイス（H.323 クライアント、H.323 ゲートウェイ、H.320 ゲートウェイ、およびすべてのタイプの H.323 トランク）の場合、Cisco Unified CallManager は、H.245 仕様で定義されている Empty Capabilities Set（ECS）方式を使用してこの機能を実現しています。H.323 エンドポイントが Cisco Unified CallManager からの ECS メッセージの受信をサポートしていない場合、切断されるか、クラッシュしてリブートする可能性もあります。この問題の回避策としては、H.323 デバイスで「MTP Required」オプションを有効（オン）にして、MTP デバイスを含まないメディア リソース グループ リスト（MRGL）をこのデバイスに割り当て、Cisco CallManager のサービス パラメータ「Fail Call if MTP Allocation Fails」を False に設定します（詳細については、「メディア リソース グループとメディア リソース グループ リスト」を参照してください）。この設定を行うと、電話機のソフトキーはグレーアウトされます。ユーザはこのエンドポイントで、保留、既存のコールとの会議、既存のコールへの参加、このエンドポイントを含む既存のコールへの割り込みなど、補足サービスを呼び出せなくなります。
（注） ここで説明した回避策には MTP デバイスを含まない MRGL が必要になるため、RSVP ベースのコール アドミッション制御を使用している場合、この回避策は使用できません。
MeetMe ソフトキーによる予約なしの会議の場合は、他のエンドポイントで使用されているシグナリング プロトコルが保留および転送をサポートしている必要はありません。これらのタイプの会議では、各エンドポイントが、会議を開始した SCCP クライアントで割り当てられた MeetMe ダイヤルイン番号をダイヤルします。
図15-7 は、H.323 エンドポイントと SCCP エンドポイントを同じ SCCP 会議に参加させる方法を示しています。この例では、SCCP エンドポイントで Conf ソフトキーによって会議が開始され、3 人のメンバーが招待されています。
図15-7 SCCP エンドポイントと H.323 エンドポイントの間の Ad-Hoc 会議
SCCP 会議は、Voice-Activated モードと Continuous-Presence をサポートします。さらに、SCCP 会議は、MCU に内蔵されたソフトウェアベースの MP、Rate Matching（RM）モジュール、および Enhanced Media Processor（EMP）モジュールをサポートします。
メディア リソース グループとメディア リソース グループ リスト
Cisco Unified CallManager は、メディア リソース グループ（MRG）とメディア リソース グループ リスト（MRGL）を使用して、指定されたエンドポイントに使用するコンファレンス ブリッジ リソースを決定します。リソースをグループ化する方法は完全に自由ですが、地理的な配置（指定されたサイトのすべてのエンドポイントが、最も近い MCU を使用する）またはエンドポイントのタイプ（ビデオ対応エンドポイントがビデオ対応 MCU を使用し、音声のみのエンドポイントは別のコンファレンス ブリッジ リソースを使用する）でグループ化することが一般的です。SCCP デバイスのユーザが Conf、Join、または MeetMe ソフトキーをアクティブにした場合、Cisco Unified CallManager は発信側エンドポイントの MRGL を使用して、使用するコンファレンス ブリッジを決定します。
Cisco Unified CallManager は、次の基準をリストの順に適用して、使用するコンファレンス ブリッジ リソースを選択します。
1. メディア リソース グループ リスト（MRGL）にリストされているメディア リソース グループ（MRG）の優先順位
2. 選択された MRG の中で、最も使用されていないリソース
このように選択されるため、ユーザがビデオ対応 SCCP エンドポイントで Conf、Join、または MeetMe ソフトキーをアクティブにしたときにビデオ対応 MCU が選択されるようにするには、ビデオ対応 SCCP エンドポイントの MRGL の最上位にビデオ対応 MCU を置く必要があります。ただし、エンドポイントによっては、ビデオ専用エンドポイントでないことがあります。たとえば、Cisco Unified Video Advantage と組み合せて使用される IP Phone は、ほとんどの場合は音声のみのコールに使用され、まれにビデオに使用されることもあります。したがって、この電話機の MRGL の最上位に MCU を配置すると、ビデオ対応の参加者がいない音声のみの会議にも、この MCU が常に選択されます。このシナリオでは、音声のみの会議で MCU リソースが浪費され、ビデオ会議の要求が発生したときに使用できなくなることがあります。
そのため、MRGL でビデオ対応 MCU リソースにアクセスできるユーザは、慎重に選択することをお勧めします。選択するときは、次の考慮事項が役立ちます。
• エンドポイントは、ビデオ専用デバイス（Sony 社製または Tandberg 社製の SCCP エンドポイントなど）か、関連付けられている Cisco Unified Video Advantage クライアントをときどき使用するだけの IP Phone か。
• そのユーザが SCCP 会議を呼び出すときに、ビデオが必要か、音声のみで十分か。
• SCCP 会議の要件を満たす十分なリソースをネットワークに提供するために、どのくらいの費用を MCU リソースに費やすことができるか。
これらの選択基準に対する答えは、企業ごとに異なります。ある企業は、マルチポイント ビデオが不可欠な機能で、いくつかのポートが音声のみの会議で浪費されてもすべてのビデオ会議に使用できるリソースが残るように、十分な MCU リソースをネットワークに提供するために必要な費用を費やします。Sony 社製および Tandberg 社製のエンドポイントだけでビデオ リソースを有効にして、Cisco Unified Video Advantage ユーザには音声のみのコンファレンス ブリッジ リソースを割り当てる企業もあります。あるいは、すべての Sony 社製および Tandberg 社製の SCCP エンドポイントと、選択された Cisco Unified Video Advantage ユーザ（管理職以上など）に対してビデオ リソースを有効にして、その他のユーザの実装には音声のみのリソースを割り当てる企業もあります。
H.323 および SIP MCU リソース
H.323 または SIP モードで設定すると、MCU は MC 機能を提供し、Cisco Unified CallManager への H.323 または SIP ピアのように動作します。H.323 および SIP MCU 会議は多くの方法で呼び出せますが、それらの方法は主に次の 2 つのカテゴリに分類できます。
スケジュール済みの会議は、コールの前に、スケジューリング アプリケーションを使用して MCU リソースを予約します。スケジューリング機能は、通常、Cisco Unified MeetingPlace、MagicSoft VCWizard、RADVision VCS、Tandberg 社製 TMS、FVC.COM Click to Meet などの Web ベースのユーザ インターフェイスで提供されます。スケジューリング アプリケーションは、通常、会議の日付と時刻、会議用に予約されているポートの数、ダイヤルイン情報をユーザに提供する招待情報を生成します。または、会議の開始時に参加者の一部、またはすべてにダイヤル アウトするようにスケジューリング システムを設定できます。
予約なしの会議の場合、MCU には、オンデマンドで使用できる一定の数のリソースがあります。会議を作成するため、ユーザはいつでも MCU にダイヤルインするだけで済みます。そのユーザが最初にダイヤルした参加者である場合、MCU は、サービス テンプレートで定義された設定を使用して、動的に新しい会議を作成します（サービス テンプレートの詳細については、「サービス テンプレートとプレフィックス」を参照してください）。同じ会議番号にダイヤルインした後続のユーザは、この会議に参加します。
スケジュール済みまたは予約なしの H.323 または SIP 会議の作成と参加は、任意のタイプのエンドポイントでできます。たとえば、SCCP エンドポイントが H.323 MCU にダイヤルインして、H.323 エンドポイントと同様に予約なしの会議を作成できます。
図15-8 は、H.323 エンドポイントと SCCP エンドポイントを同じ H.323 会議に参加させる方法を示しています。この例では、H.323 MCU にダイヤルインして新しい予約なしの会議を作成した SCCP エンドポイントによって会議が開始され、他の 2 人の参加者が、後で会議にダイヤルインしています。
図15-8 予約なしの会議の SCCP および H.323 エンドポイント
H.323 および SIP 会議は、Voice-Activated モードと Continuous-Presence モードの両方をサポートします。さらに、H.323 会議は、MCU に内蔵されたソフトウェアベースの MP、Rate Matching（RM）モジュール、および Enhanced Media Processor（EMP）モジュールなど、すべての MP タイプをサポートします。
MCU のサービスは、各会議に関係する設定を定義します。異なるタイプの会議に、異なるサービスを定義できます。各サービスは、少なくとも、次の設定を定義します。
レート変換対応 MP を使用している場合、この設定に複数の速度が含まれることがあります。
最小数は、会議の開始時に予約されるポートの数を定義します。最大数は、MCU がこの会議への参加を許可する参加者の最大数を定義します。
• ビデオ コーデック タイプ（H.261、H.263、または H.264）
• 表示するビデオ レイアウト（Voice-Activated または Continuous-Presence）
会議には複数のレイアウトを含めることができ、会議の参加者数が増減したときに変化する動的レイアウトもあります。
「SCCP service」チェックボックスが有効（オン）の場合、サービスは SCCP 会議で使用されます。このボックスが無効（オフ）の場合、サービスは H.323 および SIP 会議で使用されます。
H.323 および SIP サービスでは、特定のサービスに到達するために、エンドポイントがダイヤルするサービス プレフィックスに各サービスが割り当てられます。サービス プレフィックスは会議番号の前半の番号を形成し、後半の番号で会議 ID を定義します。この形式によって、同じサービス プレフィックスで複数の会議を同時に実行できます。たとえば、サービス プレフィックスを 555 にして、会議の完全なダイヤル文字列を 7 桁にできます。この方式では、4 桁の会議 ID を使用でき、会議番号は 5550000 ～ 5559999 の範囲になります。ユーザは、会議にアクセスするために全文字列をダイヤルする必要があります。コールを受信すると、MCU はダイヤルされた番号を解析し、サービス プレフィックスとの照合を試行します。ダイヤルされたサービス プレフィックスを判断すると、MCU は残りの番号を会議 ID として使用します。会議 ID がまだ存在しない場合、MCU は、その ID で新しい予約なしの会議を作成します。会議がすでに存在する場合は、その会議にユーザが追加されます。
MCU で H.323 と SIP の両方を同時に有効にする場合は、両方のプロトコルでダイヤル プランを同じにする必要があります。H.323 と SIP の間には、SCCP との間にあるような区別がありません。会議が SIP で作成された場合、MCU はこの会議を H.323 を介して登録します。ゲートキーパーまたは SIP プロキシが登録を拒否した場合、会議は失敗します。
SCCP サービスでもサービス プレフィックスを定義する必要がありますが、ユーザは SCCP サービスに「ダイヤル」インしないため、番号自体に意味はありません。プレフィックスは、Cisco Unified CallManager と SCCP MCU リソースとの間の SCCP 登録メッセージでのみ使用されます。ユーザは、Conf、Join、または cBarge ソフトキーを使用して SCCP MCU 会議にアクセスするか（Ad-Hoc）、Cisco Unified CallManager で割り当てられた MeetMe 番号をダイヤルして会議に参加します（予約なし）。そのため、SCCP サービス プレフィックスに指定した番号は関係ありません。999999 など、任意の番号を自由に指定できます。このプレフィックスは、MCU と Cisco Unified CallManager との間の SCCP シグナリングの外側には公開されません（つまり、ダイヤルすることも、ゲートキーパへの MCU の登録に含むこともできません）。
MCU のサイズの選定
すでに説明したように、現在の MCU モデルは IP/VC 3511 と 3540 です。IP/VC 3511 MCU は固定数のポートをサポートし、IP/VC 3540 MCU はさまざまなモジュール サイズを受け付けるモジュラ システムです。使用可能なポートの合計数を計算するときは、Audio Transcoder Daughter Card と Rate Matching（RM）モジュールまたは Enhanced Media Processor（EMP）モジュールをサポートできるように考慮する必要もあります。そのため、MCU のサイズを計算するときは、次の要素について検討します。
この値は、会議の速度によって異なります。速度が高いほど、サポートされるポートの数は減少します。
• Audio Transcoding Daughter Card がサポートできるポート数
この値は、トランスレーティングが必要な参加者の数および会議で使用するビューの数によって異なります。
サポートされるポート数に関する特定の情報については、Cisco.com で入手可能な MCU ハードウェアの製品マニュアルを参照してください。可能なバリエーションの数は無限に近いため、具体的な設計ガイダンスをこのマニュアルで示すことは非常に困難です。多くのお客様では、最終的に、SCCP Ad-Hoc 会議、H.323 および SIP の予約なしの会議、および H.323 および SIP のスケジュール済み会議が混在することになります。MCU は、正しい速度とビデオ レイアウトでこれらのすべてのタイプの会議に対応できるサイズにする必要があります。言うまでもなく、この判断はとても複雑です。特定の環境での MCU のサイズの選定にあたっては、代理店にご相談ください。
ダイヤルイン会議の IVR
ダイヤルイン会議は、通常、Interactive Voice Response（IVR; 音声自動応答装置）システムを使用して、参加する会議の会議 ID とパスワード（設定されている場合）の入力をユーザに求めます。次のタイプの IVR と Cisco Unified Videoconferencing 3500 シリーズ MCU を使用できます。
最初に会議 ID のプロンプトを再生することはできません。つまり、ユーザは参加する会議の会議番号をダイヤルする必要があり、次にその会議のパスワードの入力を求められます。
• インバンドとアウトオブバンド（H.245 英数字）の両方の DTMF をサポートする。
• より柔軟性の高いメニューまたは機能を提供するようにカスタマイズできない。
カスタマイズできるのは、ユーザに対して再生される録音済み音声ファイルだけです。
ダイヤルイン番号を 1 つにして、会議 ID を入力するようにユーザに求めるには、Cisco Unified IP-IVR と MCU を組み合せて使用します。
Cisco Unified IP-IVR には、次の特性があります。
• （特に）会議 ID とパスワードのプロンプトを再生できる。
つまり、発信側デバイスはアウトオブバンド DTMF 方式（H.323 デバイスの H.245 英数字など）をサポートしている必要があります。これらのアウトオブバンド DTMF メッセージは、次に、Cisco Unified CallManager によって Cisco IP IVR サーバにリレーされます。発信側デバイスがインバンド DTMF トーンだけをサポートしている場合、Cisco IP IVR サーバが発信側デバイスを認識しないため、そのデバイスは会議に参加できません。
• 高いカスタマイズ性があり、より柔軟性の高いメニューおよび他の高度な機能を提供できる。
カスタマイズには、ユーザの会議への参加を許可する前にユーザのアカウントをバックエンド データベースで検証すること、議長が参加するまで参加者をキューに入れることなどが含まれます。
（注） Cisco Unified IP-IVR はアウトオブバンド シグナリングのみをサポートするため、インバンド DTMF トーンを使用する H.323 エンドポイントでは機能しません。
Cisco Unified IP-IVR を使用する場合、ユーザは、MCU に直接ルーティングするルート パターンをダイヤルする代わりに、コールを Cisco Unified IP-IVR サーバにルーティングする CTI ルート ポイントをダイヤルできます。会議 ID の DTMF ディジットを収集した後、Cisco Unified IP-IVR は、MCU にコールをルーティングするルート パターンにコールをルーティングします。この転送操作では、発信側デバイスがメディア チャネルの終了と新しい宛先への再開をサポートしている必要があります。たとえば、Cisco Unified IP-IVR を呼び出す H.323 ビデオ デバイスは、最初に Cisco Unified IP-IVR サーバへの音声チャネルをネゴシエートします。次に、適切な DTMF ディジットが入力された後、MCU に転送します。この時点で Cisco Unified CallManager が、エンドポイントと Cisco Unified IP-IVR サーバとの間の音声チャネルを終了し、エンドポイントと MCU の間で新しい論理チャネルを開く Empty Capabilities Set（ECS）プロシージャを呼び出します。このプロシージャについては、この章ですでに説明しています。H.323 ビデオ エンドポイントが Cisco Unified CallManager からの ECS の受信をサポートしていない場合、コールが切断されるか、最悪の場合、クラッシュしてリブートします。
ゲートキーパー
Cisco Unified CallManager にビデオ サポートが導入されるまで、H.323 ビデオ会議ネットワークは、デバイス登録管理、コール ルーティング、および帯域幅制御を実行するゲートキーパーに依存していました。以前は Multimedia Conference Manager（MCM）と呼ばれていた Cisco IOS Gatekeeper が、これらの機能を提供します。ただし、シスコ製品を含むほとんどのゲートキーパーは、一般的なエンタープライズクラスの PBX で期待される機能と比較して、基本的なコール ルーティング機能だけを提供します。H.323 ビデオ コールのルーティングに使用する場合、Cisco Unified CallManager が基本的なゲートキーパー機能を補足し、完全なエンタープライズクラスの PBX 機能を H.323 ビデオ コールに提供します。
Cisco Unified CallManager とゲートキーパーはチームとして機能し、H.323 ビデオ エンドポイントを管理します。ゲートキーパーがすべての Registration, Admission, and Status（RAS）シグナリングを処理し、Cisco Unified CallManager がすべての H.225 コール シグナリングと H.245 メディア ネゴシエーションを処理します。そのため、図15-9 で示すように、ネットワークの H.323 エンドポイントに RAS シグナリング プロシージャが必要な場合は、ゲートキーパーと Cisco Unified CallManager サーバを同時に配置する必要があります。
図15-9 H.323 エンドポイントに RAS シグナリングを提供する Cisco Unified CallManager と IOS Gatekeeper
次のいずれかの条件が該当する場合、RAS シグナリングが常に必要になります。
エンドポイントが静的 IP アドレスを使用する場合、Cisco Unified CallManager は、エンドポイントを探すために RAS プロシージャを必要としません。エンドポイントは静的 IP アドレスを使用して Cisco Unified CallManager Administration でプロビジョニングされ、この H.323 クライアントのディレクトリ番号へのコールは、直接静的 IP アドレスにルーティングされます。エンドポイントが静的 IP アドレスを使用しない場合、Cisco Unified CallManager はこのエンドポイントにコールをルーティングするたびに、ゲートキーパーに照会してエンドポイントの現在の IP アドレスを取得する必要があります。
• E.164 アドレスへのコール発信のために、エンドポイントで RAS プロシージャを必要とする。
ほとんどの H.323 ビデオ会議エンドポイントは、IP アドレスでダイヤルする場合に限り、別のエンドポイントに直接ダイヤルできます（ユーザが宛先エンドポイントの IP アドレスをドット付き 10 進表記で入力し、コール ボタンを押す）。ただし、ユーザが E.164 形式の番号（IP アドレスのドット付き 10 進表記ではない数値）または H.323-ID（ ユーザ名 または ユーザ名@ドメイン の形式）をダイヤルする場合、ほとんどのエンドポイントは、現在、これらの宛先タイプを解決する方法としてゲートキーパーへの RAS 照会だけを提供します。ただし、E.164 アドレスへのコールが RAS プロシージャをスキップし、H.225 SETUP メッセージを指定された IP アドレスに直接送信するように設定できるエンドポイントの数が増えています。この操作方式は、ピアツーピア モードと呼ばれます。このモードを使用する例としては Tandberg 社製 H.323 エンドポイントがあり、登録するゲートキーパー アドレスを設定することも、使用する Cisco Unified CallManager サーバの IP アドレスを設定することもできます。後者の場合、エンドポイントはすべてのコールを指定された IP アドレスに直接送信し、ゲートキーパーの RAS プロシージャを必要としません。
H.323 ビデオ エンドポイントの RAS プロシージャの管理に加え、ゲートキーパーは、大規模なマルチサイト分散コール処理環境でのダイヤル プラン解決および Cisco Unified CallManager クラスタ間の帯域幅制限の管理において、重要な役割を果たしています。ゲートキーパーは、組織内の多数の H.323 VoIP ゲートウェイを統合できます。また、エンタープライズ IP Telephony ネットワークとサービス プロバイダー VoIP 転送ネットワークの間でセッション ボーダー コントローラとして機能します。
そのため、Cisco IP Video Telephony 配置に関しては、Cisco IOS Gatekeeper は次の役割の一方または両方を実行できます。
エンドポイント ゲートキーパーは、H.323 クライアント、MCU、および H.320 ビデオ ゲートウェイを宛先または発信元とするコール、およびこれら相互間のコールのすべての RAS プロシージャを管理するように設定されます。エンドポイント ゲートキーパーは、Cisco Unified CallManager がすべての H.225 コール ルーティングおよび H.245 メディア ネゴシエーションを実行できるように、これらのすべてのコールを適切な Cisco Unified CallManager クラスタに転送します。
インフラストラクチャ ゲートキーパーは、Cisco Unified CallManager クラスタ間、Cisco Unified CallManager クラスタと H.323 VoIP ゲートウェイのネットワーク間、および Cisco Unified CallManager クラスタとサービス プロバイダーの H.323 VoIP 転送ネットワーク間のすべてのダイヤル プラン解決および帯域幅制限（コール アドミッション制御）を管理するように設定されます。
Cisco Unified CallManager Release 4.0 では、エンドポイント ゲートキーパーとインフラストラクチャ ゲートウェイは別々のルータで実行する必要があり、各エンドポイント ゲートキーパーは単一の Cisco Unified CallManager クラスタだけにサービスを提供できました。企業内に複数の Cisco Unified CallManager クラスタがある場合は、各 Cisco Unified CallManager クラスタごとに、個別のエンドポイント ゲートキーパーを配置する必要がありました。Cisco Unified CallManager Release 4.1 以降では、これらの役割を単一のゲートキーパーに組み合せて、1 つ以上の Cisco Unified CallManager クラスタのエンドポイント ゲートキーパーとして使用しながら、クラスタ間またはクラスタと他の H.323 VoIP ネットワーク間のコールを管理するインフラストラクチャ ゲートキーパーとして使用できます。ただし、（特に）次の理由により、これらの役割は複数のゲートキーパーに分割することをお勧めします。
配置する Cisco IOS ルータ プラットフォーム、および混雑時のコール量の概算によっては、負荷を処理するゲートキーパーが複数必要になることがあります。
1 台のゲートキーパーでネットワーク全体をカバーすることは、大規模な国際 VoIP ネットワークにおいて、賢明な方法ではありません。複数のゲートキーパーをネットワーク全体に（一般的には地理的に）分散して配置すると、1 つのゲートキーパーが故障した場合に、より適切に障害を切り分けることができます。
ゲートキーパーの設定の中には、グローバルな性質（そのゲートキーパーに登録されているすべてのエンドポイントに関連する性質）を持つものがあります。たとえば、コマンド arq reject-unknown-prefix は、一部の H.323 VoIP 転送環境では便利ですが、Cisco Unified CallManager へのコールをルーティングするエンドポイント ゲートキーパーで使用される gw-type-prefix <プレフィックス> default-technology コマンドと衝突します。Cisco IOS では両方のコマンドを同じゲートキーパーで設定することは禁止されていませんが、 arq reject-unknown-prefix コマンドが優先されるため、不明な番号へのコールは Cisco Unified CallManager にルーティングされず、拒否されます。この場合は、H.323 VoIP 転送ネットワーク用に 1 つのゲートキーパーを使用し、別のゲートキーパーを Cisco Unified CallManager クラスタに使用します。
非互換性のもう 1 つの例は、冗長性のためにゲートキーパーを設定する際に発生することがあります。Cisco Voice Gateways や Cisco Unified CallManager など、ほとんどの Cisco H.323 音声デバイスは、Gatekeeper Update Protocol（GUP）を使用して相互に同期するゲートキーパー クラスタとしてゲートキーパーを設定可能な H.323v3 Alternate Gatekeeper 機能をサポートします。ただし、多くの H.323 ビデオ エンドポイントは Alternate Gatekeeper をサポートしないため、冗長性のために Hot Standby Routing Protocol（HSRP; ホットスタンバイ ルータ プロトコル）を使用するようにゲートキーパーを設定する必要があります。これらの 2 つの冗長性方式を同じゲートキーパーに混在させ、組み合せることはできません。この場合、Alternate Gatekeeper をサポートするエンドポイント用にゲートキーパー クラスタを使用するか、サポートしないエンドポイント用にゲートキーパーの HSRP ペアを使用するかを決定します。
図15-10 は、2 つの Cisco Unified CallManager クラスタがあるネットワーク シナリオを示しています。各クラスタは、SCCP クライアント、H.323 クライアント、H.323 MCU、および H.320 ゲートウェイで構成されています。H.323 クライアント、MCU、および H.320 ゲートウェイの RAS 部分を管理するために、エンドポイント ゲートキーパーを各クラスタに配置します。別のインフラストラクチャ ゲートキーパーが、クラスタ間のダイヤル プラン解決と帯域幅を管理します。この図ではゲートキーパーの冗長性は示されていませんが、これらの各ゲートキーパーは、実際には Alternate Gatekeeper または HSRP ベースの冗長性を持つように設定された複数のゲートキーパーです。
図15-10 2 つの Cisco Unified CallManager クラスタと必要なゲートキーパー
サポートされるゲートキーパー プラットフォーム
Cisco Unified CallManager 4.1 以降を使用するエンドポイント ゲートキーパーとして機能するには、Cisco IOS Gatekeeper で Cisco IOS Release 12.3(11)T 以降を実行する必要があります。インフラストラクチャ ゲートキーパーの最小 Cisco IOS リリース要件については、「推奨されるハードウェアと ソフトウェアの組み合せ」を参照してください。
次のルータ プラットフォームが Cisco IOS Gatekeeper をサポートしています。
• Cisco 7200 シリーズ、7301、および 7400 シリーズ
ルータ プラットフォームで使用する必要があるリリースと機能を判断するには、次の URL にある Cisco Feature Navigator を使用します（Cisco.com ログイン アカウントが必要）。
http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax_c/callc_c/h323_c/ipipgw/ipftgde.htm
この資料には、Cisco IOS Release 12.3(11)T が統合音声およびビデオ サービスを提供すると記載されています。そのため、これが推奨される最小リリースになります。
エンドポイント ゲートキーパー
次の条件の両方が該当する場合は、エンドポイント ゲートキーパーが必要です。
• クラスタに H.323 クライアント、H.323 MCU、または H.320 ゲートウェイ（集合的に H.323 エンドポイントと呼ぶ）が含まれている。これらのタイプのエンドポイントが存在しない場合（たとえば、すべてのクライアントが SCCP エンドポイントで、MCU も H.320 ゲートウェイもない場合）、エンドポイント ゲートキーパーは不要です。
–E.164 アドレスへのコール発信のために、H.323 エンドポイントで RAS プロシージャを必要とする。すでに述べたように、ピアツーピア コール シグナリングに対応するデバイスが増えています。これらのデバイスは、ゲートキーパーに登録する必要はありません。
–H.323 エンドポイントが静的 IP アドレスを使用しない。
エンドポイント ゲートキーパーの役割は、これらの H.323 エンドポイントを登録する場所を提供し、エンドポイントとの通信の RAS 部分を処理するだけです。エンドポイント ゲートキーパーは、これらのエンドポイントが宛先または発信元となるコール、またはこれらのエンドポイント間のすべてのコール要求に対応して、Cisco Unified CallManager がすべてのコール ルーティング機能および帯域幅制御機能を実行できるように、コールを適切な Cisco Unified CallManager サーバに転送します。このコール ルーティング制御および帯域幅制御を実現するには、H.323 トランクをゲートキーパーに登録するように Cisco Unified CallManager を設定し、ゾーンへのコール、ゾーンからのコール、またはゾーン内のコールをすべてこれらのトランクにルーティングするようにゲートキーパーを設定します。
Cisco Unified CallManager Release 4.1 では、RASAggregator トランクという新しいタイプの H.323 トランクが導入されました。このタイプのトランクは、すべての H.323 クライアント、H.323 MCU、または H.320 ゲートウェイ ゾーンに使用されます。一方、以前の Cisco Unified CallManager リリースからのゲートキーパー制御クラスタ間トランクおよびゲートキーパー制御 H.225 トランクは、インフラストラクチャ ゲートキーパーとの統合に使用されます。『 IP Video Telephony SRND for Cisco Unified CallManager 4.0 』に記載された推奨事項に基づいて H.323 ビデオ エンドポイントを配置した場合は、新しい RASAggregator トランクを使用してその柔軟性を利用できるように設定を修正する必要があります。この設定変更は慎重に計画し、管理者の都合の良いときに実行することで、既存の H.323 ビデオ エンドポイントの中断を最小限にする必要があります。Cisco Unified CallManager 4.0 配置からの移行手順については、「Cisco Unified CallManager 4.0 からの移行」を参照してください。
H.323 クライアントのプロビジョニング
H.323 クライアントは、他の電話機とほぼ同じ方法でプロビジョニングされます。新しい電話機（モデル タイプ = H.323 Client）を作成し、ディレクトリ番号を割り当て、コーリング サーチ スペース、デバイス プールなどを割り当てます。Cisco Unified CallManager で H.323 クライアントは、次のいずれかの方法で設定します。使用する方法は、クライアントが静的 IP アドレスを使用するかどうか、クライアントで E.164 アドレスをダイヤルする RAS プロシージャが必要かどうかによって異なります。
このタイプの設定は、静的 IP アドレスが割り当てられていないクライアント（DHCP 割り当てアドレスを使用するクライアント）で、E.164 アドレスをダイヤルする RAS プロシージャが必要な場合に使用します。これらのクライアントとの通信には、RASAggregator トランクを使用します（図15-11 および図15-12 を参照）。
このタイプの設定は、静的 IP アドレスが割り当てられているクライアントで、E.164 アドレスをダイヤルする RAS プロシージャが必要な場合に使用します。Cisco Unified CallManager はゲートキーパーを必要せずに直接シグナルを送信して IP アドレスを解決できますが、クライアントは Cisco Unified CallManager に直接シグナルを送信できず、ダイヤルしようとしている E.164 アドレスを解決するためにゲートキーパーに照会する必要があります（非同期通信）。このタイプのクライアントをサポートするには、実際にはすべてのクライアントが静的 IP アドレスを使用していても、ゲートキーパーのゾーンごとに 1 つ以上のゲートキーパー制御クライアントを Cisco Unified CallManager で定義する必要があります。この場合、非ゲートキーパー制御クライアントは、実際には存在しない「ダミー」クライアントになります。定義する目的は、ゲートキーパーがクライアントから Cisco Unified CallManager へのコールをルーティングできるように、RASAggregator トランクを作成することだけです（図15-13 および図15-14 を参照）。
このタイプの設定は、クライアントが静的 IP アドレスを持ち、ピアツーピア シグナリングに対応している（E.164 番号をダイヤルする RAS プロシージャが必要ない）場合に使用します。Cisco Unified CallManager は直接シグナルを送信でき、クライアントは Cisco Unified CallManager に直接シグナルを送信できます（同期通信）。このタイプのクライアントには、ゲートキーパーまたは RASAggregator トランクが不要です（図15-15 および図15-16 を参照）。
図15-11 から図15-16 は、これら 3 つのシナリオで使用されるシグナリング フローを示しています。
図15-11 Cisco Unified CallManager からゲートキーパー制御クライアントへのコール
図15-12 ゲートキーパー制御クライアントから Cisco Unified CallManager へのコール
図15-13 Cisco Unified CallManager から非ゲートキーパー制御クライアントへのコール（非同期）
図15-14 非ゲートキーパー制御クライアントから Cisco Unified CallManager へのコール（非同期）
図15-15 Cisco Unified CallManager から非ゲートキーパー制御クライアントへのコール（同期）
図15-16 非ゲートキーパー制御クライアントから Cisco Unified CallManager へのコール（同期）
ゲートキーパー制御クライアント
H.323 クライアントをゲートキーパー制御として設定するときは、任意の英数字文字列（わかりやすい名前など）を Device Name フィールドに入力し、 Gatekeeper-controlled ボックスをオンにして、次のフィールドに入力します。
クライアントで使用するデバイス プール。同じゾーンに登録されているすべての H.323 クライアント（ゲートキーパー制御と非ゲートキーパー制御の両方）が、同じデバイス プールを使用する必要があります。間違ってエンドポイントの間で異なるデバイスプールが割り当てられた場合、Cisco Unified CallManager は複数の RASAggregator トランクをゾーン内で登録し、着信コールが間違った RASAggregator トランクに転送されても、Cisco Unified CallManager で拒否されます。
ゲートキーパー IP アドレスのドロップダウン リスト。ゲートキーパー制御 H.323 クライアントを設定する前に、Cisco Unified CallManager でゲートキーパーを定義する必要があります。
テクノロジー プレフィックスは RASAggregator トランクで使用され、ゲートキーパーのクライアント ゾーンに登録されます。このテクノロジー プレフィックスは、ゲートキーパーでデフォルト テクノロジー プレフィックスとして設定された値と一致している必要があります。同じゾーンに登録されているすべてのゲートキーパー制御 H.323 クライアントが、同じテクノロジー プレフィックスを使用する必要があります。間違ってエンドポイントの間で異なるテクノロジー プレフィックスが割り当てられた場合、Cisco Unified CallManager は複数の
RASAggregator トランクをゾーン内で登録し、着信コールが間違った RASAggregator トランクに転送されても、Cisco Unified CallManager で拒否されます。このプレフィックスには 1# を使用することをお勧めします。
ゲートキーパーで設定されているクライアント ゾーンの名前（大文字と小文字が区別されます）。同じゾーンに登録されているすべてのゲートキーパー制御 H.323 クライアントが、同じゾーン名を使用する必要があります。間違ってエンドポイントの間で異なるゾーン名（このフィールドは大文字と小文字が区別されます）が割り当てられた場合、Cisco Unified CallManager は複数の RASAggregator トランクをゲートキーパーに登録しようとし（ただし、ゾーン名が不正なトランクは登録に失敗します）、着信コールが間違った RASAggregator トランクに転送されても、Cisco Unified CallManager で拒否されます。
また、Cisco CallManager サービス パラメータの Send Product ID and Version ID を True に設定する必要があります。このパラメータによって、ゲートキーパーがクライアント ゾーンへの H.323 コール、クライアント ゾーンからの H.323 コール、クライアント ゾーン内の H.323 コールのすべてを RASAggregator トランクに転送できるように、RASAggregator トランクをゲートキーパーに H323-GW として登録できます。
非ゲートキーパー制御クライアント
H.323 クライアントを非ゲートキーパー制御としてプロビジョニングする場合は、クライアントの静的 IP アドレスを Device Name フィールドに入力し、Gatekeeper-controlled セクションの下のその他のすべての設定をブランク（オフ）のままにします。コールがこのディレクトリ番号にルーティングされると、Cisco Unified CallManager は静的 IP アドレスを使用してクライアントに転送します。
クライアントがピアツーピア モードを使用するように設定されている場合、これ以上の設定は不要です。クライアントで E.164 アドレスにコールを発信する RAS プロシージャが必要な場合は、RASAggregator トランクを作成するために、次のフィールドに入力して、ダミーのゲートキーパー制御 H.323 クライアントも設定する必要があります。
クライアント ゾーンの RASAggregator トランクの作成を目的とするダミー クライアントとして、クライアントを識別するためのわかりやすい名前。
非ゲートキーパー制御 H.323 クライアントを設定するときに選択したデバイス プール。ダミー クライアントに割り当てられたデバイス プールが、実際のクライアントに割り当てられたデバイス プールと異なる場合、実際のクライアントからの着信コールが Cisco Unified CallManager で拒否されることがあります。
ゲートキーパー IP アドレスのドロップダウン リスト。ダミーのゲートキーパー制御 H.323 クライアントを設定する前に、Cisco Unified CallManager でゲートキーパーを定義する必要があります。
テクノロジー プレフィックスは RASAggregator トランクで使用され、ゲートキーパーのクライアント ゾーンに登録されます。このテクノロジー プレフィックスは、ゲートキーパーでデフォルト テクノロジー プレフィックスとして設定された値と一致している必要があります。このプレフィックスには 1# を使用することをお勧めします。
ゲートキーパーで設定されているクライアント ゾーンの名前（大文字と小文字が区別されます）。
また、Cisco CallManager サービス パラメータの Send Product ID and Version ID を True に設定する必要があります。このパラメータによって、ゲートキーパーがクライアント ゾーンへの H.323 コール、クライアント ゾーンからの H.323 コール、クライアント ゾーン内の H.323 コールのすべてを RASAggregator トランクに転送できるように、RASAggregator トランクをゲートキーパーに H323-GW として登録できます。
H.323 MCU のプロビジョニング
H.323 MCU は、Cisco Unified CallManager で H.323 ゲートウェイとしてプロビジョニングされてから、これらのデバイスにコールをルーティングするルート パターンが設定されます。H.323 ゲートウェイをプロビジョニングするときは、MCU の静的 IP アドレスおよび TCP シグナリング ポートを Device Name フィールドに入力する必要があります。コールが MCU に関連付けられたルート パターンと一致すると、Cisco Unified CallManager は静的 IP アドレスと TCP ポートを使用して、MCU に到達します。
（注） Cisco Unified Videoconferencing 3500 シリーズ MCU は、デフォルトでは TCP ポート 1720 を監視しません（IP/VC 3500 シリーズ MCU は、デフォルトでポート 2720 を監視します）。監視している TCP ポートを確認し、1720 に変更するか、正しいポートを Cisco Unified CallManager でプロビジョニングする必要があります。
MCU がピアツーピア モードを使用するように設定されている場合は、これ以上の設定は不要です（Cisco Unified Videoconferencing MCU は、現在、ピアツーピア モードをサポートしていませんが、一部のサードパーティ製 MCU がサポートしています）。MCU で E.164 アドレスにコールを発信する RAS プロシージャが必要な場合は、RASAggregator トランクを作成するために、次のフィールドに入力して、ダミーのゲートキーパー制御 H.323 クライアントも設定する必要があります。
MCU ゾーンの RASAggregator トランクの作成を目的とするダミー クライアントとして、クライアントを識別するためのわかりやすい名前。
MCU を表す H.323 ゲートウェイを設定するときに選択したデバイス プール。ダミー クライアントに割り当てられたデバイス プールが、MCU を表す H.323 ゲートウェイに割り当てられたデバイス プールと異なる場合、MCU からの着信コールが Cisco Unified CallManager で拒否されることがあります。
ゲートキーパー IP アドレスのドロップダウン リスト。ダミーのゲートキーパー制御 H.323 クライアントを設定する前に、Cisco Unified CallManager でゲートキーパーを定義する必要があります。
テクノロジー プレフィックスは RASAggregator トランクで使用され、ゲートキーパーの MCU ゾーンに登録されます。このテクノロジー プレフィックスは、ゲートキーパーでデフォルト テクノロジー プレフィックスとして設定された値と一致している必要があります。このプレフィックスには 1# を使用することをお勧めします。
ゲートキーパーで設定されている MCU ゾーンの名前（大文字と小文字が区別されます）。
また、Cisco CallManager サービス パラメータの Send Product ID and Version ID を True に設定する必要があります。このパラメータによって、ゲートキーパーがクライアント ゾーンへの H.323 コール、クライアント ゾーンからの H.323 コール、MCU ゾーン内の H.323 コールのすべてを RASAggregator トランクに転送できるように、RASAggregator トランクをゲートキーパーに H323-GW として登録できます。
H.323 MCU は、実行中の予約なしまたはスケジュール済みの H.323 会議に到達するダイヤルイン番号として、E.164 アドレスまたはテクノロジー プレフィックス（MCU ではサービス プレフィックスとも呼ばれる）を使用できます。MCU 管理画面で MCU Mode を Gateway ではなく MCU に設定して、E.164 アドレスを使用するように MCU を設定することをお勧めします。使用している MCU のモデルで MCU 設定を使用できない場合は、次の特別な設定を使用して、他の H.323 エンドポイントから MCU に発信されたコールを適切にルーティングします。
MCU が Gateway モードに設定されている場合、または、別のベンダーの MCU で、（何らかの理由で）会議 ID を E.164 アドレスではなくテクノロジー プレフィックスとして登録する必要がある場合は、MCU のサービス プレフィックスの先頭を # 文字にする必要があります。たとえば、MCU サービス プレフィックスが 8005551212 の場合、MCU でサービス プレフィックスを #8005551212 としてプロビジョニングする必要があります。その結果、他の H.323 エンドポイントが 8005551212 とダイヤルすると、ゲートキーパーは登録済みの一致するテクノロジー プレフィックスを検索するのではなく、コールを発信したエンドポイントのゾーンでデフォルト テクノロジー プレフィックスと共に登録された RASAggregator トランクにコールをルーティングします。Cisco Unified CallManager は、コールを MCU にルーティングする前に、着信番号の先頭に # 文字を付加する必要があります。この文字は、MCU を表す H.323 ゲートウェイに関連付けられたルート パターンに付加されます。そのため、SCCP クライアントから MCU へのコールでも、着信番号にこの # 文字が付加されます。
MCU が MCU モードで設定されている場合、または E.164 アドレスを会議 ID に使用する別のベンダーの MCU である場合、# 文字を付加する必要はありません。MCU がピアツーピア モードを使用しているため、テクノロジー プレフィックスをゲートキーパーに登録する必要がない場合もこの条件は当てはまらず、# 文字を付加する必要はありません。
H.320 ゲートウェイのプロビジョニング
H.323 MCU と同様に、H.320 ゲートウェイも、Cisco Unified CallManager で H.323 ゲートウェイとしてプロビジョニングされてから、これらのデバイスにコールをルーティングするルート パターンが設定されます。H.323 ゲートウェイをプロビジョニングするときは、H.320 ゲートウェイの静的 IP アドレスおよび TCP シグナリング ポートを Device Name フィールドに入力する必要があります。コールがゲートウェイに関連付けられたルート パターンと一致すると、Cisco Unified CallManager は静的 IP アドレスと TCP ポートを使用して、ゲートウェイに到達します。
（注） Cisco Unified Videoconferencing 3500 シリーズ ゲートウェイは、デフォルトでは TCP ポート 1720 を監視しません（IP/VC 3500 シリーズ ゲートウェイは、デフォルトでポート 1820 を監視します）。監視している TCP ポートを確認し、1720 に変更するか、正しいポートを Cisco Unified CallManager でプロビジョニングする必要があります。
ゲートウェイがピアツーピア モードを使用するように設定されている場合は、これ以上の設定は不要です。ゲートウェイで E.164 アドレスにコールを発信する RAS プロシージャが必要な場合は、RASAggregator トランクを作成するために、次のフィールドに入力して、ダミーのゲートキーパー制御 H.323 クライアントも設定する必要があります。
ゲートウェイ ゾーンの RASAggregator トランクの作成を目的とするダミー クライアントとして、クライアントを識別するためのわかりやすい名前。
H.320 ゲートウェイを表す H.323 ゲートウェイを設定するときに選択したデバイス プール。ダミー クライアントに割り当てられたデバイス プールが、ゲートウェイに割り当てられたデバイス プールと異なる場合、ゲートウェイからの着信コールが Cisco Unified CallManager で拒否されることがあります。
ゲートキーパー IP アドレスのドロップダウン リスト。ダミーのゲートキーパー制御 H.323 クライアントを設定する前に、Cisco Unified CallManager でゲートキーパーを定義する必要があります。
このフィールドの入力は必須です。Cisco Unified CallManager で「ダイヤルできない」値にしてください。
テクノロジー プレフィックスは RASAggregator トランクで使用され、ゲートキーパーのゲートウェイ ゾーンに登録されます。このテクノロジー プレフィックスは、ゲートキーパーでデフォルト テクノロジー プレフィックスとして設定された値と一致している必要があります。このプレフィックスには 1# を使用することをお勧めします。
ゲートキーパーで設定されているゲートウェイ ゾーンの名前（大文字と小文字が区別されます）。
また、Cisco CallManager サービス パラメータの Send Product ID and Version ID を True に設定する必要があります。このパラメータによって、ゲートキーパーがゲートウェイ ゾーンへの H.323 コール、クライアント ゾーンからの H.323 コール、クライアント ゾーン内の H.323 コールのすべてを RASAggregator トランクに転送できるように、RASAggregator トランクをゲートキーパーに H323-GW として登録できます。
H.320 ゲートウェイは、ユーザが ISDN の宛先に到達するためにダイヤルするプレフィックスとして、テクノロジー プレフィックス（ゲートウェイではサービス プレフィックスとも呼ばれる）を使用します。コールを正しくルーティングするには、ゲートウェイのサービス プレフィックスを # 文字で始まるように設定する必要があります。たとえば、ISDN 番号に到達するためにクライアントがダイヤルするゲートウェイのサービス プレフィックスが 9 の場合、#9 としてゲートウェイでサービス プレフィックスをプロビジョニングする必要があります。この場合、H.323 クライアントが 9 と公衆網番号をダイヤルした場合（918005551212 など）、ゲートキーパーは登録済みの一致するテクノロジー プレフィックスを検索するのではなく、デフォルト テクノロジー プレフィックスと共に登録された Cisco Unified CallManager トランクにコールをルーティングします。Cisco Unified CallManager は、コールをゲートウェイにルーティングする前に、着信番号の先頭に # 文字を付加する必要があります。ゲートウェイがピアツーピア モードを使用しているため、テクノロジー プレフィックスをゲートキーパーに登録する必要がない場合は、この条件は当てはまらず、# 文字を付加する必要がありません。
ゲートキーパー ゾーンの設定
前の項では、Cisco Unified CallManager Administration でエンドポイントをプロビジョニングする方法について説明しました。適切なゾーン定義でエンドポイント ゲートキーパーを設定する必要もあります。Cisco Unified CallManager で、エンドポイントの各タイプ（クライアント、MCU、またはゲートウェイ）にゾーンを設定する必要があり、オプションとして、これらのエンドポイントに関連付けられている各デバイス プールにゾーンを設定します。
各ゾーンは、ゾーンを宛先または発信元とするコール、ゾーン内で発信されるコールのすべてを、ゾーンに登録されている RASAggregator トランクにルーティングするように設定されます。エンドポイント ゲートキーパーでゾーンを設定するには、次のコマンド構文を使用します。
コマンド引数 invia は他のゾーンからこのゾーンに発信されたコールに適用され、 outvia はこのゾーンから他のゾーンに発信するコールに適用されます。 enable-intrazone は、ゾーン内で発信したコールに適用されます。次の項で、これらのコマンドの使用方法を示します。
クライアント ゾーン
各エンドポイント ゲートキーパー内で設定の必要なクライアント ゾーンの数は、次の要素で決まります。
• H.323 クライアントの関連付け先となるデバイス プール
デバイス プールは、各 H.323 クライアントの 1 次、2 次、および 3 次 Cisco Unified CallManager サーバを決定します。すべての H.323 クライアントを同じデバイス プールに割り当てた場合、エンドポイント ゲートキーパーで定義する必要があるクライアント ゾーンは 1 つだけです。つまり、H.323 クライアントで使用するデバイス プールごとに、ゲートキーパーで個別のクライアント ゾーンを設定する必要があります。
• エンドポイント ゲートキーパーが単一の Cisco Unified CallManager クラスタにサービスを提供するのか、複数の Cisco Unified CallManager クラスタにサービスを提供するのか
各クライアント ゾーンは、特定の RASAggregator トランクにコールをルーティングするように設定されます。そのため、1 つのエンドポイント ゲートキーパーを使用して複数の Cisco Unified CallManager クラスタにサービスを提供する場合は、ゲートキーパーがサービスを提供するクラスタごとに、個別のクライアント ゾーンを定義する必要があります。
説明のために、3 つの例でクライアント ゾーンの設定方法を示します。例15-1 は、すべての H.323 クライアントが同じデバイス プールに関連付けられた単一の Cisco Unified CallManager クラスタに定義される、単一のクライアント ゾーンを示しています。例15-2 は、H.323 クライアントが 2 つの異なるデバイス プールに分割された単一の Cisco Unified CallManager クラスタを示しています。例15-3 は、H.323 クライアントがクラスタごとに 2 つの異なるデバイス プールに分割された 2 つの Cisco Unified CallManager クラスタを示しています。
（注） 以下の例で示すいくつかのコマンドは、Cisco IOS Gatekeeper で適用されるデフォルト値です。そのため、明示的に設定する必要はなく、実際の設定にも現れません。ここでは完全なものにするために含めていますが、コマンドラインの先頭に ! のマークを付けてあります。
例15-1 単一の Cisco Unified CallManager クラスタと単一のデバイス プールのクライアント ゾーン
例15-2 単一の Cisco Unified CallManager クラスタと 2 つのデバイス プールのクライアント ゾーン
例15-3 クラスタあたり 2 つのデバイス プールのある 2 つの Cisco Unified CallManager クラスタのクライアント ゾーン
以前は Cisco Multimedia Conference Manager（MCM）と呼ばれていた Cisco IOS Gatekeeper は、H.323 プロキシ機能を提供していましたが、廃止される予定です。この機能は Cisco Unified CallManager と互換性がありませんが、端末（クライアント）との間のすべてのコールにプロキシを使用するゲートキーパーのコマンドは、まだデフォルトで有効になっています。この機能はクライアント ゾーンごとに、次のコマンド構文で無効にする必要があります。
Cisco MCM プロキシは、Cisco IOS Multiservice IP-to-IP Gateway と、それに関連付けられた中継ゾーン対応 Cisco IOS Gatekeeper という新しいソリューションに置き換えられました。このマニュアルでは IP-to-IP ゲートウェイについては説明していませんが、Cisco Unified CallManager Release 4.1 以降は、RASAggregator トランクをゲートキーパーに登録することで中継ゾーンと IP-to-IP ゲートウェイの構成を活用し、効果的に IP-to-IP ゲートウェイを模倣し、ゲートキーパーが IP-to-IP ゲートウェイであるかのように、すべての invia、outvia、および enable-intrazone コールを RASAggregator トランクにルーティングしています。
H.323 クライアント ゾーンには、デフォルト テクノロジー プレフィックス以外のゾーン プレフィックスまたはテクノロジー プレフィックスを設定する必要がありません。代わりに、 invia 、 outvia 、 enable-intrazone 、および gw-type-prefix <1#> default-technology コマンドによって、発信されたすべてのコールが、コールを発信したゾーンに関連付けられた RASAggregator トランクにルーティングされます。
MCU ゾーン
各エンドポイント ゲートキーパー内で設定の必要な MCU ゾーンの数は、次の要素で決まります。
デバイス プールは、各 MCU の 1 次、2 次、および 3 次 Cisco Unified CallManager サーバを決定します。すべての MCU を同じデバイス プールに割り当てた場合、エンドポイント ゲートキーパーで定義する必要がある MCU ゾーンは 1 つだけです。つまり、MCU クライアントで使用するデバイス プールごとに、ゲートキーパーで個別の MCU ゾーンを設定する必要があります。
• エンドポイント ゲートキーパーが単一の Cisco Unified CallManager クラスタにサービスを提供するのか、複数の Cisco Unified CallManager クラスタにサービスを提供するのか
各 MCU ゾーンは、特定の RASAggregator トランクにコールをルーティングするように設定されます。そのため、1 つのエンドポイント ゲートキーパーを使用して複数の Cisco Unified CallManager クラスタにサービスを提供する場合は、ゲートキーパーがサービスを提供するクラスタごとに、個別の MCU ゾーンを定義する必要があります。
説明のために、3 つの例で MCU ゾーンの設定方法を示します。例15-4 は、すべての MCU が同じデバイス プールに関連付けられた単一の Cisco Unified CallManager クラスタに定義される単一の MCU ゾーンを示しています。例15-5 は、MCU が 2 つの異なるデバイス プールに分割された単一の Cisco Unified CallManager クラスタを示しています。例15-6 は、MCU がクラスタごとに 2 つの異なるデバイス プールに分割された 2 つの Cisco Unified CallManager クラスタを示しています。
（注） 以下の例で示すいくつかのコマンドは、Cisco IOS Gatekeeper で適用されるデフォルト値です。そのため、明示的に設定する必要はなく、実際の設定にも現れません。ここでは完全なものにするために含めていますが、コマンドラインの先頭に ! のマークを付けてあります。
例15-4 単一の Cisco Unified CallManager クラスタと単一のデバイス プールの MCU ゾーン
例15-5 単一の Cisco Unified CallManager クラスタと 2 つのデバイス プールの MCU ゾーン
例15-6 クラスタあたり 2 つのデバイス プールのある 2 つの Cisco Unified CallManager クラスタの MCU ゾーン
デフォルトでは、Cisco IOS Gatekeeper は MCU またはゲートウェイとの間のコールにプロキシを使用しないように設定されています。ただし、これらのタイプのエンドポイントでプロキシの使用を有効にした場合は、次のコマンド構文を使用して、各 MCU ゾーンで無効にする必要があります。
MCU を MCU として登録する場合は、 no use-proxy コマンドの最後で MCU 引数を使用します。MCU をゲートウェイとして登録する場合は、 gateway 引数を使用します。
H.323 MCU ゾーンには、デフォルト テクノロジー プレフィックス以外のゾーン プレフィックスまたはテクノロジー プレフィックスを設定する必要がありません。代わりに、 invia 、 outvia 、 enable-intrazone 、および gw-type-prefix <1#> default-technology コマンドによって、発信されたすべてのコールが、コールを発信したゾーンに関連付けられた RASAggregator トランクにルーティングされます。
MCU が E.164 アドレスではなくテクノロジー プレフィックスとしてサービス プレフィックスを登録する場合は、すでに説明したように、# 文字を MCU のサービス プレフィックスに付加する特殊な設定を使用します（「MCU サービス プレフィックス」を参照）。Cisco IOS Gatekeeper がテクノロジー プレフィックスへのコールの中継ゾーンを選択する方法が原因となり、エンドポイントが MCU のサービス プレフィックスをダイヤルしたときに、ゲートキーパーが登録済みの一致するテクノロジー プレフィックスを見つけると、コールは失敗します。ゲートキーパーが一致するテクノロジー プレフィックスを見つけずに、コールを発信したゾーンに関連付けられている RASAggregator トランクにコールをルーティングするように、クライアントが # 文字をダイヤルしないようにする必要があります。
H.320 ゲートウェイ ゾーン
各エンドポイント ゲートキーパー内で設定の必要な H.320 ゲートウェイ ゾーンの数は、次の要素で決まります。
• H.320 ゲートウェイの関連付け先となるデバイス プール
デバイス プールは、各 H.320 ゲートウェイの 1 次、2 次、および 3 次 Cisco Unified CallManager サーバを決定します。すべてのゲートウェイを同じデバイス プールに割り当てた場合、エンドポイント ゲートキーパーで定義する必要があるゲートウェイ ゾーンは 1 つだけです。つまり、H.320 ゲートウェイで使用するデバイス プールごとに、ゲートキーパーで個別のゲートウェイ ゾーンを設定する必要があります。
• エンドポイント ゲートキーパーが単一の Cisco Unified CallManager クラスタにサービスを提供するのか、複数の Cisco Unified CallManager クラスタにサービスを提供するのか
各ゲートウェイ ゾーンは、特定の RASAggregator トランクにコールをルーティングするように設定されます。そのため、1 つのエンドポイント ゲートキーパーを使用して複数の Cisco Unified CallManager クラスタにサービスを提供する場合は、ゲートキーパーがサービスを提供するクラスタごとに、個別のゲートウェイ ゾーンを定義する必要があります。
説明のために、3 つの例でゲートウェイ ゾーンの設定方法を示します。例15-7 は、すべての H.320 ゲートウェイが同じデバイス プールに関連付けられた単一の Cisco Unified CallManager クラスタに定義される単一のゲートウェイ ゾーンを示しています。例15-8 は、ゲートウェイが 2 つの異なるデバイス プールに分割された単一の Cisco Unified CallManager クラスタを示しています。例15-9 は、ゲートウェイがクラスタごとに 2 つの異なるデバイス プールに分割された 2 つの Cisco Unified CallManager クラスタを示しています。
（注） 以下の例で示すいくつかのコマンドは、Cisco IOS Gatekeeper で適用されるデフォルト値です。そのため、明示的に設定する必要はなく、実際の設定にも現れません。ここでは完全なものにするために含めていますが、コマンドラインの先頭に ! のマークを付けてあります。
例15-7 単一の Cisco Unified CallManager クラスタと単一のデバイス プールのゲートウェイ ゾーン
例15-8 単一の Cisco Unified CallManager クラスタと 2 つのデバイス プールのゲートウェイ ゾーン
例15-9 クラスタあたり 2 つのデバイス プールのある 2 つの Cisco Unified CallManager クラスタのゲートウェイ ゾーン
デフォルトでは、Cisco IOS Gatekeeper はゲートウェイとの間のコールにプロキシを使用しないように設定されています。ただし、これらのタイプのエンドポイントでプロキシの使用を有効にした場合は、次のコマンド構文を使用して、各 H.320 ゲートウェイ ゾーンで無効にする必要があります。
H.320 ゲートウェイ ゾーンには、ゾーン プレフィックスを設定する必要がありません。代わりに、 invia 、 outvia 、 enable-intrazone 、および gw-type-prefix <1#> default-technology コマンドによって、発信されたすべてのコールが、コールを発信したゾーンに関連付けられた RASAggregator トランクにルーティングされます。
また、すでに説明したように、ゲートウェイのサービス プレフィックスに # 文字を付加する特殊な設定を使用する必要があります（「ゲートウェイ サービス プレフィックス」を参照）。Cisco IOS Gatekeeper がテクノロジー プレフィックスへのコールの中継ゾーンを選択する方法が原因となり、エンドポイントがゲートウェイのサービス プレフィックスをダイヤルしたときに、ゲートキーパーが登録済みの一致するテクノロジー プレフィックスを見つけると、コールは失敗します。ゲートキーパーが一致するテクノロジー プレフィックスを見つけずに、コールを発信したゾーンに関連付けられている RASAggregator トランクにコールをルーティングするように、クライアントが # 文字をダイヤルしないようにする必要があります。
ゾーン サブネット
すでに説明したように、H.323 仕様では、単一のゲートキーパーで複数のゾーンを管理できます。ただし、ゲートキーパーには、デバイスから Registration Request（RRQ）を受信したときに、そのエンドポイントをどのゾーンに配置するかを判断する手段が必要です。RRQ メッセージには、エンドポイントがどのゾーンへの登録を希望するかを示す Gatekeeper Identifier フィールドが含まれています。ただし、多くの H.323 ビデオ エンドポイントはこのフィールドを設定せず、ゲートキーパーに複数のゾーンが定義されている場合、ゲートキーパーはエンドポイントを配置するゾーンを認識できません。そのため、 zone subnet コマンドを使用して、エンドポイントと関連付けられたゾーンをゲートキーパーに示す必要があります。このコマンドは、各ゾーンへの登録が許可される IP アドレスまたは IP の範囲を定義します。コマンド構文には、ネットワーク マスクの入力が必要です。そのため、32 ビット（/32）のネットワーク マスクを入力して特定のホスト アドレスを指定するか、それよりも小さなネットワーク マスクを指定してアドレスの範囲を指定します。
MCU、H.320 ゲートウェイ、および Cisco Unified CallManager サーバは通常、固定 IP アドレスを使用しますが、H.323 クライアントは DHCP アドレスを使用できます。そのため、 zone subnet コマンドは MCU ゾーンおよびゲートウェイ ゾーンにのみ定義し、クライアント ゾーンは任意の IP アドレスを許可できるようにオープンのままにすることをお勧めします。例15-10 で示すように、Cisco Unified CallManager サーバが MCU ゾーンおよびゲートウェイ ゾーンに登録することも許可する必要があることに注意してください。
（注） 以下の例で示すいくつかのコマンドは、Cisco IOS Gatekeeper で適用されるデフォルト値です。そのため、明示的に設定する必要はなく、実際の設定にも現れません。ここでは完全なものにするために含めていますが、コマンドラインの先頭に ! のマークを付けてあります。
例15-10 の設定では、MCU ゾーンの MCU および RASAggregator を MCU ゾーンに登録することを明示的に許可しています。また、ゲートウェイ ゾーンのゲートウェイおよび RASAggregator をゲートウェイ ゾーンに登録することを明示的に許可しています。また、MCU およびゲートウェイをクライアント ゾーンに登録できないように明示的に拒否しています。その他のすべての IP アドレス（クライアント ゾーンの RASAggregator を含む）は、クライアント ゾーンに登録することが暗黙的に許可されています。
エンドポイントの存続可能時間
エンドポイントは、簡易な Registration Request（RRQ）をゲートキーパーに定期的に送信し、登録状態を維持します。これらの RRQ を送信する間隔は、Time to Live（TTL; 存続可能時間）値とも呼ばれます。エンドポイントは、使用する TTL を RRQ の本体で指定できます。ゲートキーパーは、エンドポイントが要求した TTL 値を受け入れて Registration Confirm（RCF）応答でエコーするか、異なる TTL 値を RCF で指定してエンドポイントの要求を上書きします。
TTL 値が RRQ で指定されていない場合は、ゲートキーパーが RCF 応答で指定する必要があります。この場合、エンドポイントはゲートキーパーが指定した TTL に従います。Cisco IOS Gatekeeper は、エンドポイントが指定したすべての TTL 値に従います。ただし、多くの H.323 ビデオ エンドポイントは、RRQ で TTL 値を指定しません。この場合、Cisco IOS Gatekeeper は、デフォルト値として 1800 秒（30 分）の TTL 値を指定します。Cisco IOS Gatekeeper は、エンドポイントからメッセージを受信せずに TTL 間隔の 3 倍の時間（3 ∗ 30 分 = 90 分）が経過すると、そのエンドポイントの登録をフラッシュします。
TTL 値を大きくすると、静的 IP アドレスを使用しない H.323 クライアントで問題が発生することがあります。たとえば、デフォルト TTL 値の 1800 秒を使用した場合、クライアントをネットワークから切断し、別のロケーションに移動して異なる DHCP アドレスを受け取った場合、TTL 間隔の 3 倍が経過して、ゲートキーパーがそのエンドポイントの元の登録をフラッシュするまで、ゲートキーパーへの登録に失敗します（Registration Reject（RRJ）の理由値「duplicate alias」）。
したがって、ネットワークに悪影響が生じない範囲で、TTL 値はできるだけ小さくするようにしてください。Cisco IOS Gatekeeper では、60 秒から 3600 秒の任意の値に TTL 値を設定できます。ほとんどの場合、60 秒でうまく動作するはずです。ただし、すでにゲートキーパーの使用率が高い場合は、TTL をデフォルトの 1800 秒から 60 秒に調整すると、負荷が過大になることがあります。
エンドポイント ゲートキーパーの要約
この項では、エンドポイント ゲートキーパーに関する重要なポイントを要約し、前の例で使用したテクニックを組み合せたいくつかの設定例を示します。
• エンドポイントのタイプ（クライアント、MCU、および H.320 ゲートウェイ）ごとに、エンドポイント ゲートキーパーに個別のゾーンを設定します。エンドポイントが複数のデバイス プールに関連付けられている場合は、エンドポイントのタイプごとに複数のゾーンを設定します。
• 各ゾーンに登録する RASAggregator トランクを設定します。このトランクは、Cisco Unified CallManager Administration でゲートキーパー制御 H.323 クライアントを設定したときに、自動的に作成されます。ただし、非ゲートキーパー制御 H.323 クライアント、H.323 MCU、および H.320 ゲートウェイに対しては、ゾーンの RASAggregator トランクを作成するために、ダミーのゲートキーパー制御 H.323 クライアントを設定する必要があります。
• RASAggregator トランクを IP-to-IP ゲートウェイとしてゲートキーパーに登録するには、デバイス パラメータ Send Product ID and Version ID を True に設定します。このように設定すると、ゲートキーパーは各ローカル ゾーン定義に適用される invia 、 outvia 、 enable-intrazone 、および gw-type-prefix <1#> default-technology の各コマンドを使用することによって、ゾーンを宛先または発信元とするコール、またはゾーン内で発信されるコールのすべてについて、RASAggregator を選択できます。
• エンドポイント ゾーンにゾーン プレフィックスを関連付ける必要はありません。エンドポイントが何をダイヤルしても、ゲートキーパーは一致するゾーン プレフィックスまたはテクノロジー プレフィックスを見つけることなく、コールを発信したゾーンに関連付けられている RASAggregator トランクにコールをルーティングする必要があります。ゲートキーパーで、ダイヤルされた番号と MCU またはゲートウェイのテクノロジー プレフィックスが間違って一致することを防ぐために、すべての MCU およびゲートウェイ サービス プレフィックスを # 文字でマスクし、MCU またはゲートウェイに関連付けられているルート パターンに # 文字を付加します。
• Gatekeeper Identifier（ゾーン名）の指定機能をサポートしていない H.323 エンドポイントがある場合は、登録するゾーン サブネットを設定します。
• すべてのゾーンで、古い MCM プロキシの使用を無効にします。
• ゲートキーパーの負荷が過大にならない範囲で、できるだけ低い値でエンドポイント登録の存続可能時間（TTL）を設定します。ゲートキーパーが数百のエンドポイント登録を処理するような極端なケースでは、TTL を 60 秒に設定すると、管理できない量の RAS トラフィックが発生することがあります。小規模な環境では、60 秒でうまく動作するはずです。
例15-11 は、単一の Cisco Unified CallManager クラスタにサービスを提供するエンドポイント ゲートキーパーの設定を示しています。このクラスタは、単一のデバイス プールを使用して、すべての H.323 ビデオ エンドポイント タイプにサービスを提供します。
（注） 以下の例で示すいくつかのコマンドは、Cisco IOS Gatekeeper で適用されるデフォルト値です。そのため、明示的に設定する必要はなく、実際の設定にも現れません。ここでは完全なものにするために含めていますが、コマンドラインの先頭に ! のマークを付けてあります。
例15-11 単一のクラスタと単一のデバイス プールのエンドポイント ゲートキーパー設定
例15-12 は、2 つの Cisco Unified CallManager クラスタにサービスを提供するエンドポイント ゲートキーパーの設定を示しています。各クラスタには、H.323 ビデオ エンドポイント用に 2 つの異なるデバイス プールがあります。
例15-12 2 つのクラスタと 2 つのデバイス プールのエンドポイント ゲートキーパー設定
Cisco Unified CallManager 4.0 からの移行
『 Cisco IP Video Telephony SRND for Cisco Unified CallManager 4.0 』に記載されている設計方法から、この章で示した設計方法への移行プロセスは、次の基本手順で構成されます。
1. 新しいゲートキーパー制御 H.323 クライアント機能を利用するように、H.323 クライアントを Cisco Unified CallManager Administration で再設定する。
2. H.323 クライアント、MCU、および H.320 ゲートウェイ ゾーンに使用していた H.225 ゲートキーパー制御トランクを削除し、ダミーのゲートキーパー制御 H.323 クライアントを作成して RASAggregator トランクと置き換える。
3. 新しい中継ゾーン定義構成を使用するようにエンドポイント ゲートキーパーを再設定し、H.323 クライアント、MCU、およびゲートウェイ ゾーンに適用されていたすべてのゾーン プレフィックスを削除する。
4. 必要に応じて、プレフィックスの先頭に # 文字を含めるように、すべての MCU および H.320 ゲートウェイ サービス プレフィックスを修正する。
これらの各手順を実行すると、既存の H.323 ビデオ エンドポイントのサービスが中断されることがあります。そのため、これらの設定変更は慎重に計画し、管理者が既存の H.323 ビデオ エンドポイントの中断を最小限に抑えられるときに実行する必要があります。
アプリケーション
Cisco Unified Communications には、Cisco Unified CallManager の機能を拡張し、高度な機能と他の通信メディアとの統合を提供する幅広いアプリケーションのポートフォリオが用意されています。これらの多くのアプリケーションは、特にビデオをサポートしていなくても、IP ビデオ テレフォニー デバイスと組み合せて使用できます。たとえば、Cisco Unified CallManager Release 4.1 は、TAPI/JTAPI プロトコルを使用する CTI アプリケーションのビデオ チャネルのネゴシエーションをサポートしていませんが、CTI アプリケーションをビデオ コールと組み合せて使用する妨げにはなりません。この項では、シスコおよびサードパーティ製のアプリケーションのいくつかについて検討し、ビデオ コールに対して高度なコール処理を提供できるかどうかについて説明します。
CTI アプリケーション
Cisco Emergency Responder
Cisco Emergency Responder（ER）は、緊急コール（911）を適切な Public Safety Answering Point（PSAP）にルーティングします。また、PSAP が事故のあった物理的な正しい場所に応答し、コールが切断された場合はコールバックできるように、発信元デバイスの正しい発信元回線 ID を PSAP に提供します。Cisco ER は、JTAPI を使用して Cisco Unified CallManager に統合されています。緊急コールは CTI ルート ポイント経由で Cisco ER にルーティングされ、Cisco ER は、コールの転送先 PSAP および表示する発信元回線 ID を判断します。Cisco ER は、Simple Network Management Protocol（SNMP; 簡易ネットワーク管理プロトコル）と Cisco Discovery Protocol（CDP; シスコ検出プロトコル）を使用して、エンドポイントが接続されている物理ポートと特定の Cisco Catalyst Ethernet スイッチを検出することによって、ネットワークの各エンドポイントを追跡し、物理的な場所を判断します。CDP を使用できない場合は、代わりに IP サブネットを使用してエンドポイントを探すように Cisco ER を設定できます。Cisco ER は、この情報をスイッチの物理的な場所に関連付け、データベースに情報を格納します。
Cisco Unified Video Advantage と Cisco IP Video Phone 7985 はどちらも、Cisco ER 検出の目的で CDP をサポートしています。Cisco Unified Video Advantage は、スイッチに CDP メッセージを直接送信しませんが、このサポート用として、関連付けられた Cisco Unified IP Phone を利用します。その結果、Video Telephony ユーザが 911 をダイヤルすると、Cisco ER は正しい PSAP にコールをルーティングできます。
Sony 社製および Tandberg 社製の SCCP エンドポイントは CDP をサポートしないため、Cisco ER は、IP サブネットでこれらのエンドポイントを追跡する必要があります。これにより、Cisco ER はコールを正しい PSAP にルーティングできます。
H.323 ビデオ会議クライアントは CDP をサポートしないため、Cisco ER は、IP サブネットでこれらのエンドポイントを追跡する必要があります。これにより、Cisco ER はコールを正しい PSAP にルーティングできます。ただし、H.323 デバイスのコールを Cisco ER でルーティングするには、H.323 デバイスが Empty Capabilities Set（ECS）プロシージャをサポートしている必要があります。H.323 エンドポイントが Cisco Unified CallManager からの ECS の受信をサポートしていない場合、Cisco ER が処理する 911 へのコールは失敗します。
Cisco Unified CallManager Assistant
Cisco Unified CallManager Assistant を使用すると、アシスタントが、関連するマネージャに対応できます。Unified CM Assistant は、JTAPI を使用して Cisco Unified CallManager に統合されています。Unified CM Assistant は特にビデオ対応というわけではありませんが、ビデオ対応の電話機でも Unified CM Assistant は問題なく使用できます。Unified CM Assistant がコールを処理し、コールが最終的な宛先デバイスに転送されると、コールの 2 つのデバイスが互いに直接通信し、この時点でビデオ チャネルを確立できます。たとえば、ビデオ対応エンドポイントがマネージャのディレクトリ番号をダイヤルし、アシスタントが Unified CM Assistant アプリケーションを使用してコールをカバーした場合、コールの最初の処理ではビデオは確立されていないことがあります。しかし、アシスタントが発信者をマネージャに転送すると、Cisco Unified CallManager がビデオ チャネルをネゴシエートできるようになります。ただし、H.323 デバイスを Unified CM Assistant と相互運用するには、Empty Capabilities Set（ECS）プロシージャをサポートしている必要があります。H.323 エンドポイントが Cisco Unified CallManager からの ECS の受信をサポートしていない場合、Unified CM Assistant が代行受信したコールは、アシスタントがマネージャにコールを転送しようとしたときに失敗します。
Cisco IP 音声自動応答装置と Cisco IP Contact Center
Cisco IP 音声自動応答装置（IP IVR）および Cisco IP Contact Center（IPCC）は、JTAPI を使用して Cisco Unified CallManager に統合されています。ビデオ対応デバイスが IVR アプリケーション（ヘルプ デスクなど）にコールを発信した場合、発信者がアプリケーション サーバに接続している間（発信者が IVR メニューをブラウズしている間、またはヘルプデスクのメンバーがコールを受け付けるまでキューで待機している間）、通信は音声のみになります。ただし、IVR アプリケーションがコールを最終的な宛先に転送すると、その時点でビデオ チャネルをネゴシエートできるようになります。H.323 デバイスを Cisco Unified IP-IVR および IPCC と相互運用するには、Empty Capabilities Set（ECS）プロシージャをサポートしている必要があります。H.323 エンドポイントが Cisco Unified CallManager からの ECS の受信をサポートしていない場合、Cisco Unified IP-IVR または IPCC が代行受信したコールは、アプリケーションが最終的な宛先に発信者を転送しようとしたときに失敗します。
IVR アプリケーションは、多くの場合、DTMF トーンを使用して IVR メニューのオプションを選択します。別の方法としては音声認識があり、電話機のキーを押す代わりに、発信者が IVR サーバに向かってコマンドを発音します。Cisco Unified IP-IVR と IPCC はどちらも、JTAPI を使用して Cisco Unified CallManager に統合されているため、アウトオブバンド シグナリング メッセージで DTMF トーンを渡します。現在、市販されている多くの H.323 デバイスは、インバンド DTMF トーンを使用しています。このような H.323 クライアントでは、DTMF を使用して IP IVR または IPCC メニューをナビゲートすることはできません。ただし、これらの H.323 クライアントは、IVR サーバが対応していれば、音声認識を使用できます。Cisco Unified Video Advantage などのビデオ対応デバイス、Sony 社製または Tandberg 社製の SCCP デバイス、および DTMF に H.245 英数字アウトオブバンド シグナリングを使用する H.323 エンドポイントは、DTMF トーンを使用して IVR メニューをナビゲートできます。
Cisco Attendant Console
Cisco Attendant Console は、JTAPI を使用して Cisco Unified CallManager に統合されています。Attendant Console は、着信コールを処理する管理用デバイスとして使用されます。Attendant Console は、特にビデオをサポートしているわけではありませんが、コールが最終的な宛先に転送されると、ビデオ チャネルをネゴシエートできるようになります。ただし、H.323 デバイスを Attendant Console と相互運用するには、Empty Capabilities Set（ECS）プロシージャをサポートしている必要があります。H.323 エンドポイントが Cisco Unified CallManager からの ECS の受信をサポートしていない場合、Attendant Console が代行受信したコールは、コンソール担当者が最終的な宛先に発信者を転送しようとしたときに失敗します。
Cisco Personal Assistant
Cisco Personal Assistant（PA）には、主に次の 2 つの機能があります。
• DTMF トーンまたは音声コマンドによるダイヤル サポート
• 時刻、発信者 ID 情報などの要素に基づいてユーザがプログラムするコール ルーティングのプリファレンス
どちらの機能でも、コールが PA サーバに接続されている間は、ビデオは確立されていません。しかし、PA がコールを最終的な宛先に転送すると、ビデオ チャネルをネゴシエートできるようになります。H.323 デバイスを PA と相互運用するには、Empty Capabilities Set（ECS）プロシージャをサポートしている必要があります。H.323 エンドポイントが Cisco Unified CallManager からの ECS の受信をサポートしていない場合、PA が代行受信したコールは、アプリケーションが最終的な宛先に発信者を転送しようとしたときに失敗します。
Cisco IP SoftPhone および Cisco IP Communicator
Cisco IP SoftPhone は、TAPI を使用して Cisco Unified CallManager と統合されており、スタンドアロン ソフトフォンまたは関連付けられている SCCP ハードウェア電話機を制御するソフトウェア インターフェイスとして設定できます。Cisco IP SoftPhone は、特にビデオをサポートしているわけではありませんが、Cisco Unified Video Advantage クライアントが関連付けられている IP Phone と組み合せて使用できます。Cisco IP SoftPhone は、Sony 社製または Tandberg 社製の SCCP デバイスの制御には使用できません。
Cisco IP Communicator は、SCCP クライアントなので Cisco 7970 シリーズ IP Phone のように動作するという点で、IP SoftPhone と異なります。
コラボレーション ソリューション
T.120 アプリケーション共有
T.120 プロトコルを使用して、ドキュメント、ホワイトボード、およびテキストを会議の参加者で共有するビデオ会議エンドポイントがあります。Cisco Unified CallManager は、T.120 チャネルのネゴシエートをサポートしません。T.120 の代わりに、Cisco MeetingPlace やサードパーティのコラボレーション ソリューション（Placeware、Web-Ex、IBM E-Collaborate など）のような Web ベースのコラボレーション ソリューションを使用することをお勧めします。
Cisco Unified MeetingPlace
Cisco Unified MeetingPlace は、ハイエンドな音声およびビデオ会議ソリューションと、会議のスケジューリングおよび参加に使用する Web ベースのフロントエンドを結合します。詳細については、「Cisco Unified MeetingPlace の統合」の章を参照してください。
無線ネットワーキング ソリューション
ビデオは帯域幅に大きな影響を与えるため、802.11b などの共有無線メディアをビデオ エンドポイントに使用することはお勧めしません。
Cisco Aironet 802.11b ネットワーキング ソリューション
Tandberg 社製 T-1000 モデル エンドポイントには、Cisco Aironet PCMCIA 802.11b Wireless Adapter を取り付け可能な PCMCIA インターフェイスが用意されています。ただし、ビデオ エンドポイントが、実稼働中の IP Phone と無線帯域幅を共有しないように注意する必要があります。ビデオは帯域幅の大半を消費するため、ビデオ、音声、およびデータを同じ無線メディアでサポートすることは困難です。
Cisco Unified Video Advantage は、関連付けられた IP Phone への物理イーサネット接続に依存します。通常、ユーザが物理イーサネット インターフェイスと、同じ PC にインストールされた Aironet 802.11b Wireless Adapter の両方を使用することはありません。このような設定は、無線インターフェイスがネットワークへの優先パスになった場合に、Cisco Unified Video Advantage がこのインターフェイス経由では関連付けられないため、Cisco Unified Video Advantage で問題が発生する原因になります。常に、物理イーサネット インターフェイスを優先パスにすることをお勧めします。また、ユーザが IP Phone の背面の PC ポートに接続するときは、間違って優先されないように Aironet Adapter を無効にするように指示してください。
Cisco Unified Wireless IP Phone 7920
Cisco Unified Wireless IP Phone 7920 は、ビデオをサポートしません。ビデオ エンドポイントからも Cisco Unified Wireless IP Phone 7920 にコールを発信できますが、音声のみのコールとしてネゴシエートされます。無線 IP Phone ユーザは、コールの保留、転送、または会議への参加ができます。発信者が H.323 ビデオ エンドポイントの場合、これらの補足サービスを機能させるには、Empty Capabilities Set（ECS）プロシージャをサポートしている必要があります。
XML サービス
現在、特に Cisco Unified Video Advantage クライアント ソリューション、Cisco IP Video Phone 7985、または Sony 社製や Tandberg 社製の SCCP エンドポイント用に作成された XML アプリケーションはありません。ただし、これらのエンドポイントのうち、Cisco IP Video Phone 7985 および Sony 社製エンドポイント以外は、XML アプリケーションをサポートします。Cisco VT Advantage は Cisco Unified IP Phone を使用するため、これらの電話機モデルでサポートされる XML アプリケーションは VT Advantage でも動作します。
Tandberg 社製 SCCP エンドポイントは XML をサポートしますが、現在、すべての XML アプリケーションが Tandberg 社製エンドポイントで動作するわけではありません。たとえば、Cisco エクステンション モビリティおよび Berbee InformaCast 製品は、現在、Sony 社製または Tandberg 社製の SCCP エンドポイントで動作しない代表的な 2 つの XML アプリケーションです。これらのアプリケーションをサポートするには、エンドポイントのファームウェア アップグレードと、場合によっては Cisco Unified CallManager Administration の変更が必要になります。
フィードバック