デバイス プールの概要
デバイス プールは、デバイスのグループに対して一連の共通設定を提供します。デバイス プールは、電話、ゲートウェイ、トランク、CTI ルート ポイントなどのデバイスに割り当てることができます。デバイス プールを作成すると、各デバイスを個別に設定する代わりに、各デバイスがデバイス プールの設定を継承するように関連付けることができます。
デバイス プールを使用すると、日時グループ、リージョン、電話用 NTP リファレンスなど、ロケーションに関連した情報を割り当てることによって、デバイスをロケーションに応じて設定できます。デバイス プールは必要なだけ作成できますが、通常はロケーションごとに 1 つです。ただし、デバイス プールを適用することで、職務に応じて設定を適用することもできます(たとえば会社にコール センターがある場合、コール センターの電話と事務管理部門の電話を別々のデバイス プールに割り当てることが考えられます)。
このセクションでは、次のように、デバイス プールのコア設定を設定するために必要な手順について説明します。
-
Network Time Protocol:電話用 NTP リファレンスを設定して、デバイス プール内の SIP デバイスに NTP サポートを提供します。
-
リージョン:特定のリージョンとの間のコールに使用する帯域幅とサポートされる音声コーデックを管理します。
-
Cisco Unified Communications Manager グループ:デバイスに対してコール処理の冗長性と分散コール処理を設定します。
Network Time Protocol の概要
Network Time Protocol(NTP)を使用すると、SIP 電話などのネットワーク デバイスがクロックをネットワーク タイム サーバまたはネットワーク対応のクロックと同期できるようになります。NTP は、すべてのネットワーク デバイスの時刻を同じにし、監査ログのタイムスタンプをネットワーク時間と一致させるために重要です。課金情報およびコール詳細レコードなどの機能は、ネットワーク全体の正確なタイムスタンプに依存します。また、システム管理者は、トラブルシューティングの目的で監査ログの正確なタイムスタンプを必要とします。これが正確であることで、異なるシステムの監査ログを比較し、発生している問題がどのようなものであっても、信頼できるタイムラインとイベントの順序を確認できます。
インストール時に、Unified Communications Manager パブリッシャ ノード用の NTP サーバをセットアップする必要があります。それにより、サーバ ノードはパブリッシャ ノードから時間を同期します。
NTP サーバは最大で 5 個割り当てることができます。
電話用 NTP
-
SIP 電話の場合:電話用 NTP リファレンスを設定し、デバイス プールを使用してそれらを割り当てる必要があります。これらのリファレンスにより、SIP 電話は、ネットワーク時刻を提供できる適切な NTP サーバを参照します。プロビジョニングされた電話用 NTP リファレンスから SIP 電話が日時を取得できない場合、電話は Unified Communications Manager に登録したときにこの情報を受信します。
-
SCCP 電話の場合:SCCP 電話は SCCP シグナリングを介して Unified Communications Manager からネットワーク時刻を直接取得できるため、電話用 NTP リファレンスは必要ありません。
認証済み NTP
ネットワークの NTP の領域についてネットワーク セキュリティを強化するために、認証済み NTP を設定できます。認証済み NTP を設定する場合は、次のいずれかの認証方法を選択できます。
-
対称キーを使用した認証:このオプションを選択する場合、ネットワーク内のデバイスは NTP メッセージの暗号化と認証に対称キーを使用します。このオプションは、Red Hat などのベンダーで推奨されています。
-
Autokey による認証(PKI ベースのインフラストラクチャ):このオプションを選択する場合、ネットワーク内のデバイスは NTP メッセージの暗号化と認証に Autokey プロトコルを使用します。この方法は、コモン クライテリアに準拠するためには必須となります。
-
認証なし:対称キーによる認証または Autokey 方式の認証を設定しない場合、NTP メッセージは認証されません。
リージョンの概要
リージョンは、特定のコールについて帯域幅を制限する可能性がある Unified Communications Manager のマルチサイト導入環境向けに、キャパシティ管理を提供します。たとえば、リージョンを使用して、内部コールには高い帯域幅を維持しながら、WAN リンク経由で送信されるコールの帯域幅を制限することができます。リージョンを使用すると、リージョン内またはリージョン間のコールの最大ビットレートを設定することにより、音声コールとビデオ コールの帯域幅を制限できます。
また、特定のコーデックのみをサポートするアプリケーションを使用している場合、システムはリージョンを使用してオーディオ コーデックの優先順位を設定します。サポートされているオーディオ コーデックの優先順位付きリストを設定し、特定のリージョンとの間のコールに適用することができます。
[リージョンの設定(Region Configuration)] ウィンドウで最大オーディオ ビットレートを設定する場合(または [サービスパラメータ設定(Service Parameter Configuration)] ウィンドウのサービス パラメータを使用して)、この設定はフィルタとして機能します。コールでオーディオ コーデックが選択されると、Unified Communications Manager が、適合するコーデックをコール レッグの両側から選択し、設定された最大オーディオ ビットレートを超えるコーデックを除外して、リストに残ったコーデックの中から優先されるコーデックを選択します。
Unified Communications Manager は、最大 2000 のリージョンをサポートします。
サポートされるオーディオ コーデック
Unified Communications Manager は、ビデオ ストリームの暗号化および次の音声コーデックをサポートしています
オーディオ コーデック |
説明 |
||
---|---|---|---|
G.711 |
公衆電話交換網に使用される、最も広くサポートされているコーデック。 |
||
G.722 |
ビデオ会議でよく使用されるワイドバンド コーデック。G.722 が無効化されている場合を除き、Unified Communications Manager では常にこれが優先されます。 |
||
G.722.1 |
24 および 32 kb/s で動作する低複雑度のワイドバンド コーデック。使用するビット レートはほぼ半分ですが、音声品質は G.722 の品質に近づいています。 |
||
G.728 |
ビデオ エンドポイントがサポートする低ビット レート コーデック。 |
||
G.729 |
Cisco IP Phone 7900 がサポートしており、通常 WAN リンクでの発信に使用される、8 kb/s 圧縮を使用する低ビット レートのコーデック。 |
||
GSM |
Global System for Mobile Communications(GSM)コーデック。GSM を使用すると、GSM ワイヤレス ハンドセット用の MNET システムを Unified Communications Manager と連携させることができます。 |
||
L16 |
Advanced Audio Coding-Low Delay(AAC-LD)は、音声と音楽向けに優れた音質を提供するスーパー広帯域オーディオ コーデックです。このコーデックは、低ビット レートの場合でも、古いコーデックと同等以上の音質を提供します。 |
||
AAC-LD(mpeg4-generic) |
SIP デバイス、特に、Cisco TelePresence Systems に対してサポートされています。 |
||
AAC-LD(MP4A-LATM) |
Low-overhead MPEG-4 Audio Transport Multiplex(LATM)は優れた音を提供するスーパー広帯域オーディオ コーデックです。TANDBERG や一部のサードパーティのエンドポイントを含む、SIP デバイスに対してサポートされています。
|
||
Internet Speech Audio Codec(iSAC) |
特に、低ビット レートと中ビット レートの両アプリケーションにおいて、低遅延でワイドバンド音質を提供するように設計された適応型広帯域オーディオ コーデック。 |
||
インターネット低ビット レート コーデック(iLBC) |
個別にエンコードされた音声フレームに起因する損失性ネットワークでのグレースフルな音声品質の低下を許可している間に、15.2 および 13.3 kb/s のビット レートで G.711 と G.729 の間の音声品質を提供します。iLBC は、SIP、SCCP、H323、および MGCP デバイスに対してサポートされています。
|
||
アダプティブ マルチレート(AMR) |
GSM(WDMA、EDGE、GPRS)に基づいた 2.5G/3G ワイヤレス ネットワークに必要な標準コーデック。このコーデックは、4.75 ~ 12.2 kb/s の範囲の可変ビット レートでナローバンド(200 ~ 3400 Hz)信号をエンコードし、7.4 kb/s で始まる公衆電話交換網レベルの音声品質を提供します。AMR は SIP デバイスでのみサポートされます。 |
||
アダプティブ マルチレート ワイドバンド(AMR-WB) |
正式にはワイドバンドとして知られている ITU-T 標準音声コーデックである G.722.2 として体系化されており、約 16 kb/s で音声をコード化します。このコーデックは、広い音声帯域幅(50 ~ 7000 Hz)によって、より良い音声品質を提供できるため、その他のナローバンド音声コーデック(AMR や G.711 など)より優先されます。AMR-WB は SIP デバイスでのみサポートされます。 |
||
Opus |
Opus コーデックはインタラクティブな音声およびオーディオ コーデックです。特に、Voice over IP、ビデオ会議、ゲーム内チャット、ライブ配信の音楽パフォーマンスなど、さまざまなインタラクティブ オーディオ アプリケーションに対応するために設計されています。 このコーデックは、ナローバンド低ビットレートから非常に高品質のビット レート(6 ~ 510 kb/s)まで拡大します。 Opus コーデックのサポートは、すべての SIP デバイスでデフォルトで有効になっています。[Opusコーデックの有効化(Opus Codec Enabled)] サービス パラメータを使用して Opus サポートの設置を変更できます(デフォルト設定は、[すべてのデバイスで有効(Enabled for All Devices)] です)。このパラメータの設定を変更することで、Opus コーデックのサポートを無効化することや、非録音デバイスでのみサポートを有効化することができます。
|
Cisco Unified CM グループの概要
Unified Communications Manager グループは、デバイスが登録できる最大 3 台の冗長構成のサーバについての、優先順位付きリストです。各グループには、1 個のプライマリ ノードと最大 2 個のバックアップ ノードが含まれます。ノードをリストする順序によって、1 番目のノードがプライマリ ノード、2 番目のノードがバックアップ ノード、3 番目のノードが第 3 ノードとして優先順位が決定されます。[デバイスプールの設定(Device Pool Configuration)] を使用して、Cisco Unified Communictions Manager グループにデバイスを割り当てることができます。
Unified Communications Manager グループは、システムに 2 つの重要な機能を提供します。
-
コール処理の冗長性:デバイスが登録するときに、そのデバイス プールに割り当てられているグループ内のプライマリ(1 番目)Unified Communications Manager への接続を試みます。プライマリ Unified Communications Manager が使用可能ではない場合、デバイスは最初のバックアップ ノードに接続しようとし、そのノードが使用可能ではない場合は、第 3 のノードに接続を試みます。各デバイス プールには Unified Communications Manager グループが 1 つ割り当てられます。
-
分散コール処理:複数のデバイス プールと Unified Communications Manager グループを作成することで、デバイスの登録を複数の Unified Communications Manager に均等に分散できます。
ほとんどのシステムでは、より適切な負荷分散と冗長性を実現するために、複数のグループに対して Unified Communications Manager を割り当てます。
コール処理の冗長性
Unified Communications Manager グループは、コール処理の冗長性と回復の機能を提供します。
-
フェールオーバー:グループのプライマリ Unified Communications Manager で障害が発生し、そのグループのバックアップ Unified Communications Manager にデバイスが再登録するときに実行されます。
-
フォールバック:障害が発生したプライマリ Unified Communications Manager が復旧し、そのグループのデバイスがプライマリ Unified Communications Manager に再登録されるときに実行されます。
通常動作では、グループ内のプライマリ Unified Communications Manager は、電話およびゲートウェイなど、そのグループに関連付けられたすべての登録デバイスのコール処理を制御します。
プライマリの Unified Communications Manager で何らかの理由で障害が発生した場合、グループの 1 番目のバックアップ Unified Communications Manager が、プライマリ Unified Communications Manager に登録されたデバイスを制御します。グループに 2 番目のバックアップ Unified Communications Manager を指定する場合、プライマリと 1 番目のバックアップ両方の Unified Communications Manager で障害が発生した場合には、2 番目がデバイスを制御します。
障害が発生したプライマリ Unified Communications Manager の機能が回復すると、グループの制御が戻り、そのグループのデバイスは自動的にプライマリ Unified Communications Manager に再登録されます。
例
たとえば、次の図はシンプルなシステムを示しており、1 つのグループに 3 つのUnified Communications Manager があり、800 台のデバイスを制御しています。
この図は、DP1 と DP2 の 2 つのデバイス プールが割り当てられている Unified Communications Manager グループ G1を示します。通常動作では、Unified Communications Manager 1 は、G1グループのプライマリ Unified Communications Manager として、DP1 と DP2 の 800台すべてのデバイスを制御します。Unified Communications Manager 1 で障害が発生した場合、800 台すべてのデバイスの制御が Unified Communications Manager 2 に移ります。Unified Communications Manager 2 でも障害が発生した場合、800 台すべてのデバイスの制御が Unified Communications Manager 3 に移ります。
この構成ではコール処理の冗長性が提供されますが、コール処理の負荷はこの例の 3 つの Unified Communications Manager 間でうまく分散されません。Unified Communications Manager グループとデバイス プールを使用して、クラスタ内で分散コール処理を提供する方法については、次のトピックを参照してください。
(注) |
空の Unified Communications Manager グループは機能しません。 |
分散コール処理
Cisco Unified Communications Manager グループは、コール処理の冗長化と分散型コール処理の両方を実現します。デバイス、デバイス プール、および Unified Communications Manager をどのようにグループに割り当てるかによって、システムの冗長性とロード バランシングのレベルが決まります。
多くの場合、グループ内の 1 つの Cisco Unified Communications Manager に障害が起きた場合に、他の Cisco Unified Communications Manager が過負荷にならないようにデバイスを分散する必要があります。次の図は、3 つの Cisco Unified Communications Manager と 800 のデバイスから成るシステムで分散型コール処理と冗長化を実現するために、Cisco Unified Communications Manager グループとデバイス プールを設定する方法の一例を示しています。
この図は、設定されてデバイス プールに割り当てられたUnified Communications Manager グループを表します。Unified Communications Manager 1 は、G1 と G2 の 2 つのグループでプライマリ コントローラとして機能します。If Unified Communications Manager に障害が起きた場合、DP3 の 100 台のデバイスは Unified Communications Manager 1 に再登録され、DP2の 300 台のデバイスはUnified Communications Manager 3に再登録されます。同様に、Unified Communications Manager2 は、グループ G3 と G4 のプライマリ コントローラとして機能します。Unified Communications Manager 2 で障害が発生した場合、DP3 の 100 台のデバイスが Unified Communications Manager 1 に登録し、DP3 の 300 台のデバイスが Unified Communications Manager 3 に登録します。Unified Communications Manager 1 と Unified Communications Manager 2 の両方で障害が発生した場合は、すべてのデバイスが Unified Communications Manager 3 に登録します。