Cisco Unity Connection ネットワーク ガイド リリース 8.x

2 つの Cisco Unity Connection サイト間のリンクについて

2 つの Cisco Unity Connection サイトをサイト間リンクで接続した場合、ローカル サイト ディレクトリのあらゆる変更に関する情報を収集し、リモート サイト ゲートウェイを定期的にポーリングしてリモート サイト ディレクトリの更新に関する情報を取得することは、各サイトのゲートウェイが担当します。ゲートウェイは HTTP または HTTPS プロトコルを使用して、ディレクトリ同期の更新を交換します。

各サイトのゲートウェイはまた、リモート サイトの受信者に宛てられたメッセージの転送と、自身のサイトの受信者に宛てられたメッセージの受信も担当します。サイト間メッセージは、SMTP を介して送受信されます。

Connection クラスタをサイト ゲートウェイとして使用する場合は、クラスタ内のパブリッシャ サーバだけが、サイト間リンクを介したディレクトリ同期に参加します。ただし、パブリッシャ サーバがダウンした場合は、サブスクライバ サーバが引き続きサイト間リンクを介したメッセージ交換を行います。

図 1-2 は、2 つの Connection サイトを接続する場合の、サイト ゲートウェイとサイト間リンクの役割を図示したものです。

2 つの Connection サイトをリンクするには、それぞれのサイトの全サーバで Cisco Unity Connection リリース 8.0 以降が実行されていなければならないことに注意してください。

図 1-2 サイト間リンクで接続された 2 つの Cisco Unity Connection サイトから成る Cisco ボイスメール組織

Cisco Unity Connection サイトと Cisco Unity サイトのリンクについて

Cisco Unity サイトを Cisco Unity Connection サイトにリンクした場合、ローカル サイト ディレクトリのあらゆる変更に関する情報を収集し、リモート サイト ゲートウェイを定期的にポーリングしてリモート サイト ディレクトリの更新に関する情報を取得することは、各サイトのゲートウェイが担当します。ゲートウェイは HTTP または HTTPS プロトコルを使用して、ディレクトリ同期の更新を交換します。

メッセージの交換については、Interoperability Gateway for Microsoft Exchange が Cisco Unity サイトのメッセージング ゲートウェイとして機能します。Interoperability Gateway は、ハブ トランスポートの役割が設定された Microsoft Exchange 2010 または 2007 サーバか、あるいは Microsoft Exchange 2003 サーバにインストールできます。（Interoperability Gateway の最新のサポート バージョンおよび要件については、 http://www.cisco.com/en/US/docs/voice_ip_comm/unity/compatibility/matrix/cunetoptionsreqs.html で「 Cisco UnityNetworking Options Requirements 」を参照してください）。

Cisco Unity ユーザが作成したメッセージで、外部の受信者を含むものは、メール システムにより、Interoperability Gateway が定期的にチェックするフォルダに転送されます。Interoperability Gateway は処理すべきメッセージをフォルダから選択し、送信者と受信者の情報を確認した上で必要な形式に変換し、必要に応じてメッセージのプロパティを追加または削除し、宛先ロケーションの必要に応じてオーディオを変換および暗号化/復号化し、メッセージ部分とフォーマットの変換を行ってから、メッセージを配信のためメッセージ システムに戻します。こうしたタスクを実行するため、Interoperability Gateway は Cisco Unity のディレクトリ情報にアクセスする必要があります。この情報を取得するため、Cisco Unity サイト内の Cisco Unity 8.x サーバにある Cisco Unity の Web サービスのリソースに接続が行われます（Interoperability Gateway はプライマリとセカンダリの Web サービス サーバを両方使用するように設定できます。サイト ゲートウェイを Web サービス サーバとして使用することもできますが、サイト内のあらゆる 8.x サーバが使用可能です）。

図 1-3 は、Cisco Unity サイトと Cisco Unity Connection サイトを接続する場合の、Interoperability Gateway for Microsoft Exchange、サイト ゲートウェイ、およびサイト間リンクの高レベルにおける役割を図示したものです。Cisco Unity サイトは、単一の Cisco Unity サーバ、1 つのフェールオーバー ペア、または複数の Cisco Unity サーバ（あるいはフェールオーバー ペア）を含む 1 つのデジタル ネットワークで構成できます。同様に、Connection サイトも単一の Connection サーバ、1 つの Connection クラスタ、または複数のサーバ（あるいはクラスタ）で構成できます。

図 1-3 サイト間リンクで Cisco Unity Connection サイトに接続された 1 つの Cisco Unity サイトから成る Cisco ボイスメール組織

