Cisco Collaboration 9.xソリューション リファレンス ネットワーク デザイン(SRND)
Cisco Unified CM アプリケーション
Cisco Unified CM アプリケーション
発行日;2013/10/03 | 英語版ドキュメント(2013/09/09 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 30MB) | フィードバック

目次

Cisco Unified CM アプリケーション

この章の新規情報

IP Phone サービス

IP Phone Service のアーキテクチャ

IP Phone Service のハイ アベイラビリティ

IP Phone Service のキャパシティ プランニング

IP Phone Service の設計上の考慮事項

エクステンション モビリティ

エクステンション モビリティ対応 Unified CM Service

エクステンション モビリティのアーキテクチャ

クラスタ間のエクステンション モビリティ(EMCC)

呼処理

メディア リソース

エクステンション モビリティのセキュリティ

セキュア モードの電話機のサポート

エクステンション モビリティのハイ アベイラビリティ

エクステンション モビリティのキャパシティ プランニング

エクステンション モビリティの設計上の考慮事項

クラスタ間のエクステンション モビリティ(EMCC)の設計上の考慮事項

UnifiedCM Assistant

UnifiedCMAssistant のアーキテクチャ

UnifiedCMAssistant のプロキシ回線モード

UnifiedCMAssistant のシェアド ライン モード

UnifiedCMAssistant のアーキテクチャ

UnifiedCMAssistant のハイ アベイラビリティ

サービスとコンポーネントの冗長性

デバイスと到達可能性の冗長性

UnifiedCMAssistant のキャパシティ プランニング

UnifiedCMAssistant の設計上の考慮事項

UnifiedCMAssistant のエクステンション モビリティの考慮事項

UnifiedCMAssistant のダイヤル プランの考慮事項

UnifiedCMAssistant Console

UnifiedCMAssistant Console のインストール

UnifiedCMAssistant Console の QoS

UnifiedCMAssistant Console のディレクトリ ウィンドウ

UnifiedCM Assistant Phone Console の QoS

WebDialer

WebDialer のアーキテクチャ

WebDialer サーブレット

Redirector サーブレット

WebDialer のアーキテクチャ

WebDialer の URL

WebDialer のハイ アベイラビリティ

サービスとコンポーネントの冗長性

デバイスと到達可能性の冗長性

WebDialer のキャパシティ プランニング

WebDialer の設計上の考慮事項

Cisco Unified Attendant Consoles

アテンダント コンソールのアーキテクチャ

アテンダント コンソールのハイ アベイラビリティ

アテンダント コンソールのキャパシティ プランニング

アテンダント コンソールの設計上の考慮事項

Cisco Unified CM アプリケーション

Cisco Unified CM アプリケーションは、基礎的な IP テレフォニーに多数の動作および機能の拡張を提供します。 外部の eXtensible Markup Language(XML)生産性向上アプリケーションまたは IP Phone Service は、Web サーバまたはほとんどの Cisco Unified IP Phone 上のクライアント(あるいはその両方)で実行できます。たとえば、ユーザのデスク上の IP Phone を使用して、株式相場、天気情報、フライト情報など各種の Web ベースの情報を取得できます。また、カスタム IP Phone サービス アプリケーションを作成すると、ユーザが在庫を追跡したり、時間単位で顧客に課金したり、会議室の環境(照明、ビデオ画面、室温など)を制御できます。Cisco Unified CM には、次に示すような追加機能を提供する統合アプリケーションも多数あります。

Cisco Extension Mobility(EM)

Extension Mobility(EM; エクステンション モビリティ)機能では、モバイル ユーザがその電話機にログインすることで、一時的に Cisco Unified IP Phone をそのユーザ用に設定できます。

Cisco Unified Communications Manager Assistant(Unified CM Assistant)

Unified CM Assistant は、アシスタントが 1 人以上のマネージャ宛着信電話コールを処理できるようにする Cisco Unified CM に統合されたアプリケーションです。

Cisco WebDialer

WebDialer は Cisco Unified CM のクリックツーコール アプリケーションで、ユーザはサポートされる任意の電話デバイスを使用して自分の PC から簡単にコールを発信できます。

場合によっては、これらの統合アプリケーションが追加機能を提供するために、IP Phone Service を呼び出すこともあります。

この章では、次の Cisco Unified CM アプリケーションについて説明します。

「IP Phone サービス」

「エクステンション モビリティ」

「Unified CM Assistant」

「WebDialer」

また、この章では「Cisco Unified Attendant Consoles」についても説明します。

この章の新規情報

表 18-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 18-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明箇所
改訂日

マイナー アップデートと修正

この章の各項で説明

2013 年 4 月 2 日

Cisco Unified Attendant Console

「Cisco Unified Attendant Consoles」

2012 年 9 月 28 日

セキュア モードの電話機を備えた Extension Mobility Cross Cluster(EMCC)

「セキュア モードの電話機のサポート」

2012 年 6 月 28 日

Cisco Unified Communications システム Release 9.0 向けの、その他のマイナー アップデート

この章の各項で説明

2012 年 6 月 28 日

IP Phone サービス

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 Service のアーキテクチャ」

「IP Phone Service のハイ アベイラビリティ」

「IP Phone Service のキャパシティ プランニング」

「IP Phone Service の設計上の考慮事項」

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 サービス処理の詳細を示しています。ユーザが [Service] または [Applications] ボタンを押したとき、Services Provisioning が 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 フォンは 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 Service のアーキテクチャ

 

XML Services に加えて、[Service Category] が [Java MIDlet] の新しいサービスを作成できます。Java MIDlet タイプのサービスが起動されると、設定された Service URL には、MIDlet JAD ファイルを取得できる URL を含みます。アプリケーション サーバは JAD ファイルの要求を受信すると、そのサーバは適切な JAR ファイルを対応デバイスに返します。この対応デバイスでは、電話の MIDlet インストーラがダウンロードし、処理しましす。

Cisco IP Phone の Java MIDlet サポートの詳細については、 http://www.cisco.com の Cisco IP Phone データ シートを参照してください。


) 電話機はその設定ファイルを TFTP を介してダウンロードした後、電話機はリストのサービスが変わっていないかどうか判断するためサービス設定を解析し、変わっている場合にはそのローカル(持続)サービス設定を更新します。変更されたサービスが 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 Service URL を設定する機能を提供します。HTTPS をサポートする電話機は、自動的にセキュア URL を使用します。IP Phone の信頼検証サービスとセキュリティ認証処理の詳細、および HTTPS をサポートする電話機の全リストについては、次の Web サイトで入手可能な最新バージョンの『 Cisco Unified Communications Manager Security Guide 』で、HTTPS の情報を参照してください。

http://cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

IP Phone Service のハイ アベイラビリティ

電話機のユーザに対して信頼性の高いサービスを確保するには、システムの障害時に冗長システムにシームレスに移行することにより、高レベルのシステムの可用性を維持する必要があります。

