デバイスプールの概要
デバイス プールは、デバイスのグループに対して一連の共通設定を提供します。デバイス プールは、電話、ゲートウェイ、トランク、CTI ルート ポイントなどのデバイスに割り当てることができます。デバイス プールを作成すると、各デバイスを個別に設定する代わりに、各デバイスがデバイス プールの設定を継承するように関連付けることができます。
デバイス プールを使用すると、日時グループ、リージョン、電話用 NTP リファレンスなど、ロケーションに関連した情報を割り当てることによって、デバイスをロケーションに応じて設定できます。デバイス プールは必要なだけ作成できますが、通常はロケーションごとに 1 つです。ただし、デバイス プールを適用することで、職務に応じて設定を適用することもできます(たとえば会社にコール センターがある場合、コール センターの電話と事務管理部門の電話を別々のデバイス プールに割り当てることが考えられます)。
このセクションでは、次のように、デバイスプールのコア設定を設定するために必要な手順について説明します。
-
Network Time Protocol:電話用 NTP リファレンスを設定して、デバイス プール内の SIP デバイスに NTP サポートを提供します。
-
リージョン:特定のリージョンとの間のコールに使用する帯域幅とサポートされる音声コーデックを管理します。
-
Cisco Unified Communications Manager グループ:デバイスに対してコール処理の冗長性と分散コール処理を設定します。
ネットワーク タイム プロトコル
NTP を使用すると、ネットワーク デバイスは、そのクロックをネットワーク タイム サーバまたはネットワーク対応のクロックと同期させることができます。NTP は、すべてのネットワークデバイスの時刻を同じにし、監査ログのタイムスタンプがネットワーク時間と一致するようにするために重要です。請求およびコール詳細レコードなどの機能は、ネットワーク上の正確なタイムスタンプに依存します。また、システム管理者は、トラブルシューティングのために監査ログに正確なタイムスタンプを必要とします。これによって、異なるシステムの監査ログを比較し、信頼できるタイムラインと一連のイベントを作成できます。
インストール時に、Unified Communications Manager パブリッシャ ノード用の NTP サーバをセットアップする必要があります。その後、サーバノードは、リリースサーバノードからそれらの時間を同期させます。
最大 5 個の NTP サーバを割り当てることができます。
電話用 NTP リファレンス
-
SIP 電話の場合: 電話機の NTP 参照を設定し、デバイスプールを使用してそれらを割り当てる必要があります。これらの参照により、ネットワーク時間を提供できる適切な NTP サーバに SIP 電話が送信されます。プロビジョニングされた電話用 NTP リファレンスから SIP 電話が日時を取得できない場合、電話は Unified Communications Manager に登録したときにこの情報を受信します。
-
SCCP 電話機の場合: 電話機の場合: 電話機は、sccp 電話機から、sccp 信号によって直接ネットワーク時間を取得できるため、電話機の NTP 参照は必要ありません。
認証済み NTP
ネットワークの NTP の領域についてネットワーク セキュリティを強化するために、認証済み NTP を設定できます。認証済み NTP の設定を選択した場合は、次のいずれかの認証方法を選択できます。
-
対称キーを使用した認証: このオプションを選択すると、ネットワーク内のデバイスは、対称キーを使用して NTP メッセージの暗号化と認証を行います。このオプションは、RedHat などのベンダーで推奨されています。
-
Autokey (PKI ベースのインフラストラクチャ)を使用した認証: このオプションを選択すると、ネットワーク内のデバイスは、オートキープロトコルを使用して NTP メッセージを暗号化および認証します。この方法は、共通の条件に準拠するために必須です。
-
認証なし:オートキー メソッドを使用した対称キーまたは認証を使用して認証を設定しない場合、NTP メッセージは認証されません。
リージョンの概要
リージョンは、特定のコールについて帯域幅を制限する可能性がある Unified Communications Manager のマルチサイト導入環境向けに、キャパシティ管理を提供します。たとえば、リージョンを使用して、内部コールには高い帯域幅を維持しながら、WAN リンク経由で送信されるコールの帯域幅を制限することができます。リージョンを使用すると、リージョン内またはリージョン間のコールの最大ビットレートを設定することにより、音声コールとビデオ コールの帯域幅を制限できます。
また、特定のコーデックのみをサポートするアプリケーションを使用している場合、システムはリージョンを使用してオーディオ コーデックの優先順位を設定します。サポートされているオーディオ コーデックの優先順位付きリストを設定し、特定のリージョンとの間のコールに適用することができます。
[リージョンの設定(Region Configuration)] ウィンドウで最大オーディオ ビットレートを設定する場合(または [サービスパラメータ設定(Service Parameter Configuration)] ウィンドウのサービス パラメータを使用して)、この設定はフィルタとして機能します。コールでオーディオ コーデックが選択されると、Unified Communications Manager が、適合するコーデックをコール レッグの両側から選択し、設定された最大オーディオ ビットレートを超えるコーデックを除外して、リストに残ったコーデックの中から優先されるコーデックを選択します。
Unified Communications Manager は、最大 2000 のリージョンをサポートします。
サポートされているオーディオ コーデック
Unified Communications Manager は、ビデオ ストリームの暗号化および次の音声コーデックをサポートしています
オーディオ コーデック |
説明 |
||
---|---|---|---|
G.711 |
最も一般的にサポートされているコーデックで、Public Switched Telephone Network(PSTN; 公衆電話交換網)経由で使用されます。 |
||
G.722 |
ビデオ会議でよく使用されるワイドバンド コーデックです。Unified Communications Manager では常に G.711 に優先されます。ただし、G.722 が無効になっている場合を除きます。 |
||
G.722.1 |
24 kb/s および 32 kb/s で動作する、低複雑度のワイドバンド コーデックです。G.722 と同様のオーディオ品質を、半分以下のビット レートで実現します。 |
||
G.728 |
ビデオ エンドポイントがサポートする低ビット レート コーデックです。 |
||
G.729 |
Cisco IP 電話 7900 にサポートされる 8 kb/s 圧縮を使用する低ビットレートコーデックで、通常 WAN リンクでの発信に使用されます。 |
||
GSM |
Global System for Mobile Communications(GSM)コーデックです。GSM は Unified Communications Manager で動作するように、GSM ワイヤレス ハンドセットに対して MNET システムを有効にします。 |
||
L16 |
Advanced Audio Coding-Low Delay(AAC-LD)は、優れた品質の音声や音楽を提供する超広帯域オーディオ コーデックです。このコーデックは、低ビット レートの古いコーデックに対してさえ同等あるいはより良い音質を提供します。 |
||
AAC-LD(mpeg4-generic) |
SIP(Session Initiation Protocol)デバイス、特に Cisco TelePresence Systems でサポートされます。 |
||
AAC-LD(MP4A-LATM) |
Low-overhead MPEG-4 Audio Transport Multiplex(LATM)は、優れた音質を提供する超広帯域オーディオ コーデックです。Tandberg やいくつかのサードパーティ エンドポイントを含む SIP(Session Initiation Protocol)デバイスでサポートされます。
|
||
Internet Speech Audio Codec(iSAC) |
特に低ビット レートと中ビット レートのアプリケーション両方で、低遅延のワイドバンド音質を提供するように設計された適応型広帯域オーディオ コーデックです。 |
||
インターネット低ビット レート コーデック(iLBC) |
独立してエンコードされた音声フレームが原因の損失性ネットワークにおいて音声品質のグレースフル デグラデーションを可能にしつつ、15.2 kb/s と 13.3 kb/s のビット レートで G.711 から G.729 の間の音声品質を提供します。iLBC は、SIP、SCCP、H323、MGCP デバイスでサポートされています。
|
||
アダプティブ マルチレート(AMR) |
GSM に基づく、2.5G/3G ワイヤレス ネットワークで必須の標準規格コーデックです(WDMA、EDGE、GPRS)。このコーデックは、7.4 kb/s 以上のトール品質音声により、4.75 kb/s から 12.2 kb/s の範囲の可変ビット レートでナローバンド(200 ~ 3400 Hz)信号をエンコードします。AMR は SIP(Session Initiation Protocol)デバイスでのみサポートされます。 |
||
アダプティブ マルチレート ワイドバンド(AMR-WB) |
G.722.2 として体系化されており、公式にはワイドバンドとして知られる ITU-T 標準規格音声コーデックは、音声を約 16 kb/s で符号化します。このコーデックは、50 Hz から 7000 Hz の広い音声帯域幅により、優れた音声品質を提供するので、AMR や G.711 などの他のナローバンド音声コーデックに優先されます。AMR-WB は SIP(Session Initiation Protocol)デバイスでのみサポートされます。 |
||
Opus |
Opus コーデックは、インタラクティブな音声およびオーディオコーデックで、特に Voice over IP、ビデオ会議、ゲーム内チャットやライブ配信される音楽演奏などの多様なインタラクティブ オーディオ アプリケーションを処理するために設計されています。 このコーデックは、6 kb/s から 510 kb/s までのナローバンド低ビット レートから超高ビット レートまでをサポートします。 Opus codec のサポートは、すべての SIP デバイスでデフォルトで有効になっています。Opus Codec Enabledサービスパラメータを使用して Opus サポートを再構成できます (デフォルト設定は、すべてのデバイスで有効になっています)。このパラメータを再設定することで、Opus codec のサポートを無効にしたり、非録音デバイスのみのサポートを有効にしたりできます。
|
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 Manager 2 サーバは、グループ 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 に登録します。