IP ビデオ テレフォニー
IP ビデオ テレフォニー
発行日;2013/04/24 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 38MB) | フィードバック

目次

IP ビデオ テレフォニー

この章の新規情報

IP ビデオ テレフォニー ソリューションのコンポーネント

管理に関する考慮事項

プロトコル

エンドポイント

リージョン

コール アドミッション制御

ロケーションベースのコール アドミッション制御(CAC)

トポロジ対応ロケーション(RSVP CAC)

Quality of Service

ビデオ コールをオーディオとして再試行(Retry Video Call as Audio)

ダイヤル プラン(Dial Plan)

トランク

セキュリティ

マルチポイント会議

アドホック ビデオ会議

Meet-Me ビデオ会議

スケジュールされたビデオ会議

Voice-Activated(話者切り替え)

Continuous-Presence(分割表示)

セキュア会議

アドホック会議用の MCU リソース

メディア リソース グループとメディア リソース グループ リスト

インテリジェント ブリッジ選択機能

Cisco Business Edition

H.323 および SIP MCU リソース

MCU のサイジング

ダイヤルイン会議の IVR

ゲートキーパー

エンドポイント ゲートキーパー

H.323 クライアントのプロビジョニング

H.323 MCU のプロビジョニング

H.320 ゲートウェイのプロビジョニング

ゲートキーパー ゾーンの設定

サポートされるゲートキーパー プラットフォーム

エンドポイント ゲートキーパーの要約

アプリケーション

CTI アプリケーション

Cisco Emergency Responder

Cisco Unified IP Interactive Voice Response と Cisco Unified Contact Center

コラボレーション ソリューション

T.120 アプリケーション共有

CiscoUnifiedMeetingPlace

ビデオの相互運用性

無線ネットワーキング ソリューション

IP ビデオ テレフォニー

企業は、Unified Communication システムを導入することで、外部接続に対する PSTN へのコールに加え、企業内のポイントツーポイント コールや会議などの音声サービスを幅広く使用できます。そのようなネットワークにビデオを追加すると、次のアプローチを使用できます。

「ビデオ コールをサポートするために音声デバイスを有効にする」

「音声ネットワークを既存のビデオ ネットワークと統合する」

ビデオ コールをサポートするために音声デバイスを有効にする

企業は、カメラをサポートするために既存の IP 電話を有効にしたり、PC ベース システム上のソフトウェアを使用して IP 電話と組み合わせたビデオ機能を提供したりすることがあります。可能な場合は、ビデオをサポートする新しいデバイスを配置できるため、既存の呼制御インフラストラクチャはそのまま保持されます。

このアプローチには、次の利点があります。

既存のダイヤル プラン:企業は、既存のダイヤル プランと既存のコール エージェントを使用してネットワークでビデオ コールをサポートできます。

コール アドミッション制御:企業内の 1 つのコール アドミッション制御エンティティは、ネットワーク帯域幅の使用を最適化する方法を提供します。

既存のネットワーク:企業は、企業のネットワーク上でビデオに対応するために必要な帯域幅を追加することで、既存のネットワーク トポロジを使用できます。

ユーザ:企業は、既存のすべてのユーザによるビデオ コールの発信を有効にできます。

ビデオ コーデック:ビデオ コーデックを標準化すると、企業はビデオ コールの帯域幅使用量を最適化できるため、必要なトランスコーディング リソースまたはトランスレーティング リソースを減らすことができます。

既存の IP 電話:企業は、ビデオを追加するためにソフト クライアントを追加するか、カメラと IP 電話を接続することで、既存の IP 電話を利用できます。

音声ネットワークを既存のビデオ ネットワークと統合する

会議室のビデオ コールまたは経営幹部用ビデオ デバイスに既存のビデオ ネットワークを使用している企業は、ビデオ ネットワークと音声ネットワークを統合できるため、企業のユーザがビデオ デバイスを呼び出すことができるようになります。

このアプローチには、次の利点があります。

別個のダイヤル プラン:ビデオ ネットワークの別個のダイヤル プランを使用すると、企業はビデオ会議ブリッジ、ビデオ PSTN ゲートウェイなどのビデオ リソースのプランを作成できます。ユーザは、プレフィックスをダイヤルして他のネットワークのリソースにアクセスできます。

既存のネットワーク:企業は、既存の重複したネットワーク トポロジを別個のビデオ ネットワークと音声ネットワークとして使用できます。

管理とモニタリング:音声およびビデオの別個の管理とモニタリングにより、トラブルシューティングおよび問題の解決がさらに容易になります。

トランク プロトコル:企業は、音声とビデオのコール エージェント間で相互作用する必要なプロトコルを選択できます。これにより、企業はコール転送、DTMF、MWI、他の機能に同様の方法を使用できます。

コール エージェント機能に依存しない:企業は、コールのビデオ トラフィックのビット レートの最適化など、ビデオ コール エージェントがビデオ エンドポイントに提供する機能を活用できます。これらの機能は音声コール エージェントの機能に依存しません。

企業は、上記のアプローチのいずれかを選択したり、上記のアプローチを組み合わせて企業のユーザがビデオ コールを発信したりできます。

ビデオは Cisco Unified Communications Manager(Unified CM)に完全に統合され、シスコおよびシスコの戦略的パートナーから多くのビデオ エンドポイントも入手できるようになりました。たとえば、Cisco Jabber は、Cisco Unified IP Phone と同様に簡単に配置、管理、および使用できます。

この章の新規情報

表 12-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 12-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明箇所
改訂日

Cisco Unified Communications システム Release 9.0 向けに大幅更新

この章の各項で説明

2012 年 6 月 28 日

IP ビデオ テレフォニー ソリューションのコンポーネント

Cisco IP ビデオ テレフォニー ソリューションは、Cisco Unified Communications Manager(Unified CM)、Cisco Multipoint Control Unit(MCU)、Session Initiation Protocol(SIP)および Skinny Client Control Protocol(SCCP)による電話会議、Cisco H.320 ゲートウェイ、Cisco IOS H.323 ゲートキーパー、Cisco TelePresence System EX60 および EX90、Cisco Cius、Cisco Unified IP Phone 9900 シリーズ、ビデオ機能付き Cisco Unified IP Phone(Cisco Unified IP Phone 9900 シリーズなど)、Cisco Jabber、サードパーティ製 SCCP ビデオ エンドポイント ソリューション、および Polycom、Lifesize、Sony といったパートナーが扱う既存の H.323 または SIP 準拠製品で構成されます。(図 12-1を参照)。

図 12-1 IP ビデオ テレフォニーのコンポーネント

 

管理に関する考慮事項

この項では、ビデオ テレフォニーに関係する Unified CM Administration の次の構成要素について説明します。

「プロトコル」

「エンドポイント」

「リージョン」

「コール アドミッション制御」

「Quality of Service」

「ビデオ コールをオーディオとして再試行(Retry Video Call as Audio)」

「ダイヤル プラン(Dial Plan)」

「トランク」

「セキュリティ」

プロトコル

Cisco Unified CM は多数のプロトコルをサポートしますが、ビデオを Unified CM で使用する場合 SIP が優先呼制御プロトコルになります。任意のデバイスから任意の別のデバイスを呼び出すことができますが、ビデオは SCCP、H.323、および SIP デバイスでのみサポートされます。具体的には、Cisco Unified CM Release 9. x において、次のプロトコルではビデオがサポートされません。

コンピュータ テレフォニー インテグレーション(CTI)アプリケーション(TAPI および JTAPI)

メディア ゲートウェイ コントロール プロトコル(MGCP)

したがって、現在 Unified CM でサポートされるコールのタイプは、 表 12-2 に示すとおりです。

表 12-2 Unified CM Release 9.x でサポートされるコールのタイプ

発信デバイス タイプ
着信デバイス タイプ
SCCP
H.323
MGCP
TAPI/JTAPI
SIP

SCCP

音声とビデオ

音声とビデオ

音声のみ

音声のみ

音声とビデオ

H.323

音声とビデオ

音声とビデオ

音声のみ

音声のみ

音声とビデオ

MGCP

音声のみ

音声のみ

音声のみ

音声のみ

音声のみ

TAPI/JTAPI

音声のみ

音声のみ

音声のみ

音声のみ

音声のみ

SIP

音声とビデオ

音声とビデオ

音声のみ

音声のみ

音声とビデオ

表 12-3 は、現在 Unified CM でサポートされている音声とビデオのアルゴリズムおよびプロトコルを示しています。

表 12-3 Unified CM Release 9.x でサポートされる機能

H.323
SCCP
SIP

H.261

H.261

H.261

H.263、H.263+

H.263、H.263+

H.263、H.263+

H.264

H.264

H.264

G.711 A-law および mu-law

G.711 A-law および mu-law

G.711 A-law および mu-law

G.723.1

G.723.1

G.723.1

G.728

G.728

G.728

G.729、G.729a、G.729b、G.729ab

G.729、G.729a、G.729b、G.729ab

G.729、G.729a、G.729b、G.729ab

G.722

G.722

G.722

G.722.1

iLBC

iSAC

AAC-LD

H.224 遠端カメラ制御(Unified CM でサポートされますが、すべてのエンドポイントでサポートされるわけではありません)
プロトコル インターワーキングなし

H.224 遠端カメラ制御(Unified CM でサポートされますが、すべてのエンドポイントでサポートされるわけではありません)プロトコル インターワーキングなし

H.224 遠端カメラ制御(Unified CM でサポートされますが、すべてのエンドポイントでサポートされるわけではありません)
プロトコル インターワーキングなし

アウトオブバンド DTMF(H.245 英数字)

RFC2833 AVT Tones(SIP コールへの H.323 クラスタ間トランクの場合のみ)

アウトオブバンド DTMF

RFC2833 AVT Tones

RFC2833 AVT Tones Unsolicited SIP Notify KPML


) シスコでは、可能であれば、新規および既存の H.323 デバイスを Cisco TelePresence Video Communication Server(VCS)にゲートキーパーとして登録し、H.323 と SIP のインターワーキングを使用して Unified CM に接続し、SIP トランクによって VCS と Unified CM をピアリングすることを推奨します。


エンドポイント

IP 電話、TelePresence パーソナル ユニット、リッチ メディア ソフトウェア クライアントが Cisco Unified Communications システムにおける最も一般的なビデオ エンドポイントです。ユーザの IP 電話にビデオを追加するために、企業は Cisco Unified IP Phone 9971 にカメラを使用することや、Cisco TelePresence System EX60 または EX90 パーソナル TelePresence ユニットなどのエンドポイントを使用すること、Cisco Audio Session Tunnel(CAST)をサポートするソフトウェア クライアントを実行している PC に IP 電話を接続することができます。また、企業は Cisco Jabber などのソフト クライアントを配置することも可能です。さらに、Cisco Unified CM を使用して H.323 や SIP などのプロトコルをサポートするサードパーティ製エンドポイントを配置することもできます。

可能な場合は、エンドポイントの呼制御プロトコルとして H.323 の代わりに SIP を使用する必要があります。ただし、H.323 を使用するかは、主にデータ共有(たとえば、ビデオ コール時に PC 画面を共有する)に H.239 を使用するかどうか、あるいはエンドポイント間にセキュア メディアがあるビデオ コールのエンドポイント間でセキュア トークンを渡すために H.235 を使用するかどうかで決定されます。プレゼンスなどのユーザ機能のタイプにより、エンドポイントで使用されるプロトコルのタイプが決定されます。プロトコル選択は主にエンドポイントで必要な機能のサポートに依存します。

Cisco Unified CM によりサポートされる SIP ビデオ デバイスには、Cisco 9900 Series IP Phone、Cisco E20 Video Phone、Cisco Cius、TelePresence パーソナル ユニット(Cisco EX60 および EX90 など)、サードパーティ製 SIP デバイス(拡張)、または汎用デスクトップおよびルーム システムのビデオ デバイスがあります。Cisco 9900 Series IP Phone では、そのデバイスのビデオ機能設定によってビデオを有効にできます。Cisco E20 Video Phone の設定は、その電話自体にあります。Cius は、前面にカメラがあるコールのためのビデオをサポートします。サードパーティ製 SIP デバイス(拡張)の電話タイプや汎用ビデオ デバイスは、Polycom 社製、Lifesize 社製、Sony 社製および他の製造業者のエンドポイントに対する追加オプションです。これらのエンドポイントに関して Unified CM の設定は以前のバージョンから変更されていませんが、Cisco E20 Video Phone、Cisco Cius、Tandberg 社製のエンドポイントとサードパーティ製のエンドポイントをより効率的にサポートするために Unified CM の動作が最適化されています。それらのエンドポイントからのアーリー オファーを処理して MTP リソースを使用せずに SIP トランクを介してそれらのエンドポイントを処理する機能などの機能により、コール シグナリングが最適化され、コールのメディアを確立する時間が短縮されます。また、2 つのデバイス間の最適なビデオ コールを実現するために追加のシグナリング(エンドポイント間で渡される RTCP やパラメータなど)が処理および送信されるように、Unified CM では、それらのエンドポイントの HD コールもサポートしています。Cius は、結合された場合はビデオ電話機として、また分離された場合は Wi-Fi タブレットとして柔軟に使用できるため、追加の考慮事項が必要ですが、音声には Wi-Fi ネットワークが推奨され、またコールには適切な帯域幅を使用する必要があります。無線の展開の詳細については、「モバイル ユニファイド コミュニケーション」の章を参照してください。