Services Provisioning で内部にセットされる場合、電話機は加入した電話サービスが設定された設定ファイルを受信し、これら(および対応するサービス 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 Services パラメータの設定時に使用されます。SLB デバイスは、Unified CM サブスクライバ ノードの実 IP アドレスを使用して設定されます。このため、Cisco Unified CM サーバに障害が発生しても、電話機の Services または Applications ボタンが押されたときに、IP Phone Service 加入リストは電話機に正常に返されます。また、Cisco Unified CM サーバで実行されるエクステンション モビリティおよび Unified CM Assistant などの電話サービスも、この方法によって冗長性を持つ可能性があります (「エクステンション モビリティのハイ アベイラビリティ」および 「Unified CM Assistant のハイ アベイラビリティ」を参照)。

Cisco Application Control Engine(ACE)など多くの SLB デバイスは、障害発生時の複数のサーバと自動転送要求のステータスをモニタするように設定できます。Cisco Application Control Engine(ACE)の詳細については、次の Web サイトで入手可能なマニュアルを参照してください。

http://www.cisco.com/en/US/products/ps5719/Products_Sub_Category_Home.html

図 18-3 電話サービスに冗長性を提供する方法

 

障害シナリオ 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 要求を転送できます。

IP Phone Service のキャパシティ プランニング

Cisco Unified IP Phone サービスの大部分は、HTTP クライアントとして機能します。ほとんどの場合、加入サービスのロケーションへの転送サーバとしてだけ Unified CM が使用されます。Unified CM は電話サービスへの転送サーバとして機能するため、ユーザが Service キーを押して電話サービスを要求したときに、Unified CM へ与えるパフォーマンスの影響は通常最小限になります。しかし、多数の要求(1 分間に数百の要求)はサーバのパフォーマンスに影響する可能性があります。サーバ パフォーマンスへの影響をできる限り小さくするため、IP Phone サービスの外部 URL を指定する必要がない場合、通常は Services Provisioning エンタープライズ パラメータを Internal 設定のままにすることを推奨します。Services Provisioning を 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 ブラウザの帯域幅の推定に似ています。

IP Phone Service の設計上の考慮事項

統合されたエクステンション モビリティおよび Unified CM Assistant アプリケーションの電話サービスを除き、IP Phone サービスは独立したオフクラスタの Unified CM 以外の Web サーバに存在する必要があります。Unified CM サーバ ノードで、エクステンション モビリティおよび Unified CM Assistant 以外の電話サービスを実行することはサポートされていません。

ほとんどのシスコ製 IP Phone がテキストとグラフィックスを含むコンテンツをサポートしています。Cisco Unified IP Phone 7911G などの一部の電話機は、テキストベースの XML アプリケーションしかサポートしていません。Cisco TelePresence エンドポイントなどの一部のシスコのエンドポイントは Cisco IP Phone Service をサポートしない場合があります。

エクステンション モビリティ

Cisco Extension Mobility(EM; エクステンション モビリティ)機能では、ユーザがその電話機にログインすることで、一時的に Cisco Unified IP Phone をユーザ個別の設定に設定することが可能です。ユーザがログインすると、IP Phone には、回線番号、スピード ダイヤル、サービス リンク、およびその他のユーザ固有の電話機のプロパティなど、ユーザの個別のデバイス プロファイル情報が設定されます。たとえば、ユーザ X がデスクに向かって電話機にログインした場合は、そのユーザのディレクトリ番号、スピード ダイヤル、およびその他のプロパティがその電話機に表示されますが、ユーザ Y が別のときに同じデスクを使用した場合は、ユーザ Y の情報が表示されます。EM 機能では、認証されたユーザのデバイス プロファイルに従って電話機が動的に設定されます。このアプリケーションの利点は、電話機が EM をサポートしている限り、物理的な場所に関係なく、ユーザが Cisco Unified CM クラスタ内の任意の電話機で自分の内線番号に接続できることです。

ここでは、エクステンション モビリティ機能の設計について次の項目を説明します。

「エクステンション モビリティ対応 Unified CM Service」

「エクステンション モビリティのアーキテクチャ」

「エクステンション モビリティのセキュリティ」

「クラスタ間のエクステンション モビリティ(EMCC)」

「エクステンション モビリティのハイ アベイラビリティ」

「エクステンション モビリティのキャパシティ プランニング」

「エクステンション モビリティの設計上の考慮事項」

エクステンション モビリティ対応 Unified CM Service

EM アプリケーションは、Cisco エクステンション モビリティ サービスに依存します。このサービスは機能サービスであり、サービスアビリティのページから手動でアクティブにする必要があります。

EM は、インストール時にすべての Unified CM ノードで自動的にアクティブになる Cisco エクステンション モビリティ アプリケーション ネットワーク サービスにも依存します。

Cisco エクステンション モビリティ アプリケーション サービスは、EM ユーザ電話機と Cisco エクステンション モビリティ サービスとの間のインターフェイスを提供するネットワーク サービスです。また、Cisco エクステンション モビリティ アプリケーション サービスは、クラスタ内の変更通知インジケータにサブスクライブして、アクティブな Cisco エクステンション モビリティ サービスがあるクラスタ内のノードのリストを維持します。

エクステンション モビリティのアーキテクチャ

図 18-4 は、EM アプリケーションのメッセージ フローとアーキテクチャを示しています。電話機のユーザが EM アプリケーションにアクセスする場合、次の一連のイベントが発生します。

1. ユーザが電話機の Services または Applications ボタンを押すと、[Enterprise Parameter] 設定ページの [URL Services] パラメータで指定された URL に発信されます(図 18-4 のステップ 1 を参照)。

2. HTTP/XML コールが IP Phone Service に対して生成され、このコールはユーザの電話機が加入しているすべてのサービスのリストを返します(図 18-4 のステップ 2 を参照)。


) Services Provisioning エンタープライズ パラメータが内部に設定されている場合、ステップ 1 および 2 はバイパスされます。一方、Services Provisioning が外部 URL または両方に設定されている場合、ユーザが回線ボタンまたはスピード ダイヤル ボタンを押して、Cisco エクステンション モビリティ アプリケーション サービスへの直接コールを生成できるように、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 アプリケーションのアーキテクチャとメッセージ フロー

 

クラスタ間のエクステンション モビリティ(EMCC)

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 サイトで入手可能な最新バージョンの『 Cisco Unified Communications Manager Features and Services Guide 』で、クラスタ間のエクステンション モビリティの情報を参照してください。

http://cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

呼処理

EMCC 呼処理動作はダイヤル プランの設計に影響するため、これを理解することも重要です。ユーザが Visiting クラスタの電話機にログインすると、ユーザがダイヤルした数字はホーム クラスタによって、Visiting 電話機の集合コーリング サーチ スペース(CSS)に従って分析されます。これは、Visiting 電話機用のホーム クラスタのデバイス プール(EMCC ローミング デバイス プールと呼ばれる)内の付加 CSS、ユーザのデバイス プロファイルに関連付けられたディレクトリ番号に設定された回線 CSS、およびユーザのデバイス プロファイルに設定された EMCC CSS を連結したものです。図 18-6 に、EMCC 電話機の結果の CSS を示します。

図 18-6 EMCC 電話機の結果の CSS

 

