- このマニュアルについて
- 概要
- IP テレフォニー配置モデル
- ネットワーク インフラストラクチャ
- ゲートウェイ
- Cisco Unified CallManager トランク
- メディア リソース
- Music on Hold
- コール処理
- コール アドミッション制御
- ダイヤル プラン
- 緊急サービス
- サードパーティ製のボイスメール設計
- Cisco Unity
- Cisco Unified MeetingPlace の統合
- IP ビデオ テレフォニー
- LDAP ディレクトリ統合
- IPテレフォニー移行オプション
- 音声セキュリティ
- IP テレフォニー エンドポイント
- Cisco Unified CallManager アプリケーション
- 推奨されるハードウェアと ソフトウェアの組み合せ
- 用語集
- 索引
Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) Cisco Unified CallManager Release 5.0
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月5日
章のタイトル： Cisco Unified CallManager アプリケーション
- IP Phone Service
- エクステンション モビリティ（EM）
- Cisco Unified CallManager Assistant（Unified CM Assistant）
- Unified CM Assistant Phone のサポート
- Cisco Unified CallManager および Unified CM Assistant のサービス パラメータ
- Unified CM Assistant の機能とアーキテクチャ
- Unified CM Assistant のダイヤル プランの考慮事項
- Unified CM Assistant Console
- Unified CM Assistant の冗長性
- Unified CM Assistant のガイドラインと制限
- Unified CM Assistant のパフォーマンスとキャパシティ
- Unified CM Assistant と EM の相互作用
- Attendant Console
- WebDialer
Cisco Unified CallManager アプリケーション
Cisco Unified CallManager アプリケーションは、基本となる IP テレフォニーに多数の動作および機能の拡張を提供します。External eXtensible Markup Language（XML）生産性向上アプリケーションまたは IP Phone Service は、Web サーバまたはほとんどの Cisco Unified IP Phone 上のクライアント（あるいはその両方）で実行できます。たとえば、ユーザのデスク上の IP Phone を使用して、株式相場、天気情報、フライト情報など各種の Web ベースの情報を取得できます。また、カスタム IP Phone サービス アプリケーションを作成すると、ユーザが在庫を追跡したり、時間単位で顧客に課金したり、会議室の環境（照明、ビデオ画面、室温など）を制御できます。Cisco Unified CallManager には、次のような追加機能を提供する統合アプリケーションも多数あります。
Cisco Unified CallManager のエクステンション モビリティ機能では、モバイル ユーザがその電話機にログインすることで、一時的に Cisco Unified IP Phone を独自に設定することが可能です。
•
Cisco Unified CallManager Assistant（Unified CM Assistant）
Unified CM Assistant とは、アシスタントが 1 人以上のマネージャの着信電話コールを処理できるようにする Cisco Unified CallManager に統合されたアプリケーションです。
Attendant Console を使用すると、1 人以上の受け付け係が組織内でコールに応答および転送（または送信）できます。
WebDialer は Cisco Unified CallManager のクリックダイヤル アプリケーションで、ユーザはサポートされる任意の電話デバイスを使用して自分の PC から簡単にコールを発信できるようになります。
場合によっては、これらの統合アプリケーションが追加機能を提供するために、IP Phone Service を呼び出すこともあります。
この章では、次の Cisco Unified CallManager アプリケーションについて説明します。
• 「Cisco Unified CallManager Assistant（Unified CM Assistant）」
IP Phone Service
Cisco Unified IP Phone サービス は、Web クライアントやサーバ、および Cisco Unified IP Phone の XML 機能を利用するアプリケーションです。Cisco Unified IP Phone のファームウェアには、限定的な Web ブラウジング機能を可能にするマイクロブラウザが含まれています。これらの電話サービス アプリケーションは、ユーザのデスクトップ電話機上で直接実行することで、付加価値サービスと生産性向上の可能性を提供します。この章で「電話サービス」という用語は、Cisco Unified IP Phone を宛先および発信元としてコンテンツを送受信するアプリケーションを指します。
IP Phone Service をサポートする電話機
次の電話機は IP Phone Service をサポートしています。
• Cisco Unified IP Phone 7940G、7941G、および 7941G-GE
• Cisco Unified IP Phone 7960G、7961G、および 7961G-GE
• Cisco Unified IP Phone 7970G および 7971G-GE
IP Phone Service は次の IP Phone でも実行できます。ただし、これらの電話機モデルは、テキストベースの XML アプリケーションだけをサポートします。
• Cisco Unified IP Phone 7905G
• Cisco Unified IP Phone 7911G
• Cisco Unified IP Phone 7912G および 7912G-A
上記のすべての IP Phone は、電話機と実行中の電話サービスを含む Web サーバの間でユーザ インターフェイス（UI）を有効にするために、Cisco が定義する XML オブジェクトの限定されたセットを処理できます。
上記の電話機は、Skinny Client Control Protocol（SCCP）と Session Initiation Protocol（SIP）の両方で電話サービスをサポートすることに注意してください。
Cisco Unified CallManager サービスと IP Phone Service のエンタープライズ サービス パラメータ
IP Phone Service を有効にするには、システム管理者は Cisco Unified CallManager Serviceability インターフェイスから Cisco Unified CallManager 機能サービスをアクティブにし、起動する必要があります。また、管理者は Cisco Unified CallManager のサービス パラメータを使用すると、Cisco Unified CallManager の特定の部分とアプリケーションの動作をカスタマイズし、設定することができます。次の項で説明するように、IP Phone Service に対して設定およびカスタマイズのためのオプションを提供するエンタープライズ サービス パラメータがいくつかあります。
IP Phone Service の Cisco Unified CallManager サービス
IP Phone Service はその機能を、Cisco Unified CallManager 上の Cisco Unified CallManager Cisco Unified IP Phone Service の機能サービスに依存しています。この機能は、Cisco Unified CallManager がサーバにインストールされたときにデフォルトでインストールされますが、システム管理者はこの機能を手動でアクティブにする必要があります。
IP Phone Service の エンタープライズ サービス パラメータ
IP Phone Service には、関連するいくつかのエンタープライズ サービス パラメータがあります。次の項目は、IP Phone Service および IP Phone の XML 処理に関連する、Cisco Unified CallManager Enterprise Service Parameters 設定ページの Phone URL Parameters セクションにある設定パラメータの一部です。
• URL Authentication（デフォルト値 = http:// <CM_IP_address> :8080/ccmcip/authenticate.jsp）
この URL は、Cisco Unified CallManager の authenticate.jsp サービスを指します。このサービスは、Cisco Unified IP Phones と Cisco Unified CallManager の間で認証プロキシ サービスを提供します。この URL は、電話サービスによって電話機に直接行われた「プッシュ」要求を検証するために使用されます。これは、インストール時に自動的に設定されます。このパラメータに値を指定しない場合、電話サービスは電話機にコンテンツをプッシュできません。
• URL Directories（デフォルト値 = http:// <CM_IP_address> :8080/ccmcip/xmldirectory.jsp）
この URL は、Cisco Unified CallManager の xmldirectory.jsp サービスを指します。このサービスは、ユーザが電話機の Directories（またはブック アイコン）ボタンを押したときに表示されるディレクトリ メニューを生成して返します。この URL は、インストール時に自動的に設定されます。このパラメータに値を指定しないと、ユーザが Directories ボタンを押したときに、ディレクトリ メニューを利用できません。
指定された場合、この URL は、電話機がアイドル状態のときに電話機の画面に表示されるテキストまたはイメージを提供するサービスを指します。このパラメータは、サービスを開始するまでの電話機のアイドル時間を示す URL Idle Time パラメータと密接に関連しています。デフォルトで、このパラメータはインストール時にブランクのままになります（設定されません）。
このパラメータは、電話機が URL Idle サービスを開始するまでに待機する時間を秒単位で示します。デフォルトで、このパラメータはインストール時に 0（ゼロ）に設定され、電話機がアイドル状態にならないことを示します。
• URL Information（デフォルト値 = http:// <CM_IP_address> :8080/ccmcip/GetTelecasterHelpText.jsp）
この URL は、Cisco Unified CallManager の GetTelecasterHelpText.jsp サービスを指します。このサービスは、ユーザが（キーボードの右側にある）Help（「i」または「?」）ボタンを押したときに電話機のキーおよびコール統計に関する画面上の電話機ヘルプを生成して返します。この URL は、インストール時に自動的に設定されます。このパラメータに値を指定しないと、Help ボタンを押したときにヘルプ情報が表示されません。
• URL Services（デフォルト値 = http:// <CM_IP_address> :8080/ccmcip/getservicesmenu.jsp）
この URL は、Cisco Unified CallManager の getservicesmenu.jsp サービスを指します。このサービスは、Services（または地球のアイコン）ボタンを押したときに電話機のユーザ加入電話サービスのリストを表示します。これは、インストール時に自動的に設定されます。このパラメータに値を指定しないと、Services ボタンを押したときに加入サービスのリストが表示されません。
IP Phone Service のアーキテクチャ
IP Phone サービスは、次のような複数の方法で開始できます。
IP Phone ユーザが Services ボタンを押すと、ユーザ加入電話サービスのリストを表示するために、HTTP GET メッセージが Cisco Unified CallManager に送信されます。図20-1 は、この機能を示しています。
IP Phone ファームウェア内で、アイドル時間の値は URL Idle Time パラメータによって設定できます。このタイムアウト値を超えた場合、IP Phone のファームウェア自体が URL Idle パラメータで指定されるアイドル状態の URL の場所に対して、HTTP GET を開始します。
電話サービス アプリケーションは、電話機に HTTP POST メッセージを送信することによって、IP Phone にコンテンツをプッシュできます。
（注） 電話サービスを呼び出すために電話機の Web クライアントが使用されるユーザ起動および電話機起動のプル機能とは異なり、電話サービス起動のプッシュ機能は、電話機の（クライアントではなく）Web サーバに（HTTP POST を通じて）コンテンツをポストすることによって、電話機上の処理を呼び出します。
図20-1 は、ユーザが開始する IP Phone サービス処理の詳細を示しています。ユーザが Services ボタンを押したときに、デフォルトでは、HTTP GET メッセージが IP Phone から Cisco Unified CallManager の getservicesmenu.jsp スクリプトに送信されます（ステップ 1）。URL Services パラメータを変更すると、異なるスクリプトを指定できます（「IP Phone Service の エンタープライズ サービス パラメータ」を参照してください）。getservicesmenu.jsp スクリプトは、個々のユーザが加入している電話サービス URL ロケーションのリストを返します（ステップ 2）。HTTP 応答は、IP Phone にこのリストを返します（ステップ 3）。ユーザによって選択される追加の電話サービス メニュー オプションは、ユーザと選択された電話サービス アプリケーションを含む Web サービス間で HTTP メッセージングを継続します（ステップ 4）。
図20-1 ユーザ起動の IP Phone Service のアーキテクチャ
図20-2 は、電話機起動と電話サービス起動の両方のプッシュ機能の例を示しています。電話機起動の機能の例で、電話機は、URL Idle Time に達したときに URL Idle パラメータで指定されるロケーションに HTTP GET を自動的に送信します（「IP Phone Service の エンタープライズ サービス パラメータ」を参照してください）。HTTP GET は、Cisco Unified CallManager を通じて外部 Web サーバに転送されます。この Web サーバは HTTP 応答を返し、この応答は Cisco Unified CallManager によって電話機にリレーされ、電話機は画面にテキストまたはイメージ（あるいはその両方）を表示します。
電話サービス起動のプッシュの例で、外部 Web サーバ上の電話サービスは電話機の Web サーバに対して、Common Gateway Interface（CGI）または Execute 呼び出しで HTTP POST を送信します。CGI または Execute 呼び出しを実行する前に、電話機は URL Authentication パラメータで指定されるプロキシ認証サービスを使用して要求を認証します（「IP Phone Service の エンタープライズ サービス パラメータ」を参照してください）。このプロキシ認証サービスは、電話機に対する直接の要求を検証するための、電話機と Cisco Unified CallManager ディレクトリ間のインターフェイスを提供します。要求が認証された場合、Cisco Unified CallManager は電話機に HTTP 応答を転送します。次に、電話機の Web サーバは要求された処理を実行し、電話機は外部 Web サーバに HTTP 応答を返します。認証に失敗した場合、Cisco Unified CallManager は、HTTP 否定応答を転送し、電話機は要求された CGI または Execute 処理を実行しないで、HTTP 否定応答を外部 Web サーバに転送します。
図20-2 電話機起動および電話サービス起動の IP Phone Service のアーキテクチャ
IP Phone Service の冗長性
電話機のユーザに対して信頼性の高いサービスを確保するには、システムの障害時に冗長システムにシームレスに移行することにより、高レベルのシステムの可用性を維持する必要があります。電話サービスのほとんどのバックエンド処理は Web サーバで発生しますが、電話機は電話サービスへの処理の転送を Cisco Unified CallManager に依存します。また、エクステンション モビリティおよび Cisco Unified CallManager Assistant 電話サービスの場合、実際にはサービスが Cisco Unified CallManager サーバで実行されます。
図20-1 および図20-2 に示す IP Phone サービス機能のアーキテクチャおよびメッセージ フローでは、次の 2 つの主な障害のシナリオを検討する必要があります。
障害シナリオ 1：Cisco Unified CallManager の Cisco Unified IP Phone Service サーバの障害
この場合の冗長性は、図20-3 に示すように、一種の Server Load Balancing（SLB; サーバ ロード バランシング）に依存します。この SLB では、1 つ以上の Cisco Unified CallManager サーバを指すために仮想 IP アドレスが使用されます。この仮想 IP アドレスは、URL Services パラメータの設定時に使用されます。このため、Cisco Unified CallManager サーバに障害が発生しても、電話機の Services ボタンが押されたときに、IP Phone Service 加入リストは電話機に正常に返されます。また、Cisco Unified CallManager サーバで実行されるエクステンション モビリティおよび Unified CM Assistant などの電話サービスも、この方法によって冗長性を持つ可能性があります。
障害シナリオ 2：特定の IP Phone Service をホストしている外部 Web サーバの障害
このシナリオでは、Cisco Unified CallManager サーバへの接続は保持されますが、ユーザ加入電話サービスをホストしている Web サーバへのリンクに障害が発生します。Services ボタンが押されたときに IP Phone は引き続き Cisco Unified CallManager サーバにアクセスできるため、これは冗長性を提供するための比較的容易なシナリオです。この場合、IP Phone は Web サーバにアクセスする他の IP Phone に似ています。このため、（図20-3 に示すような）一種の SLB 機能を再び使用して、電話機から、ユーザ加入電話サービスをホストしている 1 つ以上の冗長 Web サーバに HTTP 要求を転送できます。
IP Phone Service のスケーラビリティ
Cisco Unified IP Phone サービスの大部分は、HTTP クライアントとして機能します。ほとんどの場合、加入サービスのロケーションへの転送サーバとしてだけ Cisco Unified CallManager が使用されます。Cisco Unified CallManager は電話サービスへの転送サーバとして機能するため、ユーザが Services キーを押して電話サービス要求を起動したときに、Cisco Unified CallManager へのパフォーマンスの影響は最小限になります。
（注） エクステンション モビリティおよび Unified CM Assistant 電話サービスの場合、Cisco Unified CallManager は転送サーバ以上の役割を果たすので、パフォーマンスへの影響を検討する必要があります。これらのアプリケーションの特定のパフォーマンスおよびスケーラビリティの考慮事項については、「エクステンション モビリティ（EM）」および 「Cisco Unified CallManager Assistant（Unified CM Assistant）」の項を参照してください。
IP Phone はクライアントまたはサーバのいずれかであるため、IP Phone サービスで使用される必要帯域幅の推定は、Web 運用サーバにある HTTP コンテンツと同じテキストにアクセスする HTTP ブラウザの帯域幅の推定に似ています。
IP Phone Service のガイドラインと制限
統合エクステンション モビリティおよび Unified CM Assistant アプリケーションの電話サービスを除き、IP Phone サービスは独立した Web サーバに存在する必要があります。Cisco Unified CallManager サーバでエクステンション モビリティおよび IP Manager Application 以外の電話サービスを実行することはサポートされていません。
エクステンション モビリティ（EM）
Cisco Unified CallManager の Extension Mobility（EM; エクステンション モビリティ）機能では、ユーザがその電話機にログインすることで、一時的に Cisco Unified IP Phone を独自に設定することが可能です。ユーザがログインすると、IP Phone は、回線番号、短縮ダイヤル、サービス リンク、およびその他のユーザ固有の電話機のプロパティなど、ユーザの個別のデバイス プロファイル情報を受け入れます。たとえば、ユーザ X がデスクに向かって電話機にログインした場合は、そのユーザのディレクトリ番号、短縮ダイヤル、およびその他のプロパティがその電話機に表示されますが、ユーザ Y が別のときに同じデスクを使用した場合は、ユーザ Y の情報が表示されます。EM 機能では、認証されたユーザのデバイス プロファイルに従って電話機が動的に設定されます。このアプリケーションの利点は、電話機が EM をサポートしている限り、物理的な場所に関係なく、ユーザが Cisco Unified CallManager クラスタ内の任意の電話機で自分の内線番号に接続できることです。
EM Phone のサポート
次の Skinny Client Control Protocol（SCCP）電話機は EM をサポートしています。
• Cisco Unified IP Phone 7905G
• Cisco Unified IP Phone 7911G
• Cisco Unified IP Phone 7912G および 7912G-A
• Cisco Unified IP Phone 7940G、7941G、および 7941G-GE
• Cisco Unified IP Phone 7960G、7961G、および 7961G-GE
• Cisco Unified IP Phone 7970G および 7971G-GE
次の Session Initiation Protocol（SIP）Phone は、EM をサポートしています。
• Cisco Unified IP Phone 7911G
• Cisco Unified IP Phone 7941G および 7941G-GE
• Cisco Unified IP Phone 7961G および 7961G-GE
• Cisco Unified IP Phone 7970G および 7971G-GE
（注） EM は、SIP ロードを実行している Cisco Unified IP Phone 7905G、7912G、7940G、または 7960G ではサポートされません。
Cisco Unified CallManager および EM のサービス パラメータ
EM アプリケーションを有効にするには、システム管理者は Cisco Unified CallManager Serviceability インターフェイスからいくつかの Cisco Unified CallManager サービスをアクティブにし、起動する必要があります。また、EM サービス パラメータは、EM アプリケーションの動作を決定するための設定およびカスタマイズのオプションを提供します。
EM 用の Cisco Unified CallManager サービス
EM アプリケーションは次の機能サービスに依存します。これらのサービスは、Serviceability ページから手動でアクティブにする必要があります。
• Cisco Unified CallManager の Cisco Unified IP Phone Service
EM は、ネットワーク サービスの Cisco エクステンション モビリティ アプリケーションにも依存します。このサービスは、インストール時に Cisco Unified CallManager で自動的にアクティブになります。
Cisco エクステンション モビリティ アプリケーション サービスは、EM ユーザ電話機と Cisco エクステンション モビリティ サービスとの間のインターフェイスを提供します。また、Cisco エクステンション モビリティ アプリケーション サービスは、クラスタ内の変更通知インジケータにサブスクライブして、アクティブな Cisco エクステンション モビリティ サービスがあるクラスタ内のノードのリストを維持します。クラスタ内の変更通知にサブスクライブすることによって、EM サービス パラメータに変更を加えた後に、Cisco Tomcat ネットワーク サービスおよび Cisco エクステンション モビリティ機能サービスを再起動する必要がなくなります。
Cisco Unified CallManager の Cisco Unified IP Phone Service サービスは、EM 電話サービスへのアクセスを提供するために必要です。EM 電話サービスの定義に使用される URL は、次のとおりです。
http:// <Publisher_IP-Address> :8080/emapp/EMAppServlet?device=#DEVICENAME#
EM のサービス パラメータ
次の項目は、エクステンション モビリティ機能に関連する Cisco EM サービス パラメータの一部のリストです。
• Enforce Maximum Login Time（デフォルト値 = False）
このパラメータは、Maximum Login Time に達したときに、EM ユーザを自動的にログアウトするかどうかを示します。デフォルトでは、この値は False に設定され、EM ユーザを自動的にログアウトしません。
• Maximum Login Time（デフォルト値 = 8:00）
このパラメータは、EM ユーザが自動的にログアウトするまでにログイン状態を維持できる時間と分（ hh : mm ）を示します。Enforce Maximum Login Time パラメータを True に設定した場合にだけ、指定した時刻に自動ログアウトが行われます。
• Multiple Login Behavior（デフォルト値 = Multiple Logins Not Allowed）
このパラメータは、同時に複数のデバイスにログインすることを EM ユーザに許可するかどうかを示します。デフォルトでは、1 人のユーザの複数のログインは許可されず、1 台のデバイスにログオンしているときに別のデバイスにログインしようとすると、次のメッセージが表示されます。
Login Unsuccessful
[25]User logged in elsewhere.
• Remember the Last User Logged In（デフォルト値 = False）
このパラメータは、デバイスへのログインに前回使用されたユーザ ID を、次回同じデバイスにログインしようとするときまで記録するかどうかを示します。この値を True に設定すると、前回のログインに使用されたユーザ ID 情報は Cisco Unified CallManager データベースのテーブルに保存され、効率的に取得されます。次回のログイン試行時に、電話機のログイン画面の UserID フィールドには、保存されたユーザ ID の値があらかじめ表示されます。
• Clear the call log（デフォルト値 = False）
このパラメータは、EM ログインおよびログアウト時に、Directories ボタン メニューに指定されたコール ログをクリアするかどうかを指定します。このパラメータは、Missed Calls、Received Calls、および Placed Calls のログに影響を与えます。この値を True に設定した場合、これらのログはログインおよび手動ログアウト時にクリアされます。
例外として、ユーザを自動的にログアウトする場合、これらのログはクリアされません。したがって、Maximum Login Time に達してユーザを電話機から自動的にログアウトするときに、ログはクリアされません（Enforce Maximum Login Time が True に設定されている場合）。同様に、Cisco Unified CallManager 管理者が、電話機またはデバイスの設定画面の Extension セクションで Log Out ボタンをクリックした場合も、ログはクリアされません。
EM のアーキテクチャ
図20-4 は、EM アプリケーションのメッセージ フローとアーキテクチャを示しています。電話機のユーザが EM アプリケーションにアクセスする場合、次の一連のイベントが発生します。
1. ユーザが電話機の Services ボタンを押すと、Enterprise Parameter 設定ページの URL Services パラメータで指定した URL へのコールが生成されます（「IP Phone Service の エンタープライズ サービス パラメータ」を参照）（図20-4 のステップ 1 も参照）。
2. HTTP/XML コールが IP Phone Service に対して生成され、このコールはユーザの電話機が加入しているすべてのサービスのリストを返します（図20-4 のステップ 2 を参照）。
（注） ユーザの電話機の EM に対して Service URL ボタンを設定すると、ユーザが回線ボタンまたは短縮ダイヤル ボタンを押して、エクステンション モビリティ アプリケーション サービスへの直接コールを生成できます。この場合、電話機と IP Phone Service（ステップ 1 および 2）の対話はバイパスされます。
3. 次に、ユーザはエクステンション モビリティ電話サービスのリストを選択します。この選択によって、電話機と Cisco エクステンション モビリティ サービス間のインターフェイスの役割を果たす エクステンション モビリティ アプリケーション サービスに対して HTTP コールが生成されます（図20-4 のステップ 3 を参照）。
4. 次に、エクステンション モビリティ アプリケーション サービスは、ユーザ ログイン クレデンシャル（ユーザ ID および PIN）を要求している電話機に XML 応答を返すか、またはユーザがすでにログインしている場合は、ユーザに電話機からログオフするかどうかを尋ねる応答を返します（図20-4 のステップ 4 を参照）。
5. ユーザがログインしようとしている場合、そのユーザは電話機のキーパッドを使用して有効なユーザ ID および PIN を入力する必要があります。ユーザが Submit ソフトキーを押した後に、入力したユーザ ID および PIN を含む応答が、エクステンション モビリティ アプリケーション サービスに返されます（図20-4 のステップ 5 を参照してください）。
6. 次に、エクステンション モビリティ アプリケーションは、このログイン情報を エクステンション モビリティ サービスに転送します。このサービスは、Cisco Unified CallManager データベースと対話して、ユーザのクレデンシャルを検証します（図20-4 のステップ 6 を参照）。
7. ユーザのクレデンシャルの検証に成功したときに、エクステンション モビリティ サービスも Cisco Unified CallManager データベースと対話して、適切なユーザ デバイス プロファイルを読み取って選択し、デバイスのプロファイルに基づいて電話機の設定に必要な変更を書き込みます（図20-4 のステップ 7 を参照）。
8. これらの変更が加えられると、エクステンション モビリティ サービスは、エクステンション モビリティ アプリケーション サービスに成功応答を返します（図20-4 のステップ 8 を参照）。
9. 次にエクステンション モビリティ アプリケーション サービスは電話機にリセット メッセージを送信し、電話機はリセットされ、新しい電話設定を受け入れます（図20-4 のステップ 9 を参照）。
図20-4 EM アプリケーションのアーキテクチャとメッセージ フロー
EM の冗長性
図20-4 に示す EM アーキテクチャに従って、Cisco Unified CallManager データベースの読み取りおよび書き込みが要求されます。現在の Cisco Unified CallManager クラスタ アーキテクチャに基づいて、パブリッシャ サーバは Cisco Unified CallManager データベースに書き込むことができる唯一のノードです。したがって、EM 機能はパブリッシャ サーバに依存します。パブリッシャを使用できない場合、EM のログインとログアウトは行えません。パブリッシャの冗長性メカニズムは存在しないため、パブリッシャは EM 動作における単一の障害点になります。このため、EM に必要な 3 つのサービス（IP Phone Service、エクステンション モビリティ、および エクステンション モビリティ アプリケーション サービス）をすべてパブリッシャで実行することをお勧めします。パブリッシャを使用できない場合、クラスタ内の他のノードでこれらのサービスを実行しても、機能が提供されないため意味がありません。
（注） エクステンション モビリティ アプリケーション サービスは、クラスタ内のすべてのノードで常にアクティブになり、実行されます。ただし、EM 電話サービスを設定する場合は、常にパブリッシャ ノードを指すように Service URL を設定してください。
前述したように、エクステンション モビリティ アプリケーション サービスはクラスタの変更通知にサブスクライブするので、エクステンション モビリティ サービスがアクティブになっているクラスタ内のすべてのノードのリストを維持します。したがって、エクステンション モビリティ サービスはクラスタ内の複数のサーバで実行でき、エクステンション モビリティ アプリケーション サービスはエクステンション モビリティ サービスを実行している他のノードに対して自動フェールオーバーを提供できます。ただし、この自動フェールオーバーは、エクステンション モビリティ サービスだけを対象としています。これは、パブリッシャでエクステンション モビリティ サービスに障害が発生しても、その他すべてのサービス、Cisco Unified CallManager データベース、およびノード自体が動作している非常にまれな状況を除き、実際のエクステンション モビリティ機能に対してフェールオーバーを提供しません。一般に、障害シナリオは 1 つのサービスだけではなく、ノード全体、ノード アップリンク スイッチ、またはスイッチ ポートが関係します。したがって、EM 冗長性に関して、パブリッシャ以外のノードで必要なエクステンション モビリティ サービスまたは IP Phone Service を実行する必要はありません。ただし、管理者は、クラスタ内の追加のノードでエクステンション モビリティ サービスを実行することにより、前述のまれな障害シナリオに対して、このサービスの冗長性を提供できます。図20-3 に示すように、SLB および仮想 IP アドレスと実際の IP アドレス間のマッピングを通じて、IP Phone Service およびエクステンション モビリティ アプリケーション サービスに対して追加の冗長性を提供することもできます。ただし、この方法では、パブリッシャでこれらのサービスすべてに障害が発生しても、パブリッシャおよび Cisco Unified CallManager データベースが動作し続け、EM ログイン要求およびログアウト要求を処理しているまれな状況だけに冗長性を提供します。
EM のガイドラインと制限
次のガイドラインと制限は、Cisco Unified CallManager テレフォニー環境内の EM の配置と動作に関連して適用されます。
• EM は、単一の Cisco Unified CallManager クラスタ内だけでサポートされます。
現在、クラスタ間で EM はサポートされていません。ある Cisco Unified CallManager クラスタの EM ユーザは、2 番目のクラスタでそのユーザに対して別個のデバイス プロファイルおよびユーザ ID が作成されない限り、2 番目のクラスタで電話機にログオンすることはできません。
• EM ユーザは、Automated Alternate Routing（AAR）または Voice over PSTN（VoPSTN）、あるいはその両方の配置モデルが使用されている場合、クラスタ内のロケーションまたはサイト間で移動することはできません。
EM 機能は、コール ルーティングを IP ネットワークの使用に依存します。E.164 公衆網番号は静的で、公衆網はホーム サイトからの EM ユーザのディレクトリ番号（DN）の移動を考慮に入れられないため、公衆網を通じたコール ルーティングにはより多くの問題が伴います。AAR は、VoPSTN 配置モデルと同様に、コール ルーティングを公衆網に依存します。いずれの場合も、ロケーションおよびサイト間の EM ユーザの移動は、ユーザの移動するすべてのサイトが同じ AAR グループに属する場合にだけサポートされます。詳細については、「エクステンション モビリティ」を参照してください。
• EM 機能は、Cisco Unified CallManager パブリッシャ サーバに完全に依存しています。
Cisco Unified CallManager パブリッシャがダウンしている場合、EM ユーザは電話機にログオンしたり、電話機からログオフしたりすることができません。
EM のパフォーマンスとキャパシティ
Cisco EM アプリケーションは、ログインおよびログアウト機能をパブリッシャ サーバに依存します。EM は、次のパブリッシャ キャパシティをサポートしています。
• Cisco MCS-7845 サーバは、1 分あたり 50 回の順次ログインまたはログアウト（あるいはその両方）をサポートできます。
• Cisco MCS-7835 サーバは、1 分あたり 30 回の順次ログインまたはログアウト（あるいはその両方）をサポートできます。
EM のキャパシティの詳細については、次の Web サイトにある Cisco Unified CallManager のデータ シート、マニュアル、およびリリース ノートを参照してください。
EM 相互作用：Unified CM Assistant、AC、および WebDialer
Unified CM Assistant Manager ユーザと Attendant Console ユーザの両方が、それぞれの電話機へのログインに EM を使用できます。このような他のアプリケーションでの EM の使用に関する詳細とガイドラインについては、「Unified CM Assistant と EM の相互作用」および 「AC と EM の相互作用」を参照してください。
WebDialer ユーザも、EM を使用してそれぞれの電話機にログオンできます。詳細については、「WebDialer と EM の相互作用」を参照してください。
Cisco Unified CallManager Assistant（Unified CM Assistant）
Cisco Unified CallManager Assistant は、Cisco Unified CallManager に統合されたアプリケーションであり、1 人以上のマネージャに代わってアシスタントが着信コールを処理できるようにします。Unified CM Assistant Console デスクトップ アプリケーションを使用すると、アシスタントが手早くマネージャの状態を確認し、コールをどうするかを決定できます。アシスタントは、自分の電話機のソフトキーを使用したり、キーボード ショートカットまたはドロップダウン メニューで PC インターフェイスを使用したり、コールをマネージャのプロキシ回線にドラッグ アンド ドロップしたりすることで、コールを操作することができます。
Unified CM Assistant Phone のサポート
次の SCCP 電話機が Unified CM Assistant をサポートしています。
• Cisco Unified IP Phone 7940G、7941G、および 7941G-GE
• Cisco Unified IP Phone 7960G、7961G、および 7961G-GE
• Cisco Unified IP Phone 7970G および 7971G-GE
（注） Cisco Unified IP Phone Expansion Module 7914 は、Csco Unified IP Phone 7960G、7961G、7961G-GE、7970G、または 7971G-GE のすべての電話機でサポートされています。電話機あたり最大 2 つの Cisco 7914 Module がサポートされています。
Cisco Unified CallManager および Unified CM Assistant のサービス パラメータ
Unified CM Assistant アプリケーションを有効にするには、システム管理者は Cisco Unified CallManager Serviceability インターフェイスから複数の Cisco Unified CallManager 機能サービスをアクティブにし、起動する必要があります。また、Unified CM Assistant サービス パラメータは、Unified CM Assistant アプリケーションとサービスの動作を決定するための設定およびカスタマイズのオプションを提供します。
Unified CM Assistant 用の Cisco Unified CallManager サービス
Unified CM Assistant アプリケーションは次の機能サービスに依存します。これらのサービスは、Serviceability ページから手動でアクティブにする必要があります。
• Cisco Unified CallManager Assistant
• Cisco Unified CallManager の Cisco Unified IP Phone Service
Cisco CallManager IP Manager Assistant サービスは、Unified CM Assistant Console アプリケーションおよび Manager Configuration アプリケーション用のインターフェイスを提供し、Cisco CTIManager サービスおよび Cisco Unified CallManager データベースと対話します。Cisco CTIManager サービスは、電話とコールの制御のために Cisco CallManager Service および Cisco CallManager IP Manager Assistant サービスとインターフェイスし、対話します。
Cisco Unified IP Phone Service は、マネージャの電話機から Unified CM Assistant 電話サービスへのアクセスを提供するために必要です。Unified CM Assistant 電話サービスを定義するために使用される URL は、次のとおりです。
http:// <Server_IP-Address> :8080/ma/servlet/MAService?cmd=doPhoneService&Name=#DEVICENAME#
Unified CM Assistant のサービス パラメータ
次の項目は、Unified CM Assistant 機能に関連する Cisco CallManager IP Manager Assistant サービス パラメータの一部のリストです。
• CTIManager Connection Security Flag（デフォルト値 = False）
このパラメータは、Cisco CallManager IP Manager Assistant サービスと CTIManager との間でセキュアな Transport Layer Security（TLS; トランスポート レイヤ セキュリティ）接続を使用するかどうかを決定します。このパラメータを True に設定した場合、アプリケーション ユーザの Unified CM AssistantSecureSysUser のインスタンス ID に対して設定した Certificate Authority Proxy Function（CAPF）プロファイルを使用して、セキュアな接続が設定されます。このインスタンス ID は、サービス パラメータの CAPF Profile Instance ID for Secure Connection to CTIManager で指定する必要があります。
（注） アプリケーション ユーザの Unified CM AssistantSecureSysUser は、インストール時に自動的に作成されるシステム アカウントです。削除することはできません。
• CAPF Profile Instance ID for Secure Connection to CTIManager（デフォルト値 = <None>）
CAPF Profile Instance ID は、Unified CM AssistantSecureSysUser アプリケーション ユーザに対して、Unified CM Assistant サーバと CTIManager との間で確立される TLS 接続またはインスタンスを識別するために使用される、数値または文字（あるいはその両方）の一意のストリングです。CTI Manager Connection Security Flag パラメータを True に設定した場合、このパラメータに値を設定する必要があります
• CTIManager (Primary) IP Address（デフォルト値 = <ブランク>）
このパラメータは、Cisco Unified CM Assistant サーバがコールの処理に使用するプライマリ CTIManager の IP アドレスを指定します。プライマリ CTIManager は、各 Unified CM Assistant サーバで設定できます。
• CTIManager (Backup) IP Address（デフォルト値 = <ブランク>）
このパラメータは、プライマリ CTIManager がダウンしている場合に、この Cisco Unified CM Assistant サーバがコールの処理に使用するバックアップ CTIManager の IP アドレスを指定します。バックアップ CTIManager は、各 Unified CM Assistant サーバで設定できます。
• Cisco Unified CM Assistant Server (Primary) IP Address（デフォルト値 = <ブランク>）
このパラメータは、プライマリ Cisco Unified CM Assistant サーバの IP アドレスを指定します。これはクラスタ全体のパラメータで、プライマリとバックアップという 2 つの Unified CM Assistant サーバだけを設定できます。
• Cisco Unified CM Assistant Server (Backup) IP Address（デフォルト値 = <ブランク>）
このパラメータは、バックアップ Cisco Unified CM Assistant サーバの IP アドレスを指定します。バックアップ サーバは、プライマリ Unified CM Assistant サーバに障害が発生した場合に、Unified CM Assistant サービスを提供します。これはクラスタ全体のパラメータです。
• Cisco Unified CM Assistant Console Heartbeat Interval（デフォルト値 = 30）
このパラメータは、Unified CM Assistant サーバが、各 Unified CM Assistant Console デスクトップ アプリケーションにキープアライブ メッセージ（ハートビートとも呼ばれる）を送信する頻度を秒単位で指定します。Unified CM Assistant Console デスクトップ アプリケーションは、指定された時間が経過するまでにプライマリ サーバからキープアライブ メッセージを受信しないと、バックアップ Unified CM Assistant サーバへのフェールオーバーを開始します。
• Cisco Unified CM Assistant Console Request Timeout（デフォルト値 = 30）
このパラメータは、Unified CM Assistant Console デスクトップ アプリケーションが、アクティブまたはプライマリ Unified CM Assistant サーバからの応答の受信を待機する時間を秒単位で指定します。
• Cisco Unified CM Assistant RNA Forward Calls（デフォルト値 = False）
このパラメータを True に設定した場合、Cisco Unified CM Assistant RNA Timeout パラメータで指定される RNA 値が経過すると、アシスタントの電話機へのコールを、マネージャの次の応答可能なアシスタントに無応答時（RNA）転送することができます。このパラメータを False に設定した場合、コールは最初のアシスタントをいつまでも呼び続けるか、または、ボイスメール プロファイルが設定されているときはボイスメールにコールが転送されます。
• Cisco Unified CM Assistant RNA Timeout（デフォルト値 = 10）
このパラメータは、Cisco Unified CM Assistant サーバが、応答のないコールを次の応答可能なアシスタントに RNA 転送するまで待機する時間を秒単位で指定します。RNA 転送は、Cisco Unified CM Assistant RNA Forward Calls パラメータを True に設定した場合にだけ発生します。回線でボイスメール プロファイルが設定され、他のアシスタントを利用できない場合は、タイムアウトするとボイスメールにコールが転送されます。
Unified CM Assistant の機能とアーキテクチャ
Unified CM Assistant アプリケーションは、プロキシ回線モードとシェアドライン モードの 2 つのモードで動作できます。各モードの動作と機能は異なり、それぞれに長所と短所があります。どちらのモードも、1 つのクラスタ内で設定できます。ただし、同一のアシスタントでモードを混合させることはできません。1 人以上のマネージャにサポートを提供している 1 人のアシスタントは、シェアドライン モードまたはプロキシ回線モードのいずれかでこれらのマネージャをサポートできます。
Unified CM Assistant のプロキシ回線モード
図20-5 は、プロキシ回線モードでの 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）。
図20-5 Unified CM Assistant のプロキシ回線モード
（注） 図20-5 に示す CFNA による呼び出しメカニズムでは、Unified CM Assistant RP のディレクトリ番号設定ページの Forward No Answer Internal フィールドと Forward No Answer External フィールドの両方で、Unified CM Assistant RP ディレクトリ番号と同じ集約番号桁の設定が必要です。また、これらの各コール転送パラメータの Calling Search Space（CSS; コーリング サーチ スペース）フィールドは、Unified CM Assistant RP または Unified CM Assistant アプリケーションに障害が発生した場合に マネージャの電話機の DN に到達できるように、マネージャの電話機の DN が設定されたパーティションを含むコーリング サーチ スペースで設定する必要があります。
Unified CM Assistant のシェアドライン モード
図20-6 は、シェアドライン モードでの Unified CM Assistant の単純なコール フローを示しています。この例で、電話機 A は、アシスタントの電話機のシェアドラインであるディレクトリ番号（DN）60001 でマネージャの電話機をコールします（ステップ 1）。このコールは、アシスタントとマネージャの電話機の両方で着信音を鳴らします。ただし、マネージャが Do Not Disturb（DND）機能を呼び出した場合、着信音が鳴るのはアシスタントの電話機だけになります（ステップ 2）。
図20-6 Unified CM Assistant のシェアドライン モード
Unified CM Assistant のシェアドライン モードでは、マネージャの電話機へのコールを代行受信するために Unified CM Assistant RP は必要ありません。ただし、マネージャの電話機および Unified CM Assistant Console デスクトップ アプリケーションの Do Not Disturb（DND）機能は、Cisco Unified CallManager Assistant および Cisco CTIManager サービスに依存します。さらに、Unified CM Assistant シェアドライン モードでは、コール フィルタリング、コール代行受信、アシスタント選択、Assistant Watch などの機能は使用できません。
Unified CM Assistant のアーキテクチャ
Unified CM Assistant アプリケーションの機能と同様に、そのアーキテクチャについても理解することが重要です。図20-7 は、Unified CM Assistant のメッセージ フローとアーキテクチャを示しています。Unified CM Assistant のマネージャおよびアシスタント ユーザに対して Unified CM Assistant を設定すると、次の一連の対話とイベントが発生します。
1. マネージャとアシスタントの電話機は Cisco Unified CallManager サービスに登録され、コール フロー処理にキーパッドとソフトキーが使用されます（図20-7 のステップ 1 を参照してください）。
2. Unified CM Assistant Console デスクトップ アプリケーションと Manager Configuration Web ベース アプリケーションは、どちらも Unified CM Assistant サービスと通信およびインターフェイスします（図20-7 のステップ 2 を参照してください）。
3. 次に、Unified CM Assistant サービスは、回線監視情報および電話制御情報を交換するために、CTIManager サービスと対話します（図20-7 のステップ 3 を参照してください）。
4. CTIManager サービスは、Unified CM Assistant 電話制御情報を Cisco CallManager Service に渡し、さらに Unified CM Assistant RP を制御します（図20-7 のステップ 4 を参照してください）。
5. それと並行して、Unified CM Assistant サービスは、Cisco Unified CallManager データベースとの間で、Unified CM Assistant アプリケーション情報の読み取りと書き込みを行います（図20-7 のステップ 5 を参照してください）。
6. マネージャは、Services ボタンを押すことにより、Unified CM Assistant 電話サービスを呼び出して、その電話機が加入している（Unified CM Assistant 電話サービスを含む）すべてのサービスのリストを返す IP Phone Service サービスへのコールを生成できます（図20-7 のステップ 6 を参照してください）。
Unified CM Assistant 電話サービスは Unified CM Assistant サービスで制御され、電話機を使用してマネージャによって加えられた設定の変更は、Unified CM Assistant サービスを通じて処理および伝達されます。
（注） ユーザが回線ボタンまたは短縮ダイヤル ボタンを押して、Unified CM Assistant サービスへの直接コールを生成することで、IP Phone Service をバイパスできるように、マネージャの電話機で Service URL ボタンを Unified CM Assistant 電話サービス用に設定することもできます。
図20-7 Unified CM Assistant のアーキテクチャ
（注） 図20-7 は、すべて同じノードで実行されている IP Phone Service、Cisco Unified CallManager、CTIManager、および Unified CM Assistant サービスを示していますが、この設定は必須ではありません。これらのサービスではクラスタ内の複数のノードに分散できますが、説明を簡単にするためにここでは同じノードにあるものとしています。
Unified CM Assistant のダイヤル プランの考慮事項
ダイヤル プラン設定は、プロキシ回線モードで設定される Unified CM Assistant では非常に重要です。マネージャの DN に対するコールが Unified CM Assistant RP で代行受信され、アシスタントの電話機に転送されることを保証するには、Unified CM Assistant RP およびアシスタントの電話機上のマネージャのプロキシ回線を除いて、すべてのデバイスからマネージャの DN に到達できないように、コーリング サーチ スペースおよびパーティションを設定する必要があります。
図20-8 は、ダイヤル プラン コンポーネント内の各種デバイスのコーリング サーチ スペース、パーティション、および設定に対する最小要件を持つ、プロキシ回線モードの Unified CM Assistant ダイヤル プランの例を示しています。プロキシ回線モードでは 3 つのパーティションが必要です。図20-7 の例では、次のパーティションになります。
• すべての IPMA RP DN を含む IPMA パーティション
• すべてのアシスタントとその他のユーザの電話機 DN を含む IPMA_Everyone パーティション
• すべてのマネージャの電話機の DN を含む IPMA_Manager パーティション
また、2 つのコーリング サーチ スペースが必要です。図20-7 の例では、次のコーリング サーチ スペースになります。
• IPMA パーティションおよび IPMA_Everyone パーティションを含む IPMA_EVERYONE_CSS コーリング サーチ スペース
• IPMA_Manager パーティションおよび IPMA_Everyone パーティションを含む MANAGER_EVERYONE_CSS コーリング サーチ スペース
これは、この例でのダイヤル プランの範囲です。ただし、コール ルーティングが必要に応じて動作するように、適切なコーリング サーチ スペースでさまざまな電話機および IPMA RP DN または回線を適切に設定することも重要です。この場合、すべてのユーザの回線、アシスタントのプライマリ（またはパーソナル）回線、およびマネージャの電話回線は、これらの回線すべてが IPMA_Everyone パーティションおよび IPMA パーティションのすべての DN に到達できるように、IPMA_EVERYONE_CSS コーリング サーチ スペースで設定します。テレフォニー ネットワーク内のデバイスで設定されるインターコムなどの回線は、この同じコーリング サーチ スペースで設定します。すべてのマネージャのプロキシ回線およびすべての IPMA_RP 回線は、これらの回線すべてが IPMA_Manager パーティションのマネージャ DN および IPMA_Everyone パーティションに属するすべての DN に到達できるように、MANAGER_EVERYONE_CSS コーリング サーチ スペースで設定します。この方法により、ダイヤル プランでは、アシスタントの電話機の IPMA_RP 回線およびマネージャのプロキシ回線だけが、マネージャの電話機 DN に直接到達できるようになります。
図20-8 Unified CM Assistant のプロキシ回線モードのダイヤル プランの例
図20-8 の例では、プロキシ回線モードでの Unified CM Assistant に関するダイヤル プランの最小要件を示しています。ただし、実際のテレフォニー ネットワークには、ほとんどの場合、Unified CM Assistant のコーリング サーチ スペースおよびパーティションとの統合が必要な追加または既存のダイヤル プラン要件があります。図20-9 は、このような統合ダイヤル プランを示しています。この例では、前述したダイヤル プランは、2 つの追加のパーティションと 1 つの追加のコーリング サーチ スペースを処理する必要があります。図20-9 では On Cluster パーティションが追加され、追加の電話機 DN もいくつか含まれています。On Cluster パーティションは、既存のデバイスがこれらの追加 DN に到達できるように、既存の IPMA コーリング サーチ スペースの両方（IPMA_EVERYONE_CSS および MANAGER_EVERYONE_CSS）に追加されています。
UNRESTRICTED_CSS コーリング サーチ スペースも、既存のダイヤル プランに追加されています。このコーリング サーチ スペースは IPMA、IPMA_Everyone、および新たに追加した On Cluster パーティションで設定します。また、PSTN という 2 番目の新しいパーティションが追加されています。これには、共通ルート リスト（RL）、ルート グループ（RG）、およびボイス ゲートウェイ メカニズムを通じて、公衆網にコールをルーティングするために使用されるルート パターンのセットが含まれています。この PSTN パーティションは、UNRESTRICTED_CSS コーリング サーチ スペースの一部として設定します。
電話機およびデバイス回線のコーリング サーチ スペースの設定は、新しく追加したパーティションおよびコーリング サーチ スペースを組み込むために調整することができます。ただし、IPMA_RP およびアシスタントの電話機のマネージャ プロキシ回線は、MANAGER_EVERYONE_CSS コーリング サーチ スペースに割り当てたままにする必要があります。この例で、マネージャには公衆網への無制限アクセスが与えられる可能性があるため、マネージャの電話回線は、最初に設定された IPMA_EVERYONE_CSS コーリング サーチ スペースから、新しい UNRESTRICTED_CSS に移動されています。
図20-9 Unified CM Assistant のプロキシ回線モードのダイヤル プラン統合の例
図20-9 に示すように、追加のパーティションとコーリング サーチ スペースを新規または既存の Unified CM Assistant ダイヤル プランに統合することはできますが、基になるプロキシ回線モードのメカニズムが影響を受けないように注意する必要があります。
Unified CM Assistant シェアドライン モードでは、特別なダイヤル プランのプロビジョニングは必要ありません。注意の必要な Unified CM Assistant RP またはプロキシ回線が存在しないため、マネージャとアシスタントの電話機は、ネットワーク内の他の電話機と同様にコーリング サーチ スペースおよびパーティションで設定できます。シェアドライン モードに関する唯一の要件は、シェアドラインの機能を実現できるように、マネージャとアシスタントの DN が同じパーティションに属する必要があることです。
Unified CM Assistant Console
Unified CM Assistant Console デスクトップ アプリケーションは、アシスタントがマネージャの代わりにコールを処理するために必要です。このアプリケーションは、コールを処理するためのグラフィカル インターフェイスをアシスタントに提供します。また、このアプリケーションは、クリックダイヤルの短縮ダイヤルとディレクトリ エントリ、マネージャの電話機と環境の設定、すべてのマネージャの電話機の回線ステータスと可用性の表示など、その他の多くの機能を備えています。
Unified CM Assistant Console のインストール
Unified CM Assistant Console デスクトップ アプリケーションは、次の URL からインストールできます。
https:// <Server_IP-Address> :8443/ma/Install/Unified CM AssistantConsoleInstall.jsp
Unified CM Assistant Console の QoS
インストール後に、マネージャに代わってコールを処理するには、アシスタントがユーザ ID とパスワード（Cisco Unified CallManager の End-user ディレクトリで設定）を入力してアプリケーションにログオンし、Go Online アイコンまたはメニュー項目をクリックして、ステータスを「オンライン」に切り替える必要があります。ユーザがログインし、オンライン状態になると、デスクトップ アプリケーションは TCP ポート 2912 で Cisco Unified CallManager Unified CM Assistant サーバと通信します。このアプリケーションは、トラフィックを受信する場合に一時的な TCP ポートを選択します。Cisco Unified CallManager 上の Unified CM Assistant サーバは、コール制御（コール フローの生成と処理）のためにデスクトップ アプリケーションとインターフェイスするので、TCP ポート 2912 で Cisco Unified CallManager から受信されたトラフィックは、Cisco Unified CallManager によって 24 の Differentiated Services Code Point（DSCP）または CS3 の Per Hop Behavior（PHB）として、QoS マーキングされます。この方法により、Unified CM Assistant 電話制御トラフィックは、その他のすべてのコール シグナリング トラフィックと同様に、ネットワークを通じてキューに入れることができます。
対称的なマーキングとキューを保証するため、Cisco Unified CallManager の TCP ポート 2912 を宛先とする Unified CM Assistant Console アプリケーション トラフィックも、DSCP 24（PHB CS3）としてマーキングする必要があります。これにより、このトラフィックが、Cisco Unified CallManager および Unified CM Assistant サーバに向かうネットワーク パスに沿って適切なコール シグナリング キューに配置されます。Unified CM Assistant Assistant Console アプリケーションは、すべてのトラフィックをベストエフォートとしてマーキングします。つまり、スイッチ ポート レベル（または、可能な限りコンソール PC に近いネットワーク パスに沿った場所で）Access Control List（ACL; アクセス コントロール リスト）を適用することで、アプリケーション PC から送信され、TCP ポート 2912 の Cisco Unified CallManager を宛先とするトラフィックを、DSCP 0（PHB Best Effort）から DSCP 24（PHB CS3）に再マーキングする必要があります。
Unified CM Assistant Console のディレクトリ ウィンドウ
Assistant Console デスクトップ アプリケーションのディレクトリ ウィンドウを使用すると、アシスタントは Cisco Unified CallManager Directory エンドユーザを検索できます。ディレクトリ ウィンドウの Name フィールドに入力する検索文字列は、Unified CM Assistant サーバに送信され、Cisco Unified CallManager データベースに対して検索が直接実行されます。次に、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 CallManager から発生します。つまり、ディレクトリ検索トラフィックも 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 CallManager または Unified CM Assistant サーバ（あるいはその両方）から低速 WAN リンクによって分離されている多数のアシスタントが存在する。
Unified CM Assistant の冗長性
Unified CM Assistant アプリケーションの冗長性は、次の 2 つのレベルで実現できます。
このレベルでの冗長性については、Unified CM Assistant サービスまたはサーバの冗長性、および CTIManager サービスの冗長性に関して検討する必要があります。同様に、パブリッシャの冗長性の欠如、およびこのコンポーネントの障害の影響も検討する必要があります。
このレベルでの冗長性については、アシスタントとマネージャの電話機、Unified CM Assistant ルート ポイント、および Unified CM Assistant Console デスクトップ アプリケーションに関連して検討し、さらにアシスタントとマネージャの到達可能性に関する冗長性として検討する必要があります。
サービスとコンポーネントの冗長性
図20-7 に示すように、Unified CM Assistant 機能は、主に Cisco CallManager IP Manager Assistant サービスおよび Cisco CTIManager サービスに依存します。いずれの場合も、冗長性はプライマリおよびバックアップのメカニズムを使用して自動的に組み込まれます。Cisco Unified CM Assistant Server (Primary) IP Address および Cisco Unified CM Assistant Server (Backup) IP Address のサービス パラメータを使用すると、2 つの Unified CM Assistant サーバ（Cisco Unified CM Assistant サービスを実行しているノード）を 1 つのクラスタ内で定義できます（「Unified CM 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 サーバ用に定義できます（「Unified CM Assistant のサービス パラメータ」を参照してください）。これによって、Unified CM Assistant アプリケーションで使用する CTIManager が、クラスタあたり合計で最大 4 つ得られます。これらのパラメータを設定すると、CTIManager サービスに冗長性を与えることができます。このため、プライマリ CTIManager に障害が発生した場合でも、CTIManager サービスはバックアップ CTIManager から提供できます。クラスタ ノードのすべての Unified CM Assistant および CTIManager サービスに障害が発生した場合は、Unified CM Assistant ルート ポイントおよび Unified CM Assistant Console デスクトップ アプリケーションがダウンし、その結果 Unified CM Assistant アプリケーション全体がダウンします。
（注） Unified CM Assistant シェアドライン モードで設定した場合、Unified CM Assistant および
CTIManager サービスが障害によって完全に停止しても、電話機は 1 本の回線を共有し続けるため、アシスタントは引き続きマネージャの代わりにコールを処理できます。ただし、Unified CM Assistant Console デスクトップ アプリケーションと DND の機能は、使用できなくなります。
図20-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 の障害に対して追加の冗長性が提供されます。
（注） 図20-10 で説明するシナリオは、特別な状況を示しています。通常の動作時に、同じクラスタ内に 2 つのアクティブまたはプライマリ Unified CM Assistant サーバは存在できません。2 つの Unified CM Assistant サーバがネットワークを通じて通信できる場合、一方のサーバはバックアップ モードとなり、要求を処理できません。
図20-10 WAN を通じた 2 サイト クラスタ化による Unified CM Assistant の冗長性
前述のように、パブリッシャは Cisco Unified CallManager データベースへの書き込み時に単一の障害点となります。Unified CM Assistant アプリケーションに対するパブリッシャの障害の影響は、エクステンション モビリティに対する影響ほど大きくありません。パブリッシャに障害が発生しても、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 は、デバイス登録用のデバイス プールと Cisco Unified CallManager グループ設定の組み合せによって提供される組み込み冗長性に依存します。
また、一部のデバイスは、追加の冗長性および機能のためにコンポーネント サービスに依存します。たとえば、Unified CM Assistant RP はコール制御機能に関して CTIManager にも依存するため、前の項で説明したプライマリおよびバックアップ CTIManager に依存する必要があります。Unified CM Assistant Console デスクトップ アプリケーションも、冗長性と機能がコンポーネント サービスに依存します。Assistant Console デスクトップ アプリケーションは、マネージャの着信コールの処理を持続できるように、プライマリ Unified CM Assistant サーバからバックアップ サーバ（およびその反対）への自動フェールオーバーをサポートしています。この自動フェールオーバーに要する時間は、Cisco Unified CM Assistant Console Heartbeat Interval および Cisco Unified CM Assistant Console Request Timeout のサービス パラメータを使用して制御できます（「Unified CM Assistant のサービス パラメータ」を参照してください）。ハートビートまたはキープアライブの頻度は、Unified CM Assistant サーバの障害がデスクトップ アプリケーションですばやく検出されるように設定しますが、キープアライブをあまり頻繁に送信することで、ネットワークに悪影響を与えないように注意してください。多数の Assistant Console アプリケーションが使用されている場合、この考慮事項は特に重要です。
マネージャおよびアシスタントの到達可能性に確実に冗長性を与えるフェールオーバー メカニズムは、他にもいくつかあります。第 1 に、（プロキシ回線モードで）Unified CM Assistant アプリケーションを通じてマネージャのアシスタントに送信されるコールは、設定した時間の経過後にそのコールへの応答がない場合、次の応答可能なマネージャのアシスタントに転送します。設定した時間の経過後に次のアシスタントがコールに応答しない場合、そのコールは次の応答可能なマネージャのアシスタントに再び転送され、それ以降も同様に転送が続けられます。このメカニズムは、Cisco Unified CM Assistant RNA Forward Calls および Cisco Unified CM Assistant RNA Timeout のサービス パラメータを使用して設定します（「Unified CM Assistant のサービス パラメータ」を参照してください）。第 2 に、前述したように、クラスタ ノードのすべての Unified CM Assistant と CTI サービスに障害が発生した場合、Unified CM Assistant RP は使用できなくなります。ただし、Unified CM Assistant RP の CFNA 設定に基づいて、すべてのマネージャの DN に対するコールはマネージャの電話機に直接呼び出され、マネージャの到達可能性に十分な冗長性が与えられます。
Unified CM Assistant のガイドラインと制限
Unified CM Assistant には、重複および共有内線番号に関して次の制限があり、ディレクトリ番号のプロビジョニングを計画する場合に注意する必要があります。
• プロキシ回線モードの Unified CM Assistant では、アシスタントの電話機のプロキシ回線番号は、異なるパーティション間でも一意にする必要があります。
• プロキシ回線モードの Unified CM Assistant では、2 人のマネージャは異なるパーティション間でも、同じ Unified CM Assistant 制御回線番号（DN）を持つことができません。
また、Unified CM Assistant アシスタントは、Cisco Unified CallManager Release 4. x から Cisco Unified CallManager 5.0 にアップグレードする場合、Unified CM Assistant Assistant Console デスクトップ アプリケーションが最新バージョンに自動的にアップグレードされないことに注意してください。代わりに、旧バージョンの Unified CM Assistant Console デスクトップ アプリケーションをアンインストールし、新しいバージョンをインストールする必要があります。
Unified CM Assistant のパフォーマンスとキャパシティ
Cisco Unified CM Assistant アプリケーションは、次のキャパシティをサポートしています。
• マネージャあたり最大 10 人のアシスタントを設定できる。
• 1 人のアシスタントに対して最大 33 人のマネージャを設定できる。
• MCS-7845 サーバが含まれるクラスタあたり最大 1250 人のアシスタントと 1250 人のマネージャを設定できる。
• クラスタあたり最大 2 つの Unified CM Assistant サーバを配置できる（プライマリとバックアップ）。
• Unified CM Assistant 用として、クラスタあたり最大 4 つの CTIManager を設定できる（2 つの Unified CM Assistant サーバのそれぞれに対してプライマリおよびバックアップの CTIManager を指定できます）。
Cisco Unified CM Assistant アプリケーションは、回線監視および電話制御のために CTIManager と対話します。Unified CM Assistant またはマネージャの電話機の各回線は、CTIManager への接続を生成します。また、各 Unified CM Assistant ルート ポイントが CTIManager への接続を生成します。Unified CM Assistant を設定する場合、CTI 接続に対する全体的なクラスタ制限に関して、必要な CTI 接続の数を検討する必要があります（MCS-7845 プラットフォームのあるクラスタあたり 10,000 CTI 接続または MCS-7835 および MCS-7825 サーバが含まれるクラスタあたり 3200 CTI 接続）。他のアプリケーション用に追加の CTI 接続が必要な場合、Unified CM Assistant のキャパシティが制限されることがあります。
Unified CM Assistant のキャパシティの詳細については、次の Web サイトにある Cisco Unified CallManager と Unified CM Assistant のデータ シート、マニュアル、およびリリース ノートを参照してください。
Unified CM Assistant と EM の相互作用
Unified CM Assistant のマネージャは、EM を使用して、プロキシ回線モードとシェアドライン モードの両方でそれぞれの電話機にログインできます。ただし、そのマネージャは、エンドユーザ ディレクトリの Cisco Unified CM Assistant Manager 設定ページで、Mobile Manager として設定する必要があります。Unified CM Assistant と組み合せて EM を使用する場合、ユーザが EM を使用して複数の電話機にログインできないようにする必要があります。この動作は、EM サービス パラメータの Multiple Login Behavior を使用して有効または無効にできます（「EM のサービス パラメータ」を参照してください）。クラスタ内で同じユーザによる複数の EM ログインが必要な場合、EM を使用する Unified CM Assistant のマネージャに、複数の電話機にログインしないよう指示する必要があります。マネージャが EM で 2 つの異なる電話機にログインすることを許可すると、2 人のマネージャは異なるパーティション間でも同じ Unified CM Assistant 制御回線番号（DN）を持つことができないという、前述の制限に違反することになります。
（注） Unified CM Assistant のアシスタントは、Mobile Assistant の概念がないため、EM を使用してそれぞれの電話機にログインすることはできません。
Attendant Console
Cisco Unified CallManager Attendant Console（AC）アプリケーションを使用すると、受け付け係が企業内でコールに応答して転送したり、コールを送信したりすることができます。係員は Windows 2000 または Windows XP を実行している PC に、クライアント/サーバ Java アプリケーションの Attendant Console をインストールできます。Attendant Console は Cisco CallManager Attendant Console Server（Cisco Unified CallManager AC Server）に接続し、ログイン サービス、回線状態、およびディレクトリ サービスを提供します。1 つの AC サーバに複数の Attendant Console を接続できます。
AC Phone のサポート
• Cisco Unified IP Phone 7905G
• Cisco Unified IP Phone 7911G
• Cisco Unified IP Phone 7912G および 7912G-A
• Cisco Unified IP Phone 7940G、7941G、および 7941G-GE
• Cisco Unified IP Phone 7960G、7961G、および 7961G-GE
Cisco Unified CallManager および AC のサービス パラメータ
AC アプリケーションを有効にするには、システム管理者は Cisco Unified CallManager Serviceability インターフェイスからいくつかの Cisco Unified CallManager 機能サービスをアクティブにし、起動する必要があります。また、AC サービス パラメータは、AC アプリケーションの動作を決定するための設定およびカスタマイズのオプションを提供します。
AC 用の Cisco Unified CallManager サービス
AC アプリケーションは次の機能サービスに依存します。これらのサービスは、Serviceability ページから手動でアクティブにする必要があります。
• Cisco CallManager Attendant Console Server
Cisco CallManager Attendant Console Server サービスは AC Desktop アプリケーションへのインターフェイスを提供し、Cisco CTIManager サービスおよび Cisco Unified CallManager データベースと対話します。Cisco CTIManager サービスは、電話とコールの制御のために Cisco CallManager Service および Cisco CallManager Attendant Console Server サービスとインターフェイスし、対話します。AC Desktop アプリケーションともインターフェイスします。
AC のサービス パラメータ
次の項目は、AC 機能に関連する Cisco CallManager Attendant Console Server サービス パラメータの一部のリストです。
• Directory Sync Period（デフォルト値 = 3）
このパラメータは、AC サーバの AutoGenerated.txt ファイルと Cisco Unified CallManager のエンドユーザ ディレクトリの同期のための間隔を、時間単位で指定します。エンドユーザ ディレクトリへの変更は、この間隔が経過するまで AutoGenerated.txt ファイルに反映されません。
このパラメータは、AC サーバが CTIManager にログインし、通信するために使用するアプリケーション ユーザ名を指定します。
AC のアプリケーション ユーザ
AC が正しく動作するには、 ac という名前のアプリケーション ユーザを Cisco Unified CallManager で設定する必要があります。ac アプリケーション ユーザは、AC サーバが CTIManager と対話するために必要です。このアプリケーション ユーザが設定されていないと、コンソール担当者はコールを受信できません。
（注） アプリケーション ユーザは、Cisco Unified CallManager 5.0 データベース内のエンド ユーザとは異なり、ディレクトリ内のエンド ユーザとは別に保存されます。したがって、ディレクトリ検索ではアプリケーション ユーザ エントリが返されません。Cisco Unified CallManager 5.0 のアプリケーション ユーザとエンド ユーザの詳細については、「LDAP ディレクトリ統合」を参照してください。
ac ユーザには、アプリケーション ユーザの設定ページで次のグループ アクセス権を設定する必要があります。
• Standard CTI Allow Control of All Devices
• Standard CTI Allow Call Park Monitoring
管理者は、このアプリケーション ユーザ名を ac 以外の名前に変更できます。ac 以外のユーザ名に設定した場合、JTAPI Username サービス パラメータに新しいユーザ名を設定する必要があります（「AC のサービス パラメータ」を参照してください）。
AC の機能とアーキテクチャ
図20-11 は、AC の機能と動作の基本的な例を示しています。最初に、AC クライアントは Cisco Unified CallManager 上の AC サーバにログインし、登録されます（ステップ 1）。電話機 A は Cisco Unified CallManager の AC パイロット ポイントに対して設定されたディレクトリ番号（DN）をコールします（ステップ 2）。AC パイロット ポイントはこのコールを代行受信し、ハント グループ設定に基づいて、使用可能なメンバーの 1 つにコールを転送します。この場合、コールは Attendant ユーザ AC1 の電話機の回線 2 に送信されます（ステップ 3）。AC1 がまだ最初のコールで通話しているときに、パイロット ポイント番号 10001 に 2 番目のコールが着信した場合、そのコールはハント グループの別の使用可能なメンバーにルーティングされます。この場合、そのコールは、Attendant ユーザ AC2 の電話機の回線 1 に転送されます（ステップ 4）。
コールをルーティングするには、パイロット ポイントが次のいずれかのルーティング アルゴリズムに基づいて、ハント グループの次の使用可能なメンバーを決定します（パイロット ポイントの「Route Calls to」フィールドで設定します）。
このアルゴリズムでは、着信コールが、使用可能なグループの最初のメンバーにルーティングされます。
このアルゴリズムでは、着信コールが、アイドル状態（コールの処理なし）の最も長かったメンバーにルーティングされます。
このアルゴリズムでは、着信コールが、使用可能なメンバーにラウンドロビン方式でルーティングされます。
このアルゴリズムでは、着信コールがキューに入れられ、すべての使用可能なメンバーの AC デスクトップ アプリケーションに対して同時に通知が送信されます。
図20-11 に示す例では、First Available アルゴリズムを使用しています。ハント グループのルーティング アルゴリズム、および Broadcast ルーティング アルゴリズムのキュー設定は、すべて Cisco Unified CallManager の Pilot Point 設定ページで設定します。
AC のアーキテクチャ
AC アプリケーションの機能と同様に、そのアーキテクチャについて理解することも重要です。図20-12 は、AC のメッセージ フローとアーキテクチャを示しています。AC ユーザ用に AC を設定すると、次の一連の対話とイベントが発生します。
1. コンソール担当者の電話機は Cisco Unified CallManager サービスに登録され、コール フロー処理にキーパッドとソフトキーが使用されます（図20-12 のステップ 1 を参照してください）。
2. Attendant Console デスクトップ アプリケーションは、JTAPI を使用して電話と回線の制御のために CTIManager サービスと通信し、インターフェイスします。また、このデスクトップ アプリケーションは、Remote Method Invocation（RMI）を介して AC 機能のために AC サービスおよびサーバとインターフェイスします（図20-12 のステップ 2 を参照してください）。
3. 次に、AC サーバは、回線監視情報および電話制御情報を交換するために、CTIManager サービスと対話します（図20-12 のステップ 3 を参照してください）。
4. 同様に、CTIManager サービスは、Cisco CallManager Service に AC 電話制御情報を渡し、さらに AC パイロット ポイントを制御します（図20-12 のステップ 4 を参照してください）。
5. それと並行して、AC サービスは、Cisco Unified CallManager データベースとの間で、AC アプリケーション情報の読み取りと書き込みを行います（図20-12 のステップ 5 を参照してください）。
（注） 図20-12 は、すべて同じノードで実行されている Cisco Unified CallManager、CTIManager、および Attendant Console Server サービスを示していますが、この設定は必須ではありません。これらのサービスはクラスタ内の複数のノードに分散できますが、説明を簡単にするためにここでは同じノードにあるものとしています。
Attendant Console デスクトップ アプリケーション
Attendant Console デスクトップ アプリケーションは、グラフィカルな仮想コンソールを通じてコールを処理するため、コンソール担当者で使用されます。コール処理に加えて、このアプリケーションは、クリックダイヤルの短縮ダイヤルとディレクトリ エントリ、環境の設定、ディレクトリおよび短縮ダイヤル ウィンドウでの他のユーザに対する回線ステータスおよび可用性の表示など、追加の機能を備えています。
Attendant Console のインストール
Attendant Console デスクトップ アプリケーションは、次の URL からダウンロードできます。
https:// <Server_IP-Address> :8443/plugins/CiscoAttendantConsoleClient.exe
（ここで、 <Server_IP-Address> は、クラスタ内のいずれかのノードの IP アドレスです）
CiscoAttendantConsoleClient.exe ファイルは、コンソール担当者の PC にダウンロードしたら、インストールも実行する必要があります。
Attendant Console の QoS
Attendant Console デスクトップ アプリケーションのインストール後、コンソール担当者は、（Cisco Unified CallManager の Cisco Unified CM Attendant Console User ページの設定に従って）AC のユーザ ID およびパスワードを入力して、このコンソール アプリケーションにログオンします。
（注） AC のユーザ ID は AC デスクトップ アプリケーションへのログインに必要で、エンドユーザ ディレクトリで設定されるユーザおよび Cisco Unified CallManager のアプリケーション ユーザとは異なります。これらのユーザはエンドユーザ ディレクトリとは別に保存されるため、ディレクトリ検索で AC ユーザ エントリは返されません。
AC ユーザがログオンすると、AC デスクトップ アプリケーションは、主に Remote Method Invocation（RMI）および Java Telephony Application Programming Interface（JTAPI）を使用して、Cisco Unified CallManager と通信します。RMI は、登録、キープアライブ、および情報交換などのデスクトップ クライアントと AC サーバとの間の通信に使用されます。RMI トラフィックは、TCP ポート 1101 ～ 1129 の Cisco Unified CallManager、および 1 つ以上の一時的な TCP ボートのデスクトップ アプリケーションから発生します。すべての RMI トラフィックは、ベストエフォートとしてマーキングされます。
JTAPI トラフィックは、Cisco Unified CallManager 上の CTIManager と AC デスクトップ アプリケーションとの間で、デバイスおよび回線制御情報とコール制御トラフィックを伝送します。JTAPI トラフィックは、TCP ポート 2748 の Cisco Unified CallManager、および一時的な TCP ボートのデスクトップ アプリケーションから発生します。
CTIManager と AC クライアント間の JTAPI トラフィックはコール制御（コール フローの生成と処理）に使用されるため、24 の DSCP（CS3 の PHB）で、Cisco Unified CallManager により QoS マーキングされます。この方法により、AC 電話制御トラフィックは、その他のすべてのコール シグナリング トラフィックと同様に、ネットワークを通じてキューに入れることができます。対称的なマーキングとキューを保証するため、Cisco Unified CallManager TCP ポート 2748 を宛先とする Attendant Console アプリケーション トラフィックも DSCP 24（PHB CS3）としてマーキングする必要があります。これにより、このトラフィックが、Cisco Unified CallManager および CTIManager に向かうネットワーク パスに沿って適切なコール シグナリング キューに配置されます。ただし、AC クライアント アプリケーションはすべてのトラフィックをベストエフォートとしてマーキングするため、アクセス コントロール リスト（ACL）は、このトラフィックに適切に再マーキングするように設定する必要があります。
AC サーバおよびデスクトップ クライアントのマーキングは、次のように要約できます。
• Cisco Unified CallManager は、24 の DSCP（CS3 の PHB）で TCP ポート 2748 から発生するすべての JTAPI トラフィックを適切にマーキングします。
• Attendant Console デスクトップ アプリケーションは、Cisco Unified CallManager TCP ポート 2748 を宛先とする JTAPI トラフィックをベストエフォートとしてマーキングします。つまり、ACL は、0 の DSCP から 24 の DSCP（CS3 の PHB）まで、アプリケーションが Cisco Unified CallManager および AC サーバに送信する JTAPI トラフィックを再マーキングするように、スイッチ ポート レベルで適用する必要があります。
Attendant Console のディレクトリ ウィンドウ
Attendant Console デスクトップ アプリケーションのディレクトリ ウィンドウを使用すると、コンソール担当者は Cisco Unified CallManager テレフォニー環境内のエンドユーザを検索できます。一般に、ディレクトリのリストは、Cisco Unified CallManager ディレクトリ自体の検索ではなく、ディレクトリ ファイルの検索によって取得されます。AC アプリケーション ユーザがディレクトリ ウィンドウに検索条件を入力すると、次のいずれかのディレクトリ ファイルが検索されます。
このディレクトリ ファイルは、ローカル PC またはローカル ドライブ パスに格納されています。このファイルを検索するには、Attendant Settings ダイアログボックスの Advanced タブの Path Name of Local Directory File フィールドで、その名前と場所を設定する必要があります。このフィールドでファイル名と場所が設定されていない場合、このオプションはスキップされ、ディレクトリ検索はその他のいずれかのディレクトリ ファイルに対して実行されます。
このディレクトリ ファイルは、AC サーバによって Cisco Unified CallManager データベースのエンドユーザ テーブルから自動的に生成され、Cisco Unified CallManager サーバに格納されています。ローカル ディレクトリのユーザ リスト ファイルが設定されていない場合、AC デスクトップ アプリケーションは、Cisco Unified CallManager からこのファイルを自動的にダウンロードします。AutoGenerated.txt ファイルは、このファイルの情報が正確になるように、AC サーバにより定期的にエンドユーザ ディレクトリから再生成または同期されます。この同期の頻度は、Directory Sync Period AC サービス パラメータで決定されます（「AC のサービス パラメータ」を参照してください）。デフォルトでは、このパラメータは 3 時間に設定されるため、AutoGenerated.txt ファイルは 3 時間ごとに更新されます。
このファイルは、Cisco Unified CM Attendant Console User File Upload ツール（ Application > Cisco Unified CM Attendant Console ）を使用して、管理者が Cisco Unified CallManager に手動でインポートした場合にだけ使用できます。アップロードされると、Cisco Unified CallManager サーバの AutoGenerated.txt ファイルがこのファイルで置き換えられます。したがって、ローカル ユーザ リスト ファイルが設定されていない場合、AC デスクトップ アプリケーションは AutoGenerated.txt ファイルではなくこのファイルをダウンロードします。
AC デスクトップ アプリケーションが起動するたびに、上記のいずれかのディレクトリ ファイルがダウンロード（AutoGenerated または Corporate Directory.txt ファイルの場合）およびロードされます。アプリケーションが動作している限り、そのディレクトリ ファイルは、Attendant Settings ダイアログボックスの Advanced タブの Directory Reload Interval 設定に基づいて定期的にダウンロードまたは再ロード（あるいはその両方）が行われます。すべてのディレクトリ ファイルは、各行が 1 つのユーザ エントリのカンマ区切り形式になります。
デスクトップ アプリケーション内で、ディレクトリ ウィンドウ検索のためにディレクトリ ファイルをダウンロードすることで生成される追加のトラフィックは一般にわずかですが、いくつかの理由のために問題が生じることがあります。第 1 に、Cisco Unified CallManager ディレクトリ サイズが大きい場合、コンソール アプリケーションでダウンロードされる、ディレクトリ全体を含んだディレクトリ ファイルによって、ネットワークに大量のトラフィックが発生することがあります。この要因に、ネットワーク内の多数の AC デスクトップ アプリケーションがある、ダウンロード間隔が短い、集中型のコール処理が配置されている、コンソール アプリケーションが低速 WAN リンクを通じてリモート サイトで実行される、などの条件が加わると、ネットワーク輻輳、遅延、およびキューの発生する可能性が非常に高くなります。
デスクトップ アプリケーション用 PC でローカル ユーザ リスト ファイルを使用すると、ネットワーク帯域幅や輻輳に関する多くの問題が解消されますが、AC デスクトップのディレクトリ ウィンドウ内の Advanced search 機能で問題が発生しやすくなります。AC デスクトップ アプリケーションのディレクトリ ウィンドウ内のその他のすべてのディレクトリ検索は、ローカル ユーザ リスト ファイルまたはダウンロードされたファイルのいずれかに対して実行されますが、ディレクトリ ウィンドウの Advanced ボタンで開く Advanced search ウィンドウを使用して実行する検索には例外があります。Advanced search ウィンドウを使用した検索では、ディレクトリ ファイル検索規則がバイパスされ、実行時に Cisco Unified CallManager エンドユーザ ディレクトリに対して直接生成されます。つまり、定期的なディレクトリ ファイルのダウンロード以上に、ネットワーク上に追加のトラフィックが生じます。さらに、Advanced search 機能を使用してダウンロードできるエントリ数には制限がありません。このようなリアルタイム検索と取得で追加のネットワーク負荷が発生するだけでなく、返されるエントリに制限がないため、この追加の負荷は非常に大きくなることがあります。ディレクトリ ファイルのダウンロードと Advanced directory search の両方で発生するトラフィックは、ベストエフォートとしてマーキングされる RMI プロトコルを使用するため、ネットワーク パスでプライオリティ ボイス メディアおよびプロビジョニングされたコール シグナリング キューに輻輳の発生するリスクはありません。ただし、AC デスクトップ アプリケーション ディレクトリのトラフィックによって、ベストエフォート キューの輻輳が発生し、ディレクトリ トラフィックおよびその他のベストエフォート ネットワーク データ トラフィックのドロップにつながる可能性が残ります。
AC デスクトップ アプリケーションのディレクトリ ファイルのダウンロードおよびディレクトリ検索では、ネットワークの輻輳が発生する可能性があるため、次の対策を取ることをお勧めします。
• 管理者は、すべての Attendant Console ユーザに、Advanced directory search 機能の使用制限を求める必要があります。さらに、ユーザがこの機能を使用する場合は、返されるエントリの数を減らすために、Advanced search のパラメータ フィールドにできる限り多くの情報を入力してもらう必要があります。
• 集中型のコール処理配置シナリオでは、低速 WAN リンクを通じた Cisco Unified CallManager からのディレクトリ ファイルの定期的なダウンロードをなくすために、リモート サイト AC ユーザに対して AC クライアント PC またはネットワーク共有のユーザ リスト ファイルを利用する必要があります。最小限の管理オーバーヘッドでこの目標を達成する 1 つの方法は、各リモート サイトのローカル ネットワーク共有にユーザ リスト ファイルを提供することです。このファイルは、Cisco Unified CallManager データベースと同期するようにスケジューリングし、オフピーク時間または深夜にリモート ネットワーク共有に自動的にロードすることで、ピーク業務時間中にネットワーク輻輳が発生する可能性を抑えます。このようにすると、毎朝、AC ユーザがデスクトップ コンソールを起動するときに、このアプリケーションは最新のディレクトリ ユーザ リストをダウンロードできます。
これらの推奨事項は、次の 1 つ以上の条件が該当する場合は特に重要です。
• Cisco Unified CallManager クラスタ内に多数の AC ユーザが存在する。
• 低速 WAN リンクによって Cisco Unified CallManager から分離された多数の AC ユーザが存在する。
AC の冗長性
AC アプリケーションの冗長性は、次の 2 つのレベルで実現できます。
このレベルでの冗長性については、AC サービスまたはサーバの冗長性、および CTIManager サービスの冗長性に関して検討する必要があります。同様に、パブリッシャの冗長性の欠如、およびこのコンポーネントの障害の影響も検討する必要があります。
このレベルでの冗長性は、コンソール担当者の電話機、AC パイロット ポイント、および Attendant Console デスクトップ アプリケーションに関連して検討し、さらにコンソール担当者とパイロット ポイントの到達可能性に関する冗長性として検討する必要があります。
サービスとコンポーネントの冗長性
図20-12 に示すように、AC 機能は、主に Cisco CallManager Attendant Console Server サービスおよび Cisco CTIManager サービスに依存します。いずれの場合にも、冗長性は Cisco Unified CallManager クラスタ アーキテクチャに組み込まれます。AC Server サービスと CTIManager サービスの両方に対する冗長性は、各サービスが実行されるクラスタ内のノード数によって決定されます。冗長性は、サーバで障害が発生しても必要なサービスを提供し続けることができる障害の最大数で決まります。この数は、公式（N - 1）で表現でき、N はサービスを実行しているサーバの数です。 たとえば、クラスタ内の 3 台のサーバが AC Server サービスを実行している場合は、N = 3 です。このサービスの冗長性を計算すると、（3 - 1）、つまり 2 になるため、最大 2 台のサーバの障害に対して冗長性が確保されることになります。CTIManager の冗長性は、同じ公式を使用して計算できます。これらのサービスで最大限の冗長性を得るには、クラスタ内のすべてのコール処理ノードで AC Server サービスと CTIManager サービスの両方を実行することをお勧めします。これに対し、最小限の冗長性を得るには、これらの各サービスを、クラスタ内の少なくとも 2 つのコール処理ノードで実行する必要があります。
パブリッシャは、Cisco Unified CallManager データベースへの書き込み時に単一の障害点となります。AC アプリケーションに対するパブリッシャの障害の影響はわずかです。パブリッシャに障害が発生しても、AC アプリケーションのすべての部分は引き続き動作します。ただし、AC アプリケーション設定を変更できなくなります。パブリッシャが復元するまで、AC パイロット ポイント、ハント グループ、およびコンソール担当者の電話機の設定は変更できません。
デバイスと到達可能性の冗長性
デバイス レベルでの AC の冗長性は、いくつかのメカニズムに依存しています。まず第 1 に、コンソール担当者の電話機と AC パイロット ポイントは、デバイス登録用のデバイス プールと Cisco Unified CallManager グループ設定の組み合せによって提供される組み込み冗長性に依存します。
また、一部のデバイスは、追加の冗長性および機能のためにコンポーネント サービスに依存します。たとえば、AC パイロット ポイントはコール制御機能で CTIManager にも依存するため、前の項で説明した CTIManager の冗長性に依存する必要があります。
Attendant Console デスクトップ アプリケーションも、冗長性および機能がコンポーネント サービスに依存します。AC デスクトップ アプリケーションは、着信コールの処理を継続できるように、冗長 AC Servers サービスと CTIManager サービス間の自動フェールオーバーをサポートしています。AC デスクトップ アプリケーションから見ると、これらのサービスの冗長性は以下に説明するように、Cisco Unified CallManager グループ メカニズムによって決定されます。第 1 に、AC デスクトップ アプリケーションが起動され、コンソール担当者がログインすると、このアプリケーションはデバイス プールおよび Cisco Unified CallManager グループ設定に基づいて、Cisco Unified CallManager のリストをダウンロードします。このリストは、ローカル PC の GlobalSettings.xml ファイルに保存され、デスクトップ用の CTIManager サービスの冗長性を決定します。
（注） Attendant Settings ダイアログボックスの Basic タブの Attendant Server Host Name フィールドまたは IP Address フィールドには、コンソール担当者の電話機に対して Cisco Unified CallManager グループで設定したプライマリ Cisco Unified CallManager サーバの IP アドレスを入力することをお勧めします。このように入力すると、障害が発生した場合、コンソール担当者の電話機と AC デスクトップ アプリケーションの両方が、電話機に設定された Cisco Unified CallManager グループの次のサーバに同時にフェールオーバーします。
次に、デスクトップ アプリケーションは AC サーバの冗長性に関して、デバイス プールおよび（コンソール担当者の電話機がメンバーとなっている）AC パイロット ポイントの Cisco Unified CallManager グループに依存します。いずれの場合にも、Cisco Unified CallManager グループには最大 3 台のサーバを設定できるため、最大 3 次の冗長性が実現します。
デスクトップ アプリケーションに対して、これらのサービスの冗長性をさらに与えるには、Attendant Settings ダイアログボックスの Advanced タブの Call Processing Server Host Names フィールドまたは IP Addresses フィールドを使用します。このフィールドで Cisco Unified CallManager サーバのカンマ区切りリストを設定すると、Cisco Unified CallManager グループ メカニズムを超える冗長性を実現できます。ただし、この追加の冗長性はグループ メカニズムを使い切った場合にだけ役に立つため、不要なことがあります。この追加の冗長性は、実際上、コンソール担当者の電話機と AC パイロット ポイントに登録サービスを提供している最初の 3 つのサーバが使用できない（つまり、コンソール担当者の電話機と AC パイロット ポイントも使用できない）場合にだけ利用されます。電話機とパイロット ポイントが使用できない場合、デスクトップ アプリケーションは使用できません。
最後に、AC パイロット ポイントでハント グループ メカニズムに組み込まれた到達可能性の冗長性（これにより、所定の冗長性が着信コールの発信者に提供されます）のほかに、追加の冗長性を AC パイロット ポイントの障害に対して提供することもできます。AC パイロット ポイントに障害が発生した場合、パイロット ポイント番号をダイヤルする着信コールの発信者にはビジー トーンが聞こえます。パイロット ポイントにフェールオーバー メカニズムを提供するには、パイロット ポイント回線設定画面の Call Forward No Answer（CFNA）フィールドで、別のパイロット ポイント番号を設定します。この CFNA メカニズムによって、障害の発生したパイロット ポイントへの発信者は、コールの処理およびルーティングのために別のパイロット ポイントに確実に転送されます。
AC のガイドラインと制限
AC は JTAPI レベルでパーティションを認識するため、Attendant Console デスクトップ アプリケーションは回線制御という点に関してパーティションを認識します。これに対し、他の AC コンポーネントはパーティションを認識しなかったり、重複や共有内線番号に関していくつかの制限があったりします。ディレクトリ番号のプロビジョニングを計画する場合は、次のガイドラインに注意してください。
–シェアドラインは、ハント グループ メンバーが使用することはできません。
–重複内線番号は、ハント グループ メンバーが使用することはできません。
–ハント グループ メンバーのディレクトリ番号は、Cisco Unified CallManager 回線グループに追加することはできません。
–シェアドラインは、パイロット ポイントのディレクトリ番号として使用することはできません。
–パイロット ポイントのディレクトリ番号は、Cisco Unified CallManager 回線グループに追加することはできません。
コンソール ディレクトリおよび短縮ダイヤルのウィンドウ内の回線ステータス表示では、シェアドラインと重複内線番号については何もわかりません。このため、共有または重複回線が見つかった場合は、最近変更された回線インスタンスのステータスだけが表示されます。
また、ハント グループ メンバーのディレクトリ番号があるすべてのパーティションを含むコーリング サーチ スペースを、必ずすべての AC パイロット ポイントに設定してください。このように設定しないと、1 つ以上のメンバーが到達不可能になります。
AC のパフォーマンスとキャパシティ
Cisco AC アプリケーションは、次のキャパシティをサポートしています。
• Cisco MCS-7845 サーバは最大 1250 の AC デバイスをサポートします。
• Cisco MCS-7835 サーバは最大 1000 の AC デバイスをサポートします。
• Cisco MCS-7825 サーバは最大 750 の AC デバイスをサポートします。
（注） AC デバイスのキャパシティ数は、ハント パイロットとハント パイロット メンバーの間で分割できます。たとえば、MCS-7845 サーバでは AC デバイスの最大数が 1250 ですが、このキャパシティをさまざまな方法で割り当てることができます。125 のハント パイロットを用意して各ハント パイロットに 10 メンバーを含めたり、10 のハント パイロットを用意して各ハント パイロットに 125 メンバーを含めたりすることができます。
Cisco AC アプリケーションは、回線監視および電話制御のために CTIManager と対話します。コンソール担当者の電話機の各回線が、CTIManager への接続を生成します。また、各 AC パイロット ポイントが CTIManager への接続を生成します。AC アプリケーションを設定する場合、CTI 接続に対する全体的なクラスタ制限に関して、必要な CTI 接続の数を検討する必要があります（MCS-7845 プラットフォームのあるクラスタあたり 10,000 CTI 接続または MCS-7835 および MCS-7825 サーバのあるクラスタあたり 3200 CTI 接続）。他のアプリケーションのために追加の CTI 接続が必要な場合、AC アプリケーションのキャパシティが制限されることがあります。
AC と EM の相互作用
AC Console ユーザは、EM を使用してそれぞれの電話機にログインできます。ただし、コンソール担当者の電話機で設定が変更されるたびに、AC デスクトップ アプリケーションでは、AC ユーザがアプリケーションからログアウトしてログインし直す必要があります。EM ログイン（またはログアウト）によって電話機で設定が変更されるため、AC と EM を組み合せて使用する場合、ユーザは EM を使用してそれぞれの電話機にログインしてから、AC デスクトップ アプリケーションにログインします。これによって、デスクトップ アプリケーションからログアウトしてログインし直す必要がなくなります。
また、EM および AC の DN は、Device Members ではなく User Members として AC パイロット ポイントのハント グループに追加する必要があります。このようにすると、EM を使用してそれぞれの電話機にログインしていないために利用不可となっている AC ユーザに、着信コールがルーティングされなくなります。ハント グループの User Members は、ユーザ名と回線番号の両方で設定されます。これに対して、Device Members は、ディレクトリ番号だけで設定されます。パイロット ポイントは、ディレクトリ番号がビジーでないことだけを確認してから、Device Members にコールをルーティングします。パイロット ポイントは、コンソール担当者の電話機の回線番号が使用可能で、AC ユーザがログオンし、オンラインであることを確認してから、User Members にコールをルーティングします。このため、User Members として EM AC ユーザをハント グループに追加することにより、EM AC ユーザがログインしている場合にだけ、ユーザの電話機にコールを送信することができます。
WebDialer
WebDialer は Cisco Unified CallManager のクリックダイヤル アプリケーションで、ユーザはサポートされる任意の電話デバイスを使用して自分の PC から簡単にコールを発信できるようになります。管理者が CTI リンクを管理したり、JTAPI または TAPI アプリケーションを作成したりするための要件はありません。Cisco WebDialer には、独自のユーザ インターフェイスと認証メカニズムを提供するための、簡単な Web アプリケーションまたは Simple Objects Access Protocol（SOAP）が用意されているからです。どちらの方法でも、このソリューションは Cisco Unified CallManager クラスタ全体を完全な冗長性でサポートできます。
WebDialer Phone のサポート
次の SCCP 電話機は WebDialer をサポートしています。
• Cisco Unified IP Phone 7902G
• Cisco Unified IP Phone 7905G
• Cisco Unified IP Phone 7911G
• Cisco Unified IP Phone 7912G および 7912G-A
• Cisco Unified IP Phone 7940G、7941G、および 7941G-GE
• Cisco Unified IP Phone 7960G、7961G、および 7961G-GE
• Cisco Unified IP Phone 7970G および 7971G-GE
また、次の SIP 電話機は WebDialer をサポートしています。
• Cisco Unified IP Phone 7941G および 7941G-GE
• Cisco Unified IP Phone 7961G および 7961G-GE
• Cisco Unified IP Phone 7970G および 7971G-GE
（注） WebDialer は、SIP ロードを実行している Cisco Unified IP Phone 7905G、7911G、7912G、7912G-A、7940G、または 7960G ではサポートされません。
Cisco Unified CallManager および WebDialer のサービス パラメータ
WebDialer アプリケーションを有効にするには、システム管理者は Cisco Unified CallManager Serviceability インターフェイスからいくつかの Cisco Unified CallManager 機能サービスをアクティブにし、起動する必要があります。また、WebDialer サービス パラメータは、WebDialer アプリケーションおよびサービスの動作を決定するための設定およびカスタマイズのオプションを提供します。
WebDialer 用の Cisco Unified CallManager サービス
WebDialer アプリケーションは次の機能サービスに依存します。これらのサービスは、Serviceability ページから手動でアクティブにする必要があります。
Cisco WebDialer Web Service は WebDialer Web ベース アプリケーションまたはデスクトップ アプリケーションへのインターフェイスを提供し、Cisco CTIManager サービスおよび Cisco Unified CallManager データベースと対話します。Cisco CTIManager サービスは、電話とコールの制御のために Cisco CallManager Service および Cisco WebDialer Web Service とインターフェイスし、対話します。
WebDialer サービス パラメータ
次の項目は、WebDialer 機能に関連する Cisco WebDialer Web Service サービス パラメータの一部のリストです。
• CTIManager Connection Security Flag（デフォルト値 = False）
このパラメータは、Cisco WebDialer Web サービスと CTIManager との間でセキュアなトランスポート レイヤ セキュリティ（TLS）接続を使用するかどうかを決定します。このパラメータを True に設定した場合、アプリケーション ユーザの WDSecureSysUser のインスタンス ID に対して設定した Certificate Authority Proxy Function（CAPF）プロファイルを使用して、セキュアな接続が設定されます。このインスタンス ID は、サービス パラメータの CAPF Profile Instance ID for Secure Connection to CTIManager で指定する必要があります。
（注） アプリケーション ユーザの WDSecureSysUser は、インストール時に自動的に作成されるシステム アカウントです。削除することはできません。
• CAPF Profile Instance ID for Secure Connection to CTIManager（デフォルト値 = <None>）
CAPF Profile Instance ID は、WDSecureSysUser アプリケーション ユーザに対して Cisco WebDialer Web サービスと CTIManager との間で確立される TLS 接続またはインスタンスを識別するために使用される、数値または文字（あるいはその両方）の一意のストリングです。CTI Manager Connection Security Flag パラメータを True に設定した場合、このパラメータに値を設定する必要があります
• Primary Cisco CTIManager（デフォルト値 = 127.0.0.1）
このパラメータは、Cisco WebDialer Web サービスがコールを処理するために使用するプライマリ CTIManager の IP アドレスを指定します。これはクラスタ全体のパラメータで、プライマリとバックアップという 2 つの CTIManager サーバだけを設定できます。
• Backup Cisco CTIManager（デフォルト値 = <ブランク>）
このパラメータは、プライマリ CTIManager がダウンしている場合に、この Cisco WebDialer Web サービスがコールの処理に使用するバックアップ CTIManager の IP アドレスを指定します。これはクラスタ全体のパラメータです。
• List of WebDialers（デフォルト値 = <ブランク>）
このパラメータは、企業内のすべての WebDialer の IP アドレスとポート番号を指定します。複数のエントリを区切るにはスペースを使用します。このパラメータは、Redirector 機能が必要な場合にだけ入力する必要があります。
WebDialer の機能とアーキテクチャ
WebDialer アプリケーションには、WebDialer サーブレットと Redirector サーブレットの 2 つのサーブレットが含まれています。各サーブレットの動作と機能は似ていて、同時に実行するように設定できます。
WebDialer サーブレット
図20-13 は、単純な WebDialer の例を示しています。この例で、ユーザ John Smith は、Web ベース アプリケーションまたはデスクトップ アプリケーションを通じて WebDialer を起動します（ステップ 1）。WebDialer は、ログイン クレデンシャル要求で応答します。ユーザは、Cisco Unified CallManager エンドユーザ ディレクトリで設定される有効なユーザ ID とパスワードで応答する必要があります。この場合、John Smith は userID = jsmith および password = cisco を送信します（ステップ 2）。次に、このログインに基づいて、WebDialer は Cisco WebDialer Preferences 設定ページで応答し、ユーザは「User permanent device」または「Use Extension Mobility」のいずれかを指定する必要があります（ユーザが EM デバイス プロファイルを持つ場合）。この場合、ユーザ John Smith は、「User permanent device」を選択し、設定ページのドロップダウン メニューからその電話機に対して適切な MAC アドレス（SEP00036BC7B973）とディレクトリ番号（10001）を選択します（ステップ 3）。最後に、コールする電話番号を要求する画面が表示され（この値はすでに表示されていることがあります）、ユーザは Dial をクリックする必要があります。この場合、John Smith が 10002 と入力し、Dial をクリックすると、その電話機から番号 10002 の電話機 B へのコールが自動的に生成されます（ステップ 4）。
（注） ユーザが以前に WebDialer アプリケーションにログインし、Web ブラウザおよびサーバの Cookie がまだアクティブになっている場合、次の要求時に再ログインは求められません。Cookie がブラウザでクリアされるか、または WebDialer サーバの再起動によってクリアされた場合は、再ログインが要求されます。
Redirector サーブレット
Redirector サーブレットは、マルチクラスタまたは分散型のコール処理環境において、WebDialer 機能を提供します。この機能を使用すると、すべての Cisco Unified CallManager クラスタ間で単一の企業全体の Web ベース WebDialer アプリケーションを使用できます。図20-14 は、WebDialer アプリケーションの一部として Redirector サーブレットの基本的な動作を示しています。この例で、この会社には 3 つの Cisco Unified CallManager クラスタとして、New York、Chicago、San Francisco があります。3 つのクラスタはすべて、単一の WebDialer アプリケーションで設定されます。San Francisco クラスタは、Redirector として指定されます。企業全体の Redirector として San Francisco の WebDialer を指定するには、各クラスタ WebDialer サーバに独自の IP アドレス、および San Francisco の WebDialer IP アドレスで指定されたサービス パラメータ List of WebDialer が必要です（「WebDialer サービス パラメータ」を参照してください）。San Francisco の WebDialer サーバには、独自の IP アドレスと、企業内のその他の WebDialer サーバすべてのアドレスが設定されます。この例に基づいて、各 WebDialer サーバの List of WebDialers サービス パラメータ フィールドは、次のように設定されます。
• New York の WebDialer：List of WebDialers: 10.1.1.10:8443 10.3.1.0:8443
• Chicago の WebDialer：List of WebDialers: 10.1.1.10:8443 10.2.1.0:8443
• San Francisco の WebDialer：List of WebDialers: 10.1.1.10:8443 10.2.1.0:8443 10.3.1.0:8443
企業全体の Web ベース アプリケーションは San Francisco の Redirector を指し、New York のユーザから起動されます（図20-14 のステップ 1 を参照してください）。次に、Redirector はユーザのログインを要求し、New York ユーザは自分のユーザ ID とパスワードで応答します（図20-14 のステップ 2 を参照してください）。
（注） ユーザが以前に Redirector アプリケーションにログインし、Web ブラウザおよびサーバの Cookie がまだアクティブになっている場合、次の要求時に再ログインは求められません。
次に、Redirector は、（List of WebDialers サービス パラメータの設定に従って）企業内のすべての WebDialer に isClusterUser HTTPS 要求を送信します。この例で、要求は Chicago および New York の WebDialer サーバに送信されます（図20-14 のステップ 3 を参照してください）。New York ユーザは New York クラスタに対してローカルであるため、New York の WebDialer は肯定応答を返します（図20-14 のステップ 4 を参照してください）。最後に、New York ユーザはアプリケーション要求を処理するローカル WebDialer サーバに転送されます（図20-14 のステップ 5 を参照してください）。この転送はユーザに通知されません。ただし、ブラウザのアドレス バーの URL は、ユーザが Redirector から WebDialer サーバに転送されたときに変更されます。
（注） Redirector アプリケーションは、Cisco Unified CallManager データベースでのユーザ認証の必要な企業全体のアプリケーションであるため、すべての Cisco Unified CallManager クラスタですべてのエンドユーザのユーザ ID を一意にすることを強くお勧めします。一意でない場合、Redirector アプリケーションが isClusterUser 要求に対する複数の肯定応答を受信する可能性があります。この場合、Redirector アプリケーションによって、ユーザは自分のローカル WebDialer サーバを手動で選択するように求められます。このため、ユーザは自分のローカル サーバを知っている必要があります。正しくないサーバを選択した場合、WebDialer 要求は失敗します。
WebDialer のアーキテクチャ
WebDialer アプリケーションの機能と同様に、そのアーキテクチャについても理解することが重要です。図20-15 は、WebDialer のメッセージ フローとアーキテクチャを示しています。次の一連の対話とイベントが発生します。
1. WebDialer ユーザの電話機は、Cisco CallManager サービスを通じて登録し、コールの発信と受信を行います（図20-15 のステップ 1 を参照してください）。
2. ユーザの PC 上の WebDialer アプリケーションは、次のいずれかのインターフェイスを通じて Cisco WebDialer Web Service と通信します（図20-15 のステップ 2 を参照してください）。
このインターフェイスは、HTTPS プロトコルに基づいて Web ベースのアプリケーションで使用されます。これは、Redirector サーブレットへのアクセスを提供する唯一のインターフェイスです。
–SOAP（Simple Object Access Protocol）over HTTP
このインターフェイスは、SOAP インターフェイスに基づいてデスクトップ アプリケーションで使用されます。
3. WebDialer Web サービスは、Cisco Unified CallManager データベースからユーザおよび電話の情報を読み取ります（図20-15 のステップ 3 を参照してください）。
4. 次に、WebDialer Web サービスは、回線と電話の制御情報を交換するために、CTIManager サービスと対話します（図20-15 のステップ 4 を参照してください）。
5. CTIManager サービスは、WebDialer 電話制御情報を Cisco CallManager サービスに渡します（図20-15 のステップ 5 を参照してください）。
（注） 図20-15 は、すべて同じノードで実行されている Cisco Unified CallManager、CTIManager、および WebDialer Web Service サービスを示していますが、この設定は必須ではありません。これらのサービスはクラスタ内の複数のノードに分散できますが、説明を簡単にするためにここでは同じノードにあるものとしています。
WebDialer の URL
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 ユーザがダイヤルする番号です）
図20-16 は、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 を使用するクリックダイヤル アプリケーションで同じコードを使用できます。
図20-16 WebDialer URL の HTML の例
WebDialer の冗長性
WebDialer アプリケーションの冗長性は、次の 2 つのレベルで実現できます。
このレベルでの冗長性については、冗長性を、WebDialer サービスおよび CTIManager サービスの冗長性に関して検討する必要があります。同様に、パブリッシャの冗長性の欠如、およびこのコンポーネントの障害の影響も検討する必要があります。
このレベルでの冗長性については、ユーザの電話機および WebDialer ユーザ インターフェイスに関連して検討する必要があります。
サービスとコンポーネントの冗長性
図20-15 に示すように、WebDialer 機能は、主に Cisco WebDialer Web Service および Cisco CTIManager サービスに依存します。WebDialer サービスの場合は、List of WebDialers サービス パラメータ（「WebDialer サービス パラメータ」を参照）に複数の WebDialer サーバの IP アドレスをリストし、クラスタ内の複数のノードでサービスを有効にすることで、冗長性を実現します。CTIManager の場合、冗長性は、プライマリおよびバックアップのメカニズムを使用して自動的に組み込まれます。Primary Cisco CTIManager および Backup Cisco CTIManager のサービス パラメータを使用すると、クラスタ内に 2 つの CTIManager サーバまたはサービスを定義できます（「WebDialer サービス パラメータ」を参照してください）。これらのパラメータを設定すると、CTIManager サービスに冗長性を与えることができます。このため、プライマリ CTIManager に障害が発生した場合でも、CTIManager サービスはバックアップ CTIManager から提供できます。Web ベース（またはデスクトップ）アプリケーションが指している WebDialer サーバに障害が発生し、クラスタ ノード上のプライマリおよびバックアップ CTIManager サービスにも障害が発生した場合、WebDialer アプリケーションはダウンします。
前述のように、パブリッシャは Cisco Unified CallManager データベースへの書き込み時に単一の障害点となります。WebDialer アプリケーションに対するパブリッシャの障害の影響はわずかです。パブリッシャに障害が発生しても、WebDialer アプリケーションのすべての部分が引き続き動作します。
デバイスと到達可能性の冗長性
デバイス レベルでの WebDialer の冗長性は、いくつかのメカニズムに依存しています。まず第 1 に、ユーザの電話機は、デバイス登録用のデバイス プールと Cisco Unified CallManager グループ設定の組み合せによって提供される組み込み冗長性に依存します。
WebDialer アプリケーションには、サーバから見た場合の冗長性を与えることはできますが、WebDialer のユーザ インターフェイスにはデフォルトで冗長性がありません。WebDialer ユーザ インターフェイスは、WebDialer サーバとの接続を Web ブラウザまたはデスクトップ アプリケーションに依存しているため、WebDialer URL またはデスクトップ アプリケーションのポインタは、IP アドレスで WebDialer サーバをコールします。WebDialer サーバに障害が発生すると、ユーザ インターフェイスは WebDialer アプリケーションと通信できなくなります。フェールオーバー メカニズムが Web ベース アプリケーションまたはデスクトップ アプリケーションに組み込まれない限り、アプリケーション内でフェールオーバーを実現することはできません。その代わりに、図20-3 に示すようなサーバ ロード バランシング（SLB）メカニズムを使用して、フェールオーバーを実現できます。この場合、Web ベース アプリケーションまたはデスクトップ アプリケーションは、クラスタ内で設定された WebDialer サーバの実 IP アドレスのフロントエンドとなる仮想 IP アドレスを指します。このようにすると、同じユーザ インターフェイス内で WebDialer 間のフェールオーバーが可能になります。
WebDialer のガイドラインと制限
次のガイドラインと制限は、Cisco Unified CallManager テレフォニー環境内の WebDialer の配置と動作に関連して適用されます。
• 管理者は、すべての WebDialer ユーザを Cisco Unified CallManager エンドユーザ ディレクトリの電話機またはデバイス プロファイルに関連付ける必要があります。
–電話機が関連付けられていない状態でユーザが 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」
（注） WebDialer および EM アプリケーションは組み合せて使用できます。WebDialer と EM の相互作用の詳細については、「WebDialer と EM の相互作用」を参照してください。
• List of WebDialers サービス パラメータ（「WebDialer サービス パラメータ」を参照）を設定するときは、WebDialer IP アドレスと同時にポート番号 8443 を指定する必要があります。
• Client Matter Codes（CMC）または Forced Authorization Codes（FMC）を使用している場合、WebDialer ユーザはトーンが聞こえたときに、電話機のキーパッドを使用して適切なコードを入力する必要があります。トーンが聞こえたときに適切なコードを入力しないと、コールの失敗を示すリオーダー トーンが聞こえます。
WebDialer と EM の相互作用
WebDialer ユーザは、EM を使用してそれぞれの電話機にログインできます。EM ユーザは、Cisco WebDialer Preferences ページで Use Extension Mobility 設定を選択するだけで、WebDialer を使用できます。
フィードバック