この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
Cisco Unified CM アプリケーションは、基礎的な IP テレフォニーに多数の動作および機能の拡張を提供します。外部の eXtensible Markup Language(XML)生産性向上アプリケーションまたは IP Phone Service は、Web サーバまたはほとんどの Cisco Unified IP Phone 上のクライアント(あるいはその両方)で実行できます。たとえば、ユーザのデスク上の IP Phone を使用して、株式相場、天気情報、フライト情報など各種の Web ベースの情報を取得できます。また、カスタム IP Phone サービス アプリケーションを作成すると、ユーザが在庫を追跡したり、時間単位で顧客に課金したり、会議室の環境(照明、ビデオ画面、室温など)を制御できます。Cisco Unified CM には、次に示すような追加機能を提供する統合アプリケーションも多数あります。
エクステンション モビリティ(EM)機能では、モバイル ユーザがその電話機にログインすることで、一時的に Cisco Unified IP Phone をそのユーザ用に設定できます。
Unified CM Assistant は、アシスタントが 1 人以上のマネージャあて着信電話コールを処理できるようにする Cisco Unified CM に統合されたアプリケーションです。
WebDialer は Cisco Unified CM のクリックコール アプリケーションで、ユーザはサポートされる任意の電話デバイスを使用して自分の PC から簡単にコールを発信できます。
場合によっては、これらの統合アプリケーションが追加機能を提供するために、IP Phone Service を呼び出すこともあります。
表 18-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
|
|
|
---|---|---|
Cisco Unified IP Phone Service は、Web クライアントやサーバ、および Cisco Unified IP Phone の XML 機能を利用するアプリケーションです。Cisco Unified IP Phone のファームウェアには、限定的な Web ブラウジング機能を可能にするマイクロブラウザが含まれています。これらの電話サービス アプリケーションをユーザのデスクトップ電話機上で直接実行することで、付加価値サービスが提供され、生産性も向上する可能性があります。この章で phone service という用語は、Cisco Unified IP Phone を宛先および発信元としてコンテンツを送受信するアプリケーションを指します。
ここでは、IP Phone Service 機能の設計について次の項目を説明します。
IP Phone サービスは、次のような複数の方法で開始できます。
IP Phone ユーザが [サービス(Services)] または [アプリケーション(Applications)] ボタンを押すと、ユーザ加入電話サービスのリストを表示するために、HTTP GET メッセージが Cisco Unified CM に送信されます。図 18-1 は、この機能を示しています。
IP Phone ファームウェア内で、アイドル時間の値は URL Idle Time パラメータによって設定できます。このタイムアウト値を超えた場合、IP Phone のファームウェア自体が URL Idle パラメータで指定されるアイドル状態の URL の場所に対して、HTTP GET を開始します。
電話サービス アプリケーションは、電話機に HTTP POST メッセージを送信することによって、IP Phone にコンテンツをプッシュできます。
(注) 電話サービスを呼び出すために電話機の Web クライアントが使用されるユーザ起動および電話機起動のプル機能とは異なり、電話サービス起動のプッシュ機能は、電話機の(クライアントではなく)Web サーバに(HTTP POST を通じて)コンテンツをポストすることによって、電話機上の処理を呼び出します。
図 18-1 は、ユーザが開始する IP Phone サービス処理の詳細を示しています。ユーザが [サービス(Services)] または [アプリケーション(Applications)] ボタンを押したとき、[サービスのプロビジョニング(Services Provisioning)] が [外部 URL(External URL)] または [両方(Both)] に設定されている場合、デフォルトでは、HTTP GET メッセージが IP Phone から Cisco Unified CM の getservicesmenu.jsp スクリプトに送信されます(ステップ 1)。URL Services パラメータを変更することによって、異なるスクリプトを指定できます。getservicesmenu.jsp スクリプトは、個々のユーザが加入している電話サービス URL ロケーションのリストを返します(ステップ 2)。HTTP 応答は、IP Phone にこのリストを返します(ステップ 3)。ユーザによって選択される追加の電話サービス メニュー オプションは、ユーザと選択された電話サービス アプリケーションを含む Web サービス間で HTTP メッセージングを継続します(ステップ 4)。
[サービスのプロビジョニング(Services Provisioning)] パラメータは、デフォルトで [内部(Internal)] に設定されます。この設定では、IP Phone は Unified CM に HTTP GET メッセージを送る代わりに、コンフィギュレーション ファイルから電話サービスのリストを取得します。
(注) Service Provisioning エンタープライズ パラメータが内部にセットされる場合は、ステップ 1 からステップ 3 までがバイパスされ、電話サービスの処理はステップ 4 から開始します。
(注) Cisco Unified IP Phone 7960 はコンフィギュレーション ファイルから電話サービスのリストを解析する機能を持たないため、[サービスのプロビジョニング(Service Provisioning)] エンタープライズ パラメータが [内部(Internal)] に設定されている場合でも、HTTP GET を Unified CM に送ってリストを取得します。
図 18-1 ユーザ起動の IP Phone Service のアーキテクチャ
図 18-2 は、電話機起動と電話サービス起動の両方のプッシュ機能の例を示しています。電話機起動の例では、URL Idle Time に到達した時点で、自動的に、電話機から URL Idle パラメータで指定されたロケーションに HTTP GET が送信されます。HTTP GET は、Cisco Unified CM を通じて外部 Web サーバに転送されます。この Web サーバは HTTP 応答を返し、この応答は Cisco Unified CM によって電話機にリレーされ、電話機は画面にテキストまたはイメージ(あるいはその両方)を表示します。
電話サービス起動のプッシュの例で、外部 Web サーバ上の電話サービスは電話機の Web サーバに対して、Common Gateway Interface(CGI)または Execute 呼び出しで HTTP POST を送信します。CGI または Execute 呼び出しを実行する前に、電話機は URL Authentication パラメータで指定されるプロキシ認証サービスを使用して要求を認証します。このプロキシ認証サービスは、電話機に対する直接の要求を検証するための、電話機と Cisco Unified CM ディレクトリ間のインターフェイスを提供します。要求が認証された場合、Cisco Unified CM は電話機に HTTP 応答を転送します。次に、電話機の Web サーバは要求された処理を実行し、電話機は外部 Web サーバに HTTP 応答を返します。認証に失敗した場合、Cisco Unified CM は、HTTP 否定応答を転送し、電話機は要求された CGI または Execute 処理を実行しないで、HTTP 否定応答を外部 Web サーバに転送します。
図 18-2 電話機起動および電話サービス起動の IP Phone サービスのアーキテクチャ
XML Services に加えて、[Service Category] が [Java MIDlet] の新しいサービスを作成できます。Java MIDlet タイプのサービスが起動されると、設定された Service URL には、MIDlet JAD ファイルを取得できる URL を含みます。アプリケーション サーバは JAD ファイルの要求を受信すると、そのサーバは適切な JAR ファイルを対応デバイスに返します。この対応デバイスでは、電話の MIDlet インストーラがダウンロードし、処理しましす。
Cisco IP Phone の Java MIDlet サポートの詳細については、 https://www.cisco.com の Cisco IP Phone データ シートを参照してください。
(注) 電話機は、設定ファイルをダウンロードした後、リストのサービスが変わっていないかどうか判断するためサービス設定を解析し、変わっている場合にはそのローカル(持続)サービス設定を更新します。変更されたサービスが Java MIDlet(これは明示的にプロビジョニングされ、電話機に保存されます)の場合は、次に、電話機は必要なインストール処理、アップグレード処理、ダウングレード処理、およびアンインストール処理を、設定ファイルにプロビジョニングされたものに応じて順次実行します。MIDlet インストールが失敗の場合、電話機がその設定ファイルをチェックする次回(ブート、リセット、または再スタート時)に MIDlet インストールを再試行します。
管理者は、設定されたサービスの [Service Type] を [IP Phone Services]、[Directories]、または [Messages] のいずれかに指定する追加機能を使用できます。これは、ユーザが IP phone で新しいサービスにアクセスするため押すボタンを管理する柔軟性を管理者に与えます。新しいサービスはオプションとして Enterprise Subscriptions と同様に設定できます。これにより、それらサービスは個々の電話機ごとに加入を更新する必要がなく、自動的にすべての IP phone に表示されます。さらに、サービスは Unified CM データベースからそのサービスを削除する必要がなく有効にできたり無効にできたりします。
(注) Missed Calls、Placed Calls、および Corporate Directory などのデフォルトのサービスも無効にできます。これは、管理者が Service URL で指定されたデフォルト サービスをもとにしてカスタム サービスを作成できるようにします。
Unified CM は、非セキュア URL 以外に、HTTPS を使用してセキュア IP Phone サービス URL を設定する機能を提供します。HTTPS をサポートする電話機は、自動的にセキュア URL を使用します。IP Phone の信頼検証サービスとセキュリティ認証処理の詳細、および HTTPS をサポートする電話機の全リストについては、次の Web サイトで入手可能な最新バージョンの『 Security Guide for Cisco Unified Communications Manager 』で、HTTPS の情報を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html
電話機のユーザに対して信頼性の高いサービスを確保するには、システムの障害時に冗長システムにシームレスに移行することにより、高レベルのシステムの可用性を維持する必要があります。
[サービスのプロビジョニング(Services Provisioning)] で [内部(Internal)] にセットされる場合、電話機は加入した電話サービスが設定された設定ファイルを受信し、これら(および対応するサービス URL)をフラッシュ メモリに保存します。これにより電話機は、最初に Cisco CallManager IP Phone Service を参照せずにサービス URL に直接アクセスできます。Services Provisioning で内部にセットされる場合、Corporate および Personal Directories デフォルト サービスには電話機に組み込まれた追加レベルの冗長性もあります。これらサービスが選択された場合、電話機は適切な URL ストリングを使用して現在登録されている Unified CM に、HTTP メッセージの送信を試行します。したがって、電話機のデバイス プールの Unified CM Group の設定が、これらサービスの冗長性を提供します。
Services Provisioning が External URL、または両方にセットされる場合、電話サービスのほとんどのバックエンド処理は Web サーバで発生しますが、電話機はやはり加入電話サービスのそれらサービス URL を通知するには Unified CM に依存します。図 18-1 および図 18-2 に示す IP Phone サービス機能のアーキテクチャおよびメッセージ フローでは、次の 2 つの主な障害のシナリオを検討する必要があります。
障害シナリオ 1:Cisco Unified CallManager の Cisco Unified IP Phone Service サーバの障害
この場合の冗長性は、図 18-3 に示すように、ある種のサーバ ロード バランシング(SLB)に依存します。この SLB では、1 つ以上の Unified CM サーバを指すために仮想 IP アドレス(または DNS による解決可能なホスト名)が使用されます。この仮想 IP アドレス(または DNS による解決可能なホスト名)は、[URL サービス(URL Services)] パラメータの設定時に使用されます。SLB デバイスは、Unified CM サブスクライバ ノードの実 IP アドレスを使用して設定されます。このため、Cisco Unified CM サーバに障害が発生しても、電話機の [サービス(Services)] または [アプリケーション(Applications)] ボタンが押されたときに、IP Phone サービス加入リストは電話機に正常に返されます。また、Cisco Unified CM サーバで実行されるエクステンション モビリティおよび Unified CM Assistant などの電話サービスも、この方法によって冗長性を持つ可能性があります(エクステンション モビリティのハイ アベイラビリティおよび Unified CM Assistant のハイ アベイラビリティを参照)。
多くの SLB デバイスは、障害発生時の複数のサーバと自動転送要求のステータスをモニタするように設定できます。
障害シナリオ 2:特定の IP Phone Service をホストしている外部 Web サーバの障害
このシナリオでは、Cisco Unified CM サーバへの接続は保持されますが、ユーザ加入電話サービスをホストしている Web サーバへのリンクに障害が発生します。[サービス(Services)] または [アプリケーション(Applications)] ボタンが押された場合でも IP Phone は引き続き Cisco Unified CM サーバにアクセスできるため、これは冗長性を提供するための比較的容易なシナリオです。この場合、IP Phone は Web サーバにアクセスする他の任意 HTTP クライアントに似ています。このため、(図 18-3 に示すような)SLB 機能を再び使用して、電話機から、ユーザ加入電話サービスをホストしている 1 つ以上の冗長 Web サーバに HTTP 要求を転送できます。
Cisco Unified IP Phone サービスの大部分は、HTTP クライアントとして機能します。ほとんどの場合、Unified CM は加入サービスのロケーションへの転送サーバとしてのみ使用されます。Unified CM は電話サービスへの転送サーバとして機能するため、ユーザが [サービス(Services)] キーを押して電話サービスを要求したときに、Unified CM へ与えるパフォーマンスの影響は通常最小限になります。しかし、多数の要求(1 分間に数百の要求)はサーバのパフォーマンスに影響する可能性があります。サーバ パフォーマンスへの影響をできる限り小さくするため、IP Phone サービスの外部 URL を指定する必要がない場合、通常は [サービスのプロビジョニング(Services Provisioning)] エンタープライズ パラメータを [内部(Internal)] 設定のままにすることを推奨します。[サービスのプロビジョニング(Services Provisioning)] を [外部 URL(External URL)] または [両方(Both)] に設定する必要がある場合、またはコンフィギュレーション ファイルからサービスのリストを取得する機能を持たない電話機(Cisco Unified IP Phone 7960 など)を大量に使用する場合は、Cisco Unified IP Phone のサービス リスト提供ノードを慎重に選択してください。たとえば、すでにパブリッシャの負荷が高くなっているのであれば、Unified CM パブリッシャの代わりに Unified CM TFTP サーバを使用することや、あまり多くのトラフィックを扱っていない Unified CM サブスクライバを使用することを検討してください。
(注) エクステンション モビリティおよび Unified CM Assistant 電話サービスの場合、Unified CM は転送サーバ以上の役割を果たすので、パフォーマンスへのさらなる影響を検討する必要があります。これらのアプリケーションの特定のパフォーマンスおよびスケーラビリティの考慮事項については、エクステンション モビリティおよび Unified CM Assistantの項を参照してください。
IP Phone はクライアントまたはサーバのいずれかであるため、IP Phone サービスで使用される必要帯域幅の推定は、Web 運用サーバにある HTTP コンテンツと同じテキストにアクセスする HTTP ブラウザの帯域幅の推定に似ています。
統合されたエクステンション モビリティおよび Unified CM Assistant アプリケーションの電話サービスを除き、IP Phone サービスは独立したオフクラスタの Unified CM 以外の Web サーバに存在する必要があります。Unified CM サーバ ノードで、エクステンション モビリティおよび Unified CM Assistant 以外の電話サービスを実行することはサポートされていません。
ほとんどの Cisco IP Phone がテキストとグラフィックスを含むコンテンツをサポートしています。Cisco Unified IP Phone 7911G などの一部の電話機は、テキストベースの XML アプリケーションしかサポートしていません。Cisco TelePresence エンドポイントなどの一部のシスコのエンドポイントは Cisco IP Phone サービスをサポートしない場合があります。
Cisco エクステンション モビリティ(EM)機能では、ユーザがその電話機にログインすることで、一時的に Cisco Unified IP Phone をユーザ個別の設定に設定することが可能です。ユーザがログインすると、IP Phone には、回線番号、スピード ダイヤル、サービス リンク、およびその他のユーザ固有の電話機のプロパティなど、ユーザの個別のデバイス プロファイル情報が設定されます。たとえば、ユーザ X がデスクに向かって電話機にログインした場合は、そのユーザのディレクトリ番号、スピード ダイヤル、およびその他のプロパティがその電話機に表示されますが、ユーザ Y が別のときに同じデスクを使用した場合は、ユーザ Y の情報が表示されます。EM 機能では、認証されたユーザのデバイス プロファイルに従って電話機が動的に設定されます。このアプリケーションの利点は、電話機が EM をサポートしている限り、物理的な場所に関係なく、ユーザが Cisco Unified CM クラスタ内の任意の電話機で自分の内線番号に接続できることです。
ここでは、エクステンション モビリティ機能の設計について次の項目を説明します。
EM アプリケーションは、Cisco エクステンション モビリティ サービスに依存します。このサービスは機能サービスであり、[サービスアビリティ(Serviceability)] ページから手動でアクティブにする必要があります。
EM は、インストール時にすべての Unified CM ノードで自動的にアクティブになる Cisco エクステンション モビリティ アプリケーション ネットワーク サービスにも依存します。
Cisco エクステンション モビリティ アプリケーション サービスは、EM ユーザ電話機と Cisco エクステンション モビリティ サービスとの間のインターフェイスを提供するネットワーク サービスです。また、Cisco エクステンション モビリティ アプリケーション サービスは、クラスタ内の変更通知インジケータにサブスクライブして、アクティブな Cisco エクステンション モビリティ サービスがあるクラスタ内のノードのリストを維持します。
図 18-4 は、EM アプリケーションのメッセージ フローとアーキテクチャを示しています。電話機のユーザが EM アプリケーションにアクセスする場合、次の一連のイベントが発生します。
1. ユーザが電話機の [サービス(Services)] または [アプリケーション(Applications)] ボタンを押すと、[エンタープライズパラメータ設定(Enterprise Parameter configuration)] ページの [URL サービス(URL Services)] パラメータで指定された URL に発信されます(図 18-4 のステップ 1 を参照)。
2. HTTP/XML コールが IP Phone Service に対して生成され、このコールはユーザの電話機が加入しているすべてのサービスのリストを返します(図 18-4 のステップ 2 を参照)。
(注) Services Provisioning エンタープライズ パラメータが内部に設定されている場合、ステップ 1 および 2 はバイパスされます。一方、[サービスのプロビジョニング(Services Provisioning)] が [外部 URL(External URL)] または [両方(Both)] に設定されている場合、ユーザが回線ボタンまたはスピード ダイヤル ボタンを押して、Cisco エクステンション モビリティ アプリケーション サービスへの直接コールを生成できるように、[サービス URL(Service URL)] ボタンをユーザの電話機の EM に対して設定できます。ステップ 1 およびステップ 2 もバイパスされます。
3. 次に、ユーザはエクステンション モビリティ電話サービスのリストを選択します。この選択によって、電話機と Cisco エクステンション モビリティ サービス間のインターフェイスの役割を果たす Cisco エクステンション モビリティ アプリケーション サービスに対して HTTP コールが生成されます(図 18-4 のステップ 3 を参照)。
4. 次に、Cisco エクステンション モビリティ アプリケーション サービスは、ユーザ ログイン クレデンシャル(ユーザ ID および PIN)を要求している電話機に XML 応答を返すか、またはユーザがすでにログインしている場合は、ユーザに電話機からログオフするかどうかを尋ねる応答を返します(図 18-4 のステップ 4 を参照)。
5. ユーザがログインしようとしている場合、そのユーザは電話機のキーパッドを使用して有効なユーザ ID および PIN を入力する必要があります。ユーザが [送信(Submit)] ソフトキーを押した後に、入力したユーザ ID および PIN を含む応答が、Cisco エクステンション モビリティ アプリケーション サービスに返されます(図 18-4 のステップ 5 を参照)。
6. 次に、Cisco エクステンション モビリティ アプリケーション サービスは、このログイン情報を Cisco エクステンション モビリティ サービスに転送します。このサービスは、Unified CM データベースと対話して、ユーザのクレデンシャルを検証します(図 18-4 のステップ 6 を参照)。Cisco エクステンション モビリティ アプリケーション サービスはクラスタの変更通知にサブスクライブして、Cisco エクステンション モビリティ サービスがアクティブになっているクラスタ内の全ノードのリストを維持します。その結果、同じ Unified CM ノードで Cisco エクステンション モビリティ サービスが実行されていない場合、Cisco エクステンション モビリティ アプリケーション サービスは、Cisco エクステンション モビリティ サービスが実行されている他の Unified CM ノードにログイン情報を転送します。
7. ユーザのクレデンシャルの検証に成功したときに、Cisco エクステンション モビリティ サービスも Unified CM データベースと対話して、適切なユーザ デバイス プロファイルを読み取って選択し、デバイスのプロファイルに基づいて電話機の設定に必要な変更を書き込みます(図 18-4 のステップ 7 を参照)。
8. これらの変更が加えられると、Cisco エクステンション モビリティ サービスは、Cisco エクステンション モビリティ アプリケーション サービスに成功応答を返します(図 18-4 のステップ 8 を参照)。
9. 次に Cisco エクステンション モビリティ アプリケーション サービスは電話機にリセット メッセージを送信し、電話機はリセットされ、新しい電話設定を受け入れます(図 18-4 のステップ 9 を参照)。
図 18-4 EM アプリケーションのアーキテクチャとメッセージ フロー
Unified CM は、クラスタ間のエクステンション モビリティ(EMCC)という新機能によって、企業内のクラスタ間でエクステンション モビリティ ログインを実行する機能を提供します。EMCC のアーキテクチャの概要を理解することが重要です。EMCC 機能はホーム クラスタおよび Visiting クラスタという概念を使用します。これらの用語は、ログインを実行するユーザの観点から定義されています。ユーザがオフィスに移動して電話機にログインしようとしたときに、この電話機が登録されているクラスタのデータベースにユーザの情報がない場合、このクラスタは Visiting クラスタと見なされ、この電話機は以降は Visiting 電話機と呼ばれます。図 18-5 に、ホーム クラスタと Visiting クラスタの概念を示します。
図 18-5 EMCC のホーム クラスタと Visiting クラスタ
Visiting クラスタ内の EM サービスは、Unified CM 内で構成されている各 EMCC リモート クラスタに照会を送信して、ユーザのホーム クラスタを見つけようとします。ユーザのホーム クラスタが肯定応答を返した場合、両方のクラスタの EM サービス間で通信が開始され、情報が交換されます。基本的にはデバイス情報がホーム クラスタのデータベースに取り込まれ、ホーム クラスタはこの Visiting 電話機の設定ファイルを作成できます。この設定ファイルには、Visiting クラスタからデバイス設定、ホーム クラスタから設定パラメータ、およびホーム クラスタ内のユーザのデバイス プロファイルが組み込まれます。ホーム クラスタの TFTP サーバにこの Visiting 電話機の設定ファイルができると、Visiting クラスタによって発行されたリセットによって、Visiting 電話機は Visiting クラスタから小さな設定をダウンロードし、これによってさらにホーム クラスタから証明書と完全な設定をダウンロードするよう指示されます。最終的には、Visiting 電話機はホーム クラスタにクロス登録されます。つまり、すべての呼制御シグナリングはホーム クラスタの Unified CM サブスクライバと Visiting 電話機の間で発生し、ユーザのホーム クラスタのダイヤリング手順が維持されます。
EMCC ログイン プロセスの段階的な説明については、次の Web サイトで入手可能な最新バージョンの『 Feature Configuration Guide for Cisco Unified Communications Manager 』で、クラスタ間のエクステンション モビリティの情報を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
EMCC 呼処理動作はダイヤル プランの設計に影響するため、これを理解することも重要です。ユーザが Visiting クラスタの電話機にログインすると、ユーザがダイヤルした数字はホーム クラスタによって、Visiting 電話機の集合 Call Search Space(CSS)に従って分析されます。これは、Visiting 電話機用のホーム クラスタのデバイス プール(EMCC ローミング デバイス プールと呼ばれる)内の付属 CSS、ユーザのデバイス プロファイルに関連付けられたディレクトリ番号に設定された回線 CSS、およびユーザのデバイス プロファイルに設定された EMCC CSS を連結したものです。図 18-6 に、EMCC 電話機の結果の CSS を示します。
付加コーリング サーチ スペースは、新規のコール ルーティング設定パラメータです。このパラメータは、EMCC により使用され、Visiting クラスタからユーザに対して緊急番号のインターセプトおよびルーティングを行います。付加 CSS には、911、112、または 999 などのディレクトリ番号の付いたパーティションがあります。このパーティションは、Visiting クラスタにコールをルーティングして、そのコールが電話機の物理的な場所に対してローカルな緊急サービスに連絡できるようにします。付加コーリング サーチ スペースと EMCC ローミング デバイス プールの詳細、および Visiting 電話機に関連付ける方法については、次の Web サイトで入手可能な最新バージョンの『 Feature Configuration Guide for Cisco Unified Communications Manager 』で、クラスタ間のエクステンション モビリティの情報を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
(注) EMCC 機能に関連付けられた EMCC ローミング デバイス プールは、デバイス モビリティ機能に関連付けられたローミング デバイス プールとは関係ありません。
EMCC ユーザは、コールを発信する際に、ホームの Unified CM のルートおよび番号計画が利用されることを承知しておく必要があります。たとえば、クラスタ A からのユーザがクラスタ B から電話機へログインするときに、そのすぐ隣にあるクラスタ B の電話機のディレクトリ番号に発信する場合、ユーザはクラスタ A からクラスタ B の電話機に発信する場合と同様に適切なパターンをダイヤルする必要があります。これは、ホーム クラスタがクラスタ A からクラスタ B へのクラスタ間トランク コールを開始する可能性があることを意味しますが、メディアは Visiting 電話機とリモート電話機の間でローカルに流れます。
EMCC クラスタを +E.164 の番号指定を使用して配置する場合、ユーザはすでに相手の電話番号の完全な番号をダイヤルすることに慣れているので、ダイヤリング手順を変更する必要はありません。
ルーティングされた PSTN コールでは、呼処理動作に影響する次の 2 つの異なる設定があります。
EMCC ログイン ユーザが PSTN コールをダイヤルすると、番号分析が(ルート リストおよびルート グループ コンストラクトを通じて、または音声ゲートウェイ宛に直接設定されて)最終的に音声ゲートウェイにつながるルート パターンと一致した場合、コールはゲートウェイに送信されます。標準ローカル ルート グループ(LRG)機能が使用されていない場合、コールはホーム クラスタに関連付けられた音声ゲートウェイを介します。したがって、メディアは Visiting 電話機から(通常は WAN を介して)音声ゲートウェイへ流れます。ルート パターンが、標準 LRG を使用するように設定されたルート リストにつながる場合、動作は変わります(LRG の詳細については、ローカル ルート グループを参照してください)。Unified CM のロジックは、EMCC ログイン デバイスについて標準 LRG を呼び出す必要がある場合、エンドポイントを EMCC デバイスとして認識し、PSTN コールを、指定された EMCC 固有の SIP トランクを介して、この Visiting 電話機が通常登録される Visiting クラスタに送信します。
(注) EMCC トランク サービス タイプの SIP トランクは、クラスタごとに 1 つだけ必要です。このトランクには宛先情報は設定されていません。その情報は、EMCC リモート クラスタの追加および更新時に動的に収集されます。
Visiting クラスタ内の EMCC SIP トランクでコール Invite が受信されると、Visiting クラスタは再度、トランクの CSS に従って(または、Visiting 電話機の元のデバイス設定の CSS に従って)着信番号に対して番号分析を使用し、それに応じてコールをルーティングします。EMCC SIP トランク上の SIP Invite には追加情報が含まれています。つまり、Visiting 電話機のデバイス名です。これにより、Visiting クラスタはデータベース内にある Visiting 電話機の設定済みデバイス CSS を判別できます(必要な場合)。番号分析の結果が、最終的に標準 LRG を指すルート パターンとの一致である場合、Visiting クラスタはこの Visiting 電話機の設定済み標準 LRG を判別できます。Visiting クラスタ内の標準 LRG には一般に、Visiting クラスタに関連付けられた音声ゲートウェイが含まれているため、PSTN コールは、Visiting 電話機に対してローカルな音声ゲートウェイに送信されます。
緊急番号へのコールを考慮すると、LRG と LRG 以外の呼処理動作の違いは重要です。ローカル ルート グループ(LRG)の使用は、EMCC 配置の場合、クラスタ全体には必要ありませんが、EMCC ログイン電話機は、緊急コールを正しくルーティングするために LRG にアクセスする必要があります。Visiting 電話機に対して、ローカルである適切な音声ゲートウェイ経由でコールを発信できるように、緊急コールを Visiting クラスタに正しくルーティングするには LRG が必要です。EMCC デバイス用ローミング デバイス プール設定内の付加コーリング サーチ スペースにより、管理者は緊急ルート パターンを追加できます。緊急ルート パターンは、EMCC ログイン デバイスの LRG を使用しますが、ホーム クラスタ内の他のデバイスの緊急ダイヤリングに影響しません。前述したように、EMCC ログイン電話機は、(ジオロケーションにより)別のクラスタのすべての電話デバイスを示すデバイス プールに関連付けられます。デバイス プールの付加コーリング サーチ スペースでは、EMCC ログイン電話機の緊急コールだけを LRG 経由で送信するように、Visiting クラスタの緊急ルート パターンを設定できます。したがって、ホーム クラスタおよび Visiting クラスタが同じ緊急ルート パターンを使用している場合でも、EMCC ログイン電話機の緊急コールは、LRG 経由で Visiting クラスタにルーティングします。EMCC SIP トランク経由で Visiting クラスタでコールが受信されると、Visiting クラスタのダイヤル プランがコールのその後の処理を行います。
(注) EMCC をサポートするクラスタが緊急呼処理に Cisco Emergency Responder も使用している場合、その導入をサポートするダイヤル プランの設定方法の詳細については、次の Web サイトで入手可能な最新バージョンの『Cisco Emergency Responder Administration Guide』を参照してください。https://www.cisco.com/c/en/us/support/unified-communications/emergency-responder/products-maintenance-guides-list.html。
(注) 標準 LRG が緊急ルート パターン用にすでに配置されており、ホーム クラスタと Visiting クラスタが同じ緊急ダイヤル ストリングを使用する場合、付加 CSS を使用する必要はありません。
詳細な EMCC 呼処理の例と設定については、次の Web サイトで入手可能な最新バージョンの『 Feature Configuration Guide for Cisco Unified Communications Manager 』で、クラスタ間のエクステンション モビリティの情報を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
RSVP Agent を除くすべてのメディア リソースは、Visiting 電話機に割り当てられたデバイス プールのメディア リソース グループ リストに従って、ホーム クラスタから割り当てられます。会議、トランスコーディング、および保留音は、すべて通常どおり機能します。違いは、メディアは Visiting 電話機とメディア リソースの間を、(通常は)ホーム クラスタと Visiting クラスタを隔てる WAN を介してストリーミングされることです。EMCC ログイン ユーザが、RSVP Agent を使用する必要があるコールを行うと、Unified CM EMCC ロジックはそれが Visiting 電話機であることを判別でき、EMCC SIP トランクを介してリソース要求を Visiting 電話機が属するリモート クラスタに送信します。Visiting 電話機のデバイス名はこの要求に含まれています。これにより、Visiting クラスタは、通常この Visiting 電話機に割り当てられる RSVP Agent メディア リソースを確認でき、コールでの使用を割り当てることができます。
Unified CM では、HTTPS を使用するエクステンション モビリティ セキュア サービス URL を作成できます。これにより、EM のログイン/ログアウトの交換全体が暗号化されます。エクステンション モビリティではセキュア サービス URL を設定することを推奨します。HTTPS をサポートしない電話機が EM 用に配置されている場合は、非セキュア サービス URL も設定する必要があります。セキュア サービス URL と非セキュア サービス URL がサービスに対して存在する場合、HTTPS をサポートする電話機は、デフォルトでセキュア サービス URL を使用します。HTTPS をサポートする電話機の全リストについては、次の Web サイトで入手可能な最新バージョンの『 Security Guide for Cisco Unified Communications Manager 』で、HTTPS の情報を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html
EM 機能は、要求のソース IP アドレスを検証することによって、EM ログインおよびログアウト要求にオプション レベルのセキュリティを提供します。デフォルトでは、EM はこの要求の検証を実行しません。したがって、EM セキュリティを有効にするには、管理者はクラスタ全体のサービス パラメータ Validate IP Address を true に設定する必要があります。
EM ログインおよびログアウト HTTP 要求を処理する Web プロキシを実装する組織は、Allow Proxy サービス パラメータを true に設定する必要があります。プロキシ サーバは、HTTP 要求を転送している間に、そのホスト名とともに HTTP ヘッダーの via-field をセットします。デバイスと Unified CM の間に複数のプロキシ サーバがある場合で、すべてのサーバで要求が転送される場合は、次に HTTP ヘッダーの via-field にはフォワーディング パスで各プロキシ サーバのホスト名のカンマ区切りリストが必要になります。Allow Proxy サービス パラメータは、true に設定されている場合、Web プロキシを介して受信した EM ログインおよびログアウトが可能です。また、プロキシされた EM 要求はプロキシ サーバのソース IP アドレスを使用する場合、その IP アドレスは IP サービス パラメータの信頼できるリストにも設定する必要があります。
Unified CM 8. x から HTTPS および Security By Default がサポートされ、Unified CM 9. x ではセキュアな電話機が導入されたことで、EMCC のクラスタ間の連携には、クラスタ相互の通信をセキュアな方法で行うためにいくつかの段階が必要になりました。特に、EMCC に参加するすべてのクラスタで、Tomcat(Web)および TFTP 証明書を中央の sFTP サーバにエクスポートする必要があります。EMCC に使用する電話がセキュア モードになる場合は、CAPF 証明書もエクスポートする必要があります。これらのセキュリティ証明書はすべて結合され、各クラスタは結合済み証明書をインポートする必要があります。EMCC に参加する可能性がある新しいノードがクラスタに追加されるたびに、または既存のノードで証明書が更新された場合は、エクスポート、結合、およびインポートというプロセスを繰り返す必要があることに留意することが重要です。これらの手順はすべて、Unified CM Serviceability の管理によって簡素化されています。EMCC の設定の詳細については、次の Web サイトで入手可能な最新バージョンの『 Feature Configuration Guide for Cisco Unified Communications Manager 』で、クラスタ間のエクステンション モビリティの情報を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
Cisco Unified CM 9. x から、ユーザはセキュア モードの電話機、つまり認証済みまたは暗号化済みのデバイス セキュリティ プロファイルを持つ電話機を使用して EMCC によりログインできるようになりました。ユーザがセキュア モードの電話機でログインする場合、デバイス セキュリティ プロファイル内のコンフィギュレーション(デバイス セキュリティ モード、TFTP 暗号化オプション、伝送プロトコルなど)がホーム クラスタに転送され、電話機は Visiting クラスタ内で本来使用されていたのと同じセキュア モードで動作することが可能になります。たとえば、電話機が Visiting クラスタ内の暗号化されたデバイス セキュリティ モードに設定され、ユーザが EMCC 経由でログインする場合、電話機は依然としてシグナリング用のセキュア TLS チャネルとメディア用 sRTP を持つ暗号化されたデバイス セキュリティ モードで動作します。ただし、1 つの条件として、ホーム クラスタのセキュリティ モードが混合モードに設定されていることが必要です。ホーム クラスタがノンセキュアに設定されている場合は、EMCC ログインに失敗します。電話機がセキュア モードでない場合、電話機は Visiting クラスタが混合モードまたはノンセキュア モードにあるかどうかに関係なく、EMCC ログイン後、ノンセキュア モードで動作し続けます。 表 18-2 にこの動作を示します。
Unified CM 8. x は、EMCC をサポートしていますが、セキュア モードの電話機についてはサポートしていません。したがって、セキュア モード登録された電話機から Unified CM 8. x を実行中の Visiting クラスタへの EMCC ログイン試行は、ホーム クラスタで Unified CM 8. x 以降とそれ以降のリリースのどちらが実行されているかにかかわりなく、失敗します。同様に、セキュア モードの電話機から Unified CM 8. x を実行中のホーム クラスタへの EMCC ログイン試行は、Visiting クラスタで Unified CM 8. x とそれ以降のリリースのどちらが実行されているかにかかわりなく、失敗します。 表 18-2 にこの動作を示します。
(注) Cisco Unified CM 9.0 では、EMCC SIP トランクをセキュア プロファイルで設定できません。したがって、ローカル PSTN へのコールは、シグナリングにセキュア チャネルを使用しません。ただし、電話と PSTN ゲートウェイがセキュア モードで設定されている場合、メディアは暗号化されます。
図 18-4 に示す EM アーキテクチャに従って、Unified CM データベースの読み取りおよび書き込みが要求されます。EM はユーザに面した機能であって、データベースの書き込みは、EM がサブスクライバ ノードで実行できるかどうかに関係します。したがって、Unified CM パブリッシャが利用できない場合、その場合でも EM ログインおよびログアウトはできます。
冗長性の見地から、次のコンポーネント レベルの冗長性については、全面的な EM の復元性を得るよう検討する必要があります。
CallManager Cisco IP Phone サービスのハイ アベイラビリティは、Services Provisioning サービス パラメータの使用、または Cisco CallManager Cisco IP Phone サービスを実行する複数の Unified CM ノードを指すロード バランサ デバイスの使用により実現されます。詳細については、IP Phone サービスのハイ アベイラビリティを参照してください。
Cisco エクステンション モビリティ サービスのハイ アベイラビリティは、Cisco エクステンション モビリティ サービスを複数の Unified CM ノードでアクティブにすることにより実現されます。
(注) Cisco エクステンション モビリティ サービスは、3 つ以上のノードでアクティブにできますが、最大 2 つのノードが、ログイン/ログアウト要求を常にアクティブに処理します。ロード バランサを使用する場合は、2 つの Unified CM ノードのみにエクステンション モビリティ要求を送信するようにロード バランサを設定します。ロード バランサは、障害時のみ、Cisco エクステンション モビリティ サービスを実行するその他のノードに対してログイン/ログアウト リクエストの送信を開始します。
2 つの Unified CM ノード間の要求をロード バランシングしたり、冗長性を提供したりするため、サーバ ロード バランサ デバイスの導入を推奨します。サーバ ロード バランサがない場合、ロード バランシングは均等でなく、冗長性には手動で対応します。たとえば、2 つの EM IP Phone サービスをそれぞれの電話機で設定できます。1 つの Unified CM ノードが到達不能の場合、エンド ユーザはもう一方のノードに到達するために、もう一方の EM IP Phone サービスを手動で選択する必要があります。
(注) EM IP Phone サービスに冗長性を提供することは、EM IP Phone サービスのリストからサービスを手動で選択する作業をエンド ユーザに任せることで可能になりますが、この方法の場合、ハイ アベイラビリティの実現が困難になる可能性があります。ユーザが電話サービス メニュー(または割り当てられた機能キー)から選択可能になる EM IP Phone サービスを制御できないため、EM ログイン/ログアウト要求を処理する Unified CM ノード間で、EM ログイン/ログアウトのロード バランシングを確実にする方法はありません。さらに、EM サービスの応答に遅延が発生した場合のエンド ユーザの行動は、障害シナリオではよくある行動ですが、EM サービス コールをキャンセルして代替 EM IP Phone サービスを選択するというもので、たいていの場合は状況を悪化させます。これは、ネットワークのみならず、EM ログイン/ログアウト要求を処理する残りの Unified CM ノードでの輻輳および負荷の増大につながる場合があります。
Cisco エクステンション モビリティ サービスを実行する 2 つの Unified CM ノードを使用した配置は、1 分あたりのログイン/ログアウト要求の数に関して最高のキャパシティを提供します(詳細については、エクステンション モビリティのキャパシティ プランニングを参照してください)。冗長性も提供します。ただし、障害が発生した場合は、1 つのノードしか残っていないので、ログイン/ログアウト要求のキャパシティは減少します。したがって、最高のログイン/ログアウトのキャパシティを実現して、このキャパシティを障害発生時にも維持するには、Cisco エクステンション モビリティ サービスを追加の Unified CM ノードでアクティブにする必要があります。ロード バランサは、任意の時点で 2 つの Unified CM ノードのみにエクステンション モビリティ要求を送信するように配置および設定する必要があります。1 つの Unified CM ノードで障害が発生すると、ロード バランサは 2 つの Unified CM ノードがエクステンション モビリティ要求を処理し続けるように、別の Unified CM ノードに対してエクステンション モビリティ ログイン/ログアウト要求の送信を開始できます。このため、エクステンション モビリティ キャパシティが維持されます。
(注) 複数の IP リストを持つ DNS A レコードまたは SRV レコードを使用した冗長な設計は推奨できません。DNS 要求に対して複数の IP アドレスが戻ると、電話はタイムアウトを待ってから次にリストされた IP アドレスを試します。ほとんどの場合は、この動作よりエンド ユーザにとって許容できない遅延が発生します。また、このために Cisco エクステンション モビリティ アプリケーション サービスが有効である 3 つ以上のサブスクライバ ノードによってログイン/ログアウト要求が処理される場合がありますが、そのような処理はサポートされていません。
EMCC では、管理者により、リモート クラスタで EM サービスを実行している Unified CM サブスクライバ ノードの 1 つの FQDN または IP アドレスを指定し、Unified CM Web 管理画面を経由してリモート クラスタが追加されます。2 つのクラスタ間の EM サービスは、Unified CM バージョンに関する情報、EMCC EM サービス通信の EM サービス ノードの順序付きのリスト、リモート クラスタで使用可能な EMCC SIP トランク サービス(PSTN アクセスまたは RSVP Agent、あるいはその両方)、および各 EMCC サービスの EMCC SIP トランク操作を処理する最大 3 つのリモート Unified CM ノードの順序付きのリストを提供します。HTTPS 経由の EMCC EM サービス通信には、ユーザのホーム クラスタの検索、EMCC ログイン時の情報交換、およびリモート クラスタ更新が含まれます。最初の更新で、リモート クラスタのエクステンション モビリティ アプリケーション サービスが照会され、そのリスト内の最初の 3 つの EM サービス ノードが返されます。この順序付きのリストによって、EMCC 通信に使用されるリモート クラスタ EM サービス ノードが決まります。
リモート クラスタは、EMCC の PSTN アクセス サービスおよび RSVP Agent サービスのプライマリ、セカンダリ、および 3 次オプションに関する情報を、それらのサービスの割り当て済み EMCC SIP トランクのデバイス プールに関連付けられた Unified CM Group から取得します。これにより、EMCC SIP トランクを処理するプライマリ Unified CM サブスクライバがオフラインの場合、EMCC SIP トランク コールはセカンダリ Unified CM サブスクライバなどによって処理されます。
電話機に EMCC 経由でログインすると、割り当て済み EMCC デバイス プール内に設定された Unified CM Group の形式で、電話機に冗長性が提供されます。Visiting 電話機がリモート サイトに設置されており、Visiting クラスタおよびホーム クラスタの両方が到達不能になる WAN 障害があった場合、Visiting クラスタの SRST リファレンスは、EMCC 電話機により維持されます。そのため、EMCC ログイン電話機は、設置されたサイト内の適切な SRST ルータに登録可能になっています。EMCC ログイン ユーザの DID は、この SRST サイトにあるローカル ゲートウェイに関連付けられることはほとんどないため、着信コールはユーザのホーム クラスタ上のコール転送ルールに基づいてルーティングされることになります。SRST モードの間、そのユーザは SRST フェールオーバー登録中に Visiting SRST サイトで設定されたダイヤル手順に適応する必要もあります。ネットワーク障害発生中の EMCC ログイン電話機の動作のさらなる例は、次の Web サイトで入手可能な最新バージョンの『 Feature Configuration Guide for Cisco Unified Communications Manager 』で、「Cisco Extension Mobility Cross Cluster」セクションを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
ホーム クラスタへの登録を可能にする EMCC 設定ファイルをダウンロードするために Visiting 電話機が使用する、デフォルトおよびバックアップの Unified CM TFTP サーバを設定することも推奨します。これは、[EMCC Feature Configuration] で設定します。
Cisco エクステンション モビリティ アプリケーションを実行している単一の Unified CM の場合、Unified CM ノードが 7,500 人のユーザまたは 10,000 人のユーザ用の VM 構成で展開されているときのクラスタ全体の最大キャパシティは、1 分あたり 250 回のログインまたはログアウトです。Cisco エクステンション モビリティ ログインおよびログアウト機能は、ログイン/ログアウトのクラスタ キャパシティを増加するためにサブスクライバ ノードのペアに分散できます。ロード バランサ デバイスを使用できますが、手動で EM 負荷を 2 つのサブスクライバ ノード間で均等に分散するには、サブスクライバ ノードの 1 つを指している EM 電話サービスに加入している 1 つの電話機グループと、2 番めのサブスクライバ ノードを指している別の EM 電話サービスに加入している別の電話機グループの、2 つのグループに電話機を分割する必要があります。EM 負荷がこの方法で分散され、7,500 人のユーザまたは 10,000 人のユーザ用の VM 構成を使用した Unified CM ノード間で均等な場合、1 分あたりのクラスタ全体のキャパシティは最大で 375 回の順次ログインまたはログアウト(あるいはその両方)になります。
(注) Cisco エクステンション モビリティ サービスは、冗長性を目的として 3 つ以上のノードでアクティブにできますが、最大 2 つのサブスクライバ ノードまでが同時にアクティブにログイン/ログアウト処理することをサポートしています。
(注) EM セキュリティの有効化はパフォーマンスを低下しません。
EMCC ログイン/ログアウト処理は、クラスタ内 EM ログイン/ログアウトよりも多くの処理リソースを必要とします。したがって、サポートされるログイン/ログアウトの最大レートは低くなります。クラスタ内 EM ログイン/ログアウトがない場合、Unified CM は 7,500 人のユーザまたは 10,000 人のユーザ用の VM 構成を使用して、1 分あたり 75 回の EMCC ログイン/ログアウトの最大レートをサポートします。ほとんどの配置では、クラスタ内ログイン/ログアウトとクラスタ間ログイン/ログアウトの組み合わせが発生します。より一般的なこのシナリオでは、EMCC ログイン/ログアウトの混合(ホーム クラスタまたは Visiting クラスタのどちらとして機能する場合でも)は、1 分あたり 40 回のモデルにする必要があります。同時にクラスタ内 EM ログインは、シングル EM ログイン サーバを使用する場合、185 回のログイン/ログアウトのモデルにする必要があります。2 つの Unified CM ノードをデュアル EM サービス構成で展開し、7,500 人のユーザまたは 10,000 人のユーザ用の VM 構成を使用する場合、クラスタ内 EM ログインのレートは 1 分あたり 280 回のログイン/ログアウトにまで増加できます。
キャパシティ制限の詳細については、コラボレーション ソリューション サイジング ガイダンスの章を参照してください。
EMCC ログイン デバイス(Visiting 電話機)は、クラスタ内の他のエンドポイントの 2 倍のリソースを消費します。EMCC ログイン デバイスの最大サポート数はクラスタあたり 2,500 台ですが、これによっても、クラスタあたりの他のデバイスの理論的な最大数は 30,000 から 25,000 に減少します。クラスタ内の他の登録デバイス数を削減しても、EMCC ログイン デバイスの最大サポート数は 2,500 台のままです。
クラスタに追加できる EMCC リモート クラスタ数に技術的な制限はありません。ただし、リモート クラスタ数が増えると、フルメッシュ要件によって EM サービスの負荷は増大します。サイト数が多い(10 を超える)場合、Cisco Real Time Monitoring Tool(RTMT)を使用して EM の CPU をモニタする必要があります。
次のガイドラインと制限は、Unified CM 環境内の EM の配置と動作に関連して適用されます。
EM 機能は、コール ルーティングを IP ネットワークの使用に依存します。E.164 PSTN 番号は静的で、PSTN はホーム サイトからの EM ユーザのディレクトリ番号(DN)の移動を考慮に入れられないため、PSTN を通じたコール ルーティングにはより多くの問題が伴います。AAR は、VoPSTN 配置モデルと同様に、コール ルーティングを PSTN に依存します。いずれの場合も、ロケーションおよびサイト間の EM ユーザの移動は、ユーザの移動するすべてのサイトが同じ AAR グループに属する場合にだけサポートされます。詳細については、エクステンション モビリティを参照してください。
Cisco エクステンション モビリティ サービスを停止するまたは再起動する場合、システムは最大ログイン間隔が経過後のすでにログインしているユーザを自動ログアウトしません。これらの電話機は、手動でログアウトするか、毎日のデータベース クリーンアップ処理が実行されるのを待つ必要があります(通常は深夜)。
Cisco TelePresence エンドポイントなどの一部のシスコのエンドポイントはエクステンション モビリティをサポートしない場合があります。
WebDialer では、エクステンション モビリティを使用してログインされた電話機だけを使用できます。詳細については、WebDialerを参照してください。
EMCC を配置する場合、次の設計上の考慮事項が適用されます。
たとえば、EMCC は Visiting 電話機の動的 CTI 制御をサポートします。ただし、アプリケーションを介してオフフックが発行され、電話機がオフフックになるまでに 1 秒かかる場合、内勤者はこれを許容できてもコール センター エージェントは許容できない場合があります。
Cisco Unified CM Assistant は、Unified CM に統合されたアプリケーションです。これを使用すると、1 人または複数のマネージャに代わってアシスタントが着信コールを処理できます。Unified CM Assistant Console デスクトップ アプリケーションまたは Unified CM Assistant Console 電話サービスをアシスタントの電話機で使用すると、アシスタントが手早くマネージャの状態を確認し、コールをどうするかを決定できます。自分の電話機のソフトキーおよびサービス メニューを使用するか、または PC インターフェイスを介してキーボード ショートカット、ドロップダウン メニューを使用するか、あるいはマネージャのプロキシ回線へのコールのドラッグ アンド ドロップすることによって、アシスタントはコールを処理できます。
ここでは、Unified CM Assistant 機能の設計について次の項目を説明します。
Unified CM Assistant アプリケーションは、プロキシ回線モードとシェアド ライン モードの 2 つのモードで動作できます。各モードの動作と機能は異なり、それぞれに長所と短所があります。どちらのモードも、1 つのクラスタ内で設定できます。ただし、同一のアシスタントでモードを混合させることはできません。1 人以上のマネージャにサポートを提供している 1 人のアシスタントは、シェアド ライン モードまたはプロキシ回線モードのいずれかでこれらのマネージャをサポートできます。
図 18-7 は、プロキシ回線モードでの Unified CM Assistant の単純なコール フローを示しています。この例で、電話機 A は、ディレクトリ番号(DN)60001 でマネージャの電話機をコールします(ステップ 1)。CTI/Unified CM Assistant Route Point(RP)は、6XXXX に設定された DN に基づいてこのコールを代行受信します。次に、マネージャの DN に基づいて、コールはルート ポイントにより、アシスタントの電話機上のマネージャのプロキシ回線(DN:39001)に転送されます(ステップ 2)。次に、アシスタントはコールに応答または処理し、必要に応じてマネージャの電話機にコールを転送します(ステップ 3)。Unified CM Assistant アプリケーションの障害、または Unified CM Assistant RP の障害が発生した場合に、マネージャの DN へのコールがマネージャの電話機を直接呼び出すよう、RP の Call Forward No Answer(CFNA)の 6XXXX 設定による呼び出しメカニズムが存在します(ステップ 4)。
図 18-7 Unified CM Assistant のプロキシ回線モード
(注) 図 18-7 に示す CFNA による呼び出しメカニズムでは、Unified CM Assistant RP のディレクトリ番号設定ページの [Forward No Answer Internal] フィールドと [Forward No Answer External] フィールドの両方で、Unified CM Assistant RP ディレクトリ番号と同じ集約番号桁の設定が必要です。また、これらの各コール転送パラメータのコーリング サーチ スペース(CSS)フィールドは、Unified CM Assistant RP または Unified CM Assistant アプリケーションに障害が発生した場合にマネージャの電話機の DN に到達できるように、マネージャの電話機の DN が設定されたパーティションを含むコーリング サーチ スペースで設定する必要があります。
図 18-8 は、シェアド ライン モードでの Unified CM Assistant の単純なコール フローを示しています。この例で、電話機 A は、アシスタントの電話機のシェアド ラインであるディレクトリ番号(DN)60001 でマネージャの電話機をコールします(ステップ 1)。このコールは、アシスタントとマネージャの電話機の両方で着信音を鳴らします。ただし、マネージャが Do Not Disturb(DND)機能を呼び出した場合、着信音が鳴るのはアシスタントの電話機だけになります(ステップ 2)。
図 18-8 Unified CM Assistant のシェアド ライン モード
Unified CM Assistant のシェアド ライン モードでは、マネージャの電話機へのコールを代行受信するために Unified CM Assistant RP は必要ありません。ただし、マネージャの電話機および Unified CM Assistant Console デスクトップ アプリケーションの Do Not Disturb(DND)機能は、Cisco IP Manager Assistant(IPMA)および Cisco CTIManager サービスに依存します。さらに、Unified CM Assistant シェアド ライン モードでは、コール フィルタリング、コール代行受信、アシスタント選択、Assistant Watch などの機能は使用できません。
Unified CM Assistant アプリケーションのアーキテクチャは、その機能と同様に、そのアーキテクチャについても理解することが重要です。図 18-9 は、Unified CM Assistant のメッセージ フローとアーキテクチャを示しています。Unified CM Assistant のマネージャおよびアシスタント ユーザに対して Unified CM Assistant を設定すると、次の一連の対話とイベントが発生します。
1. マネージャとアシスタントの電話機は Cisco CallManager サービスに登録され、コール フロー処理にキーパッドとソフトキーが使用されます(図 18-9 のステップ 1 を参照)。
2. Unified CM Assistant Console デスクトップ アプリケーションと Manager Configuration Web ベース アプリケーションは、どちらも Cisco IP Manager Assistant サービスと通信およびインターフェイスします(図 18-9 のステップ 2 を参照)。
3. 次に、Cisco IP Manager Assistant サービスは、回線モニタリング情報および電話制御情報を交換するために、CTIManager サービスと対話します(図 18-9 のステップ 3 を参照)。
4. CTIManager サービスは、Unified CM Assistant 電話制御情報を Cisco CallManager Service に渡し、さらに Unified CM Assistant RP をも制御します(図 18-9 のステップ 4 を参照)。
5. それと並行して、Cisco IP Manager Assistant サービスは、Unified CM データベースとの間で、Unified CM Assistant アプリケーション情報の読み取りと書き込みを行います(図 18-9 のステップ 5 を参照)。
6. マネージャは、Services または Applications ボタンを押すことにより、Unified CM Assistant 電話サービスを呼び出して、その電話機が加入している(Unified CM Assistant 電話サービスを含む)すべてのサービスのリストを返す IP Phone サービス サービスへのコールを生成できます(図 18-9 のステップ 6 を参照)。
Unified CM Assistant 電話サービスは Cisco IP Manager Assistant サービスで制御され、電話機を使用してマネージャによって加えられた設定の変更は、Cisco IP Manager Assistant サービスを通じて処理および伝達されます。
(注) Services Provisioning エンタープライズ パラメータが内部に設定されている場合、ステップ 1 および 2 はバイパスされます。一方、Services Provisioning が外部 URL または両方に設定されている場合、ユーザが回線ボタンまたはスピード ダイヤル ボタンを押して、Cisco IP Manager Assistant サービスへの直接コールを生成できるように、Service URL ボタンはユーザの電話機で Unified CM Assistant 電話サービスの設定ができます。ステップ 1 および 2 もバイパスされます。
図 18-9 Unified CM Assistant のアーキテクチャ
(注) 図 18-9 は、同じノードですべてが実行されている IP Phone Service、Cisco CallManager、CTIManager、および Cisco IP Manager Assistant サービスを示していますが、この設定は必須ではありません。これらのサービスではクラスタ内の複数のノードに分散できますが、説明を簡単にするためにここでは同じノードにあるものとしています。
Unified CM Assistant アプリケーションの冗長性は、次の 2 つのレベルで実現できます。
このレベルでの冗長性については、Unified CM Assistant サービスまたはサーバの冗長性、および CTIManager サービスの冗長性に関して検討する必要があります。同様に、パブリッシャの冗長性の欠如、およびこのコンポーネントの障害の影響も検討する必要があります。
このレベルでの冗長性については、アシスタントとマネージャの電話機、Unified CM Assistant ルート ポイント、Unified CM Assistant Console デスクトップ アプリケーション、および電話サービスに関連して検討し、さらにアシスタントとマネージャの到達可能性に関する冗長性として検討する必要があります。
図 18-9 に示すように、Unified CM Assistant 機能は、主に Cisco IP Manager Assistant サービスおよび Cisco CTIManager サービスに依存します。いずれの場合も、冗長性はプライマリおよびバックアップのメカニズムを使用して自動的に組み込まれます。Unified CM Assistant サーバ(Cisco IP Manager サービスを実行しているノード)のアクティブおよびバックアップのペアは最大で 3 個まで定義できます。つまり、単一クラスタ内で合計 6 つの Unified CM Assistant サーバになります。アクティブおよびバックアップ Unified CM Assistant サーバ ペアは Cisco IPMA Server IP Address、Pool 2、Cisco IPMA Server IP Address、および Pool 3 Cisco IPMA Server IP Address サービス パラメータを使用して設定されます。これらのパラメータを設定することで、必要な Unified IP Assistant サービスに冗長性が与えられます。いずれかのプライマリ Unified CM Assistant に障害が発生した場合、バックアップまたはスタンバイ Unified CM Assistant サーバが Unified CM Assistant サービス要求を処理できます。Unified CM Assistant サーバの各ペアでは、任意の時点でアクティブになり、要求を処理する Unified CM Assistant サーバは 1 つだけです。その別の Unified CM Assistant サーバはスタンバイ状態になり、アクティブなサーバに障害が発生しない限り、要求を処理しません。
また、CTIManager (Primary) IP Address および CTIManager (Backup) IP Address サービス パラメータを使用して、2 つの CTIManager サーバまたはサービスを各 Unified CM Assistant サーバ用に定義できます。これらのパラメータを設定すると、CTIManager サービスに冗長性を与えることができます。このため、プライマリ CTIManager に障害が発生した場合でも、CTIManager サービスはバックアップ CTIManager から提供できます。クラスタ ノードのすべての Unified IP Assistant および CTIManager サービスに障害が発生した場合は、Unified CM Assistant ルート ポイントおよび Unified CM Assistant Console デスクトップ アプリケーションがダウンし、その結果 Unified CM Assistant アプリケーション全体がダウンします。ただし、前にも説明したように、Unified CM Assistant に障害が発生した場合、CFNA による呼び出しメカニズムは引き続き動作し、マネージャへのコールは直接マネージャの電話にルーティングできます。
(注) Unified IP Assistant シェアド ライン モードで設定した場合、Unified CM Assistant および CTIManager サービスが障害によって完全に停止しても、電話機は 1 本の回線を共有し続けるため、アシスタントは引き続きマネージャの代わりにコールを処理できます。ただし、Unified CM Assistant Console デスクトップ アプリケーションと DND の機能は、使用できなくなります。
図 18-10 は、WAN を通じたクラスタリングで、2 サイトの配置による Unified CM Assistant および CTIManager のプライマリ サーバとバックアップ サーバの冗長設定を示しています。最大限の冗長性を実現するため、サイト 1 のノードはプライマリ Unified CM Assistant サーバとして設定し、サイト 2 のノードはバックアップ Unified CM Assistant サーバとして設定します。WAN に障害が発生した場合、既存のプライマリ Unified CM Assistant サーバはサイト 2 から到達できなくなるため、サイト 2 のバックアップ Unified CM Assistant サーバがプライマリ Unified CM Assistant サーバになります。このようにすることで、クラスタオーバー WAN 環境で、Unified CM Assistant サーバは WAN の障害に対して冗長性を持つことができます。さらに、サイト 1 とサイト 2 の両方でプライマリおよびバックアップ CTIManager を設定すると、CTIManager は WAN の障害に対する冗長性を持ち、各サイトで CTIManager の障害に対して追加の冗長性が提供されます。
(注) 図 18-10 で説明するシナリオは、特別な状況を示しています。通常の動作時に、Unified CM Assistant サーバの任意ペアを同時にアクティブにすることはできません。Unified CM Assistant サーバのアクティブおよびバックアップ ペアがネットワークを通じて通信できる場合、一方のサーバはバックアップ モードとなり、要求を処理できません。
図 18-10 WAN を通じた 2 サイト クラスタリングによる Unified CM Assistant の冗長性
前に説明したように、パブリッシャは、Unified CM Assistant 情報を Unified CM データベースへ書き込みする時に単一の障害点となります。パブリッシャに障害が発生しても、Unified CM Assistant アプリケーションのすべての部分が引き続き動作します。ただし、Unified CM Assistant アプリケーション設定を変更できなくなります。パブリッシャが回復するまで、Unified CM Assistant Console デスクトップ アプリケーション、Manager Configuration Web ベース アプリケーション、電話機のソフトキー、または Unified CM Assistant 電話サービスを通じて設定を変更できません。この条件には、Do Not Disturb、DivertAll、Assistant Watch、コール フィルタリングなどの機能の有効化や無効化、およびコール フィルタとアシスタント選択設定の変更が含まれます。
デバイス レベルでの Unified CM Assistant の冗長性は、いくつかのメカニズムに依存しています。まず第 1 に、マネージャおよびアシスタントの電話機と Unified CM Assistant RP は、デバイス登録用のデバイス プールと Unified CM グループ設定の組み合わせによって提供される組み込み冗長性に依存します。
また、一部のデバイスは、追加の冗長性および機能のためにコンポーネント サービスに依存します。たとえば、Unified CM Assistant RP は呼制御機能に関して CTIManager にも依存するため、前の項で説明したプライマリおよびバックアップ CTIManager に依存する必要があります。Unified CM Assistant Console デスクトップ アプリケーションも、冗長性と機能がコンポーネント サービスに依存します。Assistant Console デスクトップ アプリケーションは、マネージャの着信コールの処理を持続できるように、プライマリ Unified CM Assistant サーバからバックアップ サーバ(およびその反対)への自動フェールオーバーをサポートしています。この自動フェールオーバーに要する時間は、Cisco Unified IPMA Assistant Console Heartbeat Interval および Cisco Unified IPMA Assistant Console Request Timeout のサービス パラメータを使用して制御できます。ハートビートまたはキープアライブの頻度は、Unified CM Assistant サーバの障害がデスクトップ アプリケーションですばやく検出されるように設定しますが、キープアライブをあまり頻繁に送信することで、ネットワークに悪影響を与えないように注意してください。多数の Assistant Console アプリケーションが使用されている場合、この考慮事項は特に重要です。
Unified CM Assistant Console 電話サービスは、Unified CM Assistant Console デスクトップ アプリケーションとは異なり、プライマリ Unified CM Assistant サーバに障害が発生した場合の冗長性には手動で調整する必要があります。プライマリ Unified CM Assistant サーバがダウンした場合、電話コンソールを使用しているアシスタントにはこの状態の表示が見えません。ただし、アシスタント電話では、ソフトキーを使用するときにメッセージ「Host not found Exception」を受信します。バックアップ Unified CM Assistant サーバで電話コンソールを引き続き使用するには、ユーザは IP Services メニューから再びログインして、セカンダリ Unified CM Assistant 電話サービスを手動で選択する必要があります。
マネージャおよびアシスタントの到達可能性に確実に冗長性を与えるフェールオーバー メカニズムは、他にもいくつかあります。第 1 に、(プロキシ回線モードで)Unified CM Assistant アプリケーションを通じてマネージャのアシスタントに送信されるコールは、設定した時間の経過後にそのコールへの応答がない場合、次の応答可能なマネージャのアシスタントに転送します。設定した時間の経過後に次のアシスタントがコールに応答しない場合、そのコールは次の応答可能なマネージャのアシスタントに再び転送され、それ以降も同様に転送が続けられます。このメカニズムは、Cisco IPMA RNA Forward Calls および Cisco IPMA RNA Timeout のサービス パラメータを使用して設定します。第 2 に、前述したように、クラスタ ノードのすべての Unified IP Assistant と CTI サービスに障害が発生した場合、Unified CM Assistant RP は使用できなくなります。ただし、Unified CM Assistant RP の CFNA 設定に基づいて、すべてのマネージャの DN に対するコールはマネージャの電話機に直接呼び出され、マネージャの到達可能性に十分な冗長性が与えられます。
Cisco Unified CM Assistant アプリケーションは、次のキャパシティをサポートしています。
Unified CM Assistant 最大でアシスタント 3500 人とマネージャ 3500 人(合計 7000 人)のキャパシティを実現するには、マルチの Unified CM Assistant サーバ プールを定義する必要があります。図 18-11 に示しているように、最大 3 個のプールを設定できます。各プールはプライマリおよびバックアップ Unified CM Assistant サーバおよびマネージャとアシスタントのグループで構成されています。Pool 1 の Unified CM Assistant サーバは Cisco IPMA Server(Primary/Backup)の IP Address サービス パラメータで設定し、Pool 2 のサーバは Pool2 で Cisco IPMA Server(Primary/Backup)の IP Address アドバンスト サービス パラメータで設定し、Pool 3 のサーバは Pool3 で Cisco IPMA Server(Primary/Backup)の IP Address アドバンスト サービス パラメータで設定します。
図 18-11 Unified CM Assistant Server Pools 環境下のマルチ アクティブ モード
Cisco Unified CM Assistant アプリケーションは、回線モニタリングおよび電話制御のために CTIManager と対話します。Unified CM Assistant 用のまたはマネージャ電話用の各回線(インターコム回線を含む)が CTI 回線を CTIManager と共に必要になります。また、各 Unified CM Assistant ルート ポイントは、CTI 回線インスタンスが CTIManager と共に必要になります。Unified CM Assistant を設定する場合、必要な CTI 回線または接続の数について、CTI 回線または接続に対する全体的なクラスタ制限と合わせて考慮する必要があります(クラスタごとの CTI 接続制限の詳細については、CTI のキャパシティ プランニングを参照してください)。他のアプリケーションの CTI 回線を追加する必要がある場合は、Unified CM Assistant のキャパシティが制限される可能性があります。
Unified CM Assistant には、重複および共有内線番号に関して次の制限があり、ディレクトリ番号のプロビジョニングを計画する場合に注意する必要があります。
Multiple Active Mode を有効にして複数の Unified CM Assistant サーバ プールを使用する場合は、Unified CM Assistant サーバ プールの間でマネージャおよびアシスタントが均等に分散されるようにして、適切なサーバ プール(1 から 3)がエンド ユーザの [Manager Configuration] ページの [Assistant Pool] フィールドで選択されることを確認します。マネージャに連携したアシスタントは、そのマネージャが設定されたプールに自動的に割り当てられます。
Unified CM Assistant は、CTI Manager に対する安全でない接続と安全な接続(トランスポート層セキュリティ)の両方をサポートします。
Cisco TelePresence System EX90 などの一部のシスコのエンドポイントは Cisco Unified CM Assistant をサポートしない場合があります。詳細については、次の Web サイトで入手可能な『 Feature Configuration Guide for Cisco Unified Communications Manager 』の最新バージョンを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
Unified CM Assistant のマネージャは、エクステンション モビリティ(EM)を使用して、プロキシ回線モードとシェアド ライン モードの両方でそれぞれの電話機にログインできます。ただし、そのマネージャは、エンド ユーザ ディレクトリの [Cisco Unified CM Assistant Manager] 設定ページで、Mobile Manager として設定する必要があります。Unified CM Assistant と組み合わせて EM を使用する場合、ユーザが EM を使用して複数の電話機にログインできないようにする必要があります。この動作は、EM サービス パラメータの Multiple Login Behavior を使用して有効または無効にできます。クラスタ内で同じユーザによる複数の EM ログインが必要な場合、EM を使用する Unified CM Assistant のマネージャに、複数の電話機にログインしないよう指示する必要があります。マネージャが EM で 2 つの異なる電話機にログインすることを許可すると、2 人のマネージャは異なるパーティション間でも同じ Unified CM Assistant 制御回線番号(DN)を持つことができないという、前述の制限に違反することになります。
(注) Unified CM のアシスタントは、Mobile Assistant の概念がないため、EM を使用してそれぞれの電話機にログインできません。
ダイヤル プラン設定は、プロキシ回線モードで設定される Unified CM Assistant では非常に重要です。マネージャの DN に対するコールが Unified CM Assistant RP で代行受信され、アシスタントの電話機に転送されることを保証するには、Unified CM Assistant RP およびアシスタントの電話機上のマネージャのプロキシ回線を除いて、すべてのデバイスからマネージャの DN に到達できないように、コーリング サーチ スペースおよびパーティションを設定する必要があります。
図 18-12 は、ダイヤル プラン コンポーネント内の各種デバイスのコーリング サーチ スペース、パーティション、および設定に対する最小要件を持つ、プロキシ回線モードの Unified CM Assistant ダイヤル プランの例を示しています。プロキシ回線モードでは 3 個のパーティションが必要です。図 18-12 の例では、次のパーティションになります。
また、2 つのコーリング サーチ スペースが必要です。図 18-12 の例では、次のコーリング サーチ スペースになります。
これは、この例でのダイヤル プランの範囲です。ただし、コール ルーティングが必要に応じて動作するように、適切なコーリング サーチ スペースでさまざまな電話機および Unified CM Assistant RP DN または回線を適切に設定することも重要です。この場合、すべてのユーザの回線、アシスタントのプライマリ(またはパーソナル)回線、およびマネージャの電話回線は、これらの回線すべてが Assistant_Everyone パーティションおよび Assistant_Route_Point パーティションのすべての DN に到達できるように、ASSISTANT_EVERYONE_CSS コーリング サーチ スペースで設定します。テレフォニー ネットワーク内のデバイスで設定されるインターコムなどの回線は、この同じコーリング サーチ スペースで設定します。すべてのマネージャのプロキシ回線およびすべての Assistant_RP 回線は、これらの回線すべてが Assistant_Manager パーティションのマネージャ DN および Assistant_Everyone パーティションに属するすべての DN に到達できるように、MANAGER_EVERYONE_CSS コーリング サーチ スペースで設定します。この方法により、ダイヤル プランでは、アシスタントの電話機の Assistant_RP 回線およびマネージャのプロキシ回線だけが、マネージャの電話機 DN に直接到達できるように確保します。
図 18-12 Unified CM Assistant のプロキシ回線モードのダイヤル プランの例
図 18-12 の例では、プロキシ回線モードでの Unified CM Assistant に関するダイヤル プランの最小要件を示しています。ただし、実際のテレフォニー ネットワークには、ほとんどの場合、Unified CM Assistant のコーリング サーチ スペースおよびパーティションとの統合が必要な追加または既存のダイヤル プラン要件があります。図 18-13 は、このような統合ダイヤル プランを示しています。この例では、前述したダイヤル プランは、2 つの追加のパーティションと 1 つの追加のコーリング サーチ スペースを処理する必要があります。図 18-13 では On Cluster パーティションが追加され、追加の電話機 DN もいくつか含まれています。On Cluster パーティションは、既存のデバイスがこれらの追加 DN に到達できるように、既存の Unified CM Assistant コーリング サーチ スペースの両方(ASSISTANT_EVERYONE_CSS および MANAGER_EVERYONE_CSS)に追加されています。UNRESTRICTED_CSS コーリング サーチ スペースも、既存のダイヤル プランに追加されています。このコーリング サーチ スペースは Assistant_Route_Point、Assistant_Everyone、および新たに追加した On Cluster パーティションで設定します。また、PSTN という別の新しいパーティションが追加されています。これには、共通ルート リスト(RL)、ルート グループ(RG)、およびボイス ゲートウェイ メカニズムを通じて、PSTN にコールをルーティングするために使用されるルート パターンのセットが含まれています。この PSTN パーティションは、UNRESTRICTED_CSS コーリング サーチ スペースの一部として設定します。
電話機およびデバイス回線のコーリング サーチ スペースの設定は、新しく追加したパーティションおよびコーリング サーチ スペースを組み込むために調整できます。ただし、Assistant_RP およびアシスタントの電話機のマネージャ プロキシ回線は、MANAGER_EVERYONE_CSS コーリング サーチ スペースに割り当てたままにする必要があります。この例で、マネージャには PSTN への無制限アクセスが与えられる可能性があるため、マネージャの電話回線は、最初に設定された ASSISTANT_EVERYONE_CSS コーリング サーチ スペースから、新しい UNRESTRICTED_CSS に移動されています。
図 18-13 Unified CM Assistant のプロキシ回線モードのダイヤル プラン統合の例
図 18-13 に示すように、追加のパーティションとコーリング サーチ スペースを新規または既存の Unified CM Assistant ダイヤル プランに統合することはできますが、基になるプロキシ回線モードのメカニズムが影響を受けないように注意する必要があります。
Unified CM Assistant シェアド ライン モードでは、特別なダイヤル プランのプロビジョニングは必要ありません。注意の必要な Unified CM Assistant RP またはプロキシ回線が存在しないため、マネージャとアシスタントの電話機は、ネットワーク内の他の電話機と同様にコーリング サーチ スペースおよびパーティションで設定できます。シェアド ライン モードに関する唯一の要件は、シェアド ラインの機能を実現できるように、マネージャとアシスタントの DN が同じパーティションに属する必要があることです。
Unified CM Assistant Console デスクトップ アプリケーションまたは Unified CM Assistant Console 電話サービスは、アシスタントがマネージャの代わりにコールを処理するために必要です。このデスクトップ アプリケーションは、コールを処理するためのグラフィカル インターフェイスをアシスタントに提供しますが、電話サービスはコールを処理するためのメニュー方式インターフェイスを提供します。デスクトップ アプリケーションと IP フォン サービスの両方では、アシスタントがマネージャの電話機の設定および環境の設定ができて、回線ステータスおよび可用性をモニタできます。また、このデスクトップ アプリケーションは、クリックコール スピード ダイヤルおよびディレクトリ エントリなど別の機能を備えています。この別の機能も従来のソフトキーおよびメニュー アプローチを使用してアシスタントの電話機で行うことができます。
Unified CM Assistant Console デスクトップ アプリケーションは、次の URL からインストールできます。
https:// <Server_IP-Address> :8443/plugins/CiscoUnifiedCallManagerAssistantConsole.exe
(ここで、 <Server_IP-Address> は、クラスタ内のいずれかのノードの IP アドレスです)
Unified CM Assistant Console 電話サービスは、いかなるインストールも必要がありません。アシスタントの電話機をコンソールとして使用可能にするには、アシスタントの電話機を Unified CM Assistant 電話サービスにサブスクライブします(これは、マネージャの電話機もサブスクライブする必要があることと同じサービスです)。
インストール後に、マネージャに代わってコールを処理するには、アシスタントがユーザ ID とパスワード(Cisco Unified CM の End-user ディレクトリで設定されている)を入力してアプリケーションにログインし、[Go Online] アイコンまたはメニュー項目をクリックして、ステータスを「online」に切り替える必要があります。ユーザがログインし、オンライン状態になると、デスクトップ アプリケーションは TCP ポート 2912 で Unified CM Assistant サーバと通信します。このアプリケーションは、トラフィックを受信する場合に一時的な TCP ポートを選択します。Cisco Unified CM 上の Unified CM Assistant サーバは、呼制御(コール フローの生成と処理)のためにデスクトップ アプリケーションとインターフェイスするので、TCP ポート 2912 で Cisco Unified CM から受信されたトラフィックは、Cisco Unified CM によって 24 の Diffserv コード ポイント(DSCP)または CS3 の Per Hop Behavior(PHB)として、QoS マーキングされます。この方法により、Unified CM Assistant 電話制御トラフィックは、その他のすべてのコール シグナリング トラフィックと同様に、ネットワークを通じてキューに入れることができます。
対称的なマーキングとキューを保証するため、Cisco Unified CM の TCP ポート 2912 を宛先とする Unified CM Assistant Console アプリケーション トラフィックも、DSCP 24(PHB CS3)としてマーキングする必要があります。これにより、このトラフィックが、Cisco Unified CM および Unified CM Assistant サーバに向かうネットワーク パスに沿って適切なコール シグナリング キューに配置されます。Unified CM Assistant Console アプリケーションは、すべてのトラフィックをベストエフォートとしてマーキングします。つまり、スイッチ ポート レベル(または、可能な限りコンソール PC に近いネットワーク パスに沿った場所で)アクセス コントロール リスト(ACL)を適用することで、アプリケーション PC から送信され、TCP ポート 2912 の Cisco Unified CM を宛先とするトラフィックを、DSCP 0(PHB Best Effort)から DSCP 24(PHB CS3)に再マーキングする必要があります。
Assistant Console デスクトップ アプリケーションのディレクトリ ウィンドウを使用すると、アシスタントは Cisco Unified CM Directory エンド ユーザを検索できます。ディレクトリ ウィンドウの [Name] フィールドに入力する検索文字列は、Unified CM Assistant サーバに送信され、Cisco Unified CM データベースに対して検索が直接実行されます。次に、Unified CM Assistant サーバによって、検索照会への応答がデスクトップ アプリケーションに返されます。
デスクトップ アプリケーションのディレクトリ検索によって生じる追加のトラフィックはわずかですが、1 つ以上の Unified CM Assistant コンソール アプリケーションがリモート サイトで実行されている集中型の呼処理配置では、このトラフィックが問題になることがあります。1 つのエントリが得られるディレクトリ検索では、Unified CM Assistant サーバからデスクトップ アプリケーションへの約 1 キロビットのトラフィックが発生します。1 回の検索あたり最大 25 のエントリを取得できるため、デスクトップ アプリケーションで実行される検索ごとに最大約 25 キロビットのトラフィックが生成されることがあります。ただし、Unified CM Assistant サーバからの低速 WAN リンクを通じて、複数の Unified CM Assistant Console デスクトップ アプリケーションでディレクトリ検索が実行されると、輻輳、遅延、およびキューの発生する可能性が高くなります。また、ディレクトリ検索トラフィックは、デスクトップに対するその他すべての Unified CM Assistant トラフィックと同様に、TCP ポート 2912 の Cisco Unified CM から発生します。つまり、ディレクトリ検索トラフィックも DSCP 24(PHB CS3)としてマーキングされるため、コール シグナリング トラフィックと同様にキューに入れられます。このため、ディレクトリ検索によって、呼制御トラフィックの輻輳、オーバーラン、または遅延が生じる可能性があります。
(注) ディレクトリ検索で 25 を超えるエントリが生成される場合、アシスタントには、ダイアログボックスを介して警告メッセージ「検索結果が 26 項目以上あります。(Your search returned more than 25 entries.)検索条件を設定し直してください。(Please refine your search.)」が表示されます。
ネットワーク輻輳の可能性を考慮に入れて、管理者は Unified CM Assistant Console ユーザに次の操作の実行を推奨することを推奨します。
Unified CM Assistant Phone Console 電話サービスを使用してマネージャに代わってコールを処理するには、アシスタントがユーザ ID と PIN(Unified CM の End-user ディレクトリで設定されている)を入力してアプリケーションにログインする必要があります。ユーザがログインしている状態になると、電話コンソール サービスは HTTPS および SCCP を使用して Unified CM と通信します。Unified CM Assistant コール生成および呼処理の呼制御トラフィックは、SCCP を使用して電話と Unified CM の間で送信されます。デフォルトでは、このトラフィックは 24 の Diffserv コード ポイント(DSCP)または CS3 の Per Hop Behavior(PHB)として、QoS マーキングされます。こうして、コール シグナリング トラフィックと同様にネットワークを通じてキューに入れられ確保します。したがって、追加の QoS の設定またはマーキングの必要はありません。
WebDialer は Cisco Unified CM のクリックコール アプリケーションで、ユーザはサポートされる任意の電話デバイスを使用して自分の PC から簡単にコールを発信できます。管理者が CTI リンクを管理したり、JTAPI または TAPI アプリケーションを作成したりするために必要なものはありません。Cisco WebDialer には、独自のユーザ インターフェイスと認証メカニズムを提供するための、簡単な Web アプリケーションと HTTP または Simple Objects Access Protocol(SOAP)が用意されているからです。
ここでは、WebDialer 機能の設計について次の項目を説明します。
WebDialer アプリケーションには、WebDialer サーブレットと Redirector サーブレットの 2 つのサーブレットが含まれています。サブスクライバ サーバで Cisco WebDialer Web サービスがアクティブである場合、両方のサーブレットが有効になります。これらのサーブレットは関連していますが、それぞれ異なる機能を提供し、同時に実行するように設定できます。
図 18-14 は、単純な WebDialer の例を示しています。この例では、ユーザ John Smith は Web ベースまたはデスクトップ アプリケーションから WebDialer を起動します(ステップ 1)。WebDialer は、ログイン クレデンシャル要求で応答します。ユーザは、Unified CM エンド ユーザ ディレクトリで設定される有効なユーザ ID とパスワードで応答する必要があります。この場合、John Smith は userID = jsmith および password = cisco を送信します(ステップ 2)。次に、このログインに基づいて、WebDialer は [Cisco WebDialer の初期設定(Cisco WebDialer Preferences)] 設定ページで応答し、ユーザは、[ユーザ指定デバイス(User preferred device)] または [エクステンション モビリティを使用する(Use Extension Mobility)] のいずれかを示す必要があります(ユーザが EM デバイス プロファイルを持つと想定して)。この場合、ユーザ John Smith は、[ユーザ指定デバイス(User preferred device)] を選択し、設定ページのドロップダウン メニューからその電話機に対して適切な MAC アドレス(SEP00036BC7B973)とディレクトリ番号(10001)を選択します(ステップ 3)。最後に、コールする電話番号を要求する画面が表示され(この値はすでに表示されていることがあります)、ユーザは [Dial] をクリックする必要があります。この場合、John Smith が 10002 と入力し、[Dial] をクリックすると、その電話機から番号 10002 の電話機 B へのコールが自動的に生成されます(ステップ 4)。
(注) ユーザが以前に WebDialer アプリケーションにログインし、Web ブラウザおよびサーバの Cookie がまだアクティブになっている場合、次の要求時に再ログインは求められません。Cookie がブラウザでクリアされるか、または WebDialer サーバの再起動によってクリアされた場合は、再ログインが要求されます。一方、ユーザ Web ブラウザ クッキーは期限を WebDialer サービス パラメータで設定できます。これは、WebDialer サービス パラメータで設定された通り所定の時間が経過した後、自動的に期限切れになります。
Redirector サーブレットは、マルチクラスタまたは分散型の呼処理環境において、WebDialer 機能を提供します。この機能を使用すると、すべての Unified CM クラスタ間で単一の企業全体の Web ベース WebDialer アプリケーションを使用できます。図 18-15 は、WebDialer アプリケーションの一部として Redirector サーブレットの基本的な動作を示しています。この例で、この企業には 3 個の Unified CM クラスタとして、New York、Chicago、および San Francisco があります。3 個のクラスタはすべて、単一の WebDialer アプリケーションで設定されます。San Francisco クラスタは、Redirector として指定されます。
企業全体の Web ベース アプリケーションは San Francisco の Redirector を指し、New York のユーザから起動されます(図 18-15 のステップ 1 を参照)。次に、Redirector はユーザのログインを要求し、New York ユーザは自分のユーザ ID とパスワードで応答します(図 18-15 のステップ 2 を参照)。
(注) ユーザが以前に WebDialer アプリケーションにログインし、Web ブラウザおよびサーバの Cookie がまだアクティブになっている場合、次の要求時に再ログインは求められません。一方、ユーザ Web ブラウザ クッキーは期限を WebDialer サービス パラメータで設定できます。これは、WebDialer サービス パラメータで設定された通り所定の時間が経過した後、自動的に期限切れになります。
次に、Redirector は、(List of WebDialers サービス パラメータの設定に従って)企業内のすべての WebDialer に isClusterUser HTTPS 要求を同時に送信します。この例で、要求は Chicago および New York の WebDialer サーバに送信されます(図 18-15 のステップ 3 を参照)。New York ユーザは New York クラスタに対してローカルであるため、New York の WebDialer は肯定応答を返します(図 18-15 のステップ 4 を参照)。最後に、New York ユーザはアプリケーション要求を処理するローカル WebDialer サーバに転送されます(図 18-15 のステップ 5 を参照)。この転送はユーザに通知されません。ただし、ブラウザのアドレス バーの URL は、ユーザが Redirector から WebDialer サーバに転送されたときに変更されます。この例では、1 個の Redirector のみ配置されます。ただし、Redirector に冗長性を提供するには、サービスとコンポーネントの冗長性に説明されているように複数のクラスタに Redirector を設定します。
(注) Redirector アプリケーションは、Unified CM データベースでのユーザ認証の必要な企業全体のアプリケーションであるため、すべての Unified CM クラスタですべてのエンド ユーザのユーザ ID を一意にすることを強く推奨します。一意でない場合、Redirector アプリケーションが isClusterUser 要求に対する複数の肯定応答を受信する可能性があります。この場合、Redirector アプリケーションによって、ユーザは自分のローカル WebDialer サーバを手動で選択するように求められます。このため、ユーザは自分のローカル サーバを知っている必要があります。正しくないサーバを選択した場合、WebDialer 要求は失敗します。
WebDialer アプリケーションのアーキテクチャは、その機能と同様に、そのアーキテクチャについても理解することが重要です。図 18-16 は、WebDialer のメッセージ フローとアーキテクチャを示しています。次の一連の対話とイベントが発生します。
1. WebDialer ユーザの電話機は、Cisco CallManager サービスを通じて登録し、コールの発信と受信を行います(図 18-16 のステップ 1 を参照)。
2. ユーザの PC 上の WebDialer アプリケーションは、次のいずれかのインターフェイスを通じて Cisco WebDialer Web Service と通信します(図 18-16 のステップ 2 を参照)。
このインターフェイスは、HTTPS プロトコルに基づいて Web ベースのアプリケーションで使用されます。これは、Redirector サーブレットへのアクセスを提供する唯一のインターフェイスです。
– Simple Object Access Protocol(SOAP)over HTTPS
このインターフェイスは、SOAP インターフェイスに基づいてデスクトップ アプリケーションで使用されます。
3. WebDialer Web サービスは、Unified CM データベースからユーザおよび電話の情報を読み取ります(図 18-16 のステップ 3 を参照)。
4. 次に、WebDialer Web サービスは、回線と電話の制御情報を交換するために、CTIManager サービスと対話します(図 18-16 のステップ 4 を参照)。
5. CTIManager サービスは、WebDialer 電話制御情報を Cisco CallManager サービスに渡します(図 18-16 のステップ 5 を参照)。
(注) 図 18-16 は、すべて同じノードで実行されている Cisco Unified CallManager、CTIManager、および WebDialer Web Service サービスを示していますが、この設定は必須ではありません。これらのサービスはクラスタ内の複数のノードに分散できますが、説明を簡単にするためにここでは同じノードにあるものとしています。
Web ベースのアプリケーションから HTML-over-HTTPS インターフェイスを通じて WebDialer アプリケーションにアクセスするには、次の URL を使用します。
https:// <Server-IP_Addr> :8443/webdialer/Webdialer?destination= <Number_to_dial>
(ここで、 <Server_IP-Address> は、Cisco WebDialer Web Service サービスを実行しているクラスタ内のノードの IP アドレスで、 <Number_to_dial> は WebDialer ユーザがダイヤルする番号です)
https:// <Server-IP_Addr> :8443/webdialer/Redirector?destination= <Number_to_dial>
(ここで、 <Server_IP-Address> は、Cisco WebDialer Web Service サービスを実行している企業内のノードの IP アドレスで、 <Number_to_dial> は WebDialer ユーザがダイヤルする番号です)
図 18-17 は、Cisco WebDialer アプリケーションをコールするクリックコール Web ベース アプリケーションで使用される、HTML ソース コードの例を示しています。この例で、HTML ソース ビューの URL https://10.1.1.1:8443/webdialer/Webdialer?destination=30271 は、Web ブラウザ ビュー内のユーザ Steve Smith 用の「Phone: 30721」リンクに対応しています。ユーザがこのリンクをクリックすると、WebDialer アプリケーションが起動し、ログイン後に Dial をクリックすると、そのユーザの電話機から Steve Smith の電話機へのコールが生成されます。URL を https://10.1.1.1:8443/webdialer/Redirector?destination=30271 に変更すると、Redirector を使用するクリックコール アプリケーションで同じコードを使用できます。
図 18-17 WebDialer URL の HTML の例
デスクトップ アプリケーションのクリックコールで使用される SOAP-over-HTTPS ソース コードの情報および例については、次の Web サイトで入手可能な『 Cisco WebDialer Developer Guide 』の WebDialer API Programming 資料を参照してください。
https://developer.cisco.com/site/webdialer/discover/getting-started/
WebDialer アプリケーションの冗長性は、次の 2 つのレベルで実現できます。
このレベルでの冗長性については、冗長性を、WebDialer サービスおよび CTIManager サービスの冗長性に関して検討する必要があります。同様に、パブリッシャの冗長性の欠如、およびこのコンポーネントの障害の影響も検討する必要があります。
このレベルでの冗長性については、ユーザの電話機および WebDialer ユーザ インターフェイスに関連して検討する必要があります。
図 18-16 に示すように、WebDialer 機能は、主に Cisco WebDialer Web Service および Cisco CTIManager サービスに依存します。WebDialer サービスはクラスタ内の複数のノードで有効にできます。これらの複数ノードへの到達可能性はデバイスと到達可能性の冗長性の項で説明されています。CTIManager の場合、冗長性は、プライマリおよびバックアップのメカニズムを使用して自動的に組み込まれます。Primary Cisco CTIManager および Backup Cisco CTIManager のサービス パラメータを使用すると、クラスタ内に 2 つの CTIManager サーバまたはサービスを定義できます。これらのパラメータを設定すると、CTIManager サービスに冗長性を与えることができます。このため、プライマリ CTIManager に障害が発生した場合でも、CTIManager サービスはバックアップ CTIManager から提供できます。Web ベース(またはデスクトップ)アプリケーションが指している WebDialer サーバに障害が発生し、クラスタ ノード上のプライマリおよびバックアップ CTIManager サービスにも障害が発生した場合、WebDialer アプリケーションはダウンします。WebDialer サービスは Unified CM パブリッシャに依存しません。
デバイス レベルでの WebDialer の冗長性は、いくつかのメカニズムに依存しています。まず第 1 に、ユーザの電話機は、デバイス登録用のデバイス プールと Unified CM グループ設定の組み合わせによって提供される組み込み冗長性に依存します。
複数の WebDialer サービスは冗長性を提供するために同じクラスタで複数の Unified CM サブスクライバを実行できます。しかしながら、多くのアプリケーションは複数の IP アドレスを処理するようには備わっていません。企業では、複数の WebDialer サーバのプレゼンスをマスクしてサーバ ロード バランサ(SLB)使用することを推奨します。SLB 機能は、仮想 IP アドレスまたは DNS-resolvable hostname を実現します。この DNS-resolvable hostname は、WebDialer サーバの実 IP アドレスのフロントエンドになるものです。Cisco IOS SLB 機能を実行するシスコ デバイスなど多くの SLB デバイスは、複数の WebDialer サーバおよび障害イベント発生時に自動的な転送要求のステータスをモニタする設定ができます。SLB 機能は、追加のクリックコール キャパシティを必要とする場合、ロード バランサ WebDialer 要求も設定できます。代替えとして、DNS Service(SRV)レコードも冗長性の提供に使用できます。
マルチ クラスタ環境と同様に、単一の Redirector サーブレットが複数の WebDialer をサポートする場合は、単一障害点になる可能性があります。この単一障害点を回避するために、各クラスタの Redirector サーブレットを設定し、Redirector サーバの実際の IP アドレスをフロントエンドにする仮想 IP アドレスまたは DNS-resolvable hostname を実現するためにサーバ ロード バランサ(SLB)を使用します。
WebDialer および Redirector サービスは Unified CM クラスタ内で複数のサブスクライバ ノードを実行でき、次のキャパシティがサポートされています。
次の一般式が WebDialer の 1 秒あたりのコール数の決定に使用できます。
(WebDialer のユーザ数)∗((平均 BHCA)/(3600 秒/時間))
この計算を行う場合、特に WebDialer サービスを使用した発信の、ユーザあたりの BHCA を適切に推定することが重要です。以下の例で、サンプルの組織に対して WebDialer デザイン計算式をどのように使用するかを示します。
例 18-1 WebDialer のコール数 1 秒あたりの計算
会社 XYZ は、WebDialer サービスを使用してクリックコール アプリケーションを稼働させることを考えています。その事前のトラフィック分析結果は次の資料の通りです。
(注) これらの値は、WebDialer 配置のサイジングの演習を示すために使用した例です。ユーザのダイヤル特性は、組織によって大きく異なります。
10,000 ユーザで各 6 BHCA ならば、合計 60,000 BHCA です。ただし、WebDialer 配置のサイジングの計算は、発信コールのみ考慮します。このサイジングの例で最初の情報では、合計 BHCA の 50 %が発信です。これは、WebDialer を用いたクリックコールが利用可能なすべてのユーザで、合計 30,000 発信 BHCA という結果になります。
この発信数のうち、WebDialer サービスを使用して発信される割合は、組織によって変化します。この例の組織では、ユーザはいくつかのクリックコール アプリケーションを利用可能で、発信の 30 % が WebDialer を使用すると見積もられています。
(30,000 発信 BHCA)∗ 0.30 = 9,000 発信 BHCA が WebDialer を使用
9,000 BHCA の負荷をサポートするのに必要な WebDialer サーバの数を判別するには、この値を最繁時に維持する必要のある平均の Busy Hour Call Attempt(BHCA)1 秒あたりに変換します。
(9,000 call attempts / 時間)∗(時間/3600 秒)= 2.5 cps
各 WebDialer サービスは最大で 4 cps をサポートできます。したがって、この例では、WebDialer サービスを実行するため 1 つのノードを設定できます。これは、将来の WebDialer 拡張使用に利用できます。障害の発生時に WebDialer キャパシティを維持するため、冗長性を提供する追加のバックアップ WebDialer サーバを設置する必要があります。
Cisco WebDialer アプリケーションは、電話制御のために CTIManager と対話することに留意してください。有効にすると、各 WebDialer サービスは単一持続性 CTI 接続を CTIManager に開きます。また、各 WebDialer の個々の MakeCall(または EndCall)要求は一時的な CTI 接続を生成します。WebDialer コール レートの処理に必要な CTI 接続の数も、クラスタごとの CTI 接続制限に対して適用されます(クラスタごとの CTI 接続制限の詳細については、CTI のキャパシティ プランニングを参照してください)。
次のガイドラインと制限は、Unified CM 環境内の WebDialer の配置と動作に関連して適用されます。
– 電話機が関連付けられていない状態でユーザが [Cisco WebDialer Preferences] 画面の [Use permanent device] を選択すると、Dial ボタンを押したときに次のメッセージが表示されます。
「ユーザ用に設定されているサポート済みデバイスはありません(No supported device configured for user)」
– デバイス プロファイルが関連付けられていない状態で(またはプロファイルを使用してログインしないで)ユーザが [Cisco WebDialer Preferences] 画面の [Use Extension Mobility] を選択すると、Dial ボタンを押したときに次のメッセージが表示されます。
「 <dialed_ number> へのコールに失敗しました:ユーザがログインしているデバイスがありません(Call to <dialed_ number> failed: User not logged in on any device)」
Cisco Computer Telephony Integration(CTI)をサポートするシスコのエンドポイントの一覧については、次の URL にある『 CTI (TAPI/JTAPI) Supported Device Matrix 』を参照してください。
https://developer.cisco.com/site/jtapi/wiki/cti-tapi-jtapi-supported-device-matrix/
アテンダント コンソールの統合によって、受付係は、組織内でその目的のために特別に設計された Microsoft Windows デスクトップ アプリケーションからコールに応答したり、コールを転送または送信したりできます。Cisco Unified Attendant Consoles はローカルおよび企業のディレクトリへのアクセスを提供し、ユーザはユーザ回線の状態、Jabber のステータス、Skype for Business のステータス(Cisco Unified Attendant Console Advanced のみ)を見ることができます。
Cisco Unified Communications ポートフォリオには、次の 2 つのエディションの Cisco Unified Attendant Console が用意されています。
このコンソールはユーザの電話機のモニタと制御を行うために Unified CM に直接統合されるローカル インストールです(「サーバレス」ソリューション)。コンソール アプリケーション経由で実行されるコール ルーティングと制御はソフトウェアへのログインに使用されるデバイスを模倣します。
このローカル アテンダント コンソール アプリケーションは中央の Cisco Unified Attendant Console Advanced Windows サーバ アプリケーションに接続します(Unified CM とは分離)。Cisco Unified Attendant Console Advanced サーバは Secure Socket Layer(SSL)を利用し、CTI および AXL 経由で Unified CM と通信します。すべてのコール ルーティングと制御は中央のサーバ アプリケーションによって実行されます。
ここでは、アテンダント コンソールの設計について次の項目を説明します。
次の設計上のガイドラインと制限は、Unified CM テレフォニー環境内の Cisco Unified Attendant Console Standard の導入および動作に適用されます。
共有回線およびコール ルーティングに関する設計上の考慮事項については、次の Web サイトで入手可能な最新バージョンの『 Cisco Unified Attendant Console Standard Installation and Configuration Guide 』を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-attendant-console-standard/model.html
図 18-18 に、サーバ ベースの Cisco Unified Attendant Console Advanced 統合の上位レベル アーキテクチャの概要を示しますソリューションの機能と動作を理解することにより、アーキテクチャ自体の理解も深まります。次の一連の手順(図 18-18 を参照)は、アテンダント コンソールへの一般的なコールに関係するイベントを示しています。
1. コールが Unified CM に入ります。着信番号は CTI ルート ポイントに設定されたディレクトリ番号と一致します。
2. CTI ルート ポイントは、アテンダント コンソール サーバ アプリケーションによって CTI が制御され、サーバに設定されているキュー Direct Dial In(DDI)に関連付けられます。
3. アテンダント コンソール サーバ アプリケーションは、コールを直接 Computer Telephony(CT)ゲートウェイ デバイスのいずれかに内部的にリダイレクトします。このプロセスの一環として、アテンダント コンソール サーバ アプリケーションは、コールを CTI ポートにリダイレクトする CTI リダイレクト メッセージを CTI Manager サービスに送信します。
(注) CTI リダイレクト メッセージでは、コールは接続されません。コールへの応答はなく、メディア接続もありません。
4. アテンダント コンソール サーバ アプリケーションはここで、コールを CT ゲートウェイ デバイスに関連付け、CTI ポートでそのコールを制御します。
5. この時点で、コールは、キュー DDI に関連付けられたシステム内のアテンダント コンソール クライアント アプリケーションに送信されます。
6. コンソール担当者がアテンダント コンソール クライアント アプリケーションを介してコールに応答することを選択すると、別の CTI リダイレクト メッセージが CTI Manager サービスに送信され、それによってコールが CTI ポートから応答するコンソール担当者の電話機に転送されます。コールは、コンソール担当者の電話機の設定に応じて、その電話機のハンドセットまたはヘッドセットに自動的に接続します。コンソール担当者の電話機および発信側のゲートウェイまたは電話機のリージョンとロケーションの設定によって、メディアに使用されるコーデックが決定します。
7. 別の内線番号への転送が必要である場合、コンソール担当者はアテンダント コンソール クライアント アプリケーションを介して転送を開始し、アテンダント コンソール サーバ アプリケーションに転送を伝達します。
8. アテンダント コンソール サーバ アプリケーションはそのコールを内部的にサービス キューに関連付け、CTI リダイレクト メッセージを CTI Manager サービスに送信します。これによって、コールはコンソール担当者の電話機からアテンダント コンソール サーバ アプリケーションによって制御される CTI ポートにリダイレクトされます。
(注) コール転送はコンソール担当者の電話機から発信される場合もありますが、その場合はアテンダント コンソール サーバ アプリケーションがコール フローから外れ、拡張機能(転送再コール機能など)は利用できなくなります。
9. この段階で、サービス キューは転送を実行する前にコールに実際に応答するので(短い接続があります)、アテンダント コンソール サーバ アプリケーションにインストールされた Cisco Media ドライバが起動します。この CTI ポートおよびコール開始ゲートウェイまたは電話機のリージョンとロケーションの設定によって、メディアに使用されるコーデックが決定します。設定されている CTI ポートの保留音(MoH)オーディオ ソースも、発信者に聞こえる MoH に影響します。転送はこのように実行されるので、応答がない場合、アテンダント コンソール クライアント アプリケーションが引き続きコールを制御します。最終的な相手がコールを受信すると、アテンダント コンソール サーバ アプリケーションはコール フローから外れます。
図 18-18 サーバ ベースの Cisco Unified Attendant Consoles のアーキテクチャ
アテンダント コンソール サーバ アプリケーションのコール パーク機能では、Unified CM の固有のコール パーク機能は使用されません。代わりに、コール パーク デバイスを使用する独自のコール パーク機能が使用されます。コール パーク デバイスは、図 18-18 のステップ 7 ~ 9 にあるように、サービス キューとほとんど同様に機能します。転送と同様に、コール パーク デバイスを利用することで、コールのパーク中にアテンダント コンソール サーバ アプリケーションがコールを制御できるようになります。
Cisco Unified Attendant Console Advanced は、2 台の Cisco Unified Attendant Console サーバを持つ復元性の高い構成にインストールできます。
CTI と AXL 通信の両方について、統合の両側に冗長性を備えることを検討する必要があります。
CTI に関しては、アテンダント コンソール サーバ アプリケーションは Cisco TAPI Telephony Service Provider(TSP)プラグイン(Unified CM からダウンロード)を使用して、CTI Manager サービスと通信します。Cisco TSP では、プライマリとバックアップの CTI Manager サービスを設定できます。プライマリの CTI Manager サービスがオフラインになった場合の復元性を高めるため、クラスタ内の少なくとも 2 つの Unified CM サブスクライバ ノードで CTI Manager サービスを有効にすることを推奨します。アテンダント コンソール サーバに障害が発生した場合の復元性を達成するには、キュー DDI に関連付けられた CTI ルート ポイントに対して設定された Call Forward Unregistered(CFU)および Call Forward CTI の障害接続先を利用します。アテンダント コンソール サーバ アプリケーションがオフラインになると、コールは自動的に Call Forward の設定に従います。たとえば、冗長アテンダント コンソールが配置されている場合、パブリッシャがオフラインになると、コールは Cisco Unified Attendant Console サブスクライバ サーバに転送されます。単一のアテンダント コンソール サーバでは、宛先として 1 台の IP Phone に関連付けられたハント パイロット番号またはディレクトリ番号(DN)を使用できます。
AXL 通信を有効にするには、Unified CM ノードで Cisco AXL Web Service をアクティブにします。複数の Unified CM ノードで Cisco AXL Web Service を有効にできますが、アテンダント コンソール サーバ アプリケーションには Unified CM 接続用に 1 つのエントリしか設定できません。障害が発生した場合、管理者は Cisco AXL Web Service を実行するバックアップ用の Unified CM ノードにこのエントリをアップデートできます。冗長 Cisco Unified Attendant Consoles が配置されている場合、アテンダント コンソール サーバは AXL Web Service の異なる Unified CM ノードで設定できます。
Unified CM には、Cisco Unified Attendant Console に属する一連の CTI ルート ポイントおよび CTI ポートが準備されています。関連付けられたデバイス プールにより、登録の維持を担当する Unified CM 呼処理ノードの優先順位付けされたリストを含む Unified CM グループが決定します。Unified CM グループ内のプライマリの Unified CM がオフラインである場合、CTI ルート ポイントと CTI ポートはセカンダリの Unified CM ノードを登録できるので、CTI ルート ポイントおよびポート自体のハイ アベイラビリティが実現します。
次の設計上のガイドラインと制限は、Unified CM テレフォニー環境内の Cisco Unified Attendant Console Advanced の導入および動作に適用されます。
1 つの一意なキュー DDI が、特にアテンダント コンソールにルーティングされる、システム内の一意の着信ディレクトリ番号ごとに必要です。
キュー DDI に入るすべての着信コールは、直接 CT ゲートウェイ デバイスにリダイレクトされます。CT ゲートウェイ デバイスが所定の時間に予想される最大着信コール数を処理するのに十分な台数になるよう、システムを設計してください。
コンソール担当者がコールを転送するか、コールを保留にするたびに、サービス キューが必要になります。システム内のすべてのコンソール担当者が所定の時間に転送する、または保留にするコールの最大数を維持できるだけの十分なサービス キューが用意されるように、システムを設計する必要があります。コンソール担当者ごとに 3 つか 4 つのサービス キューを用意することが一般的なガイドラインですが、シナリオによってはさらに多くのキューが必要になる場合もあります。
コンソール担当者がアテンダント コンソール クライアント アプリケーションを介してコール パーク機能を起動するたびに、コール パーク デバイスが必要になります。この機能では、Unified CM の固有のコール パーク機能は使用されません。所定の時間にシステム内のすべてのコンソール担当者がパークするコールの最大数を処理できるだけの十分なコール パーク デバイスが用意されるように、システムを設計してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-attendant-consoles/products-maintenance-guides-list.html
Cisco Unified Attendant Consoles Advanced に関する追加の設計ガイダンスについては、次の Web サイトで入手可能なマニュアルを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-attendant-consoles/products-implementation-design-guides-list.html
Cisco Unified Attendant Console のエディションの比較とそれぞれの機能については、Cisco Unified Attendant Console の製品ドキュメンテーションを参照してください。次の Web サイトで入手できます。
https://www.cisco.com/c/en/us/support/unified-communications/unified-attendant-consoles/tsd-products-support-series-home.html
Unified CM クラスタを正しくサイジングするには、Unified CM クラスタのスケーラビリティに影響する可能性がある相互依存変数が多数存在するため、シスコ代理店またはシスコのシステム エンジニアが Cisco Collaboration Sizing Tool( https://www.cisco.com/go/cst )を使用して、多数の CTI リソースと大量のコールを包含するすべての設計を検証する必要があります。サイジング ツールを使用すると、Attendant Console 設計基準を満たすために必要なサーバまたはクラスタの正確な台数を決定できます。
Cisco Paging Server は、ユーザが音声のみのメッセージを組織内の最大 50 の IP Phone のグループに送信できるようにします。Cisco Paging Server は基本的なページング モードの Singlewire InformaCast です。より大きい電話または他のエンドポイントのグループに通知、またはブロードキャストをスケジュールするユーザは、Advanced Notification モードへのアップグレードを検討する必要があります。
Cisco Paging Server はオープン仮想アプライアンス(OVA)として配布され、VMware 内で仮想マシンとして実行されます。この仮想マシンは Unified CM 仮想マシンと共存して実行する場合があります。Cisco Paging Server は、SIP、SNMP、AXL と CTI を使用して Unified CM と通信します。単一の Cisco Paging Server は Unified CM クラスタごとにサポートされます。
Cisco Paging Server は HTTP を使用して IP Phone と通信します。Cisco Paging Server 9.0.1 以降では、HTTP または CTI は電話機との通信に使用できます。HTTP モードでは、Cisco Paging Server はコマンドおよびクレデンシャルを IP Phone HTTP サーバに送信します。IP Phone は、クレデンシャルを検証し、次のコマンドを実行します。CTI モードでは、Unified CM 経由で各電話機にコマンドを送信します。CTI モードでは、Cisco Paging Server が各リクエストに対してクレデンシャルを送信する必要がないため、各電話機は Web サーバを有効化する必要がなく、コマンドがすばやく実行されます。また、CTI モードでは、話中電話機を迅速にチェックできます。
Cisco Paging Server が開始した後は、SNMP を使用して設定可能な間隔で Unified CM に接続します。Cisco Paging Server サーバは SNMP を使用して、他の Unified CM クラスタ メンバの IP アドレスと各クラスタ メンバに登録された電話機の一覧を検索します。SNMP 通信が完了すると、Cisco Paging Server は AXL を使用してデバイス名、説明、デバイス プール、コーリング サーチ スペース、電話番号やロケーションなどの各登録済みの電話に関する詳細情報を特定します。この情報は、 受信者グループ と呼ばれる論理電話機グループを作成するのに使用できます。Cisco Paging Server では、受信者グループには最大 50 の電話機を含めることができます。
ブロードキャストは常に Cisco Paging Server へのボイスコールとして開始されます。Cisco Paging Server でのこれらのコールに応答するサービスは DialCast と呼ばれます。DialCast は CTI や SIP 経由でコールを受信できます。CTI の場合、コールは CTI ルート ポイントに着信し、処理されます(Cisco Paging Server では CTI ポートは着信コールに応答する必要はありません)。SIP の場合、コールは SIP トランクの Unified CM から発信します。CTI と SIP の両方が有効でサポートされます。ただし、SIP のトラブルシューティングは CTI のトラブルシューティングよりもはるかに容易なため、CTI 経由の SIP コール フローを推奨します。
Cisco Paging Server はマルチキャストを使用して IP Phone に音声を送信します。マルチキャスト ストリームは Cisco Paging Server から発信され、IP Phone で受信されます(図 18-19 を参照)。
図 18-19 複数の電話機グループにメッセージを送信する Cisco Paging Server
図 18-19 に示すように、このシーケンスは Cisco Paging Server が 1 台以上の IP Phone に対してブロードキャストを開始する方法を説明します。
1. 発信者は、Unified CM で定義された番号にダイヤルします。この番号は、SIP トランクまたは CTI ルート ポイント経由で Cisco Paging Server にコールをルーティングします。
2. Cisco Paging Server は、このコールに DialCast コールとして応答します。
3. 発信者には低く小さいトーンが聞こえます。Cisco Paging Server はこのトーンを再生しますが、受信者グループ内の各電話機に HTTP 経由でコマンドを送信します。このコマンドは、各電話機にマルチキャスト グループに参加するよう要求します。
4. すべての電話機がマルチキャスト グループに参加すると、Cisco Paging Server はゴーサインを示す高いトーンを再生します。発信者にこのトーンが聞こえる場合、Cisco Paging Server が RTP ストリームを発呼側 IP Phone から受信側の電話機にマルチキャスト RTP ストリームとして送信していることを示します。発信者が話すと、その音声は受信側の電話に送信されます。
5. 発信者が切断すると Cisco Paging Server は各 IP Phone に別の要求を送信します。このとき、マルチキャスト グループから抜けてブロードキャストは終了します。
https://www.singlewire.com/compatibility-matrix
詳細については、次の URL から入手可能な『 InformaCast Virtual Appliance Basic Paging Installation and User Guide 』の最新バージョンを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/paging-server/products-maintenance-guides-list.html