Cisco Unified Communications システム リリース 8.x SRND
IP ビデオ テレフォニー
IP ビデオ テレフォニー
発行日;2012/12/18 | 英語版ドキュメント(2012/07/30 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 39MB) | フィードバック

目次

IP ビデオ テレフォニー

この章の新規情報

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

管理に関する考慮事項

プロトコル

エンドポイント

リージョン

トポロジ対応ロケーション

Retry Video Call as Audio

Wait for Far-End to Send TCS

トランク

マルチポイント会議

Ad-Hoc 会議用の MCU リソース

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

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

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

MCU のサイジング

ダイヤルイン会議の IVR

ゲートキーパー

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

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

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

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

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

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

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

アプリケーション

CTI アプリケーション

Cisco Emergency Responder

Cisco Unified Communications Manager Assistant

Cisco Unified IP Interactive Voice Response と Cisco Unified Contact Center

Cisco Unified Enterprise Attendant Console

CiscoIP Communicator

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

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

CiscoUnifiedMeetingPlace

ビデオの相互運用性

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

CiscoUnifiedWireless IP Phone 7925G および 7921G

XML サービス

IP ビデオ テレフォニー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この章の新規情報

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

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

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

ビデオの相互運用性

「ビデオの相互運用性」

2012 年 4 月 30 日

細部の訂正および変更

この章の各項で説明

2011 年 9 月 30 日

細部の訂正および変更

この章の各項で説明

2011 年 6 月 2 日

SIP クライアント

「エンドポイント」

2010 年 11 月 15 日

ビデオ コール用トランク

「トランク」

2010 年 11 月 15 日

ビデオ エンドポイント

「エンドポイント」

2010 年 11 月 15 日

Cisco Unified IP Phone 9900 シリーズ

この章の各項で説明

2010 年 4 月 2 日

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

Cisco IP ビデオ テレフォニー ソリューションは、Cisco Unified Communications Manager(Unified CM)、H.323 電話会議、Session Initiation Protocol(SIP)電話会議、および Skinny Client Control Protocol(SCCP)電話会議に対応する Cisco Unified Videoconferencing 3500 および 5000 シリーズ Multipoint Control Unit(MCU; マルチポイント コントロール ユニット)、Cisco Unified Videoconferencing 3500 シリーズ H.320 ゲートウェイ、Cisco IOS H.323 ゲートキーパー、Cisco Unified IP Phone 9900 シリーズ、Cisco IP Video Phone E20、Cisco Unified Personal Communicator、Cisco Unified Video Advantage、Cisco Unified IP Phone 7985、サードパーティ製の SCCP ビデオ エンドポイント ソリューション、および Polycom、Lifesize、Sony などのパートナーが取り扱っている既存の H.323 または SIP 準拠製品で構成されます (図 12-1 を参照)。

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

 

管理に関する考慮事項

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

「プロトコル」

「エンドポイント」

「リージョン」

「トポロジ対応ロケーション」

「Retry Video Call as Audio」

「Wait for Far-End to Send TCS」

「トランク」

プロトコル

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

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

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

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

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

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

SCCP

音声とビデオ

音声とビデオ

音声のみ

音声のみ

音声とビデオ

H.323

音声とビデオ

音声とビデオ

音声のみ

音声のみ

音声とビデオ

MGCP

音声のみ

音声のみ

音声のみ

音声のみ

音声のみ

TAPI/JTAPI

音声のみ

音声のみ

音声のみ

音声のみ

音声のみ

SIP

音声とビデオ

音声とビデオ

音声のみ

音声のみ

音声とビデオ

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

表 12-3 Unified CM Release 8.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

エンドポイント

IP 電話は、Cisco Unified Communications システムにおける最も一般的なビデオ エンドポイントです。ユーザ用にビデオを IP 電話に追加するために、企業は Cisco Unified IP Phone 9971 にカメラを使用したり、Cisco E20 Video Phone などのエンドポイントを使用したり、Cisco Unified Video Advantage を実行する PC に IP 電話を接続したりできます。また、企業は Cisco Unified Personal Communicator などのソフト クライアントを配置することもできます。