Cisco Unity サイトと Cisco Unity Connection サイトをリンクするには、Connection サイト内の全サーバで Connection 8.x が実行されていなければならないことに注意してください。Cisco Unity サイト ゲートウェイでは、Cisco Unity 8.x が実行されている必要があります。Cisco Unity サイト内の他の Cisco Unity サーバでは、Connection のネットワーク サポートを追加するための該当する特別技術オプションがインストールされている場合は、Cisco Unity 5.0 以降が実行されていれば構いません。追加の詳細情報および要件については、 http://www.cisco.com/en/US/docs/voice_ip_comm/unity/compatibility/matrix/cunetoptionsreqs.html で「 Cisco UnityNetworking Options Requirements 」を参照してください。

Connection クラスタを Connection サイト ゲートウェイとして使用する場合は、クラスタ内のパブリッシャ サーバだけが、Cisco Unity とのディレクトリ同期に参加します。ただし、パブリッシャ サーバがダウンした場合は、サブスクライバ サーバが引き続きサイト間リンクを介したメッセージ交換を行うことができます。同様に、Cisco Unity フェールオーバー ペアを Cisco Unity サイト ゲートウェイとして使用する場合は、プライマリ Cisco Unity サーバだけが Connection とのディレクトリ同期に参加しますが、メッセージ交換はセカンダリ Cisco Unity サーバがアクティブな際でも続行できます。

Cisco Unity Connection サイト内でのレプリケーション

Cisco Unity Connection サイト内では、 表 1-1 に示すオブジェクトとオブジェクト プロパティが、各ロケーションで独自のディレクトリから他のすべてのロケーションにレプリケートされます。

レプリケートされたオブジェクトはほとんどの場合、ローカル オブジェクトと同様に使用できます。たとえば、リモート ユーザをシステム コール ハンドラのメッセージ受信者として割り当てたり、リモート サーチ スペースを使用するようにユーザの検索範囲を設定したりできます。ただし、次の例外に注意してください。

• システム コール ハンドラの所有者はローカル ユーザでなければなりません。

• パーティションに属するオブジェクト（ユーザ、連絡先、ハンドラ、システム同報リスト、および VPIM ロケーション）は、ローカル パーティションにだけ属することができます。ただし、ローカル サーチ スペースにリモート パーティションを追加することは可能です。

Connection ロケーションをホームとするレプリケートされたオブジェクトを追加、変更、または削除すると、変更に関する詳細を含むオブジェクト変更要求が、このロケーションから他のすべてのロケーションに送信されます。特定のロケーションのオブジェクト変更要求は、Unique Sequence Number（USN; ユニークなシーケンス番号）と呼ばれる番号で指示され追跡されます。それぞれの変更について、ロケーションで USN が 1 ずつ増やされ、その変更がデータベースに記録されます。リモート ロケーションは、その送信者から前に受信した要求よりも 1 大きい USN 値を持つオブジェクト変更要求を受信すると、それに応じてその Connection ディレクトリのコピーを更新し、送信者用に追跡する USN のコピーを 1 大きくします。リモート ロケーションが 1 つまたは複数の変更を受信し損ねて、そのロケーションから前に受信した要求よりも 2 以上大きい USN を持つ変更要求を受信した場合は、受信し損ねた変更の USN 値を要求してその変更を取得することができます。

USN の他に、各ロケーションにはもう 1 つ、レプリケーション セットと呼ばれる番号が関連付けられています。レプリケーション セットの値は、USN が属する一連の変更の追跡に使用されます。レプリケーション セットの値は、アップグレード、復元、またはロールバックの処理中、自動的に変更されます。これにより、処理の結果発生したデータベースへのあらゆる変更が、確実にネットワークにレプリケートされます。たとえば、ロケーション A で、レプリケーション セットが 10 で USN が 5 のメッセージがロケーション B から受信され、次にロケーション B からレプリケーション セットが 9 で USN が 5 のメッセージが受信された場合、9 のほうが数値が低くそのメッセージの日付はレプリケーション セット 10 のメッセージよりも古いため、レプリケーション セット 9 のメッセージが無視されます。ロケーション A がロケーション B から、レプリケーション セットが 10 で USN が 5 の別のメッセージをもう一度受信した場合、それは重複メッセージであり無視可能であると判断されます。

ロケーションで一括処理が実行中の場合、そのロケーションでのレプリケーションは処理が終了するまで一時停止されます。

2 つの Cisco Unity Connection サイト間でのレプリケーション

表 1-2 に示すように、2 つの Cisco Unity Connection サイト間では単一の Connection サイト内の場合と同じオブジェクトおよびオブジェクト プロパティがレプリケートされますが、次のような例外があります。

