サーバー間サインイン、転送およびライブ返信

はじめに

この章では、サイト内の Cisco Unity Connection 間、サイト間リンクがリンクしている別のサイト内の Unity Connection ロケーション間、および、サイト間リンクがリンクしているサイト内の Cisco Unity および Unity Connection ロケーション間で利用可能なサーバー間サインイン、転送、ライブ返信機能について説明します。 この章では、サーバー間機能の構成手順について説明します。

サーバー間サインイン、転送およびライブ返信の概要

レプリケーションのトラフィックを制限し、ディレクトリのサイズを管理しやすい状態に保つため、ユーザーのホームロケーションからほかのネットワーク接続されたロケーションへは、ユーザー情報のごく一部のみがレプリケートされます。 そのため、通話転送設定、挨拶メッセージ、その他のユーザー固有の詳細情報は、ユーザーのホームロケーションのみに保持されます。 別のロケーションに属するユーザー宛ての通話を、ロケーションが適切の処理するには、通話をそのユーザーのホームロケーションに転送する必要があります。 サーバー間機能の目的は、表 1 で示されているように、単一のサーバー環境と同じようなユーザーエクスペリエンスをネットワーク接続された環境でも設定することです。

表 1. サーバー間機能

機能

説明

サーバー間サインイン

サーバー間サインイン機能を使用すると、管理者は、別のロケーションに属するユーザーに、サインイン時に使用できる 1 つの電話番号を提供できるようになります。組織外から発信する際、ユーザーは、属するホームサーバーに関係なく、同じ番号に発信でき、サインインする該当するホームサーバーに転送されます。

サーバ間転送

サーバー間転送機能を使用すると、通話転送および発信したユーザーのスクリーニング設定に基づいて、自動応答からの通話、または別のロケーションのユーザーに転送されるあるロケーションのディレクトリハンドラからの通話を有効にできます。

サーバ間ライブ返信

サーバー間ライブ返信機能を使用すると、電話機でメッセージを再生しているユーザーは、別のロケーションに所属するユーザーからのメッセージに対し、そのユーザーへ転送して返信できます (通話転送および発信したユーザーのスクリーニング設定に従い)。

サーバ間機能はそれぞれ異なる機能ではあるものの、いずれも同じ基盤となる機能、すなわち強化された監視付き通話転送機能を利用している。

  1. サインイン、転送、またはライブ返信が実行されるロケーションでは、発信者を保留状態にした後、受信側ロケーション用のサーバー間ダイヤル文字列として指定された電話番号をダイヤルして、その受信側ロケーションに発信します。

  2. 受信側が応答すると、発信側はハンドオフ要求であることを示す一連の DTMF トーンを送信します。

  3. 受信側ロケーションには、一連の DTMF トーンで応答し、発信側ロケーションが、受信側ロケーションに通話を転送して、処理を任せます。

この時点では、機能は、通話が受信側ロケーションで発信された場合と同じです。

本章では、発信元ロケーションとは、他のロケーションを呼び出すサーバ（またはクラスタ）と定義する。 受信側ロケーションは、サーバー間通話に応答するサーバー (またはクラスタ) として定義されます。

サーバー間ダイヤル文字列は、ロケーション間では同期されません。 各発信側ロケーションは、各受信側ロケーションのダイヤル文字列で構成できます。 発信側ロケーションが、複数の電話機システム統合に向けて構成されている場合は、すべての電話機システム統合が受信側ロケーションに到達するために使用するダイヤル文字列を選択する必要があることに注意します。

クロスサーバサインイン、転送、ライブ返信に関する検索スペースの考慮事項

ユーザが自分のホームサーバではない Unity Connection 拠点のパイロット番号にダイヤルした場合、応答した拠点は、その拠点の通話管理プランに従って通話を処理します。 検索スペースは、通話と一致する最初のコールルーティングルールに割り当てられます。 後続の処理ステップごとに、呼び出しの検索範囲が変わる可能性があります。 Unity Connection は、通話が Attempt Sign-In 会話に到達した時点で通話に割り当てられた検索スペースを使用して、サインインを試行しているユーザーを特定します。ユーザーが、検索スペースのメンバーではないパーティションの内線番号から発信した場合、その通話は、そのユーザーからの発信された通話として認識されません。 ユーザーの内線番号が、この検索スペースにも表示される別のパーティションの内線番号と重複する場合、その通話は、検索スペース内に表示される順序でパーティションを検索した際に、Unity Connection が最初に見つけたオブジェクトからの通話として識別されます。 リモートユーザーからの着信サインイン通話を処理する各 Unity Connection ロケーションのダイレクトルーティングルールを確認して、ルールまたは、Attempt Sign-In 会話に通話を送信するその他の通話管理オブジェクトが設定した検索スペースを決定します。 リモートユーザを含むパーティションがこのサーチスペースの一部ではない場合、クロスサーバサインインは有効になっていても機能しません。

また、Unity Connection のある場所から別の Unity Connection の場所 (同じサイト内またはリモートサイト内) へのサーバ間呼び出しの場合、発信元の場所で呼び出しに適用される検索スペースと受信側の場所で適用される検索スペースが一致しないと、サーバ間サインインやサーバ間転送に問題が発生する可能性があることに注意してください。 発信元の場所の検索範囲では一致する結果が得られた場合でも、受信側の場所の別の検索範囲では一致が得られない可能性がある。 そのため、発信元と受信側の両方で同じ検索範囲が設定されていることを確認する必要があります。 たとえば、コールルーティングルールを使用すると、そのロケーションへの到達に使用されたサーバー間ダイヤル文字列に基づいて、受信側ロケーションのサーバー間通話を適切な検索スペースへ振り分けることができます。

サーバー間ライブ返信の場合は、ほかのライブ返信の試行と同様に、送信者がそのユーザーに対して構成された検索スペースのメンバーであるパーティションに属している場合のみ、Unity Connection ユーザーは、その送信者に発信できます。

サーバー間サインイン

サーバー間サインイン機能を使用すると、組織外から発信するユーザーは、そのユーザーがホームにしているサーバーに関係なく、同じ番号に発信できるようになります。また、このユーザーは、該当するホームサーバーに転送され、サインインできます。サーバー間サインインを有効にしない場合、ユーザーは、ホームサーバーの電話番号に発信してサインインする必要があります。

クロスサーバサインイン呼び出しの手順は以下のとおりです。

  1. ユーザーは、サーバー間サインイン向けに構成されたサーバーに発信します。 ユーザーは、この番号に発信されることで特定されるか、ID の入力が求められます。

  2. サーバーは、データベースの発信者 ID を検索することで、このアカウントが、ローカルサーバーをホームにしているのか、ネットワーク接続されたサーバーをホームにしているのかを判断します。

    • ユーザーアカウントが、ローカルサーバーをホームにしている場合、通常通りサインインできます。

    • ユーザーアカウントが別のサーバーをホームにしている場合、会話が設定されている場合は、「少々お待ちください」というプロンプトが再生され、ユーザーを保留にし、ユーザーが発信したポートと同じポートを使用してユーザーのホームサーバーに発信します。 ユーザーが、主要内線番号または代替内線番号から発信した場合、通常、「少々お待ちください」というプロンプトが、ユーザーが最初に聞くプロンプトになります。

      受信側サーバーが応答すると、発信側サーバーは、通話をサーバー間サインインとして特定する一連の DTMF トーンを送信します。

  3. 受信側ロケーションは、一連の DTMF トーンに応答します。

  4. 発信側ロケーションは、通話を受信側サーバーに引き渡して処理します。 受信側サーバーの会話によって、ユーザーパスワードが求められます。 この時点では、動作は、ユーザーが受信側サーバーに直接発信した場合と同様です。

この機能の利用目的は、組織外から電話をかけてくるユーザに限定されます。 サーバー間サインインは、内部通話をホームサーバーに転送しますが、多数のユーザーに対して転送を行うと、サーバーの負荷が増加します。 したがって、[メッセージ] ボタンまたは [ボイスメール短縮ダイヤル] ボタンを使用して、ユーザーのホームサーバーに直接発信できるように、ユーザーの電話機を常に構成しておきます。 ユーザアカウントをあるサーバから別のサーバに移行する場合は、それに応じてユーザの電話システム構成を更新してください。

ビデオ通話の場合は、2 つの Unity Connection ロケーションを、サイト間リンク、サイト内リンクまたは HTTPS ネットワークでリンクされている場合に、ある Unity Connection ロケーションのユーザーが、別の Unity Connection ロケーションにサインインしようとすると、通話は音声通話にダウングレードされます。

クロスサーバサインインを有効にするための前提条件

Cisco ボイスメール組織に Cisco Unityサーバーを含める場合、サーバー間サインイン向けの発信側ロケーションとして構成したネットワーク接続されたすべての Cisco Unity サーバーを、Cisco Unity サイトゲートウェイと同じ台やリングドメインとして構成する必要があります。 ダイヤルドメインは、Cisco Unity Administrator の [ネットワーク > プライマリロケーション > プロファイル] ページで設定します。

サーバー間サインインを有効にするためのタスクリスト