付加コーリング サーチ スペースは、新規のコール ルーティング設定パラメータです。このパラメータは、EMCC により使用され、Visiting クラスタからユーザに対して緊急番号のインターセプトおよびルーティングを行います。付加 CSS には、911、112、または 999 などのディレクトリ番号の付いたパーティションがあります。このパーティションは、Visiting クラスタにコールをルーティングして、そのコールが電話機の物理的な場所に対してローカルな緊急サービスに連絡できるようにします。付加コーリング サーチ スペースと EMCC ローミング デバイス プールの詳細、および Visiting 電話機に関連付ける方法については、次の Web サイトで入手可能な最新バージョンの『 Cisco Unified Communications Manager Features and Services Guide 』で、クラスタ間のエクステンション モビリティの情報を参照してください。

http://cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html


) EMCC 機能に関連付けられた EMCC ローミング デバイス プールは、デバイス モビリティ機能に関連付けられたローミング デバイス プールとは関係ありません。


EMCC ユーザは、コールを発信する際に、ホームの Unified CM のルートおよび番号計画が利用されることを承知しておく必要があります。たとえば、クラスタ A のユーザがクラスタ B の電話機にログインして、すぐ隣のクラスタ B 電話機のディレクトリ番号にコールを発信する場合、ユーザは、クラスタ A からクラスタ B の電話機にコールを発信しているものとして、適切なパターンをダイヤルする必要があります。このことは、ホーム クラスタはクラスタ A からクラスタ B へのクラスタ間トランク コールを開始できますが、メディアは Visiting 電話機とリモート電話機間をローカルに流れることを意味します。

EMCC クラスタを +E.164 の番号指定を使用して配置する場合、ユーザはすでに相手の電話番号の完全な番号をダイヤルすることに慣れているので、ダイヤリング手順を変更する必要はありません。

ルーティングされた PSTN コールでは、呼処理動作に影響する次の 2 つの異なる設定があります。

ローカル ルート グループ(LRG)機能を使用しないルート パターン

LRG 機能を使用するルート パターン

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』を参照してください。http://www.cisco.com/en/US/products/sw/voicesw/ps842/prod_maintenance_guides_list.html



) 標準 LRG が緊急ルート パターン用にすでに配置されており、ホーム クラスタと Visiting クラスタが同じ緊急ダイヤル ストリングを使用する場合、付加 CSS を使用する必要はありません。


詳細な EMCC 呼処理の例と設定については、次の Web サイトで入手可能な最新バージョンの『 Cisco Unified Communications Manager Features and Services Guide 』で、クラスタ間のエクステンション モビリティの情報を参照してください。

http://cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_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 サイトで入手可能な最新バージョンの『 Cisco Unified Communications Manager Security Guide 』で、HTTPS の情報を参照してください。

http://cisco.com/en/US/products/sw/voicesw/ps556/prod_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 サイトで入手可能な最新バージョンの『 Cisco Unified Communications Manager Features and Services Guide 』で、クラスタ間のエクステンション モビリティの情報を参照してください。

http://cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_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 と 9. x のどちらが実行されているかにかかわりなく、失敗します。同様に、セキュア モードの電話機から Unified CM 8. x を実行中のホーム クラスタへの EMCC ログイン試行は、Visiting クラスタで Unified CM 8. x と 9. x のどちらが実行されているかにかかわりなく、失敗します。 表 18-2 にこの動作を示します。

 

表 18-2 EMCC ログイン後の電話機のセキュリティ モード

Visiting クラスタ
Unified CM 8. x を実行中のホーム クラスタ
Unified CM 9. x を実行中のホーム クラスタ
混合モードまたはノンセキュア モード
混合モード
ノンセキュア モード

セキュア モードの電話機。Visiting クラスタは Unified CM 8. x を実行中

EMCC ログインに失敗

EMCC ログインに失敗

EMCC ログインに失敗

セキュア モードの電話機。Visiting クラスタは Unified CM 9. x を実行中

EMCC ログインに失敗

セキュア モード

EMCC ログインに失敗

ノンセキュア モードの電話機。Visiting クラスタは Unified CM 8. x または 9. x を実行中(混合モードまたはノンセキュア モードの Visiting クラスタ)

ノンセキュア モード

ノンセキュア モード

ノンセキュア モード


) Cisco Unified CM 9.0 では、EMCC SIP トランクをセキュア プロファイルで設定できません。したがって、ローカル PSTN へのコールは、シグナリングにセキュア チャネルを使用しません。ただし、電話と PSTN ゲートウェイがセキュア モードで設定されている場合、メディアは暗号化されます。


エクステンション モビリティのハイ アベイラビリティ

図 18-4 に示す EM アーキテクチャに従って、Unified CM データベースの読み取りおよび書き込みが要求されます。EM はユーザに面した機能であって、データベースの書き込みは、EM がサブスクライバ ノードで実行できるかどうかに関係します。したがって、Unified CM パブリッシャが利用できない場合、その場合でも EM ログインおよびログアウトはできます。

冗長性の見地から、次のコンポーネント レベルの冗長性については、全面的な EM の復元性を得るよう検討する必要があります。

Cisco CallManager Cisco IP Phone サービス

CallManager Cisco IP Phone Services のハイ アベイラビリティは、Services Provisioning サービス パラメータの使用、または Cisco CallManager Cisco IP Phone Services を実行する複数の Unified CM ノードを指す SLB デバイスの使用により実現されます。詳細については、「IP Phone Service のハイ アベイラビリティ」を参照してください。

Cisco エクステンション モビリティ サービス

Cisco エクステンション モビリティ サービスのハイ アベイラビリティは、Cisco エクステンション モビリティ サービスを複数の Unified CM ノードでアクティブにすることにより実現されます。


) Cisco エクステンション モビリティ サービスは、3 つ以上のノードでアクティブにできますが、最大 2 つのノードが、ログイン/ログアウト要求を常にアクティブに処理できます。Cisco エクステンション モビリティ サービスを実行している他のノードは、障害が発生した場合にのみログイン/ログアウト要求の処理を開始する必要があります。


2 つの Unified CM ノード間の要求をロード バランシングしたり、冗長性を提供したりするため、Cisco Application Control Engine(ACE)などのサーバ ロード バランサ デバイスの導入を推奨します。サーバ ロード バランサがない場合、ロード バランシングは均等でなく、冗長性には手動で対応します。たとえば、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 つのノードだけでのログイン/ログアウト要求処理を常に確保するには、Cisco Application Control Engine(ACE)などのサーバ ロード バランサ デバイスを配置する必要があります。Cisco Application Control Engine には、プライマリ サーバがダウンしているかどうかを検出し、障害が発生した場合にバックアップ サーバに要求の送信を開始する機能があります。Cisco Application Control Engine(ACE)の設定の詳細については、次の Web サイトで入手可能なマニュアルを参照してください。

http://www.cisco.com/en/US/products/ps5719/Products_Sub_Category_Home.html


) 複数の 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 サイトで入手可能な『 Cisco Unified Communications Manager Features and Services Guide 』の「Cisco Extension Mobility Cross Cluster」のセクションを参照してください。

http://cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

ホーム クラスタへの登録を可能にする EMCC 設定ファイルをダウンロードするために Visiting 電話機が使用する、デフォルトおよびバックアップの Unified CM TFTP サーバを設定することも推奨します。これは、[EMCC Feature Configuration] で設定します。

エクステンション モビリティのキャパシティ プランニング