• システム連絡先はサイト間でレプリケートされません。

• 各サイトについて、リモート サイトをホームとするすべてのシステム同報リストを同期するかどうかを選択できます。また個々のリストについても、そのリストをレプリケーション用にリモート サイトに提供するかどうかを選択できます。

• システム同報リストのメンバーシップは、サイト間でレプリケートされません。

• VPIM ロケーション（および連絡先）は、サイト間でレプリケートされません。

サイト内リンクの場合と同様、リモート サイトからレプリケートしたオブジェクトはローカル オブジェクトと同じように使用できますが、コール ハンドラの所有者はローカル ユーザでなければならず、パーティションに属するオブジェクトはローカル パーティションにのみ属することができます。

サイト間レプリケーションは、各サイト ゲートウェイで実行されているフィーダ サービスとリーダー サービスを使用して行います。リーダー サービスは、リモート サイト ゲートウェイを定期的にポーリングして、前回のポール間隔以降に行われたディレクトリ変更情報を収集します。フィーダ サービスは、変更トラッキング データベースを調べてディレクトリ変更が行われたかどうかを確認し、必要な情報を使用してポーリング要求に応答します。

各サイト ゲートウェイでは、リーダーがディレクトリ データを確認するためリモート フィーダをポーリングするスケジュール、および録音名を確認するためポーリングするスケジュールを設定できます。サイト ゲートウェイの Cisco Unity Connection Administrationで、ディレクトリとリモート ネットワークの同期タスクか、音声名をリモート ネットワークと同期タスクのいずれかを選択すると、[ツール（Tools）] > [タスク管理（Task Management）] ページのスケジュールにアクセスできます。または、[サイト間リンクの編集（Edit Intersite Link）] ページの [関連リンク（Related Links）] フィールドを使用すると、いずれかのタスクにアクセスできます。

音声名をリモート ネットワークと同期タスクを有効にすると、リーダーは、リモート ユーザの録音名ファイルとシステム同報リスト（該当する場合）を処理します。ローカル サイトのリモート オブジェクトに一度録音名を作成すると、その名前はリモートおよびローカルの録音名のファイル名が異なる場合だけ更新されます。たとえば、リモート サイト ゲートウェイで録音名の発信コーデックを変更しても、ローカル サイトのファイル名は変更されないため、ローカル サイトにある該当ファイルは更新されません。この場合、更新された録音名のコピーをプルするには、ローカル サイト ゲートウェイから既存の録音名をすべてクリアし、次に Connection の管理 の [サイト間リンクの検索（Search Intersite Links）] ページにある [録音名のクリア（Clear Recorded Names）] ボタンおよび [すべて再同期（Resync All）] ボタンを使用して、完全な再同期を実行する必要があります。

Cisco Unity サイトと Cisco Unity Connection サイト間でのレプリケーション

Cisco Unity サイトと Cisco Unity Connection サイトをリンクすると、各 Connection ユーザについて連絡先（Cisco Unity Administrator では Connection ネットワーク サブスクライバと呼ばれる）が、Cisco Unity ディレクトリおよび Active Directory に追加されます。同様に、各 Cisco Unity ユーザについて、ユーザ（Cisco Unity Connection Administrationでは Cisco Unity ユーザと呼ばれる）が Connection サイトのグローバル ディレクトリに追加されます。Connection のシステム連絡先と VPIM 連絡先は Cisco Unity にレプリケートされず、Cisco Unity ネットワーク連絡先（AMIS、Bridge、VPIM、Internet、または Trusted Internet のサブスクライバ）も Connection にはレプリケートされません。

システム同報リストは、ローカル サイトがリストをリモート サイトからプルするように設定されていて、リスト自体も他のサイトへのレプリケーションを許可するように設定されている場合、サイト間でレプリケートされることがあります。システム連絡先またはネットワーク連絡先を含むリストは、他のサイトへのレプリケーションを許可するように設定することはできません。レプリケートされるリストでは、宛先指定に使用されるリスト名などの情報だけがレプリケートされ、リスト メンバーシップはレプリケートされません。

表 1-3 は、Cisco Unity サイトと Cisco Unity Connection サイトの間でレプリケートされるオブジェクト、およびレプリケートされるオブジェクト プロパティの一覧を示したものです。

サイト間レプリケーションは、各サイト ゲートウェイで実行されているフィーダ サービスとリーダー サービスを使用して行います。リーダー サービスは、リモート サイト ゲートウェイを定期的にポーリングして、前回のポール間隔以降に行われたディレクトリ変更情報を収集します。フィーダ サービスは、変更トラッキング データベースを調べてディレクトリ変更が行われたかどうかを確認し、必要な情報を使用してポーリング要求に応答します。