Unity Connection サイトを 1 つ構成する場合でも、Unity Connection サイトを 2 つ含む組織を構成する場合でも、Unity Connection サイトと Cisco Unity サイトを含む組織を構成する場合でも、基本的な手順は同じです。 次のタスクリストを使用して、サーバー間サインインを有効にします。 相互参照により、詳細な手順を参照できます。

  1. クロスサーバサインインにおいて、発信元となる場所と受信元となる場所を特定します。 多くの場合、1 つのロケーションは、組織外からすべてのユーザーが発信する際の発信側ロケーションとして指定され、ほかのすべてのロケーションは受信側ロケーションとして指定されますが、必ずしもそうである必要はありません。 単一の場所が、発信地と受信地の両方を兼ねる場合もある。

  2. 発信側ロケーションの場合、ロケーションが受信側ロケーションサーバーに到達するためにダイヤルする電話番号のリストを作成します。


    （注）  
    受信場所ごとに入力できるダイヤル文字列は 1 つだけです。 発信側ロケーションが、複数の電話機システム統合に向けて構成されている場合は、すべての電話機システム統合が受信側ロケーションに到達するために使用するダイヤル文字列が必要です。

  3. 各受信場所が、サーバ間ハンドオフ要求を処理できるように設定してください。

  4. Cisco Unity Connection ロケーションが、Cisco Unity サーバーからサーバー間ハンドオフ要求を受信する場合は、# から始まるサーバー間 DTMF シーケンスを許可するように Unity Connection ロケーションを構成します。 6-5 ページの「Cisco Unity ロケーションからのサーバー間 DTMF シーケンスを許可するように Unity Connection 受信側ロケーションを構成する」項を参照してください。

  5. 発信元ごとに、クロスサーバサインイン機能を有効にし、タスク 2 で作成したリストから受信先のパイロット番号を入力します 。

  6. クロスサーバサインイン機能をテストしてください。 6-8 ページの「サーバー間サインインをテストする」項を参照してください。

サーバー間ハンドオフ要求を許可する Unity Connection 受信側ロケーションを構成する

デフォルトでは、各 Unity Connection サーバは、サーバ間ハンドオフ要求を無視するように設定されています。 サーバー間機能を有効にするには、受信側ロケーションが要求を許可するように構成し、そのロケーションが、着信サーバー間通話を通話ハンドラにルーティングすることを確認する必要があります。 次の 2 つの手順を実行して、各受信側 Unity Connection ロケーションがハンドオフを許可するように構成します。 (そうすることで、そのロケーションがすべての種類のサインイン、転送、ライブ返信を受信できるようになります)。

Unity Connection の受信場所を設定して、サーバ間ハンドオフ要求を受け入れるようにする

手順

ステップ 1

Cisco Unity Connection Administration のそのロケーションをホームとしているユーザーにサーバー間ハンドオフを許可するロケーション (受信側ロケーション) で、[システム設定] > [詳細設定][会話] の順に選択します。

ステップ 2

[サーバー間ハンドオフ要求に応答する] チェックボックスをオンにします。

ステップ 3

残りのすべての Unity Connection 受信場所についても、この手順を繰り返してください。

通話ルーティングルールが通話をコールハンドラーの挨拶にルーティングするように設定されていることを確認します

手順

ステップ 1

Cisco Unity Connection Administration のサーバー間ハンドオフを許可するロケーションで、[通話管理]、 > [コールルーティング]、[直接ルーティングルール] の順に選択します。

ステップ 2

発信元からの着信クロスサーバ通話に適用されるルーティングルールの表示名を選択してください。

ステップ 3

ルールに一致する通話がコールハンドラーにルーティングされていることを確認してください。

ステップ 4

残りのすべての Unity Connection 受信側ロケーションについても同じ手順を繰り返します。

受信側の Cisco Unity ロケーションが Opening Greeting に通話をルーティングすることを検証する

サーバー間ハンドオフ要求を承認するには、各 Cisco Unity サーバーが、通話を Opening Greeting 通話ハンドラにルーティングするように構成する必要があります。 （これは Cisco Unity を最初にインストールしたときのデフォルト設定です。）


（注）  
フェイルオーバーシステムの場合は、プライマリサーバとセカンダリサーバの両方でこの手順を実行してください。

以下の手順を実行して、コールルーティングルールが Opening Greeting 通話ハンドラに通話をルーティングするように設定されていることを確認します。

手順

ステップ 1

Cisco Unity Administrator のサーバー間サインインハンドオフを許可するロケーションで、[コールルーティング] > > [ダイレクトコール] の順に選択します。

ステップ 2

発信側ロケーションからのサーバー間受信通話が、Opening Greeting にルーティングされていることを確認します。

デフォルトの通話ハンドラルーティングルール (削除または変更不可) は、Opening Greeting に通話を送信します。 したがって、ルーティングルールを追加していない場合、サーバーは、既にサーバー間通話を正しく処理するように設定されています。

ステップ 3

残りのすべての Cisco Unity 受信側ロケーションについても同じ手順を繰り返します。

Cisco Unity ロケーションからサーバー間 DTMF シーケンスを許可するように Unity Connection 受信側ロケーションを構成する

発信側 Cisco Unity ロケーションが受信側ロケーションに送信する一連の DTMF トーンは、# (シャープ) で始まります。 デフォルトでは、Unity Connection Opening Greeting 通話ハンドラやその他の通話ハンドラは、# キーのあとに続くその他の発信者入力を無視するように構成されています。 このような構成では、サーバ間のハンドオフはすべて失敗します。

Unity Connection の受信側ロケーションで動作を変更して、サーバー間のハンドオフを正常に実行できるようにするには、いくつかの方法があります。

  • Opening Greeting (または、ルーティングルール構成に基づいてサーバー間ハンドオフを受信するその他の既存通話ハンドラ) を変更し、# キーを入力し、追加の入力を受け付けるようにします。

  • サーバー間通話の処理に特化した新しい通話ハンドラおよび直接コールルーティングルールを作成します。 新しいコールハンドラは、# キーの後にさらに入力を受け付ける必要があります。 直接コールルーティングルールは、サーバー間通話に適用される条件に基づいて新しい通話ハンドラに通話をルーティングするはずです (たとえば、発信側 Cisco Unity ロケーションの発信番号または発信側ロケーションが、着信側ロケーションに到達するためにダイヤルするサーバー間ダイヤル文字列)。 （他の通話がルーティングルールに一致しないようにするには、サーバ間通話に固有の条件を選択してください。）

各 Unity Connection 受信側ロケーションで次の手順を実行して、Opening Greeting を構成するか、その他の通話ハンドラが、# キーの後にその他の入力をできるようにし、必要に応じて、新しい直接コールルーティングルールを作成します。

手順

手順

ステップ 1

サーバー間サインインハンドオフを許可するロケーションの Cisco Unity Connection Administration にサインインします。 [通話管理]、[システム通話ハンドラ] の順に選択します。

ステップ 2

[通話ハンドラを検索] ページで、以下のいずれかを実行します。

  • Opening Greeting の 表示名または変更するその他の通話ハンドラを選択します。 手順 6 にスキップします。

  • [新規追加] を選択して、サーバー間通話専用の新しい通話ハンドラ作成します。 手順 3 を参照してください。

ステップ 3

「新しいコールハンドラー」ページで、必要に応じて基本設定を入力します。 （各項目の詳細については、ヘルプ> このページをご覧ください。）

ステップ 4

通話ハンドラが、サーバー間 DTMF シーケンスを許可するように設定する:

  1. 編集メニューで 呼び出し元入力を選択します。

  2. [発信者入力] ページで、# を選択し、[そのほかの入力を無視] チェックボックスをオフにします。

  3. 保存を選択します。

ステップ 5

Cisco Unity サーバーから通話ハンドラに通話を送信するための触接コールルーティングルールを作成する:

  1. [通話管理] > [コールルーティング]、[直接ルーティングルール] の順に選択します。

  2. [直接ルーティングルール] ページで、[新規追加] を選択します。

  3. [新しい直接ルール] ページの [表示名] フィールドに新しいルールの名前を入力し、[保存] を選択します。

  4. [直接ルールを編集] ページの [通話を送信] フィールドで、[通話ハンドラ]、手順 2 で追加した通話ハンドラの名前の順に選択します。

  5. 保存を選択します。

  6. [ルーティングルール条件] で、[新規追加] を選択します。

  7. Cisco Unity サーバーからのサーバー間通話と一致するように、ルーティングルールの条件を構成します。 たとえば、ユーザーからの通話に応答する Cisco Unity ポートの電話番号と一致する [発信番号] フィールドを使用します。

  8. 保存を選択します。

  9. [編集] メニューで、[直接ルーティングルールを編集] を選択します。

  10. サーバー間通話と一致させる必要があるその他の番号や番号のパターンに対して、f. から i. を繰り返します。

ステップ 6

残りのすべての Unity Connection 受信場所についても、この手順を繰り返してください。

サーバー間サインイン要求を実行するために Unity Connection 発信側ロケーションを構成する

デフォルトでは、Unity Connection ロケーションは、その他のロケーションをホームにしているユーザーに対してサーバー間サインインを試行しません。

手順

ステップ 1

Cisco Unity Connection Administration のリモートユーザーからのサインイン通話を処理するロケーション (発信側ロケーション) で、[ネットワーク]、[ロケーション] の順に選択します。

ステップ 2

[ロケーションを検索] ページで、このロケーション (受信側ロケーション) をホームにしているユーザーのサーバー間サインイン要求を許可するリモートロケーションの表示名を選択します。

