Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン Cisco CallManager Release 4.0 および 4.1

Cisco Unity

---

この章では、Cisco Unity と Cisco CallManager の統合について、設計上の側面を中心に説明します。この章で扱う設計に関するトピックは、ボイスメール配置とユニファイド メッセージング配置の両方に適用されます。

さらに、この章では、Microsoft Exchange 2000 または 2003 メッセージ ストアあるいは Lotus Notes Domino メッセージ ストアおよび Microsoft Windows 2000 または 2003 と共に Cisco Unity を配置する場合の設計上の問題についても説明します。この章では、Microsoft NT 4.0 や Exchange 5.5 による配置、および Microsoft NT 4.0 や Exchange 5.5 からのアップグレードは扱いません。

シスコ以外のメッセージング システムとの統合など、Cisco Unity に関するその他の設計情報については、次の Web サイトで入手可能な『 Cisco Unity Design Guide 』を参照してください。

http://www.cisco.com

この章では、Cisco Unity の設計に関する次のトピックについて取り上げます。

• 「メッセージング配置モデル」

• 「メッセージング システム インフラストラクチャ コンポーネント」

• 「帯域幅の管理」

• 「Cisco Unity のネイティブ トランスコーディング動作」

• 「Cisco CallManager クラスタとの音声ポート統合」

• 「専用 Cisco CallManager バックアップ サーバを使用する音声ポート統合」

• 「集中型メッセージングと集中型コール処理」

• 「分散型メッセージングと集中型コール処理」

• 「結合されたメッセージング配置モデル」

• 「集中型メッセージングと WAN を介したクラスタ化」

• 「分散型メッセージングと WAN を介したクラスタ化」

• 「Cisco Unity メッセージング フェールオーバー」

• 「Cisco Unity フェールオーバーと WAN を介したクラスタ化」

• 「集中型メッセージングと複数の Cisco CallManager サーバ」

Cisco CallManager Release 4.0 では、回線グループ、ハント リスト、およびハント パイロットが導入されています。これらは、既存の音声ポートの動作に影響を及ぼすことができます。旧バージョンの Cisco CallManager から Cisco CallManager Release 4.0 以降にアップグレードする前に、該当する 4. x リリースの『 Cisco CallManager Administration Guide 』を参照してください。このマニュアルは、次の Web サイトで入手できます。

http://www.cisco.com

この章で説明する配置モデルおよび設計上の考慮事項はすべて、Cisco CallManager Release 3.1 以降によって完全にサポートされています。

メッセージング配置モデル

Cisco Unity は、次の 3 つの主なメッセージング配置モデルをサポートしています。

• 「単一サイト メッセージング」

• 「集中型メッセージング」を使用するマルチサイト WAN 配置

• 「分散型メッセージング」を使用するマルチサイト WAN 配置

Cisco CallManager と Cisco Unity の両方を含む配置では、Cisco CallManager に 1 つのコール処理モデルを使用し、Cisco Unity に 1 つのメッセージング モデルを使用します。メッセージング配置モデルは、配置されるコール処理モデルのタイプに依存しません。

3 つのメッセージング配置モデルに加えて、Cisco Unity はメッセージング フェールオーバーもサポートしています（「メッセージング フェールオーバー」を参照してください）。

すべてのメッセージング配置モデルが、ボイスメールとユニファイド メッセージングの両方のインストールをサポートしています。

メッセージング フェールオーバー

3 つのメッセージング配置モデルはすべて、メッセージング フェールオーバーをサポートしています。図13-1 に示しているように、ローカル メッセージング フェールオーバーを実装できます。ローカル フェールオーバーでは、プライマリ Cisco Unity サーバとセカンダリ Cisco Unity サーバの両方が、アベイラビリティの高い同じ LAN 上の同じサイトに置かれます。

図13-1 Cisco Unity メッセージングのローカル フェールオーバー

 

Cisco Unity および Cisco CallManager は、メッセージング配置モデルとコール処理配置モデルの次の組み合せをサポートしています。

• 単一サイト メッセージングと単一サイト コール処理

• 集中型メッセージングと集中型コール処理

• 分散型メッセージングと集中型コール処理

• 集中型メッセージングと分散型コール処理

• 分散型メッセージングと分散型コール処理

サイト分類の詳細、およびメッセージング配置モデルとコール処理配置モデルのサポートされている組み合せの詳細な分析については、 http://www.cisco.com で入手可能な『 Cisco Unity Design Guide 』を参照してください。

メッセージング システム インフラストラクチャ コンポーネント