Connection サイト ゲートウェイでは、リーダーがディレクトリ データを確認するためリモート フィーダをポーリングするスケジュール、および録音名を確認するためポーリングするスケジュールを設定できます。サイト ゲートウェイの Cisco Unity Connection Administration で、[ディレクトリをリモート ネットワークと同期（Synchronize Directory With Remote Network）] タスクか、[音声名をリモート ネットワークと同期（Synchronize Voice Names With Remote Network）] タスクのいずれかを選択すると、[ツール（Tools）] > [タスク管理（Task Management）] ページのスケジュールにアクセスできます。または、[サイト間リンクの編集（Edit Intersite Link）] ページの [関連リンク（Related Links）] フィールドを使用すると、いずれかのタスクにアクセスできます。

Cisco Unity サイト ゲートウェイでは、録音名の同期を有効または無効にし、リーダーが Cisco Unity Connection フィーダをポーリングしてディレクトリ データおよび録音名を収集する間隔を設定できます。ディレクトリ データと録音名のポーリング スケジュールを個別に設定できる Connection リーダーとは異なり、Cisco Unity リーダーは各サイクルで両方の情報をポーリングします（録音名の同期が有効になっている場合）。

音声名をリモート ネットワークと同期タスクを有効にすると、リーダーは、リモート ユーザの録音名ファイルとシステム同報リスト（該当する場合）を処理します。ローカル サイトのリモート オブジェクトに録音名が作成されている場合、その名前はリモートおよびローカルの録音名のファイル名が異なる場合だけ更新されます。たとえば、リモート サイト ゲートウェイで録音名の発信コーデックを変更しても、ローカル サイトのファイル名は変更されないため、ローカル サイトにある該当ファイルは更新されません。更新された録音名のコピーを Cisco Unity から Connection にプルするには、Connection の管理 の [ネットワーク（Networking）] > [リンク（Links）] > [サイト間リンクの検索（Search Intersite Links）] ページにある [録音名のクリア（Clear Recorded Names）] ボタンを使用して、Connection サイト ゲートウェイから既存の録音名をすべてクリアする必要があります。更新された録音名のコピーを Connection から Cisco Unity にプルするには、Cisco Unity Administrator の [ネットワーク（Networking）] > [Connection ネットワーク プロファイル（Networking Profile）] ページにある [ボイス名の消去（Clear Voice Names）] ボタンを使用します。

Cisco Unity Connection サイト内でシステム同報リストへのメッセージが処理される仕組み

システム同報リストは Cisco Unity Connection サイト内のロケーション間でレプリケートされるため、ユーザはリストが自分の検索範囲内にある限り、あらゆるロケーションにあるシステム同報リストをメッセージの宛先として指定できます。

システム同報リストをメッセージの宛先として指定すると、ローカルの Cisco Unity Connection ロケーションで同報リストのメンバーシップが解析されます。送信元ロケーションは、メッセージをリスト上のローカル ユーザに直接配信します。リストにリモートの Connection ユーザが含まれている場合、送信元ロケーションはこれらのリモート ユーザがホームとする各ロケーションにメッセージを配信します。リストに VPIM ユーザが含まれている場合、送信元サーバは、VPIM ロケーションがローカルをホームとしていればメッセージを VPIM の宛先に配信し、そうでなければロケーションがホームとしているサーバに渡して、そのサーバが宛先サーバへのメッセージの転送を処理します。

Connection には、[すべてのボイスメール ユーザ（All Voicemail Users）]、[配信できないメッセージ（Undeliverable Messages）]、および [ボイスメールが有効なすべての連絡先（All Voicemail-Enabled Contacts）] という事前定義のシステム同報リストがあります。組織内の各 Connection サーバは、これらの各リストの別個のバージョンを持ちます。これらのリストの名前を一意のものに変更していない場合は、初回のレプリケーション時に各サーバで自動的に、ローカルのリスト名と名前がオーバーラップするすべてのリモート リストの表示名にリモート サーバ名が追加されます。

デフォルトでは、各 Connection ロケーションの事前定義リストは同じ録音名を持っており、[すべてのボイスメール ユーザ（All Voicemail Users）] リストおよび [ボイスメールが有効なすべての連絡先（All Voicemail-Enabled Contacts）] リストは各ロケーションで同じ内線番号を持っています（[配信できないメッセージ（Undeliverable Messages）] リストは、通常メッセージの宛先とされないため、デフォルトで内線番号が割り当てられません）。Connection サイトを設定するときは、各 [すべてのボイスメール ユーザ（All Voicemail Users）] リストと各 [ボイスメールが有効なすべての連絡先（All Voicemail-Enabled Contacts）] リストの録音名の変更を検討してください。そうでないと、ユーザがメッセージを名前でこれらのリストのいずれかに対して送信した場合、ユーザに対してわかりにくい選択肢のリストが再生されることがあります。ユーザが、内線番号が他のリストとオーバーラップしているリストの内線番号を宛先として指定すると、Connection がユーザのサーチ スペースのパーティションを順番に検索した際に最初に見つかったリストに到達します。