ステップ 3

受信側ロケーションの [ロケーションを編集] ページで、受信側ロケーションに対してサーバー間機能を有効にします。

  1. リモートロケーションに対してサーバー間サインインを有効にするには、[このリモートロケーションに対してサーバー間サインインを許可する] チェックボックスをオンにします。

  2. ハンドオフを実行する際 (ホームサーバーのパイロット番号など)、受信側ロケーションの発信にこのロケーションが使用するダイヤル文字列を入力します。

    （注）  

     
    受信場所ごとに入力できるダイヤル文字列は 1 つだけです。 発信側ロケーションが、複数の電話機システム統合に向けて構成されている場合は、すべての電話機システム統合が受信側ロケーションに到達するために使用するダイヤル文字列を入力します。

ステップ 4

この場所からのサーバ間サインインハンドオフを受け入れる各受信場所を設定するには、 手順 2 と 手順 3 を繰り返します。

ヒント

 
ページの変更を保存したら、 次へ ボタンと 前へ ボタンを使用して、組織内の各場所をすばやく移動できます。

ステップ 5

残りのすべての Unity Connection 発信元拠点に対して、この手順を繰り返してください。

サーバー間サインイン要求を実行するために Cisco Unity 発信側ロケーションを構成する

デフォルトでは、Cisco Unity 発信側ロケーションは、その他のロケーションをホームにしているユーザーに対してサーバー間サインインを試行しません。 次の手順を実行して、Cisco Unity 発信側ロケーションでサーバー間サインインを有効にします。


（注）  
システムがフェイルオーバーを使用している場合は、プライマリサーバとセカンダリサーバの両方でこの手順を実行してください。ネットワーク > ダイヤルドメインオプションページのほとんどの設定はレジストリに保存されているためです。 （レジストリ設定はセカンダリサーバには複製されません。）
手順

ステップ 1

Cisco Unity Administrator で、 Network > を展開し、 > Dialing Domain Options を選択します。

（注）  

 

システムに、[ダイヤルリングドメインオプション] リンクが無い場合は、まず Cisco Unity Administrator の [プライマリロケーション設定] ページでダイヤルリングドメインを構成する必要があります。

ステップ 2

[サーバー間ログオン] セクションで、[サブスクライバが同じ番号にダイヤルしてCisco Unityにログオンする] チェックボックスをオンにします。

ステップ 3

[サーバー間ログオン向けパイロット番号、転送およびライブ返信] セクションにあるテーブルに表示されている各サーバーの [ダイヤル文字列] フィールドにパイロット番号を入力します。 （入力したパイロット番号は、Cisco Unity サーバ上の SQL Server データベース UnityDb に保存されることに注意してください。） したがって、システムがフェイルオーバーを使用している場合、パイロット番号はセカンダリサーバに複製されます。

ステップ 4

[サーバー間ログオン、転送、ライブ返信中にプロンプトを再生して、発信者に何かが起こっていることを知らせる] チェックボックスをオンにします。 「少々お待ちください」というプロンプトを再生するかどうかは任意ですが、チェックボックスはオンにする必要があります。これは、受信側サーバーが、ユーザーにパスワードの入力を求めるまでのサーバー間処理に数秒を要するためです。

ステップ 5

保存を選択します。

ステップ 6

残りのすべての Cisco Unity 発信拠点に対して、この手順を繰り返してください。

サーバー間サインインをテストする

ユーザがこの機能を使用できるようにする前に、サーバ間サインインのテストを実施する必要があります。 フェールオーバーシステムの場合、まずプライマリ宛先サーバーがサーバー間通話に応答するかどうかをテストします。 次に、宛先サーバを手動でフェイルオーバーして、セカンダリサーバがサーバ間呼び出しに応答することを確認します。 宛先サーバがフェイルオーバー用に適切に構成されていれば、プライマリサーバが利用できない場合、セカンダリサーバがサーバ間呼び出しに応答するはずです。

クロスサーバサインインをテストするには、以下の手順を実行してください。

手順

ステップ 1

テスト目的で、各宛先サーバーで新しいユーザーアカウントを作成します (または既存のアカウントを使用します)。 ユーザーアカウント情報が、テストするすべてのサーバーで複製されていることを確認します。 ユーザーデータのレプリケートにかかる時間は、ネットワーク構成とレプリケーション スケジュールによって異なります。

ステップ 2

各ユーザーアカウントの場合は、サーバー間サインイン向けに構成されたサーバーのパイロット番号に発信し、サインインを試行します。以下の点を確認します。

  • (構成されている場合) 「少々お待ちください」というメッセージが再生されます。

  • 正常にログインしています。

サーバ間転送

サーバー間転送とは、通話の制御を自動応答またはディレクトリハンドラから着信ユーザーのホームサーバーに渡す特殊な監視型転送の一種です。

  1. 発信者は、音声テキストアプリケーションが設定されている Cisco Unity または Unity Connection サーバーに電話をかけます。

  2. 発信者は以下のいずれかを実行します。

  • 通話ハンドラ (Opening Greeting など) え、別のサーバーのユーザーの内線番号を入力します。

  • ディレクトリハンドラで、別のサーバーのユーザー名にスペルを入力します。

  1. 通話を処理しているサーバーは、発信者を保留にし、ユーザーのホームサーバーを呼び出します。

  2. 受信側のサーバが応答すると、発信側のサーバは、その通話がサーバ間転送であることを示す一連の DTMF トーンを送信します。

  3. 受信側サーバーは、一連の DTMF トーンに応答します。

  4. 発信元サーバは、処理のために呼び出しを受信側サーバに引き継ぎます。 この時点では、動作は、発信者が受信側サーバーの自動応答システムまたはディレクトリハンドラに直接発信した場合と同様の動作になります。

  5. ビデオ通話の場合、2 つの Unity Connection ロケーションは、サイト間リンク、サイト内リンクまたは HTTPS ネットワークでリンクされ、ある Unity Connection ロケーションのユーザーが、サーバー間転送を試行した場合、その通話は、監視型転送時に音声通話としてダウングレードされます。

  6. ビデオ通話の場合、2 つの Unity Connection ロケーションは、サイト間リンク、サイト内リンクまたは HTTPS ネットワークでリンクされ、ある Unity Connection ロケーションのユーザーが、サーバー間転送を試行した場合、その通話は、Release to Switch 時にビデオ通話として確立されます。

サーバ間転送が設定されている場合、ユーザ通話転送、通話スクリーニング、通話保留、およびアナウンス機能が利用可能になります。

サーバ間転送を有効にするための前提条件

Cisco ボイスメール組織にネットワーク接続された Cisco Unity サーバーが含まれている場合:

  • クロスサーバ転送の発信元として設定するすべての Cisco Unity サーバは、Cisco Unity サイトゲートウェイと同じダイヤルドメインに属するように設定する必要があります。 ダイヤルドメインは、Cisco Unity Administrator の [ネットワーク > プライマリロケーション > プロファイル] ページで設定します。

  • 各 Cisco Unity サーバーのアドレッシング、ディレクトリハンドラ、および自動応答の検索範囲は、ダイヤルリングドメインまたはグローバルディレクトリに設定する必要があります。 詳細については、該当する『Cisco Unity 向けネットワークガイド』の「デジタルネットワーク」章の「アドレッシング、ディレクトリハンドラおよび自動応答検索範囲を設定する」項を参照してください (入手先: http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_feature_guides_list.html)。

サーバ間転送を有効にするためのタスクリスト

Unity Connection サイトを 1 つ構成する場合でも、2 つの Unity Connection サイトを含む組織を構成する場合でも、あるいは、Unity Connection サイトと Cisco Unity サイトを含む組織を構成する場合でも、適用される基本的なタスクは同じです。 次のタスクリストを使用して、サーバー間転送を有効にします。 相互参照により、詳細な手順を参照できます。

  1. 各ロケーションが、発信側ロケーションなのか、着信側ロケーションなのか、その両方なのかを判断します。

  2. 発信側ロケーションの場合、ロケーションが受信側ロケーションサーバーに到達するためにダイヤルする電話番号のリストを作成します。


    （注）  
    受信場所ごとに入力できるダイヤル文字列は 1 つだけです。 発信側ロケーションが、複数の電話機システム統合に向けて構成されている場合は、すべての電話機システム統合が受信側ロケーションに到達するために使用するダイヤル文字列が必要です。

  3. 各受信場所が、サーバ間ハンドオフ要求を処理できるように設定してください。

  4. Unity Connection ロケーションが、Cisco Unity サーバーからサーバー間ハンドオフ要求を受信する場合は、# から始まるサーバー間 DTMF シーケンスを許可するように Unity Connection ロケーションを構成します。 6-4 ページの「サーバー間ハンドオフ要求を許可するように Unity Connection 受信側ロケーションを構成する」項を参照してください。

  5. 各発信拠点について、クロスサーバ転送機能を有効にし、タスク 2 で作成したリストから受信拠点のパイロット番号を入力します 。

  6. サーバ間転送機能をテストしてください。 6-14 ページの「サーバー間転送をテストする」項を参照してください。

Cisco Unity Connection への通話転送中のクロスサーバ転送の設定

Cisco Unity Connection への通話転送中にサーバ間転送を設定するには、以下の手順を実行してください。

手順

ステップ 1