各種 IP 電話と Cisco ソフトウェア クライアントの詳細については、「Unified Communications エンドポイント」の章を参照してください。Cisco Unified Personal Communicator、Client Services Framework などのソフトウェア クライアントの詳細については、「Cisco Collaboration クライアントおよびアプリケーション」の章を参照してください。

ユーザがビデオ コールを発信するための適切な IP 電話とエンドポイントの選択は、目的の機能、求められている視覚効果、ビデオ コールに必要な機能によって異なります。使用可能なオプションにより、さまざまなタイプのユーザにクライアントを柔軟に設計および配置できます。

リージョン

リージョンを設定するときは、Unified CM Administration の 2 つのフィールド、[Audio Codec] と [Video Bandwidth] を設定します。オーディオ設定ではコーデック タイプを指定し、ビデオ設定ではコールごとの帯域幅の量を指定します。ただし、表記は異なりますが、[Audio Codec] フィールドと [Video Bandwidth] フィールドは、実際には似た機能を実行します。[Audio Codec] フィールドは、音声のみのコールおよびビデオ コールの音声チャネルに許可される最大ビット レートを定義します。たとえば、リージョンの [Audio Codec] を G.711 に設定した場合、Unified CM はそのリージョンの音声チャネルに許可される最大帯域幅として 64 kbps を割り当てます。この場合、Unified CM は G.711、G.722、G.728、iLBC、または G.729 を使用するコールを許可します。ただし、[Audio Codec] を G.729 に設定すると、Unified CM は、音声チャネルに許可される帯域幅の最大量として 8 kbps だけを割り当てます。この場合、iLBC、G.728、G.711、および G.722 はすべて 8 kbps より多く帯域幅を使用するため、G.729 を使用するコールだけが許可されます。


) 両方のエンドポイントが G.711 と G.722 をサポートしている場合、ワイドバンド コーデックである G.722 がネゴシエートされます。


[Video Bandwidth] フィールドは、コールのビデオ チャネルに許可される最大ビット レートを定義します。ただし、従来のビデオ会議製品での慣例に従い、このフィールドに使用する値には、音声チャネルの帯域幅も含めます。たとえば、G.711 の音声を使用する 384 kbps のコールを許可するには、[Video Bandwidth] フィールドに 320 kbps ではなく 384 kbps を設定します。


) [Audio Codec] 設定は、ビデオ コールの音声チャネルにも適用されます。


つまり、[Audio Codec] フィールドは音声のみのコールおよびビデオ コールの音声チャネルに使用する最大ビット レートを定義し、[Video Bandwidth] フィールドは、ビデオ コールに許可される最大ビット レート(コールの音声部分を含む)を定義します。

各デバイスは特定の音声コーデックのみをサポートするため、正しい音声コーデックの帯域幅制限を選択することが重要です。リージョンを G.729 に設定した場合、ビデオ会議デバイスによっては、このタイプのコーデックをサポートできないものがあります。たとえば、Cisco Unified IP Phone 9971 と G.729 を使用するよう設定された Cisco TelePresence System EX90 エンドポイント セットとの間のコールは、失敗するか、Unified CM がコールに音声トランスコーディング リソースを割り当てます。(特定のエンドポイントでサポートされるコーデックの最新リストについては、そのエンドポイントの製品マニュアルを参照してください)。

Cisco Unified CM は、パススルー コーデックによるビデオ ストリームをサポートしながら、ビデオ コールのオーディオ ストリームのトランスコーディングが可能です。パススルー コーデックは、トランスコーディングが必要なストリームには使用できないため、ビデオ ストリームにのみ使用されます。パススルー コーデックを使用するには、次の 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 を使用する別のリージョンを設定する必要があります (図 12-2 を参照)。この方式を使用すると、必要なリージョンの数が増えますが、望ましいコーデックと帯域幅の割り当てが得られます。

図 12-2 ビデオ コールに G.711 を使用し、音声のみのコールに G.729 を使用

 


) ビデオを禁止するリージョンのペアを設定できます。このリージョン ペアにある 2 つのビデオ対応デバイスが相互に通話しようとした場合、[Retry Video Call as Audio] がオンになっていれば、音声のみとして接続されます。オフになっている場合は、AAR 再ルーティング ロジックが実行されます。


表 12-4 は、設定例とその結果を示しています。

表 12-4 さまざまなリージョン設定のシナリオ

リージョン設定
[Retry Video as Audio] の設定
結果

リージョンでビデオを許可する。

有効

ビデオ コールは許可される。

リージョンでビデオを許可する。

無効

ビデオ コールは許可される。

リージョンでビデオを許可しない。

有効

ビデオ コールは音声として処理される。

リージョンでビデオを許可しない。

無効

AAR が設定されていない場合、ビデオ コールは失敗する(ビジー トーンが再生され、「Bandwidth Unavailable」メッセージが表示される)。

[Video Call Bandwidth] フィールドには、1 ~ 32,256 kbps の値を指定できます。ただし、H.323 および H.320 ビデオ会議デバイスとの互換性を維持するために、このフィールドの値を常に 56 または 64 kbps の倍数で入力することを推奨します。したがって、このフィールドの有効な値としては 112 kbps、128 kbps、224 kbps、256 kbps、336 kbps、384 kbps などがあります。

エンドポイントで要求されるコール速度がリージョンに設定されている帯域幅値を超えた場合、Unified CM は自動的に、リージョン設定で許可された値に適合するようにコールをネゴシエートします。たとえば、H.323 エンドポイントが別の H.323 エンドポイントを 768 kbps で呼び出しているが、リージョンは最大 384 kbps を許可するように設定されていたとします。発信側からの着信 H.225 セットアップ要求はコール速度として 768 kbps を提示しますが、Unified CM は、着信側への発信 H.225 セットアップ メッセージで、この値を 384 kbps に変更します。そのため、着信側エンドポイントは、開始するコールが 384 kbps であると認識し、このレートでコールがネゴシエートされます。発信側エンドポイントは、要求した帯域幅として 768 kbps を提示しますが、ネゴシエートされた帯域幅は 384 kbps になります。

ただし、リージョンの [Video Bandwidth] を「None」に設定した場合は、着信側デバイスの [Retry Video Call as Audio] が有効かどうかに応じて、Unified CM はコールを終了するか(この場合、H.225 Release Complete メッセージを発信側に送信)、音声のみのコールとして通過を許可します (「ビデオ コールをオーディオとして再試行(Retry Video Call as Audio)」を参照)。

コールのビデオ解像度が高くなるにつれて、必要な帯域幅も大きくなります。リージョン設定のビデオ帯域幅には、CIF ビデオ解像度が必要な場合は 384 kbps を、VGA 解像度が必要な場合には 768 kbps を、720p 解像度のビデオ コールが必要な場合には 1.5 Mbps を設定することを推奨します。ほとんどのビデオ エンドポイントには可変ビット レート エンコーダが備えられていますが、Cisco Unified IP Phone 9900 シリーズなどのビデオ電話機には固定ビット レートのビデオ用エンコーダが備えられています。固定ビット レートのエンコーダでは、より良いモーション ビデオおよびエラー復元性が提供されます。

一部のエンドポイントでは、サポートする解像度の数は限られています。たとえば、そのようなデバイスからのビデオ コールの解像度を VGA に制限する場合、ビデオ コール帯域幅のリージョン設定を 768 kbps にして、デバイスをこのリージョンに関連付けることができます。この場合、高解像度のエンドポイントへのコールまたは MCU への会議では、ビデオ用として VGA 解像度をネゴシエートします。

ワイヤレス機能を備えた一部の Unified Communications エンドポイント(たとえば、Cisco Unified IP Phones 9900 シリーズや Cisco Cius)では、ワイヤレス メディア用のさまざまな帯域幅設定を指定できます。詳細および設計上の考慮事項については、「ワイヤレス LAN インフラストラクチャ」を参照してください。

コール アドミッション制御

Cisco Unified CM は、ロケーション間のコールで使用できる帯域幅の量を制限するための 2 種類の方法をサポートします。

「ロケーションベースのコール アドミッション制御(CAC)」

「トポロジ対応ロケーション(RSVP CAC)」

ロケーションベースのコール アドミッション制御(CAC)

Cisco Unified CM は、設定された場所のビデオ コールをサポートし、Cisco Unified CM ロケーションのリンク オプションによって、そのロケーションとそのリンクを介して接続されている別のロケーションとの間のすべてのコールに許可される合計帯域幅を定義します。Cisco Unified CM 9. x は、ロケーション間の関係を作成することとマルチ ホップ モデルを許可することによって、複雑なトポロジのネットワーク モデリングを可能にします。Unified CM 9. x で追加された別の特色は、専用のイマーシブ帯域幅プールです。サービス パラメータ Use Video Bandwidth Pool for Immersive Video Calls true に設定された場合、Unified CM は IP ビデオ テレフォニー(ビデオ会議)帯域幅とは別に、イマーシブ ビデオ コールの帯域幅使用状況をトラッキングします。IP ビデオ テレフォニー トラフィックがイマーシブ ビデオ用に予約された帯域幅を枯渇させることがないよう、ビデオ帯域幅のトラッキングを分離することを推奨します。こうして、イマーシブ ビデオのコール アドミッション制御を実行するかどうかを、管理者がイマーシブ ビデオのロケーション コンフィギュレーション内にある [unlimited bandwidth] オプションによって選択できるようになります。イマーシブ ビデオに対するコール アドミッション制御を実行するかどうかは、望まれるユーザ エクスペリエンスによって決定します。TelePresence ユーザが会議をスケジュールするときには帯域予約が発生しないため、イマーシブ ビデオのコール アドミッション制御によって、スケジュールされたテレプレゼンス コールが帯域幅不足のために拒否される結果になる可能性もあります。

静的ロケーションを設定するときは、Unified CM Administration で [Audio Bandwidth]、[Video Bandwidth]、[Immersive Bandwidth] の 3 つのフィールドを設定します。ただし、リージョンとは異なり、静的ロケーションの [Audio Bandwidth] が音声のみのコールにのみ適用される一方、[Video Bandwidth] と [Immersive Bandwidth] はビデオ コールのオーディオ チャネルとビデオ チャネルの両方に適用されます。帯域幅プールは、別々に維持されます。これは、両方のタイプのコールが帯域幅の単一割り当てを共有すると、音声コールが使用可能な帯域幅のすべてを使用してビデオ コール用の帯域幅が残らなくなる(または、その逆になる)可能性が高いためです。また、音声とビデオの個別の帯域幅プールは、ネットワーク上のスイッチおよびルータでのキューの設定方法に対応します。通常、音声トラフィック用のプライオリティ キューと、ビデオ トラフィック用の独立したプライオリティ キューまたはクラスベース WFQ があります。(詳細については、「WAN の Quality of Service(QoS)」の章を参照してください)

すべての帯域幅プールには、None、Unlimited または数値使用可能フィールドの 3 種のオプションがあります。ただし、これらのフィールドに入力する値は、2 つの異なる計算モデルを使用します。[Audio Bandwidth] フィールドに入力する値には、コールに必要なレイヤ 3 ~ 7 のオーバーヘッドを含める必要があります。たとえば、ロケーションとの間で単一の G.729 コールを許可する場合は、値として 24 kbps を入力します。G.711 コールの場合は 80 kbps の値を入力します。逆に、[Video Bandwidth] および [Immersive 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 ロケーションに次の値を設定します。

ロケーション
必要な音声コールの数
[Audio Bandwidth] フィールドの値
必要なビデオ コールの数
[Video Bandwidth] フィールドの値

San Francisco

4、G.729 を使用

96 kbps(または 24 kbps で 4)

1、384 kbps

384 kbps

Dallas

8、G.711 を使用

640 kbps(または 80 kbps で 8)

2、384 kbps

768 kbps

エンドポイントで要求されるコール速度がロケーションに設定されている値を超えた場合、リージョンの場合とは異なり、Unified CM がロケーション設定で許可された値に適合するように、自動的にコール速度をネゴシエートすることはありません。コールは拒否されるか、音声のみのコールとして再試行されます(着信側デバイスで [Retry Video as Audio] 設定が有効の場合)。そのため、リージョンのビデオ帯域幅は、ロケーションのビデオ帯域幅の値よりも低い値に設定する必要があります。たとえば、2 つのリージョン(リージョン A とリージョン B)があり、これら 2 つのリージョン間のビデオ帯域幅が 768 kbps に設定されている場合、リージョン A のデバイスがビデオ帯域幅が 384 kbps に設定されているロケーションにあると、これら 2 つのリージョン間のすべてのコールが失敗するか、音声のみのコールになります([Retry Video Call as Audio] の設定による)。

トポロジ対応ロケーション(RSVP CAC)

Cisco Unified CM は、2 地点間のパスに利用可能な十分の帯域幅があるかを判定するため、リソース予約プロトコル(RSVP)に基づくトポロジ対応ロケーションもサポートしています。RSVP はネットワーク リソースの実際の可用性に基づいたホップごとのチェックを可能にします。これは複雑なトポロジに対応し、リンク障害時は動的に調整を実行するもので、RSVP アプリケーション ID の使用によって音声コール帯域幅とビデオ コール帯域幅の分離をサポートします。

RSVP ベースのロケーションでは、RSVP ポリシーの概念が採用されています。多くのポリシー オプションがありますが、主に次の 2 つのカテゴリに分けられます。

コールを完了するために、ビデオ ストリームの RSVP 予約が必須。コールは失敗するか(ビジー トーンが再生され、「Bandwidth Unavailable」メッセージが表示される)、自動代替ルーティング(AAR)によってコールの再ルーティングが試行されます。


) コールは PSTN 経由で再ルーティングされますが、ビデオは使用できません。