さらに、Cisco Unified CM を使用して 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、サードパーティ製 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 Video Advantage の詳細については、「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] フィールドは、ビデオ コールに許可される最大ビット レート(コールの音声部分を含む)を定義します。

各デバイスは、 表 12-4 で示すように、特定の音声コーデックのみをサポートするため、正しい音声コーデックの帯域幅制限を選択することが重要です (特定のエンドポイントでサポートされるコーデックの最新リストについては、そのエンドポイントの製品マニュアルを参照してください)。

表 12-4 エンドポイント デバイスでサポートされている音声コーデックのタイプ

コーデック タイプ
Cisco 7900 および 9900 シリーズ IP Phone
SCCP サードパーティ製ビデオ エンドポイント
一般的な H.323 または SIP エンドポイント
Cisco Unified Videoconferencing 3500 シリーズ ゲートウェイ
Cisco Unified Videoconferencing 3500 および 5000 シリーズ MCU

G.729

Yes

あり、モデルによる

No

No

あり、モデルによる

G.728

No

あり、モデルによる

Yes

Yes

あり、モデルによる

G.711

Yes

Yes

Yes

Yes

Yes

G.722

あり、モデルによる

Yes

Yes

Yes

あり、モデルによる

表 12-4 で示すように、リージョンを G.729 に設定した場合、ビデオ会議デバイスによっては、このタイプのコーデックをサポートできないものがあります。たとえば、Cisco Unified Video Advantage エンドポイントと Tandberg T1000 エンドポイントとの間のコールは失敗します。または、このコールに Unified CM が音声変換リソースを割り当てます。

Cisco Unified CM 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 を使用する別のリージョンを設定する必要があります (図 12-2を参照)。この方式を使用すると、必要なリージョンの数が増えますが、望ましいコーデックと帯域幅の割り当てが得られます。

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

 


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


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

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

リージョン設定
[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 シリーズなどのビデオ電話機には固定ビット レートのビデオ用エンコーダが備えられています。固定ビット レートのエンコーダでは、より良いモーション ビデオおよびエラー復元性が提供されます。

Cisco Unified Video Advantage などのいくつかのエンドポイントでは、コールの CIF 解像度が使用されます。そのようなデバイスからのビデオ コールの CIF 解像度を制限するために、ビデオ コール帯域幅のリージョン設定を 384 kbps にして、デバイスをこのリージョンに関連付けることができます。この結果、高解像度のエンドポイントへのコールまたは MCU への会議では、ビデオの CIF 解像度がネゴシエートされます。

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

トポロジ対応ロケーション

ロケーション間のコールで使用できる帯域幅の量を制限する方式は、2 種類あります。Cisco Unified CM 4.0 では、ロケーションでのビデオ コールのサポートが導入されました。具体的には、Cisco Unified CM のロケーション オプションによって、あるロケーションと別のロケーションの間のすべてのコールに許可される合計帯域幅が定義されます。この合計帯域幅の値は、従来のハブアンドスポーク ネットワーク トポロジに十分に対応します。Cisco Unified CM Release 5. x では、リソース予約プロトコル(RSVP)に基づくトポロジ対応ロケーションを使用して、2 つのサイト間のパスに十分な帯域幅があるかどうかを判断するオプションが用意されています。RSVP を使用すると、複雑なトポロジに対応するホップ単位のチェックが可能になり、RSVP アプリケーション ID を使用して音声帯域幅とビデオ帯域幅を個別にサポートできます。


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


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

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


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


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

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


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


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

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

San Francisco

4、G.729 を使用

96 kbps(4 ∗ 24 kbps)

1、384 kbps

384 kbps

Dallas

8、G.711 を使用

640 kbps(8 ∗ 80 kbps)

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] の設定による)。

Retry Video Call as Audio

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

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

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

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

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

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

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