Cisco Unity は、Dynamic Domain Name Server（DDNS）、ディレクトリ サーバ、メッセージ ストアなど、さまざまなネットワーク リソースと対話します（図13-2 を参照してください）。Cisco Unity は、単一の一体型デバイスではなく、相互依存コンポーネントのシステムと見なす方が適しています。正常に動作するには、Cisco Unity メッセージング システムの各メッセージング システム インフラストラクチャ コンポーネントが必要であり、これらすべてのコンポーネントがアベイラビリティの高い同じ LAN 上に存在することが重要です（ほとんどの場合、これらのコンポーネントは物理的に同じ場所に置かれます）。これらのコンポーネント間に WAN リンクがある場合は、どのような WAN リンクでも、Cisco Unity の動作に影響を及ぼす遅延を引き起こす可能性があります。このような遅延は、TUI 操作中の長い遅延や無音期間となって表れます。詳細については、 http://www.cisco.com から入手可能な『 Cisco Unity Design Guide 』の「 Network and Infrastructure Considerations 」の章を参照してください。

図13-2 Cisco Unity メッセージング システム インフラストラクチャ コンポーネント

図13-2 は、メッセージ システム インフラストラクチャ コンポーネントを論理的に表現したものです。これらのコンポーネントのいくつかは、同じサーバ上に置くことができます。Domino Lotus Notes の場合、メッセージ ストアとディレクトリ（Names.nsf）が同じサーバ上に置かれます。Microsoft Windows、グローバル カタログ サーバ、およびドメイン コントローラも同じサーバ上に置くことができます。メッセージ ストア クラスタリングの場合と同様に、Cisco Unity が Microsoft Exchange 2000 または 2003 および Lotus Domino に対してサポートする各コンポーネントの複数のインスタンスを使用することもできます。すべてのメッセージング システム インフラストラクチャ コンポーネントは、サービス提供先の Cisco Unity サーバと同じ、アベイラビリティの高い LAN 上に置く必要があります。分散型メッセージングを使用して Cisco Unity を配置する場合は、各サイト（ロケーション）がメッセージング システム コンポーネントの独自の完全なセットを持っている必要があります。

帯域幅の管理

Cisco CallManager は、帯域幅を管理するためのさまざまな機能を備えています。リージョン、ロケーション、およびゲートキーパーさえも使用して、Cisco CallManager は、WAN リンクを介して伝送される音声コールの数によって既存の帯域幅がオーバーサブスクリプションの状態になることがなく、音声品質が低下しないことを保証できます。Cisco Unity は、帯域幅の管理とコールのルーティングを Cisco CallManager に依存しています。コール（音声ポート）が WAN リンクを通過することのある環境に Cisco Unity を配置する場合、このようなコールはゲートキーパーベースのコール アドミッション制御にとって透過的になります。このような状況は、Cisco Unity サーバが分散クライアントにサービスを提供している場合（分散型メッセージングまたは分散型コール処理）、または Cisco CallManager がリモートに置かれている場合（分散型メッセージングまたは集中型コール処理）、いつでも発生します。ゲートキーパーベースのコール アドミッション制御に代わる唯一の方法は、Cisco CallManager のリージョンとロケーションの使用です。

図13-3 では、集中型メッセージングと集中型コール処理を使用する小規模なサイトで、リージョンとロケーションを連携させて使用可能な帯域幅を管理する方法を示しています。リージョンとロケーションの詳細については、「コール アドミッション制御」を参照してください。

図13-3 ロケーションとリージョン

図13-3 では、リージョン 1 と 2 が、リージョン内コールに G.711 を使用し、リージョン間コールに G.729 を使用するように設定されています。ロケーション 1 と 2 は、両方 24 kbps に設定されています。ロケーションの帯域幅は、ロケーション間コールの場合にだけ配分されます。

リージョン内（G.711）コールは、ロケーションの使用可能な帯域幅に対して配分されません。たとえば、内線番号 100 が内線番号 101 をコールする場合、このコールはロケーション 1 の使用可能帯域幅 24 kbps に対して配分されません。ただし、G.729 を使用するリージョン間コールは、ロケーション 1 とロケーション 2 の両方の帯域幅割り当て 24 kbps に対して配分されます。たとえば、内線番号 100 が内線番号 200 をコールすると、このコールは接続されますが、追加の（同時）リージョン間コールでは、リオーダー（ビジー）トーンが聞こえます。

AAR によってルーティングされるボイスメール コールで RDNIS が送信されないことによる影響