ヒント 同報リストは、他の同報リストを含むようにネストできます。サイト内の各 Connection ロケーションの [すべてのボイスメール ユーザ（All Voicemail Users）] リストを含む、1 つのマスター [すべてのボイスメール ユーザ（All Voicemail Users）] 同報リストを作成することもできます。

サイト間でシステム同報リストへのメッセージが処理される仕組み

サイト間ネットワーク（Cisco Unity Connection サイト間または Cisco Unity サイトと Connection サイトの間）では、システム同報リストのレプリケーションはオプションであり、リストをレプリケートすると、リストをメッセージの宛先とするために必要な情報だけがレプリケートされます。そのため、ユーザが別のサイトをホームとするシステム同報リストをメッセージの宛先とした場合、メッセージはリモート サイト ゲートウェイ（リモート サイトが Connection サイトの場合）か、または Interoperability Gateway for Microsoft Exchange（リモート サイトが Cisco Unity サイトの場合）に転送されます。この時点で、受信側のシステム同報リストは、メッセージがリモート サイト内から発信されたかのように処理されます。

システム同報リストは、ローカル リストにメンバーとしてリモート リストが含まれるようにネストすることができます。たとえば、あるサイトの [すべてのボイスメール ユーザ（All Voicemail Users）] リストを、他のサイトの [すべてのボイスメール ユーザ（All Voicemail Users）] リスト内にネストできます。（Cisco Unity を Connection とネットワーク接続する場合は、サイト間リンクの作成時に指定したテンプレートによって、Connection ユーザが自動的に [すべてのユーザ（All Subscribers）] リストまたはその他のリストのメンバーとして作成される場合があることに注意してください）。リモート リストをローカル リストのメンバーとしてネストするときは、次のような点に注意することをお勧めします。

• ローカル リストをリモート リストのメンバーとしてネストすることは避けてください。

• ローカル リストをリモート リストにレプリケートすることは許可しないでください。

ネットワーク接続されていない電話システムの宛先オプション

会社がロケーションごとに別個の電話システムを備えている場合は、あるロケーションのユーザが別のロケーションのユーザを呼び出す場合、内線番号だけでなく完全な電話番号をダイヤルします。ユーザがログインして、ネットワーク接続された他のロケーションのユーザにメッセージを送信するときは、メッセージの宛先を内線番号で指定する際に入力する番号は、番号計画がロケーション間でオーバーラップしているかどうかによって異なります。

あるロケーションのユーザの内線番号が別のロケーションのユーザの内線番号とオーバーラップしている場合は、各ユーザ アカウントに代行の内線番号を設定して、各ユーザに一意の内線番号を与えることができます。それぞれのユーザについて、そのユーザの完全な電話番号と同じ代行内線番号を入力し、その代行内線番号が、他のロケーションのユーザが使用するサーチ スペースのメンバーであるパーティション内にあることを確認します。この設定を終えると、ユーザがログインしてメッセージを送信する際、宛先を指定するために入力する番号は、通話の発信に使用するものと同じ番号になります。

番号計画がネットワーク接続されたロケーション間でオーバーラップしていない場合、つまりユーザの内線番号がロケーション間で一意の場合は、別のロケーションに関連付けられたユーザ宛のメッセージの宛先を指定する際、内線番号を入力することができます。この場合、ユーザの便宜のため、2 つの異なる番号（ユーザに直接電話する場合とメッセージの宛先を指定する場合）を記憶しなくてすむように、オプションで代行の内線番号を各ユーザ アカウントに追加することができます。ただし代行内線番号を設定しない場合は、必ずユーザに、別のロケーションに関連付けられたユーザをメッセージの宛先として指定する際は、完全な電話番号ではなく内線番号を使用するよう伝えてください。

代行内線番号には、ユーザ電話機上の複数回線着信表示の処理など、ネットワークにおける使用以外にも目的があることに注意してください。

識別ユーザ メッセージング

ユーザが他のユーザにコールして、そのコールが着信側ユーザのガイダンスに転送される際に、それがメッセージを残しているユーザであることを識別する Cisco Unity Connection の機能は、識別ユーザ メッセージングと呼ばれます。Connection では発信者がユーザであることを識別できるため、次のような利点があります。