発信側デバイスが LCD 画面付き SCCP エンドポイントの場合、発信者にはビジー トーンが聞こえ、メッセージ「Bandwidth Unavailable」がデバイスに表示されます。

発信側デバイスが LCD 画面なしの SCCP エンドポイントの場合(Cisco Unified IP Phone 7902 など)、発信者にはビジー トーンが聞こえます。

発信側デバイスが H.323 または SIP デバイス、またはゲートウェイで接続されたPSTN デバイスの場合、発信者にはビジー トーンが聞こえ、Unified CM が適切なエラー メッセージ(Q.931 Network Congestion 原因コードなど)を H.323、SIP、または MGCP デバイスに送信します。

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

 

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

図 12-4 は、非ゲートキーパー制御クラスタ間トランクを使用する、2 つのクラスタ間のコールの手順を示しています。

図 12-4 非ゲートキーパー制御クラスタ間トランクを使用する 2 つのクラスタ間のコール フロー

 

Wait for Far-End to Send TCS

このチェックボックスは、H.323 クライアント、H.323 ゲートウェイ、H.225 ゲートキーパー制御トランクなど、すべての H.323 デバイスで使用できます。この機能は、H.323 コールの H.245 機能交換フェーズに関係します。この機能を有効にすると、Unified CM は、Unified CM が Terminal Capabilities Set(TCS; 端末機能セット)を H.323 デバイスに送信する前に、リモート H.323 デバイスが TCS を Unified CM に送信するまで待機します。このオプションが無効の場合、Unified CM は待機せず、すぐに TCS をリモート H.323 デバイスに送信します。

デフォルトでは、[Wait for Far-End to Send TCS] オプションが有効(オン)です。ただし、次の場合はオフ(無効)にする必要があります。

Unified CM と通信する H.323 デバイスも、遠端が TCS を送信するまで待機する。

この場合、どちらの側も TCS を送信しないためデッドロックが発生し、数秒後に H.245 接続がタイムアウトします。遠端が TCS を送信するまで待機するデバイスの例としては、一部の H.323 ルーテッドモード ゲートキーパー、H.320 ゲートウェイ、H.323 プロキシ(IP-to-IP ゲートウェイ)、一部の H.323 マルチポイント カンファレンス ブリッジがあります。これらのデバイスが遠端からの TCS の送信を待機する理由は、Unified CM が待機する理由と同じです。TCS を他方に転送する前に、接続の両端が TCS を送信するまで待機するためです。

クラスタ間トランクを介して別の Unified CM クラスタと通信している。


) クラスタ間トランクおよびゲートキーパー制御クラスタ間トランクでは、[Wait for Far-End to Send TCS] オプションは常に無効で、有効にはできません。


多くのシナリオで、Unified CM は、2 つのエンドポイント デバイス(相互に通話しようとする 2 つの H.323 クライアントなど)を接続するソフトウェア スイッチの役割を実行します。このような場合、両方のデバイスが TCS メッセージを送信するまで Unified CM が待機することが最良です。Unified CallManager が各デバイスの機能を認識することで、それぞれに送信する TCS に関して(特に、リージョンおよびロケーションの設定に応じて)最適な判断ができます。この場合、Wait for Far-End to Send TCS 機能は有効にする必要があります。

ただし、その他の H.323 デバイス(H.323 デバイスを H.320 デバイスに接続する H.320 ゲートウェイなど)が、複数の参加者を接続する機能を実行することもあります。また、ゲートウェイも、コールのセットアップ方法に関して最適な選択ができるように、両端が TCS メッセージを送信するまで待機します。Unified CM とゲートウェイの両方が、相手側から TCS が送信されるまで待機すると、デッドロックが発生します。このデッドロック状態を防止するには、Wait for Far-End to Send TCS 機能を無効(オフ)にします。

たとえば、図 12-5 で示す次のコール シナリオについて考えます。

シナリオ 1:Cisco Unified Video Advantage が H.320 エンドポイントを呼び出す。