Cisco CallManager の機能である Automated Alternate Routing（AAR; 自動代替ルーティング）では、WAN がオーバーサブスクリプションの状態になった場合に、公衆網を介してコールをルーティングできます。ただし、公衆網を介してコールが再ルーティングされる場合、Redirected Dialed Number Information Service（RDNIS）が損なわれることがあります。Cisco Unity がメッセージング クライアントに対してリモートである場合は、正しくない RDNIS 情報によって、AAR が外線を介して再ルーティングするボイスメール コールに影響が及ぼされることがあります。RDNIS 情報が正しくない場合、コールはダイヤル先のユーザのボイスメール ボックスに到達せず、自動アテンダント プロンプトを受信します。発信者は、到達を試みているユーザの内線番号を再入力するように要求されることがあります。この動作は、主に、電話通信事業者がネットワークを介した RDNIS を保証できない場合の問題です。通信事業者が RDNIS の正常な送信を保証できない理由は数多くあります。通信事業者に問い合せて、回線のエンドツーエンドで RDNIS の送信を保証しているかどうかを確認してください。オーバーサブスクリプションの状態になった WAN に対して AAR を使用する代わりの方法は、単に、オーバーサブスクリプションの状況で発信者にリオーダー トーンが聞こえるようにすることです。

Cisco Unity のネイティブ トランスコーディング動作

デフォルトでは、Cisco Unity サーバは自動的にトランスコーディングを実行します。現在、Cisco CallManager および Cisco Unity は、SCCP TAPI Service Provider（TSP）音声ポートに対して G.729 と G.711 だけをサポートしています。他のコーデックは、Intel または Dialogic の音声ボードを使用する従来型の統合でサポートされています。Cisco Unity のネイティブ トランスコーディングは、外部ハードウェア トランスコーダを使用せず、サーバのメイン CPU を使用します。Cisco CallManager がハードウェア トランスコーダを音声ポート コールに割り当てるようにするには、レジストリ設定によって、Cisco Unity サーバ上でネイティブ トランスコーディングを無効（オフ）にする必要があります。このレジストリ設定は「Audio - Enable G.729a codec support」と呼ばれます。これを設定するためのツールは、 http://www.CiscoUnityTools.com で入手可能な Advanced Settings Tool です。デフォルトでは、コーデック レジストリ キーが存在しないため、ネイティブ トランスコーディングは有効（オン）です。Advanced Settings Tool により、使用可能な 2 つのコーデックのうちのどちらか 1 つを選択できる新しいレジストリ キーが追加されます。その後、Cisco Unity は、1 つのコーデックだけをサポートすることを Cisco CallManager に「アドバタイズ」します。音声ポートを終端または起点とするコールが、Cisco Unity サーバに設定されているタイプと異なるコーデックを使用している場合、Cisco CallManager はそのコールに外部トランスコーディング リソースを割り当てます。Cisco CallManager 上でトランスコーディング リソースを設定する方法の詳細については、「メディア リソース」を参照してください。

Advanced Settings Tool を使用して 1 つのコーデックだけを有効にする場合は、Cisco Unity サーバのシステム プロンプトが、使用されるコーデックと同じである必要があります。デフォルトでは、システム プロンプトは G.711 です。コーデックが G.711 に設定されている場合、システム プロンプトは正常に機能します。ただし、G.729 が選択されている場合は、システム プロンプトを変更する必要があります。システム プロンプトを変更する方法の詳細については、 http://www.cisco.com で入手可能な『 Cisco Unity Administration Guide 』を参照してください。システム プロンプトが、レジストリで選択されているコーデックと同じでない場合は、エンド ユーザに、理解不能なシステム プロンプトが聞こえます。

Cisco CallManager クラスタとの音声ポート統合

単一サイト メッセージング環境に Cisco Unity を配置する場合、Cisco CallManager クラスタとの統合は SCCP 音声ポートを介して行われます。Cisco CallManager サブスクライバに障害が発生した場合でも（Cisco CallManager フェールオーバー）、ユーザおよび外部コールが引き続き音声メッセージングにアクセスできるように、設計上の考慮事項には、Cisco CallManager サブスクライバ間の音声ポートの適切な配置が含まれる必要があります（図13-4 を参照してください）。

図13-4 Cisco CallManager クラスタと統合された Cisco Unity サーバ（専用バックアップ サーバなし）