• 発信者がメッセージを残すと、Connection で着信側ユーザの内線ガイダンスが再生されます。

• 受信者がメッセージを聞くと、Connection でメッセージを残したユーザの録音名が再生されます。

• Connection では、受信者が返信を録音できます。

次の 2 つの状況間の相違点に注意することが重要です。

• ユーザが Connection にログインし、メッセージを録音して送信する。この場合、ユーザがログインすると、Connection ではメッセージ受信者がどのロケーションをホームとしているかによらず、メッセージがそのユーザからのものであると識別できます。この場合は、電話システムは使用されず、受信者の電話の呼び出し音は鳴りません。メッセージは代わりに、SMTP を使用したネットワーク メッセージ交換によって送信されます。

• ユーザが別のユーザに電話をかけてメッセージを残した。この状況が、識別ユーザ メッセージングの基礎となります。

Connection ロケーションで識別ユーザ メッセージングが有効になっている限り、Connection ではローカルとリモートのユーザが両方識別されます。ただし、両方のケースで識別ユーザ メッセージングが機能するためには、通話の初期の検索範囲が、発信者がローカルのユーザかリモートのユーザかにかかわらず、発信側の内線番号に基づいて正しいユーザを検索するサーチ スペースに設定されている必要があります。

ユーザが通話の初期検索範囲として設定されたサーチ スペースのメンバーでないパーティション内の内線番号からコールした場合、通話はそのユーザからのものと識別されません。ユーザの内線番号が、このサーチ スペースに表示される別のパーティション内の内線番号と重なる場合、その通話は Connection がパーティションをサーチ スペースでの表示順で検索した際に最初に見つかったオブジェクトからのものと識別されます。

そのため、ロケーション間で番号計画がオーバーラップしている場合は、ユーザが残すメッセージが、別のパーティションで内線番号が同じ別のユーザからのものであると誤って識別されてしまうことがあります。通話の初期検索範囲は呼ルーティングのルールに基づくため、このような状況を回避するには、次の設定ガイドラインを使用します。

• ロケーションごとに別個のサーチ スペースを保持し、それぞれのロケーションのユーザを含むパーティションがサーチ スペース内で最初に表示されるようにします。（デフォルトでは、各 Connection サーバが独自のデフォルト パーティションとデフォルト サーチ スペースを使用します。このデフォルト パーティションとデフォルト サーチ スペースは、サーバがネットワーク接続されると、他のロケーションにレプリケートされます）。

• 各ロケーションで、他のすべてのロケーションについて個別に、そのロケーションからの通話だけに適用されるルーティング ルールの条件（たとえば着信通話のポートや電話システムに基づいて）を指定して、ロケーションごとに固有の転送コール ルーティングのルールを設定します。通話の検索範囲を、そのロケーションのユーザを含むパーティションが最初に表示されるサーチ スペースに設定するようルールを作成します。

Cisco Unity と Cisco Unity Connection のサイト間ネットワークに関する考慮事項

次の項を参照してください。

• 「Cisco Unity Connection のサーチ スペースと Cisco Unity ユーザ」

• 「Cisco Unity のダイヤル発信ドメインと Cisco Unity Connection ユーザ」

• 「ユーザが同じ Active Directory 環境内にアカウントを持っている場合の Cisco Unity Unified Messaging と Cisco Unity Connection Integrated Messaging の統合」

Cisco Unity Connection のサーチ スペースと Cisco Unity ユーザ

Cisco Unity サイトと Cisco Unity Connection サイトをリンクすると、各 Cisco Unity サーバの Connection ディレクトリにパーティションが自動的に作成され、そのサーバをホームとするすべての Cisco Unity ユーザとシステム同報リストがそのパーティションに配置されます。ただしこのパーティションは、Connection ロケーションのサーチ スペースに自動的に追加はされません。Connection ユーザが Cisco Unity ユーザをメッセージの宛先として指定する許可を得るには、その Connection ユーザが使用するサーチ スペースにパーティションを追加する必要があります。ユーザが内線番号でアドレス指定する場合は、サーチ スペースに表示される順序が重要になります。たとえば、Connection ユーザと Cisco Unity ユーザがオーバーラップした 4 桁の内線番号を持つ場合、Connection ユーザが他の Connection ユーザには 4 桁のプライマリ内線番号で着信し、Cisco Unity ユーザには 7 桁の固有の代行内線番号で着信できるようにするには、そのオーバーラップした 4 桁の内線番号を含む Connection パーティションの後に Cisco Unity パーティションが表示されていることを確認してください。