シナリオ 2:H.323 クライアントが H.320 エンドポイントを呼び出す。

これらのシナリオでは、どちらの場合も、Wait for Far-End to Send TCS 機能は、デフォルト設定である有効(オン)のままにします。

図 12-5 Wait for Far-End to Send TCS 機能が有効(オン)のシナリオ

 

図 12-5 のシナリオ 1 では、登録時に SCCP デバイスがメディア機能を Unified CM に提供しているため、Unified CM はすでに Cisco Unified Video Advantage クライアントの機能を認識しています。しかし、ゲートウェイがコールの H.245 フェーズで TCS を Unified CM に送信するまで、Unified CM は H.320 ゲートウェイの機能を認識しません。同様に、H.320 エンドポイントが TCS をゲートウェイに送信するまで、H.320 ゲートウェイは、Unified CM に送信する TCS を判断できません。この場合、H.320 エンドポイントがゲートウェイに TCS を送信し、ゲートウェイが Unified CM に TCS を送信し、判断に使用できる両端のエンドポイントからの TCS を Unified CM が受信するため、Wait for Far-End to Send TCS 機能は有効のままにしておく方が適切です。

図 12-6 は、次のコール シナリオを示しています。これらのシナリオでは、Wait for Far-End to Send TCS 機能を無効にしないとコールが失敗します。

シナリオ 1:Cisco Unified Video Advantage が、ISDN ネットワークを介してリモート クラスタにある別の Cisco Unified Video Advantage を呼び出す。

シナリオ 2:H.323 クライアントが、ISDN ネットワークを介してリモート クラスタにある別の H.323 クライアントを呼び出す。

図 12-6 Wait for Far-End to Send TCS 機能が無効(オフ)のシナリオ

 

図 12-6 のどちらのシナリオでも、両方の Unified CM がゲートウェイから TCS を受信するまで待機し、両方のゲートウェイも ISDN 側からの TCS を受信するまで待機するため、デッドロックが発生します。コールは数秒後にタイムアウトし、失敗します。ユーザから見ると、発信者にはコールが進行中であることを示すリングバック トーンが聞こえ、着信側には着信コールを示す呼び出し音が聞こえます。着信側がコールに応答しようとすると、デッドロックのために H.245 フェーズが失敗し、コールは両方で切断されて失敗します。

このようなシナリオの問題の回避策としては、Unified CM で H.320 ゲートウェイを表すデバイスで、[Wait for Far-End to Send TCS] オプションを無効(オフ)にすることを推奨します。H.320 ゲートウェイに到達するように Unified CM を設定した方法に応じて、このデバイスは H.225 ゲートキーパー制御トランクまたは H.323 ゲートウェイ デバイスになります。

ただし、[Wait for Far-End to Send TCS] オプションを無効にすると、交換された初期機能がリモート デバイスで機能しなくなることがあります。たとえば、Unified CM リージョンが 768 kbps ビデオに設定されていても、H.320 デバイスが 384 kbps しかサポートしないことがあります。また、選択された音声コーデックがリモート側で機能しないことがあります。この場合、初期ネゴシエートされた論理チャネルを切断し、正しい速度とコーデックで再開する必要があります。多くのレガシー H.323 および H.320 デバイスは、この状態を正しく処理せず、Unified CM が CloseLogicalChannel メッセージを送信して異なる値でチャネルと再ネゴシエートすると、コールを切断します。そのため、[Wait for Far-End to Send TCS] オプションを無効にする場所とタイミングには注意が必要です。

トランク

Cisco Unified CM は、さまざまなタイプのトランクをサポートしています。H.323 エンドポイントの配置が非常に多く、コールをビデオ エンドポイントおよびゲートウェイにルーティングする 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 トランクは、Media Termination Point(MTP; メディア ターミネーション ポイント)がなくてもビデオ コールのアーリー オファーをサポートします。これが重要となるのは、コールが複数の呼制御サーバを通過する配置、または双方向メディア パスを確立するためのコールのカットスルー時間が重要となる配置の場合です。詳細については、「Cisco Unified CM トランク」の章を参照してください。

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

