ネットワーク概念の概要
概要
各 Cisco Unity Connection サーバー (またはクラスター) には、サポートできるユーザーの最大数があります。 組織のメッセージ要件により、複数の Unity Connection サーバーまたはクラスタが必要な場合、または複数の Unity Connection ディレクトリを組み合わせる場合、または Unity Connection を Cisco Unity に相互接続する場合は、Cisco ボイスメール組織を構成する仕組みが必要です。
Cisco ボイスメール組織は、Unity Connection サーバーまたはクラスタをリンクしてサイトを構成する際、および Unity Connection サイトを別の Unity Connection さいとまたは Cisco Unity サイトにリンクする際に編成できます。
Unity Connection サイトとサイト内リンクについて
2 つ以上の Unity Connection サーバーまたはクラスタを接続すると (最大 10 まで)、接続性の高いネットワークを構築できます。これは、Unity Connection サイトと呼ばれています。 サイトに接続されているサーバーは、ロケーションと呼ばれます。 (Unity Connection クラスタが構成されている場合、クラスタは、サイト内で 1 つのロケーションとしてカウントされます)。 サイト内で、各ロケーションは SMTP を使用して、ディレクトリ同期情報およびメッセージを他のすべてのロケーションと直接交換します。 各ロケーションは、サイト内リンクを介してサイト内の他のすべてのロケーションにリンクされています。 図 1 は、サイト内リンクで接続された 5 つの Unity Connection ロケーションで構成されているサイトを示しています。
Unity Connection サイトのコンセプトは、Unity Connection リリース 7.x ではデジタルネットワークとして知られていました。 そのサイトがほかのサイト (サイト間リンクでは、各 Unity Connection ロケーションがリリース 14 である必要があります) にリンクされていない限り、同じ Unity Connection サイト (サイト内リンク) で 7.x ロケーションと 8.x ロケーションを接続できます。
各 Unity Connection サーバーまたはクラスタは、サイト内で単一の Unity Connection ロケーションとして表されます。これは、インストール中にローカルに作成され、サーバー自体から削除することはできません。 サイト内の既存のロケーションにサーバー (またはクラスター) を接続する際、Unity Connection ロケーションは、サイト内のほかのすべてのロケーションにサーバー (またはクラスタ) に対して自動削除され、これらのロケーションは、新しいロケーションとのディレクトリ同期を開始します。 Unity Connection のロケーションは、1 つのサイトにのみ属することができます。
Cisco ボイスメール組織とサイト間リンクについて
サイト間リンクを使用すると、ある Unity Connection サイトを別の Unity Connection サイトに接続できます。これにより、10 つのロケーションから最大 20 のロケーションまで組織を拡張できます。また、サイト間リンクを使用すると、Unity Connection サーバーまたはサイトを Cisco Unity サーバーまたは Cisco Unity デジタルネットワークに接続できます。 リンクされたサイトは Cisco ボイスメール組織と呼ばれます。
サイト間リンクを作成するには、各サイトから 1 つのロケーションを選択して、他のサイトへのゲートウェイとして機能させます。 ディレクトリ同期に関するすべての通信は、2 つのサイトゲートウェイ間を経由するため、接続要件と帯域幅の使用量は、これら 2 つのサイトゲートウェイ間のリンクに限定されます。
サイトごとにサポートされているサイト間リンクは 1 つだけです。 つまり、単一の Unity Connection サイトを単一の Cisco Unity サイトにリンクすることも、単一の Unity Connection サイトを別の Unity Connection サイトにリンクすることもできます。
2 つの Unity Connection サイトのリンクについて
2 つの Unity Connection サイトをサイト間リンクで接続する場合、各サイトのゲートウェイは、ローカルサイトディレクトリへのすべての変更に関する情報を収集し、リモートサイトゲートウェイを定期的にポーリングして、リモートサイトディレクトリの更新に関する情報を取得する責任を負います。 ゲートウェイは、ディレクトリ同期の更新情報を交換するために HTTP または HTTPS プロトコルを使用します。
各サイトゲートウェイは、リモートサイトの受信者宛てのメッセージを送信するとともに、自サイトの受信者宛てのメッセージを受信する役割も担います。 サイト間のメッセージは SMTP を使用して送受信されます。
Unity Connection クラスタをサイト ゲートウェイとして使用する場合、クラスタ内のパブリッシャサーバだけがサイト間リンク上のディレクトリ同期に参加します。 ただし、サブスクライバサーバーは、パブリッシャサーバーが停止しても、引き続きサイト間リンク経由でメッセージを交換します。
図 2 は、2 つの Unity Connection サイトを接続する際のサイトゲートウェイとサイト間リンクの役割を示しています。
 （注） |