通話転送中のサーバー間転送の構成を表示するには、次のコマンドを実行します。

run cuc dbquery unitydirdb select fullname,name,parentid,valuebool,value from vw_Configuration where name like 'HandoffForwardRemoteForward'

コマンドの実行結果が設定済みテーブルエントリであれば、その機能は Cisco Unity Connection で設定されていることを意味します。 そうでない場合は、 ステップ 2 に進んで設定エントリを作成してください。

構成されたテーブルエントリで、「valuebool」パラメータの値を確認します。 Valuebool が 1 の場合、Cisco Unity Connection でその機能が有効になっていることを意味します。 そうでない場合は、手順 3 に進み、機能を有効にします。

ステップ 2

以下のコマンドを使用して設定エントリを作成します。


run cuc dbquery unitydirdb execute procedure csp_ConfigurationCreate(pName='HandoffForwardRemoteForward'::lvarchar, pParentFullName='System.Conversations.CrossBox'::lvarchar, pType=11, pValueBool=0, pRequiresRestart=1)

ステップ 3

以下のコマンドを使用して、通話転送時のサーバー間転送を有効にします。 


run cuc dbquery unitydirdb execute procedure csp_ConfigurationModify(pName='HandoffForwardRemoteForward'::lvarchar, pParentFullName='System.Conversations.CrossBox'::lvarchar, pValueBool=1)

ステップ 4

以下のコマンドを使用して、通話転送時のサーバー間転送を無効にします。 


run cuc dbquery unitydirdb execute procedure csp_ConfigurationModify(pName='HandoffForwardRemoteForward'::lvarchar, pParentFullName='System.Conversations.CrossBox'::lvarchar, pValueBool=0)

（注）  

 

  • クラスター環境の場合は、パブリッシャーサーバ上でのみコマンドを実行し、クラスター全体でデータベースのレプリケーションが正常に動作していることを確認してください。

  • 上記コマンドの実行後、サービスの再起動は不要です。

（注）  

 
Cisco Unity Connection Administration を通じて、通話転送時のサーバ間転送を有効にすることもできます。 機能を有効にするには、[システム設定] > [詳細] > [会話] の順に選択し、Cisco Unity Connection Administration の [会話構成] ページで、[通話転送中のCisco Unityサーバー間ハンドオフ] チェックボックスをオンにします。

サーバー間ハンドオフ要求を許可する Unity Connection 受信側ロケーションを構成する

デフォルトでは、各 Unity Connection サーバは、サーバ間ハンドオフ要求を無視するように設定されています。 サーバー間機能を有効にするには、受信側ロケーションが要求を許可するように構成し、そのロケーションが、着信通話を通話ハンドラにルーティングすることを確認する必要があります。

次の手順を実行して、Unity Connection 受信側ロケーションを構成します。

手順

ステップ 1

クロスサーバハンドオフを受け入れるロケーション（受信ロケーション）の Cisco Unity Connection Administration にログインします。 [システム設定] > [詳細設定][会話] の順に選択します。

ステップ 2

「サーバ間ハンドオフ要求に応答する」チェックボックスをオンにします。

ステップ 3

残りのすべての Unity Connection 受信場所についても、この手順を繰り返してください。

コールルーティングルールが、通話ハンドラのグリーティングに通話をルーティングするように設定されていることを確認する

手順

ステップ 1

サーバー間ハンドオフを許可するロケーションの Cisco Unity Connection Administration にサインインします。 [通話管理] > > [コールルーティング] > [直接ルーティングルール] の順に選択します。

ステップ 2

発信側ロケーションからの受信サーバー間通話に適用するルーティングルールの表示名を選択します。

ステップ 3

ルールに一致する通話がコールハンドラーにルーティングされていることを確認してください。

ステップ 4

残りのすべての Unity Connection 受信場所についても、この手順を繰り返してください。

受信側の Cisco Unity ロケーションが Opening Greeting に通話をルーティングすることを検証する

サーバー間ハンドオフ要求を承認するには、各 Cisco Unity サーバーが、通話を Opening Greeting 通話ハンドラにルーティングするように構成する必要があります。 (これは Cisco Unity の初回インストール時のデフォルト設定です)。 受信側の Cisco Unity サーバそれぞれで以下の手順を実行し、通話ルーティングルールがハンドオフを受け入れるように正しく設定されていることを確認してください。


（注）  

フェイルオーバーシステムの場合は、プライマリサーバとセカンダリサーバの両方でこの手順を実行してください。

手順

ステップ 1

スーパーソフトな間転送ハンドオフを許可するロケーションの Cisco Unity Administrator にサインインします。 [コールルーティング] > [ダイレクトコール] の順に選択します。

ステップ 2

発信側ロケーションからのサーバー間受信通話が、Opening Greeting にルーティングされていることを確認します。

デフォルトの通話ハンドラルーティングルール (削除または変更不可) は、Opening Greeting に通話を送信します。 したがって、ルーティングルールを追加していない場合、サーバーは、既にサーバー間通話を正しく処理するように設定されています。

ステップ 3

残りのすべての Cisco Unity 受信側ロケーションについても同じ手順を繰り返します。

Cisco Unity ロケーションからのクロスサーバ DTMF シーケンスを許可するように Unity Connection 受信ロケーションを設定する

発信側 Cisco Unity ロケーションが受信側ロケーションに送信する一連の DTMF トーンは、# (シャープ) で始まります。 デフォルトでは、Unity Connection の起動時の挨拶やその他のコールハンドラーは、# キーの後に続く発信者からの追加入力を無視するように設定されています。 このような構成では、サーバ間のハンドオフはすべて失敗します。

Unity Connection の受信側ロケーションで動作を変更して、サーバー間のハンドオフを正常に実行できるようにするには、いくつかの方法があります。

  • 追加の入力を許可するように、Opening Greeting (または、ルーティングルール構成に基づいてサーバー間ハンドオフを受信するその他の既存通話ハンドラ) を変更します。

  • サーバー間通話の処理に特化した新しい通話ハンドラおよび直接コールルーティングルールを作成します。 直接コールルーティングルールは、サーバー間通話に適用される条件に基づいて新しい通話ハンドラに通話をルーティングするはずです (たとえば、発信側 Cisco Unity ロケーションの発信番号または発信側ロケーションが、着信側ロケーションに到達するためにダイヤルするサーバー間ダイヤル文字列)。 (その他の通話が、ルーティングルールと一致しないようにするには、サーバー間通話に固有の条件を選択します)。

各 Unity Connection 受信側ロケーションで次の手順を実行して、Opening Greeting を構成するか、その他の通話ハンドラが、# キーの後にその他の入力をできるようにし、必要に応じて、新しい直接コールルーティングルールを作成します。

手順

ステップ 1

サーバー間転送ハンドオフを許可するロケーションの Cisco Unity Connection Administration にサインインします。 コール管理 を展開し、 システムコールハンドラーを選択します。

ステップ 2

[通話ハンドラ] ページで、Opening Greeting 通話ハンドラまたは修正するその他の通話ハンドラの表示名を選択するか、[新規追加] を選択して、サーバー間通話用の新しい通話ハンドラを作成します。

ステップ 3

手順 2 で新しい通話ハンドラを作成しなかった場合は、手順 6 に進みます。 手順 2 で新しい通話ハンドラを [新しい通話ハンドラ] ページで作成した場合は、必要に応じて、基本設定を入力します。 （フィールド情報については、ヘルプメニューから「このページ」を選択してください。）

ステップ 4