マルチポイント会議

3 者以上が同じビデオ コールに同時に参加するには、Multipoint Control Unit(MCU; マルチポイント コントロール ユニット)が必要です。MCU は、次のメイン コンポーネントで構成されています。

マルチポイント コントローラ(MC)

マルチポイント プロセッサ(MP)

MC は、メディア ネゴシエーション、コール シグナリング、コールに使用する MP の選択など、会議のコール セットアップと切断のすべての面を処理します。MP は、すべての音声パケットおよびビデオ パケットを処理します。MC が MP を制御し、1 つの MC で複数の MP を制御できます。MP は、ソフトウェアベースのものも、ハードウェアベースのものもあります。ソフトウェアベースの MP は、通常、高度なトランスコーディング、トランスレーティング(複数の速度)、構成機能は実行できません。

Cisco MCU では、Skinny Client Control Protocol(SCCP)もサポートされています。これにより、Cisco IOS カンファレンス ブリッジがオーディオ会議に統合できるように、MCU がビデオ カンファレンス ブリッジとして Unified CM に統合可能になります。

Cisco Unified Videoconferencing 製品では、Multipoint Conference Unit(MCU; マルチポイント カンファレンス ユニット)に、Multipoint Controller(MC; マルチポイント コントローラ)機能と Multipoint Processor(MP; マルチポイント プロセッサ)機能が統合デバイスとして組み込まれています。シャーシ ベースの MCU では、ビデオ会議を実行する Enhanced Media Processor(EMP)モジュールを管理および制御する MCU モジュールを使用することによって、柔軟性と拡張性が提供されます。


) Cisco 3545 および 5200 MCU には、ソフトウェア ベースの MP が備えられていないため、EMP が必要です。MCU モジュールは、MCU シャーシの EMP を制御するために必要です。


Cisco Unified CM では、SCCP、H.323、および SIP モードで Cisco Unified Videoconferencing MCU がサポートされています。各プロトコルにはさまざまな機能が用意され、さまざまな理由で使用されます。そのため、3 つのプロトコルすべてを実行するように、これらの各 MCU が搭載されています。Cisco Unified Videoconferencing MCU は 3 つすべてのプロトコルを実行し、これら 3 つの間で利用可能な MP リソースの合計数を分割するように設定できます。

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

Voice-Activated(音声起動)(切り替え)

Continuous-Presence(連続表示)

Voice-Activated(音声起動)

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

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

Voice-Activated モード

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

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

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

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

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

Continuous-Presence(連続表示)

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


) Continuous-Presence には、Cisco Unified Videoconferencing MCU の Enhanced Media Processor(EMP)が必要です。


MP リソース

どちらのタイプの会議でも、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 クライアントの場合、Unified CM は、H.323 クライアントで別のコールの生成を許可しません。そのため、内蔵 MCU の機能は無効になります。


Ad-Hoc 会議用の MCU リソース

すでに説明したように、Cisco Unified Videoconferencing MCU では、これらのモデルのソフトウェア バージョン 3.2+ および Cisco Unified CM Release 4.0 から SCCP をサポートしています。SCCP モードで設定すると、Unified CM が MC 機能を提供し、MCU が MP 機能を提供します。SCCP MCU は、Unified CM で完全に制御されます。Cisco Unified CM 8.6 以降のリリースは、カンファレンス ブリッジ経由の SIP ベースの TelePresence MCU をサポートします。その結果、より高い解像度をサポートできる Ad-Hoc 会議用の MCU 統合の方法も提供します。

Ad-Hoc MCU リソースを呼び出すのは、次のイベントだけです。

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

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

ソフトフォン モードの Cisco Cius または Cisco Unified Personal Communicator のユーザが、参加機能または会議機能を使用して会議に複数のコールを参加させた。