ビデオ ストリームの RSVP 予約が望ましい。

最初に、リージョンに設定された音声コーデックとビデオ帯域幅で、ビデオ コールの最大速度(ビット レート)が定義されます。予約要求として、最大ビット レートを使用してコールのオーディオ ストリームとビデオ ストリームの RSVP 予約が Cisco RSVP Agent から送信されます。ビデオ ストリームの RSVP 予約が失敗した場合、Unified CM は RSVP ポリシーの設定をチェックし、このコールの処理方法を決定します。オーディオ ストリームのポリシーがオプションの場合、コールは音声のみとして継続します。オーディオ ストリームの RSVP ポリシーが必須の場合は、オーディオ ストリームも RSVP 予約の取得に失敗した場合を除いて、コールは音声のみとして継続します。予約に失敗した場合、コールは失敗するか(ビジー トーンが再生され、「Bandwidth Unavailable」メッセージが表示される)、自動代替ルーティング(AAR)によってコールの再ルーティングが試行されます


) ビデオ優先ポリシーを使用しているときに、ビデオ予約に失敗した場合、コールは音声のみとして完了します。ただし、ユーザはビデオが失敗した原因を示す、視覚的な表示または音声によるフィードバックを受けることができません。


さらに、Cisco Unified CM 9.x は、Cisco IOS 15.2T 以降を実行中の Cisco IOS 拡張メディア ターミネーション ポイント(MTP)使用時に、RTCP、FECC および BFCP のパススルー サポートを提供します。このパススルー サポートでは、RTCP、FECC および BFCP 機能の使用を継続しながら、ビデオ コールに RSVP CAC を使用できるため、Unified CM のビデオ コールに特に効果的です。


) 静的ロケーションと RSVP ベースのロケーションは、異なるモデルを使用して、音声コールとビデオ コールを区別します。詳細については、「コール アドミッション制御」の章を参照してください。


Quality of Service

シスコでは、さまざまなビデオ アプリケーションに異なる DSCP マーキングを使用することを推奨します。Unified CM 9. x は、イマーシブ ビデオ トラフィックおよびビデオ会議(IP ビデオ テレフォニー)トラフィックへの、異なる DSCP マーキングをサポートします。デフォルトでは、Unified CM 9. x は TelePresence(イマーシブ ビデオ)コールに CS4、ビデオ(IP ビデオ テレフォニー)コールに AF41 を推奨 DSCP 値として事前設定しています。図 12-3に、推奨 DSCP 値を使用した統合環境でのさまざまなビデオ アプリケーションを示します。

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

 

QoS のオーバーヘッドの計算

音声とは異なり、リアルタイム IP ビデオ トラフィックは通常ややバースト性があるの可変ビット レート ストリームです。音声と異なり、ビデオにはネットワーク オーバーヘッドを計算するための明確な公式がありません。ビデオ パケット サイズとレートがビデオ画像そのものの動きの度合いに比例して異なるためです。ネットワーク管理者から見れば、帯域幅はレイヤ 2 で常にプロビジョニングされますが、パケット サイズの変動や、エンドツーエンドで通過するパケットのレイヤ 2 メディアの違いのため、レイヤ 2 でプロビジョニングされる必要がある実際の帯域幅を計算するのは難しくなります。ただし、十分にテストされ広く用いられている無難な規則として、ビデオ帯域幅を 20 % 多めにプロビジョニングするというものがあります。これにより、10 % のバーストと、レイヤ 2 からレイヤ 4 へのオーバーヘッドに対応します。

Quality of Service の詳細については、「ネットワーク インフラストラクチャ」の QoS 情報を参照してください。

ビデオ コールをオーディオとして再試行(Retry Video Call as Audio)

このチェックボックスは、ビデオと H.323 および SIP デバイスをサポートする SCCP エンドポイント タイプで使用できます(クライアント、ゲートウェイ、およびすべてのタイプの H.323 トランク)。このオプションがアクティブ(オン)のときに、デバイスに到達できるだけの帯域幅がない場合(たとえば、Unified CM リージョンまたはロケーションで、そのコールのビデオが許可されない場合)、Unified CM はそのコールを音声のみのコールとしてリトライします。このオプションが非アクティブ(オフ)のときは、Unified CM はコールを音声のみとして再試行することなく、コールを失敗させるか、自動代替ルーティング(AAR)パスが設定されている場合は可能な限り再ルーティングします。デフォルトでは、このリトライ オプションは有効(オン)です。

この機能は、次のシナリオだけに適用されます。

ビデオを許可しないようにリージョンが設定されている。

ビデオを許可しないようにロケーションが設定されている。または、ロケーションが RSVP ポリシーを使用しない場合は、要求されたビデオ速度が、そのロケーションで使用可能なビデオ帯域幅を超えている。

Unified CM クラスタ間のコールの場合、要求されたビデオ速度がゲートキーパーのゾーン帯域幅制限を超えている。

Retry Video Call as Audio オプションは、終端(着信側)デバイスでのみ有効です。そのため、発信側デバイスでは宛先ごとに異なるオプション(再試行または AAR)を使用できる柔軟性があります。

帯域幅の制限が原因でビデオ コールが失敗した場合、自動代替ルーティング(AAR)が有効であれば、Unified CM は失敗したコールをビデオ コールとして AAR の宛先に再ルーティングしようとします。AAR が有効でない場合、失敗したコールによって、発信者にビジー トーンとエラー メッセージが送信されます (図 12-4 を参照)。

図 12-4 ビデオ コールで起こり得るシナリオ

 

AAR の使用方法の詳細については、「コール アドミッション制御」の章を参照してください。

ダイヤル プラン(Dial Plan)

IP ビデオ テレフォニーの観点では、特定のユーザ エクスペリエンスが持つダイヤル プランの影響を考慮することが重要です。たとえば、Cisco Unified CM 9.0 では URI ダイヤリングのサポートが追加されました。しかし、URI ダイヤリング ユーザと DN ユーザが 9.0 以前の Unified CM クラスタに混在する場合、[calling and connected party info format] を [deliver DN only in connected party] に設定して、DN 情報だけを提供するようクラスタ間を接続するトランクを設定する必要があります。同様に、Unified CM 9.0 以降のリリースと統合された Cisco Video Communication Server(VCS)は、変換を使用する必要なく URI ダイヤル プラン スキームを活用できますが、バージョン 9.0 およびそれ以前のリリースの複数の Unified CM クラスタと統合された VCS では、依然として多くの変換が必要になります。VCS 内の URI に 9.0 以前の Unified CM から到達する必要があるためです。したがって、VCS が 9.0 以前の Unified CM と統合されている状況では、VCS 内で数値ダイヤル プランを使用することを推奨します。

URI ダイヤリングに関するその他の情報については、「ダイヤル プラン」を参照してください。

トランク

Cisco Unified CM は、さまざまなタイプのトランクをサポートしています。しかし、最新リリースの Unified CM で使用できる SIP トランク機能によって、SIP は新規のトランク接続にも既存のトランク接続にも適した選択肢になりました。シスコでは、可能であれば、新規および既存の H.323 デバイスを Cisco VCS にゲートキーパーとして登録し、H.323 と SIP のインターワーキングを使用して Unified CM に接続し、SIP トランクによって VCS と Unified CM をピアリングすることを推奨します。インターワーキングに VCS を使用する場合、帯域幅の影響を考慮するのは重要です。インターワークされているコールのメディアは VCS を通過するからです(メディア フロースルー)。

VCS の使用が不可能な状況では、コールをビデオ エンドポイントおよびゲートウェイにルーティングする H.323 ゲートキーパーとのインターワーキングに H.323 トランクを使用できます。H.323 トランクには、H.239、H.235 などの H.323 ビデオ ポイントで使用される数多くのビデオ機能のパススルー機能もあります。RASAggregator トランクにより、Unified CM は Cisco IOS ゲートキーパーに登録されているエンドポイントのコールのコール制限および帯域幅拡張などの機能を提供できます。

SIP トランクは、SIP ネットワークとの相互接続を提供できます。これらのトランクは、トランク間でのビデオおよび SRTP をサポートしています。Unified CM は、Cisco TelePresence Video Communication Server(VCS)などのビデオ通信サーバのより緊密な統合を可能にします。この機能により、高解像度のコールのサポートが拡張され、Cisco VCS、Cisco Video デバイス、およびサードパーティ製ビデオ エンドポイントで必要となる高度なシグナリングも Unified CM 経由で動作できるようになります。さらに、Cisco Unified CM SIP トランクは、メディア ターミネーション ポイント(MTP)がなくてもビデオ コールのアーリー オファーをサポートします。これが重要となるのは、コールが複数の呼制御サーバを通過する配置、または双方向メディア パスを確立するためのコールのカットスルー時間が重要となる配置の場合です。詳細については、「Cisco Unified CM トランク」の章を参照してください。

展開方法によっては、ネットワークで DNS SRV を使用する場合があります。DNS SRV を使用する Cisco TelePresence VCS 展開の場合、Unified CM SIP トランクも DNS SRV を使用できます。そのような展開では、DNS サーバのスケーラビリティおよび冗長性を考慮する必要があり、またロード バランシングおよび冗長性の機能は、要求を処理する DNS サーバに依存することにも注意する必要があります。このように、Unified CM トランクのロード バランシングおよび冗長性は、DNS サーバのロード バランシングおよび冗長性に追加されます。

セキュリティ

Unified CM 9. x は、H.323 ビデオ デバイスとの連携時に H.235 パススルーをセキュリティ メカニズムとしてサポートしており、Cisco SIP ビデオ エンドポイントのビデオ コールのビデオ メディア ストリームおよびオーディオ メディア ストリームに対する Secure Real-Time Transport Protocol(SRTP)暗号化のサポートを追加しました。ただし、H.235 から SRTP へのインターワーキングは現在のところ Unified CM でサポートされていません。ビデオ展開で H.235 と SRTP が必要な場合はいつでも、H.323 エンドポイントを Cisco VCS にゲートキーパーとして登録して SIP-H.323 インターワーキングを使用し、Unified CM 側の SIP ビデオ エンドポイントの SRTP および VCS へのセキュアな SIP トランクを提供することを推奨します。VCS について H.235 を使用するよう H.323 ビデオ エンドポイントが設定されている場合、コールは暗号化されたエンドツーエンドにすることができます。図 12-5 では、Unified CM 9. x と VCS が連携して、SIP と H.323 混在ネットワークでセキュアなエンドツーエンドを提供しています。

図 12-5 SIP-H.323 混在ネットワークでエンドツーエンドのセキュリティを提供する Unified CM および VCS

 

Unified CM でのセキュリティに関する詳細については、「Unified Communications のセキュリティ」を参照してください。

マルチポイント会議

3 者以上が同じビデオ コールに同時に参加するには、マルチポイント コントロール ユニット(MCU)が必要です。Cisco Unified CM では、SCCP、H.323、および SIP モードで Cisco MCU がサポートされています。各プロトコルでは異なる機能が提供されるため、プロトコルと MCU の統合は展開される会議サービスのタイプに基づいて実行される必要があります。3 種類のビデオ会議サービス タイプがあります。

「アドホック ビデオ会議」

「Meet-Me ビデオ会議」

「スケジュールされたビデオ会議」

シグナリング プロトコルに関係なく、MCU は、音声ストリームとビデオ ストリームを各参加者から受信し、これらのストリームをすべての他の参加者に、組み合わせたビューで送信するという同じ基本機能を提供します。マルチポイント テレビ会議のビューには、次の 2 つのタイプがあります。

「Voice-Activated(話者切り替え)」

「Continuous-Presence(分割表示)」

アドホック ビデオ会議

アド ホック ビデオ会議とは、即座に行われる会議を表します。この会議は、IP Phone の Confr 機能を呼び出しているユーザが作成することがあります。Cisco Unified CM 9. x は、この種のビデオ会議向けの SCCP と SIP MCU の統合をサポートしています。ブリッジ選択プロセスで MCU を利用可能にするために、Unified CM 内でメディア リソースとして定義しておく必要があります。Cisco Unified CM 9. x は、会議ブリッジ経由の SIP ベースの TelePresence MCU をサポートし、これにより高い解像度をサポートできるアドホック会議用の MCU 統合の方法も提供します。

アドホック MCU リソースを呼び出すのは、次のイベントだけです。

SCCP エンドポイントまたは SIP エンドポイント(IP Phone やサードパーティ製 SCCP ビデオ エンドポイントなど)のユーザが、[Conf] ソフトキー、[Join] ソフトキー、または [cBarge] ソフトキーを押してアドホック会議を呼び出した。

SCCP エンドポイントまたは SIP エンドポイント(IP Phone やサードパーティ製 SCCP ビデオ エンドポイントなど)のユーザが、[MeetMe] ソフトキーを押して、予約なしの Meet-Me 会議を呼び出した。

ソフト フォン モードの Cisco Cius または Cisco ビデオ ソフトウェア クライアント(Cisco Jabber など)のユーザが、会議に複数コールを参加させるために Join または Conference 機能を使用した。