次の手順を実行して、サーバー間 DTMF シーケンスを許可する通話ハンドラを構成します。

  1. 編集メニューで 呼び出し元入力を選択します。

  2. [発信者入力] ページで、[#] を選択します。

  3. 「追加入力を無視する」チェックボックスのチェックを外してください。

  4. 保存を選択します。

ステップ 5

手順 2 で新しい通話ハンドラを作成した場合は、新しい直接通話中着信ルーティングルールを作成して、通話を Cisco Unity サーバーから通話ハンドラに送信して処理します。

  1. [通話管理] > [コールルーティング] > [直接ルーティングルール] の順に選択します。

  2. [直接ルーティングルール] ページで、[新規追加] を選択します。

  3. [新規直接ルール] ページの [表示名] フィールドに新しいルールの名前を入力します。

  4. 保存を選択します。

  5. [直接ルールを編集] ページで、通話送信先に対して、[通話ハンドラ] を選択したら、手順 2 で追加した通話ハンドラの名前を選択します。

  6. 保存を選択します。

  7. [ルーティングルール条件] で、[新規追加] を選択します。

  8. Cisco Unity サーバーからのサーバー間通話と一致するように、ルーティングルールの条件を構成します。 たとえば、ユーザーからの通話に応答する Cisco Unity ポートの電話番号と一致する [発信番号] フィールドを使用します。

  9. 保存を選択します。

  10. [編集] メニューで、[直接ルーティングルールを編集] を選択します。

  11. サーバー間通話と一致させる必要があるその他の番号や番号のパターンに対して、g. から j. を繰り返します。

ステップ 6

残りのすべての Unity Connection 受信場所についても、この手順を繰り返してください。

クロスサーバ転送リクエストを実行するための Unity Connection 発信元ロケーションの設定

デフォルトでは、Unity Connection ロケーションはサーバー間転送の実行を試行しません。 Unity Connection でサーバー間転送を有効にすると、サーバー間ライブ返信が自動で有効になることに注意します。 次の手順を実行して、Unity Connection の発信側ロケーションでサーバー間転送とライブ返信を有効にします。

次の手順を実行して、Unity Connection 発信側ロケーションが、サーバー間転送とライブ返信ハンドオフ要求を実行できるように構成します。

手順

ステップ 1

Cisco Unity Connection Administration のリモートユーザーに通話を転送するロケーション (発信側ロケーション) で、[ネットワーク]、[ロケーション] の順に選択します。

ステップ 2

[検索ロケーション] ページで、このロケーションがホームであるユーザーに対してサーバー間転送ハンドオフが許可されているリモートロケーションの [表示名] を選択します。

ステップ 3

受信側ロケーションに関する [ロケーションを編集] ページで、以下を実行して、この受信側ロケーションに対してサーバー間機能を有効にします。

  1. リモートロケーションに対するサーバー間転送とライブ返信を有効にするには、[このリモートロケーションに対してサーバー間転送を許可する] チェックボックスをオンにします。

  2. ハンドオフを行う際に、受信側ロケーションに発信するためにこのロケーションが使用するダイヤル番号を入力します (たとえば、受信側ロケーションのパイロット番号)。

    （注）  

     
    受信場所ごとに入力できるダイヤル文字列は 1 つだけです。 発信側ロケーションが、複数の電話機システム統合に向けて構成されている場合は、すべての電話機システム統合が受信側ロケーションに到達するために使用するダイヤル文字列を入力します。

ステップ 4

この場所からサーバ間転送ハンドオフを受け入れる受信場所ごとに、 ステップ 2 と ステップ 3 を繰り返します。

ヒント

 
ページで変更を保存したら、[次へ] ボタンと [前へ] ボタンを使用して、組織内の各ロケーションを素早く移動します。

ステップ 5

残りのすべての Unity Connection 発信元拠点に対して、この手順を繰り返してください。

サーバー間転送要求を実行するために Cisco Unity 発信側ロケーションを構成する

デフォルトでは、Cisco Unity の発信元ロケーションは、他のロケーションへのサーバ間転送を試みません。 Cisco Unity の発信元拠点すべてでサーバ間転送を有効にするには、以下の手順を実行してください。


（注）  
システムがフェールオーバーを使用している場合は、プライマリサーバーとセカンダリサーバーの両方で以下の手順を実行します。これは、[ネットワーク] > [ダイヤルリングドメインオプション] ページのほとんどの設定は、レジストリに保存されているためです。 （レジストリ設定はセカンダリサーバには複製されません。）
手順

ステップ 1

Cisco Unity Administrator で、[ネットワーク]、 > [ダイヤルリングドメインオプション] ページの順に選択します。

（注）  

 

システムに、[ダイヤルリングドメインオプション] リンクが無い場合は、Cisco Unity Administrator の [プライマリロケーション設定] ページでダイヤルリングドメインを構成する必要があります。

ステップ 2

[サーバー間転送: 発信側サブスクライバのCisco Unityサーバーに制御を渡す] チェックボックスをオンにします。 （電話システムへの通話の解放を選択すると、このサーバから発信されるサーバ間転送が無効になります。） ユーザーのホームサーバーに通話を転送する代わりに、Cisco Unityは、ユーザーに対して構成されたサーバー間転送用内線番号向けのリリース転送を試行します。 Unity Connection ユーザーで、ユーザー向けのサーバー間転送内線番号が構成されていない場合は、エラーになります)。

ステップ 3

[サーバー間ログオン向けパイロット番号、転送およびライブ返信] セクションにあるテーブルに表示されている各サーバーの [ダイヤル文字列] フィールドにパイロット番号を入力します。 (入力したパイロット番号は、Cisco Unity サーバーの SQL Server database UnityDb に保存されることに注意します)。 したがって、システムがフェイルオーバーを使用している場合、パイロット番号はセカンダリサーバに複製されます。

ステップ 4

[サーバー間ログオン、転送、ライブ返信中にプロンプトを再生して、発信者に何かが起こっていることを知らせる] チェックボックスをオンにします。 「少々お待ちください」という音声ガイダンスを再生するかどうかは任意ですが、発信者が転送されるまでにサーバ間の処理に数秒かかる場合があるため、チェックボックスをオンにすることをお勧めします。

ステップ 5

保存を選択します。

ステップ 6

残りのすべての Cisco Unity 発信拠点に対して、この手順を繰り返してください。

サーバー間転送をテストする

発信者がこの機能を使用できるようにする前に、サーバー間転送をテストする必要があります。 フェールオーバーシステムの場合、まずプライマリ宛先サーバーがサーバー間通話に応答するかどうかをテストします。 次に、宛先サーバーを手動でフェールオーバーして、セカンダリサーバーがサーバー間通話に応答することを確認します。 宛先サーバーがフェールオーバーに向けて適切に構成されていれば、プライマリサーバーが利用できない場合、セカンダリサーバーがサーバー間通話に応答するはずです。

サーバ間転送をテストするには、以下の手順を実行してください。

手順

ステップ 1

テスト目的で、各宛先サーバーで新しいユーザーアカウントを作成します (または既存のアカウントを使用します)。 ユーザーアカウント情報が、テストするすべてのサーバーで複製されていることを確認します。 ユーザデータの複製にかかる時間は、ネットワーク構成と複製スケジュールによって異なります。

ステップ 2

各ユーザーアカウントで、サーバー間転送向けに構成されたサーバーのパイロット番号を発信し、最初のメッセージでユーザーの内線番号を入力します。 以下の点を確認します。

  • (構成されている場合) 「少々お待ちください」というメッセージが再生されます。

  • 通話は、着信先のユーザの通話転送設定に応じて、ユーザの電話または応答メッセージに転送されます。

サーバー間ライブ返信

ライブ返信を有効にすると、電話機でメッセージを聞いているユーザーは、ユーザーに転送することで別のユーザーからのメッセージに返信できるようになります。 ユーザーがライブ返信を使用できるかどうかは、サービスのクラスによって制御されることに注意します。

サーバー間ライブ返信が有効になっている場合:

  1. 別のネットワーク接続されたロケーションからのメッセージを聞いた後、メッセージ受信者は、メッセージを残したユーザーに電話をかけることができます。

    特定したサブスクライバメッセージ (ISM) が、メッセージを録音したロケーションで無効になっている場合、サーバー間ライブ返信オプションは、サインインし、自分のメールボックスからメールを宛て先指定して送信したユーザーが送信したメッセージのみに使用できます。

  2. 発信元側はユーザを保留にし、データベースで内線番号を検索して、応答相手のユーザが同じサーバ上にいるか、別のネットワーク上の場所にいるかを判断します。 ユーザが同じサーバ上にいる場合は、処理は通常どおり進行します。

    ただし、返信先のユーザーが別のロケーションに所属している場合は、発信側ロケーションから該当する受信側ロケーションに対して発信が行われます。

  3. 受信側ロケーションが応答すると、発信側ロケーションが通話をサーバー間ライブ返信として認識する一連の DTMF トーンを送信します。

  4. 受信側は、一連の DTMF トーンで応答する。

  5. 発信側ロケーションは、通話を受信側ロケーションに引き渡して処理します。

前提条件: サーバー間ライブ返信を有効にする

  • ユーザーは、ユーザー間のライブ返信が有効になっているサービスのクラスに属している必要があります。 Cisco Unity Connection ユーザーの場合、ユーザー間のライブ返信を有効にするには、Cisco Unity Connection Administration で、[サービスのクラス] > [サービスのクラスを編集] ページの順に選択し、[ユーザーがその他のユーザーからのメッセージに発信することで返信できるようにする] チェックボックスをオンにします。

サーバー間ライブ返信の有効化に関するタスク一覧


（注）  
Unity Connection では、サーバー間転送が有効な場合、サーバー間ライブ返信も自動でサポートされます (サービスのクラスで許可されているユーザーの場合)。 以前に、サーバー間転送に対して発信側ロケーションまたは着信側ロケーションとして Unity Connection ロケーションを構成した場合、ロケーションも、サーバー間ライブ返信要求を送受信します。

次のタスクを実行して、Cisco Unity と Unity Connection サイトでサーバー間ライブ返信を有効にするか、Unity Connection ロケーション (1 つのサイトまたは 2 つの Unity Connection サイトのいずれか) 間でサーバー間転送とサーバー間ライブ返信を有効にします。 相互参照により、詳細な手順を参照できます。

  1. 各ロケーションが、発信側ロケーションなのか、着信側ロケーションなのか、その両方なのかを判断します。

  2. 発信側ロケーションの場合、ロケーションが受信側ロケーションサーバーに到達するためにダイヤルする電話番号のリストを作成します。


    （注）  
    受信場所ごとに入力できるダイヤル文字列は 1 つだけです。 発信側ロケーションが、複数の電話機システム統合に向けて構成されている場合は、すべての電話機システム統合が受信側ロケーションに到達するために使用するダイヤル文字列が必要です。

  3. 各受信場所が、サーバ間ハンドオフ要求を処理できるように設定してください。

  4. Unity Connection ロケーションが、Cisco Unity サーバーからサーバー間ハンドオフ要求を受信する場合は、# から始まるサーバー間 DTMF シーケンスを許可するように Unity Connection ロケーションを構成します。 6-7 ページの「Unity Connection 発信側ロケーションがサーバー間サインイン要求を実行するように構成する」項を参照してください。

  5. 各発信側ロケーションに対して、該当するサーバー間機能を有効にし、タスク 2 で作成した受信側ロケーションのパイロット番号を入力します。

  6. サーバー間ライブ返信機能をテストします。 6-8 ページの「サーバ間サインインのテスト」セクションを参照してください 。