これらのタイプの会議の参加者には、任意のタイプのエンドポイント(サポートされる任意のゲートウェイ タイプを介して Unified CM がサポートする任意のシグナリング プロトコルを使用するビデオ デバイスおよび非ビデオ デバイス)が含まれます。ただし、Ad-Hoc MCU リソースを呼び出せるのは、SCCP エンドポイント、SIP Cisco IP Phone、または Cisco Unified Personal Communicator だけです。つまり、H.323 ビデオ エンドポイントは Ad-Hoc 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」の項を参照してください。


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

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

図 12-7 SCCP エンドポイント、SIP エンドポイント、および H.323 エンドポイントの間の Ad-Hoc 会議

 

Ad-Hoc 会議は、使用されるカンファレンス ブリッジに応じて、Voice-Activated モードと Continuous-Presence をサポートします。

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

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

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

インテリジェント ブリッジ選択機能では、次のタイプのエンドポイントがビデオ対応として扱われます。

Cisco Unified Video Advantage(IP Phone の PC ポートに接続された PC 上で実行する必要があります)

Cisco Unified IP Phone 7985G および 9900 シリーズ

Cisco Unified Personal Communicator または Client Services Framework クライアント

H.323 クライアント(サードパーティ製ビデオ エンドポイント)

SIP Advanced エンドポイント(サードパーティ製ビデオ エンドポイント)

ビデオ コール用 Media Termination Point(MTP; メディア ターミネーション ポイント)のない SIP トランク

ビデオ コール用 MTP のない H.323 トランク

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

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

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

他のブリッジ選択方式では音声のみの会議に占有されかねない、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 Unified Video Advantage(IP Phone の PC ポートに接続された PC 上で実行する必要があります)

Cisco Unified IP Phone 7985G

Cisco Unified Personal Communicator

H.323 クライアント(サードパーティ製ビデオ エンドポイント)

SIP Advanced エンドポイント(サードパーティ製ビデオ エンドポイント)

ビデオ コール用 Media Termination Point(MTP; メディア ターミネーション ポイント)のない SIP トランク

ビデオ コール用 MTP のない H.323 トランク

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

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

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

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


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


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

H.323 または SIP モードで設定すると、MCU は MC 機能を提供し、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 エンドポイントが H.323 MCU にダイヤルインして、H.323 エンドポイントと同様に予約なしの会議を作成できます。

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

図 12-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)

フレーム レート(15 または 30 fps)

解像度(QCIF または CIF)

MP リソース(Auto、MP、RM、または EMP)

表示するビデオ レイアウト(Voice-Activated または Continuous-Presence)

会議には複数のレイアウトを含めることができ、会議の参加者数が増減したときに変化する動的レイアウトもあります。

H.323 と SIP、または SCCP

[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 サービスに「ダイヤル」インしないため、番号自体に意味はありません。プレフィックスは、Unified CM と SCCP MCU リソースとの間の SCCP 登録メッセージでのみ使用されます。ユーザは、[Conf]、[Join]、または [cBarge] ソフトキーを使用して SCCP MCU 会議にアクセスするか(Ad-Hoc)、Unified CM で割り当てられた MeetMe 番号をダイヤルして会議に参加します(予約なし)。そのため、SCCP サービス プレフィックスに指定した番号は関係ありません。999999 など、任意の番号を自由に指定できます。このプレフィックスは、MCU と Unified CM との間の SCCP シグナリングの外側には公開されません(つまり、ダイヤルすることも、ゲートキーパーへの MCU の登録に含むこともできません)。


) Cisco MeetingPlace Express メディア サーバでは、SCCP がサポートされています。この統合を使用すると、Cisco Unified Videoconferencing MCU と同様に、Cisco MeetingPlace Express メディア サーバで Unified CM に Ad-Hoc カンファレンス ブリッジを提供できます。


MCU のサイジング

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

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

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

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

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

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


) 1 つの SCCP 会議が複数の EMP にまたがることはできません。各 SCCP 会議は、最大 24 人の参加者をサポートします。