これらのタイプの会議の参加者には、任意のタイプのエンドポイント(サポートされる任意のゲートウェイ タイプを介して Unified CM がサポートする任意のシグナリング プロトコルを使用するビデオ デバイスおよび非ビデオ デバイス)が含まれます。ただし、アドホック MCU リソースを呼び出せるのは、SCCP エンドポイント、SIP ベースの Cisco Unified IP Phone、または Cisco ビデオ ソフトウェア クライアントだけです。つまり、H.323 ビデオ エンドポイントは アドホック MCU リソースを呼び出せませんが、SCCP ビデオ エンドポイントがリソースを呼び出し、H.323 ビデオ参加者をコールに参加させることはできます。たとえば、SCCP エンドポイントのユーザは、[Conf] ソフトキーを押し、H.323 クライアントのディレクトリ番号をダイヤルして、もう一度 [Conf] ソフトキーを押すと、トランザクションを完了できます。H.323 クライアントは、参加者として SCCP MCU 会議に参加します。


) このマニュアルの旧版では、付加サービス(コールの保留など)をサポートしない H.323 デバイス用の代替設定について説明しました。詳細については、http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/uc7_0.html で入手可能な『Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 7.x』の「SCCP MCU Resources」の項を参照してください。


Meet-Me ビデオ会議

Meet-Me ビデオ会議の場合、会議の開催者が事前に IP Phone の MeetMe 機能を呼び出して会議を作成します。会議の開催者は参加者に MeetMe 番号を配布し、ダイヤル インできるようにします。Unified CM 9. x は、Meet-Me ビデオ会議用に SCCP と SIP MCU の統合をサポートしています。ブリッジ選択プロセスで MCU を利用可能にするために、Unified CM 内でメディア リソースとして定義しておく必要があります。

スケジュールされたビデオ会議

スケジュールされたビデオ会議は、開催者が IVR にダイヤルして会議を作成するか、ミドルウェア時間管理システムがスケジュールすることで開始されます。会議の作成や論理制御について、Unified CM はこのシナリオで MCU やミドルウェアで使用できるサービスに依存します。Unified CM 9 .x は、スケジュールされたビデオ会議用に H.323 と SIP MCU をサポートしています。シスコでは、Cisco TelePresence システム ビデオ会議サーバ(VCS)にゲートキーパーとして登録した H.323 MCU を使用することと、この種の会議のサポート提供のため VCS から Unified CM に H.323 と SIP の連携を設定することを推奨します。

Voice-Activated(話者切り替え)

話者切り替え会議は、すべての参加者の音声ストリームとビデオ ストリームを取得し、主要な発言者を決定し、主要な発言者のビデオ ストリームだけをすべての他の参加者に送信します。参加者には、主要な発言者の全画面イメージが表示されます(現在の発言者には、前の主要な発言者が表示されます)。すべての参加者からの音声ストリームが混合され、全員が他の全員の発言を聞くことができますが、ビデオは主要な発言者のものだけが表示されます。

次のいずれかの方法で、主要な発言者を選択できます。

Voice-Activated モード

このモードを使用すると、MCU は、最も声が大きく、発言が長い会議参加者を判断して、主要な発言者を自動的に選択します。声の大きさを判断するために、MCU は各参加者の音声信号の強さを計算します。会話中に条件が変わると、MCU は自動的に新しい主要な発言者を選択し、その参加者が表示されるようにビデオを切り替えます。ホールド タイマーによって、ビデオの頻繁な切り替えが防止されます。主要な発言者になるには、指定された秒数以上発言し、他のすべての参加者よりも際立つ必要があります。

MCU の Web ベースの会議制御ユーザ インターフェイスによる主要な発言者の手動選択

会議コントローラ(議長)は MCU の Web ページにログインし、参加者を強調表示することで、その参加者を主要な発言者として選択できます。この処理によって音声アクティビティ検出は無効になり、議長が新しい主要な発言者を選択するか、Voice-Activated モードを再度有効にするまで、主要な発言者は固定されます。

参加者リストを自動的に 1 人ずつ循環するように MCU を設定

この方式を使用すると、MCU は設定された時間だけ各参加者で止まり、リスト上の次の参加者に切り替えます。会議コントローラ(議長)は、Web インターフェイスでこの機能をオンまたはオフにできます(オフにすると、Voice-Activated モードが再度有効になります)。

Continuous-Presence(分割表示)

Continuous-Presence 会議では、一部の参加者またはすべての参加者が合成ビューで同時に表示されます。ビューには、さまざまなレイアウトで参加者を表示できます。各レイアウトには、長方形の 1 つを Voice-Activated にする機能があり、合成ビューに表示できる長方形の数よりも参加者の方が多い会議で役立ちます。たとえば、4 画面のビューを使用していて、コールの参加者が 5 人のとき、同時に表示される参加者は 4 人だけです。この場合、長方形の 1 つを Voice-Activated にすると、主要な発言者に応じて参加者 4 と参加者 5 をその長方形で切り替えることができます。他の 3 つの長方形に表示される参加者は固定で、すべての長方形は、会議制御 Web ベース ユーザ インターフェイスで操作できます。


) Asynchronous Continuous Presence は使用しないことを強く推奨します。



) MCU が内蔵された H.323 および SIP クライアントの場合、Unified CM は、H.323 クライアントで別のコールの生成を許可しません。そのため、内蔵 MCU の機能は無効になります。


セキュア会議

Unified CM 9. x は、SIP MCU 統合タイプによるセキュア会議をサポートしています。セキュア会議の場合、Unified CM は会議スケジュールについて HTTPS を使用して MCU と通信し、コール シグナリングとメディア ペイロードの暗号化にはそれぞれ TLS と SRTP を使用します。ただし、会議は、すべての参加者のビデオ エンドポイントが暗号化をサポートしている場合に限りセキュアになります。

セキュア会議の詳細については、「Unified Communications のセキュリティ」を参照してください。

アドホック会議用の MCU リソース

[MeetMe] ソフトキーによる予約なしの会議の場合は、他のエンドポイントで使用されているシグナリング プロトコルが保留および転送をサポートしている必要はありません。これらのタイプの会議では、各エンドポイントが、会議を開始したエンドポイントにより割り当てられた MeetMe ダイヤルイン番号をダイヤルします。

図 12-6 は、H.323 エンドポイントと Cisco IP Phone を同じアドホック会議に参加させる方法を示します。この例では、SCCP エンドポイントで [Conf] ソフトキーによって会議が開始され、3 人のメンバーが招待されています。

図 12-6 SCCP エンドポイント、SIP エンドポイント、および H.323 エンドポイントの間のアドホック会議

 

アドホック会議は、使用される会議ブリッジに応じて、Voice-Activated モードと Continuous-Presence をサポートします。

メディア リソース グループとメディア リソース グループ リスト

SCCP または SIP 電話機のユーザが [Conf]、[Join]、または [MeetMe] ソフトキーをアクティブにした場合、Unified CM では、メディア リソース マネージャを使用して会議ブリッジが選択されます。会議ブリッジまたは MCU リソースは、メディア リソース グループ(MRG)で設定されます。メディア リソース グループ リスト(MRGL)は、優先順位順に並べられた MRG のリストを指定するものであり、エンドポイントと関連付けることができます。メディア リソース マネージャでは、エンドポイントの MRGL を使用して、会議ブリッジが選択されます。リソースをグループ化する方法は完全に自由ですが、地理的な配置(特定のサイトのすべてのエンドポイントで最も近い会議ブリッジが使用されるようにする方法)、またはエンドポイントのタイプ(ビデオ対応エンドポイントがビデオ対応 MCU を使用し、音声だけのエンドポイントは別の会議ブリッジ リソースを使用するようにする方法)でグループ化することが一般的です。

Cisco Unified CM には、インテリジェント ブリッジ選択機能があります。この機能を使用すると、会議のエンドポイントの能力に基づいて、会議リソースを選択できます。ビデオ会議の起動時に複数のビデオ エンドポイントが存在し、ビデオ会議リソースが使用可能な場合、インテリジェント ブリッジ選択機能は、会議に使用するリソースを選択します。ビデオ会議リソースが 1 つも使用できない場合、またはビデオ会議にビデオ対応エンドポイントが 1 つも存在しない場合、インテリジェント ブリッジ選択機能は、会議で使用可能なオーディオ リソースを選択します。インテリジェント ブリッジ選択機能は、セキュア会議に対しセキュアな会議ブリッジを選択する付加機能を提供します。ただし、セキュアな会議ブリッジ接続は、デバイス機能に依存します。Unified CM は、ビデオまたはオーディオ会議ブリッジの代わりに、セキュアな会議ブリッジを割り当てることがあります。インテリジェント ブリッジ選択機能の動作は、Unified CM におけるサービス パラメータの設定によって、柔軟に変更できます。

インテリジェント ブリッジ選択機能は、会議ブリッジの他の選択方式と比べて、次のような利点があります。

会議タイプによる会議ブリッジ選択:セキュア、ビデオ、または音声会議

メディア リソース設定の簡素化

他のブリッジ選択方式では音声のみの会議に占有されかねない、MCU ビデオ ポートの適正な使用

すべての会議ブリッジ リソースおよび MCU を 1 つの MRGL に含めることができます。インテリジェント ブリッジ選択機能では、音声会議だけでよいのか、あるいはビデオ会議を行う必要があるのかに基づいて、会議ブリッジが選択されます。

Unified CM では、サービス パラメータ設定によって指定可能な、もう 1 つの会議ブリッジ選択方法がサポートされています。このモードでは、Unified CM において次の基準がここに示した順序で適用されて、使用する会議ブリッジ リソースが選択されます。

1. メディア リソース グループ リスト(MRGL)にリストされているメディア リソース グループ(MRG)の優先順位

2. 選択された MRG の中で、最も使用されていないリソース

電話機の MRGL の最上位に MCU を配置すると、ビデオ対応の参加者がいない音声だけの会議にも、この MCU が常に選択されます。このシナリオでは、音声のみの会議で MCU リソースが浪費され、ビデオ会議の要求が発生したときに使用できなくなることがあります。


) Meet-Me 会議は、インテリジェント ブリッジ選択機能を使用しません。


インテリジェント ブリッジ選択機能

Cisco Unified CM には、インテリジェント ブリッジ選択機能があります。この機能を使用すると、会議のエンドポイントの能力に基づいて、会議リソースを選択できます。ビデオ会議の起動時に複数のビデオ エンドポイントが存在し、ビデオ会議リソースが使用可能な場合、インテリジェント ブリッジ選択機能は、会議に使用するリソースを選択します。ビデオ会議リソースが 1 つも使用できない場合、またはビデオ会議にビデオ対応エンドポイントが 1 つも存在しない場合、インテリジェント ブリッジ選択機能は、会議で使用可能なオーディオ リソースを選択します。

インテリジェント ブリッジ選択機能は、セキュア会議に対しセキュアな会議ブリッジを選択する付加機能を提供します。ただし、セキュアな会議ブリッジ接続は、デバイス機能に依存します。Unified CM は、ビデオまたはオーディオ会議ブリッジの代わりに、セキュアな会議ブリッジを割り当てることがあります。インテリジェント ブリッジ選択機能の動作は、サービス パラメータの設定によって、柔軟に変更できます。

Cisco Business Edition

Cisco Business Edition 3000 でビデオを使用する場合、Business Edition 3000 がビデオ会議ブリッジ登録をサポートしていないため、Business Edition 3000 ではマルチポイント コールがサポートされないことに留意してください。

Cisco Business Edition 6000 はビデオ会議ブリッジをサポートし、エンドポイントにマルチポイント コール機能を提供します。

H.323 および SIP MCU リソース

H.323 または SIP モードで設定すると、MCU は MC 機能を提供し、Unified CM への H.323 または SIP ピアのように動作します。現在のリリースの Unified CM では SIP 機能を使用できるため、MCU 統合の選択肢として SIP が優先されます。シスコでは、H.323 MCU リソースを Cisco VCS に登録し、SIP トランク経由で Unified CM とピアリングするために H.323-SIP インターワーキング機能を使用することを推奨します。

H.323 および SIP MCU 会議は多くの方法で呼び出せますが、それらの方法は主に次の 2 つのカテゴリに分類できます。

スケジュール済み

予約なし

スケジュール済みの会議は、コールの前に、スケジューリング アプリケーションを使用して MCU リソースを予約します。スケジューリング機能は、通常、Cisco Unified MeetingPlace や Cisco Unified Video Conferencing Manager などの Web ベースのユーザ インターフェイスで提供されます。スケジューリング アプリケーションは、通常、会議の日付と時刻、会議用に予約されているポートの数、ダイヤルイン情報をユーザに提供する招待情報を生成します。または、会議の開始時に参加者の一部、またはすべてにダイヤル アウトするようにスケジューリング システムを設定できます。

予約なしの会議の場合、MCU には、オンデマンドで使用できる一定の数のリソースがあります。会議を作成するため、ユーザはいつでも MCU にダイヤルインするだけで済みます。そのユーザが最初にダイヤルした参加者である場合、MCU は、サービス テンプレートで定義された設定を使用して、動的に新しい会議を作成します。同じ会議番号にダイヤルインする後続のユーザは、この会議に参加します。

スケジュール済みまたは予約なしの H.323 または SIP 会議の作成と参加は、任意のタイプのエンドポイントで実行できます。たとえば、SCCP エンドポイントが SIP MCU にダイヤルインして、SIP エンドポイントと同様に予約なしの会議を作成できます。