図13-4 の Cisco CallManager クラスタは、1 対 1 のサーバ冗長性および 50/50 のロード バランシングを採用しています。正常な動作時には、各サブスクライバ サーバがアクティブで、サーバの全コール処理負荷の 50% を処理します。1 台のサブスクライバ サーバに障害が発生すると、残りのサブスクライバ サーバが、障害の発生したサーバの負荷を担います。

図13-5 と図13-6 では、Cisco Unity Telephone Integration Manager（UTIM）でのボイスメール ポート設定を示しています。この設定では、ボイスメール ポートのグループが 2 つ使用され、各グループに、ライセンスのある音声ポートの合計数の半分が含まれています。1 つのグループは、プライマリ サーバが SUB1 で、セカンダリ（バックアップ）サーバが SUB2 になるように設定されています（図13-5 を参照してください）。もう 1 つのグループは、SUB2 がプライマリ サーバで、SUB1 がバックアップになるように設定されています（図13-6 を参照してください）。

MWI 専用ポートや他の特殊なポートが、2 つのグループ間で等しく分散されていることを確認してください。音声ポートの設定中は、命名規則に特に注意してください。Cisco UTIM ユーティリティでポートの 2 つのグループを設定する場合は、必ずデバイス名プレフィックスがグループごとに固有となるようにし、Cisco CallManager Administration でボイスメール ポートを設定するときと同じデバイス名を使用します。図13-5 および図13-6 で示しているように、この例で、デバイス名プレフィックスがポートのグループごとに固有になっています。グループ SUB1 ではデバイス名プレフィックスとして CiscoUM1 が使用され、SUB2 では CiscoUM2 が使用されています。

着信ボイスメール ポートと発信ボイスメール ポート（MWI、メッセージ通知、および TRaP 用）の比率に関する設計上の詳細情報については、 http://www.cisco.com で入手可能な『 Cisco Unity Design Guide 』を参照してください。

図13-5 サブスクライバ 1 の音声ポートに関する Cisco Unity の設定

図13-6 サブスクライバ 2 の音声ポートに関する Cisco Unity の設定

（注） デバイス名プレフィックスは、ポートのグループごとに固有で、Cisco CallManager Administration に設定されているボイスメール ポートの命名規則と一致する必要があります。

Cisco CallManager Administration では、この例のポートの半分が固有なデバイス名プレフィックス CiscoUM1 を使用して登録されるよう設定され、残りの半分が CiscoUM2 を使用して登録されるよう設定されています（図13-7 を参照してください）。ポートが Cisco CallManager に登録される場合、半分がサブスクライバ Sub1（図13-4 を参照）に登録され、残りの半分が Sub2 に登録されます。

図13-7 Cisco CallManager Release 3.3 以前の Cisco CallManager Administration でのボイスメール ポート設定

（注） Cisco CallManager Administration でボイスメール ポートに使用される命名規則は、Cisco UTIM で使用されるデバイス名プレフィックスと一致する必要があります。一致しないと、ポートの登録に失敗します。

Cisco CallManager の正常な動作時、ボイスメール ポートはビジーである場合も、応答しない場合もあります（たとえば、ボイスメールのメンテナンス中）。Cisco CallManager Release 3.3 以前では、話中転送や無応答時転送などの場合のポートの動作を設定する必要があります。通常は、各ポートが順番に次のポートに転送されます（ 表13-1 を参照してください）。この一般的な規則の例外は、MWI 専用ポートの直前のポートです。このポートは次のポート（MWI 専用ポート）を飛ばして、その後のポートに転送されます。たとえば、 表13-1 では、CiscoUM1-VI4（DN 1003）が CiscoUM2-VI1（DN 1005）に転送されることを示しています。MWI 専用ポートでない最後のポートは、最初のポートに戻って転送されるため、循環が完成します。最適なパフォーマンスを得るため、MWI 専用ポートの数を音声ポートの合計数の 25% 以下に制限し、他のすべてのポート上で MWI 機能を無効にしてください。

Cisco CallManager Release 4.0 では、ボイスメール ポートの設定方法と動作方法を大きく変える新機能が導入されました。Release 4.0 以降では、回線グループ、ハント リスト、およびハント パイロットを使用して、ボイスメール ポートがアベイラビリティ、使用状況、および状態に基づいて相互に転送を行う方法を指定します。ボイスメール ポートのハント方法を設定する場合は、Current Line Group Members リストから MWI ポートをすべて削除します（図13-8 を参照してください）。これにより、これらのポートがコール応答用のハント グループから外れて、MWI アクティビティのために確保されることが保証されます。さらに、Cisco UTIM ユーティリティを使用して MWI ポートがコールに応答しないように設定する必要があるため、回線グループからこれらのポートを削除すると、ボイスメールにアクセスするユーザが ring-no-answer 状態を受信しないことが保証されます。回線グループ、ハント リスト、およびハント パイロットの詳細については、 http://www.cisco.com で入手可能な Release 4.0 以降の『 Cisco CallManager Administration Guide 』を参照してください。