手順: サーバー間ライブ返信を有効にする

サーバー間ハンドオフ要求を許可する Unity Connection 受信側ロケーションを構成する

デフォルトでは、各 Unity Connection サーバは、サーバ間ハンドオフ要求を無視するように設定されています。 サーバー間機能を有効にするには、受信側ロケーションが要求を許可するように構成し、そのロケーションが、着信通話を通話ハンドラにルーティングすることを確認する必要があります。

手順

ステップ 1

Cisco Unity Connection Administration のそのロケーションをホームとしているユーザーにサーバー間ハンドオフを許可するロケーション (受信側ロケーション) で、[システム設定] > [詳細設定][会話] の順に選択します。

ステップ 2

[サーバー間ハンドオフ要求に応答する] チェックボックスをオンにします。

ステップ 3

残りのすべての Unity Connection 受信場所についても、この手順を繰り返してください。

コールルーティングルールが、通話ハンドラのグリーティングに通話をルーティングするように設定されていることを確認する

手順

ステップ 1

Cisco Unity Connection Administration のサーバー間ハンドオフを許可するロケーションで、[通話管理]、 > [コールルーティング]、[直接ルーティングルール] の順に選択します。

ステップ 2

発信元からの着信クロスサーバ通話に適用されるルーティングルールの表示名を選択してください。

ステップ 3

ルールに一致する通話がコールハンドラーにルーティングされていることを確認してください。

ステップ 4

残りのすべての Unity Connection 受信側ロケーションについても同じ手順を繰り返します。

受信側の Cisco Unity ロケーションが、着信コールをオープニンググリーティングにルーティングすることを確認する

サーバー間ハンドオフ要求を承認するには、各 Cisco Unity サーバーが、通話を Opening Greeting 通話ハンドラにルーティングするように構成する必要があります。 （これは Cisco Unity を最初にインストールしたときのデフォルト設定です。） 受信側の Cisco Unity サーバそれぞれで以下の手順を実行し、通話ルーティングルールがハンドオフを受け入れるように正しく設定されていることを確認してください。


（注）  
フェイルオーバーシステムの場合は、プライマリサーバとセカンダリサーバの両方でこの手順を実行してください。
手順

ステップ 1

Cisco Unity Administrator のサーバー間ライブ返信ハンドオフを許可するロケーションで、[コールルーティング] > ダイレクトコール ページの順に選択します。

ステップ 2

発信側ロケーションからのサーバー間受信通話が、Opening Greeting にルーティングされていることを確認します。

デフォルトの通話ハンドラルーティングルール (削除または変更不可) は、Opening Greeting に通話を送信します。 したがって、ルーティングルールを追加していない場合、サーバは既にサーバ間通話を正しく処理するように設定されています。

ステップ 3

残りのすべての Cisco Unity 受信側ロケーションについても同じ手順を繰り返します。

Cisco Unity ロケーションからサーバー間 DTMF シーケンスを許可するように Unity Connection 受信側ロケーションを構成する

発信側 Cisco Unity ロケーションが受信側ロケーションに送信する DTMF トーンは、# (シャープ) で始まり、ハンドオフ (サインイン、転送またはライブ返信) の種類を区別する 2 つ目のトーンが含まれます。 デフォルトでは、Unity Connection Opening Greeting 通話ハンドラやその他の通話ハンドラは、# キーのあとに続くその他の発信者入力を無視するように構成されています。 このような構成では、サーバ間のハンドオフはすべて失敗します。

Unity Connection の受信側ロケーションで動作を変更して、サーバー間のハンドオフを正常に実行できるようにするには、いくつかの方法があります。

  • 追加の入力を許可するように、Opening Greeting (または、ルーティングルール構成に基づいてサーバー間ハンドオフを受信するその他の既存通話ハンドラ) を変更します。

  • サーバー間通話の処理に特化した新しい通話ハンドラおよび直接コールルーティングルールを作成します。 直接コールルーティングルールは、サーバー間通話に適用される条件に基づいて新しい通話ハンドラに通話をルーティングするはずです (たとえば、発信側 Cisco Unity ロケーションの発信番号または発信側ロケーションが、着信側ロケーションに到達するためにダイヤルするサーバー間ダイヤル文字列)。 （他の通話がルーティングルールに一致しないようにするには、サーバ間通話に固有の条件を選択してください。）

各 Unity Connection 受信側ロケーションで次の手順を実行して、Opening Greeting を構成するか、その他の通話ハンドラが、# キーの後にその他の入力をできるようにし、必要に応じて、新しい直接コールルーティングルールを作成します。

手順

ステップ 1

Cisco Unity Connection Administration のサーバー間サインインハンドオフを許可するロケーションで、[通話管理]、[システム通話ハンドラ] の順に選択します。

ステップ 2

[通話ハンドラ] ページで、Opening Greeting 通話ハンドラまたは修正するその他の通話ハンドラの表示名を選択するか、[新規追加] を選択して、サーバー間通話用の新しい通話ハンドラを作成します。

ステップ 3

手順 2 で新しい通話ハンドラを作成しなかった場合は、手順 6 に進みます。 手順 2 で新しい通話ハンドラを [新しい通話ハンドラ] ページで作成した場合は、必要に応じて、基本設定を入力します。 （フィールド情報については、ヘルプメニューから「このページ」を選択してください。）

ステップ 4

クロスサーバ DTMF シーケンスを受け入れるようにコールハンドラーを設定するには、以下の手順を実行します。

  1. 編集メニューで 呼び出し元入力を選択します。

  2. [発信者入力] ページで、[#] を選択します。

  3. [その他の入力を無視する] チェックボックスをオフにして、[保存] を選択します。

ステップ 5

手順 2 で新しい通話ハンドラを作成した場合は、新しい直接通話中着信ルーティングルールを作成して、通話を Cisco Unity サーバーから通話ハンドラに送信して処理します。

  1. [通話管理] > [コールルーティング]、[直接ルーティングルール] の順に選択します。

  2. [直接ルーティングルール] ページで、[新規追加] を選択します。

  3. [新規直接ルール] ページの [表示名] フィールドに新しいルールの名前を入力します。

  4. 保存を選択します。

  5. [直接ルールを編集] ページで、通話送信先に対して、[通話ハンドラ] を選択したら、手順 2 で追加した通話ハンドラの名前を選択します。

  6. 保存を選択します。

  7. [ルーティングルール条件] で、[新規追加] を選択します。

  8. Cisco Unity サーバーからのサーバー間通話と一致するように、ルーティングルールの条件を構成します。 たとえば、[発信番号] フィールドを使用して、ユーザーからの電話に応答する Cisco Unity ポートの電話番号を一致させるようにし、[保存] を選択します。

  9. [編集] メニューで、[直接ルーティングルールを編集] を選択します。

  10. サーバー間通話と一致させる必要があるその他の番号や番号のパターンに対して、g. から i. を繰り返します。

ステップ 6

残りのすべての Unity Connection 受信場所についても、この手順を繰り返してください。

サーバー間ライブ返信と転送要求を実行する Unity Connection 発信側ロケーションを構成する

デフォルトでは、Unity Connection ロケーションはサーバー間ライブ応答の実行を試行しません。 Unity Connection でサーバー間ライブ返信を有効にすると、サーバー間転送が自動で有効になることに注意します。 次の手順を実行して、Unity Connection の発信側ロケーションでサーバー間転送とライブ返信を有効にします。

手順

ステップ 1

Cisco Unity Connection Administration のリモートユーザーに通話を転送するロケーション (発信側ロケーション) で、[ネットワーク]、[ロケーション] の順に選択します。

ステップ 2

[検索ロケーション] ページで、このロケーションがホームであるユーザーに対してサーバー間ライブ返信と転送ハンドオフが許可されているリモートロケーションの [表示名] を選択します。

ステップ 3

受信場所の「場所の編集」ページで、この受信場所に対してクロスサーバ機能を有効にするには、次の手順を実行します。

  1. リモートロケーションに対するサーバー間転送とライブ返信を有効にするには、[このリモートロケーションに対してサーバー間転送を許可する] チェックボックスをオンにします。

  2. ハンドオフを行う際に、この場所が受信場所へ電話をかける際に使用するダイヤル文字列を入力してください（例：受信場所のパイロット番号）。

    （注）  

     
    受信場所ごとに入力できるダイヤル文字列は 1 つだけです。 発信側ロケーションが、複数の電話機システム統合に向けて構成されている場合は、すべての電話機システム統合が受信側ロケーションに到達するために使用するダイヤル文字列を入力します。

ステップ 4

この場所からサーバ間転送ハンドオフを受け入れる受信場所ごとに、 ステップ 2 と ステップ 3 を繰り返します。

ヒント

 
ページで変更を保存したら、[次へ] ボタンと [前へ] ボタンを使用して、組織内の各ロケーションを素早く移動します。

ステップ 5

残りのすべての Unity Connection 発信側ロケーションについても同じ手順を繰り返します。

サーバー間ライブ返信要求を実行するために Cisco Unity 発信側ロケーションを構成する

デフォルトでは、Cisco Unity 発信側ロケーションは、ほかのロケーションに対してサーバー間ライブ返信を実行しません。 次の手順を実行して、Cisco Unity 発信側ロケーションでサーバー間ライブ返信を有効にします。


（注）  
システムがフェイルオーバーを使用している場合は、プライマリサーバとセカンダリサーバの両方で以下の手順を実行してください。ネットワーク > ダイヤルドメインオプションページのほとんどの設定はレジストリに保存されているためです。 （レジストリ設定はセカンダリサーバには複製されません。）
手順

ステップ 1

Cisco Unity Administrator で、 Network > を展開し、 > Dialing Domain Options ページを選択します。

（注）  

 
システムに、[ダイヤルリングドメインオプション] リンクが無い場合は、Cisco Unity Administrator の [プライマリロケーション設定] ページでダイヤルリングドメインを構成する必要があります。

ステップ 2

[ライブ返信] セクションで、[サービスのクラスの権限が付与されているサブスクライバがほかのCisco Unityサーバーをホームにしているサブスクライバからのメッセージに相手に発信すること返信できるようにする] チェックボックスをオンにし、[サーバー間ライブ返信: 着信側のサブスクライバのCisco Unityサーバーに制御を渡す] をオンにします。 （電話システムへの通話の解放を選択すると、このサーバから発信されるサーバ間転送が無効になります。） ユーザーのホームサーバーに通話を転送する代わりに、Cisco Unityは、ユーザーに対して構成されたサーバー間転送用内線番号向けのリリース転送を試行します。 Unity Connection ユーザーで、ユーザー向けのサーバー間転送内線番号が構成されていない場合は、エラーになります)。