2 つの Unity Connection サイトをリンクするには、各サイトのすべてのサーバが Unity Connection バージョン 14 を実行している必要があります。 |
VPIM ネットワーキングについて
Unity Connection は、インターネットまたは TCP/IP ネットワーク上で異なる音声メッセージシステムが音声やテキストメッセージを交換できるようにする業界標準のプロトコルである、Voice Profile for Internet Mail (VPIM) プロトコルをサポートしています。 VPIM は、Simple Mail Transfer Protocol (SMTP) および Multi-Purpose Internet Mail Extension (MIME) プロトコルに基づいています。
Unity Connection 15 は、Unity Connection ディレクトリ内で最大 10 個の VPIM ロケーションと 10 万件の VPIM 連絡先をサポートします。 これらの制限は、単一の Unity Connection サーバまたはクラスタペアのディレクトリ、あるいはサイト内のグローバルディレクトリのいずれにも適用されます。
Unity Connection ネットワークサイトに VPIM を導入する場合は、サイト内の単一の Unity Connection ロケーションを、VPIM ロケーションと連絡先の設定を処理するブリッジヘッドとして指定する必要があります。 VPIM ロケーションデータおよび VPIM ロケーションにおけるすべての連絡先 (自動的に作成された連絡先を含む) は、ブリッジヘッドからサイト内の他のロケーションにレプリケートされます。 VPIM メッセージが、ブリッジヘッド以外の Unity Connection ロケーションをホームにしているユーザーによって送信された場合、メッセージはまず、メッセージを宛て先サーバーに転送する処理を行うブリッジヘッドに渡されます。 同様に、VPIM 連絡先からのメッセージはブリッジヘッド別に受信され、Unity Connection 受信者のホームサーバーに中継されます。
Cisco Voicemail Organization に VPIM を導入する場合、各サイトで VPIM の設定を個別に行う必要があります。 VPIM の場所と連絡先はサイト間のリンクを介して複製されず、サイトゲートウェイは VPIM メッセージを他のサイトに中継しません。
VPIM ネットワークの詳細については、「VPIM ネットワーク」の章を参照してください。 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/14/networking/guide/b_14cucnetx/b_14cucnetx_chapter_011.html
ディレクトリ同期
Unity Connection サイトまたは Cisco Voicemail Organization 内の各ロケーションには、そのロケーションで作成されたユーザーやその他のオブジェクトの独自のディレクトリがあり、それらはそのロケーションに所属しているとされています。 場所やサイト間で複製されるオブジェクトおよびオブジェクトプロパティの集合は、グローバルディレクトリと呼ばれます。
ディレクトリ同期中に複製される特定のオブジェクトおよびオブジェクトプロパティの詳細については、以下のセクションを参照してください。
Unity Connection サイト内でのレプリケーション
Unity Connection サイト内では、各ロケーションは、表 1 に示されているオブジェクトおよびオブジェクトプロパティをそのディレクトリから各ロケーションにレプリケートします。
|
レプリケートされたオブジェクト |
レプリケートされたプロパティ |
|---|---|
|
メールボックスを持つユーザ |
|
|
システムの連絡先 |
すべてのプロパティ |
|
システム分散リスト |
リストメンバーシップを含むすべてのプロパティ |
|
パーティション |
すべてのプロパティ |
|
サーチスペース |
メンバーシップを含むすべてのプロパティ |
|
Unity Connection の場所 |
|
|
VPIM ロケーション |
[連絡先作成] 設定を除くすべてのプロパティ (連絡先作成は、VPIM ロケーションのホームとなっている Unity Connection ロケーションで処理されます) |
ほとんどの場合、複製されたオブジェクトはローカルオブジェクトと同じように使用できます。たとえば、リモートユーザをシステムコールハンドラのメッセージ受信者として割り当てたり、ユーザの検索範囲を構成してリモート検索スペースを使用するようにしたりできます。 次の例外に注意します。
-
システムコールハンドラの所有者はローカルユーザでなければなりません。
-
パーティションのオブジェクト (ユーザー、連絡先、ハンドラ、システム分散リストおよび VPIM ロケーション) は、ローカルパーティションのみに属することができます。 ただし、リモートパーティションをローカル検索スペースに追加することは可能です。
Unity Connection ロケーションをホームとするレプリケートされたオブジェクトが追加、変更または削除された場合、そのロケーションは、変更詳細を含むオブジェクト変更要求をその他のすべてのロケーションに送信します。 特定の場所におけるオブジェクト変更要求は、固有シーケンス番号（USN）と呼ばれる番号によって順序付けられ、追跡されます。 変更が発生するたびに、その場所は USN を 1 つ増やし、データベースに変更内容を記録します。 送信元から前回受信した要求の USN より 1 大きい USN 値を持つオブジェクト変更要求を受信すると、その内容に応じて Unity Connection ディレクトリのコピーを更新し、送信者向けに追跡している USN の値を 1 増やします。 リモートロケーションが、1 つ以上の変更を見落とし、このロケーションから受信した前回受信した要求の USN より 1 大きい USN 値を持つ変更要求を受信した場合、見落とした USN 値を要求することで見落とした変更を取得できます。
USN に加えて、各ロケーションには、レプリケーションセットと呼ばれる別の関連付けられている番号があります。 レプリケーションセットの値は、USN が属する変更のセットを追跡するために使用されます。 レプリケーションセットの値は、アップグレード、復元、またはロールバック操作中に自動的に変更されます。 これにより、その操作によって発生したデータベースへの変更が、ネットワークにレプリケートされます。 たとえば、ロケーション A がロケーション B から、レプリケーションセット 10 と USN 5 が設定されたメッセージを受信し、その後、ロケーション B からレプリケーションセット 9 と USN 5 が設定されたメッセージを受信した場合、ロケーション A は、レプリケーションセット 9 が設定されたメッセージを無視します。これは、9 が 10 より低い番号で、そのメッセージが、レプリケーションセット 10 のメッセージよりも古いメッセージであるためです。ロケーション A が、ロケーション B から、レプリケーションセット 10 と USN 5 が設定された別のメッセージ再度受信した場合、ロケーション A は、これを重複するメッセージだと認識し、無視します。
ロケーションで一括処理が進行中の場合、その処理が完了するまで、そのロケーションでのレプリケーションは一時停止されます。
2 つの Unity Connection サイト間でのレプリケーション
表 2 に示すように、1 つの Unity Connection サイト内と同様に、2 つの Unity Connection サイト間でも同じオブジェクトとオブジェクトプロパティがレプリケートされますが、以下の例外があります。
-
システム連絡先はサイト間でレプリケートされません。
-
各サイトごとに、リモートサイトをホームにしているすべてのシステム分散リストを同期するかどうかを選択できます。 また、個々のリストごとに、そのリストをリモートサイトへのレプリケーション対象として提供するかどうかを選択できます。
-
システム配布リストのメンバーシップは、サイト間で複製されません。
-
VPIM の場所（および連絡先）は、サイト間で複製されません。
表 2. ある Unity Connection サイトから別の Unity Connection サイトにレプリケートされたオブジェクト 複製されたオブジェクト
複製されたプロパティ
メールボックスを持つユーザ
-
Alias
-
名、姓、表示名、別名
-
内線、サーバー間転送内線、および代替内線
-
ディレクトリ一覧のステータス
-
パーティション
-
記録名 1
-
SMTP アドレスと SMTP プロキシアドレス
システム分散リスト 2
-
Alias
-
表示名
-
内線番号
-
パーティション
-
録音名1
パーティション
すべてのプロパティ
サーチスペース
すべてのプロパティ
Unity Connection のロケーション
-
表示名
-
ホストアドレス
-
SMTP ドメイン名
-
Unity Connection バージョン
1 サイトごとに、リモートサイトオブジェクトの記録名を同期するかどうかを選択できます。 2 ローカルサイトシステム分散リストは、リモートサイトゲートウェイのサイト間リンクに対して、[ディレクトリデータの同期時に分散リストを含める] チェックボックスがオンになっており、リストに対して [サイト間リンク経由でリモートサイトをレプリケートする] チェックボックスがオンになっている場合のみリモートサイトによって同期されます。 -
サイト内リンクと同様に、リモートサイトからレプリケートされたオブジェクトは、ローカルオブジェクトと同様に使用できますが、通話ハンドラの所有者は、ローカルユーザーである必要があり、パーティションのオブジェクトは、ローカルパーティションにのみ属することができます。
サイト間レプリケーションは、各サイトのゲートウェイ上で実行されるフィーダーサービスとリーダーサービスによって実現されます。 リーダーサービスは、定期的にリモートサイトのゲートウェイを使って、前回のポーリング間隔以降に変更されたディレクトリの有無を調べます。 フィーダーサービスは変更追跡データベースでディレクトリの変更を確認し、必要な情報でポーリングリクエストに応答します。
各サイトゲートウェイでは、Reader がディレクトリデータについてリモート Feeder をポーリングするスケジュールおよび録音名をポーリングするスケジュールを構成できます。 サイトゲートウェイの Cisco Unity Connection Administration で、[ツール] > [タスク管理] ページ > [ディレクトリとリモートネットワークを同期タスク] または [音声名をリモートネットワークと同期タスク] の順に選択すると、スケジュールにアクセスできます。 または、サイト間リンクの編集ページにある「関連リンク」フィールドを使用して、どちらのタスクにもアクセスできます。
[音声名とリモートネットワークを同期タスク] を有効にすると、Reader は、リモートユーザーとシステム分散リスト (ある場合) の録音名ファイルを処理します。 ローカルサイト上のリモートオブジェクトに対して記録名が作成されると、その記録名に対応するリモートファイル名とローカルファイル名が異なる場合にのみ、記録名が更新されます。 例えば、リモートサイトのゲートウェイで記録された名前の送信コーデックを変更した場合、その変更はファイル名には影響しないため、ローカルサイトのファイルは更新されません。 この場合に更新された録音名のコピーをプルするには、ローカルサイトゲートウェイからのすべての既存の録音名を消去し、Unity Connection Administration の [サイト間リンクを検索] ページの [録音名を消去] ボタンと [すべて再同期] ボタンを使用して、完全な再同期を実行します。Cisco Unity と Unity Connection サイト間のレプリケーション
Cisco Unity サイトと Unity Connection サイトをリンクする際、連絡先 (別名: Unity Connection Networking サブスクライバ) が、Cisco Unity ディレクトリと各 Unity Connection ユーザーの Active Directory に追加されます。 同様に、ユーザー (別名: Cisco Unity Connection Administration の Cisco Unity ユーザー) が、各 Cisco Unity ユーザーの Unity Connection サイト グローバル ディレクトリに追加されます。 Unity Connection システム連絡先と VPIM 連絡先は、Cisco Unity ではレプリケートされません。また、Cisco Unity ネットワーク連絡先 (AMIS、ブリッジ、VPIM、サイト間または信頼されているインターネットサブスクライバ) は、Unity Connection ではレプリケートされません。
システム分散リストは、ローカルサイトがリモートサイトからリストをプルするように構成されている場合、およびリスト自体が別のサイトにレプリケーションできるように構成されている場合、あるサイトから別のサイトにレプリケートされる場合があります。 システム連絡先を含むリストまたはネットワーク連絡先は、他のサイトにレプリケートするように構成できません。 複製されるリストの場合、複製されるのはリスト名とアドレス指定に使用されるその他の情報のみであり、リストのメンバーシップは複製されません。
表 3 は、Cisco Unity と Unity Connection サイト間でレプリケートされたオブジェクト、およびレプリケートされているオブジェクトプロパティを一覧します。
|
レプリケートされたオブジェクト |
複製されたプロパティ |
|---|---|
|
メールボックスを保持する Unity Connection ユーザー |
|
|
Cisco Unity ユーザー |
|
|
システム分散リスト 5 |
|
|
ロケーション（Locations） |
|
サイト間レプリケーションは、各サイトのゲートウェイ上で実行されるフィーダーサービスとリーダーサービスによって実現されます。 リーダーサービスは、定期的にリモートサイトのゲートウェイを使って、前回のポーリング間隔以降に変更されたディレクトリの有無を調べます。 フィーダーサービスは変更追跡データベースでディレクトリの変更を確認し、必要な情報でポーリングリクエストに応答します。
Unity Connection サイトゲートウェイでは、Reader がディレクトリデータについて リモート Feeder をポーリングするスケジュールおよび録音名をポーリングするスケジュールを構成できます。 サイトゲートウェイの Cisco Unity Connection Administration で、[ツール] > [タスク管理] ページ > [ディレクトリとリモートネットワークを同期タスク] または [音声名をリモートネットワークと同期タスク] の順に選択すると、スケジュールにアクセスできます。 または、サイト間リンクの編集ページにある「関連リンク」フィールドを使用して、どちらのタスクにもアクセスできます。
Cisco Unity サイトゲートウェイでは、録音名の同期を有効または無効にできます。また、リーダーがディレクトリの更新や録音名について Unity Connection フィーダーにポーリングする間隔を設定できます。 ディレクトリデータと録音名のポーリングに対して個別に設定可能なスケジュールを持つ Unity Connection リーダーとは異なり、Cisco Unity リーダーは各サイクル中に両方（録音名の同期が有効になっている場合）についてポーリングすることに注意してください。
「リモートネットワークとの音声名の同期」タスクが有効になっている場合、リーダーはリモートユーザおよびシステム配布リスト（該当する場合）の記録された名前ファイルを処理します。 ローカルサイトのリモートオブジェクトに対して録音名が作成された場合、録音名のリモートファイル名とローカルファイル名が異なる場合のみ、録音名が更新されます。 例えば、リモートサイトのゲートウェイで記録された名前の送信コーデックを変更した場合、その変更はファイル名には影響しないため、ローカルサイトのファイルは更新されません。 Cisco Unity から Unity Connection に更新された録音名のコピーをプルするには、Unity Connection Administration で、[ネットワーク] > [リンク] > [サイト間リンクを検索] ページの順に選択し、[録音名を消去] ボタンを使用して Unity Connection サイトゲートウェイからすべての既存の録音名を消去する必要があります。 Unity Connection から Cisco Unity に更新された録音名のコピーをプルするには、Cisco Unity Administrator で、[ネットワーク] > [Unity Connectionネットワークプロファイル] ページの順に選択し、[音声名を消去] ボタンを使用します。
ディレクトリのサイズ制限
Unity Connection グローバルディレクトリ (ローカルオブジェクトとレプリケートされたオブジェクトのすべてのコレクション) には、具体的なサイズ制限があります。 単一の Unity Connection サイトにも、リンクされたサイトの Cisco Voicemail Organization にも、同じ制限が適用されます（Unity Connection サイトが別の Unity Connection サイトまたは Cisco Unity サイトにリンクされているかどうかに関係なく）。 Cisco ボイスメール組織では、制限を超えると、サイト同士をリンクする機能や、サイトがリンクされた後にサイト間リンク経由で追加のディレクトリオブジェクトをレプリケートする機能に影響します。 Unity Connection 14 では、ユーザ数と連絡先数、およびシステム配布リストの数にそれぞれ個別の制限が設けられています。
Unity Connection 14 の時点でのサイズ制限は以下のとおりです。
-
ユーザーとシステムの連絡先 (VPIM ロケーションに関連付けられた連絡先と、ロケーションに関連付けられていない連絡先の両方を含む) の合計数 100,000 件
-
100,000 件のシステム分散リスト
-
システム分散リストあたり 25,000 ユーザー
-
すべてのシステム分散リストにおける総メンバー数 150万
-
20 階層のネスト (あるシステム分散リストが別のリストのメンバーとして含まれる場合)
-
（注） |
ディレクトリオブジェクトには追加の制限があり、リリース以降にディレクトリオブジェクトの制限が更新されている可能性があります。 最新の制限の詳細については、「Cisco Unity Connection リリース 14 のシステム要件」を参照してください (入手先: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/14/requirements/b_14cucsysreqs.html)。 |
Unity Connection サイトを別の Unity Connection サイトまたは Cisco Unity サイトにリンクしようとすると、Unity Connection サイトゲートウェイによって、ユーザとシステムのコンタクト制限、およびシステム配布リストの制限の両方がチェックされます。 リンク作成後にゲートウェイ上のユーザと連絡先の合計数がユーザと連絡先の制限を超える場合、またはゲートウェイ上のシステム配布リストの合計数がリストの制限を超える場合は、サイトをリンクすることはできません。 （サイト間リンクでは連絡先が複製されないため、リンク後も 2 つのサイトのグローバルディレクトリサイズが必ずしも一致するとは限りません。） ただし、各 Unity Connection サイトは、システム連絡先を含む最大サイズ制限の対象となります。
以下のユーザーおよびシステム連絡先の上限チェックの例を考慮します。 Unity Connection のサイト A には 40,000 人のユーザーと 5,000 件のシステム連絡先があり、Unity Connection のサイト B には 50,000 人のユーザーと 15,000 件の連絡先があります。 これらのサイトをリンクすると、Unity Connection サイト A のグローバルディレクトリには 95,000 のユーザーおよび連絡先オブジェクト (40,000 + 5,000 + 50,000) が含まれることになります。 一方、Unity Connection サイト B のグローバルディレクトリには、合計 105,000 のユーザーおよび連絡先オブジェクト (50,000＋15,000＋40,000) が含まれることになります。 これらの 2 つのサイトを結合しようとしても、サイト B のユーザー数と連絡先数の上限を超過しているため失敗します。一方で、50,000 人のユーザーと 15,000 件のネットワーク連絡先を持つ Cisco Unity サイトと Unity Connection サイト A の結合は成功します。これは、Unity Connection サイトのグローバルディレクトリにある 95,000 のユーザーおよび連絡先オブジェクトが、100,000 のユーザーおよびシステム連絡先数の上限を超えないためです。
Unity Connection の各サイトゲートウェイは、2 つのサイトが接続される際に制限を確認するだけでなく、Reader サービスが実行されるたびに、ユーザーとシステムの連絡先の制限、およびシステム分散リストの制限も確認します。 制限値を 5 パーセント以上超過した場合、Reader サービスはリモートサイトオブジェクト用の新しいディレクトリオブジェクトを作成できなくなります。 さらに、既存のオブジェクトに対する変更は引き続き同期され、オブジェクトがリモート サイトで削除された場合は、そのオブジェクトも削除されます。 そのため、この状態は、「削除モード」と呼ばれます。Reader を削除モードから解除するには、十分な量の適切な種類のオブジェクトを削除し、オブジェクト数を上限の 5% 超過未満に抑えます (たとえば、ユーザーとシステム連絡先上限を超過している場合は、リモートユーザー、ローカルユーザーまたはローカルシステム連絡先を削除します。またはシステム分散リストの上限を超過している場合は、ローカルシステムまたはリモートシステムの分散リストを削除します)。
Messaging
特定のネットワーク状況におけるメッセージングの処理方法の詳細については、以下のセクションを参照してください。
Unity Connection サイト内でシステム配信リストへのメッセージがどのように処理されるか
Unity Connection サイトのロケーションでシステム分散リストがレプリケートされるため、リストがユーザーの検索範囲で到達可能である限り、ユーザーは、任意のロケーションの任意のシステム分散リストにメッセージをアドレス指定できます。
ユーザーが、メッセージをシステム分散リストにアドレス指定する場合、ローカル Unity Connection ロケーションは、分散リストのメンバーシップを解析します。 送信元は、リストに登録されているローカルユーザにメッセージを直接配信します。 リストにリモート Unity Connection ユーザーがある場合、送信側ロケーションは、メッセージをこれらのリモートユーザーがホームにしている各ロケーションに配信します。 リストに VPIM ユーザーが存在する場合、送信側サーバーは、VPIM ロケーションがローカルにホームされていればその VPIM 宛先にメッセージを配信し、そうでない場合は、そのロケーションがホームされているサーバーにメッセージを渡します。また、そのサーバーが宛先サーバーへのメッセージ転送を処理します。
Unity Connection には、All Voicemail Users、Undeliverable Messages および All Voicemail-Enabled Contacts の事前定義済みのシステム分散リストが含まれています。 組織内の各 Unity Connection サーバには、これらのリストのそれぞれ異なるバージョンが存在します。 これらのリストの名前を一意に変更していない場合、最初のレプリケーション時に、各サーバーは、ローカルリスト名と重複する名前の任意のリモートリストの表示名にリモートサーバーの名前を自動で追加します。
デフォルトでは、Unity Connection ロケーションの事前定義されたリストは、同じ録音名が指定され、All Voicemail Users リストと All Voicemail-Enabled Contacts リストには、各ロケーションで同じ内線番号が割り当てられます (デフォルトの Undeliverable Messages リストは、内線番号に割り当てられません。これは、ユーザーは通常、このリストへのメッセージをアドレス指定しないためです)。 Unity Connection サイトの設定時、各 All Voicemail Users リストと All Voicemail-Enabled Contacts リストの録音名を変更することを考慮します。変更しないと、ユーザーがこれらのリストのいずれかの名前でメッセージをアドレス指定する際に、分かりにくい選択肢のリストが聞こえてしまうことがあります。 ユーザーが、別のリストの内線番号と重複しているリストを内線番号でアドレス指定した場合、Unity Connection はユーザーの検索スペースのパーティションを順番に検索し、最初に見つかったリストに接続します。
 ヒント |
