デバイスプールの概要
デバイス プールは、デバイスのグループに対して一連の共通設定を提供します。 デバイス プールは、電話、ゲートウェイ、トランク、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 は、Cisco Unified Communications Manager パブリッシャノードで設定されます。 サブスクライバ ノードと IM and Presenceノードは、Unified CM Publisherノードからの時刻を同期します。
次の認証方法から選択できます。
-
対称キーを使用した認証: このオプションを選択すると、ネットワーク内のデバイスは、対称キーを使用して 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 |
公衆電話交換網に使用される、最も広くサポートされているコーデック。 |
||
G.722 |
ビデオ会議でよく使用されるワイドバンド コーデック。 G.722 は無効になっていない限り、Unified Communications Manager では常に G.711 より優先されます。 |
||
G.722.1 |
24 および 32 kb/s で動作する低複雑度のワイドバンド コーデック。 使用するビット レートはほぼ半分ですが、音声品質は G.722 の品質に近づいています。 |
||
G.728 |
ビデオエンドポイントがサポートする低ビットレートコーデック。 |
||
G.729 |
Cisco IP 電話 7900 でサポートされている 8 kb/s 圧縮を使用する低ビット レート コーデック。通常は、WAN リンクを通過するコールに使用されます。 |
||
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) |
低オーバーヘッド MPEG-4 オーディオトランスポートマルチプレックス(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〜510kb / 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 に再登録されます。
例
たとえば、 次の図は 800 台のデバイスを制御する単一グループ内の 3 台の Unified Communications Manager を備えた簡単なシステムを示しています。
この図 は、2 つのデバイス プール DP1 と DP2 が割り当てられている Unified Communications Manager グループ G1 を示しています。 Unified Communications Manager 1 は、グループ G1 のプライマリ Unified Communications Manager であり、通常の動作時には、DP1 と DP2 の 800 台のデバイスをすべて制御しています。 Unified Communications Manager1 に障害が発生した場合、800 台すべてのデバイスの制御は Unified Communications Manager 2 に移ります。Unified Communications Manager 2 にも障害が発生した場合は、800 台すべてのデバイスの制御は Unified Communications Manager 3 に移ります。
この構成では、コール処理の冗長化は実現していますが、コール処理の負荷は、この例の 3 台の Unified Communications Manager 間で適切に分散されていません。 Unified Communications Manager グループとデバイス プールを使用して、クラスタ内で分散コール処理を提供する方法については、次のトピックを参照してください。
(注) |
空の Unified Communications Manager グループは機能しません。 |
分散コール処理
Unified Communications Manager グループは、コール処理の冗長性と分散型コール処理の両方を提供します。 デバイス、デバイス プール、および Unified Communications Manager をどのようにグループに割り当てるかによって、システムの冗長性とロード バランシングのレベルが決まります。
多くの場合、グループ内の 1 台の Unified Communications Manager に障害が起きた場合に、他の Unified Communications Manager が過負荷状態にならないようにデバイスを分散する必要があります。 次の図は、3 台の と 800 台のデバイスで構成されるシステムで、分散型コール処理と冗長化の両方を実現するための グループとデバイス プールの設定例を示しています。Unified Communications ManagerUnified Communications Manager
上の図は、 グループの設定、デバイス プールへの割り当てを示しています。 1 は、2 つのグループ G1 と G2 でプライマリ コントローラとして機能します。Unified Communications ManagerUnified Communications ManagerUnified Communications Manager 1 で障害が発生した場合、デバイスプール DP1 の 100 台のデバイスは Unified Communications Manager 2 に再登録され、DP2 の 300 台のデバイスは Unified Communications Manager 3 に再登録されます。同様に、Unified Communications Manager 2 はグループ G3 と G4 のプライマリコントローラとして機能します。 Unified Communications Manager 2 で障害が発生した場合、DP3 の 100 台のデバイスは Unified Communications Manager 1 に再登録され、DP4 の 300 台のデバイスは Unified Communications Manager 3 に再登録されます。Unified Communications Manager 1 と Unified Communications Manager 2 の両方で障害が発生した場合は、すべてのデバイスは Unified Communications Manager 3 に再登録されます。