単一の Unified CM で Cisco エクステンション モビリティ アプリケーションを実行中の場合、MCS 7845-H2/I2 または MCS 7845-I3 サーバ、もしくは同等 OVA を使用中の仮想マシンでは、クラスタ全体の最大キャパシティは 1 分あたり 250 ログイン/ログアウトです。Cisco エクステンション モビリティ ログインおよびログアウト機能は、ログイン/ログアウトのクラスタ キャパシティを増加するためにサブスクライバ ノードのペアに分散できます。SLB デバイスを使用できます。または、手動で EM 負荷を 2 つのサブスクライバ ノード間で均等に分散するには、サブスクライバ ノードの 1 つを指している EM 電話サービスに加入している 1 つの電話機グループと、2 番めのサブスクライバ ノードを指している別の EM 電話サービスに加入している別の電話機グループの、2 つのグループに電話機を分割する必要があります。EM 負荷がこの方法で分散され、2 台の MCS 7845-H2/I2/I3 サーバまたは同等の OVA を使用する 2 台の仮想マシンの間で均等な場合、クラスタ全体の最大キャパシティは 1 分あたり 375 回の連続ログイン/ログアウトになります。


) Cisco エクステンション モビリティ サービスは、冗長性を目的として 3 つ以上のノードでアクティブにできますが、最大 2 つのサブスクライバ ノードによるログイン/ログアウトのアクティブな処理を常にサポートしています。



) EM セキュリティの有効化はパフォーマンスを低下しません。


EMCC ログイン/ログアウト処理は、クラスタ内 EM ログイン/ログアウトよりも多くの処理リソースを必要とします。したがって、サポートされるログイン/ログアウトの最大レートは低くなります。クラスタ内 EM ログイン/ログアウトがない場合、Unified CM は、Cisco MCS 7845-H2/I2 および MCS 7845-I3 サーバまたは同等の OVA で 1 分あたり 75 回の EMCC ログイン/ログアウトという最大レートをサポートします。ほとんどの配置では、クラスタ内ログイン/ログアウトとクラスタ間ログイン/ログアウトの組み合わせが発生します。より一般的なこのシナリオでは、EMCC ログイン/ログアウトの混合(ホーム クラスタまたは Visiting クラスタのどちらとして機能する場合でも)は、1 分あたり 40 回のモデルにする必要があります。同時にクラスタ内 EM ログインは、シングル EM ログイン サーバを使用する場合、185 回のログイン/ログアウトのモデルにする必要があります。クラスタ内 EM ログイン レートは、デュアル EM サービス設定で MCS 7845-H2/I2 もしくは MCS 7845-I3 サーバまたは同等の OVA を使用する場合、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 ユーザは、自動代替ルーティング(AAR)または Voice over PSTN(VoPSTN)、あるいはその両方の配置モデルが使用されている場合、クラスタ内のロケーションまたはサイト間で移動できません。

EM 機能は、コール ルーティングを IP ネットワークの使用に依存します。E.164 PSTN 番号は静的で、PSTN はホーム サイトからの EM ユーザのディレクトリ番号(DN)の移動を考慮に入れられないため、PSTN を通じたコール ルーティングにはより多くの問題が伴います。AAR は、VoPSTN 配置モデルと同様に、コール ルーティングを PSTN に依存します。いずれの場合も、ロケーションおよびサイト間の EM ユーザの移動は、ユーザの移動するすべてのサイトが同じ AAR グループに属する場合にだけサポートされます。 詳細については、「エクステンション モビリティ」を参照してください。

Cisco エクステンション モビリティ サービスまたはこのサービスを実行中のノードの再起動は、自動ログアウト設定に影響を与えます。

Cisco エクステンション モビリティ サービスを停止するまたは再起動する場合、システムは最大ログイン間隔が経過後のすでにログインしているユーザを自動ログアウトしません。これらの電話機は、手動でログアウトするか、毎日のデータベース クリーンアップ処理が実行されるのを待つ必要があります(通常は深夜)。

Cisco TelePresence エンドポイントなどの一部のシスコのエンドポイントはエクステンション モビリティをサポートしない場合があります。

WebDialer では、エクステンション モビリティを使用してログインされた電話機だけを使用できます。詳細については、「WebDialer」を参照してください。

クラスタ間のエクステンション モビリティ(EMCC)の設計上の考慮事項

EMCC を配置する場合、次の設計上の考慮事項が適用されます。

一般的な設計上の考慮事項

EMCC では、企業内のすべてのクラスタにわたってユーザは一意である必要があります。LDAP 同期によって複数のクラスタの共通ユーザが保守されている場合は、ある種のフィルタリングを適用する必要があります。

使用を計画している機能との組み合わせで、クラスタ間のネットワーク遅延を考慮します。Visiting 電話機がホーム クラスタに登録されると、機能は動作します。ただし、特定の配置のネットワーク遅延によっては、すべてのアプリケーションおよび機能がユーザ要件を満たすとはかぎりません。特定のネットワークに対して機能の操作性を判断するためにテストが必要な場合があります。

たとえば、EMCC は Visiting 電話機の動的 CTI 制御をサポートします。ただし、アプリケーションを介してオフフックが発行され、電話機がオフフックになるまでに 1 秒かかる場合、内勤者はこれを許容できてもコール センター エージェントは許容できない場合があります。

ログイン プロセス中に電話機ロード ファームウェアは強制されません。代わりに、クロス登録によって新しい電話機ファームウェアがダウンロードされないように、Visiting クラスタの電話機ロード情報が保守されます。

ホーム クラスタのロケールが Visiting クラスタのロケールと異なる場合、電話機は Visiting クラスタの TFTP サーバから新しいロケールをダウンロードします。そのロケールを使用できない場合、電話機はロケールを変更せず、Visiting クラスタのロケールを保守します。

登録された Visiting 電話機に対してホーム クラスタでライセンスは消費されません。

EMCC ログインの合計数は、Bulk Administration Tool(BAT)の EMCC 挿入デバイスの合計数によって制御されます。

EMCC は、RSVP ベースのコール アドミッション制御だけをサポートします。Unified CM のロケーションベースのコール アドミッション制御はサポートされません。

RSVP Agent を除き、その他のすべてのメディア リソースは、EMCC ローミング デバイス プールに関連付けられたメディア リソース グループ リストに従って、ホーム クラスタから割り当てられます。

オーディオおよびビデオ コーデックは、EMCC リージョン設定によって決まります。これらの設定は、EMCC 登録電話機の通常のリージョン設定よりも優先されます。すべての EMCC リージョン パラメータは、すべてのクラスタで同じ値を使用して設定する必要があります。異なる場合、そのクラスタの RSVP Agent は、リモート クラスタ更新操作によって使用不可になります。

EMCC ローミング デバイス プールを正しく割り当てるには、EMCC 対応電話機に、デバイス設定またはデバイス プール経由で設定されたジオロケーションが必要です。

呼処理の設計上の考慮事項

ユーザのディレクトリ番号の着信コールは常にホーム クラスタの音声ゲートウェイで受信されるため、着信コールでは RTP メディアは Visiting 電話機とホーム ゲートウェイ間を流れます。

EMCC SIP トランクを介して送信されるコールは、ホーム クラスタの番号操作を通過します。コールされる番号には、Visiting クラスタのルート パターンと一致するために操作が必要な場合があります。

