Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) Cisco Unified CallManager Release 5.0

Cisco Unity

---

この章では、Cisco Unity および Cisco Unity Connection と Cisco Unified 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 Connection は外部メッセージ ストアに依存しません。

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

http://www.cisco.com

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

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

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

• 「ポート グループ（分離統合）」

• 「帯域幅の管理」

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

• 「ボイスメール統合のための Cisco Unified CallManager SIP トランクの設定」

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

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

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

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

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

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

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

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

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

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

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

http://www.cisco.com

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

Cisco Unified CallManager 5.0 には、SIP トランクの新機能も追加されています。SIP トランクで Cisco Unity および Unity Connection との統合が直接サポートされ、SIP プロキシ サーバの必要性がなくなりました。

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

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

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

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

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

Cisco Unity Connection は単一サイト メッセージング、および単一メッセージング サーバによる集中型メッセージングをサポートしています。

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

3 つのメッセージング配置モデルに加えて、Cisco Unity はメッセージング フェールオーバーもサポートしています（「メッセージング フェールオーバー」を参照）。Cisco Unity Connection は現在、フェールオーバーをサポートしていません。Cisco Unity Connection はサーバ間のネットワーキングのない単一サーバだけを使用するため、単一サイト モデルと集中型メッセージング モデルだけをサポートしています。

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

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

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

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

 

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

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

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

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

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

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

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

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

Cisco Unity は、Dynamic Domain Name Server（DDNS）、ディレクトリ サーバ、メッセージ ストアなど、さまざまなネットワーク リソースと対話します（図13-2 を参照）。Cisco Unity はメッセージ ストアとして、Microsoft Exchange と IBM Lotus Notes の両方をサポートしています。これらのメッセージ ストア タイプはそれぞれ異なるインフラストラクチャ コンポーネントを持っています（ http://www.cisco.com で入手可能な『 Cisco Unity Design Guide 』で該当する配置タイプを参照してください）。

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 メッセージング システム インフラストラクチャ コンポーネント（Exchange 固有）

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

Cisco Unity Connection を配置するときは、Automatic Speech Recognition（ASR; 自動音声認識）サービスを別のサーバに置くことも可能です。この配置環境では、Cisco Unity Connection サーバと ASR サーバが同じロケーションに存在する必要があります。Cisco Unity Connection のインフラストラクチャ要件または依存関係は、Cisco Unity とは異なります。

ポート グループ（分離統合）

Unity Connection では、Cisco Unity 4.2 で 分離統合 とも呼ばれている、 ポート グループ という概念が導入されています。Unity の初期のリリースでは、Cisco Unity Telephony Integration Manager（UTIM）で同じタイプの統合の 複数クラスタ を設定できました。ポート グループと分離統合が、単一統合における複数のクラスタとどのように異なるかを理解することが重要です。単一統合で複数のクラスタという手法では、Unity データベースがユーザをクラスタではなく、統合と関連付けます。単一統合しかないため、すべてのサブスクライバはどのクラスタ上に存在するかに関係なく、その単一統合と関連付けられていました。Message Waiting Indication（MWI; メッセージ待機インジケータ）に対して、Unity は MWI アップデートを、サブスクライバが存在しないクラスタも含めて、単一統合におけるすべてのポートからブロードキャストする必要がありました。Unity（4.2）の分離統合、および Unity Connection のポート グループが新たに追加されたことで、サブスクライバは所属する特定の統合に関連付けられます。MWI 信号をすべてのポートからブロードキャストする必要がなくなり、特定のサブスクライバに関連付けられた特定のポートだけに送信されるようになりました。

従来型の電話システムと Cisco Unified CallManager 電話システムを統合したり、Cisco Unified CallManager SIP システムと Cisco Unified CallManager SCCP システムを統合したりするなど、複数のタイプのシステムを Unity または Unity Connection サーバに統合すると、二重統合が発生します。SCCP で 2 つ以上の Cisco Unified CallManager クラスタに統合する場合など、同じタイプの統合によって 4.1 以前のバージョンの Cisco Unity を複数の Cisco Unified CallManager クラスタに統合すると、複数統合が発生します。

Unity 4.2 では、分離統合は UTIM で設定されるのに対して、Unity Connection ポート グループはシステム管理者が設定します。

帯域幅の管理