図 12-7 は、SIP エンドポイントと SCCP エンドポイントを同じ SIP 会議に参加させる方法を示しています。この例では、SIP MCU にダイヤルインして新しい予約なしの会議を作成した SCCP エンドポイントによって会議が開始され、他の 2 人の参加者が、後で会議にダイヤルインしています。

図 12-7 予約なしの会議の SCCP および SIP エンドポイント

 

H.323 および SIP 会議は、Voice-Activated モードと Continuous-Presence モードの両方をサポートします。

MCU のサイジング

MCU がサポートできる会議のタイプと数の決定には、複数の要因が関与します。サイジングに関連するこれらの要因は、MCU のモデルによって異なります。また、MCU では、標準品位(SD)を使用する場合、高品位(HD)モードと比較してより多くのポートを使用できます。

MCU のサイズ計算は、次の要素で決まります。

ビデオ会議の解像度のタイプ

MCU がサポートできる合計ポート数

MCU が各プロトコル専用に割り当てることができるポート数

カスケード化された会議が MCU 間で必要かどうか

サポートされるポート数に関する特定の情報については、Cisco.com で入手可能な MCU ハードウェアの製品マニュアルを参照してください。可能なバリエーションの数は無限に近いため、具体的な設計ガイダンスをこのマニュアルで示すことは非常に困難です。多くのお客様では、最終的に、SIP または SCCP のアドホック会議、H.323 および SIP の予約なしの会議、および H.323 および SIP のスケジュール済み会議が混在することになります。MCU は、正しい速度とビデオ レイアウトでこれらのすべてのタイプの会議に対応できるサイズにする必要があります。言うまでもなく、この判断はとても複雑です。特定の環境での MCU のサイジングにあたっては、代理店にご相談ください。

ダイヤルイン会議の IVR

ダイヤルイン会議は、通常、音声自動応答装置(IVR)システムを使用して、参加する会議の会議 ID とパスワード(設定されている場合)の入力をユーザに求めます。次のタイプの IVR のいずれかを Cisco MCU と使用できます。

MCU に内蔵された IVR

Cisco Unified IP IVR

MCU の内蔵 IVR には、次の特性があります。

会議の作成または会議 ID での参加のプロンプトを再生できる。

会議のパスワードのプロンプトを再生できる。

インバンドとアウトオブバンド(H.245 英数字)の両方の DTMF をサポートする。

より柔軟性の高いメニューまたは機能を提供するようにカスタマイズできない。

カスタマイズできるのは、ユーザに対して再生される録音済み音声ファイルだけです。

ダイヤルイン番号を 1 つにして、会議 ID を入力するようにユーザに求めるには、Cisco Unified IP IVR と MCU を組み合わせて使用します。

Cisco Unified IP IVR には、次の特性があります。

(特に)会議 ID とパスワードのプロンプトを再生できる。

アウトオブバンド DTMF だけをサポートする。

つまり、発信側デバイスはアウトオブバンド DTMF 方式(H.323 デバイスの H.245 英数字など)をサポートしている必要があります。これらのアウトオブバンド DTMF メッセージは、次に、Unified CM によって 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 に転送します。この時点で Unified CM が、エンドポイントと Cisco Unified IP IVR サーバとの間の音声チャネルを終了し、エンドポイントと MCU の間で新しい論理チャネルを開く Empty Capabilities Set(ECS)プロシージャを呼び出します。このプロシージャについては、この章ですでに説明しています。H.323 ビデオ エンドポイントが Unified CM からの ECS の受信をサポートしていない場合、コールが切断されるか、最悪の場合、クラッシュしてリブートします。

ゲートキーパー

現在のリリースの Unified CM では SIP 機能を使用でき、Cisco VCS で堅牢な H.323 ビデオがサポートされているため、可能な場合はいつでも、H.323 ビデオ デバイスを Cisco VCS にゲートキーパーとして登録する必要があります。こうして、Cisco VCS はデバイスに対して、ローカル コールの解決や、SIP トランクを介したネイバー Unified CM との SIP-H.323 インターワーキングを提供できます。しかし、登録が可能でない場合のため、続く項に Unified CM と H.323 ゲートキーパーとの統合についてのガイドラインを提示します。

Unified CM とゲートキーパーはチームとして機能し、H.323 ビデオ エンドポイントを管理します。ゲートキーパーがすべての Registration, Admission, and Status(RAS)シグナリングを処理し、Unified CM がすべての H.225 コール シグナリングと H.245 メディア ネゴシエーションを処理します。そのため、図 12-8 で示すように、ネットワークの H.323 エンドポイントに RAS シグナリング プロシージャが必要な場合は、ゲートキーパーと Unified CM サーバを同時に配置する必要があります。

図 12-8 H.323 エンドポイントに RAS シグナリングを提供する Unified CM と Cisco IOS Gatekeeper

 

次のいずれかの条件が該当する場合、RAS シグナリングが常に必要になります。

エンドポイントが固定 IP アドレスを使用しない。

エンドポイントが静的 IP アドレスを使用する場合、Unified CM は、エンドポイントを探すために RAS プロシージャを必要としません。エンドポイントは静的 IP アドレスを使用して Unified CM Administration でプロビジョニングされ、この H.323 クライアントのディレクトリ番号へのコールは、直接静的 IP アドレスにルーティングされます。エンドポイントが静的 IP アドレスを使用しない場合、Unified CM はこのエンドポイントにコールをルーティングするたびに、ゲートキーパーに照会してエンドポイントの現在の 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 エンドポイントがあり、登録するゲートキーパー アドレスを設定することも、使用する Unified CM サーバの IP アドレスを設定することもできます。後者の場合、エンドポイントはすべてのコールを指定された IP アドレスに直接送信し、ゲートキーパーの RAS プロシージャを必要としません。

H.323 ビデオ エンドポイントの RAS プロシージャの管理に加え、ゲートキーパーは、大規模なマルチサイト分散呼処理環境でのダイヤル プラン解決および Unified CM クラスタ間の帯域幅制限の管理において、重要な役割を果たしています。ゲートキーパーは、組織内の多数の H.323 VoIP ゲートウェイを統合できます。また、エンタープライズ IP Telephony ネットワークとサービス プロバイダー VoIP 転送ネットワークの間でセッション ボーダー コントローラとして機能します。

そのため、Cisco IP Video Telephony 配置に関しては、Cisco IOS Gatekeeper は次の役割の一方または両方を実行できます。

エンドポイント ゲートキーパー

エンドポイント ゲートキーパーは、H.323 クライアント、MCU、および H.320 ビデオ ゲートウェイを宛先または発信元とするコール、およびこれら相互間のコールのすべての RAS プロシージャを管理するように設定されます。エンドポイント ゲートキーパーは、Unified CM がすべての H.225 コール ルーティングおよび H.245 メディア ネゴシエーションを実行できるように、これらのすべてのコールを適切な Unified CM クラスタに転送します。

インフラストラクチャ ゲートキーパー

インフラストラクチャ ゲートキーパーは、Unified CM クラスタ間、Unified CM クラスタと H.323 VoIP ゲートウェイのネットワーク間、および Unified CM クラスタとサービス プロバイダーの H.323 VoIP 転送ネットワーク間のすべてのダイヤル プラン解決および帯域幅制限(コール アドミッション制御)を管理するように設定されます。

以前の Cisco Unified CM リリースでは、エンドポイント ゲートキーパーとインフラストラクチャ ゲートキーパーは別々のルータで実行する必要があり、各エンドポイント ゲートキーパーは単一の Unified CM クラスタだけにサービスを提供できました。企業内に複数の Unified CM クラスタがある場合は、Cisco Unified CM クラスタごとに、個別のエンドポイント ゲートキーパーを配置する必要がありました。現在のリリースの Cisco Unified CM では、これらの役割を単一のゲートキーパーに組み合わせて、1 つ以上の Unified CM クラスタのエンドポイント ゲートキーパーとして使用しながら、クラスタ間またはクラスタと他の H.323 VoIP ネットワーク間のコールを管理するインフラストラクチャ ゲートキーパーとして使用できます。ただし、(特に)次の理由により、これらの役割は複数のゲートキーパーに分割することを推奨します。

拡張性

配置する Cisco IOS ルータ プラットフォーム、および最繁時のコール量の概算によっては、負荷を処理するゲートキーパーが複数必要になることがあります。

地理的な復元性

1 台のゲートキーパーでネットワーク全体をカバーすることは、大規模な国際 VoIP ネットワークにおいて、賢明な方法ではありません。複数のゲートキーパーをネットワーク全体に(一般的には地理的に)分散して配置すると、1 つのゲートキーパーが故障した場合に、より適切に障害を切り分けることができます。

非互換性

ゲートキーパーの設定の中には、グローバルな性質(そのゲートキーパーに登録されているすべてのエンドポイントに関連する性質)を持つものがあります。たとえば、コマンド arq reject-unknown-prefix は、一部の H.323 VoIP 転送環境では便利ですが、Unified CM へのコールをルーティングするエンドポイント ゲートキーパーで使用される gw-type-prefix <プレフィックス> default-technology コマンドと競合します。Cisco IOS では両方のコマンドを同じゲートキーパーで設定することは禁止されていませんが、 arq reject-unknown-prefix コマンドが優先されるため、不明な番号へのコールは Unified CM にルーティングされず、拒否されます。この場合は、H.323 VoIP 転送ネットワーク用に 1 つのゲートキーパーを使用し、別のゲートキーパーを Unified CM クラスタに使用します。

非互換性のもう 1 つの例は、冗長性のためにゲートキーパーを設定する際に発生することがあります。Cisco Voice Gateways や Unified CM など、ほとんどの Cisco H.323 音声デバイスは、Gatekeeper Update Protocol(GUP)を使用して相互に同期するゲートキーパー クラスタとしてゲートキーパーを設定可能な H.323v3 Alternate Gatekeeper 機能をサポートします。ただし、多くの H.323 ビデオ エンドポイントは Alternate Gatekeeper をサポートしないため、冗長性のためにホットスタンバイ ルータ プロトコル(HSRP)を使用するようにゲートキーパーを設定する必要があります。これらの 2 つの冗長性方式を同じゲートキーパーに混在させ、組み合わせることはできません。この場合、Alternate Gatekeeper をサポートするエンドポイント用にゲートキーパー クラスタを使用するか、サポートしないエンドポイント用にゲートキーパーの HSRP ペアを使用するかを決定します。

図 12-9 は、2 つの Unified CM クラスタがあるネットワーク シナリオを示しています。各クラスタは、SCCP クライアント、H.323 クライアント、H.323 MCU、および H.320 ゲートウェイで構成されています。H.323 クライアント、MCU、および H.320 ゲートウェイの RAS 部分を管理するために、エンドポイント ゲートキーパーを各クラスタに配置します。別のインフラストラクチャ ゲートキーパーが、クラスタ間のダイヤル プラン解決と帯域幅を管理します。この図ではゲートキーパーの冗長性は示されていませんが、これらの各ゲートキーパーは、実際には Alternate Gatekeeper または HSRP ベースの冗長性を持つように設定された複数のゲートキーパーです。

図 12-9 2 つの Unified CM クラスタと必要なゲートキーパー

 

エンドポイント ゲートキーパー

次の条件の両方が該当する場合は、エンドポイント ゲートキーパーが必要です。

クラスタに H.323 クライアント、H.323 MCU、または H.320 ゲートウェイ(集合的に H.323 エンドポイントと呼ぶ)が含まれている。これらのタイプのエンドポイントが存在しない場合(たとえば、すべてのクライアントが SCCP エンドポイントで、MCU も H.320 ゲートウェイもない場合)、エンドポイント ゲートキーパーは不要です。

次の条件のいずれかに当てはまる。

E.164 アドレスへのコール発信のために、H.323 エンドポイントで RAS プロシージャを必要とする。すでに述べたように、ピアツーピア コール シグナリングに対応するデバイスが増えています。これらのデバイスは、ゲートキーパーに登録する必要はありません。

H.323 エンドポイントが静的 IP アドレスを使用しない。

エンドポイント ゲートキーパーの役割は、これらの H.323 エンドポイントを登録する場所を提供し、エンドポイントとの通信の RAS 部分を処理するだけです。エンドポイント ゲートキーパーは、これらのエンドポイントが宛先または発信元となるコール、またはこれらのエンドポイント間のすべてのコール要求に対応して、Unified CM がすべてのコール ルーティング機能および帯域幅制御機能を実行できるように、コールを適切な Unified CM サーバに転送します。このコール ルーティング制御および帯域幅制御を実現するには、H.323 トランクをゲートキーパーに登録するように Unified CM を設定し、ゾーンへのコール、ゾーンからのコール、またはゾーン内のコールをすべてこれらのトランクにルーティングするようにゲートキーパーを設定します。

Cisco Unified CM では、RASAggregator トランクという H.323 トランクを使用してエンドポイント ゲートキーパーに登録する必要があります。このタイプのトランクは、すべての H.323 クライアント、H.323 MCU、または H.320 ゲートウェイ ゾーンに使用されます。一方、ゲートキーパー制御クラスタ間トランクおよびゲートキーパー制御 H.225 トランクは、インフラストラクチャ ゲートキーパーとの統合に使用されます。

H.323 クライアントのプロビジョニング