ホーム クラスタの H.323 および SIP ゲートウェイの設定済みコーデック能力を確認します。たとえば、ホーム クラスタのゲートウェイが G.711 コールだけを受け入れるように設定されており、EMCC リージョンの帯域幅が 8 kbps(G.729)に設定されている場合、コールを完了するにはトランスコーダが必要です。あるいは、G.711 以外に G.729 を許可するように、H.323 または SIP ゲートウェイ ダイヤル ピアを設定できます。

EMCC 緊急コールの発信者について、設計上の考慮事項を作成する必要があります。ダイヤル プラン設定によっては、Visiting クラスタのゲートウェイからの発呼側番号は、通常はホーム クラスタに関連付けられる、ユーザの DID である場合があります。このことにより、EMCC SIP トランクまたはルート パターンで着信する、または Visiting ゲートウェイで発信する発呼側番号を変換する必要があります。

EMCC が Cisco Emergency Responder とともに配置される場合、Emergency Responder は、1 つの Emergency Responder クラスタによって処理されるすべてのクラスタに配置される必要があります。Visiting クラスタが Emergency Responder とともに配置され、ホーム クラスタは Emergency Responder とともに配置されない場合、コールが Visiting クラスタに戻ったときに Emergency Responder は Visiting 電話機を識別できません。

Unified CM Assistant

Cisco Unified CM Assistant は、Unified CM に統合されたアプリケーションです。これを使用すると、1 人または複数のマネージャに代わってアシスタントが着信コールを処理できます。Unified CM Assistant Console デスクトップ アプリケーションまたは Unified CM Assistant Console 電話サービスをアシスタントの電話機で使用すると、アシスタントが手早くマネージャの状態を確認し、コールをどうするかを決定できます。自分の電話機のソフトキーおよびサービス メニューを使用するか、または PC インターフェイスを介してキーボード ショートカット、ドロップダウン メニューを使用するか、あるいはマネージャのプロキシ回線へのコールのドラッグ アンド ドロップすることによって、アシスタントはコールを処理できます。

ここでは、Unified CM Assistant 機能の設計について次の項目を説明します。

「Unified CM Assistant のアーキテクチャ」

「Unified CM Assistant のハイ アベイラビリティ」

「Unified CM Assistant のキャパシティ プランニング」

「Unified CM Assistant の設計上の考慮事項」

「Unified CM Assistant Console」

Unified CM Assistant のアーキテクチャ

Unified CM Assistant アプリケーションは、プロキシ回線モードとシェアド ライン モードの 2 つのモードで動作できます。各モードの動作と機能は異なり、それぞれに長所と短所があります。どちらのモードも、1 つのクラスタ内で設定できます。ただし、同一のアシスタントでモードを混合させることはできません。1 人以上のマネージャにサポートを提供している 1 人のアシスタントは、シェアド ライン モードまたはプロキシ回線モードのいずれかでこれらのマネージャをサポートできます。

Unified CM Assistant のプロキシ回線モード

図 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 が設定されたパーティションを含むコーリング サーチ スペースで設定する必要があります。


Unified CM Assistant のシェアド ライン モード

図 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 のアーキテクチャ

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 Service サービスへのコールを生成できます(図 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 のハイ アベイラビリティ

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 サーバになります。このように、Unified CM Assistant サーバは、WAN 障害を前提として、クラスタオーバー 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 に対するコールはマネージャの電話機に直接呼び出され、マネージャの到達可能性に十分な冗長性が与えられます。

Unified CM Assistant のキャパシティ プランニング

Cisco Unified CM Assistant アプリケーションは、次のキャパシティをサポートしています。

マネージャあたり最大 10 人のアシスタントを設定できる。

1 人のアシスタントに対して最大 33 人のマネージャを設定できる(マネージャ毎に 1 つの Unified CM Assistant 制御回線がある場合)。

クラスタあたり最大 3500 人のアシスタントと 3500 人のマネージャを、Cisco MCS 7845 または同等の OVA を使用して設定できる(合計 7000 人)。

プライマリおよびバックアップ Unified CM Assistant サーバのペアをクラスタあたり最大 3 組配置できる。ただし、Enable Multiple Active Mode アドバンスト サービス パラメータが True に設定され、Unified CM Assistant サーバの 2 番めおよび 3 番めのプールが設定されている場合。

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 回線が別のアプリケーションに必要になる場合、これらの CTI 回線によって Unified CM Assistant のキャパシティが制限される場合があります。

Unified CM Assistant の設計上の考慮事項

Unified CM Assistant には、重複および共有内線番号に関して次の制限があり、ディレクトリ番号のプロビジョニングを計画する場合に注意する必要があります。

プロキシ回線モードの Unified CM Assistant では、アシスタントの電話機のプロキシ回線番号は、異なるパーティション間でも一意にする必要があります。

プロキシ回線モードの Unified CM Assistant では、2 人のマネージャは異なるパーティション間でも、同じ Unified CM Assistant 制御回線番号(DN)を持つことができません。

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 サイトで入手可能な『 Cisco Unified Communications Manager Features and Services Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

Unified CM Assistant のエクステンション モビリティの考慮事項

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 のダイヤル プランの考慮事項

ダイヤル プラン設定は、プロキシ回線モードで設定される Unified CM Assistant では非常に重要です。マネージャの DN に対するコールが Unified CM Assistant RP で代行受信され、アシスタントの電話機に転送されることを保証するには、Unified CM Assistant RP およびアシスタントの電話機上のマネージャのプロキシ回線を除いて、すべてのデバイスからマネージャの DN に到達できないように、コーリング サーチ スペースおよびパーティションを設定する必要があります。

図 18-12 は、ダイヤル プラン コンポーネント内の各種デバイスのコーリング サーチ スペース、パーティション、および設定に対する最小要件を持つ、プロキシ回線モードの Unified CM Assistant ダイヤル プランの例を示しています。プロキシ回線モードでは 3 個のパーティションが必要です。図 18-12 の例では、次のパーティションになります。

すべての Unified CM Assistant RP DN を含む Assistant_Route_Point パーティション

すべてのアシスタントとその他のユーザの電話機 DN を含む Assistant_Everyone パーティション

すべてのマネージャの電話機の DN を含む Assistant_Manager パーティション

また、2 つのコーリング サーチ スペースが必要です。図 18-12 の例では、次のコーリング サーチ スペースになります。

Assistant_Route_Point パーティションおよび Assistant_Everyone パーティションを含む ASSISTANT_EVERYONE_CSS コーリング サーチ スペース

Assistant_Manager パーティションおよび Assistant_Everyone パーティションを含む MANAGER_EVERYONE_CSS コーリング サーチ スペース

これは、この例でのダイヤル プランの範囲です。ただし、コール ルーティングが必要に応じて動作するように、適切なコーリング サーチ スペースでさまざまな電話機および 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 デスクトップ アプリケーションまたは Unified CM Assistant Console 電話サービスは、アシスタントがマネージャの代わりにコールを処理するために必要です。このデスクトップ アプリケーションは、コールを処理するためのグラフィカル インターフェイスをアシスタントに提供しますが、電話サービスはコールを処理するためのメニュー方式インターフェイスを提供します。デスクトップ アプリケーションと IP フォン サービスの両方では、アシスタントがマネージャの電話機の設定および環境の設定ができて、回線ステータスおよび可用性をモニタできます。また、このデスクトップ アプリケーションは、クリックツーコール スピード ダイヤルおよびディレクトリ エントリなど別の機能を備えています。この別の機能も従来のソフトキーおよびメニュー アプローチを使用してアシスタントの電話機で行うことができます。

Unified CM Assistant Console のインストール

Unified CM Assistant Console デスクトップ アプリケーションは、次の URL からインストールできます。

https:// <Server_IP-Address> :8443/plugins/CiscoUnifiedCallManagerAssistantConsole.exe

(ここで、 <Server_IP-Address> は、クラスタ内のいずれかのノードの IP アドレスです)

Unified CM Assistant Console 電話サービスは、いかなるインストールも必要がありません。アシスタントの電話機をコンソールとして使用可能にするには、アシスタントの電話機を Unified CM Assistant 電話サービスにサブスクライブします (これは、マネージャの電話機もサブスクライブする必要があることと同じサービスです)。

Unified CM Assistant Console の QoS

インストール後に、マネージャに代わってコールを処理するには、アシスタントがユーザ 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)に再マーキングする必要があります。