Cisco Unified CallManager は、帯域幅を管理するためのさまざまな機能を備えています。リージョン、ロケーション、およびゲートキーパーさえも使用して、Cisco Unified CallManager は、WAN リンクを介して伝送される音声コールの数によって既存の帯域幅がオーバーサブスクリプションの状態になることがなく、音声品質が低下しないことを保証できます。Cisco Unity および Unity Connection は、帯域幅の管理とコールのルーティングを Cisco Unified CallManager に依存しています。コール（音声ポート）が WAN リンクを通過することのある環境に Cisco Unity または Unity Connection を配置する場合、このようなコールはゲートキーパーベースのコール アドミッション制御にとって透過的になります。このような状況は、Cisco Unity または Unity Connection サーバが分散クライアントにサービスを提供している場合（分散型メッセージング（Unity のみ）または分散型コール処理）、または Cisco Unified CallManager がリモートに置かれている場合（分散型メッセージング（Unity のみ）または集中型コール処理）、いつでも発生します。Cisco Unified 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 Unified CallManager の機能である Automated Alternate Routing（AAR; 自動代替ルーティング）では、WAN がオーバーサブスクリプションの状態になった場合に、公衆網を介してコールをルーティングできます。ただし、公衆網を介してコールが再ルーティングされる場合、Redirected Dialed Number Information Service（RDNIS）が損なわれることがあります。Cisco Unity または Unity Connection がメッセージング クライアントに対してリモートである場合は、正しくない RDNIS 情報によって、AAR が外線を介して再ルーティングするボイスメール コールに影響が及ぼされることがあります。RDNIS 情報が正しくない場合、コールはダイヤル先のユーザのボイスメール ボックスに到達せず、自動アテンダント プロンプトを受信します。発信者は、到達を試みているユーザの内線番号を再入力するように要求されることがあります。この動作は、主に、電話通信事業者がネットワークを介した RDNIS を保証できない場合の問題です。通信事業者が RDNIS の正常な送信を保証できない理由は数多くあります。通信事業者に問い合せて、回線のエンドツーエンドで RDNIS の送信を保証しているかどうかを確認してください。オーバーサブスクリプションの状態になった WAN に対して AAR を使用する代わりの方法は、単に、オーバーサブスクリプションの状況で発信者にリオーダー トーンが聞こえるようにすることです。

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

デフォルトでは、Cisco Unity または Unity Connection サーバは自動的にトランスコーディングを実行します。現在、Cisco Unified CallManager および Cisco Unity は、Skinny Client Control Protocol（SCCP）TAPI Service Provider（TSP）音声ポートに対して G.729 と G.711 だけをサポートしています。他のコーデックは、Intel または Dialogic の音声ボードを使用する従来型の統合でサポートされています。Cisco Unity のネイティブ トランスコーディングは、外部ハードウェア トランスコーダを使用せず、サーバのメイン CPU を使用します。SCCP 統合の場合に限り、Cisco Unified CallManager がハードウェア トランスコーダを音声ポート コールに割り当てるようにするには、レジストリ設定によって、Cisco Unity サーバ上でネイティブ トランスコーディングを無効（オフ）にする必要があります。このレジストリ設定は「Audio - Enable G.729a codec support」と呼ばれます。これを設定するためのツールは、 http://www.CiscoUnityTools.com で入手可能な Advanced Settings Tool です（この項の最後で説明するように、Cisco Unity Connection のネイティブ トランスコーディングを無効にするには、メッセージング コーデックの設定を別に行います）。

デフォルトでは、コーデック レジストリ キーが存在しないため、ネイティブ トランスコーディングは有効（オン）です。Advanced Settings Tool により、使用可能な 2 つのコーデックのうちのどちらか 1 つを選択できる新しいレジストリ キーが追加されます。その後、Cisco Unity は、1 つのコーデックだけをサポートすることを Cisco Unified CallManager に「アドバタイズ」します。音声ポートを終端または起点とするコールが、Cisco Unity サーバに設定されているタイプと異なるコーデックを使用している場合、Cisco Unified CallManager はそのコールに外部トランスコーディング リソースを割り当てます。Cisco Unified CallManager 上でトランスコーディング リソースを設定する方法の詳細については、「メディア リソース」の章を参照してください。

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

SIP で統合するときに Unity のネイティブ トランスコーディングを無効にする方法の詳細については、 http://www.cisco.com で入手可能な Unity 製品のマニュアルを参照してください。

Cisco Unity Connection がサポートするコーデックをアドバタイズする方法を変更するには、Cisco Unity とは異なる設定を行います。Cisco Unity Tools Depot は使用せず、設定変更は Cisco Unity Connection Administration ページで行います。Telephony Integrations の Port Groups リンクを選択します。Port Groups ページで、アドバタイズの設定を G.711 のみ、G.729 のみ、またはその両方に変更しますが、G.711 または G.729 のどちらかに設定するようにしてください。このように設定にすると、Cisco Unity Connection は両方のプロトコル（ネイティブ トランスコーディング）をサポートするものの、指定された一方のみの使用が適していることをアドバタイズします。ネイティブ トランスコーディングが無効の状態では、トランスコーダ リソースが必要な場合に、Unity または Unity Connection サーバの CPU を使用する代わりに、Cisco Unified CallManager がリソースを提供します。

ボイスメール統合のための Cisco Unified CallManager SIP トランクの設定

Cisco Unified CallManager 5.0 では、回線側デバイスの SIP をサポートする新機能が導入され、トランク側の SIP も拡張されました。このような機能により、Cisco Unified CallManager は SIP で直接 Cisco Unity および Unity Connection と統合できるようになり、SIP プロキシ サーバが必要なくなりました。