ステップ 3

[サーバー間ログオン向けパイロット番号、転送およびライブ返信] セクションにあるテーブルに表示されている各サーバーの [ダイヤル文字列] フィールドにパイロット番号を入力します。 （入力したパイロット番号は、Cisco Unity サーバ上の SQL Server データベース UnityDb に保存されることに注意してください。） したがって、システムがフェイルオーバーを使用している場合、パイロット番号はセカンダリサーバに複製されます。

ステップ 4

[サーバー間ログオン、転送、ライブ返信中にプロンプトを再生して、発信者に何かが起こっていることを知らせる] チェックボックスをオンにします。 「少々お待ちください」というプロンプトを再生するかどうかは任意ですが、発信者を転送する前のサーバー間処理には数秒かかるため、このチェックボックスをオンにすることをお勧めします。

ステップ 5

保存を選択します。

ステップ 6

残りのすべての Unity Connection 発信元拠点に対して、この手順を繰り返してください。

サーバー間ライブ返信をテストする

発信者がこの機能を使用できるようにする前に、サーバー間ライブ返信をテストする必要があります。

フェールオーバーシステムの場合、まずプライマリ宛先サーバーがサーバー間通話に応答するかどうかをテストします。 次に、宛先サーバーを手動でフェールオーバーして、セカンダリサーバーがサーバー間通話に応答することを確認します。 宛先サーバーがフェールオーバーに向けて適切に構成されていれば、プライマリサーバーが利用できない場合、セカンダリサーバーがサーバー間通話に応答するはずです。

クロスサーバライブ応答をテストするには、以下の手順を実行してください。

手順

ステップ 1

テスト目的で、各ロケーションに新しいユーザアカウントを作成するか、既存のアカウントを使用します。 ユーザーが、ライブ返信が有効なサービスのクラスに属しているかを確認します。 また、ユーザアカウント情報がテスト対象のすべてのサーバに複製されていることを確認してください。 ユーザデータの複製にかかる時間は、ネットワーク構成と複製スケジュールによって異なります。

ステップ 2

発信側ロケーションのユーザーとしてサインインし、メッセージを別のロケーションのテストユーザーに送信します。

ステップ 3

テストメッセージを受信した各ユーザーでサインインして、メッセージを聞いてから、送信者に発信するオプションを選択します。 以下の点を確認します。

  • (構成されている場合) 「少々お待ちください」というメッセージが再生されます。

  • 通話は、発信先ユーザーの通話転送設定に基づいて、ユーザーの電話機または挨拶メッセージに転送されます。

サーバ間サインイン、転送、ライブ返信における注目すべき動作

このセクションでは、サーバー間サインイン、転送、ライブ返信に関連する注目すべき動作や想定される動作について説明します。

ユーザー ワークステーション クライアントにアクセスできないサーバー間サインイン

Cisco Personal Communications Assistant (Cisco PCA) や IMAP クライアントなどのクライアント アプリケーションを使用する場合、ユーザーは、ホームサーバー (またはクラスタ) にアクセスする必要があります。 電話機インターフェイスは、サーバー間サインイン機能を指定する唯一のクライアントです。

Unity Connection と Cisco Unity 間のサーバー間サインイン時にパスワード入力を要求されるユーザー

Unity Connection ユーザーが、既知の内線番号から Cisco Unity ロケーションに発信し、そのユーザーが、サーバー間サインインを使用してホームロケーションに転送される場合、受信側 Unity Connection ロケーションは、ユーザーを識別できますが、ユーザーが既知の内線番号から発信していることは認識できません。 このため、Cisco Unity Connection Administration の [システム設定] > [詳細設定] > [会話] ページで [既知の内線番号から発信する場合にパスワードをスキップする] 設定が選択されているかどうかに関わらず、ユーザには常にパスワードの入力が求められます。

同様に、Cisco Unity ユーザーが、既知の内線番号から Unity Connection ロケーションに発信し、そのユーザーが、サーバー間サインインを使用してホームロケーションに転送される場合、[電話機のパスワードを要求する] が [ユーザーが既知の内線番号から発信した場合のみ] に設定されているかいないかに関わらず、ユーザーは常にパスワードの入力を求められます。

サーバ間ハンドオフ中に遅延を引き起こす要因

以下の要因は、サーバ間通話ハンドオフの遅延に大きく影響する可能性があります。

  • ユーザーのより長い内線番号。 4 桁の内線番号は、10 桁の内線番号に比べて、電話の引き継ぎ時にダイヤルするのに時間がかからない。

  • 受信側ロケーションに到達するより長いダイヤル番号。 4 桁のダイヤル文字列は、10 桁のダイヤル文字列と比較して、ダイヤルするのに時間がかかりません。

  • 発信場所と受信場所間の通話経路には、複数の要素（PIMG/TIMG ユニット、音声ゲートウェイ、TDM トランク、PSTN インターフェースなど）が存在する。 通話パスの要素が更けると、サーバー間通話転送処理により時間がかかります。

お使いの環境では、このような要素が増えることで、サーバー間機能のエラーの原因となり、発信者が使用できなくなる場合があります。 お使いの環境の代表的な通話パスでサーバー間構成をテストして、発信者が直面している遅延が許容範囲かどうかを判断します。

クロスサーバ機能によるポート使用量の増加

クロスサーバ機能を利用するには、送信元と受信側の両方でポートを使用する必要があります。 サーバの負荷状況によっては、これらの機能を有効にする前に、ポートを追加したり、サーバを追加したりする必要がある場合があります。 ポートの設定方法を調整する必要がある場合もあります。 例えば、着信を受け入れるために、より多くのポートを有効にする必要があるかもしれません。

サーバー間機能を有効にした後は、サーバーが負荷の増加に対応できると確信できるまで、サーバー上のアクティビティを綿密に監視する必要があります。 Cisco Unity Connection サーバーの場合、Cisco Unity Connection Serviceability の Port Activity レポートを使用するとポートの使用状況を監視できます。 Cisco Unity サーバーの場合、このタスクには Port Usage Analyzer を使用できます。 Port Usage Analyzer は、Tools Depot の [レポートツール] セクションで利用できます。 詳細な手順については、ポート使用状況アナライザーのヘルプを参照してください。 ポートの問題に関連するイベントログメッセージが発信側および受信側の Cisco Unity サーバーの Windows Event Viewer に記録されていないかも必ず監視してください。

サーバ間転送における転送オーバーライド

発信者が自動応答システムに内線番号を入力し、続けて「#2」と入力すると、転送を試みることなく、入力された内線番号に対応する挨拶に直接接続されます。 これは、転送オーバーライド用数字シーケンスと呼ばれています。

Unity Connection は、ネットワーク接続された拠点間の転送オーバーライドシーケンスを自動的にサポートします。 Cisco Unity サーバーの場合、「#2」の前の内線番号を使用するユーザーが、ダイやリングドメインの別のサーバーをホームとしている場合、転送オーバーライド用数字シーケンスは、デフォルトで無視されます。 Unity Connection ロケーションを含む、ダイヤリングドメイン内の他のロケーションをホームにしているユーザーに対して転送オーバーライド用数字シーケンスを有効にする場合は、サーバー間転送要求を発信した各 Cisco Unity で次の手順を実行します。

Cisco Unity ロケーションからのサーバー間転送で転送オーバーライドを有効にする手順

手順

ステップ 1

Cisco Unity サーバーデスクトップで、[Cisco Unityツールデポ] アイコンをダブルクリックします。

ステップ 2