図13-8 Cisco CallManager Release 4.0 以降の Cisco CallManager Administration での回線グループ設定

専用 Cisco CallManager バックアップ サーバを使用する音声ポート統合

この Cisco CallManager クラスタ構成では、各サブスクライバ サーバが 50% を超えるコール処理負荷で動作できます。各プライマリ サブスクライバ サーバは、専用バックアップ サーバまたは共有バックアップ サーバを持ちます（図13-9 を参照してください）。正常な動作時、バックアップ サーバはコールを処理しません。サブスクライバ サーバの障害時またはメンテナンス時に、バックアップ サーバはそのサブスクライバ サーバのすべての負荷を担います。

図13-9 単一の Cisco CallManager クラスタと統合された Cisco Unity サーバ（バックアップ サブスクライバ サーバを使用）

この場合のボイスメール ポートの設定は、50/50 のロードバランシング クラスタに似ています。ただし、もう 1 台のサブスクライバ サーバをセカンダリ サーバとして使用するように音声ポートを設定せず、個別の共有バックアップ サーバまたは専用バックアップ サーバを使用します。共有バックアップ サーバと共にクラスタ化された Cisco CallManager では、両方のサブスクライバ サーバのセカンダリ ポートが、単一のバックアップ サーバを使用するように設定されます。

音声ポート名（デバイス名プレフィックス）は、Cisco UTIM グループごとに固有で、Cisco CallManager サーバ上で使用されるデバイス名と同じである必要があります。

この例の設定では、Cisco UTIM ユーティリティでボイスメール ポートの 2 つのグループを設定します。Secondary Servers ボックスには、バックアップ サーバの IP アドレスまたは DNS 名を指定します（図13-10 を参照してください）。クラスタが共有バックアップ サーバを持つ場合は、両方のグループで同じサーバが使用されます。音声ポートを設定する場合は、両方のポート グループに、同じ数の MWI 専用ポートとフル機能の音声ポートが存在するようにしてください。また、Audio Messaging Interchange Specification（AMIS）および TRaP の音声ポートを 2 つのグループに等しく分散させることも必要です。 表13-1 に示しているように、話中転送および無応答時転送用のポートを設定します。

図13-10 バックアップ サーバ（Bkup1）をセカンダリとするサブスクライバ サーバ（Sub1）の音声ポートに関する Cisco UTIM 設定画面

サービスの復元後に音声ポートがサブスクライバ サーバに再接続されるようにするには、「Reconnect to the primary Cisco CallManager server after failover is corrected.」というラベルのボックスをオンにします。

集中型メッセージングと集中型コール処理

集中型メッセージングでは、Cisco Unity サーバが Cisco CallManager クラスタと同じ場所に置かれますが、メッセージング クライアントはメッセージング システムに対してローカルとリモートの両方にあります（図13-11 を参照してください）。リモート ユーザが中央のサイトのリソース（Tail-End Hop-Off（TEHO; テールエンド ホップオフ）の場合と同様に、音声ポート、IP Phone、公衆網ゲートウェイなど）にアクセスする場合、そのコールはゲートキーパー コール アドミッション制御にとって透過的になります。したがって、Cisco CallManager でリージョンとロケーションを設定して、コール アドミッション制御を提供する必要があります。（「帯域幅の管理」を参照してください）。IP Phone または MGCP ゲートウェイにリージョン間コールを発信する場合、IP Phone は設定済みのリージョン間コーデックを自動的に選択します。ネイティブ トランスコーディングが無効である場合、Cisco Unity 音声ポートは、WAN を通過する（リージョン間）コールのために Cisco CallManager トランスコーディング リソースを要求します。

図13-11 集中型メッセージングと集中型コール処理

図13-11 では、リージョン 1 と 2 が、リージョン内コールに G.711 を使用し、リージョン間コールに G.729 を使用するように設定されています。Cisco Unity サーバ上でネイティブ トランスコーディングは無効になっています。

図13-11 で示しているように、内線番号 200 からリージョン 1 のボイスメール ポートにコールが発信されると、エンドポイントではリージョン間の G.729 コーデックが使用されますが、RTP ストリームがトランスコードされ、音声ポート上では G.711 が使用されます。この例では、Cisco Unity サーバ上のネイティブ トランスコーディングが無効になっています。Cisco CallManager トランスコーディング リソースは、ボイスメール システムと同じサイトに置く必要があります。