配布リストはネストすることができ、ある配布リストの中に別のリストを含めることができます。 各 Unity Connection ロケーションの All Voicemail Users リストを含むサイトに対して、1 つのマスター All Voicemail Users 分散リストを作成できます。 |
サイト間でシステム分散リストへのメッセージが処理される方法
サイト間ネットワーク (Unity Connection サイト間、または Cisco Unity と Unity Connection サイト間) の場合、システム分散リストのレプリケーションはオプションであり、リストをレプリケートする場合は、リスト宛てのメッセージに必要な情報のみがレプリケートされます。 したがって、ユーザーが別のサイトをホームにしているシステム分散リストにメッセージをアドレス指定すると、そのメッセージは、リモートサイトゲートウェイ (リモートサイトが Unity Connection サイトの場合)、または Microsoft Exchange との相互運用性 (リモートサイトが Cisco Unity サイトの場合) にルーティングされます。 この時点では、システム配布リストの受信者は、メッセージがリモートサイト内で発信されたかのように扱われます。
システム分散リストはネストで気、ロケーションリストにメンバーとして含めることができます。 たとえば、あるサイトの All Voicemail Users 分散リストを、別のサイトの All Voicemail Users リスト内にネストできます。 (Cisco Unity と Unity Connection をネットワーク接続する場合、他会リンク作成時に指定したテンプレートによっては、Unity Connection ユーザーが All Subscribers リストまたはその他のリストのメンバーとして自動作成されることがあります)。 リモートリストをローカルリストのメンバーとしてネストする場合は、以下の推奨事項に従います。
-
ローカルリストをリモートリストのメンバーとしてネストすることは避けてください。
-
ローカルリストをリモートサイトに複製させないでください。
サーバー間サインイン、転送およびライブ返信
レプリケーションのトラフィックを制限し、ディレクトリのサイズを管理しやすい状態に保つため、ユーザーのホームロケーションからほかのロケーションへは、ユーザー情報のごく一部のみがレプリケートされます。 そのため、通話転送設定、挨拶メッセージ、その他のユーザー固有の詳細情報は、ユーザーのホームロケーションのみに保持されます。 ロケーションが別のロケーションのユーザー宛の通話を適切に処理するには、通話を受信するロケーションが、通話をそのユーザーのホームロケーションに転送する必要があります。 サーバー間機能の目的は、表 4 で示されているように、単一のサーバー環境と同じようなユーザーエクスペリエンスをネットワーク接続された環境でも設定することです。
|
機能 |
説明 |
|---|---|
|
サーバー間サインイン |
サーバー間サインイン機能を使用すると、管理者は、別のロケーションに属するユーザーに、サインイン時に使用できる 1 つの電話番号を提供できるようになります。組織外から発信する際、ユーザーは、属するホームサーバーに関係なく、同じ番号に発信でき、サインインする該当するホームサーバーに転送されます。 |
|
サーバー間転送 |
サーバー間転送機能を使用すると、通話転送および発信したユーザーのスクリーニング設定に基づいて、自動応答からの通話、または別のサーバーのユーザーに転送されるあるサーバーのディレクトリハンドラからの通話を有効にできます。 |
|
サーバー間ライブ返信 |
サーバー間ライブ返信機能を使用すると、電話機でメッセージを再生しているユーザーは、別のサーバーに所属するユーザーからのメッセージに対し、そのユーザーへ発信して返信できます (通話転送および発信したユーザーのスクリーニング設定に従い)。 |
サーバー間機能は、1 つのサイトおよび Cisco ボイスメール組織全体の両方で有効化できます。 サーバー間機能の有効化に関する詳細と手順については、「サーバー間サインイン、転送、ライブ返信」章を参照してください。
アドレス指定とダイヤルプランに関する考慮事項
特定のネットワーク状況におけるアドレス設定とダイヤルプランの考慮事項については、以下のセクションを参照してください。
ネットワーク接続されていない電話システムのアドレス指定オプション
組織が各拠点ごとに独立した電話システムを導入している場合、ある拠点のユーザは、別の拠点の人に電話をかける際に、内線番号だけでなく、完全な電話番号をダイヤルする必要があります。 ユーザーがサインインして、ネットワーク接続された別のロケーションにいるユーザーにメッセージを送信する際、内線番号でアドレス指定するメッセージを送信する際に入力する番号は、ロケーション間で番号計画が重複しているかどうかによって異なります。
ある場所のユーザ内線番号が別の場所のユーザ内線番号と重複する場合、各ユーザアカウントに代替内線番号を設定することで、各ユーザに固有の内線番号を提供できます。 各ユーザーの場合、ユーザーの完全な電話番号と同じ代替の内線番号として入力し、その代替内線番号が、別のロケーションのユーザーが使用する検索スペースのメンバーであるパーティション内にあることを確認します。 この設定が完了すると、ユーザがメッセージを送信するためにログインする際、メッセージの宛先として入力する番号は、電話をかける際に使用する番号と同じになります。
ネットワーク接続された複数の拠点間で番号計画が重複しない場合、つまり、ユーザの内線番号が拠点ごとに一意である場合、ユーザは別の拠点に関連付けられているユーザにメッセージを送信する際に内線番号を入力できます。 オプションとして、このような状況にあるユーザの利便性を高めるため、各ユーザアカウントに代替の内線番号を追加するように設定できます。これにより、ユーザは、直接電話をかけるための番号と、メッセージを送信するための番号という、2 つの異なる番号を覚えておく必要がなくなります。 ただし、代替の内線番号を設定しない場合は、別の場所に所属するユーザ宛てにメッセージを送信する際には、電話番号全体ではなく内線番号を使用するようにユーザに伝えるようにしてください。
代替の内線番号は、ネットワークでの使用以外にも、ユーザーの電話機で複数回線を表示する処理など、ほかの目的があることに注意します。
メッセージ送信者識別機能
ユーザーが別のユーザーに電話をかけ、その通話が着信したユーザーの挨拶に転送される場合、メッセージを残している相手がユーザーであることを Unity Connection が識別する機能を、メッセージ送信者識別機能と呼ばれます。 これは、Unity Connection が、発信者をユーザーとして識別できるためです。
-
Unity Connection は、発信者がメッセージを残す際に、着信先のユーザの内部挨拶を再生します。
-
Unity Connection は、受信者がメッセージを聞く際に、メッセージを残したユーザーの記録名を再生します。
-
Unity Connection では、受信者が返信を録音できます。
以下の 2 つの状況の違いに留意することが重要です。
-
ユーザは Unity Connection にサインインし、メッセージを録音して送信します。 この場合、ユーザーがサインインすると、メッセージ受信者がどのロケーションに所属しているかに関係なく、Unity Connection はそのメッセージがそのユーザーからのものであると識別できます。 この場合、電話システムは関与しておらず、受信側の電話は鳴りません。 代わりに、メッセージはネットワーク経由のメッセージ交換 (SMTP を使用) で送信されます。
-
あるユーザが別のユーザに電話をかけ、メッセージを残す。 この状況が、メッセージ送信者識別機能の基盤となっています。
Unity Connection の設置場所で識別済みユーザメッセージングが有効になっている限り、Unity Connection はローカルユーザとリモートユーザの両方を識別できます。 ただし、メッセージ送信者識別機能を両方のケースで機能させるためには、発信者がローカルユーザーなのかリモートユーザーなのかにかかわらず、通話の初期検索範囲を、発信側の内線番号に基づいた正確なユーザーを特定する検索スペースに設定する必要があります。
ユーザーが、その通話の初期検索範囲として設定されていた検索スペースのメンバーではないパーティションの内線番号から電話をかけた場合、その通話は、そのユーザーからかけられた通話として識別されません。 ユーザの内線番号が、この検索空間にも表示される別の分割の内線番号と重複する場合、その通話は、Unity Connection が分割を検索したときに、検索空間に表示された順に検索した最初のオブジェクトから発信されたものとして識別されます。
そのため、番号計画が複数の場所で重複している場合、ユーザが残したメッセージが、別のパーティションに属する同じ内線番号の別のユーザからのメッセージとして誤って識別される可能性があります。 通話の初期検索範囲は通話ルーティングルールに基づいて決定されるため、この状況を回避するには、以下の設定ガイドラインに従ってください。
-
ロケーションごとに個別の検索スペースを維持し、その検索スペースでは、そのロケーションのユーザーを含むパーティションが先頭に配置されるようにします。 （デフォルトでは、各 Unity Connection サーバは独自のデフォルトパーティションとデフォルト検索スペースを使用し、サーバがネットワークに接続されると、これらは他の場所に複製されます。）
-
各拠点において、他のすべての拠点に固有の転送通話ルーティングルールを設定します。これは、その拠点からの通話にのみ適用されるルーティングルール条件を指定することによって行います（たとえば、着信通話のポートまたは電話システムに基づく）。 そのロケーションのユーザーを含むパーティションが先頭に配置されている検索スペースを、通話の検索範囲として設定するようにルールを構成します。
フィードバック