Unified CM Assistant Console のディレクトリ ウィンドウ

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 を超えるエントリが生成される場合、アシスタントには、ダイアログボックスを介して警告メッセージ「Your search returned more than 25 entries.Please refine your search.」が表示されます。


ネットワーク輻輳の可能性を考慮に入れて、管理者は Unified CM Assistant Console ユーザに次の操作の実行を推奨することを推奨します。

ディレクトリ ウィンドウ検索機能の使用を制限する。

返されるエントリの数を減らすため、この機能を使用するときは、[Name] フィールドにできる限り多くの情報を入力し、ワイルドカードやブランクでの検索は実行しない。

これらの推奨事項は、次のいずれかの条件が該当する場合は特に重要です。

クラスタ内に多数の Unified CM Assistant Assistants が存在する。

Cisco Unified CM または Unified CM Assistant サーバ(あるいはその両方)から低速 WAN リンクによって分離されている多数のアシスタントが存在する。

Unified CM Assistant Phone Console の QoS

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

WebDialer は Cisco Unified CM のクリックツーコール アプリケーションで、ユーザはサポートされる任意の電話デバイスを使用して自分の PC から簡単にコールを発信できます。管理者が CTI リンクを管理したり、JTAPI または TAPI アプリケーションを作成したりするために必要なものはありません。Cisco WebDialer には、独自のユーザ インターフェイスと認証メカニズムを提供するための、簡単な Web アプリケーションと HTTP または Simple Objects Access Protocol(SOAP)が用意されているからです。Cisco Unified Communications Widget の クリックツーコール アプリケーションは SOAP インターフェイスを使用し、現在は次の Web サイトでダウンロードできます(ログイン認証が必要です)。

http://tools.cisco.com/support/downloads/go/Redirect.x?mdfid=278875240

ここでは、WebDialer 機能の設計について次の項目を説明します。

「WebDialer のアーキテクチャ」

「WebDialer のハイ アベイラビリティ」

「WebDialer のキャパシティ プランニング」

「WebDialer の設計上の考慮事項」

WebDialer のアーキテクチャ

WebDialer アプリケーションには、WebDialer サーブレットと Redirector サーブレットの 2 つのサーブレットが含まれています。サブスクライバ サーバで Cisco WebDialer Web サービスがアクティブである場合、両方のサーブレットが有効になります。これらのサーブレットは関連していますが、それぞれ異なる機能を提供し、同時に実行するように設定できます。

WebDialer サーブレット

図 18-14 は、単純な WebDialer の例を示しています。この例で、ユーザ John Smith は、Unified Communications Widget のクリックツーコールなどの Web ベース アプリケーションまたはデスクトップ アプリケーションから WebDialer を起動します(ステップ 1)。WebDialer は、ログイン クレデンシャル要求で応答します。ユーザは、Unified CM エンド ユーザ ディレクトリで設定される有効なユーザ ID とパスワードで応答する必要があります。この場合、John Smith は userID = jsmith および password = cisco を送信します(ステップ 2)。次に、このログインに基づいて、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 サービス パラメータで設定された通り所定の時間が経過した後、自動的に期限切れになります。


図 18-14 WebDialer サーブレットの動作

 

Redirector サーブレット

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 を設定します。

図 18-15 IRedirector サーブレットの動作

 


) Redirector アプリケーションは、Unified CM データベースでのユーザ認証の必要な企業全体のアプリケーションであるため、すべての Unified CM クラスタですべてのエンド ユーザのユーザ ID を一意にすることを強く推奨します。一意でない場合、Redirector アプリケーションが isClusterUser 要求に対する複数の肯定応答を受信する可能性があります。この場合、Redirector アプリケーションによって、ユーザは自分のローカル WebDialer サーバを手動で選択するように求められます。このため、ユーザは自分のローカル サーバを知っている必要があります。正しくないサーバを選択した場合、WebDialer 要求は失敗します。


WebDialer のアーキテクチャ

WebDialer アプリケーションのアーキテクチャは、その機能と同様に、そのアーキテクチャについても理解することが重要です。図 18-16 は、WebDialer のメッセージ フローとアーキテクチャを示しています。次の一連の対話とイベントが発生します。

1. WebDialer ユーザの電話機は、Cisco CallManager サービスを通じて登録し、コールの発信と受信を行います(図 18-16 のステップ 1 を参照)。

2. ユーザの PC 上の WebDialer アプリケーションは、次のいずれかのインターフェイスを通じて Cisco WebDialer Web Service と通信します(図 18-16 のステップ 2 を参照)。

HTML over HTTPS

このインターフェイスは、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 WebDialer のアーキテクチャ

 


図 18-16 は、すべて同じノードで実行されている Cisco Unified CallManager、CTIManager、および WebDialer Web Service サービスを示していますが、この設定は必須ではありません。これらのサービスはクラスタ内の複数のノードに分散できますが、説明を簡単にするためにここでは同じノードにあるものとしています。


WebDialer の URL

Web ベースのアプリケーションから HTML-over-HTTPS インターフェイスを通じて WebDialer アプリケーションにアクセスするには、次の URL を使用します。

WebDialer サーブレット

https:// <Server-IP_Addr> :8443/webdialer/Webdialer?destination= <Number_to_dial>

(ここで、 <Server_IP-Address> は、Cisco WebDialer Web Service サービスを実行しているクラスタ内のノードの IP アドレスで、 <Number_to_dial> は WebDialer ユーザがダイヤルする番号です)

Redirector サーブレット

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 Unified Communications Manager Developers Guide 』の WebDialer API Programming 資料を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_programming_reference_guides_list.html

WebDialer のハイ アベイラビリティ

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 Application Control Engine(ACE)または Cisco IOS SLB 機能など多くの SLB デバイスは、複数の WebDialer サーバおよび障害イベント発生時に自動的な転送要求のステータスをモニタする設定ができます。SLB 機能は、追加のクリックツーコール キャパシティを必要とする場合、ロード バランサ WebDialer 要求も設定できます。代替えとして、DNS Service(SRV)レコードも冗長性の提供に使用できます。