サポートされるポート数に関する特定の情報については、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 を使用できます。

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 にビデオ サポートが導入されるまで、H.323 ビデオ会議ネットワークは、デバイス登録管理、コール ルーティング、および帯域幅制御を実行するゲートキーパーに依存していました。以前は Multimedia Conference Manager(MCM)と呼ばれていた Cisco IOS Gatekeeper が、これらの機能を提供します。ただし、シスコ製品を含むほとんどのゲートキーパーは、一般的なエンタープライズクラスの PBX で期待される機能と比較して、基本的なコール ルーティング機能だけを提供します。H.323 ビデオ コールのルーティングに使用する場合、Unified CM が基本的なゲートキーパー機能を補足し、完全なエンタープライズクラスの PBX 機能を H.323 ビデオ コールに提供します。

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

図 12-9 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 をサポートしないため、冗長性のために Hot Standby Routing Protocol(HSRP; ホットスタンバイ ルータ プロトコル)を使用するようにゲートキーパーを設定する必要があります。これらの 2 つの冗長性方式を同じゲートキーパーに混在させ、組み合わせることはできません。この場合、Alternate Gatekeeper をサポートするエンドポイント用にゲートキーパー クラスタを使用するか、サポートしないエンドポイント用にゲートキーパーの HSRP ペアを使用するかを決定します。

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

図 12-10 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 Client)を作成し、ディレクトリ番号を割り当て、コーリング サーチ スペース、デバイス プールなどを割り当てます。Unified CM で H.323 クライアントは、次のいずれかの方法で設定します。使用する方法は、クライアントが静的 IP アドレスを使用するかどうか、クライアントで E.164 アドレスをダイヤルする RAS プロシージャが必要かどうかによって異なります。

ゲートキーパー制御

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

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

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

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

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

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

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

 

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

 

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

 

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

 

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

 

図 12-16 非ゲートキーパー制御クライアントから 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 アプリケーション