ヘアピン

考慮する必要のあるもう 1 つの問題は、複数の Cisco Unity 音声ポートを介する音声コールのヘアピン（トロンボーニング）です。ヘアピンは、SCCP TSP 音声ポートだけを使用する環境では問題ではありませんが、二重統合環境では問題になります。二重統合環境では、従来型のシステムの音声ポートと SCCP TSP 音声ポートの間でヘアピンが発生する可能性があります。

二重統合の詳細については、次の Web サイトで入手可能な『 Cisco Unity Administration Guide 』を参照してください。

http://www.cisco.com

分散型メッセージングと集中型コール処理

分散型メッセージングは、テレフォニー環境内に複数のメッセージング システムが分散されており、各メッセージング システムがローカル メッセージング クライアントだけにサービスを提供することを意味します。このモデルは集中型メッセージングとは異なります。集中型メッセージングでは、メッセージング システムに対してローカルなクライアントとリモートのクライアントの両方が存在します。図13-12 では、集中型コール処理を使用する分散型メッセージング モデルを示しています。他のマルチサイト コール処理モデルと同様に、WAN 帯域幅を管理するためにリージョンとロケーションを使用する必要があります。このモデルでは、Cisco Unity ネイティブ トランスコーディングを無効にすることも必要です。

図13-12 分散型メッセージングと集中型コール処理

図13-12 の構成では、トランスコーダ リソースが各 Cisco Unity メッセージ システム サイトに対してローカルである必要があります。リージョン 1 と 2 は、リージョン内コールに G.711 を使用し、リージョン間コールに G.729 を使用するように設定されています。Cisco Unity サーバ上でネイティブ トランスコーディングは無効になっています。

Cisco CallManager サーバに設定されているコーリング サーチ スペースとデバイス プールによって、両方の Cisco Unity サーバの音声メッセージング ポートに、適切なリージョンとロケーションが割り当てられる必要があります。さらに、テレフォニー ユーザをボイスメール ポートの特定のグループに関連付けるために、Cisco CallManager ボイスメール プロファイルを設定する必要があります。コーリング サーチ スペース、デバイス プール、およびボイスメール プロファイルを設定する方法の詳細については、次の Web サイトで入手可能な、該当するバージョンの『 Cisco CallManager Administration Guide 』を参照してください。

http://www.cisco.com

メッセージング システムは相互に「ネットワーク接続」され、内部ユーザと外部ユーザの両方に単一のメッセージング システムを提供します。分散 Unity サーバ向けの Cisco Unity ネットワーク機能については、次の Web サイトで入手可能な『 Networking in Cisco Unity Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html

結合されたメッセージング配置モデル

複数のメッセージング モデルを同じ配置で組み合わせることができます。ただし、その配置は、上記の項で示したすべてのガイドラインに従う必要があります。図13-13 では、集中型メッセージングと分散型メッセージングの両方が同時に採用されるユーザ環境を示しています。

図13-13 結合された配置モデル

図13-13 では、2 つのメッセージング モデルの結合を示しています。リージョン 1 と 3 は集中型メッセージングと集中型コール処理を使用し、リージョン 2 は分散型メッセージングと集中型コール処理を使用しています。すべてのリージョンが、リージョン内コールに G.711 を使用し、リージョン間コールに G.729 を使用するように設定されています。

図13-13 では、中央サイトとサイト 3 の間で、集中型メッセージングと集中型コール制御が使用されています。中央サイトのメッセージング システムは、中央サイトとサイト 3 の両方のクライアントにメッセージング サービスを提供します。サイト 2 は、集中型コール処理を使用する分散型メッセージング モデルを使用しています。サイト 2 に置かれているメッセージング システム（Unity2）は、サイト 2 の中にいるユーザだけにメッセージング サービスを提供します。この配置では、両方のモデルが、この章に記載されているそれぞれの設計上のガイドラインに従っています。トランスコーディング リソースは各メッセージング システム サイトに対してローカルに置かれ、サイト 2 のユーザが中央サイトのユーザにメッセージを残す場合のように、（メッセージング システムに対して）リモートのサイトからメッセージング サービスにアクセスするクライアントをサポートします。

集中型メッセージングと WAN を介したクラスタ化