左側のペインの [管理ツール]で、[詳細設定ツール] をダブルクリックします。

ステップ 3

[Unity設定] ペインで、[ネットワーク: サーバー間転送ハンドオフで転送オーバーライドを許可] を選択します。

ステップ 4

[新しい値] リストで、[1]、[設定] の順に選択します。

ステップ 5

プロンプトが表示されたら、 OKを選択してください。

変更を加えた場合でも、Cisco Unity ソフトウェアまたはサーバを再起動する必要はありません。

（注）  

 
Cisco Unity のフェイルオーバーでは、レジストリの変更は複製されないため、一方の Cisco Unity サーバで行ったレジストリの変更は、もう一方の Cisco Unity サーバで手動で行う必要があります。

Display Original Calling Number on Transfer パラメータを使用するサーバー間機能を使用する

Cisco Unity Connection (Cisco Unity とも呼ばれる) を、Cisco Unified Communications Manager と統合する際、Cisco Unified CM の Display Original Calling Number on Transfer from Cisco Unity サービスパラメータは、サーバー間ハンドオフとインターフェイスできます。これは、受信側ロケーションが、着信サーバー間ハンドオフ通話が、別のロケーションからの通話であることを認識しないためです。

以下のタスクを実行すると、このサービスパラメータが Cisco Unified CM で設定されている場合に、ロケーション間でサーバー間ハンドオフを適切に完了できます。このタスクリストで、サーバー間ハンドオフ中のみに使用される受信側ロケーションの特別なディレクトリ番号を作成すると、受信側ロケーションが通話をハンドオフとして認識できるようになります。

サーバー間機能向けのサーバー間ディレクトリ番号を構成するためのタスクリスト

  1. Cisco Unified Communications Manager Administration で、サーバー間サインイン、転送またはライブ返信通話を受信する各ロケーションに対して、新しいディレクトリ番号 (CTI ルートポイントなどで) を作成します。 新しいディレクトリ番号を設定して、その場所のパイロット番号に常に着信を転送するようにします。 お使いの Cisco Unified CM のリリースに対応する『Cisco Unified Communications Manager Administration ガイド』の「ディレクトリ番号の構成」章を参照してください (入手先: http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html)。

  2. 転送コールルーティングルールを使用して受信側ロケーションを構成します。これは、転送元ステータスがそのロケーションと同じ新しいサーバー間ディレクトリ番号と同じ通話を、Opening Greeting 通話ハンドラに送信します。転送コールルーティングルールを使用して受信側ロケーションを構成します。これは、転送元ステータスがそのロケーションと同じ新しいサーバー間ディレクトリ番号と同じ通話を、Opening Greeting 通話ハンドラに送信します。転送コールルーティングルールを使用して受信側ロケーションを構成します。これは、転送元ステータスがそのロケーションと同じ新しいサーバー間ディレクトリ番号と同じ通話を、Opening Greeting 通話ハンドラに送信します。? 6-23 ページの「クロスサーバ通話の宛先場所に転送通話ルーティングルールを追加する」セクションを参照してください 。

  3. 各発信側ロケーションが、サーバー間通話中に、パイロット番号ではなく、受信側ロケーションのサーバー間ディレクトリ番号にダイヤルするように更新します。 6-25 ページの「発信場所でクロスサーバディレクトリ番号をダイヤル文字列として構成する」セクションを参照してください 。

サーバー間通話に向けて転送済みコールルーティングルールを宛先ロケーションに追加する

このセクションには 2 つの手順が含まれています。 Cisco Unity Connection および/または Cisco Unity 受信側ロケーションの有無に応じて、どちらかまたは両方の手順を実行します。

手順

ステップ 1

Cisco Unity Connection Administration の Unity Connection の受信側ロケーションのいずれかで、新しい転送ルーティングルールを作成します。

  1. [通話管理] > [コールルーティング]、[転送ルーティングルール] の順に選択します。

  2. 転送ルーティングルールのページで、 新規追加を選択します。

  3. 新しい転送ルールのページで、表示名フィールドに新しいルールの名前を入力し、 保存を選択します。

  4. [転送ルーティングルールを編集] ページで、[通話送信先] に対して [通話ハンドラ] を選択します。 [通話ハンドラ] ドロップダウンメニューで、[Opening Greeting]、[保存] の順に選択します。

  5. [転送ルーティングルールを編集] ページの [ルーティングルールの条件] で、[新規追加] を選択します。

  6. [新しい転送ルーティングルールの条件] ページで、[転送元ステーション] を選択します。 [転送元ステーション] ドロップダウンリストで、[同じ] を選択します。 テキストボックスに、この場所の新しいクロスサーバディレクトリ番号を入力してください。

  7. 保存を選択します。

ステップ 2

[転送ルーティングルール] > [転送ルーティングルール] の順に選択して [転送ルーティングルール] ページに戻るか、[通話管理] > [コールルーティング] > [転送ルーティングルール] の順に選択して [転送ルーティングルール] ページに戻ります。

ステップ 3

ページ上の転送ルーティングルールの順序を確認してください。 手順 1で作成した新しいルーティングルールがテーブルの先頭 (優先順位の高い順) に表示されていない場合は、以下の副手順を実行して、新しいルーティングルールを転送ルーティングルールテーブルの先頭に移動します。

  1. [転送ルーティングルール] ページで、[順番を変更] を選択します。

  2. [転送ルーティングルールの順番を編集] ページで、手順 1 で作成した新しいルーティングルールの表示名を選択します。

  3. 表の下にある [上矢印] アイコンを選択して、ルールを一番上に移動します。 （アイコンを複数回選択する必要がある場合があります。）

  4. 保存を選択します。

ステップ 4

残りの Unity Connection 受信場所ごとに、この手順を繰り返してください。

転送コールルーティングルールを Cisco Unity 受信側ロケーションに追加する

手順

ステップ 1

Cisco Unity Administrator の Cisco Unity の受信側ロケーションのいずれかで、新しい転送済みルーティングルールを作成します。

  1. [通話管理] > [コールルーティング] の順に選択します。

  2. [転送された通話] を選択します。

  3. [追加] アイコンを選択します。

  4. 「通話ルーティングルールの追加」ダイアログボックスで、「名前」フィールドに新しいルールの名前を入力します。

  5. [追加]を選択します。

  6. [転送ステーション] フィールドに、このロケーションの新しいサーバー間ディレクトリ番号を入力します。

  7. [通話送信先] フィールドで、[通話ハンドラ] を選択します。 次に、[通話ハンドラを選択] を選択します。

  8. [通話ハンドラの選択] ボックスで、[Opening Greeting通話ハンドラ] を選択します。

  9. 保存を選択します。

ステップ 2

ページ上の転送ルーティングルールの順序を確認してください。 手順 1で作成した新しいルーティングルールがテーブルの先頭 (優先順位の高い順) に表示されていない場合は、以下の副手順を実行して、新しいルーティングルールを転送ルーティングルールテーブルの先頭に移動します。

  1. [ルールの順序を変更] を選択します。

  2. [転送通話ルールの再編集] ページで、手順 1 で作成した新しいルーティングルールの表示名を選択します。

  3. [上へ] を選択して、ルールを一番上に移動し、[閉じる] を選択します。

ステップ 3

[保存] アイコンを選択します。

ステップ 4

残りの Cisco Unity 受信場所ごとに、この手順を繰り返してください。

発信側ロケーションでダイヤル文字列としてサーバー間ディレクトリ番号を構成する

Unity Connection および/または Cisco Unity の発信側ロケーションがあるかどうかに応じて、以下のいずれかの手順を実行します。

手順

ステップ 1

Cisco Unity Connection Administration のサーバー間通話を発信する Unity Connection ロケーションのいずれかで、[ネットワーク] > [ロケーション] の順に選択します。

ステップ 2

[ロケーションを検索] ページで、受信側ロケーションの表示名を選択します。

ステップ 3

受信側ロケーションの [ロケーションを編集] ページで、このロケーションが受信側ロケーションンに発信する際に使用するダイヤル文字列を受信側ロケーションの新しいサーバー間ディレクトリ番号に変更します。 保存を選択します。

ステップ 4

手順 2 から手順 3 を繰り返して、このロケーションからサーバー間ハンドオフを許可する各受信側ロケーションを構成します。

ヒント

 
ページで変更を保存したら、[次へ] ボタンと [前へ] ボタンを使用して、組織内の各ロケーションを素早く移動します。

ステップ 5

残りのすべての Unity Connection 発信元拠点に対して、この手順を繰り返してください。

Cisco Unity 発信側ロケーションでダイヤル文字列としてサーバー間ディレクトリ番号を構成する

手順

ステップ 1

Cisco Unity Administrator で、[ネットワーク] > > [ダイヤルリングドメインオプション] の順に選択します。

ステップ 2

[サーバー間ログオン向けパイロット番号、転送およびライブ返信] セクションで、テーブルに表示されている各サーバーの [ダイヤル文字列] フィールドにサーバー間ディレクトリ番号を入力します。

（注）  

 
(入力した番号は、Cisco Unity サーバーの SQL Server database UnityDb に保存されます。 したがって、システムがフェールオーバーを使用している場合、数値はセカンダリサーバーにレプリケートされます)。

ステップ 3

[保存]を選択し、残りのすべての Cisco Unity 発信側ロケーションでこの手順を繰り返します。