次のアプリケーションは、Computer Telephony Integration(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 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 にコールをルーティングできます。

サードパーティ製の 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 Communications Manager Assistant

Cisco Unified Communications Manager Assistant を使用すると、アシスタントが、関連するマネージャに対応できます。Unified CM Assistant は、JTAPI を使用して Unified CM に統合されています。Unified CM Assistant は特にビデオ対応というわけではありませんが、ビデオ対応の電話機でも Unified CM Assistant は問題なく使用できます。Unified CM Assistant がコールを処理し、コールが最終的な宛先デバイスに転送されると、コールの 2 つのデバイスが互いに直接通信し、この時点でビデオ チャネルを確立できます。たとえば、ビデオ対応エンドポイントがマネージャのディレクトリ番号をダイヤルし、アシスタントが Unified CM Assistant アプリケーションを使用してコールをカバーした場合、コールの最初の処理ではビデオは確立されていないことがあります。しかし、アシスタントが発信者をマネージャに転送すると、Unified CM がビデオ チャネルをネゴシエートできるようになります。ただし、H.323 デバイスを Unified CM Assistant と相互運用するには、Empty Capabilities Set(ECS)プロシージャをサポートしている必要があります。H.323 エンドポイントが Unified CM からの ECS の受信をサポートしていない場合、Unified CM Assistant が代行受信したコールは、アシスタントがマネージャにコールを転送しようとしたときに失敗します。

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 サーバが対応していれば、音声認識を使用できます。Cisco Unified Video Advantage などのビデオ対応デバイス、サードパーティ製の SCCP ビデオ デバイス、および DTMF に H.245 英数字アウトオブバンド シグナリングを使用する H.323 エンドポイントは、DTMF トーンを使用して IVR メニューをナビゲートできます。

Cisco Unified Enterprise Attendant Console

Cisco Unified Enterprise Attendant Console は、JTAPI を使用して Unified CM に統合されています。Unified Enterprise Attendant Console は、着信コールを処理する管理用デバイスとして使用されます。Unified Enterprise Attendant Console は、特にビデオをサポートしているわけではありませんが、コールが最終的な宛先に転送されると、ビデオ チャネルをネゴシエートできるようになります。ただし、H.323 デバイスを Unified Enterprise Attendant Console と相互運用するには、Empty Capabilities Set(ECS)プロシージャをサポートしている必要があります。H.323 エンドポイントが Unified CM からの ECS の受信をサポートしていない場合、Unified Enterprise Attendant Console が代行受信したコールは、コンソール担当者が最終的な宛先に発信者を転送しようとしたときに失敗します。

Cisco IP Communicator

Cisco IP Communicator は SCCP ソフトフォンであり、ビデオはサポートでていません。Cisco Unified Video Advantage クライアントを Cisco IP Communicator に関連付けることによって、ビデオを提供できます。バージョン 2.0 では、両方のアプリケーションが同じ PC 上に存在する場合、Cisco IP Communicator を Cisco Unified Video Advantage 2.0 に関連付けることができます。詳細については、「Unified Communications エンドポイント」の章を参照してください。

Cisco IP Communicator 2.1 以降のリリースではまた、Cisco IP Communicator デバイスを作成または追加する際のデバイス プロトコルとして、SIP を選択できます。ただし、SIP プロトコルを使用した Cisco IP Communicator では、Cisco Unified Video Advantage はサポートされていません。

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

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

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

この新しく追加されたサポートの主な目的は、他の方法で必要になる高価な 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 と無線帯域幅を共有しないように注意する必要があります。ビデオは帯域幅の大半を消費するため、ビデオ、音声、およびデータを同じ無線メディアでサポートすることは困難です。

Cisco Unified Video Advantage は、関連付けられた物理 IP Phone への物理イーサネット接続に依存します。ユーザが物理イーサネット インターフェイスと、Aironet 802.11b Wireless Adapter の両方を同じ PC にインストールすることはよくあります。このような設定は、無線インターフェイスがネットワークへの優先パスになった場合に、Cisco Unified Video Advantage がこのインターフェイス経由では関連付けられないため、Cisco Unified Video Advantage で問題が発生する原因になります。常に、物理イーサネット インターフェイスを優先パスにすることを推奨します。また、ユーザが IP Phone の背面の PC ポートに接続するときは、間違って優先されないように Aironet Adapter を無効にするように指示してください。

Cisco Unified Wireless IP Phone 7925G および 7921G

Cisco Unified Wireless IP Phone 7925G および 7921G は、ビデオをサポートしません。ビデオ エンドポイントからも Cisco Unified Wireless IP Phone にコールを発信できますが、音声のみのコールとしてネゴシエートされます。ワイヤレス IP Phone ユーザは、コールの保留、転送、または会議への参加ができます。発信者が H.323 ビデオ エンドポイントの場合、これらの付加サービスを機能させるには、Empty Capabilities Set(ECS)プロシージャをサポートしている必要があります。

XML サービス

現在、特に Cisco Unified Video Advantage クライアント ソリューション、Cisco IP Video Phone 7985、またはサードパーティ製の SCCP ビデオ エンドポイント用に作成された XML アプリケーションはありません。ただし、これらのエンドポイントのうち、少数のサードパーティ製エンドポイント以外は、XML アプリケーションをサポートします。Cisco Unified Video Advantage は Cisco Unified IP Phone を使用するため、これらの電話機モデルでサポートされる XML アプリケーションは Unified Video Advantage でも動作します。

ほとんどのサードパーティ製 SCCP ビデオ エンドポイントは XML をサポートしますが、現在、すべての XML アプリケーションがそれらのエンドポイントで動作するわけではありません。たとえば、Cisco エクステンション モビリティおよび Berbee InformaCast 製品は、現在、サードパーティ製の SCCP エンドポイントで動作しない代表的な 2 つの XML アプリケーションです。これらのアプリケーションをサポートするには、エンドポイントのファームウェア アップグレードと、場合によっては Unified CM Administration の変更が必要になります。