ここでは、集中型メッセージングと、ローカル フェールオーバー機能を持つ WAN を介した Cisco CallManager クラスタ化を一緒に配置する場合の Cisco Unity の設計上の問題について説明します。このモデルで WAN に障害が発生した場合は、WAN が復元されるまで、すべてのリモート メッセージング サイトがボイスメール機能を失います（図13-14 を参照してください）。

WAN を介したクラスタ化は、ローカル フェールオーバーをサポートしています。ローカル フェールオーバーでは、各サイトが、物理的にそのサイトに置かれているバックアップ サブスクライバ サーバを持ちます。ここでは、Cisco Unity 集中型メッセージングと、WAN を介したクラスタ化のローカル フェールオーバーを一緒に配置する方法を中心に説明します。

詳細については、「IP WAN を介したクラスタ化」の項を参照してください。

図13-14 Cisco Unity 集中型メッセージングと、ローカル フェールオーバー機能を持つ WAN を介したクラスタ化

クラスタ サイト間で必要な最小帯域幅は T1 回線（1,544 MHz）です。この量の帯域幅で、最大 10,000 の Busy Hour Call Attempts（BHCA: 混雑時発呼）に対してシグナリング トラフィックおよびデータベース トラフィックをサポートできます。ただし、これには、必要なメディア帯域幅が含まれていません。

Cisco CallManager Release 3.3(3) 以前を使用する WAN を介したクラスタ化では、クラスタごとに最大 4 つのサイトをサポートしますが、Cisco CallManager Release 4.1 以上では最大 8 つのサイトをサポートします。Cisco Unity は、どちらの場合でもその最大数までサイトをサポートします。ボイスメール ポートは、Cisco Unity メッセージング システムが置かれているサイトだけに設定されます（図13-14 を参照してください）。ボイスメール ポートは、WAN を介してリモート サイトに登録されません。他のサイトのメッセージング クライアントは、プライマリ サイトのすべてのボイスメール リソースにアクセスします。WAN に障害が発生すると、リモート サイトは集中型メッセージング システムにアクセスできなくなるため、WAN を介してリモート サイトに音声ポートを設定してもメリットがありません。帯域幅を考慮して、ボイスメール ポートで TRaP を無効にし、すべてのメッセージング クライアントがそのローカル PC（ユニファイド メッセージング専用）にボイスメール メッセージをダウンロードするようにする必要があります。

分散型メッセージングと WAN を介したクラスタ化

Cisco Unity メッセージング サーバも配置されたローカル フェールオーバー サイトでは、集中型メッセージング モデルと同様に、音声ポートがローカル Cisco CallManager サブスクライバ サーバに登録されます。音声ポートの設定については、「Cisco CallManager クラスタとの音声ポート統合」および 「専用 Cisco CallManager バックアップ サーバを使用する音声ポート統合」を参照してください。

図13-15 Cisco Unity 分散型メッセージングと、ローカル フェールオーバー機能を持つ WAN を介したクラスタ化

WAN を介したクラスタ化を含む単純分散型メッセージング実装では、クラスタ内の各サイトに、独自の Cisco Unity メッセージング サーバとメッセージング インフラストラクチャ コンポーネントが置かれます。すべてのサイトにローカル Cisco Unity メッセージング システムが置かれるわけではなく、一部のサイトで、ローカル メッセージング クライアントがリモート メッセージング サーバを使用する場合、その配置は分散型メッセージングと集中型メッセージングの結合モデルとなります（「結合されたメッセージング配置モデル」を参照してください）。このモデルで WAN に障害が発生した場合は、WAN が復元されるまで、集中型メッセージングを使用するすべてのリモート サイトがボイスメール機能を失います。

ローカル メッセージング サーバを持たない各サイトは、そのすべてのメッセージング クライアントに対して単一のメッセージング サーバを使用する必要がありますが、そのようなサイトのすべてが同じメッセージング サーバを使用する必要はありません。たとえば、サイト 1 とサイト 2 のそれぞれがローカル メッセージング サーバを持っているとします。その場合、サイト 3 のすべてのクライアントがサイト 2 のメッセージング サーバを使用し（そのメッセージング サーバに登録し）、サイト 4 のすべてのクライアントがサイト 1 のメッセージング サーバを使用するようにすることができます。ローカル Cisco Unity メッセージング サーバを持つサイトには、トランスコーダ リソースが必要です。

他の分散型コール処理配置と同様に、これらのサイト間のコールはゲートキーパー コール アドミッション制御にとって透過的です。したがって、Cisco CallManager でリージョンとロケーションを設定してコール アドミッション制御を提供する必要があります（「帯域幅の管理」を参照してください）。