マルチ クラスタ環境と同様に、単一の Redirector サーブレットが複数の WebDialer をサポートする場合は、単一障害点になる可能性があります。この単一障害点を回避するために、各クラスタの Redirector サーブレットを設定し、Redirector サーバの実際の IP アドレスをフロントエンドにする仮想 IP アドレスまたは DNS-resolvable hostname を実現するためにサーバ ロード バランサ(SLB)を使用します。

企業の配置では、リンク コストもまた重要な考慮事項です。Cisco ACE Global Site Selector(GSS)アプライアンスは、リンク コストおよびロケーションをロード バランシング アルゴリズムを追加することで、その他の機能の 1 つとして、SLB 機能のキャパシティを拡張します。ACE および GSS の詳細については、 http://www.cisco.com を参照してください。

WebDialer のキャパシティ プランニング

WebDialer および Redirector サービスは Unified CM クラスタ内で複数のサブスクライバ ノードを実行でき、次のキャパシティがサポートされています。

各 WebDialer サービスは、ノードごとに 1 秒あたり最大 4 コール要求まで処理できます。

各 Redirector サービスは、1 秒あたり最大 8 コール要求まで処理できます。

次の一般式が WebDialer の 1 秒あたりのコール数の決定に使用できます。

(WebDialer のユーザ数)∗((平均 BHCA)/(3600 秒/時間))

この計算を行う場合、特に WebDialer サービスを使用した発信の、ユーザあたりの BHCA を適切に推定することが重要です。以下の例で、サンプルの組織に対して WebDialer デザイン計算式をどのように使用するかを示します。

例 18-1 WebDialer のコール数 1 秒あたりの計算

会社 XYZ は、WebDialer サービスを使用してクリックツーコール アプリケーションを稼働させることを考えています。その事前のトラフィック分析結果は次の資料の通りです。

10,000 人をクリックツーコール機能で有効にする。

各ユーザの平均 6 BHCA

すべてのコールの 50% が発信で、50% が着信

計画では、すべての発信のうち、WebDialer サーバを使用して開始する発信を 30% と見積もる。


) これらの値は、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 のキャパシティ プランニング」を参照してください)。

WebDialer の設計上の考慮事項

次のガイドラインと制限は、Unified CM 環境内の WebDialer の配置と動作に関連して適用されます。

管理者は、すべての WebDialer ユーザが Unified CM エンド ユーザ ディレクトリの電話機またはデバイス プロファイルに関連付けられることを確認します。

電話機が関連付けられていない状態でユーザが [Cisco WebDialer Preferences] 画面の [Use permanent device] を選択すると、Dial ボタンを押したときに次のメッセージが表示されます。

「No supported device configured for user」

デバイス プロファイルが関連付けられていない状態で(またはプロファイルを使用してログインしないで)ユーザが [Cisco WebDialer Preferences] 画面の [Use Extension Mobility] を選択すると、Dial ボタンを押したときに次のメッセージが表示されます。

「Call to <dialed_ number> failed: User not logged in on any device」

HTTPS 経由の WebDialer および Redirector サーブレットのアプリケーションとのインターフェイス。

クライアント識別コード(CMC)または強制承認コード(FAC)を使用している場合、WebDialer ユーザはトーンが聞こえたときに、電話機のキーパッドを使用して適切なコードを入力する必要があります。トーンが聞こえたときに適切なコードを入力しないと、コールの失敗を示すリオーダー トーンが聞こえます。

Cisco WebDialer は、Cisco Computer Telephony Integration(CTI)をサポートする、すべてのシスコのエンドポイントで使用可能です。

Cisco Computer Telephony Integration(CTI)をサポートするシスコのエンドポイントの一覧については、次の URL にある『 Cisco CTI Supported Device Matrix 』を参照してください。

http://developer.cisco.com/web/jtapi/wikidocs/-/wiki/Main/Cisco+CTI+Supported+Device+Matrix

Cisco Unified Attendant Consoles

アテンダント コンソールの統合によって、受付係は、組織内でその目的のために特別に設計されたデスクトップ アプリケーションからコールに応答したり、コールを転送または送信したりできます。アテンダント コンソールからは社内ディレクトリにアクセスでき、場合によっては、特定のユーザの回線状態をモニタできます。Cisco Unified Communications ポートフォリオには、次のタイプの Cisco Unified Attendant Console が用意されています。

Cisco Unified Attendant Console Department Edition

Cisco Unified Attendant Console Business Edition

Cisco Unified Attendant Console Enterprise Edition

Cisco Unified Attendant Console Premium Edition

Cisco Unified Attendant Console には、アテンダントの Windows PC にインストールするクライアント アテンダント コンソール アプリケーションがあります。また、Unified CM とは別の物理サーバにインストールされたアテンダント コンソール サーバ アプリケーションも必要です。アテンダント コンソール アプリケーションはアテンダント コンソール サーバ アプリケーションと通信し、アテンダント コンソール サーバ アプリケーションは Secure Socket Layer(SSL)接続で CTI および AVVID XML Layer(AXL)を介して安全に Unified CM と通信します。複数のアテンダント コンソールを 1 つのアテンダント コンソール サーバに接続できます。Department、Business、Enterprise および Premium エディションは、サポートされるオペレータ クライアントの数やサポートされるディレクトリ エントリの数など、各種の機能の制限がそれぞれ異なります。

ここでは、アテンダント コンソールの設計について次の項目を説明します。

「アテンダント コンソールのアーキテクチャ」

「アテンダント コンソールのハイ アベイラビリティ」

「アテンダント コンソールのキャパシティ プランニング」

「アテンダント コンソールの設計上の考慮事項」

アテンダント コンソールのアーキテクチャ