ただし、Cisco Unified CallManager は SIP トランクを介したボイスメールの直接統合が可能ですが、Skinny Client Control Protocol（SCCP）ポートと同じ Voicemail Port Wizard を持っていません。ある程度の手動設定が必要です。基本的な統合シナリオでは、SIP トランクの設定に次の手順が必要です。

ステップ 1 Cisco Unified CallManager Administration で SIP Profile を作成します。それには、 Device > Device Setting > SIP Profile の順に選択します。

このとき、ボイスメール統合に固有のものは特にありませんが、管理機能を簡単にし、一貫したものにするため、実際のボイスメール統合に固有の SIP プロファイルを作成し、それに応じた名前を付けるようにしてください。

ステップ 2 CallManager Administration で SIP Trunk Security Profile を作成します。それには、 System > Security Profile > SIP Trunk Security Profile の順に選択します。

SIP Trunk Security Profile の Incoming Port # はボイスメールに固有のもので、Cisco Unity または Unity Connection サーバが Cisco Unified CallManager クラスタへの接続に使用する SIP ポート番号の数値です。また、 Accept Unsolicited Notifications をオン（有効）にし、Cisco Unity および Unity Connection が Cisco Unified CallManager of Message Waiting Indicator（MWI）イベントを通知できるようにします。

（注） MWI 機能は Unsolicited Notifies で処理されます。SCCP 統合に必要な MWI DN を設定する必要はありません。

ステップ 3 CallManager Administration で SIP Trunk を作成します。それには、 Device > Trunk [Add New] の順に選択します。トランクの作成ページで、設定済みの SIP Profile と SIP Trunk Security Profile を対応するフィールドに指定します。また、Unity または Unity Connection サーバの宛先アドレスを設定し、 Unattended Port をオンに（有効に）します。 Redirecting Number IE Deliver - Outbound もオンに（有効に）します。

（注） Unattended Port の例外として、複数の Cisco Unity サーバを 1 つの Cisco Unified CallManager クラスタに接続し（たとえば、72 を超えるボイスメール ポートが配置されたため、2 つ以上の Cisco Unity サーバが必要な場合）、ライブ応答またはクロスサーバ ログオンが設定されている場合があります。このシナリオでは、Unattended Port をオフ（無効）のままにすると、あるサーバのボイスメール ポートからのコール転送が、他のサーバで終端されるようにできます。現在のところ、この例外は Unity だけに適用されます。

ステップ 4 ルート パターンを作成し、ボイスメール SIP トランクを宛先として指定します。

ステップ 5 ステップ 4 で設定したルートパターンと同じ番号のボイスメール パイロット番号を作成します。

ステップ 6 対応するボイスメール パイロット番号を使用して、ボイスメール プロファイルを作成します。

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

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

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

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

この設定では、ボイスメール ポートのグループが 2 つ使用され、各グループに、ライセンスのある音声ポートの合計数の半分が含まれています。1 つのグループは、プライマリ サーバが Sub1 で、セカンダリ（バックアップ）サーバが Sub2 になるように設定されています。もう 1 つのグループは、Sub2 がプライマリ サーバで、Sub1 がバックアップになるように設定されています。

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

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

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

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

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

Cisco Unified CallManager 4.0 では、SCCP ボイスメール ポートでのハントと転送の方法に関して多数の変更が行われました。ボイスメール ポートの動作と設定に影響のあるこれらの変更の詳細については、次の Web サイトで入手可能な Cisco Unified CallManager 4.0 のマニュアルを参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/4_0/index.htm

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

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

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

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

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

Cisco Unity でボイスメール ポートを設定するには UTIM ツールを使用します。Cisco Unity Connection では、Unity Connection Administration コンソールの Telephony Integration セクションを使用します。詳細については、 http://www.cisco.com で入手可能な Cisco Unity または Cisco Unity Connection のアドミニストレーション ガイドを参照してください。

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

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

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

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

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

ヘアピン

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

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

http://www.cisco.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

他の分散型コール処理配置と同様に、これらのサイト間のコールはゲートキーパー コール アドミッション制御にとって透過的です。したがって、Cisco Unified 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 Connection は現在、フェールオーバーをサポートしていません。

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

（注） Unity Connection は現在、フェールオーバーをサポートしていません。

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

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

http://www.cisco.com

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

Cisco Unity および Unity Connection はポート グループをサポートしているため、いずれかの Unity 製品サーバ上のサブスクライバをポート グループと関連付け、最終的に統合することができます。サブスクライバが特定のポート グループに関連付けられると、そのポート グループに属する MWI ポートだけで、ユーザの MWI 機能が実行されます。この機能は、SCCP と SIP の両方のボイスメール ポートで同じ動作になります。Cisco Unity は最大 7 つのポート グループをサポートしますが、Cisco Unity Connection は最大 9 つのポート グループをサポートしています。詳細については、 http://www.cisco.com で入手可能な該当する Cisco Unity または Cisco Unity Connection のアドミニストレーション ガイドを参照してください。

図13-12 Cisco Unity または Unity Connection と複数の Cisco Unified CallManager クラスタの統合

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