H.323 クライアントは、他の電話機とほぼ同じ方法でプロビジョニングされます。新しい電話機(モデル タイプ = H.323 クライアント)を作成し、ディレクトリ番号を割り当て、コーリング サーチ スペース、デバイス プールなどを割り当てます。Unified CM で H.323 クライアントは、次のいずれかの方法で設定します。使用する方法は、クライアントが静的 IP アドレスを使用するかどうか、クライアントで E.164 アドレスをダイヤルする RAS プロシージャが必要かどうかによって異なります。

ゲートキーパー制御

このタイプの設定は、静的 IP アドレスが割り当てられていないクライアント(DHCP 割り当てアドレスを使用するクライアント)で、E.164 アドレスをダイヤルする RAS プロシージャが必要な場合に使用します。これらのクライアントとの通信には、RASAggregator トランクを使用します (図 12-10 および図 12-11 を参照)。

非ゲートキーパー制御、非同期

このタイプの設定は、静的 IP アドレスが割り当てられているクライアントで、E.164 アドレスをダイヤルする RAS プロシージャが必要な場合に使用します。Unified CM はゲートキーパーを必要とせずに直接シグナルを送信して IP アドレスを解決できますが、クライアントは Unified CM に直接シグナルを送信できず、ダイヤルしようとしている E.164 アドレスを解決するためにゲートキーパーに照会する必要があります(非同期通信)。このタイプのクライアントをサポートするには、実際にはすべてのクライアントが静的 IP アドレスを使用していても、ゲートキーパーのゾーンごとに 1 つ以上のゲートキーパー制御クライアントを Unified CM で定義する必要があります。この場合、非ゲートキーパー制御クライアントは、実際には存在しない「ダミー」クライアントになります。目的は、ゲートキーパーがクライアントから Unified CM へのコールをルーティングできるように、RASAggregator トランクを作成することです。(図 12-12 および図 12-13 を参照)。

非ゲートキーパー制御、同期

このタイプの設定は、クライアントが静的 IP アドレスを持ち、ピアツーピア シグナリングに対応している(E.164 番号をダイヤルする RAS プロシージャが必要ない)場合に使用します。Unified CM は直接シグナルを送信でき、クライアントは Unified CM に直接シグナルを送信できます(同期通信)。このタイプのクライアントには、ゲートキーパーまたは RASAggregator トランクが不要です (図 12-14 および図 12-15 を参照)。

図 12-10 から図 12-15 は、これら 3 つのシナリオで使用されるコール シグナリング フローを示しています。

図 12-10 Unified CM からゲートキーパー制御クライアントへのコール

 

 

図 12-11 ゲートキーパー制御クライアントから Unified CM へのコール

 

図 12-12 Unified CM から非ゲートキーパー制御クライアントへのコール(非同期)

 

図 12-13 非ゲートキーパー制御クライアントから Unified CM へのコール(非同期)

 

図 12-14 Unified CM から非ゲートキーパー制御クライアントへのコール(同期)

 

図 12-15 非ゲートキーパー制御クライアントから Unified CM へのコール(同期)

 

ゲートキーパー制御クライアント

H.323 クライアントをゲートキーパー制御として設定するときは、任意の英数字文字列(わかりやすい名前など)を [Device Name] フィールドに入力し、[Gatekeeper-controlled] ボックスをオンにして、次のフィールドに入力します。

Device Pool

クライアントで使用するデバイス プール。同じゾーンに登録されているすべての H.323 クライアント(ゲートキーパー制御と非ゲートキーパー制御の両方)が、同じデバイス プールを使用する必要があります。間違ってエンドポイントの間で異なるデバイス プールが割り当てられた場合、Unified CM は複数の RASAggregator トランクをゾーン内で登録し、着信コールが間違った RASAggregator トランクに転送されても、Unified CM で拒否されます。

Gatekeeper

ゲートキーパー IP アドレスのドロップダウン リスト。ゲートキーパー制御 H.323 クライアントを設定する前に、Unified CM でゲートキーパーを定義する必要があります。

Technology Prefix

テクノロジー プレフィックスは RASAggregator トランクで使用され、ゲートキーパーのクライアント ゾーンに登録されます。このテクノロジー プレフィックスは、ゲートキーパーでデフォルト テクノロジー プレフィックスとして設定された値と一致している必要があります。同じゾーンに登録されているすべてのゲートキーパー制御 H.323 クライアントが、同じテクノロジー プレフィックスを使用する必要があります。間違ってエンドポイントの間で異なるテクノロジー プレフィックスが割り当てられた場合、Unified CM は複数の RASAggregator トランクをゾーン内で登録し、着信コールが間違った RASAggregator トランクに転送されても、Unified CM で拒否されます。このプレフィックスには 1# を使用することを推奨します。

Zone Name

ゲートキーパーで設定されているクライアント ゾーンの名前(大文字と小文字が区別されます)。同じゾーンに登録されているすべてのゲートキーパー制御 H.323 クライアントが、同じゾーン名を使用する必要があります。間違ってエンドポイントの間で異なるゾーン名(このフィールドは大文字と小文字が区別されます)が割り当てられた場合、Unified CM は複数の RASAggregator トランクをゲートキーパーに登録しようとし(ただし、ゾーン名が不正なトランクは登録に失敗します)、着信コールが間違った RASAggregator トランクに転送されても、Unified CM で拒否されます。

また、Unified CM サービス パラメータの [Send Product ID and Version ID] を [True] に設定する必要があります。このパラメータによって、RASAggregator トランクをゲートキーパーに H323-GW として登録できます。それによりゲートキーパーは、クライアント ゾーンへの H.323 コール、クライアント ゾーンからの H.323 コール、クライアント ゾーン内の H.323 コールのすべてを RASAggregator トランクに転送できます。

非ゲートキーパー制御クライアント

H.323 クライアントを非ゲートキーパー制御としてプロビジョニングする場合は、クライアントの静的 IP アドレスを [Device Name] フィールドに入力し、[Gatekeeper-controlled] セクションの下のその他のすべての設定をブランク(オフ)のままにします。コールがこのディレクトリ番号にルーティングされると、Unified CM は静的 IP アドレスを使用してクライアントに転送します。

クライアントがピアツーピア モードを使用するように設定されている場合、これ以上の設定は不要です。クライアントで E.164 アドレスにコールを発信する RAS プロシージャが必要な場合は、RASAggregator トランクを作成するために、次のフィールドに入力して、ダミーのゲートキーパー制御 H.323 クライアントも設定する必要があります。

Device Name

クライアント ゾーンの RASAggregator トランクの作成を目的とするダミー クライアントとして、クライアントを識別するためのわかりやすい名前。

Device Pool

非ゲートキーパー制御 H.323 クライアントを設定するときに選択したデバイス プール。ダミー クライアントに割り当てられたデバイス プールが、実際のクライアントに割り当てられたデバイス プールと異なる場合、実際のクライアントからの着信コールが Unified CM で拒否されることがあります。

Gatekeeper

ゲートキーパー IP アドレスのドロップダウン リスト。ダミーのゲートキーパー制御 H.323 クライアントを設定する前に、Unified CM でゲートキーパーを定義する必要があります。

Technology Prefix

テクノロジー プレフィックスは RASAggregator トランクで使用され、ゲートキーパーのクライアント ゾーンに登録されます。このテクノロジー プレフィックスは、ゲートキーパーでデフォルト テクノロジー プレフィックスとして設定された値と一致している必要があります。このプレフィックスには 1# を使用することを推奨します。

Zone Name

ゲートキーパーで設定されているクライアント ゾーンの名前(大文字と小文字が区別されます)。

また、Unified CM サービス パラメータの [Send Product ID and Version ID] を [True] に設定する必要があります。このパラメータによって、RASAggregator トランクをゲートキーパーに H323-GW として登録できます。それによりゲートキーパーは、クライアント ゾーンへの H.323 コール、クライアント ゾーンからの H.323 コール、クライアント ゾーン内の H.323 コールのすべてを RASAggregator トランクに転送できます。

H.323 MCU のプロビジョニング

H.323 MCU は、Unified CM で H.323 ゲートウェイとしてプロビジョニングされてから、これらのデバイスにコールをルーティングするルート パターンが設定されます。H.323 ゲートウェイをプロビジョニングするときは、MCU の静的 IP アドレスおよび TCP シグナリング ポートを [Device Name] フィールドに入力する必要があります。コールが MCU に関連付けられたルート パターンと一致すると、Unified CM は静的 IP アドレスと TCP ポートを使用して、MCU に到達します。


) Cisco Unified Videoconferencing 3500 および 5000 シリーズ MCU は、デフォルトでは TCP ポート 1720 を監視しません (Cisco Unified Videoconferencing 3500 および 5000 シリーズ MCU は、デフォルトでポート 2720 を監視します)。監視している TCP ポートを確認し、1720 に変更するか、正しいポートを Unified CM でプロビジョニングする必要があります。


MCU がピアツーピア モードを使用するように設定されている場合は、これ以上の設定は不要です (Cisco Unified Videoconferencing MCU は、現在、ピアツーピア モードをサポートしていませんが、一部のサードパーティ製 MCU がサポートしています)。MCU で E.164 アドレスにコールを発信する RAS プロシージャが必要な場合は、RASAggregator トランクを作成するために、「非ゲートキーパー制御クライアント」 に説明した [Device Name]、[Device Pool]、[Gatekeeper]、[Technology Prefix]、および [Zone Name] の各フィールドに入力して、ダミーのゲートキーパー制御 H.323 クライアントも設定する必要があります。

MCU サービス プレフィックス

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 トランクにコールをルーティングします。Unified CM は、コールを MCU にルーティングする前に、着信番号の先頭に # 文字を付加する必要があります。この文字は、MCU を表す H.323 ゲートウェイに関連付けられたルート パターンに付加されます。そのため、SCCP クライアントから MCU へのコールでも、着信番号にこの # 文字が付加されます。

MCU が [MCU] モードで設定されている場合、または E.164 アドレスを会議 ID に使用する別のベンダーの MCU である場合、# 文字を付加する必要はありません。MCU がピアツーピア モードを使用しているため、テクノロジー プレフィックスをゲートキーパーに登録する必要がない場合もこの条件は当てはまらず、# 文字を付加する必要はありません。

H.320 ゲートウェイのプロビジョニング

H.323 MCU と同様に、H.320 ゲートウェイも、Unified CM で H.323 ゲートウェイとしてプロビジョニングされてから、これらのデバイスにコールをルーティングするルート パターンが設定されます。H.323 ゲートウェイをプロビジョニングするときは、H.320 ゲートウェイの静的 IP アドレスおよび TCP シグナリング ポートを [Device Name] フィールドに入力する必要があります。コールがゲートウェイに関連付けられたルート パターンと一致すると、Unified CM は静的 IP アドレスと TCP ポートを使用して、ゲートウェイに到達します。


) Cisco Unified Videoconferencing 3500 および 5000 シリーズ ゲートウェイは、デフォルトでは TCP ポート 1720 を監視しません (Cisco Unified Videoconferencing 3500 および 5000 シリーズ ゲートウェイは、デフォルトでポート 1820 をリッスンします)。リッスンしている TCP ポートを確認し、1720 に変更するか、正しいポートを Unified CM でプロビジョニングする必要があります。


ゲートウェイがピアツーピア モードを使用するように設定されている場合は、これ以上の設定は不要です。ゲートウェイで E.164 アドレスにコールを発信する RAS プロシージャが必要な場合は、RASAggregator トランクを作成するために、「非ゲートキーパー制御クライアント」 に説明した [Device Name]、[Device Pool]、[Gatekeeper]、[Technology Prefix]、および [Zone Name] の各フィールドに入力して、ダミーのゲートキーパー制御 H.323 クライアントも設定する必要があります。

ゲートウェイ サービス プレフィックス

H.320 ゲートウェイは、ユーザが ISDN の宛先に到達するためにダイヤルするプレフィックスとして、テクノロジー プレフィックス(ゲートウェイではサービス プレフィックスとも呼ばれる)を使用します。コールを正しくルーティングするには、ゲートウェイのサービス プレフィックスを # 文字で始まるように設定する必要があります。たとえば、ISDN 番号に到達するためにクライアントがダイヤルするゲートウェイのサービス プレフィックスが 9 の場合、#9 としてゲートウェイでサービス プレフィックスをプロビジョニングする必要があります。この場合、H.323 クライアントが 9 と PSTN 番号をダイヤルした場合(918005551212 など)、ゲートキーパーは登録済みの一致するテクノロジー プレフィックスを検索するのではなく、デフォルト テクノロジー プレフィックスと共に登録された Unified CM トランクにコールをルーティングします。Unified CM は、コールをゲートウェイにルーティングする前に、着信番号の先頭に # 文字を付加する必要があります。ゲートウェイがピアツーピア モードを使用しているため、テクノロジー プレフィックスをゲートキーパーに登録する必要がない場合は、この条件は当てはまらず、# 文字を付加する必要がありません。

ゲートキーパー ゾーンの設定

前の項では、Unified CM Administration でエンドポイントをプロビジョニングする方法について説明しました。適切なゾーン定義でエンドポイント ゲートキーパーを設定する必要もあります。Unified CM で、エンドポイントの各タイプ(クライアント、MCU、またはゲートウェイ)にゾーンを設定する必要があり、オプションとして、これらのエンドポイントに関連付けられている各デバイス プールにゾーンを設定します。

各ゾーンは、ゾーンを宛先または発信元とするコール、ゾーン内で発信されるコールのすべてを、ゾーンに登録されている RASAggregator トランクにルーティングするように設定されます。エンドポイント ゲートキーパーでゾーンを設定するには、次のコマンド構文を使用します。