図 18-18 に、Cisco Unified Attendant Console 統合の上位レベル アーキテクチャの概要を示します。ソリューションの機能と動作を理解することにより、アーキテクチャ自体の理解も深まります。次の一連の手順(図 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 Department、Business、および Enterprise Attendant Console のアーキテクチャ

 

アテンダント コンソール サーバ アプリケーションのコール パーク機能では、Unified CM の固有のコール パーク機能は使用されません。代わりに、コール パーク デバイスを使用する独自のコール パーク機能が使用されます。コール パーク デバイスは、図 18-18 のステップ 7 ~ 9 にあるように、サービス キューとほとんど同様に機能します。転送と同様に、コール パーク デバイスを利用することで、コールのパーク中にアテンダント コンソール サーバ アプリケーションがコールを制御できるようになります。

アテンダント コンソールのハイ アベイラビリティ

Cisco Unified Attendant Console Premium Edition は、2 台の Cisco Unified Attendant Console サーバを持つ復元性の高い構成にインストールできます。

パブリッシャ:クライアントによって使用されるプライマリ サーバ。このサーバに失敗した場合、すべてのアテンダントのオペレータはサブスクライバ サーバに切り替えられます。パブリッシャが再び実行されると、オペレータにパブリッシャに再接続するよう促すプロンプトが表示されます。

サブスクライバ:パブリッシャが何らかの理由で停止した場合に使用されます。

The Cisco Unified Attendant Console の Department、Business、Enterprise の各エディションは、単一の 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 failure の宛先を設定します。アテンダント コンソール サーバ アプリケーションがオフラインになると、コールは自動的に Call Forward の設定に従います。たとえば、Cisco Unified Attendant Console Premium Edition では、コールを Cisco Unified Attendant Console サブスクライバ サーバに転送できます。Cisco Unified Attendant Console のその他のエディションでは、宛先として 1 台の IP フォンに関連付けられたハント パイロット番号またはディレクトリ番号(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 Console Premium Edition には AXL 復元性があります。

Unified CM には、Cisco Unified Attendant Console との統合用に一連の CTI ルート ポイントおよび CTI ポートも準備されています。これらのデバイスにはデバイス プールがあり、そのため Unified CM グループに割り当てられて、登録を維持する役割を果たす Unified CM 呼処理ノードの優先順位別リストが示されます。Unified CM グループ内のプライマリの Unified CM がオフラインである場合、CTI ルート ポイントと CTI ポートはセカンダリの Unified CM ノードを登録できるので、CTI ルート ポイントおよびポート自体のハイ アベイラビリティが実現します。

アテンダント コンソールのキャパシティ プランニング

Cisco Unified Attendant Console の Department、Business、Enterprise、Premium エディションの比較とそれぞれの機能については、『 Cisco Unified Attendant Consoles Business/Department/Enterprise/Premium Edition Design Guide 』を参照してください。次の Web サイトで入手できます。

http://www.cisco.com/en/US/products/ps7282/products_implementation_design_guides_list.html

Unified CM クラスタを正しくサイジングするには、Unified CM クラスタのスケーラビリティに影響する可能性がある相互依存変数が多数存在するため、シスコ代理店またはシスコのシステム エンジニアが Cisco Unified Communications Sizing Tool( http://tools.cisco.com/cucst )を使用して、多数の CTI リソースと大量のコールを包含するすべての設計を検証する必要があります。サイジング ツールを使用すると、Attendant Console 設計基準を満たすために必要なサーバまたはクラスタの正確な台数を決定できます。

Cisco Unified Attendant Console の各エディションのパフォーマンスと機能については、Web サイトで入手可能な製品マニュアルを参照してください。

http://www.cisco.com/en/US/products/ps7282/tsd_products_support_series_home.html

アテンダント コンソールの設計上の考慮事項

次の設計上のガイドラインと制限が、Unified CM テレフォニー環境内の Cisco Unified Attendant Console の配置および動作に関して適用されます。

次の一般的な設計指針は、アテンダント コンソール サーバ アプリケーション コンポーネントに適用します。

キュー DDI

1 つの一意なキュー DDI が、特にアテンダント コンソールにルーティングされる、システム内の一意の着信ディレクトリ番号ごとに必要です。

CT ゲートウェイ デバイス

キュー DDI に入るすべての着信コールは、直接 CT ゲートウェイ デバイスにリダイレクトされます。CT ゲートウェイ デバイスが所定の時間に予想される最大着信コール数を処理するのに十分な台数になるよう、システムを設計してください。

サービス キュー(Service Queue)

コンソール担当者がコールを転送するか、コールを保留にするたびに、サービス キューが必要になります。システム内のすべてのコンソール担当者が所定の時間に転送する、または保留にするコールの最大数を維持できるだけの十分なサービス キューが用意されるように、システムを設計する必要があります。コンソール担当者ごとに 3 つか 4 つのサービス キューを用意することが一般的なガイドラインですが、シナリオによってはさらに多くのキューが必要になる場合もあります。

コール パーク デバイス

コンソール担当者がアテンダント コンソール クライアント アプリケーションを介してコール パーク機能を起動するたびに、コール パーク デバイスが必要になります。この機能では、Unified CM の固有のコール パーク機能は使用されません。所定の時間にシステム内のすべてのコンソール担当者がパークするコールの最大数を処理できるだけの十分なコール パーク デバイスが用意されるように、システムを設計してください。

アテンダント コンソール サーバ アプリケーションに設定されたすべてのキュー DDI、CT ゲートウェイ デバイス、サービス キュー、およびコール パーク デバイスによって、Unified CM 内の CTI ルート ポイントまたは CTI ポートが作成されます。また、Unified Department、Business、または Enterprise Attendant Console の統合を処理するために必要な CTI 接続の数も、クラスタごとの CTI 接続制限までカウントされます (クラスタごとの CTI 接続制限の詳細については、「CTI のキャパシティ プランニング」を参照してください)。

アテンダント コンソール サーバ アプリケーションは、エンド ユーザ デバイスのビジー ランプ フィールド(BLF)モニタリングを可能にしますが、このアプリケーションでは、BLF スピード ダイヤル機能を実現する Unified CM 内の同一機能は使用されないことに注意してください。代わりに、アテンダント コンソール サーバ アプリケーションは、CTI を介して Unified CM と通信することで、モニタ対象デバイスの回線状態情報を取得します。アテンダント コンソール サーバ アプリケーションがエンド ユーザ デバイスをモニタする場合は、BLF のモニタ対象デバイスの台数が特定のレベル(2,000)に到達するまで、CTI 経由でモニタが継続されます。この上限に到達すると、BLF プラグインが、新しく要求されたデバイスをモニタ対象デバイスのリストに追加するために、そのリストからデバイスを削除し始めるため、アテンダント コンソール サーバから CTI 経由で開始されるデバイスの台数が上限(2,000)を超えることはありません。CTI 経由でモニタされるこれらのデバイスは、Unified CM 上の CTI 上限も考慮されます。

アテンダント コンソール サーバ アプリケーションは、エンド ユーザ デバイスのビジー ランプ フィールド(BLF)モニタリングを可能にしますが、このアプリケーションでは、BLF スピード ダイヤル機能を実現する Unified CM 内の同一機能は使用されないことに注意してください。代わりに、アテンダント コンソール サーバ アプリケーションは、CTI を介して Unified CM と通信することで、モニタ対象デバイスの回線状態情報を取得します。

Quality of Service(QoS)に関しては、アテンダント コンソール サーバ アプリケーション、アテンダント コンソール クライアント アプリケーション、および Cisco TSP はすべて Best Effort としてマークされたトラフィック(DSCP=0)を送信します。このトラフィックが WAN または通常輻輳するリンクを経由する場合は、ネットワークを介して優先的に処理されるようにパケットにマーキングする必要があります。これらのアプリケーションに関連付けられた TCP ポート番号の完全なリストについては、次の Web サイトで適切なログイン認証によって入手可能な Unified Department、Business、または Enterprise Attendant Console の設計ガイドを参照してください。

http://www.cisco.com/go/ac

Cisco TSP は、パーティションを認識しません。したがって、複数のパーティションに同じディレクトリ番号(DN)が存在する場合、モニタ対象のデバイスの DN に誤りが生じる可能性があります。

Cisco Unified Attendant Console は、SIP SIMPLE プロトコルによって Cisco IM およびプレゼンス サービスと統合できます。このタイプの統合の詳細については、次の Web サイトで入手できる Cisco Unified Attendant Console の適切なアドミニストレーション ガイドを参照してください。

http://www.cisco.com/en/US/products/ps7282/prod_maintenance_guides_list.html

Cisco Unified Attendant Console の設計ガイドラインについては、次の Web サイトで入手可能なマニュアルを参照してください。

http://www.cisco.com/en/US/products/ps7282/products_implementation_design_guides_list.html