分散 Cisco Unity サーバは、デジタルでネットワーク接続することもできます。このトピックの詳細については、 http://www.cisco.com で入手可能な『 Cisco Unity Networking Guide 』を参照してください。配置される特定のメッセージング ストアに固有の Networking Guide が用意されています。

Cisco Unity メッセージング フェールオーバー

Cisco Unity フェールオーバーにより、Cisco Unity サーバに障害が発生した場合のボイスメール存続可能性が確保されます（図13-1 を参照してください）。Cisco Unity ローカル フェールオーバーでは、プライマリとセカンダリの両方の Unity メッセージング サーバが同じ物理ロケーションに存在し、メッセージング インフラストラクチャ コンポーネントがプライマリ サーバと同じ場所に置かれます。メッセージング インフラストラクチャ コンポーネント（メッセージング ストア サーバ、Domain Controller/Global Catalog（DC/GC; ドメイン コントローラ/グローバル カタログ）サーバ、DNS サーバなど）は、オプションで、冗長コンポーネントを持つこともできます。これらは、Cisco Unity セカンダリ サーバと物理的に同じ場所に置くことができます。

Cisco Unity フェールオーバーは、すべてのメッセージング配置モデルでサポートされています。

Cisco Unity フェールオーバーの設定については、次の Web サイトで入手可能な『 Cisco Unity Failover Configuration and Administration Guide 』を参照してください。

http://www.cisco.com

Cisco Unity フェールオーバーと WAN を介したクラスタ化

Cisco Unity ローカル フェールオーバーと WAN を介したクラスタ化を配置する場合は、「集中型メッセージングと WAN を介したクラスタ化」および 「分散型メッセージングと WAN を介したクラスタ化」で説明している設計プラクティスを適用します。正常な動作時、プライマリ Cisco Unity サーバからの音声ポートは WAN を通過しません。

図13-16 では、Cisco Unity ローカル フェールオーバーを示しています。プライマリ Cisco Unity サーバとセカンダリ Cisco Unity サーバの両方が物理的に同じサイトに置かれていることに注意してください。Cisco Unity フェールオーバーは、Cisco CallManager の WAN を介したクラスタ化で使用可能な最大数までリモート サイトをサポートします。

図13-16 Cisco Unity ローカル フェールオーバーと WAN を介したクラスタ化

Cisco Unity フェールオーバーの設定については、次の Web サイトで入手可能な『 Cisco Unity Failover Configuration and Administration Guide 』を参照してください。

http://www.cisco.com

集中型メッセージングと複数の Cisco CallManager サーバ

このモデルでは、Cisco Unity メッセージング サーバと同じ場所にある Cisco CallManager クラスタ（図13-17 ではクラスタ 1）にフル機能の音声ポートと MWI ポートを設定し、リモート Cisco CallManager クラスタ（図13-17 ではクラスタ 2）に MWI 専用ポートを割り当てます。ボイスメール コールがクラスタ 1 とクラスタ 2 の間の WAN を通過する場合は、必ずトランスコーディング リソースが必要になります。このリソースは、Cisco Unity メッセージング サーバと同じ場所に置く必要があります。Cisco CallManager のトランスコーディング リソースを使用するために、Cisco Unity サーバのネイティブ トランスコーディングを無効にする必要があります。

図13-17 では、Cisco CallManager クラスタ 2 に MWI 専用のボイスメール ポートが設定されています。テレフォニー加入者が Cisco CallManager クラスタ 1 のボイスメール ポートにアクセスするようにするには、パイロット番号を DN 以外にして、その番号がルート パターンによってルーティングされるようにする必要があります。2 つのクラスタ間でクラスタ間トランクが設定されると、そのクラスタ間トランクを介してボイスメール パイロットをルーティングできます。ルート パターンが使用されるため、ゲートキーパーのコール アドミッション制御を使用でき、WAN 帯域幅を適切に管理できます。

図13-17 には、次の設定情報が適用されます。

図13-17 複数のクラスタにサービスを提供する単一の Cisco Unity サーバ

クラスタ 1 とクラスタ 2 の両方のサイトのメッセージング クライアントが、物理的にクラスタ 1 に置かれている Cisco Unity メッセージング インフラストラクチャを使用します。

単一の Cisco Unity を複数の Cisco CallManager クラスタと統合する方法の詳細については、次の Web サイトで入手可能な White Paper『 Cisco Unity Integration with Multiple Clusters of Cisco CallManager 3.1 and Later 』を参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/whitpapr/clust_31.htm