zone local <zone_name> <domain_name> <ip_address> invia <zone_name> outvia <zone_name> enable-intrazone
 

コマンド引数 invia は他のゾーンからこのゾーンに発信されたコールに適用され、 outvia はこのゾーンから他のゾーンに発信するコールに適用されます。 enable-intrazone は、ゾーン内で発信したコールに適用されます。次の項で、これらのコマンドの使用方法を示します。

クライアント ゾーン

各エンドポイント ゲートキーパー内で設定の必要なクライアント ゾーンの数は、次の要素で決まります。

H.323 クライアントの関連付け先となるデバイス プール

デバイス プールは、各 H.323 クライアントの 1 次、2 次、および 3 次 Unified CM サーバを決定します。すべての H.323 クライアントを同じデバイス プールに割り当てた場合、エンドポイント ゲートキーパーで定義する必要があるクライアント ゾーンは 1 つだけです。つまり、H.323 クライアントで使用するデバイス プールごとに、ゲートキーパーで個別のクライアント ゾーンを設定する必要があります。

エンドポイント ゲートキーパーが単一の Unified CM クラスタにサービスを提供するのか、複数の Unified CM クラスタにサービスを提供するのか

各クライアント ゾーンは、特定の RASAggregator トランクにコールをルーティングするように設定されます。そのため、1 つのエンドポイント ゲートキーパーを使用して複数の Unified CM クラスタにサービスを提供する場合は、ゲートキーパーがサービスを提供するクラスタごとに、個別のクライアント ゾーンを定義する必要があります。

説明のために、次の例でクライアント ゾーンの設定方法を示します。例 12-1 は、すべての H.323 クライアントが同じデバイス プールに関連付けられた単一の Unified CM クラスタに定義される、単一のクライアント ゾーンを示しています。例 12-2 は、H.323 クライアントが 2 つの異なるデバイス プールに分割された単一の Unified CM クラスタを示しています。


) 次の例で示すいくつかのコマンドは、Cisco IOS Gatekeeper で適用されるデフォルト値です。そのため、明示的に設定する必要はなく、実際の設定にも現れません。ここでは完全なものにするために含めていますが、コマンドラインの先頭に !のマークを付けてあります。


例 12-1 単一の Unified CM クラスタと単一のデバイス プールのクライアント ゾーン

gatekeeper
zone local clients domain.com invia clients outvia clients enable-intrazone
gw-type-prefix 1# default-technology
no use-proxy clients default inbound-to terminal
no use-proxy clients default outbound-from terminal
! no arq reject-unknown-prefix
endpoint ttl 60
no shutdown
 

例 12-2 単一の Unified CM クラスタと 2 つのデバイス プールのクライアント ゾーン

gatekeeper
zone local dp1-clients domain.com invia dp1-clients outvia dp1-clients enable-intrazone
zone local dp2-clients domain.com invia dp2-clients outvia dp2-clients enable-intrazone
gw-type-prefix 1# default-technology
no use-proxy dp1-clients default inbound-to terminal
no use-proxy dp1-clients default outbound-from terminal
no use-proxy dp2-clients default inbound-to terminal
no use-proxy dp2-clients default outbound-from terminal
! no arq reject-unknown-prefix
endpoint ttl 60
no shutdown
 

プロキシ使用の無効化

以前は Cisco Multimedia Conference Manager(MCM)と呼ばれていた Cisco IOS Gatekeeper は、H.323 プロキシ機能を提供していましたが、廃止される予定です。この機能は Unified CM と互換性がありませんが、端末(クライアント)との間のすべてのコールにプロキシを使用するゲートキーパーのコマンドは、まだデフォルトで有効になっています。この機能はクライアント ゾーンごとに、次のコマンド構文で無効にする必要があります。

gatekeeper
no use-proxy <zone_name> default [inbound-to | outbound-from] terminals
 

Cisco MCM プロキシは、Cisco IOS Multiservice IP-to-IP Gateway と、それに関連付けられた中継ゾーン対応 Cisco IOS Gatekeeper というソリューションに置き換えられました。このマニュアルでは IP-to-IP ゲートウェイについては説明していませんが、Cisco Unified CM は、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 の関連付け先となるデバイス プール

デバイス プールは、各 MCU の 1 次、2 次、および 3 次 Unified CM サーバを決定します。すべての MCU を同じデバイス プールに割り当てた場合、エンドポイント ゲートキーパーで定義する必要がある MCU ゾーンは 1 つだけです。つまり、MCU で使用するデバイス プールごとに、ゲートキーパーで個別の MCU ゾーンを設定する必要があります。

エンドポイント ゲートキーパーが単一の Unified CM クラスタにサービスを提供するのか、複数の Unified CM クラスタにサービスを提供するのか

各 MCU ゾーンは、特定の RASAggregator トランクにコールをルーティングするように設定されます。そのため、1 つのエンドポイント ゲートキーパーを使用して複数の Unified CM クラスタにサービスを提供する場合は、ゲートキーパーがサービスを提供するクラスタごとに、個別の MCU ゾーンを定義する必要があります。

MCU ゾーンのゲートキーパー設定は、例 12-1 および例 12-2 に示した設定と同様で、これらを MCU 用に設定したものです。

プロキシ使用の無効化

デフォルトでは、Cisco IOS Gatekeeper は MCU またはゲートウェイとの間のコールにプロキシを使用しないように設定されています。ただし、これらのタイプのエンドポイントでプロキシの使用を有効にした場合は、次のコマンド構文を使用して、各 MCU ゾーンで無効にする必要があります。

gatekeeper
no use-proxy <zone_name> default [inbound-to | outbound-from] [MCU | gateway]
 

MCU を MCU として登録する場合は、 no use-proxy コマンドの最後で MCU 引数を使用します。MCU をゲートウェイとして登録する場合は、 gateway 引数を使用します。

MCU ゾーン プレフィックス

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 次 Unified CM サーバを決定します。すべてのゲートウェイを同じデバイス プールに割り当てた場合、エンドポイント ゲートキーパーで定義する必要があるゲートウェイ ゾーンは 1 つだけです。つまり、H.320 ゲートウェイで使用するデバイス プールごとに、ゲートキーパーで個別のゲートウェイ ゾーンを設定する必要があります。

エンドポイント ゲートキーパーが単一の Unified CM クラスタにサービスを提供するのか、複数の Unified CM クラスタにサービスを提供するのか

各ゲートウェイ ゾーンは、特定の RASAggregator トランクにコールをルーティングするように設定されます。そのため、1 つのエンドポイント ゲートキーパーを使用して複数の Unified CM クラスタにサービスを提供する場合は、ゲートキーパーがサービスを提供するクラスタごとに、個別のゲートウェイ ゾーンを定義する必要があります。

ゲートウェイ ゾーンのゲートキーパー設定は、例 12-1 および例 12-2 に示した設定と同様で、これらをゲートウェイ用に設定したものです。

プロキシ使用の無効化

デフォルトでは、Cisco IOS Gatekeeper はゲートウェイとの間のコールにプロキシを使用しないように設定されています。ただし、これらのタイプのエンドポイントでプロキシの使用を有効にした場合は、次のコマンド構文を使用して、各 H.320 ゲートウェイ ゾーンで無効にする必要があります。

gatekeeper
no use-proxy <zone_name> default [inbound-to | outbound-from] gateway
 

ゲートウェイ ゾーン プレフィックス

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 ゲートウェイ、および Unified CM サーバは通常、固定 IP アドレスを使用しますが、H.323 クライアントは DHCP アドレスを使用できます。そのため、 zone subnet コマンドは MCU ゾーンおよびゲートウェイ ゾーンにのみ定義し、クライアント ゾーンは任意の IP アドレスを許可できるようにオープンのままにすることを推奨します。例 12-3 で示すように、Unified CM サーバが MCU ゾーンおよびゲートウェイ ゾーンに登録することも許可する必要があることに注意してください。


) 次の例で示すいくつかのコマンドは、Cisco IOS Gatekeeper で適用されるデフォルト値です。そのため、明示的に設定する必要はなく、実際の設定にも現れません。ここでは完全なものにするために含めていますが、コマンドラインの先頭に !のマークを付けてあります。


例 12-3 ゾーン サブネットの定義

gatekeeper
no zone subnet MCUs default enable
zone subnet MCUs [MCUs_IP_addr]/32 enable
zone subnet MCUs [RASAggregators_IP_addr]/32 enable
no zone subnet gateways default enable
zone subnet gateways [gateways_IP_addr]/32 enable
zone subnet gateways [RASAggregators_IP_addr]/32 enable
! zone subnet clients default enable
no zone subnet clients [MCUs_IP_addr]/32 enable
no zone subnet clients [gateways_IP_addr]/32 enable
 

例 12-3 の設定では、MCU ゾーンの MCU および RASAggregator を MCU ゾーンに登録することを明示的に許可しています。また、ゲートウェイ ゾーンのゲートウェイおよび RASAggregator をゲートウェイ ゾーンに登録することを明示的に許可しています。また、MCU およびゲートウェイをクライアント ゾーンに登録できないように明示的に拒否しています。その他のすべての IP アドレス(クライアント ゾーンの RASAggregator を含む)は、クライアント ゾーンに登録することが暗黙的に許可されています。

エンドポイントの存続可能時間

エンドポイントは、簡易な Registration Request(RRQ)をゲートキーパーに定期的に送信し、登録状態を維持します。これらの RRQ を送信する間隔は、存続可能時間(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 秒に調整すると、負荷が過大になることがあります。

TTL 値を設定するには、次のコマンド構文を使用します。

gatekeeper
endpoint ttl <seconds>
 

サポートされるゲートキーパー プラットフォーム

Cisco Unified CM を使用するエンドポイント ゲートキーパーとして機能するには、Cisco IOS Gatekeeper で Cisco IOS Release 12.3(11)T 以降を実行する必要があります。インフラストラクチャ ゲートキーパーの最小 Cisco IOS リリース要件については、次の Web サイトで入手可能な最新の『 Cisco Unified Communications System Release Notes for IP Telephony 』を参照してください。

http://www.cisco.com/go/unified-techinfo

ルータ プラットフォームで使用する必要があるリリースと機能を判断するには、次の URL にある Cisco Feature Navigator を使用します(Cisco.com ログイン アカウントが必要)。

http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp

詳細については、次の Web サイトで入手可能な『 Cisco IOS H323 Gatekeeper Data Sheet 』も参照してください。

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps4139/data_sheet_c78_561921.html

エンドポイント ゲートキーパーの要約

この項では、エンドポイント ゲートキーパーに関する重要なポイントを要約し、前の例で使用したテクニックを組み合わせたいくつかの設定例を示します。

エンドポイントのタイプ(クライアント、MCU、および H.320 ゲートウェイ)ごとに、エンドポイント ゲートキーパーに個別のゾーンを設定します。エンドポイントが複数のデバイス プールに関連付けられている場合は、エンドポイントのタイプごとに複数のゾーンを設定します。

各ゾーンに登録する RASAggregator トランクを設定します。このトランクは、Unified CM 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 秒でうまく動作するはずです。

例 12-4 は、単一の Unified CM クラスタにサービスを提供するエンドポイント ゲートキーパーの設定を示しています。このクラスタは、単一のデバイス プールを使用して、すべての H.323 ビデオ エンドポイント タイプにサービスを提供します。


) 次の例で示すいくつかのコマンドは、Cisco IOS Gatekeeper で適用されるデフォルト値です。そのため、明示的に設定する必要はなく、実際の設定にも現れません。ここでは完全なものにするために含めていますが、コマンドラインの先頭に !のマークを付けてあります。


例 12-4 単一のクラスタと単一のデバイス プールのエンドポイント ゲートキーパー設定

gatekeeper
zone local clients domain.com invia clients outvia clients enable-intrazone
zone local MCUs domain.com invia MCUs outvia MCUs enable-intrazone
zone local gateways domain.com invia gateways outvia gateways enable-intrazone
! zone subnet clients default enable
no zone subnet clients [MCUs_IP_addr]/32 enable
no zone subnet clients [gateways_IP_addr]/32 enable
no zone subnet MCUs default enable
zone subnet MCUs [MCUs_IP_addr]/32 enable
zone subnet MCUs [RASAggregators_IP_addr]/32 enable
no zone subnet gateways default enable
zone subnet gateways [gateways_IP_addr]/32 enable
zone subnet gateways [RASAggregators_IP_addr]/32 enable
no use-proxy clients inbound-to terminals
no use-proxy clients outbound-from terminals
! no use-proxy MCUs inbound-to [MCU | gateway]
! no use-proxy MCUs outbound-from [MCU | gateway]
! no use-proxy gateways inbound-to gateway
! no use-proxy gateways outbound-from gateway
gw-type-prefix 1# default-technology
! no arq reject-unknown-prefix
endpoint ttl 60
no shutdown
 

アプリケーション

Cisco Unified Communications には、Unified CM の機能を拡張し、高度な機能と他の通信メディアとの統合を提供する幅広いアプリケーションのポートフォリオが用意されています。これらの多くのアプリケーションは、特にビデオをサポートしていなくても、IP ビデオ テレフォニー デバイスと組み合わせて使用できます。たとえば、Cisco Unified CM は、TAPI/JTAPI プロトコルを使用する CTI アプリケーションのビデオ チャネルのネゴシエーションをサポートしていませんが、CTI アプリケーションをビデオ コールと組み合わせて使用する妨げにはなりません。この項では、シスコおよびサードパーティ製のアプリケーションのいくつかについて検討し、ビデオ コールに対して高度なコール トリートメントを提供できるかどうかについて説明します。