Cisco Unity のダイヤル発信ドメインと Cisco Unity Connection ユーザ

ダイヤル ドメインは、同じディレクトリにアクセスし、同じ電話システムまたは電話システム ネットワークと連動するサーバの集合です。ダイヤル発信ドメインは、Cisco Unity がサーバ間での着信転送や内線番号によるアドレス指定を処理するための、グループ分けの方式です。ダイヤル発信ドメイン内では、内線番号は一意でなければならず、電話システム内の電話の内線番号も同様です。

Cisco Unity サイトと Cisco Unity Connection サイトをリンクする場合、Cisco Unity ディレクトリで作成された Connection ユーザとシステム同報リストのオブジェクトは、Cisco Unity サイト ゲートウェイに設定されたダイヤル発信ドメインに属します。Connection のサーチ スペースとパーティションの設計はオーバーラップする内線番号に対応しており、一部のユーザはプライマリ内線番号と代行内線番号を別のパーティション内に持っている可能性があるため、Connection の内線番号を Cisco Unity のダイヤル発信ドメインにマッピングする方法を選択する必要があります。これを行うには、各 Connection ロケーションについて、Cisco Unity が内線番号をプルするパーティションを 1 つ指定します。（Cisco Unity Connection Administrationでは、ローカル ロケーションの [ロケーションの編集（Edit Location）] ページにある、[Cisco Unity ユーザが内線番号で宛先指定できるローカル パーティション（Local Partition That Cisco Unity Users Can Address to By Extension）] フィールドを設定します）。たとえば、Kelly Bader という Connection ユーザが、「Sales パーティション」にプライマリ内線番号（4441）と、「Chicago パーティション」に代行内線番号（2025555）という 2 つの内線番号を持っているとします。Kelly のホーム サーバ ロケーションのダイヤル発信ドメインに内線番号をマッピングするパーティションが「Chicago パーティション」の場合、Cisco Unity ユーザは内線番号 2025555 を入力すれば Kelly を宛先として指定できます。内線番号 4441 を入力しても、Kelly を宛先には指定できません。Kelly のロケーションのダイヤル発信ドメインにマッピングを行うパーティションが「Sales パーティション」に変更されると、Cisco Unity ユーザは内線番号 4441 を入力すれば Kelly を宛先として指定できますが、内線番号 2025555 ではできなくなります。（いずれの場合も、Cisco Unity ユーザは内線番号ではなく名前を使用すれば、Kelly を宛先として指定できます）。

Connection ユーザの内線番号が、ダイヤル発信ドメイン内の既存の内線番号と競合し、そのユーザが Cisco Unity でプルされるパーティション内に使用可能な代行内線番号を持っている場合、Cisco Unity はユーザの代行内線番号の 1 つを、対応する連絡先オブジェクトの内線番号として割り当てるよう試みます。使用可能な代行内線番号がない場合や、すべての代行内線番号がダイヤル発信ドメイン内の既存の内線番号と競合する場合は、内線番号のない新しいオブジェクトが作成されます。このオブジェクトは、名前でだけアドレス指定できます。同様に、ダイヤル発信ドメインにマッピングを行うパーティション内にオブジェクトの内線番号がない場合も、内線番号のない新しいオブジェクトが作成されます。

ユーザが同じ Active Directory 環境内にアカウントを持っている場合の Cisco Unity Unified Messaging と Cisco Unity Connection Integrated Messaging の統合

Cisco Unity Unified Messaging サイトを Connection サイトとリンクする際、両方のサイトのユーザが同じ Active Directory 環境内に電子メール アカウントを持っている場合は、Cisco Unity で Connection ユーザ用に作成される連絡先により、ユーザが ViewMail for Outlook または他の電子メール クライアントを介してメッセージを送信する際のユーザ エクスペリエンスが複雑化する場合があります。

例として、次の 2 名のユーザを考えてみます。

• pjones@example.com というエイリアスを使用する Unified Messaging アカウントを持つ、Cisco Unity ユーザの Pat Jones。Pat は Microsoft Outlook および Cisco Unity ViewMail for Outlook を使用して、1 つのメールボックスにある電子メールとボイス メッセージにアクセスしています。

• 同様に Microsoft Exchange の電子メールアカウントを持つ Connection ユーザの Robin Smith。エイリアスは alias rsmith@example.com です。Robin は Microsoft Outlook および Connection ViewMail for Outlook を使用して、Exchange のメールボックスにある電子メールと、Connection メールボックスにあるボイス メッセージにアクセスしています。