CTI アプリケーション

次のアプリケーションは、コンピュータ テレフォニー インテグレーション(CTI)インターフェイスに基づいています。

Cisco Emergency Responder

Cisco Emergency Responder(ER)は、緊急コール(911)を適切な Public Safety Answering Point(PSAP)にルーティングします。また、PSAP が事故のあった物理的な正しい場所に応答し、コールが切断された場合はコールバックできるように、発信元デバイスの正しい発信元回線 ID を PSAP に提供します。Cisco ER は、JTAPI を使用して Unified CM に統合されています。緊急コールは CTI ルート ポイント経由で Cisco ER にルーティングされ、Cisco ER は、コールの転送先 PSAP および表示する発信元回線 ID を判断します。Cisco ER は、簡易ネットワーク管理プロトコル(SNMP)と Cisco Discovery Protocol(CDP)を使用して、エンドポイントが接続されている物理ポートと特定の Cisco Catalyst Ethernet スイッチを検出することによって、ネットワークの各エンドポイントを追跡し、物理的な場所を判断します。CDP を使用できない場合は、代わりに IP サブネットを使用してエンドポイントを探すように Cisco ER を設定できます。Cisco ER は、この情報をスイッチの物理的な場所に関連付け、データベースに情報を格納します。

Cisco SCCP ビデオ デバイスは Cisco ER 検出の目的で CDP をサポートしています。その結果、ビデオ テレフォニー ユーザが 911 をダイヤルすると、Cisco ER は正しい PSAP にコールをルーティングできます。

サードパーティ製の 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 エンドポイントが Unified CM からの ECS の受信をサポートしていない場合、Cisco ER が処理する 911 へのコールは失敗します。

Cisco Cius が 3G または 4G 接続を使用して Unified CM に接続されている場合、Cisco ER ではユーザのロケーションの適切な PSAP を特定できません。3G または 4G 接続でローミングしている場合、Cisco Cius ユーザに別の方法で 911 をコールするように指示する必要があります。

Cisco Unified IP Interactive Voice Response と Cisco Unified Contact Center

Cisco Unified IP Interactive Voice Response(Unified IP IVR)および Cisco Unified Contact Center(Unified CC)は、JTAPI を使用して Unified CM に統合されています。ビデオ対応デバイスが IVR アプリケーション(ヘルプ デスクなど)にコールを発信した場合、発信者がアプリケーション サーバに接続している間(発信者が IVR メニューをブラウズしている間、またはヘルプデスクのメンバーがコールを受け付けるまでキューで待機している間)、通信は音声のみになります。ただし、IVR アプリケーションがコールを最終的な宛先に転送すると、その時点でビデオ チャネルをネゴシエートできるようになります。H.323 デバイスを Cisco Unified IP IVR および Unified CC と相互運用するには、Empty Capabilities Set(ECS)プロシージャをサポートしている必要があります。H.323 エンドポイントが Unified CM からの ECS の受信をサポートしていない場合、Cisco Unified IP IVR または Unified CC が代行受信したコールは、アプリケーションが最終的な宛先に発信者を転送しようとしたときに失敗します。

IVR アプリケーションは、多くの場合、DTMF トーンを使用して IVR メニューのオプションを選択します。別の方法としては音声認識があり、電話機のキーを押す代わりに、発信者が IVR サーバに向かってコマンドを発音します。Cisco Unified IP IVR と Unified CC はどちらも、JTAPI を使用して Unified CM に統合されているため、アウトオブバンド シグナリング メッセージで DTMF トーンを渡します。現在、市販されている多くの H.323 デバイスは、インバンド DTMF トーンを使用しています。このような H.323 クライアントでは、DTMF を使用して IP IVR または Unified CC メニューをナビゲートできません。ただし、これらの H.323 クライアントは、IVR サーバが対応していれば、音声認識を使用できます。SCCP ビデオ対応デバイス、サードパーティ製の SCCP ビデオ デバイス、および DTMF に H.245 英数字アウトオブバンド シグナリングを使用する H.323 エンドポイントは、DTMF トーンを使用して IVR メニューをナビゲートできます。

コラボレーション ソリューション

エンドポイント間のビデオ通信を提供するために、次のテクノロジーが使用されることがあります。

T.120 アプリケーション共有

T.120 プロトコルを使用して、ドキュメント、ホワイトボード、およびテキストを会議の参加者で共有するビデオ会議エンドポイントがあります。Unified CM は、T.120 チャネルのネゴシエートをサポートしません。T.120 の代わりに、Cisco MeetingPlace やサードパーティのコラボレーション ソリューションのような Web ベースのコラボレーション ソリューションを使用することを推奨します。

Cisco Unified MeetingPlace

Cisco Unified MeetingPlace は、ハイエンドな音声およびビデオ会議ソリューションと、会議のスケジューリングおよび参加に使用する Web ベースのフロントエンドを結合します。詳細については、「Cisco Unified MeetingPlace」を参照してください。

ビデオの相互運用性

ビデオの相互運用性とは、Cisco TelePresence System(CTS)エンドポイント、他の Cisco Unified Communications(UC)ビデオ エンドポイント、およびサードパーティ製ビデオ エンドポイント間でポイントツーポイント コールの音声とビデオをサポートすることです。Cisco Unified CM 8.5 よりも前のリリースでは、異なるファミリのビデオ エンドポイント間におけるビデオの相互運用性は、ビデオ トランスコーダやマルチポイント コントロール ユニット(MCU)などのビデオ コンポーネントをエンドポイントの間に挿入した場合にのみ実現できました。

Cisco Unified CM 8.5 以降のリリースでは、異なるエンドポイント ファミリ タイプ間(ポイントツーポイント)のネイティブ ビデオの相互運用性が提供されるだけでなく、SIP および H.323 プロトコルでの H.264 コーデック ネゴシエーションによってビデオの相互運用性が全体的に向上し、利用可能な場合は高品位(HD)解像度をエンドポイントでネゴシエートできるようになりました。ただし、相互運用性は相互運用をサポートするエンドポイントに依存します。

上記のとおり、Unified CM のビデオの相互運用性により、Cisco TelePresence System(CTS)エンドポイントは CTS 以外のエンドポイントと通信できます。ただし、インストールされている CTS ソフトウェアでそのような相互運用性がサポートされている場合に限ります。詳細については、次の Web サイトで入手可能な『 Interoperability Between CTS Endpoints and Other Cisco Endpoints or Devices 』を参照してください。

http://www.cisco.com/en/US/docs/telepresence/interop/endpoint_interop.html

また、Cisco Unified CM 8.6 には、Unified CM 以外のコール エージェントとの相互運用性強化のために、スクリプトのサポートが追加されました。スクリプトによって、Unified CM には、次の機能のサポートが追加されました。

SIP 透過性:既知および未知のメッセージ コンポーネントをパススルーことが可能

SIP の正規化:着信および発信 SIP メッセージおよびコンテンツ本文の変換

このビデオ相互運用性サポートの主な目的は、他の方法で必要になる高価な DSP インフラストラクチャを配置することなく、さまざまなエンドポイントの相互作用を促進することです。

次の項では、ビデオの相互運用性の使用に関する一般的な考慮事項と推奨事項を示します。

「ビデオの相互運用性アーキテクチャ」

「ビデオの相互運用性に関する設計上の考慮事項」

ビデオの相互運用性アーキテクチャ

ビデオの相互運用性アーキテクチャには、次の要素が含まれます。

ビデオの相互運用性のサポートは、Cisco Unified CM 8.5 以降のリリースでのみ提供されます。

ビデオ コールに参加する、2 つの異なるビデオ エンドポイント ファミリ タイプ(Cisco TelePresence エンドポイント、Cisco UC エンドポイント、またはサードパーティ製エンドポイント)。

次の項では、ビデオの相互運用性サポートの範囲について詳しく説明します。

「ビデオの相互運用性のテスト ケース」

「ビデオの相互運用性の制限」

ビデオの相互運用性のテスト ケース

ほとんどの場合、独自のシグナリングを使用せずに SIP または H.323 をサポートするビデオ エンドポイントは、ビデオの相互運用性をサポートする Cisco UC ビデオ エンドポイントと相互運用できます。一般的な配置済みデバイス間の相互運用性の範囲に関する具体的な情報、およびこれらの一般的な相互運用性の例を検証するために実施されたテストの一般情報については、次の Web サイトで入手可能な『 Cisco Unified Communications System Test Results for IP Telephony 』を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/unified/communications/system/ucstart.htm

ビデオの相互運用性の制限

ビデオの相互運用性のサポートでは、任意間のポイントツーポイント ビデオ コールの相互運用性を実現しようとしますが、別のエンドポイントと相互運用するときに、個々のビデオ エンドポイントのすべての機能がサポートされるとは限りません。これにはさまざまな理由があります。たとえば、異なる呼制御プロトコル間の非互換性により、機能が利用できなくなったり、その機能の表現が異なる場合があります。別の例として、H.264 ビデオ メディア パラメータは、H.323 では SIP と異なる表現になることがあります。また、H.323 ではプレゼンスがサポートされませんが、SIP ではプレゼンスは一般的にサポートされています。Skinny Client Control Protocol(SCCP)には、SIP および H.323 のエンドポイント実装で一般的に利用可能なアプリケーション共有の概念がありません。たとえば、PC 画面を共有しようとする SCCP ユーザは、SCCP で Binary Flow Control Protocol(BFCP)および H.239 を使用できないため妨げとなります。

ビデオの相互運用性に関する設計上の考慮事項

Unified CM のビデオの相互運用性により、任意間のビデオ コールを達成するためのビデオ トランスコーディングへの依存度が低くなるため、一部のコール フローは大幅に変わる可能性があります。それは、ビデオ トランスコーディングがすべてのコール フローで不要になるということではなく、Unified CM のビデオの相互運用性機能を利用できるコール フローでは不要になることを意味しています。したがって、ビデオの相互運用性を有効にすると、DSP リソースの必要性が低くなります。

さらに、Unified CM のビデオの相互運用性機能を実装するときに、次の領域を考慮する必要があります。

「ビデオの相互運用性に関するガイドラインと制約事項」

「ビデオの相互運用性のための Quality of Service(QoS)とコール アドミッション制御に関する考慮事項」

ビデオの相互運用性に関するガイドラインと制約事項

Unified CM 配置におけるビデオの相互運用性に関しては、次のガイドラインと制約事項が適用されます。

H.323 または SCCP プロトコルをビデオの相互運用性と併用する場合は、Unified CM によって単一の H.264 ペイロードのみがサポートされ、パケット化モードは 0 として処理されます。この状況の副次的な影響(1 つだけではありません)の例として、1080p 解像度にはパケット化モード 1 が必要になるため、これらのプロトコルでは 1080p を利用できないということがあります。

ビデオの相互運用性コールに参加している H.323 または SCCP エンドポイントによって複数のペイロードが提示される場合、Unified CM ではコーデック プロファイルが最も低いペイロードのみが使用されます。これにより、サポートされている最高の解像度より低い解像度がコールに選択される可能性があります。

SIP エンドポイントでセッション記述プロトコル(SDP)の level-asymmetry-allowed パラメータが省略されると、シスコ製品はエンドポイントが非対称の解像度送信をサポートできると想定します。したがって、受信側と送信側で異なるビデオ解像度もコール中にネゴシエートできます。

Unified CM で SIP と H.323 によるプロトコル インターワーキングが実行されている間にコールをビデオの相互運用性で処理する場合、H.323 エンドポイントは SIP 側で指定されたダイナミック ペイロード番号を受け入れます。つまり、別のペイロードへの再ネゴシエーションはサポートされません。

ビデオ コールによってメディア ターミネーション ポイント(MTP)またはトランスコーダが呼び出された場合、Unified CM は Real-Time Transport Control Protocol(RTCP)のフィードバックをネゴシエートしません。

ビデオの相互運用性のための Quality of Service(QoS)とコール アドミッション制御に関する考慮事項

ビデオの相互運用性がサポートされても、Unified CM のリージョンとロケーションの設定に変更はありません。ただし、リージョンはエンドポイントのグループ間の解像度を決定するときに重要な役割を果たし、これらのデバイスで相互運用時に使用される解像度の最大化または最小化に使用できます。リージョン設定の [Max Video Call Bit Rate] フィールドは、帯域幅およびエンドポイントがネゴシエートできる解像度を決定するために使用されます。

ネイティブ ビデオの相互運用性による QoS とコール アドミッション制御の詳細については、「TelePresence ビデオの相互運用性アーキテクチャに関するコール アドミッション制御の設計上の推奨事項」の項を参照してください。

無線ネットワーキング ソリューション

ビデオは帯域幅に大きな影響を与えるため、802.11b/g などの共有無線メディアをビデオ エンドポイントに使用することは 推奨しません。

ビデオ エンドポイントが、実稼働中の IP Phone と無線帯域幅を共有しないように注意する必要があります。ビデオは帯域幅の大半を消費するため、ビデオ、音声、およびデータを同じ無線メディアでサポートすることは困難です。

常に、物理イーサネット インターフェイスを優先パスにすることを推奨します。また、ユーザが IP Phone の背面の PC ポートに接続するときは、間違って優先されないように Aironet Adapter を無効にするように指示してください。