Cisco Unity と Connection のサイトをリンクする前は、Pat と Robin が Outlook で使用している連絡先リストには、pjones@example.com としての Pat Jones のエントリが 1 つ、rsmith@example.com としての Robin Smith のエントリが 1 つ含まれています。Robin はまた、Connection ViewMail for Outlook でボイス メッセージを送信し、Outlook の連絡先リストを使用してアドレス指定されたメッセージを受信するための、Connection の SMTP プロキシ アドレスとして定義された rsmith@example.com を持っています。（ただし 2 つのサイトをリンクする前は、Pat と Robin が ViewMail クライアントを使用してボイスメッセージのやり取りをすることはできません）。

2 つのサイトをリンクすると、Cisco Unity で Robin Smith の Active Directory に連絡先が追加されます。この連絡先の表示名はデフォルトで「Robin Smith - Voicemail」となり、Robin の Exchange アカウントと区別されます。（「-Voicemail」という表示名のサフィックスは変更可能です）。この連絡先には、UCI_<エイリアス>_BH-<Connection ロケーション ID>@<Exchange の連絡先作成ポリシーに従って生成されたドメイン> の形式の SMTP アドレスが付与されます。Cisco Unity ユーザが ViewMail でボイスメッセージの宛先を指定する際は、この連絡先を使用可能で、またこれを使用する必要があります。Connection ユーザの電子メール アカウント（その連絡先ではなく）を宛先としたボイス メッセージは、音声付きの電子メールとして配信され、ユーザのメッセージ受信インジケータは点灯しないか、そうでない場合は Connection を介してアクセス可能になります。

別の Connection ユーザが、連絡先リスト内の「Robin Smith - Voicemail」宛にボイス メッセージを送信しようとすると、デフォルトでこのメッセージは配信不能として返送されます。これは、Connection が UCI_<エイリアス>_BH-<Connection ロケーション ID>@<Cisco Unity サイト ゲートウェイ ドメイン> というアドレスを、Connection ユーザに属するものとして認識しないからです。この問題を緩和するには、アドレスをユーザの SMTP プロキシ アドレスとして追加することができます。（Active Directory ユーザとコンピュータを使用して Connection の連絡先のリストをエクスポートし、その後Bulk Administration Toolを使用して SMTP プロキシ アドレスを Connection ユーザに一括で追加することができます。Bulk Administration ToolBulk Administration Tool の使用方法については、 http://www.cisco.com/en/US/docs/voice_ip_comm/connection/8x/user_mac/guide/8xcucmacx.html で、『 User Moves, Adds, and Changes Guide for Cisco Unity Connection 』 （Release 8.x） の「 Using the Cisco Unity Connection Bulk Administration Tool 」の章を参照してください）。Robin に SMTP プロキシ アドレスを設定したら、他の Connection ユーザは「Robin Smith - Voicemail」という連絡先にボイス メッセージを送信できるようになります。ただし、Connection ユーザがこの連絡先宛に電子メールを送信しようとすると、その電子メールは配信不能として返送されます。

Cisco Unity ユーザには、サイトのリンク後も、Active Directory に 1 つのエントリがあります。いずれのサイトのユーザも、ViewMail for Outlook のエントリにボイス メッセージを送信できます。

1 つ以上の Connection システム同報リストを Cisco Unity Unified Messaging 環境に同期する場合は、各リストについて Active Directory グループが作成され、それらのグループは連絡先リスト内で確認できます。このグループには、表示名に追加されるのと同じ設定可能なサフィックス（デフォルトでは「Voicemail」）が付きます。ユーザの連絡先エントリの場合と同様、グループ宛にメッセージを送信しようとする Connection ユーザには、応答として不達確認が返されます。ただしこの場合、現時点では、同報リストの SMTP プロキシ アドレスは設定できないため、SMTP プロキシ アドレスを使用して同期した同報リストに関する問題を緩和することはできません。この問題を回避するには、2 種類の方法があります。

• Connection システム同報リストを Cisco Unity サイトに同期しないでください。代わりに、Cisco Unity ユーザが必要とするリストはすべて Cisco Unity サイト上で作成し、必要に応じて Connection の連絡先をメンバーとして追加します。

• Microsoft Exchange の複数の連絡先リストを使用して Cisco Unity ユーザと Connection ユーザ間のセグメント アドレッシングを行い、Connection ユーザが Cisco Unity で Connection リストについて作成されたグループのアドレスにアクセスできないようにします。

Connection ユーザがグループのアドレス帳エントリを使用して Connection システム同報リストにメッセージを送信することはできませんが、Connection リストをメッセージの宛先とすることはできます。この場合は、<リストのエイリアス>@<Connection サーバ SMTP ドメイン> の形式でリストのアドレスを入力します。